I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. Next time up is SANS Sec560 network penetration testing in Albuquerque, NM. 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. I was performing a web application penetration test, and the list of things that it was vulnerable to was quite impressive!: The list of vulnerabilities:
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! Using the XSS:
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 my point a demonstration was in order, that did the following:
My Google-fu was with me that day, I discovered a post by Tim Tomes (lanmaster53) that described exactly what I wanted to do. He also had sample code to start with: Administrator (victim) logs into the application: The add user function as seen in an interception proxy (OWASP ZAP): The code running: Now the code. The important parts are getting the script to run, I used a body onload. The script runs each one of the forms. The forms each contain one of the XSF 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. Cheers, Check out BSides Ottawa, our CfP is still open! Con is 5-6 September References: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) Code: <html> <body onload="runme();"> <form name="xsrf0" action="http://intru-shun.ca/omeka/admin/users/add" method="POST" target="frame0"> <form name="xsrf1" action="http://intru-shun.ca/omeka/admin/users/change-password/1" method="POST" target="frame1"> <form name="xsrf2" action="http://intru-shun.ca/omeka/admin/users/logout" method="POST" target=frame2"> <iframe name="frame0"></iframe> <script> </body> |
Adrien de Beaupre 353 Posts ISC Handler Aug 9th 2014 |
Thread locked Subscribe |
Aug 9th 2014 7 years ago |
Just had to check that youtube link ;p
|
Anonymous |
Quote |
Aug 13th 2014 7 years ago |
Sign Up for Free or Log In to start participating in the conversation!