Monday, September 9, 2013

Analysis: Fill a BlackHole

The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. The formatter threw an exception while trying to deserialize the message: Error in deserializing body of request message for operation 'Translate'. The maximum string content length quota (30720) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 32751.

Today, exploiting vulnerabilities in legitimate programs is one of the most popular methods of infecting computers. According to our data, user machines are most often attacked using exploits for Oracle Java vulnerabilities. Today’s security solutions, however, are capable of effectively withstanding drive-by attacks conducted with the help of exploit packs. In this article, we discuss how a computer can be infected using the BlackHole exploit kit and the relevant protection mechanisms that can be employed.


As a rule, instead of using a single exploit, attackers employ ready-made sets known as exploit packs. This helps them to significantly increase the effectiveness of ‘penetration’, since each attack can utilize one or more exploits for software vulnerabilities present on the computer being attacked.


Whereas in the past exploits and malicious programs downloaded with their help to victims’ computers were created by the same people, today this segment of the black market operates according to the SaaS (Software as a Service) model. As a result of the division of labor, each group of cybercriminals specializes in its own area: some create and sell exploit packs, others lure users to exploit start pages (drive traffic), still others write the malware that is distributed via drive-by attacks. Today, all a cybercriminal wishing to infect user machines with, say, a variant of the ZeuS Trojan needs to do is buy a ready-made exploit pack, set it up and get as many potential victims as possible to visit the start page (also called a landing page).


Attackers use several methods to redirect users to an exploit pack’s landing page. The most dangerous one for users is hacking pages of legitimate websites and injecting scripts or iframe elements into their code. In such cases, it is enough for a user to visit a familiar site for a drive-by attack to be launched and for an exploit pack to begin working surreptitiously. Cybercriminals can also use legitimate advertising systems, linking banners and teasers to malicious pages. Another method that is popular among cybercriminals is distributing links to the landing page in spam.

 
Infecting user machines using exploit packs: an overview diagram


There are numerous exploit packs available on the market: Nuclear Pack, Styx Pack, BlackHole, Sakura and others. In spite of the different names, all these ‘solutions’ work in the same way: each exploit pack includes a variety of exploits plus an administrator panel. Moreover, the operation of all exploit packs is based on what is essentially the same algorithm.


One of the best-known exploit packs on the market is called BlackHole. It includes exploits for vulnerabilities in Adobe Reader, Adobe Flash Player and Oracle Java. For maximum effect, exploits included in the pack are constantly modified. In early 2013, we studied three exploits for Oracle Java from the BlackHole pack, so we selected BlackHole to illustrate the operating principles of exploit packs.


It should be noted that all data on exploits, the contents of start pages and other specific information discussed in this article (particularly the names of methods and classes and the values of constants) was valid at the time the research was carried out. Cybercriminals are still actively developing BlackHole: they often modify the code of one exploit or another to hinder detection by anti-malware solutions. For example, they may change the decryption algorithm used by one of the exploits. As a result, some of the code may differ from that shown in the examples below; however, the underlying principles of operation will remain the same.


We print all changeable data in small type.


An exploit pack’s start page is used to determine input parameters and make decisions on the exploit pack’s further actions. Input parameters include the version of the operating system on the user machine, browser and plugin versions, system language etc. As a rule, the exploits to be employed in attacking a system are selected based on the input parameters. If the software required by the exploit pack is not present on the target computer, an attack does not take place. Another reason an attack may not take place is to prevent the exploit pack’s contents from falling into the hands of experts at anti-malware companies or other researchers. For example, cybercriminals may ‘blacklist’ IP addresses used by research companies (crawlers, robots, proxy servers), block exploits from launching on virtual machines, etc.

 
Screenshot of code from the BlackHole exploit kit’s start page


Even a brief look at the screenshot is sufficient to see that the JavaScript code is obfuscated and most information is encrypted.


Visiting the start page will result in execution of the code that was originally encrypted.


Algorithm for decrypting the JavaScript code that was in use in January 2013:

populate variables “z1 – zn” with encrypted data,then concatenate these variables into one string and decrypt the data as follows: every two characters (the character “-” is ignored) are considered to make up a 27-ary number, which is converted to decimal;add “57” to the value obtained and divide the result by 5;convert the resulting number back to a character using the function “fromCharCode”.

