JBoss Richfaces 3.X RCE

Context

While on an engagement for ASU, I ran into a newly built web application that was running Red Hat JBoss. For those of you who don’t know what JBoss is, it is an Application platform that “delivers enterprise-grade security, performance, and scalability in any environment”. Another thing to note before reading this post is that RichFaces, a JBoss component, is an “advanced UI component framework for easily integrating Ajax capabilities into business applications using JSF”. Now that’s all said and done, lets get on with how to RCE this sucker.

While reviewing this web application for security problems, there were a few systemic issues I noticed. The server itself was very slow and buggy. The overall security of the application had little to no “low-hanging fruit”. This is pretty standard for web applications that have a bug bounty program. However, this application in particular was very outdated and contained various xHTML functions that I found while crawling the application.

Methodology

Some shit here about methodolies and my approach to pentesting this app.
Some things to keep in mind:
The application was using the JBoss(Java) Seam framework and was a HEAVY state based application. So what does this even mean? There are basically two opportunities to win on an application like this…
Find a way to exploit the Seam framework || Find a Java deserialization bug

Research

There’s a problem with older technology. Back when the tech was built, they didn’t have security in mind. This is especially true when it comes to government IT systems such as mainframes. Never the less, old technology breaks, you just have to find where the weak spots are. After doing extensive research on the Java Seam framework and how it works with web applications, I found a few interesting things:
1. The last stable release for the Java Seam framework was in January 2012.
2. Richfaces is a huge dependency and a LOT of applications still use it.
3. Typlically, upon CVE submission if the CVE is less than a 9.5, a new CVE will not be accepted for software past end of life of 5+ years

Figure 1 – Image of similar Java based application

There’s an old saying in security, check the source!

This looked to me like a Java object????

So I read some interesting things about how RichFaces has been exploited before using this method. However, the source was a sketchy Chinese website. I attempted to decipher the this article to build the exploit. After trying to get everything to work, I got REKT! Most of the library Jar dependencies were out of date and do not work anymore. But at least the code compiles?

Putting it all together

The sketch Chinese website led me to a Github page that was in English didn’t have very good instructions. So the only thing left to do is was OSINT for the missing and broken dependencies and find some old stuff. I decided to waste another 5 hours of my life by searching for this. I finally came across a JBoss El API page that has the same methods needed for this exploit.

After finding everything I needed from the right dependencies to the right version of Eclipse to build the application, I finally got everything working. Or so I thought….

The steps were simple,

Create a new Java Web Project in Eclipse.
Extract dependencies in Jar format to the lib folder.
Read Chinese from sketch website to get the Main.java class.
Create payload and compile

After everything compiled and executed correctly I had the final Java Object that I needed to exploit this beast. So I tried running a simple command to create a file called WinnaWinna in the root directory and executed it .

Andddddd broken. Turns out I just cant spell and missed a needed paramater in the URL. Go figure. So for my final attempt as if this is a Magic Show and the magician just sucks, this was my final GET request:

WinnWinna was created in the root directory. For the screenshot purposes of this write-up, I used the tmp dir (I know someone was gonna say shit about that so I had to say it)

For all of you wondering if I got the 1337 /etc/passwd file :