Sophos Cloud Optix
A technical paper by Fraser Howard, SophosLabs, UK
2.3.3 Exploit components
The landing page will load files that target the exploits relevant to the victim’s machine (based on the information determined from fingerprinting). The following file types are used by Blackhole:
The PDFs used are typical for what we expect from any exploit kit. They contain embedded JavaScript that is used to exploit the underlying client vulnerabilities. Some example URLs used to load recent PDF components are shown below.
[removed]/content/ap1.php?f=b6863 (type 1)
[removed]/content/ap2.php?f=b6863 (type 2)
[removed]/content/fdp2.php?f=50 (type 2)
Two PDFs (types 1 and 2) are typically loaded by Blackhole in order to target the relevant exploits included in Table 1. The deobfuscated JavaScript from within these PDFs is shown in Appendices 2 (‘type 1’) and 3 (‘type 2’).
Flash
Two Flash files are loaded, from URLs such as those listed below:
[removed]/content/field.swf (type 1)
[removed]/content/score.swf (type 2)
The disassembled ActionScript from a ‘type 1’ sample is shown in Appendix 4. Note the use of the Adobe ExternalInterface class, to allow ActionScript to call some of the JavaScript functions listed in Appendix 1. The ExternalInterface class is an API that enables communication between ActionScript and the container, in this case the exploit kit landing page.
The function of the first (‘type 1’) Flash file is to prepare (spray) the heap (using the relevant JavaScript functions), and load the second (‘type 2’) sample. The JavaScript getCN() function (see Appendix 1) is called in order to load the second Flash sample. It is the second sample that actually exploits the system once loaded (CVE-2011-0611). The second sample contains another Flash file embedded as a hex string. As you can see from the partial disassembly in Appendix 5, the hex string is deobfuscated and loaded using the loadBytes() method.
Java
Blackhole is one of the reasons behind the press interest in Java vulnerabilities recently. Anecdotal evidence* collected during the past year indicates that it is predominantly the Java vulnerabilities that lead to users getting infected by Blackhole. The Java content is loaded via JAR files, from URLs such as that listed below:
[removed]/content/field.jar
Interestingly Blackhole uses the Java Open Business Engine (Java OBE) to load the CVE-2010-0842 exploit code and infect the victim.
As noted in Appendix 1, the JAR content may be loaded via either JavaScript or an applet element in the landing page. The URL to the executable payload is typically passed via an applet parameter, as in Figure 6.
Figure 6: An applet HTML element used to load malicious Java content. Note the obfuscated URL passed in via the applet parameter.
One of the class files within the JAR archive decodes the URL parameter in order for the executable payload to be downloaded. Figure 7 illustrates the Java code used to do this.
Figure 7: Snippet of Java code responsible for decoding the obfuscated URL included as a parameter in the applet element of Figure 6.
As you can see, deobfuscation requires two additional strings initialized in the malicious class file. For this example, the applet parameter decodes to the path of the executable payload:
hxxp://[removed]/w.php?f=19&e=1
The exact same trick of passing the obfuscated payload URL via the applet parameter is not unique to Blackhole. Recently we have seen the trick used by an exploit kit known as Jupiter (Figure 8).
Figure 8: Extract from the Jupiter landing page, illustrating the same obfuscated URL trick that Blackhole uses (Figure 7).
See Section 3.4 for some examples of how Blackhole aggressively modifies and obfuscates the applet element in order to evade detection. Recent flavours of the landing pages also use additional data prepended to the start of the obfuscated URL string!
HTML/JS/VBS
Blackhole also targets the much publicized vulnerability in Microsoft Help and Support Center, (CVE-2010-1885). The kit adds an iframe to load content from a malformed hcp:// URL, in order to run a script that writes out a VBS.
Figure 9: Snippet of code used in exploiting CVE-2010-1885
The VBS attempts to download further content from hcp_vbs.php (CVE-2006-0003) or hcp_asx.php.
* Through private communications with individuals from several organisations