Companies battle with users who download files from the Internet at work and then execute them. Unsuspicious files are often infected with malware. A common procedure to decrease the amount of infections is to block common bad file types (for example .exe, .scr or .zip), before the files can enter the internal network. The preconditions are that users are only able to communicate with the Internet through a HTTP proxy and the internal email server. A whitelist on the email- and web-content filter, which only allows .docx to go through, can greatly decrease the amount of malware infections. Attackers will have to use exploits (e.g. in the browser, a plugin or office exploits) to perform code execution on the clients.
Sadly, in the case of web content filters, they can all be circumvented. They usually work by looking for HTTP responses whose content types are not safe, for example “application/octet-stream”. Here an example of a typical file download:
The initial request to retrive the page goes to a plain html file:
There is no simple solution for this problem. Content filters may be able to catch certain pages which use this functionality, but this would break other pages like Google Docs.
The issue was identified at a discussion at the Compass Offsite Meeting 2013 in Berlin. The Proof-of-Concept code (as seen above) has been implemented first by Cyrill Bannwart and works for current versions of Chrome, Firefox and IE10.
Where’s the code dude?
We will not release the code. It is quite trivial to find examples via google on stackoverflow.