I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. I will be teaching SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at many events this year. This is one of the many techniques that I will be exploring in this series of posts. When I am teaching one of the points I make is to never consider the vulnerabilities in isolation, using them in combination truly demonstrates the risk and impact. My team were performing a web application penetration test, and the list of things that it was vulnerable to was quite impressive!
The list of vulnerabilities:
- Content can be framed
- XSS
- Method interchange
- DoS, application hangs on long abnormal inputs, relies on client side validation
- Able to upload files, including malicious content
- Information leakage, internal server names, IP addresses, install locations...
- XSRF
- User enumeration via forgot password function
- Administrators can disable their own account
We had determined that the primary threat would be for a user to escalate privileges and access information from other accounts. In order to achieve this goal we concentrated on the persistent XSS and XSRF. We would use the persistent XSS to launch the XSRF attack. We leveraged all of the vulnerabilities in one way or another, in other words, we were having a good time! Once you have XSS in an application all that you need is one or more attractive transactions to be performed. We find that XSRF is the best XSS payload there is.
Using the persistent XSS:
- Create trouble ticket
- Ticket will be first viewed by administrator
- Script executes in the administrator browser
- Administrator can perform all of the functions vulnerable to XSRF
A significant number of the functions were vulnerable to Cross Site Request Forgery (CSRF or XSRF), which is also known as session riding and transaction injection. The functions that were vulnerable had absolutely no anti-XSRF protection, and the interesting ones were all in the administrator part of the site.
An attacker could add a new user, put the user in the administrator group, change the passwords, and log out. The problem was, each of these were different transactions, and had to be performed in the correct order to pull off the attack. The application owner and the development team did not appreciate the severity of the issue, and pointed out that their automated scanning tool had not identified the issue, therefore it didn't exist. Even if the issue did exist, it could only be of medium severity, because their tool said so. To top it all off, even if an attacker could pull off this mythical attack, it could not be done in one shot, the administrator had to click multiple times. In short, they did not appreciate the impact, the attacker would have complete control over the application. In order to make our point a demonstration was in order, that did the following:
- Add a new user
- Put the user in an administrator group
- Lockout the super-user account
- Logout the super-user account
- Did the functions in the correct order
- Each function would wait for the last to complete
- Was all in one HTML page
- Could be delivered as a single XSS payload
- Would force the administrator to view a certain Rick Astley video
- OK, we didn't do the last one, that would be WAY too mean.
Google-fu was with us that day, we discovered a post by Tim Tomes (lanmaster53) that described exactly what we wanted to do. He also had sample code to start with:
http://www.lanmaster53.com/2013/07/multi-post-csrf/
The next problem was that obviously we could not use their custom application to do the proof of concept, but needed another application with similar vulnerabilities to demo for this post. Once again the force of Google-fu was with us:
http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php
Omeka is a free and open source web publishing application. Also quick and easy to install. Also quick and easy to exploit. Last, but not least, we could download the vulnerable version 2.2 and be up and running in no time.
Administrator (victim) logs into the application:
The add user function as seen in an interception proxy (OWASP ZAP):
The Add User function was just one of many that were vulnerable to XSRF, with no protection as shown above. The api_key_label POST parameter id not sanitized, it is our persistent XSS vector. The administrator would have to invoke that function for the code to run. The code used is shown below in a PDF format.
The code running:
Now the code. The important parts are getting the script to run, we used a body onload. The script runs each one of the forms. The forms each contain one of the XSRF attacks. Each form loads in a different iframe. The first one runs, then the second one waits from the iframe onload to fire before it runs, and so on. Victim logs in, they check their queue, the XSS runs, the XSRF runs, they have lost control of the application, attacker win, or in this case a very effective demonstration of risk.
I am teaching SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at multiple SANS training events around the world in 2018.
Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
Certified SANS Instructor https://www.sans.org/instructors/adrien-de-beaupre
Co-author of SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques
References:
- https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
- http://cwe.mitre.org/data/definitions/352.html
- http://www.lanmaster53.com/2013/07/multi-post-csrf/
- http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php
- http://omeka.org/
- https://www.youtube.com/watch?v=dQw4w9WgXcQ
Code:
