Recently, researchers at Trustwave’s SpiderLabs spoke at Black Hat Europe on the dangers of simply reflecting data back to the requesting user as part of an HTTP request/response exchange. When you think about it, this stands to reason, after all, it’s what Cross-site Scripting attacks are born from. What’s interesting is that the new research discussed another way in which it could be exploited.
The basic premise of the attack (as described on SpiderLabs’s Reflected File Download whitepaper) is as follows:
- The user follows a malicious link to a trusted web site
- An executable file is downloaded and saved on the user’s machine. All security indicators show that the file was hosted on the trusted web site
- The user executes the file which contains shell commands that gain complete control over the computer
So how does it work? On a recent engagement, one of our consultants found a similar issue. In their case, it was a stored variant of the issue SpiderLabs describe but in other regards, it was identical. The consultant discovered that the application they were testing used two APIs that allowed for the storage and retrieval of data, like so:
POST /putData HTTP/1.0
...
{"id":12345, "input":"asdf||calc.exe||pause"}
This data could then be retrieved using the following URL:
- http://URL/getData/12345;1.bat
Requesting this in a browser results in the browser believing that the user has downloaded what appeared to be a batch file called 12345;1.bat. If the user executes this file, then calc.exe (part of our original input) will be executed.
As with other similar attacks, which exploit variances in how user controlled data is treated by different components of a solution (in this case, the browser and the server), once you know what to watch out for, it’s fairly easy to mitigate.
Specifically:
- Validate all user input
- Sanitise by means of context sensitive encoding/escaping any user input that remains
- Avoid wildcard mappings such as /getdata/* on exposed web services
- Ensure that you’re correctly setting the important HTTP headers such as Content-Type and Content-Disposition (and other related headers such as X-Content-Type-Options) so that direct requests for the URL cause the file to be downloaded
This last point is particularly important, browsers will often attempt to automatically render downloaded content using whatever application is rendered for the target file type. Sending a Content-Disposition header of:
attachment; filename=1.txt
precludes this, as no matter whether it is saved or opened, it will be treated as text, a relatively safe file type.
All in all, a nice catch and one we’ll definitely use in our red team engagements.