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

    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  

    11:47 pm (UTC-7)   |    by

    Detecting banking malware has become part and parcel of the security industry, so cybercriminals are continuously looking to gain the upper hand in the battle against the financial industry and security vendors. In the BlackHat presentation Winning the Online Banking War last August 5, Sean Park proposed the use of a new online banking security framework for banks and web app developers called “Malware Inject Prevention System.”

    The advent of ZeuS ignited the renaissance of banking Trojans a few years ago. The ZeuS source leak enabled the underground community to competitively develop new variants and even pushed the creation of fresh banking Trojan families such as Carberp. This boom of banking Trojans was possible because the ZeuS model was a modular approach that separates the malware from its money-stealing web application logic—which is called the ‘webinject’ or sometimes, ‘injects’ or ‘injections’. This enables cybercriminals to steal online banking customer credentials and to perform transaction manipulation and webinjects while bypassing two-factor authentication. (See also Automating Online Banking Fraud.)

    Although a significant part of the cat-and-mouse battle between the security industry and cybercriminals has to do with detecting the malware binary and evading detection, the detection of webinjects and the subsequent creation of evasion tactics has become a hot new battle ground between the banking industry and cybercriminals.

    Battling it out in the DOM space

    Currently, many security products and financial institutions rely on online banking page integrity checks to detect the presence of banking malware. This technique works due to the inherent mechanics of banking malware injecting itself into the browser’s Document Object Model (DOM) space. For instance, it is quite common for an online banking victim to give away the secure code when he encounters the message below during an online banking session.

    Figure 1. Sample webinject

    An HTML message that’s combined with a piece of JavaScript code injected by the banking malware renders the above screen. It is this injected JavaScript that many banks or vendors use as an artefact in order to detect the infected online banking session via DOM scan.

    However, this purely web-based DOM scan method can be subverted in many ways:

    • Exploiting invalid memory reference patterns

    The webinject can go undetected by exploiting invalid memory reference patterns. When the webinject removes its own script node from the DOM while its reference is kept elsewhere, it causes an invalid memory reference. This is because JavaScript’s garbage collector won’t be able to free the memory object whose reference count is positive. Using this technique, a webinject can register an event handler to an object within the online banking page, remove itself from DOM, and still remain “alive.” More importantly, the naïve script enumeration technique will not be able to see the removed script node.

    • Detection script evasion

    One of the major attack vectors in this threat environment is manipulating the detection script. Once the attackers reverse engineer the detection script, they can forge the intelligence transmitted by the detection script through a replay attack and manipulate the functions implemented by the detection script. This is possible because the banking malware has full visibility and access to all online banking web applications as well as the detection script. The attackers can insert their code at an arbitrary location, replace the detection script functions, or manipulate the detection code. This renders the detection script unable to perform its intended function, unless further remediation is taken.

    • Use of rootkits

    In the world of operating systems, rootkits allow malware to hide malicious components by intercepting the normal control flow of API functions. Rootkit are therefore another viable technique the fraudsters can take advantage of. The webinject can hook functions provided by DOM and the libraries (i.e. jQuery), and tamper with the information they return. This is what I call DOM rootkit (or JavaScript rootkit). For instance, evading the naïve script scan method is as easy as hooking getElementsByTagName DOM function and removing the malicious script from the list before it gets returned. Likewise, this rootkit technique can be applied to any functions used by the detection script. Therefore, it is critical that the detection script runs with a correct view of the operating environment (i.e., without any malicious code interfering with its control flow).

    The need for a paradigm shift

    Any complex code included in the detection script is fully exposed to the attacker. This makes it subject to reverse-engineering and subsequent evasion techiniques on the part of the cybercriminals. Defenders can defeat this by randomization of the detection script with algorithmically heterogeneous implementations with the goal of increasing the attack cost per randomization. In effect, the detection script is obfuscated from the attacker, and attempts to remove this obfuscation would impose a significant computational burden.

    The blind application of traditional metamorphism and polymorphism won’t help increase the difficulty of the attack. Carefully designed strategic defense mechanisms are necessary for each attack vector as described in the paper. In addition, it is critical to acquire a correct system view and ensure that existing defense mechanisms aren’t being subverted. Rootkit detection and code integrity checks can help here.


    In the BlackHat paper, the author outlined the different stealth and evasion techniques that cybercriminals use and the appropriate defensive measures that the banking industry should implement. The author also introduced the creation of MIPS, a hypothetical online banking security framework that works in the web application level instead of the operating system level. This means that instead of trying to discover webinjects in the browser’s virtual memory space, MIPS attempts to find out the JavaScript and associated artefacts injected by the malware. The full presentation is available for download [PDF] at the BlackHat 2015 briefings page.

    Banks need to go through a rigid set of tests before any change is released, which can take up more time than a banking malware’s webinject release cycle. In order to win the online banking war, it is crucial to set up strategic defense rather than short term ad-hoc patching since the overall update structure is not in favor of the defenders in the online banking war.

    When it comes to addressing online banking malware, it is not enough to be reactive to incidents as they occur. Strategic planning and the use of multiple layers of defense can go a long way.

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


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