[jira] [Commented] (ACCUMULO-3460) Monitor should not allow HTTP TRACE
[ https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559871#comment-14559871 ] Christopher Tubbs commented on ACCUMULO-3460: - The solution I applied was to enforce a security constraint which required one to be authenticated with an unspecified (thus, impossible to satisfy) set of roles, before TRACE could be permitted. As a result, the error message is a 403 Forbidden (if the roles had been specified, it would have returned a 401 Unauthorized... something we may want to consider in the future if we make it so that authenticated users are permitted to do TRACE). An alternative solution would have been to implement doTrace in all of our servlets, which responded with a 405 Method Not Allowed error, like the DefaultServlet does (which we could get by extending DefaultServlet). However, I felt that a solution with a server-level constraint would be more robust to changes in the future (like somebody forgetting to extend a base Servlet or changes to the underlying behavior of DefaultServlet). I also wasn't sure if there'd be any other side-effects of extending DefaultServlet, which we wouldn't want. Monitor should not allow HTTP TRACE --- Key: ACCUMULO-3460 URL: https://issues.apache.org/jira/browse/ACCUMULO-3460 Project: Accumulo Issue Type: Bug Components: monitor Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 Reporter: Sean Busbey Assignee: Christopher Tubbs Priority: Minor Labels: security Fix For: 1.6.3, 1.8.0, 1.7.1 Time Spent: 0.5h Remaining Estimate: 0h A Nessus scan pinged my test cluster because the Accumulo monitor allows HTTP TRACE requests. (ref: [an overview of the general problem class|http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf]) The issue isn't bad unless * there's a same-origin-policy bypass for the user browser * there's an auth token we care about Exploits the bypass the same-origin-policy happen, so it's best to clean up server side if possible. The only auth tokens present in the Monitor are when we make use of the ShellServlet from ACCUMULO-196. We rely on the session state for auth, so there isn't a risk of leaking auth info directly, but we would leak the session id. The CSRF added in ACCUMULO-2785 means just the session id wouldn't be enough for impersonation, but if an attacker can read one requested page we have to presume they can read another. We should clean up our configs to disallow HTTP TRACE as a proactive measure. Marking minor since an attack vector would need an enabling vulnerability on the client side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3460) Monitor should not allow HTTP TRACE
[ https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14556742#comment-14556742 ] Sean Busbey commented on ACCUMULO-3460: --- Let me know when you think it's fixed and I'll see if I can update where my nightly scans check. Monitor should not allow HTTP TRACE --- Key: ACCUMULO-3460 URL: https://issues.apache.org/jira/browse/ACCUMULO-3460 Project: Accumulo Issue Type: Bug Components: monitor Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 Reporter: Sean Busbey Assignee: Christopher Tubbs Priority: Minor Labels: security A Nessus scan pinged my test cluster because the Accumulo monitor allows HTTP TRACE requests. (ref: [an overview of the general problem class|http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf]) The issue isn't bad unless * there's a same-origin-policy bypass for the user browser * there's an auth token we care about Exploits the bypass the same-origin-policy happen, so it's best to clean up server side if possible. The only auth tokens present in the Monitor are when we make use of the ShellServlet from ACCUMULO-196. We rely on the session state for auth, so there isn't a risk of leaking auth info directly, but we would leak the session id. The CSRF added in ACCUMULO-2785 means just the session id wouldn't be enough for impersonation, but if an attacker can read one requested page we have to presume they can read another. We should clean up our configs to disallow HTTP TRACE as a proactive measure. Marking minor since an attack vector would need an enabling vulnerability on the client side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3460) Monitor should not allow HTTP TRACE
[
https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262454#comment-14262454
]
Sean Busbey commented on ACCUMULO-3460:
---
Here's a redacted version of me replicating the Nessus probe against an
ssl-enabled monitor on a cluster running the current master branch.
{code}
[busbey@gateway ~]$ openssl s_client -connect monitor.example.com:50095
CONNECTED(0003)
snip server cert info
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 1499 bytes and written 499 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-RSA-AES256-SHA384
Session-ID: 54A465E965F7EF56A3A7FB43942B8EB0A8105E23EED078DA7AB8D15FC811F82C
Session-ID-ctx:
Master-Key:
75F2F0B204A4CF15A8020CE64DA44F78E2F7FE6D379EF5F42C3F6E8C68536CC55FD432962D4416F8F0176EF131807C9B
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1420060137
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
TRACE /Nessus1536302595.html HTTP/1.1
Connection: Close
Host: monitor.example.com
Pragma: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Authorization: Basic YWRtaW46YWRtaW4=
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 371
Connection: close
Server: Jetty(9.1.5.v20140505)
TRACE /Nessus1536302595.html HTTP/1.1
Accept-Language: en
Authorization: Basic YWRtaW46YWRtaW4=
Host: monitor.example.com
Accept-Charset: iso-8859-1,*,utf-8
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Connection: close
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Pragma: no-cache
closed
{code}
What we want is to not get a response of HTTP/1.1 200 OK with the contents
echoed back. Ideally we'd get rejected with a message that TRACE isn't allowed,
but an empty response would probably be fine.
Monitor should not allow HTTP TRACE
---
Key: ACCUMULO-3460
URL: https://issues.apache.org/jira/browse/ACCUMULO-3460
Project: Accumulo
Issue Type: Bug
Components: monitor
Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2
Reporter: Sean Busbey
Priority: Minor
Labels: security
Fix For: 1.5.3, 1.7.0, 1.6.3
A Nessus scan pinged my test cluster because the Accumulo monitor allows HTTP
TRACE requests. (ref: [an overview of the general problem
class|http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf])
The issue isn't bad unless
* there's a same-origin-policy bypass for the user browser
* there's an auth token we care about
Exploits the bypass the same-origin-policy happen, so it's best to clean up
server side if possible.
The only auth tokens present in the Monitor are when we make use of the
ShellServlet from ACCUMULO-196. We rely on the session state for auth, so
there isn't a risk of leaking auth info directly, but we would leak the
session id.
The CSRF added in ACCUMULO-2785 means just the session id wouldn't be enough
for impersonation, but if an attacker can read one requested page we have to
presume they can read another.
We should clean up our configs to disallow HTTP TRACE as a proactive measure.
Marking minor since an attack vector would need an enabling vulnerability on
the client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