The code which performs these operations is marked with blue ovals on the screenshot above. The second array consists of decimal numbers from 0 to 255, which are converted to characters using the ASCII table. Both code fragments obtained by conversion are executed using the “eval” command (shown on the screenshot with red arrows).


The entire algorithm above could have been implemented with a few lines of code, but the cybercriminals used special techniques (marked with yellow ovals in the screenshot) to make detection more difficult:

deliberately causing an exception with the  “document.body*=document” command;checking the style of the first
element using the command “document.getElementsByTagName("d"+"iv")[0].style.left===""”; note that an empty
element is inserted for this purpose into the document (in the second line);calling “if(123)”, which makes no sense, since this expression is always true;breaking up function names and subsequently concatenating the parts.

In addition to the tricks described above, cybercriminals use numerous minor code changes that can hamper signature-based detection. Although our antivirus engine, for example, includes a script emulator and simple changes in constants and operations will not affect the effectiveness of detection, the tricks described above can make things more difficult for an emulator, too.


After decryption, code appears in RAM — we will refer to it as the “decrypted script”. It consists of two parts.


The first part is a module based on the free PluginDetect library, which can be used to determine the versions and capabilities of most modern browsers and their plugins. Cybercriminals use a variety of libraries, but this module is a key element of any exploit pack. BlackHole uses PluginDetect to select the appropriate exploits for download depending on the software installed on the user machine. By ‘appropriate’ we mean those exploits which have the highest chances of successfully running and launching malware on a specific PC.


The second part of the “decrypted script” is code responsible for processing the results produced by PluginDetect functions and then downloading the exploits selected and launching them.


In March 2013, BlackHole used exploits for the following vulnerabilities:

Java versions from 1.7 to 1.7.?.8 – CVE-2012-5076;Java versions below 1.6 or from 1.6 to 1.6.?.32 – CVE-2012-0507;Java versions from 1.7.?.8 to 1.7.?.10 – CVE-2013-0422;Adobe Reader versions below 8 – CVE-2008-2992;Adobe Reader version 8 or from 9 to 9.3 – CVE-2010-0188;Adobe Flash versions from 10 to 10.2.158 – CVE-2011-0559;Adobe Flash versions from 10.3.181.0 to 10.3.181.23 and below 10.3.181 – CVE-2011-2110.

Below we discuss exploits for Java vulnerabilities.


Information about this exploit became available on October 16, 2012, instantly making it enormously popular, because it was able to ‘break through’ Java Runtime Environment (JRE) up to version 7.7. Although a patch was released in the same month in which the exploit was discovered, the exploit was still included in the BlackHole pack in March 2013 because of its broad coverage of JRE versions and effectiveness.


The main steps of the exploit’s loading and operation are:

Pass parameters to the browser. The “code” parameter is used to pass the name of the starting Java class and the “” tag – to pass individual parameters for the Java applet being called (marked with red ovals on the screenshot below). It can be seen in the screenshot that the attackers replace printed characters with their decimal representations in the “&#xxxxx” format in order to make signature-based detection more difficult.Call the exploit. Once unpacked, the script calls the exploit in the usual way – using the
tag. 
Part of the script responsible for loading and launching the exploit for CVE-2012-5076

Process parameters. The Java exploit itself consists of three class files – in this example their names are “hw”, “test” and “test2”. Execution begins by calling method “init” of class file “hw”. The method puts together the parameters passed in the tag (marked with a red oval in the screenshot below) and passing them to method “ttt” of class “test2”. 
Starting function of Java exploit for CVE-2012-5076

Generate the code of a class file. Method “ttt” is used to convert an array of strings to a binary representation of the class.

In this case, all the strings are concatenated into one large string, then every two characters are converted to a hexadecimal number, from which “42” is subtracted, and then the remainder from the division of the resulting number by 256 is calculated.

The resulting data array is the class file’s binary code.

 
Code responsible for converting strings to a binary representation of the Java class

