RCE and Complete Server Takeover of http://www.█████.starbucks.com.sg/

Summary

This report from @spaceraccoon demonstrated a valid attack resulting in RCE and full compromise of the target. The detailed and thorough report was especially helpful throughout the triage process, and ultimately helped us reproduce and resolve the issue as quickly as possible. The vulnerable site has been taken offline.

We'd like to thank @spaceraccoon for the submission, and hope to continue to see reports like this in the future.

Chaining CVEs: From a 404 Page to RCE

Initial Recon

I first got to this subdomain via the usual subdomain enumeration. It looked unpromising: a 404 page that said “this website is not in use,” a little picture, and nothing else. Running path discovery for the usual pages turned up nothing, not even a useful robots.txt. However, I took a closer look at the footer. It said something like Copyright 2010 | Built on xxxx CMS (not the real CMS name). That was promising because it told me that the site was both old and built on a custom CMS, meaning it was far more likely to be vulnerable. Google searching for the CMS turned up nothing, it was that obscure.

That was when I had the idea to try the path website.com/xxxx (entering the name of the CMS into the path). I was immediately redirected to /josso/signin (approximate path since the site has been taken offline) which has a login form. Bingo!

The Red Herring

I tried the usual trick: entering the username and password admin. My excitement went through the roof when a “success” message popped up, but it seemed to hit an error. There must have been something wrong on the backend, because all I got was an empty page. Nothing else worked and the credentials also seemed to be disabled after the first login. It was a red herring.

The First CVE

However, messing around further with the URL path suddenly gave me an Apache Tomcat stack trace that revealed the version number: 5.5.20. On some specific (mis)configurations, Tomcat could be vulnerable to CVE-2007-0450, a medium-level directory traversal vulnerability in the mod_proxy plug-in. You trigger it by adding some special characters to the path (read the CVE for more info). So I tried site.com/josso/%5C../ and bingo! I was redirected to a Jboss web console page. It seemed like I had bypassed the internal proxy directly to the Jboss instance running on localhost.

The Second CVE

I wasn’t familiar with Jboss, but doing some reading up informed me that it was a Red Hat app server that served Java applets. In addition, I found CVE-2007-1036, a High vulnerability that said that the Jboss web console needed to be protected to prevent unauthenticated server admin requests. As it turned out, thanks to the traversal CVE, I had managed to bypass the local proxy and get direct web access to the Jboss web console, which also wasn’t password-protected.

Remote. Code. Execution!

From then on, RCE was quick. There are many attacks you can use, but I used the jexboss tool that allowed me to quickly gain RCE by exploiting Java deserialization vulnerabilities. One twist was that since I needed to bypass the local proxy, instead of attacking /web-console, I had to send all requests to /josso/%5C../web-console. I could then do anything I wanted on the server: modify the home page, check out other hosts on the local network, and view a useful backup SQL dump...

Lessons

I took away a few things from this: sometimes, a 404 or redirect isn’t the end of the road. See if the server still has some pages left lying around that you can exploit. Furthermore, think about how you can chain vulnerabilities to hit the RCE holy grail. Next, back up your RCE by looking for sensitive information or horizontal escalation opportunities on the server. Are there other hosts on the network? Clues in /etc/passwd? The opportunities are endless.