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

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    September 2015
    S M T W T F S
    « Aug    
  • Email Subscription

  • About Us

    Why would Pawn Storm, the long-running cyber-espionage campaign, set its sights on a Russian punk rock group? Sure, Pussy Riot is controversial. Members of the feminist band had previously been thrown in jail for their subversive statements against the Orthodox Church and Russian patriarchal system. But why would attackers have any interest in them? What is their connection to other targets?

    Earlier this year, we reported that the operators behind Pawn Storm had gone after members of the North Atlantic Treaty Organization (NATO), the White House, and the German parliament. Previously, they focused on various embassies and military attachés stationed across several countries. Pawn Storm’s targets have mostly been external political entities outside of Russia, but after our analysis we found that a great deal of targets can actually be found within the country’s borders.

    Domestic spying in Russia

    The Russian spies behind Pawn Storm apparently do not discriminate. They even monitor their fellow citizens. Credential phishing attacks directed towards Russian nationals builds a case for domestic spying. Figure 1 shows a closer breakdown of their targets per industry.

    Figure 1. Primary industry/sector targets in Russia

    Many peace activists, bloggers, and politicians got targeted in Russia. Some of the more noteworthy targets per industry are as follows:

    Politicians A former Russian prime minister, and a prominent member of United Russia
    Artists Two members of Pussy Riot and a popular Russian rock star
    Media Journalists from, The New Times, TV Rain, Novaya Gazeta, Jailed Russia, other media outlets that criticize the current Russian regime, and the Apostol Media Group
    Software developers A CEO of a Russian company developing encryption software, and a developer

    Looking at the list, it’s easy to conclude that the people behind this campaign are keeping tabs on potential dissidents of the current Russian regime. Pussy Riot’s criticism of the government does make them a logical target if this were the case. But the inclusion of software developers, as well the Apostol Media Group, which has ties to Russian government, is interesting. The fact that at least one active Russian military attaché in a NATO country got targeted by Pawn Storm makes the spies’ motivations even more intriguing.

    The Ukraine and US connection

    In Figure 2, we see the top 10 target countries of Pawn Storm. Ukraine has the lion’s share. With 25%, it surpasses Russia and the US. The three countries currently have a volatile relationship thanks to clashing political interests.

    Figure 2. Breakdown of Top 10 targets by country

    The military, media, government, and political figures in Ukraine were all targeted almost equally, with those four categories accounting for approximately two-thirds of all targets in the country:

    Figure 3. Primary industry/sector targets in Ukraine

    As for the US, the primary targets are defense companies and the military (Air Force, Navy, and Army). Think tanks and academia are targets too. Pawn Storm also has a particular interest in oil researchers and nuclear energy.

    Figure 4. Primary industry/sector targets in the US

    These attempted compromises were part of a larger campaign of tens of thousands of individual credential phishing attacks against high-profile users of a multitude of webmail providers like Gmail, Yahoo, Hushmail, Outlook, and other providers in Ukraine, Iran, Norway, and even China.

    The United Kingdom is a big target for Pawn Storm, but the majority of attacks are attempts to compromise Eastern Europeans who reside in Britain.

    A case of credential phishing

    The way the attacks are carried out varies. Some campaigns used malware and vulnerabilities. Pawn Storm used at least six zero-days, including the critical CVE-2015-2590 Java vulnerability. A prominent modus operandi is advanced credential phishing. We were able to collect data on more than 12,000 individual credential phishing attacks in 2014 and 2015, making it possible for us to derive reliable statistics on Pawn Storm targets worldwide.

    To illustrate one of the credential phishing attacks Pawn Storm sends to its targets, we will focus on a particular attack on high-profile Yahoo users in early July 2015.

    Figure 5. Targeted Yahoo credential phishing e-mail

    This phishing attack tried to lure selected Yahoo users to give Pawn Storm full access to their mailboxes using OAuth—an open standard authentication protocol that Yahoo offers to app developers. Pawn Storm sent out phishing e-mails that offered a “Mail Delivery Service” for guaranteed delivery of e-mails. In reality, this service was built to allow attackers behind Pawn Storm to access their target’s accounts through OAuth. When Yahoo users would opt in, Pawn Storm would get unfettered access to the mailbox.

    The problem here is that the phishing links point to a legitimate Yahoo website of OAuth. Since this is the case, recipients of the phishing e-mails may think the phishing URL is harmless.


    Figure 6. Phishing site at where Pawn Storm’s targets are lured into giving permission to full mailbox access

    Although we cannot say for sure what these spies’ intentions are, given the variety of this campaign’s targets, it looks like they are amassing a huge database of information, perhaps keeping tabs on possible threats to Russia. We are continually monitoring the campaign and its developments.

    This is the latest entry in a series of blog posts we have done on Operation Pawn Storm:

    Pawn Storm is also mentioned in our 2Q Security Roundup, A Rising Tide: New Hacks Threaten Public Technologies.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    A supposed airline hack and other similar incidences this past quarter have made it clear: Attackers are finding more inventive ways to infiltrate and abuse existing technologies. This signals a rise in threats that go beyond just stealing data, and whose effects are more physical, evident, or close to home.

    Take for instance the increasing number of attacks involving routers and DNS changer detections, particularly in Brazil, which accounted for 81% of the total number of DNS changer detections in 2Q. Advancements in point-of-sale (PoS) malware continued to be a nuisance to businesses, yet its slight decline in 2Q could mean that the threat may be reaching its saturation point.

    Figure 1. There was a noticeable decrease in PoS threats for the second quarter of the year.

    This doesn’t mean that cybercriminals are abandoning their old operations. Traditional malware is still circulating, with basic malware components readily available for just about anyone to create his own malicious enterprise. The second quarter also shed some light on solo cybercriminal operations seen across the globe as evidenced by solo operations seen in Brazil and Canada.

    Figure 2. Solo cybercriminal operations were spotted in the second quarter.

    One of the more notable developments we saw was coordination across law enforcement agencies for public-private partnerships (PPP). Some law enforcement wins included botnet takedowns for longstanding operations and the indictment of Silk Road mastermind Ross Ulbricht.

    Government entities were the primary attack targets in the second quarter, with the OPM breach marking the biggest incident to date exposing more than 20 million records belonging to United States federal employees. Another big attack that continues to affect government entities until now is Operation Pawn Storm, which we saw targeting NATO members as well as the White House in April and even using a Java zero-day to attack governments this July.

    The Angler Exploit Kit creators aggressively integrated new exploits for Adobe® Flash® vulnerabilities. We have also seen a faster integration of these kits as evidenced by the high amount of Angler Exploit Kit-related detections in the second quarter. According to Deep Security Labs Director Pawan Kinger, “Enterprises must be very watchful of vulnerabilities in the core software and plug-ins that they use. Custom applications need customized checking. A good penetration test on custom applications always compensates for that.”

    As more and more public-facing technologies get developed for Internet connectivity, we are witnessing a recurrence in attacks that are more strongly felt. User online safety and privacy has never been more critical than now.

    Read our 2Q 2015 Security Roundup, A Rising Tide: New Hacks Threaten Public Technologies.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    The “hits” keep on coming for Android’s mediaserver component. We have discovered yet another Android mediaserver vulnerability, which can be exploited to perform attacks involving arbitrary code execution. With this new vulnerability, an attacker would be able to run their code with the same permissions that the mediaserver program already has as part of its normal routines.

    This vulnerability has been designated as CVE-2015-3842. While it affects Android versions 2.3 to 5.1.1, Google has fixed and published details this vulnerability via the Android Open Source Project (AOSP). Currently, there are no known active attacks against this vulnerability.

    This discovery closely follows three other major vulnerabilities in Android’s mediaserver component that surfaced recently. CVE-2015-3823 may allow attackers to trap phones in endless reboots, ANDROID-21296336 may render devices silent, while CVE-2015-3824 (Stagefright), can be used to install malware through a multimedia message.

    How it works

    The vulnerability involves AudioEffect, a component of the mediaserver program. It uses an unchecked variable which comes from the client, which is usually an app. For an attack to begin, attackers convince the victim to install an app that doesn’t require any required permissions, giving them a false sense of security.

    Figure 1. Android UI showing the lack of permissions required by our POC app

    The checking of the buffer sizes of pReplyData and pCmdData is not correct. The buffer sizes of both pReplyData and pCmdData and the buffer pCmdData itself all come from client-supplied parameters. As the mediaserver component uses these buffers, it reads a size coming from the buffer pCmdData; the mediaserver component assumes the buffer sizes of pReplyData and pCmdData are bigger than this size. We can make the buffer size of pReplyData, which is client-supplied, smaller than the size read from the buffer pCmdData. This causes a heap overflow.

    I used the related source code files from a vulnerable Android version (5.1.1). In the screenshot below, we can see that the vulnerable file name is EffectBundle.cpp.

    Figure 2. Heap overflow locations

    Another vulnerable file is EffectReverb.cpp.

    Figure 3. Heap overflow location

    Proof-of-concept demonstration

    I decided to test it using a Nexus 6 with the Android 5.1.1 LMY47Z image. I wrote an app that crashes the mediaserver component by overflowing the buffer pReplyData in heap. Below is a portion of the PoC’s Java language source code.

    Figure 4. Get mNativeAudioEffect from object

    Below is the PoC’s C++ language source code, which is invoked by Java:

    Figure 5. Send malformed data to mediaserver

    In the PoC, when the app is running, the mediaserver component will crash at a random function. If the mediaserver component doesn’t crash, the POC app can be closed and ran again.

    Below is one of the crash report logs:

    F/libc    (  357): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x7777776b in tid 4757 (Binder_5)
    I/DEBUG   (  354): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    I/DEBUG   (  354): Build fingerprint: 'google/shamu/shamu:5.1.1/LMY47Z/1860966:user/release-keys'
    I/DEBUG   (  354): Revision: '33696'
    I/DEBUG   (  354): ABI: 'arm' W/NativeCrashListener(  855): Couldn't find ProcessRecord for pid 357
    I/DEBUG   (  354): pid: 357, tid: 4757, name: Binder_5  >>> /system/bin/mediaserver <<<
    I/DEBUG   (  354): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7777776b
    I/DEBUG   (  354):     r0 b3123bb4  r1 b3123bb4  r2 77777777  r3 b404e380
    I/DEBUG   (  354):     r4 b3123bb4  r5 b589a1c0  r6 b3123bb4  r7 00000003
    I/DEBUG   (  354):     r8 0000030e  r9 b3123bdc  sl 00000009  fp b5873b20
    I/DEBUG   (  354):     ip b6e46d7c  sp b3123ba8  lr b6fb1db7  pc b6fb1c26  cpsr 80000030
    I/DEBUG   (  354):
    I/DEBUG   (  354): backtrace:
    I/DEBUG   (  354):     #00 pc 0001ec26  /system/lib/
    I/DEBUG   (  354):     #01 pc 0001edb3  /system/lib/
    I/DEBUG   (  354):     #02 pc 0002341b  /system/lib/
    I/DEBUG   (  354):     #03 pc 0002045f  /system/lib/
    I/DEBUG   (  354):     #04 pc 00009bef  /system/lib/
    I/DEBUG   (  354):     #05 pc 00016d95  /system/lib/ (android::AudioPolicyManager::getInputForAttr(audio_attributes_t const*, int*, audio_session_t, unsigned int, audio_format_t, unsigned int, audio_input_flags_t, android::AudioPolicyInterface::input_type_t*)+736)
    I/DEBUG   (  354):     #06 pc 00009701  /system/lib/
    I/DEBUG   (  354):     #07 pc 00069647  /system/lib/ (android::BnAudioPolicyService::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+890)
    I/DEBUG   (  354):     #08 pc 0001a6cd  /system/lib/ (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+60)
    I/DEBUG   (  354):     #09 pc 0001f77b  /system/lib/ (android::IPCThreadState::executeCommand(int)+582)
    I/DEBUG   (  354):     #10 pc 0001f89f  /system/lib/ (android::IPCThreadState::getAndExecuteCommand()+38)
    I/DEBUG   (  354):     #11 pc 0001f8e1  /system/lib/ (android::IPCThreadState::joinThreadPool(bool)+48)
    I/DEBUG   (  354):     #12 pc 00023a5b  /system/lib/
    I/DEBUG   (  354):     #13 pc 000104d5  /system/lib/ (android::Thread::_threadLoop(void*)+112)
    I/DEBUG   (  354):     #14 pc 00010045  /system/lib/
    I/DEBUG   (  354):     #15 pc 00016baf  /system/lib/ (__pthread_start(void*)+30)
    I/DEBUG   (  354):     #16 pc 00014af3  /system/lib/ (__start_thread+6)
    I/BootReceiver(  855): Copying /data/tombstones/tombstone_03 to DropBox (SYSTEM_TOMBSTONE)

    Possible threat scenarios

    This attack can be fully controlled, which means a malicious app can decide when to start the attack and also when to stop. An attacker would be able to run their code with the same permissions that mediaserver already has as part of its normal routines. Since the mediaserver component deals with a lot of media-related tasks including taking pictures, reading MP4 files, and recording videos, the privacy of the victim may be at risk. Devices with customized versions of Android but with no modification made to the mediaserver component are also affected.

    A dilemma users may face is that it will be difficult for them to locate the cause once an attack occurs. In our demo, we simply triggered the attack by running an app; this is convenient and intuitive for disclosure. While attacks can be triggered by apps alone, real-world attacks won’t involve apps that are easy to detect. The malicious app will try as much as possible to appear legitimate and use dynamic load technology to remain undetected while triggering the attack several days/months later, either persistently or intermittently, similar to other malware.


    End users can block this threat from the onset by downloading Trend Micro Mobile Security (TMMS), which can detect threats trying to use this vulnerability and running any of the scenarios presented. Android users can also reboot their device using safe mode to uninstall the malicious app. However, this method might prove difficult, especially for those unaccustomed to tinkering with their devices.

    We also recommend that device manufacturers patch their devices regularly to prevent their users from suffering from attacks that use this vulnerability.

    Disclosure Timeline

    This vulnerability was disclosed to Google, with details outlined below:

    • June 19: We reported the issue, along with the corresponding POC, to the Android Security Team.
    • June 19: The Android Security Team accepted it as a high severity vulnerability and assigned AndroidID-21953516 to it.
    • June 24: The Android Security Team assigned CVE-2015-3842 to it.
    • August 1: The Android Security Team published the fix in AOSP.
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    Earlier this week Oracle’s CSO released a blog post that talked about why people should stop looking for vulnerabilities in their software products. Needless to say, this did not go down well with the security community – and the post was soon taken down with a statement from the company adding that the post “does not reflect our beliefs or our relationship with our customers.”

    Security through obscurity doesn’t work, and that is what Oracle’s CSO was in effect promoting when it comes to vulnerabilities. On the other hand… she might have had a point if they were talking about people who look for vulnerabilities to sell vulnerabilities, or to use them in attack code (like the zero-day we recently found as part of Pawn Storm.)

    Of course, we informed Oracle about this vulnerability before we published the blog post. Our initial entry was deliberately vague in order to prevent less-informed attackers from learning details about the vulnerability. As we saw actual attacks, however, we released a more detailed entry that showed how the exploit worked. Amusingly, the attacker behind the initial usage of this zero-day took offense to our earlier reporting: they added one of our domains ( into their attack code. As we believe in transparency, we talked about this as well.

    In short, if Oracle had criticized those who make money and endanger the safety of users, then maybe any post would have been better received. The vulnerability business model where cybercriminals, “researchers”, and nation-states buy and sell vulnerabilities isn’t good for anybody… except those who are already part of that “market”.

    Trend Micro discovers and reports many vulnerabilities every year, even though it is not our company’s primary focus. I believe that we need to look at the bigger picture: why do security companies look for vulnerabilities, why do we follow responsible disclosure, and why we are against selling and buying vulnerabilities.

    Why it is important to detect and fix vulnerabilities?

    Companies should be pleased if legitimate researchers like Trend Micro detect vulnerabilities – and we have had companies that were glad for the help. Any researcher that abides by responsible disclosure should be welcomed by developers.

    We make our money by protecting our customers – the moment we know about a new vulnerability we use this knowledge to help protect our customers – without disclosing any details about the vulnerability to the public. If someone were to reverse engineer all the rules we provide with our products, they may get a hint… but not enough to fully understand and exploit the vulnerabilities in question.

    Once we have informed affected companies, they are usually able to release a patch fixing the issue pretty quickly. Users now have a more stable and secure application. If we’re on the other side of a vulnerability disclosure, we do our best to quickly patch our own products as well.

    Why we follow responsible disclosure

    As I mentioned earlier, we inform companies about the vulnerabilities we discover in their products, as well as those vulnerabilities we learn about from our various sourcing efforts. We give them plenty of time to release a fix before we disclose anything so that the general public is protected.

    However, if the vulnerability is used in the wild before any disclosure is made, we may release more details right away. We believe that’s our duty, and you saw this during the recent Hacking Team incident. We warned users as soon as possible using this blog that there were zero-day vulnerabilities from the data dumps, that these were now being used in exploits kits, and how users could protect themselves.

    Why we are against the vulnerabilities trade

    Trend Micro is strictly opposed to the trading of vulnerabilities for money. For me, it is hard to swallow that my home country (Germany) and other countries bought (and are probably still buying) vulnerabilities to attack others. We know how widespread this practice is now thanks to the now public customer list of Hacking Team. This is not how I want to see my tax money at work.

    Governments should only be allowed to buy vulnerabilities to inform the affected vendors immediately – i.e., to protect users. Even better, if nobody bought vulnerabilities anymore, but the affected vendors are informed for free soon after the flaw has been detected, our digital world would be a safer place.

    If we were in such a place, then the Oracle CSO would not have to release posts complaining about reverse engineering. Instead, she would be thankful – because it is not done out of commercial interests, but to protect users and to make software code more stable and resilient.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    2015 has so far been a very busy year for security researchers. The data leaked from Hacking Team shocked many, thanks to the multiple zero-days that were disclosed, as well as emails discussing the unscrupulous trade in exploits and “tools”.

    Cybercriminals (including exploit kit authors) have been hard at work integrating these newly-discovered flaws into their “products” to victimize more people and organizations; meanwhile vendors have been racing to provide users with security updates. This is a good time to see how the threat landscape has been shaped by the vulnerabilities found so far this year.

    Summary of 2015 to date

    As I noted earlier this year, the risks of using OS X, iOS, Android and Flash Player increased this year. Our own research, plus the leaked data from Hacking Team, reflects this trend. By the end of July 2015, our researchers discovered and disclosed 26 vulnerabilities; eight were zero-days.

    Of these, two were discovered in high-profile advanced attacks, including Operation Pawn Storm and attacks in Korea and Japan.  We found two Flash zero-days (CVE-2015-0311 and CVE-2015-0313) by monitoring popular exploit kits as well as feedback from Trend Micro products. Four more zero-days were found as part of the Hacking Team data and later confirmed at least one (CVE-2015-5122) of them was quickly integrated in exploit kits. As of July, a total of 15 noteworthy zero-days were found in commonly used desktop applications by various researchers, with 8 of these found by our researchers.

    Figure 1. Timeline of 2015 zero-days and critical vulnerabilities discovered by Trend Micro

    The following is a list of the vulnerabilities Trend Micro has discovered to date in 2015, the affected software, and the relevant vendor bulletin (if any). The vulnerabilities in bold text represent zero-days:

    1. CVE-2014-4140 (Microsoft Internet Explorer, MS14-056)
    2. CVE-2015-0069 (Microsoft Internet Explorer, MS15-009)
    3. CVE-2015-0311 (Adobe Flash, APSB15-03)
    4. CVE-2015-0313 (Adobe Flash, APSA15-02)
    5. CVE-2015-1649 (Microsoft Office, MS15-033)
    6. CVE-2015-1683 (Microsoft Office, MS15-046)
    7. CVE-2015-1694 (Microsoft Internet Explorer, MS15-043)
    8. CVE-2015-1709 (Microsoft Internet Explorer, MS15-043)
    9. CVE-2015-1754 (Microsoft Internet Explorer, MS15-056)
    10. CVE-2015-1835 (Apache Cordova bulletin)
    11. CVE-2015-2391 (Microsoft Internet Explorer, MS15-065)
    12. CVE-2015-2415 (Microsoft Office, MS15-070)
    13. CVE-2015-2425 (Microsoft Internet Explorer, MS15-065)
    14. CVE-2015-2426 (Microsoft Windows, MS15-078)
    15. CVE-2015-2590 (Oracle Java – Oracle Critical Patch Update Advisory – July 2015)
    16. CVE-2015-3823 (Google Android)
    17. CVE-2015-3824 (Google Android)
    18. CVE-2015-3839 (Google Android)
    19. CVE-2015-3840 (Google Android)
    20. CVE-2015-3842 (Google Android)
    21. CVE-2015-3847 (Google Android)
    22. CVE-2015-3851 (Google Android)
    23. CVE-2015-3852 (Google Android)
    24. CVE-2015-5119 (Adobe Flash, APSA15-03)
    25. CVE-2015-5122 (Adobe Flash, APSA15-04)
    26. CVE-2015-5123 (Adobe Flash, APSB15-18)

    We also discovered nine vulnerabilities on the Android platform. The number of vulnerabilities in mobile operating systems and OS X grew significantly from 2014, given the increase in attention given to it by blackhat hackers, white hat hackers, and security conferences. Attacks in the wild are also known: a zero-day exploit toolkit made by Hacking Team included well-crafted shellcode to attack OS X 64-bit systems. That means Hacking Team’s customers – the attackers – are also very interested in Mac users.

    At least five Flash exploits were imported into exploit kits right after Adobe’s patches were released. However, new exploits targeting other applications were rarely seen during the same time period. It indicates that Flash Player was specifically targeted by attackers.

    Figure 2. Distribution of zero-days discovered in desktop applications

    Figure 3. Distribution of zero-day discoveries

    New changes and the future

    In addition to the multitude of Flash exploits found in the year to date, there were some other developments related to exploits and vulnerabilities:

    • After several difficult years, Adobe finally introduced new exploit mitigations into the current version of Flash Player (with some assistance from Google Project Zero). This has strengthened the Flash heap with isolation and stronger randomization, and added extra validation on the Vector.<*> length as well. As a result, vulnerabilities can no longer be exploited by currently known and common methods. I believe that these will keep out attackers in the short term by making it more difficult to write exploit code – so long as users are on current versions of Flash.
    • We discovered the first Java zero-day since 2013. It was used in new attacks related to Operation Pawn Storm, which targeted armed forces of a NATO country and a US defense organization. Two vulnerabilities were used in the exploit, and one (CVE-2015-2590) has been fixed by Oracle. It’s a good question if we will see large-scale attacks targeting Java return.
    • Vendors rapidly fixed the vulnerabilities leaked from the Hacking Team data. Although good news for now, these leaked attack templates will continue to have lingering effects over the long-run. Hacking Team was well-organized, and other attackers can definitely learn from them. It is not easy to create exploits that will run across multiple platforms and which will run without being spotted by the user. This is what Hacking Team has accomplished – not only did they create exploits, they created high-quality, well-designed ones. These could serve as templates that other attackers could learn from.

    Based on the above points, I predict there will be more advanced attacks in the second half of 2015.

    Macs will attract more attackers with the number of discovered OS X vulnerabilities gradually on the rise. Looking at CVE details, 63 were found in 2013, and another 111 in 2014. Even though the year is still far from finished, 178 have already been found in 2015 – beyond even the number found in 2014.  Trend Micro researchers have discovered some OS X vulnerabilities, and are working with Apple to provide patches. It’s still in the early days of OS X vulnerability research, and some skills from Windows exploits (such as return-oriented programming, or ROP) are also applicable to the OS X platform. Even some malware families (such as Flashback) have been “ported” as well.

    So far in 2015, there have been several security incidents based on the research into OS X issues such as ThunderstrikeRoot-pipeEFI boot script vulnerability, and DYLD_PRINT_TO_FILE vulnerability. Fortunately, each of these exploits could only be used as part of a larger attack chain, instead of a complete attack.

    This changed with the “Thunderstrike 2″ rootkit, which has already been disclosed to the public. It exploits the DYLD_PRINT_TO_FILE vulnerability to compromise Macs remotely (i.e., via a phishing email or malicious website). It can then spread from one Mac to another via Thunderbolt devices by exploiting an EFI vulnerability (much like USB malware on Windows PCs). Thunderstrike 2 is more serious for three reasons:

    • It can be remotely deployed and spread
    • You cannot remove it even you format your hard disk.
    • One of vulnerabilities does not have a patch yet.

    All this indicates that Mac users are under increasing risk from similar attacks.

    In addition, more evasive techniques like SecureSWF encryption may be used by attackers. They may also use Java once again. Windows 10’s new browser Microsoft Edge has been introduced, and while it does contain notable improvements, attackers are surely going to test its defenses as well. In more hopeful news, Flash exploits will be restricted to users who don’t have the latest version installed (although many users don’t upgrade to the newest version).

    Vulnerability research and Trend Micro protection

    Trend Micro researchers focus on analyzing exploit samples gathered from victims of targeted attacks. These are harvested from different channels such as honeypots, feedback from Trend Micro products, and submissions from customers and users. This comprehensive approach helps us discover many zero-day attacks in only seven months. We also proactively seek out vulnerabilities using static analysis, fuzzing, and penetration testing. We responsibly report vulnerabilities to vendors before hackers can use them.

    Our researchers work closely with our development teams to ensure our products provide the best possible protection against exploits. Our products use the most effective detection methods, guided by our experience in exploit analysis. The collected samples and discovered vulnerabilities are used to validate the effectiveness of our products and solutions.

    These and other efforts contribute to the positive test results of Trend Micro products in tests by independent laboratories like AV-Test, AV-Comparative, and NSS Labs. In particular for the second year in a row Trend Micro™ Deep Discovery has received a “recommended” rating and is the highest overall recommended breach detection system from NSS Labs, making it the most effective solution available. This shows the solution excellence of Deep Discovery, which is based on more than 20 issued patents and dozens of other pending patents.

    Zero-day exploits are used primarily for carrying out targeted attacks. By definition, they are unknown and unpredictable, exposing the systems of even the most diligent security practitioners. In addition to benchmarking, our research helps us proactively detect zero-days and stay one step ahead of attackers. The existing Sandbox with Script Analyzer engine (which is part of Trend Micro Deep Discovery), can detect many of the zero-day exploits seen in 2015, without need for updates. The ability to detect zero-days is even more valuable to users than discovery and response. We were able to detect the following zero-days without any updates:

    • CVE-2015-0310
    • CVE-2015-0311
    • CVE-2015-0313
    • CVE-2015-2590
    • CVE-2015-3043
    • CVE-2015-3113
    • CVE-2015-5119
    • CVE-2015-5123

    This benchmarking achievement and advanced detection shows that Trend Micro Deep Discovery is an industry leading APT/advanced threat solution, with our smart sandbox being one of the key contributors. The smart sandbox is customizable, and it not only has payload behavior detection, but it also has script and shell-code behavior detection. If you want to know more details, please visit my previous blog here.

    Update as of August 17, 2015, 10:o9 A.M. PDT (UTC-7):

    Apple has released a security update last week to address several vulnerabilities, including the DYLD_PRINT_TO_FILE bug mentioned in this entry. Included in the vulnerabilities addressed by this patch is a bug discovered by Trend Micro. Designated as CVE-2015-3787, this vulnerability may allow an attacker with privileged network position may be able to perform denial of service attack using malformed Bluetooth packets. We advise Apple users to install the patch immediately.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  


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