As you may know, the “Aurora” exploit used in the attack over Google went public. We won’t go into the details of this situation, as it is well covered in the Reference section bellow.
Certain Windows machines running Internet Explorer are at risk, for the affected systems lists please see Microsoft Security Advisory (979352). Currently there is no patch available for this vulnerability.
I wrote this blog entry as is interesting to see if the enhancements introduced by Microsoft with Forefront TMG 2010 can help mitigate against the risks that may appear now when the “Aurora” exploit is publicly available.
To quickly summarize it, we have potential web-based threats against users or businesses due to MS Advisory 979352 while there is no patch available for this vulnerability. This situation is not surprising at all, given that web-based threats against users or businesses are on the rise for quite a while.
There are three new layers of protection natively available with Forefront TMG 2010 compared to ISA Server 2006(layers that may prove useful in such a situation):
- an indirect one, offered by the URL filtering solution. This can help by possibly stopping the user visiting suspect links by blocking “bad destinations” or whitelisting allowed destinations to the minimum necessary. Note that apparently legitimate web sites can be involved in malware distribution(if they become compromised). TMG uses a cloud-based URL filtering technology.
- a direct one, offered by the Malware Inspection. The publicly available exploits, depending on some aspects, were detected by Microsoft’s antivirus engine as Exploit:JS/Elecom.B(Published: Jan 12, 2010), as Trojan:Win32/Swrort.A(Published: Jan 12, 2010) and as Exploit:JS/ShellCode.gen(Updated: Sep 09, 2008, Published: Sep 09, 2008). The later signature is for "detecting JavaScript-enabled objects that exhibit suspicious behavior", and if the dates are correct, apparently Forefront TMG 2010 could detect and block some attacks attempting to exploit the MS Advisory 979352 vulnerability before this vulnerability became known(against a “true” 0-day)-pure speculation, as can be many variables involved-. The signatures version on my test Forefront TMG 2010 machine were 1.71.2310.0. The success of the Malware Inspection is up to the inspection engines and the way the exploit will be written/used(it may be possible for an attacker to bypass the inspection engines with the "help" of the HTTP protocol or by obfuscating the code).
- a direct one offered by NIS(IPS). Currently I do not see any specific signature for this vulnerability. There is a signature, Expl:Win/Browser.Shellcode.RCE!0000-0000, that "detects commonly used exploitation techniques for browser based vulnerabilities" which is of no use in this case(against the currently available exploit public code). Thus protection offered by NIS is none for MS Advisory 979352 as writing. Normally the NIS offers intrusion prevention and detection for exploits against Microsoft products. NIS was implemented based on GAPA(Generic Application-level Protocol Analyzer) research. The signatures version on my test Forefront TMG 2010 machine were 4.17.0.0.
Basically we have available for assessing the protection offered by Forefront TMG 2010 for MS Advisory 979352:
- the exploit code publicly available.
- the Metasploit ie_aurora.rb module.
Bellow we won’t attempt to bypass the inspection engines on TMG. We will use the exploits just the way they are.
If we upload to VirusTotal the exploit code publicly available, we can note that only a few antivirus engines currently detect it, Microsoft’s antivirus engine being one of them detecting this exploit code as Exploit:JS/Elecom.B:
So, if we put this file on a test web server and attempt to access it from a host behind TMG, TMG’s Malware Inspection will detect the threat as Exploit:JS/Elecom.B and it will clean the file:
Clean means that it removed the script from the file(note that the browser will still attempt to get that ‘.gif’ file, but this should not do any harm now):
TMG cleans the file due to the Attempt to clean infected files setting, which is enabled by default:
If you’ve disabled the Attempt to clean infected files setting, the attempt to access the malicious web page would be blocked, as a Severe threat was detected(Severe threats are blocked by default):
If we use the Metasploit ie_aurora.rb module for testing(no obfuscation was enabled on Metasploit), things change, as the Malware Inspection does not identify the exploit by a specific signature, and a generic signature, Exploit:JS/ShellCode.gen, kicks in(this will happen if you had left enabled the Block suspicious files setting on the Malware Inspection configuration, this setting is enabled by default) and again the file is cleaned:
If you had disabled the Block suspicious files setting on the Malware Inspection configuration, another signature, Trojan:Win32/Swrort.A, will block the exploit:
References:
- http://en.wikipedia.org/wiki/Web_threat
- http://praetorianprefect.com/archives/2010/01/the-aurora-ie-exploit-in-action/
- http://siblog.mcafee.com/cto/“aurora”-exploit-in-google-attack-now-public/
- http://blog.metasploit.com/2010/01/reproducing-aurora-ie-exploit.html
- http://www.avertlabs.com/research/blog/index.php/2010/01/14/more-details-on-operation-aurora/
- http://www.microsoft.com/technet/security/advisory/979352.mspx
- Exploit:JS/Elecom.B
- Trojan:Win32/Swrort.A
- Exploit:JS/ShellCode.gen
- Expl:Win/Browser.Shellcode.RCE!0000-0000