Exploit the vulnerability. Classes AnonymousClassLoader, GenericConstructor and ManagedObjectManagerFactory are manipulated in order to exploit vulnerability CVE-2012-5076 (the low-level mechanism used to exploit this vulnerability was well described by our colleagues from Microsoft). The “loadClass” method is then used to call the class file generated (see step 4), which is executed outside the JRE sandbox.Launch the payload. The class file downloads and launches an executable file, the path to which is passed to it from the unpacked script in a parameter. This process also takes place outside the sandbox and is therefore not blocked by Java security mechanisms. 
Decrypted Java class to be executed in memory

Note that the exploit’s code includes numerous tricks designed to evade static (signature-based) detection, such as dividing code into several classes, assigning meaningless values to variables, breaking up strings etc.

 
Code fragment from exploit for CVE-2012-5076

Vulnerability CVE-2012-0507 was closed with a patch distributed by Oracle back in February. Several weeks afterwards, an exploit taking advantage of this flaw was found in-the-wild, after which cybercriminals took to actively using it and adding it to various exploit packs. It affects Java versions below 1.6 and from 1.6 to 1.6.?.32.

Overall, this exploit’s algorithm is very similar to that of vulnerability CVE-2012-5076.

The exploit for CVE-2012-0507, like the one discussed above, is called using the tag.Its parameters are passed using tags.First, a vulnerability is exploited, enabling a class to be launched outside the JRE sandbox.The malicious class file is also generated in memory by converting strings. The algorithm for converting strings to a binary representation of the class is identical to that used in the exploit above – as are some of the function names.The class file generated is launched without any privilege restrictions and receives values from the unpacked script as parameters. 
Fragment of code launching a downloaded executable file

The key distinguishing feature of this exploit is that to exploit CVE-2012-0507, it is necessary to create a special array and then call method “AtomicReferenceArray”.

 
Code used to exploit the vulnerability is marked with a red oval

Cybercriminals began to exploit CVE-2013-0422 in December 2012. The vulnerability was discovered by security researchers in early 2013. After information about the vulnerability became publicly available, the exploit was included in most exploit packs. BlackHole was no exception.

The exploit for CVE-2013-0422 is based on an algorithm that is similar to the ones discussed above: first, a vulnerability is exploited, then a class file is launched outside the sandbox, downloading and launching a malicious payload – usually a backdoor or other Trojan.

The Java exploit for CVE-2013-0422 includes three class files: “hw.class”, “maker.class”, and “test.class”, where the code is obfuscated using techniques similar to those discussed above: meaningless assignment of string, integer and float variables, encryption, reversing, and breaking up string variables. The starting class file – “hw.class” – only checks input parameters passed via the decrypted JavaScript script of the landing page and calls a method of “maker.class” class file. The starting class file, “hw.class”, also includes a fragment of the string “FindVirtual” – “irtual”.

 
Code fragment from the starting class file “hw class” (obfuscation is marked with red, parameter names with orange)

In the “maker” class, the “maker” method performs the actual exploitation of the vulnerability using class “MBeanServer” and the “findConstructor” method of the “MethodHandles” class, which makes it possible to run the code of a previously generated class file without proper security checks, i.e., outside the sandbox.

Code in the class “maker” is heavily obfuscated – most strings are broken up and/or encrypted. An example of obfuscation is marked with a red oval in the figure below.

 
Code fragment from the class “maker”

Code in the class file that is to be called outside the sandbox is also broken up into pieces and represented as a string. The exploit’s code decrypts the data in memory and launches decrypted code after exploiting the vulnerability.

 
Fragment of encrypted binary data

As discussed above, three Java exploits are based essentially on the same mechanism: they obtain privileges and load the payload, which downloads and launches the target file. The three exploits also generate the same Java class file. This clearly indicates that the same person or people were behind the development of these three exploits. The only difference is the technique used to obtain unrestricted privileges for a class file.

The class file can download and launch files, decrypting parameters passed via the decrypted script. To make detection more difficult, the malicious file downloaded is usually encrypted and, consequently, does not start with a PE header. The file downloaded is usually decrypted in memory using the XOR algorithm.

Passing parameters via the decrypted script is a convenient way of quickly changing the links pointing to the payload: all this takes is to modify data on the exploit pack’s landing page without having to recompile the malicious Java applet.

