Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:


  • Recent Posts

  • Calendar

    April 2015
    S M T W T F S
    « Mar    
     1234
    567891011
    12131415161718
    19202122232425
    2627282930  
  • Email Subscription

  • About Us


    Author Archive - Peter Pi (Threats Analyst)




    We have found an interesting discrepancy in how the Angler exploit kit targets Adobe Flash.

    The Angler exploit kit is known for its use of various Adobe Flash Player exploits. Reports have indicated that Angler has started targeting CVE-2015-0359, a vulnerability that was fixed in Adobe’s April 2015 update. CVE-2015-0359 is a race condition vulnerability that occurs because ByteArray::Write is not thread-safe, and it requires many workers to trigger. However, in the sample that we analyzed, the current exploit used by Angler is a use-after-free (UAF) vulnerability related to domainMemory and is easier to trigger, opening the possibility that an already known and patched vulnerability is being exploited.

    Execution Flow

    Instead of CVE-2015-0359, the execution flow of the Flash exploit that we saw is very similar to that used by CVE-2015-0313:

    1. shareable ByteArray object is set to be shared between the main thread and worker thread by calling setSharedProperty.
    2. Set this shareable ByteArray object memory to domainMemory.
    3. A worker thread gets the shareable ByteArray object through worker shared property by calling getSharedProperty, and the execution flow is dependent on the Flash player version. If the version of Flash present is vulnerable to CVE-2015-0313 vulnerability, it then calls ByteArray::Clear; if not, it calls ByteArray::WriteBytes

    Figure 1. Difference between this sample and CVE-2015-0313

    The difference between this new exploit and CVE-2015-0313 is that it will call ByteArray::WriteBytes to cause the underlying buffer change, and this change is not notified to domainMemory (which will still point to the freed memory). This will cause a UAF vulnerability. An attacker can use intrinsic instructions to read and write from the freed memory address. In effect, it is the same kind of flaw as CVE-2015-0313, except a different function is called to trigger it.

    Conclusion

    It is not clear why it is thought that the newer exploit used by Angler targets CVE-2015-0359. Perhaps it may have been a happy coincidence that the fix for CVE-2015-0359 also fixed this UAF vulnerability; given that the race condition vulnerability does use the ByteArray::WriteBytes function as well that is a distinct possibility.

    We are working with Adobe to clarify the scope of this vulnerability.

    Additional analysis by Brooks Li and Joseph C. Chen

    Related SHA1 of the Flash sample is as follows:

    • E0C46A5BF1F98C0BF5F831E7AD1881502809DA93
     
    Posted in Exploits, Vulnerabilities |



    We have detected through feedback from the Trend Micro™ Smart Protection Network™ that the Nuclear Exploit Kit has been updated to include the recently fixed Adobe Flash Player vulnerability identified as CVE-2015-0336. We first saw signs of this malicious activity on March 18 this year.

    This particular vulnerability was only recently fixed as part of Adobe’s regular March update for Adobe Flash Player which upgraded the software to version 17.0.0.134. However, our feedback indicates that many users are still running the previous version (16.0.0.305). (We recommend that users stay up-to-date with the latest Flash Player version, and this incident is an excellent reminder of why.) We noted earlier this month that Flash Player was being targeted more frequently by exploit kits, and that pattern shows no sign of changing soon.

    This exploit, detected as SWF_EXPLOIT.OJF, is being distributed to users via compromised websites, including one for an Internet Explorer repair tool and various Japanese pornographic sites. Users are directed to landing page located at hxxp://_ibalinkmedia[.]com/S0ldSAZRTlpQVV8MXFhfUVcMUx1RW14.html; this loads the Flash exploit located at hxxp://_ibalinkmedia[.]com/V0tCSEofXU8HAE9UCgBOXVEEXlpcX14AVlpTGlAKX08ABgNLBwAcAA

    BLAQJOBQdXBAQDBgNWA09UWAE.

    We believe that this is the Nuclear Exploit Kit for two reasons: first, the style of the URLs listed above is consistent with previous Nuclear attacks. Secondly, the content of the landing page is also consistent with the Nuclear Exploit Kit:

    Figure 1. HTML code of landing page

    Our feedback information shows that more than 8,700 users have visited the above URLs. More than 90% of these victims are from Japan.

    Figure 2. Distribution of would-be victims by country

    Trend Micro is already able to protect users against this threat. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior without any engine or pattern updates.  The Browser Exploit Prevention feature in our endpoint products such as Trend Micro™ SecurityOfficeScan, and Worry-Free Business Security blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention protects against exploits that target browsers or related plugins.

    The SHA1 of the malicious Adobe Flash exploit is:

    • d2bbb2b0075e81bfd0377b6cf3805f32b61a922e
     
    Posted in Bad Sites, Exploits, Malware |



    Adobe has started rolling out an update to Flash Player which fixes the zero-day vulnerability we discussed earlier this week. This particular vulnerability can be exploited via all major browsers (Internet Explorer, Firefox, and Chrome); however Chrome users are protected by that browser’s sandbox for its Flash plugin, protecting end users from any attacks. The patch brings the newest version of Flash Player to 16.0.0.305.

    This particular vulnerability is a use-after-free vulnerability. Like CVE-2015-0311, the memory referenced by domainMemory was freed before it was used.  Other portions of the exploit are similar to CVE-2015-0311, such as the obfuscation, ROP techniques, and shellcode. After analysis of the exploit kit pages (we would like to thank Kafeine for working with us on this analysis), we’ve found that it is possible that this exploit was first used by the Hanjuan exploit kit.

    Despite these similarities, however, there are some differences between the earlier zero-day and this one.

    Background: ActionScript workers

    Before we can analyze this vulnerability’s root cause, we need to introduce some concepts about Flash and its scripting language, ActionScript.

    ActionScript 3.0 uses the Worker object to help developers implement high performance applications. Objects can be shared between different workers, as explained in the ActionScript 3.0 Developer’s Guide.

    The most important thing to understand is that workers share the underlying memory of a shareable ByteArray object. No new memory will be allocated when calling worker.setSharedProperty on a shareable ByteArray object. Changes by one worker on the shareable ByteArray object memory content will be seen by other workers.

    Root cause analysis

    The exploit code we acquired uses a worker object. There are communications between the main execution thread and the worker using a shared property and MessageChannel. MessageChannel is used to synchronize the main thread and the worker thread; the shared property is used to actually trigger the vulnerability.

    The vulnerability’s trigger flow can be simplified as following 3 steps.

    1. [Main Thread] A shareable ByteArray object is set to be shared between the main thread and worker thread by calling setSharedProperty.
    2. [Main Thread] Set this shareable ByteArray object memory to domainMemory.
    3. [Worker Thread] Worker thread gets the shareable ByteArray object through worker shared property by calling getSharedProperty, and then clears the memory by calling ByteArray::Clear.

    Why does domainMemory reference the freed memory?

    In step 3, the worker thread clears the memory of the shareable ByteArray by calling ByteArray::Clear. It is this action that triggers the bug.

    My debugging found that before the memory is cleared in the worker thread, the underlying buffer is referenced by the shareable ByteArray object and domainMemory. The ByteArray::Clear function will free the underlying buffer and set the pointer to NULL, but it does not notify domainMemory to change the memory reference. This is a logic bug, which is not present in other functions.

    Some functions, such as ByteArray::Length, will notify domainMemory to change the memory reference if they are called in a worker thread. Other functions, such as ByteArray::Compress and ByteArray::Uncompress, will throw an ArgumentError when called on a shareable ByteArray which is referenced by domainMemory within a worker thread.

    The following pictures show the differences before and after calling ByteArray::Clear:

    Figure 1. Memory references before clear function call

    Figure 2. Memory references after clear function call

    ROP and Shellcode

    This vulnerability’s ROP and shellcode are similar to those used by CVE-2015-0311. The ROP gadgets used are in the following picture:

    Figure 3. ROP gadgets

    The functions used by the shellcode are in the following picture. It uses winhttp functions to download the actual malware payload.

    Figure 4. Shellcode function call

    Figure 5. Payload downloaded (click to enlarge)

    We advise users to update their versions of Flash as soon as possible, if they haven’t already.

    Trend Micro products have been protecting users from this attack from the beginning through different technologies.

    The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can also be used to detect this threat by its behavior without any engine or pattern update. The Browser Exploit Prevention feature in our endpoint products such as Trend Micro™ SecurityOfficeScan, and Worry-Free Business Security blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention also protects against exploits that target browsers or related plugins.

    Trend Micro™ Deep SecurityVulnerability Protection (formerly the Defense Firewall plug-in for OfficeScan) and Deep Discovery customers with the latest rules also have an additional layer of protection against this vulnerability. Specifically, Trend Micro releases the following rules and patterns:

    • Deep Security rule DSRU15-004
    • Deep Packet Inspection (DPI) rule 1006468 for Deep Security and Vulnerability Protection (formerly the IDF plug-in for OfficeScan)

    More information about Trend Micro solutions for this threat are available in our support portal.

    Update as of February 4, 2015 12:55 A.M. (PST) – The entry has been edited to expound on the Trend Micro solutions for this threat.

     
    Posted in Exploits, Vulnerabilities |



    Our researchers have discovered a new zero-day exploit in Adobe Flash used in malvertisement attacks. The exploit affects the most recent version of Adobe Flash, and is now identified as CVE-2015-0313. Our initial analysis suggests that this might have been executed through the use of the Angler Exploit Kit, due to similarities in obfuscation techniques and infection chains.

    According to our data, visitors of the popular site dailymotion.com were redirected to a series of sites that eventually led to the URL hxxp://www.retilio.com/skillt.swf, where the exploit itself was hosted. It is important to note that infection happens automatically, since advertisements are designed to load once a user visits a site. It is likely that this was not limited to the Dailymotion website alone, since the infection was triggered from the advertising platform and not the website content itself. Trend Micro detects this exploit as SWF_EXPLOIT.MJST and blocks the URL mentioned above. The ads from this particular infection chain appear to be down as of this writing.

    We have been monitoring this attack since January 14, and saw a spike in the hits to the IP related to the malicious URL around January 27. According to data from the Trend Micro™ Smart Protection Network™, most of the users who accessed the malicious server related to the attack are from the United States.

    numberofhits_adobezeroday

    Figure 1. Number of accessed counts to one of  the affected IP addresses

    This post serves to warn end-users and enterprises of the severity of this threat. So far we’ve seen around 3,294 hits related to the exploit, and with an attack already seen in the wild, it’s likely there are other attacks leveraging this zero-day, posing a great risk of system compromise to unprotected systems. Since the exploit affects the latest version of Flash, 16.0.0.296, users may consider disabling Flash Player until a fixed version is released. Adobe has confirmed that this is a zero-day exploit and the patch is expected to be available this week to address this. More details can be found in this advisory Adobe released for this vulnerability.

    The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can also be used to detect this threat by its behavior without any engine or pattern update. The Browser Exploit Prevention feature in our endpoint products such as Trend Micro™ SecurityOfficeScan, and Worry-Free Business Security blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention also protects against exploits that target browsers or related plugins.

    This is only the latest of the zero-day vulnerabilities found in Adobe Flash this month. Just weeks ago, we wrote a couple of blog entries (Flash Greets 2015 With New Zero-DayAnalyzing CVE-2015-0311: Flash Zero Day Vulnerability) pertaining to zero-day vulnerabilities found in Adobe Flash Player and covered under CVE-2015-0311.

    This is a developing story and we will continue to update this entry as new information and development about this threat surfaces. We will also share the technical analysis once the Adobe Flash update is released.

    With additional analysis from Joseph C. Chen

    Update as of February 2, 2015, 8:07 AM PST

    Trend Micro™ Deep Security and Vulnerability Protection (formerly the Defense Firewall plug-in for OfficeScan) protects user systems from threats that may leverage this zero-day vulnerability following the DPI rule:

    • 1006468 – Adobe Flash Player Unspecified Vulnerability (CVE-2015-0313)

    Update as of February 3, 2015, 11:49 AM PST

    We have updated information on the exploit kit used in this attack. We now believe it is not Angler, but the Hanjuan Exploit Kit. More details in our blog entry A Closer Look at the Exploit Kit in CVE-2015-0313 Attack.

     



    Last week a major zero-day vulnerability was found in Adobe Flash Player. Over the weekend, Adobe released an update to fix the vulnerability: users who have enabled auto-update already received the newest version (16.0.0.296). Our analysis has confirmed that the vulnerable code has been modified.

    The update will be available for manual download later this week. Users of Chrome and newer versions of Internet Explorer will receive updates for their included versions of Flash Player at around the same time.

    Looking into the samples we acquired, we found that the actual Flash file was embedded within the malicious .SWF file. In addition, the actual file was heavily obfuscated.

    Once we removed the obfuscation, we were able to analyze the vulnerability in full and find out how the exploit works. Before going into the details, we will point out one curious little fact: some of the code fragments are similar to exploits targeting CVE-2014-8439. It is possible that the same person is responsible for both exploits.

    Vulnerability Root Cause

    Our analysis found that this is a use-after-free (UAF) type of vulnerability. In this case, the memory referenced by domainMemory is freed. This vulnerability can be used to read and write into memory, and an attacker can use this ability to run arbitrary code.

    This vulnerability is triggered by the following steps:

    1. Create a new ByteArray, and write lots of data to it, then compress the contents.

      Figure 1. ByteArray creation code

    2. Overwrite the ByteArray compressed data from position 0x200 and set ByteArray to domainMemory.

      Figure 2. Overwriting ByteArray

    3. Uncompress the ByteArray data. Because of the actions in the previous step, this will result in an IOError exception. The code catches the exception, then uses another ByteArray to hold the freed memory’s place, this ByteArray is buffered with 0xBBBBBBBB.

      Figure 3. IOError and catching the exception

    4. Clear the place holder data in ByteArray.

      Figure 4. Freeing the 0xBBBBBBBB ByteArray memory

    Why Does domainMemory Still Reference The Uncompressed Data Buffer?

    In the AvmPlus project code, we found that the bug is in the ByteArray::UncompressViaZlibVariant function. The function is designed this way: it will allocate a new buffer for storing the uncompressed data first. If the decompression is successful, it will notify domainMemory to use the new buffer. If the decompression fails, it will not notify domainMemory to use the new buffer, and instead, it will free the newly created buffer.

    This seems correct, but in the decompression process, the allocation for the new buffer will grow bigger. The class Grower will handle the buffer’s dynamic growth. After this growth is complete, the destruction of class Grower will notify domainMemory to use the expanded buffer. What we end up with is domainMemory using the new buffer during the decompression process. If this fails, the newly created buffer is freed. This breaks the original logic of ByteArray::UncompressViaZlibVariant: even if the decompression fails, domainMemory uses the new buffer.

    This is why after performing the above steps, domainMemory now points to a freed memory space filled with 0xBBBBBBBB, the exploit can now use intrinsic instructions to read and write the freed memory space.

    Figure 5. Reading the freed memory space

    Like most recent Adobe Flash exploits, the exploit code controls the memory layout and put vectors beside the freed memory. This allows the vector length to be overwritten, which allows the attacker to arbitrarily read and write into the memory.

    Figure 6. Overwriting memory

    We can see the memory layout changing during uncompression, up to the vector length being overwritten in the following pictures. The use-after-free memory address is 0x05120000 in my debug environment.

    Figure 7. The memory layout after uncompressing (the header data is successfully uncompressed)

    Figure 8. The memory layout after allocated the 0xBBBBBBBB ByteArray

    Figure 9. The memory lay out after freed the 0xBBBBBBBB ByteArray and sprayed Vectors

    Figure 10. The memory layout after overwrite vector length

    After the vector length has been overwritten to 0x40000000, the sample code can now read and write into arbitrary memory; this capability can be used by exploits to run arbitrary code. The exploit just triggers a fake virtual function call to execute shellcode.

    Trend Micro Solutions

    Trend Micro’s dynamic script emulation technology is able to successfully analyze even heavily obfuscated Flash files. This allows us to extract embedded .SWF files and monitor the vector heap spray behavior. As a result, we are able to provide a more complete analysis of exploits and provide complete protection to our users in a relatively short period of time.

    Our initial post contains details on our available solutions for this threat.

     


     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice