accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3460) Monitor should not allow HTTP TRACE
Date Wed, 31 Dec 2014 21:53:13 GMT

    [ 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)

Mime
View raw message