The three vulnerabilities discussed above are so-called logical flaws. It is impossible to control exploits for such vulnerabilities using such automatic tools as those monitoring memory integrity or the generation of exceptions. This means that such exploits cannot be detected using Microsoft’s DEP or ALSR technologies or other similar automatic tools. However, there are technologies that can cope with this – an example is Kaspersky Lab’s Automatic Exploit Prevention (AEP).

In spite of all the efforts by cybercriminals, today’s security solutions can effectively block drive-by attacks conducted using exploit packs. As a rule, protection against exploits includes an integrated set of technologies that block such attacks at different stages.

Above, we provided a description of the BlackHole exploit kit’s operating principles. Now we will demonstrate, using Kaspersky Lab solutions as an example, how protection is provided at each stage of an attack using Java exploits from BlackHole. Since the way other exploit packs operate is similar to that implemented in BlackHole, the protection structure discussed here can be applied to them, as well.

 
Staged protection against a drive-by attack

Below we discuss which protection components interact with malicious code and when.

An attack starts as soon as the user reaches the exploit pack’s landing page. However, the security solution’s web antivirus component can block an attack even before it starts, i.e., before a script on the landing page is launched. This protection component verifies the address of the web page before it is opened. Essentially, this is a simple check of the page’s URL against a database of malicious links, but it can block the user from visiting the exploit pack’s landing page, provided that its address is already known to belong to a malicious resource.

This makes it essential for antivirus vendors to add malicious links to their databases as early as possible. Malicious URL databases can be located on user machines or in the cloud (i.e., on a remote server). In the latter case, cloud technologies help to minimize the time lag before a security product begins to block new malicious links. The ‘response time’ is reduced in this case because the security solution installed on the user machine receives information about a new threat as soon as the relevant record is added to the malicious links database, without having to wait for an antivirus database update.

Cybercriminals in turn try to change domains used to host exploit pack landing pages very often to prevent security software from blocking these pages. This ultimately reduces the profitability of their business.

If the user has after all reached an exploit pack’s landing page, this is where components of the file antivirus module – the static detector and the heuristic analyzer – come in. They scan the exploit pack’s landing page for malicious code. Below we analyze the operating principles, advantages and shortcomings of each component.

The static detector uses static signatures to detect malicious code. Such signatures are triggered only by specific code fragments, essentially by specific byte sequences. This is the threat detection method that was used in the early antivirus solutions and its advantages are well known. They include high performance and ease of storing signatures. All a detector needs to do to come up with a verdict is compare the checksum or byte sequence of the code being analyzed to the relevant records in the antivirus database. Signatures are tens of bytes in size and easily packed, making them easy to store. The most significant shortcoming of a static detector is the ease with which a signature can be ‘evaded’. All the cybercriminals have to do to make the detector stop detecting an object is change just one byte. This shortcoming leads to another one: a large number of signatures is needed to cover a large number of files, which means that the databases rapidly grow in size.The heuristic analyzer also uses databases, but works according to a completely different operating principle. It is based on analyzing objects: collecting and intelligently parsing object data, identifying patterns, computing statistics etc. If the data produced as a result of this analysis matches a heuristic signature, the object is detected as malicious. The main advantage of a heuristic signature is that it enables the solution to detect a large number of similar objects provided that the differences between them are not too great. The drawback is that compared to processing static signatures, the heuristic analyzer can be slower and affect system performance. For example, if a heuristic signature is not designed efficiently, i.e., if it requires a large number of operations to perform its checks, this may affect system performance on the machine on which the antivirus solution is running.

To prevent an object from being detected using a static signature, cybercriminals need to make minimal changes to the object’s code (script, executable program or file). This process can to some extent be automated.

To evade heuristic detection, a malware writer needs to conduct research to find out what mechanism is used to detect the object. When the algorithm has been fully or partially analyzed, changes preventing the heuristic signature from being triggered must be made to the malicious object’s code.

Clearly, ‘evading’ a heuristic signature inevitably takes cybercriminals longer than preventing detection using static signatures. This means that heuristic signatures have a longer ‘life span’. On the other hand, after malware writers have modified an object to evade heuristic detection, it also takes an antivirus vendor some time to create a different signature.

