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


  • Recent Posts

  • Calendar

    July 2015
    S M T W T F S
    « Jun    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Email Subscription

  • About Us


    Author Archive - Peter Pi (Threats Analyst)




    Earlier we talked about the out-of-band update for Flash Player that was released by Adobe (identified as APSB15-14) that was released to fix CVE-2015-3113. This update raised the Flash Player version to 18.0.0.194.

    Our analysis of the current flaw reveals that the root cause of CVE-2015-3113 is similar to CVE-2015-3043. Both cause a buffer overflow within the Flash Player code. In fact, code targeting the previous exploit can also cause crashes in version 18.0.0.160 (the version immediately before this emergency update).

    Both vulnerabilities can be used to run arbitrary code (i.e., malware) on user systems if they visit a site with a malicious Flash file. Users who visit a malicious or compromised site containing malicious Flash files that still use older, unpatched versions of Flash Player are at risk.

    Vulnerability comparisons

    Both CVE-2015-3113 and CVE-2015-3043 are heap overflow vulnerabilities in the FLV audio parsing flow. They are both in how Flash Player processes audio with the Nellymoser codec; they can be triggered by modifying the FLV file’s audio tag. They both overflow a hardcoded length heap buffer with a length of 0x2000.

    CVE-2015-3043 and CVE-2015-3113 both trigger this bug using sample_count * sample_size > 0x2000, and bypass the length check.

    Old Patch for CVE-2015-3043

    CVE-2015-3043 was originally patched in 17.0.0.169. This was done by limiting the sample count acquired from the FLV audio tag.

    Figure 1. Original patch

    We can see that the sample count is limited to 0x400. We can compute the biggest buffer size needed from this: FLV specifies a size of 4 as the biggest size per sample. The Nellymoser codec has a hardcoded multiple size of 2 (as seen in the code below). Therefore, the biggest buffer needed is 0x400 * 4 *2 = 0x2000.

    Figure 2. Nellymoser doubling

    New Patch in 18.0.0.160

    However, the code underwent significant changes in 18.0.0.160. The code now looks like this:

    Figure 3. New patch

    The GetSampleCount function checks the final buffer size needed. If the final buffer size is larger than 0x2000, it will limit it to 0x2000. However, this ignores the Nellymoser decode function’s hardcoded double operation; this can be used to trigger a heap buffer overflow once again.

    Conclusion

    The analysis above shows that both the previous Flash zero-day and the current incident share the same underlying root cause. In fact, code targeting the previous zero-day will cause 18.0.0.160 to crash.

    This incident highlights how important careful development of patches is, to prevent patched bugs from being re-exploited at a later time. Regression testing must also be a part of software development in order to check that old bugs do not threaten new versions of software.

    Update as of June 24, 2015, 8:08 A.M. (PDT):

    Trend Micro Deep Security and Vulnerability Protection protect user systems from threats that may leverage this vulnerability with the following DPI rule:

    • 1006810 – Adobe Flash Player Heap Buffer Overflow Vulnerability (CVE-2015-3113)

    Update as of June 26, 2015, 3:10 P.M. PDT (UTC-7):

    Trend Micro solutions are available to help protect users against threats that may leverage this vulnerability. Endpoint products detect malware that attempt to exploit this vulnerability as SWF_EXPLOYT.S. 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.

    Hashes of related files:

    • 5f6a2521c6bfd5becfefc3a3db74d0a23d382f0e
    • 5f28787f60c5f8d9f3aa9163975422d1ff55f460
     
    Posted in Malware | 1 TrackBack »



    Adobe may have already patched a Flash Player vulnerability last week, but several users—especially those in the US, Canada, and the UK —are still currently exposed and are at risk of getting infected with CryptoWall 3.0. The Magnitude Exploit Kit included an exploit, detected as SWF_EXPLOIT.MJTE, for the said vulnerability, allowing attackers to spread crypto-ransomware into their target systems. We first saw signs of this activity yesterday, June 15, through our monitoring of threat intelligence from the Trend Micro™ Smart Protection Network™.

    This particular vulnerability, identified as CVE-2015-3105, was fixed as part of Adobe’s regular June Update for Adobe Flash Player which upgraded the software to version 18.0.0.160. However, many users are still running the previous version (17.0.0.188), which means that a lot of users are still at risk.

    As of this week, these are the top 10 countries most affected by this threat:

    1. United States
    2. Canada
    3. UK
    4. Germany
    5. France
    6. Australia
    7. Italy
    8. Turkey
    9. India
    10. Belgium

    Ongoing Exploit Problem

    This is another example of how cybercriminals rapidly take advantage of recently-patched vulnerabilities through exploit kits. We saw a similar incident in March, where exploits for an Adobe Flash Player vulnerability were added to the Nuclear Exploit Kit just a week after the patch was released. We also noted earlier this month that Flash Player was being targeted more frequently by exploit kits, and that shows no sign of changing soon.

    Figure 1. Flash version used in testing

    The SWF sample we acquired is heavily obfuscated using secureSWF, and uses two shaders for the actual exploit code.

    Figure 2. Shaders used in exploit code

    Widely-used exploit kits such as Magnitude are often well-maintained with new vulnerabilities. Our research on these tools reveals that Magnitude is one of the most used exploit kits by cybercriminals along with SweetOrange and Angler.

    CryptoWall is also another notable threat in and of itself. We initially saw CryptoWall last year spreading through spam, and again later this year partnering with information stealing malware FAREIT.

    Figure 3. Ransomware demand page

    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.  Meanwhile, the Browser Exploit Prevention feature in the Endpoint Security in Trend Micro™ Smart Protection Suite 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.

    We recommend that users stay up-to-date with the latest Flash Player version, and this incident is an excellent reminder of just how important it is to do so. We also note that Google Chrome automatically updates its own included version of Flash Player.

    The malicious Adobe Flash exploit is detected as SWF_EXPLOIT.MJTE. Below is its SHA1:

    • 16ad317b7950c63720f9c7937a60ee3ea78cc940

    Additional analysis by Brooks Li and Joseph C Chen

    Update as of June 16, 2015, 8:30 A.M. PST: We have updated the entry to include the detection name for the exploit.

     



    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 – detected as SWF_EXPLOIT.CAK
     



    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 | Comments Off on Freshly Patched Flash Exploit Added to Nuclear Exploit Kit



    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 | Comments Off on Analyzing CVE-2015-0313: The New Flash Player Zero Day


     

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