Please note that republishing this article in full or in part is only allowed under the conditions described here.
This article describes several ways of employing uncommon or invalid HTTP responses to transport malware from server to client without being detected by Sophos UTM Web Protection. All of these bypasses got reported to Sophos and most of them are fixed by now.
Sophos UTM is a firewall with deep inspection capabilities, i.e. not a simple packet filter. Formerly called IPS or Secure Gateway these class of firewalls are now mostly advertised as Unified Threat Managment (UTM) or Next Generation Firewall (NGFW).
According to their product page Sophos sees its UTM and Next-Gen Firewall as "The Ultimate Security Package" and sees itself as an "Industry leader" because of reports of Gartner and "Sophos SG Series was named Best UTM Solution at the SC Awards 2015.".
Web traffic is handled by Sophos UTM at the application layer by a proxy which allows deeper inspection and also modification of the content.
From the product description of Sophos UTM Web Protection:
Unfortunately, in order to inspect the web code their engine must get reliable access to the content first. And while the trivial bypass by simply using the deflate compresssion was fixed in 12/2014 a closer look revealed more bypass vectors.
The first bypass was possible by using multiple compressions at the same time. This is the same attack I've already published in 07/2013 where I reported bypasses for several IDS and virustotal.com. And while Sophos UTM could not be bypassed if the first encoding was gzip, it could be bypassed when the first encoding was deflate like in
Content-encoding: deflate Content-encoding: gzip ...content first compressed with deflate and then with gzip
The issue was reported to Sophos on 2015/05/03 and was fixed with version 9.314-13
on 2015/07/31. Affected are all browsers which support multiple compressions, that is all modern browsers except Internet Explorer. From the announcement:
34907 HTTP Proxy: deflate zlib data according to RFC
Unfortunately this short description does not tell the impact of the problem, i.e. the full bypass of protection. Nor does Sophos acknowledge that this bug report came from an external researcher (me).
The Content-length is used to give the size of the content. By using a weird value for the Content-length together with line-folding another bypass was possible. To bypass the firewall with the EICAR test virus (68 byte) the following response could be used:
HTTP/1.0 200 ok Content-length: 68 34 Content-type: application/octet-stream X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Different variations of this bypass were possible.
The issue was reported to Sophos on 2015/05/13 and was fixed with version 9.314-13 on 2015/07/31. All modern browsers are affected. I did not find any issue in the change log pointing to this exact problem, but from the communicaton with Sophos I know that there was some code cleanup which probably fixed this issue too.
Browsers are way too tolerant when parsing HTTP. It looks like that in case of specifically broken responses Sophos UTM does not inspect the content but instead simply passes the broken response to the client. Such broken response headers might contain plain invalid header lines, fields which are not ASCII-only or simple HTTP/0.9 responses which do not contain any headers. Example:
HTTP/1.1 200 ok : Content-length: 68 Content-type: application/octet-stream X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Or simply giving the HTTP version in lower case worked too:
http/1.1 200 ok Content-length: 68 Content-type: application/octet-stream X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
All modern browsers are affected by this issue. It was reported to Sophos on 2015/06/25 and was partly fixed with version 9.314-13 on 2015/07/31. But, this fix needs to be explicitly enabled by activating the option "Block unscannable and encrypted files" because Sophos seems to fear that customers run into compatibility issues with broken web sites. They are probably right in that customers will notice if a web site gets broken by the firewall but will not notice if a malicious website simply bypasses the firewall. Too bad a firewall should protect against the latter one :(
There is no specific issue in the change log about the bug and it's impact and that it is not fixed in the default settings. Also, the issue is only partly fixed since some bypasses still work (for more information try my test tool described below).
Even though Sophos did not publically acknowdledge me for the bug reports and even though they did not manage to fix everything I still like to thank them for their courage to offer a version of their UTM for home use and that they are open for bug reports from outside.
And while these kind of bypasses can be trivially executed by an attacker one should be aware that firewalls from other vendors are not necessarily better in protecting the client. I'm currently investigating reports that some highly praised Next Generation Firewalls by other vendors can be bypassed with similar techniques.
Thus if you are behind a firewall and are not yet fully lulled into the advertisements of your vendor you might want to check out by yourself how resistent your firewall is against these kind of attacks. This check might be as simple as pointing you browser to my test site and run the "Bulk test firewall evasion with EICAR test virus" there. This test tries to download the harmless EICAR test virus which should be detected by every virus scanner. But even though no harm will be done to your computer by running these tests some firewall vendors still consider this test site malicious, maybe because it shows that their own products can be bypassed. In this case you might set up your own server by using the publically available code.
Information about other kinds of bypasses at the application level can be found at my page about employing the semantic gap for bypasses.