As discussed above, an anti-malware solution uses different sets of signatures to scan the landing page. In their turn, malware writers modify objects on the exploit pack’s start page in order to evade signature-based detection of both types. While it is sufficient to simply break strings up into characters to evade static signatures, evading heuristics requires making use of the finer features offered by JavaScript – unusual functions, comparisons, logical expressions, etc. An example of this type of obfuscation was provided in the first part of the article. It is at this stage that malware is often detected, particularly due to excessive code obfuscation that can be regarded as a characteristic feature of malicious objects.

In addition to databases stored on the computer’s hard drive, there are signatures located in the cloud. Such signatures are usually very simple, but the extremely short new-threat response time (up to five minutes from creating a signature to making it available in the cloud) means that user machines are well protected.

If the security solution fails to recognize the start page of the exploit pack, the latter comes into operation. It checks which browser plugins are installed (Adobe Flash Player, Adobe Reader, Oracle Java, etc.) and makes a decision as to which exploits will be downloaded and launched. The security solution will scan each exploit being downloaded in the same way as it did the exploit pack’s landing page – using the file antivirus module and cloud-based signatures. The attackers in their turn try to evade detection using certain techniques, which are similar to those described above.

If none of the components responsible for reactive (signature-based) protection has detected anything suspicious while scanning the exploit pack’s contents and an exploit has launched, this is where proactive protection modules come in. They monitor the behavior of applications in the system in real time and identify any malicious activity.

Each application is categorized, based on information provided by heuristic analysis, data from the cloud and other criteria, as “Trusted”, “Low Restricted”, “High Restricted” or “Untrusted”. Application Control restricts each application’s activity based on its category. Applications in the Trusted class are allowed all types of activity, those in the Low Restricted group are denied access to such resources as password storage, programs in the High Restricted category are not allowed to make changes to system folders, etc. All the applications being launched and all those running are analyzed by a module called Application Control in Kaspersky Lab products. This component monitors program execution in the system using low-level hooks.

In addition to the above, so-called behavior stream signatures (BSS) describing malicious activity are used to detect the dangerous behavior of applications. Such signatures are developed by virus analysts and are subsequently compared to the behavior of active applications. This enables proactive protection to detect new malware versions that were not included in the Untrusted or High Restricted categories. It should be noted that this type of detection is the most effective, since it is based on analyzing data on applications’ actual current activity rather than static or heuristic analysis. It renders such techniques as code obfuscation and encryption completely ineffective, because they in no way affect the behavior of a malicious program.

For more stringent control of applications to prevent their vulnerabilities from being exploited, we use a technology called Automatic Exploit Prevention (AEP). The AEP component monitors each process as it is launched in the system. Specifically, it checks the call stack for anomalies, checks the code which launched each process, etc. In addition, it performs selective checks of dynamic libraries loaded into processes.

All this prevents malicious processes from being launched as a result of exploiting vulnerabilities. This is in fact the last line of defense, providing protection against exploits in the event that other protection components have failed. If an application, such as Oracle Java or Adobe Reader, behaves suspiciously as a result of exploitation, the vulnerable legitimate application will be blocked by the anti-malware solution, preventing the exploit from doing harm.

Since protection at this stage is based on the program’s behavior, cybercriminals have to use sophisticated and labor-intensive techniques to evade proactive protection.

If an exploit does go undetected, it attempts to download the payload and run it on the user machine.

As we wrote above, the malicious file is usually encrypted to make detection more difficult, which means that it does not begin with a PE header. The file downloaded is usually decrypted in memory using the XOR algorithm. Then the file is either launched from memory (usually, this is a dynamic library) or dropped on the hard drive and then launched from the hard drive.

The trick of downloading an encrypted PE file enables the malware to fool antivirus solutions, because such downloads look like ordinary data streams. However, it is essential that the exploit launches a decrypted executable file on the user machine. And an anti-malware solution will subject that file to all the various protection technologies discussed above.

Exploit packs are an integrated system for attacking victim machines. Cybercriminals devote a lot of time and effort to maintain the effectiveness of exploit packs and minimize detections. In their turn, anti-malware companies are continually improving their security solutions. Anti-malware vendors now have a range of technologies that can block drive-by attacks at all stages, including those involving exploitation of vulnerabilities. 
Posted by at
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts