[
https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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(00000003)
<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)
