Remote code execution 0 day in up-to-date Struts 2 applications: Some months ago Struts2 announced a security vulnerability S2-020 that allowed ClassLoader manipulation and that could be used to get Remote Code Execution on certain application servers like Tomcat 8. The fix for this vulnerability was to forbid the (.*\.|^)class\..* regex from action parameters. However a bypass was made public that basically consists in changing the dot notation for the square bracket notation.
I played with Fusion level05 for a couple of days last Xmas and although I found how to smash the stack, I couldn’t find any reliable way of leaking the .text base address to bypass PIE protection so I left it there. Yesterday, a tweet from @Newlog_ got me thinking it could be a good idea to post what I’ve done so far in case anyone wants to pick it from there and help solving the level.
This blog was published in the HP Security research blog but publishing it here for greater dissemination:
Advisory overview Restlet is a lightweight Java framework for building RESTful APIs. It comes in different flavors (Java SE, Java EE, Android, Google Web Toolkit and Google App Engine) and is composed of a core API and different extensions that provide additional functionality.
While adding support for the Restlet API to HP Fortify SCA, the Software Security Research group discovered that the XStream extension prior to 2.
In this task we were presented an audio file (similar.ogg) containg a signal that sounded like a Fax machine. Actually a Hint later published read 129 LPM (Lines per minute) so it looked like a RadioFax or HF Fax transmission. So we could use RadioFax software to extract the image being transmitted.
We tried different tools like MultiPSK, MIXW and SeaTTY and finally got some “clear enough” images:
and
We saw the contents of a file being transmitted in something that looked like UUencoding:
“Wait, I’m not clear on what’s happening here. Is this even possible? Just by giving an application a single piece of XML, you can cause it to steal other files for you?”
Those were a customer’s words when an XML External Entity injection vulnerability was reported on one of his applications and although these kinds of attacks are known since the early 2000s I’m still under the impression that they are not known and tested enough by application developers and security auditors.
OK, so let start reviewing the FourGoats App. First, If you havent done yet, clone the ForGoats repo from github to get the source code.
Try to get an idea of how does the app work, install it in your device and/or emulator and get familiar with the different activities and application flow.
Open the Main activity and check what its doing. Basically, its looking for a sessionToken and if she cannot find it, it will start the Login Activity, otherwise it will take the user to the Home or AdminHome activities.
If we keep on reading the Login activity, we will soon spot an asynchronous task used to validate the user credentials in the server and we will see that there is a harcoded user/password pair that will set up the admin property and so it will enable us to access the AdminHome Activity:
if (userName.equals("customerservice") && password.equals("Acc0uNTM@n@g3mEnT")) userInfo.put("isAdmin", "true"); If we enter these credentials (and the user is registered in the backend), we will be able to access the AdminHome Activity:
I have been thinking about starting a blog for a while but never got something to say that could not be found googling around (or that was too secret to tell in public :) ). Anyway, Ive being doing some research lately on secure coding on Android applications and I found OWASP goatDroid very instructive and formative but although the source code is freely available here. I could not find a comprehensive list of vulnerabilities present in the code so I decided to start a serie of posts about Android vulnerabilities using goatdroid to show them off.
