Bug 743006 (CVE-2011-3609) - CVE-2011-3609 JBoss AS: CSRF in the administration console & HTTP management API
Summary: CVE-2011-3609 JBoss AS: CSRF in the administration console & HTTP management API
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2011-3609
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 743016
TreeView+ depends on / blocked
 
Reported: 2011-10-03 14:50 UTC by Jan Lieskovsky
Modified: 2019-09-29 12:48 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-02 04:12:51 UTC


Attachments (Terms of Use)

Description Jan Lieskovsky 2011-10-03 14:50:01 UTC
It was found that the JBoss Application Server did not properly restrict access (did not specify list of valid URIs) to the management console information (for example via the "Access-Control-Allow-Origin" HTTP access control flag). A remote attacker could provide a specially-crafted web page, which once visited by a valid, JBoss Application Server user, with the administrator privilege, could lead to unauthorized information leak.

Comment 2 Jan Lieskovsky 2011-10-03 16:29:54 UTC
Acknowledgements:

Red Hat would like to thank David Black for reporting this issue.

Comment 4 Jean-frederic Clere 2011-10-04 06:31:38 UTC
"Access-Control-Allow-Origin" depends on the browser and I don't think it make sense to use it. Probably filtering the URL in the application is the way  to go.

Comment 5 David Jorm 2011-10-05 07:30:25 UTC
This report is a bit confusing. Here's what I make of it:

1) We're not protecting against CSRF. We need to fix that.
2) Setting Access-Control-Allow-Origin: * means that attempts to apply CSRF protection will probably fail. I don't see a good reason for us setting this header, can we just remove it altogether and not set it at all? Or does it serve some purpose I'm not aware of?
3) The PoC JS demonstrates that the management console's JSON interface is open. I don't think this demonstrates the problem with Access-Control-Allow-Origin: * or CSRF, although the reporter might intend it to. To me it just demonstrates that it's open by default.

I'm told that the console will require authentication in EAP 6. The take away message from this report is that we need to protect against CSRF.

Comment 6 Jean-frederic Clere 2011-10-05 08:00:40 UTC
Are you saying that the console isn't protected at all or the JSON interface?
I am speak of authorisation and cookies or URL encoded sessionid.

Again the ccess-Control-Allow-Origin: * is a new feature we should be carefull in using it.

Comment 7 Jan Lieskovsky 2011-10-05 08:09:12 UTC
David Jorm, my team-mate responsible for dealing with JBoss products flaws, has provided his summary of the flaw at:
https://bugzilla.redhat.com/show_bug.cgi?id=743006#c5 (made it to be a public comment)

Jean, let us know if the above is sufficient or if you would desire some further clarification.

Thanks, Jan.

Comment 8 Jean-frederic Clere 2011-10-05 08:45:24 UTC
[jfclere@jfcpc jboss-as-7.1.0.Alpha2-SNAPSHOT]$ bin/jboss-admin.sh -c --file=bin/scripts/secure-standalone-mgmt.cli
Connected to standalone controller at localhost:9999
#1 /core-service=management/security-realm=PropertiesMgmtSecurityRealm:validate-address
#2 /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=PropertiesMgmtSecurityRealm)
#3 /core-service=management/management-interface=native-interface:write-attribute(name=security-realm,value=PropertiesMgmtSecurityRealm)
The batch executed successfully.
[jfclere@jfcpc jboss-as-7.1.0.Alpha2-SNAPSHOT]$ curl -v localhost:9990/management
* About to connect() to localhost port 9990 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 9990 (#0)
> GET /management HTTP/1.1
> User-Agent: curl/7.21.3 (i386-redhat-linux-gnu) libcurl/7.21.3 NSS/3.12.10.0 zlib/1.2.5 libidn/1.19 libssh2/1.2.7
> Host: localhost:9990
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< Content-length: 0
< Www-authenticate: Digest realm="PropertiesMgmtSecurityRealm",nonce="8cacd05d3d78d27bbe2eebab39465258"
< Date: Wed, 05 Oct 2011 08:44:14 GMT
< 
* Connection #0 to host localhost left intact
* Closing connection #0

I think you should secure and try again.

Comment 9 David Jorm 2011-10-06 03:13:44 UTC
With authentication applied as per comment #8, I am unable to reproduce a CSRF attack, but I still think this is something we need to fix. The dmr-encoded JSON API does not seem to allow any actions to be triggered by GET requests, only POST requests. There are two main mechanisms for effecting CSRF attacks using POST requests:

1) Using a <form> with Javascript to auto-submit the form. This is not feasible in this case because the form will generate a POST body consisting of key/value pairs rather than an encoded JSON string.

2) Using Javascript to call XMLHTTPRequest with the encoded JSON string in the POST body. This fails because the request is cross-domain, requiring CORS to function. As previously noted, the Access-Control-Allow-Origin: * header should enable this. It turns out that CORS includes a pre-flight request [0] that calls the URL using the OPTIONS HTTP verb, excluding user credentials. This request fails, with 401 Authentication Required. Enabling the security realm seems to require authentication for all HTTP verbs, and I can't see how to disable it for the OPTIONS verb. If I could do that, I'm confident a CSRF attack is possible.

There could also be other techniques I'm not aware of. There's no CSRF token being used, and I think we need to add one.

[0] http://www.w3.org/TR/cors/#preflight-request

Comment 10 David 2011-10-06 11:41:27 UTC
So If you can send a valid json post (non-base64 encoded something) to ES within a text-plain post then something like the following may work:

 <form action="http://localhost:9990/management" method="post" id="sup"  enctype="text/plain">
        <input id=32 name="{'system-property' : 'x" type="hidden" value="likeaboss' }"></input>
</form>

Comment 11 Jean-frederic Clere 2011-10-07 10:21:43 UTC
For me adding authentication looks enough and I am -1 adding the stuff like: "Access-Control-Allow-Origin: * header".

Comment 12 Jan Lieskovsky 2011-10-07 11:01:09 UTC
(In reply to comment #11)

Hi Jean,

  if under authentication you mean adding CSRF token protection, then right, it should be probably sufficient to remove this deficiency (though David can comment more appropriately, since he is testing this). Agree that "Access-Control-Allow-Origin: * header" might
be new feature not necessarily required to fix this.

Jan.

> For me adding authentication looks enough and I am -1 adding the stuff like:
> "Access-Control-Allow-Origin: * header".

Comment 13 David 2011-10-07 12:50:46 UTC
I'll have to have a play and see what the server actually accepts with and without auth. I don't know enough / what the server accepts. From David Jorm's comment it seems like he knows more about what (the server) accepts.

Comment 14 David Jorm 2011-10-10 04:32:23 UTC
I am now able to reproduce a CSRF attack, using non-encoded JSON as suggested by dave b.

Comment 22 David Jorm 2011-11-07 23:34:44 UTC
This development is being tracked in JIRA:
https://issues.jboss.org/browse/AS7-2400

Comment 25 David Jorm 2011-11-28 04:19:21 UTC
This issue has been addressed in the following commit:

https://github.com/jbossas/jboss-as/commit/29cf3610d8dab1af0227842d877b926543b72273

Comment 26 David Jorm 2011-12-02 04:11:30 UTC
This issue is now resolved in JBoss AS 7.1.0 Beta 1.

Comment 27 David Jorm 2011-12-02 04:12:51 UTC
Statement:

Not vulnerable. This issue only affects community JBoss AS 7 prior to 7.1.0
Beta 1. It does not affect components shipped with any Red Hat products.


Note You need to log in before you can comment on or make changes to this bug.