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

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    August 2015
    S M T W T F S
    « Jul    
  • Email Subscription

  • About Us

    Microsoft has released MS15-093, an out-of-band update for all supported versions of Windows. This bulletin fixes a vulnerability in Internet Explorer (designated as CVE-2015-2502) that allowed an attacker to run arbitrary code on a user’s system if they visited a malicious site. A compromised site, spear phishing, and/or malicious ads could all be used to deliver exploits targeting this vulnerability to the user. This threat is already in use in limited, targeted watering hole attacks in the wild.

    This particular vulnerability is a memory corruption vulnerability, which has historically proven to be a common problem for Internet Explorer. While this vulnerability has been rated as Critical by Microsoft and no mitigations/workarounds were identified in the post, there are several factors that help lessen the risk to users.

    First, any code is run with the privileges of the logged-in user; therefore users who run as an ordinary user and not as an administrator are at lesser risk. Secondly, users of the new Microsoft Edge browser in Windows 10 are also not at risk. In addition, because Internet Explorer in server versions of Windows (Server 2008, Server 2008 R2, Server 2012, or Server 2012 R2) runs in a restricted mode that reduces the risk for these OSes.

    Trend Micro Deep Security and Vulnerability Protection users are already protected from this threat; the following rule that was released as part of the regular Patch Tuesday set of rules also covers this vulnerability:

    • 1006957 – Microsoft Internet Explorer Arbitrary Remote Code Execution Vulnerability

    We urge all affected users to immediately use Windows Update to download and install this update. Users who wish to download this update manually should note that this bulletin is not a cumulative update for Internet Explorer. As a result, the August cumulative update should be installed before this new patch is installed.

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

    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  


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