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    
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    3031  
  • Email Subscription

  • About Us

    Jul30
    2:09 pm (UTC-7)   |    by

    July has been a fairly poor month for Adobe Flash Player security, to say the least. Three separate zero-day vulnerabilities (all courtesy of the Hacking Team dump) have left many people concerned about Flash security, with many (including this blog) calling for it to go away.

    Some sort of reaction from Adobe to improve Flash security was inevitable. The recent version of Flash, version (18.0.0.209), includes several additional mitigation techniques. These were developed by Adobe, working together with Google’s Project Zero.

    The new exploit mitigation techniques are:

    • Vector.<*> length validation – adds a length cookie to the Vector buffer. If an exploit overwrites the Vector length, the cookie checking will cause a failure. Because every Flash exploit today uses overwrites the Vector length, this mitigation point makes Flash exploit harder, and can stop even undisclosed zer0-day exploits.
      After adding the length cookie check, an attacker needs two vulnerabilities to carry out an attack –  one to leak the length cookie, and another to overwrite the length. A single vulnerability that can both leak and overwrite this field can also be used, but this kind of vulnerability is rare.
    • Vector.<uint> buffer heap partitioning – this mitigation makes leaking cookies and overwriting the vector length harder. Specific vulnerabilities are now needed instead of generic information leak and overwrite vulnerabilities.
    • stronger randomization for the Flash heap – this mitigation point makes leaking cookies and overwriting the vector length harder, because the heap layout is harder to predict than before.

    These techniques mitigate exploits fairly effectively, as it can decrease the number of exploits using vector length overwrite techniques. However, note that these are exploit mitigation techniques: in effect, it’s a band-aid on any vulnerable code. Other attempts at exploit mitigation (such as that done on Internet Explorer by Microsoft in 2014) have added mitigation techniques and fixed the underlying code. In the IE example, most IE UAF vulnerabilities became NULL pointer dereferences.

    Not all vulnerabilities can be mitigated in this manner. If attackers were able to find a new class of potential Flash vulnerabilities that bypass these steps, we could be back in a situation where similar vulnerabilities appear in relatively close succession. Alternately, it may become the case that each exploit is essentially “from scratch” and does not rely much on what was found

    Not all of these protection techniques apply to all browsers. Vector.<*> length validation is available to other browsers; however the other techniques are not. Users on other browsers are not yet fully protected, although they will be next month.

    Hacking Team, Targeted Attacks, and Flash: Exploits Beyond the Browser

    While these additional mitigation techniques are useful and can reduce the problems that users face, however Flash is now being targeted for exploitation outside of the browser. It is now being embedded into Office documents; this allows many of these defenses to be bypassed.

    Once again, credit for this “discovery” must go to the people over at Hacking Team. Trend Micro has noticed that some of these zero-day vulnerabilities, CVE-2015-5119, has been adopted in targeted attacks. Emails spoofing the Taiwanese government that contain a malicious attachment have been spotted in the wild, as seen below:

    Figure 1. Spoofed email

    At first glance it would appear to be a perfectly ordinary targeted attack email, complete with a malicious email. We believe that this particular sample has links to the PLEAD campaign which we found last year. In addition, we believe that it can now target 64-bit versions of Windows as well as Mac OS X:

    Figure 2. Windows x64/OS X

    However, what is more interesting is these malicious attachments do not target Microsoft Office vulnerabilities at all. These Office documents contain an embedded Flash file which contains an exploit. If this exploit is successful, it is then used to download and run the actual malware payload.

    Figure 3. Successful exploit with an Internet Explorer process (Click to enlarge)

    Builder tools

    How was this attack carried out? The attackers appear to have been inspired by the Hacking Team, which used a very similar method. Based on correspondence and files from the Hacking Team leak, we learned that the attackers used automated builders to help automate their attacks. The following diagram shows how this builder was actually used:

    Figure 4. Builder usage

    The attackers would provide a “clean” Office document they would use for the attack, the Flash exploit, and the actual malware payload. The builder would create the documents with embedded Flash files, as well as the files that need to be uploaded to a malicious or compromised server of the attacker’s choosing.

    There is one key difference in how the attacks we encountered and how the Hacking Team designed their attacks. The files we saw had the Flash exploit embedded directly. The Hacking Team builder embeds a Flash file which downloads a separate Flash exploit. This has the advantage of not placing any exploit code inside the Flash file which may be detected.

    While the Flash files and the payload do not have to be in the same directory, the builder is designed to place them in the same location.

    The builder is also designed to help make detection and analysis of the malware used more difficult:

    • Network traffic uses HTTPS to encrypt its traffic, making detection by network security solutions such as Deep Discovery more difficult.
    • A random 4-byte key and the XOR function is used to encrypt the malware used.

    Best practices

    A key part of Flash-related best practices to date has been to keep it up to date and use click-to-play in browsers (or to disable it entirely). However, these controls only work with attacks that use Flash via the browser. Solutions that use Flash via Microsoft Office would not be affected, so users can be affected even if they think they are “safe”.

    Security-conscious users should consider completely disabling Flash on their systems, and uninstalling it if possible. Windows users may also opt to use kill bits to disable Flash from running on their systems at all.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Crystal-01This is the second post in the “FuTuRology” project, a blog series where the Trend Micro Forward-Looking Threat Research (FTR) team predicts the future of popular technologies. Make sure to check the first entry of the series for a brief introduction on the project.

    Predicting the future sucks. It does because we are never right. If what we say does not come to pass, we look bad. On the other hand, if what we say happens, naysayers will say that it’s because the attackers read the blog too and we gave them ideas—the self-fulfilling prophecy.  We’re damned if we do and damned if we don’t. That is how it is for infosec fortune tellers.

    Today’s topic is very exciting: healthcare technology.

    Let me start by mentioning a technology we have at present: fitness wearables. These little devices are already in mass production and selling like hotcakes, just look at vendors like Fitbit or Jawbone®. Last February’s Mobile World Congress at Barcelona saw us trying out device after device in all kinds of flavors. Some vendors were already aiming at niche markets, like pets and children, but don’t let me stray from the topic at hand. These wearables, when strapped on our bodies, can count the steps we take and our heartbeats per minute, then estimate the calories we burn. Their companion mobile apps let us log weight changes and our food intakes to better estimate our calories and compare how much we are over/under-eating. All this information is uploaded to the vendor’s cloud so they can show us pretty colored graphs. So far, so good.

    Let us look at the near future. Judging by some crowdfunded projects and rising public interest, something big is coming soon. I’m talking about devices that measure health parameters at will and upload data to the vendor’s cloud. What kinds of data? There’s body temperature, blood pressure, blood oxygen levels, heart rate, respiratory rate, electrocardiogram (EKG or ECG), and others like them. Once the data is uploaded, the server algorithmically analyzes whether those values are normal or a bit off based on your personal historical data. This technology promises to know whether you’re going to become sick before you actually do or even notice that you might. Awesome tech!

    The similarities between fitness wearables and smart medical devices are pretty obvious. Will we see an amalgamation of both at some point in the future on the same device? It’s hard to say but it’s probable. I’d venture to say it’s even more likely that we’d see health data correlation at a scale never seen before. From the medical point of view, mining both data sets is huge. The fitness data provides us the actions, while the medical data provides the effects. Does a higher intake of bananas start a metabolic effect that makes us sick after two months? Does this only happen in certain regions? Or perhaps only in populations of a certain age? Even simpler than that, when does a flu outbreak start in the world and how does its impact change based on your activity level? How cool is this?

    Once we have this technology implemented on a massive scale, we can use it for different things too. How about enabling remote doctor house calls, where the doctor can triage patients based on their current medical data? This could lower medical costs quite a bit. Perhaps we can use these doctor visits in remote locations in case someone can’t physically make it in time for the diagnosis. More interesting than that, outbreak specialists can virtually be anywhere in the world, taking body measurements remotely and studying the geographical impact of a spreading disease from their home laboratories.

    Affordable DNA sequencing is another healthcare technology that might have great impact on all of us in the future. When the cost of this technology gets low enough, we can all get tested to see what kinds of illnesses we are prone to. We may also prepare by making lifestyle and dietary changes to avoid them. This can be a big change in the healthcare field.

    I’ll let you, the reader, create attack scenarios for each of those. Possible attack vectors don’t always focus on stealing money or credentials (to enable the much-touted ‘identity theft’ or even user extortion) from users. The most likely kinds of threats we expect to see – at least initially – would be focused on privacy. If we start uploading medical data to the cloud, we upload very confidential information to places we do not control. Privacy is clearly a concern as would be any denial of service (DDoS) attack on remote medical services or data tampering of medical diagnosis at any point.

    It’s difficult to be more concrete than this at this point or we run the risk of plotting a science-fiction movie very quickly. Remember that, in any new technology with a lot of moving pieces, poking the engine with a stick will cause gears to fly. These technologies are still in the works and are not even remotely ready yet. At this point, these future healthcare scenarios are purely hypothetical, but still, the intellectual exercise of attacking castles in the air is always interesting, isn’t it?

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Last week we discussed how Microsoft Edge, the new browser in Windows 10, represented a significant increase in the security over Internet Explorer. However, there are also new potential threat vectors that aren’t present in older versions.

    Integrated plug-ins

    Microsoft Edge has now integrated two widely used plug-ins into the browser itself: Adobe Flash and a PDF reader. Flash has proved itself to be a significant security risk for many years. While we believe that users and sites should move away from it, the reality is that for the foreseeable future Flash won’t go away yet. Attacks targeting Flash will continue to be a problem, and having it as a built-in feature may pose risks down the road.

    Similarly, an integrated PDF reader in the module windows.data.pdf.dll.  This could also become a potential target for an attacker looking for a way into the Edge browser.

    While these represent potential attack vectors, implemented properly they can remain relatively secure. Both Google Chrome and Mozilla Firefox have implemented integrated plug-ins without major problems; a proper implementation can reduce the risk from insecure plug-ins.

    In addition, the integration of Flash means that updates to it can be pushed via Windows Update, reducing the risk of users running older Flash versions. (Note that this is not completely unprecedented: since Internet Explorer 10 on Windows 8, this has been the case already.)

    Support for asm.js 

    One feature new to Edge is support for asm.js. This is a Mozilla-developed subset of JavaScript that has been designed to run faster than conventional code. In effect, it translates the C/C++/etc. code into JavaScript code, which can run much faster if the browser supports asm.js. The LLVM compiler is responsible for this action.

    Figure 1. asm.js flow chart

    In other browsers, asm.js support has led to security problems. At 2015’s annual Pwn2Own competition, a vulnerability (CVE-2015-0817) in the Mozilla Firefox implementation of asm.js was used to successfully “own” that browser. Therefore, we cannot rule out the possibility that it could be a source of vulnerabilities in Microsoft Edge as well.

    New Extension Model

    Microsoft Edge will introduce improved extension support sometime after the launch of Windows 10. It is known that Chrome and Firefox extensions can be used by Microsoft Edge with relatively little modification, but other details have not been made clear.

    These extensions will run in the AppContainer sandbox, but sandbox escape vulnerabilities can be used to evade this. In addition, the of malicious extensions cannot be ruled out – either they may be malicious from the start, or a legitimate extension can be modified with an update to become malicious.

    However, the version of Edge that will be launched with Windows 10 does not have support for extensions yet.

    Browser Security Comparison

    The following tables compare the various features, protections, and attack surfaces of various browsers.

    Figure 2. Exploit mitigation features (Edge versus IE 11)

    Although IE 11 supports the EPM sandbox, by default it only uses the PM sandbox. The IE 11 rendering process is also, by default, 32-bit.

    Figure 3. Attack surfaces

    Figure 4. Exploit mitigation features (major browsers)

    Summary

    Microsoft Edge represents a clear improvement compared to Internet Explorer 11. Specifically, the improved sandbox and exploit mitigation techniques make exploiting Edge more difficult than its predecessor. In addition, the dropping of unused legacy features reduces the possible attack vectors into the browser.

    Overall, we believe that Edge has reached a security parity with the Google Chrome browser, with both markedly superior to Mozilla Firefox. However, multiple attack surfaces still remain which can be used by an attacker. Given the sophistication and demands on modern browsers, this may well be inevitable.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    We have discovered a vulnerability in Android that can render a phone apparently dead – silent, unable to make calls, with a lifeless screen. This vulnerability is present from Android 4.3 (Jelly Bean) up to the current version, Android 5.1.1 (Lollipop). Combined, these versions account for more than half of Android devices in use today. No patch has been issued in the Android Open Source Project (AOSP) code by the Android Engineering Team to fix this vulnerability since we reported it in late May.

    This vulnerability can be exploited in two ways: either via a malicious app installed on the device, or through a specially-crafted web site. The first technique can cause long-term effects to the device: an app with an embedded MKV file that registers itself to auto-start whenever the device boots would case the OS to crash every time it is turned on.

    In some ways, this vulnerability is similar to the recently discovered Stagefright vulnerability. Both vulnerabilities are triggered when Android handles media files, although the way these files reach the user differs.

    Vulnerability Description

    The vulnerability lies in the mediaserver service, which is used by Android to index media files that are located on the Android device. This service cannot correctly process a malformed video file using the Matroska container (usually with the .mkv extension). When the process opens a malformed MKV file, the service may crash (and with it, the rest of the operating system).

    The vulnerability is caused by an integer overflow when the mediaserver service parses an MKV file. It reads memory out of buffer or writes data to NULL address when parsing audio data. The source code below – found in the frameworks/av/media/libstagefright/matroska/MatroskaExtractor.cpp file – shows the vulnerability in detail:

    865 size_t offset = 1;
    866 size_t len1 = 0;
    867 while (offset < codecPrivateSize && codecPrivate[offset] == 0xff) {//codecPrivate is controlled by the mkv file
    868 len1 += 0xff;
    869 ++offset;
    870 }
    871 if (offset >= codecPrivateSize) {
    872 return ERROR_MALFORMED;
    873 }
    874 len1 += codecPrivate[offset++];
    875
    876 size_t len2 = 0;
    877 while (offset < codecPrivateSize && codecPrivate[offset] == 0xff) {
    878 len2 += 0xff;
    879 ++offset;
    880 }
    881 if (offset >= codecPrivateSize) {
    882 return ERROR_MALFORMED;
    883 }
    884 len2 += codecPrivate[offset++];
    885
    886 if (codecPrivateSize < offset + len1 + len2) {//len1 or len2 maybe 0xffffffff, then integer overflow happened
    887 return ERROR_MALFORMED;
    888 }
    889
    890 if (codecPrivate[offset] != 0x01) {
    891 return ERROR_MALFORMED;
    892 }
    893 meta->setData(kKeyVorbisInfo, 0, &codecPrivate[offset], len1);//crash in here

    Proof Of Concept

    We created a proof-of-concept app that includes a malformed MKV file (res/raw/crash.mkv) to demonstrate how this attack functions. Once the app is started, the mediaserver service will keep crashing.

    Figure 1. The mediaserver service continuously restarting after the exploit is triggered

    This wil cause the device to become totally silent and non-responsive. This means that:

    • No ring tone, text tone, or notification sounds can be heard. The user will have have no idea of an incoming call/message, and cannot even accept a call. Neither party will hear each other.
    • The UI may become very slow to respond, or completely non-responsive. If the phone is locked, it cannot be unlocked.

    Figure 2. Unresponsive phone

    The video below demonstrates the exploitation through a malicious app.

    As for exploitation through the specially-crafted URL, we’ve created a test website with the same MKV file embedded into an HTML page. When this site is loaded using the Chrome browser, we see the same effect:

    Figure 3. HTML code of test page

    What’s more, although mobile Chrome disables preload and autoplay of videos, the malformed MKV still causes the Chrome to read more than 16MB until mediaserver crashes. It appears to have bypassed the limitation.

    Potential threat scenarios

    As we mentioned above, there are two ways that this attack can be exploited: the user can either visit a malicious site or download a malicious app.

    There are many common techniques that could be used to lure a user to a malicious site. We’ve discussed in the past how repackaged apps pose a problem for users who may have a hard time differentiating legitimate apps from repackaged ones.

    Whatever means is used to lure in users, the likely payload is the same. Ransomware is likely to use this vulnerability as a new “threat” for users: in addition to encrypting on the device being encrypted, the device itself would be locked out and unable to be used. This would increase the problems the user faces and make them more likely to pay any ransom.

    Further research into Android – especially the mediaserver service – may find other vulnerabilities that could have more serious consequences to users, including remote code execution. One of them is Stagefright, a recently discovered vulnerability which can infect Android devices using just one MMS.

    We reported this vulnerability privately to Google and received responses on the following dates:

    • May 15 – Trend Micro reported the vulnerability to Google
    • May 20 – Google acknowledged the report as a low priority vulnerability identified it as ANDROID-21296336

    For ransomware and other apps that may disrupt the functionality of mobile devices, users can opt to reboot their device in “safe mode,” which is similar to the safe mode found in Windows. Safe mode allows users to start up their device without loading any third-party apps. Booting in safe mode should allow users to access the list of installed apps and remove the malicious app. Booting in safe mode may vary per device so we advise users to consult their device or network provider before proceeding.

    Protect your Android devices with on-device security solutions like Trend Micro Mobile Security (TMMS) to block threats like these. TMMS watches out for vulnerabilities that can be used to alter system functions like the notification sounds and display.

    Find out more mobile stories and graphics in our Mobile Threat Intelligence Center.

    Updated on July 30, 2015, 7:54 A.M. PDT (UTC-7) to include more solutions addressing ransomware and other disruptive apps.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    A recent campaign compromised Taiwan and Hong Kong sites to deliver Flash exploits related to Hacking Team and eventually download PoisonIvy and other payloads in user systems. This campaign started on July 9, a few days after the Hacking Team announced it was hacked.

    The actors compromised the sites of a local television network, educational organizations, a religious institute, and a known political party in Taiwan; and a popular news site in Hong Kong. Note that the affected sites have consistent followers given the nature of their content. The affected educational organizations, for instance, are used to deliver employment exams for government employees. The Taiwanese television network involved has been producing and importing TV shows and movies for a decade.

    We have notified the owners of the sites that are affected by the campaign; however, three sites are still compromised as of this writing.

    Traces of Hacking Team Still Out There

    The actors initially delivered a Flash Player exploit  (CVE-2015-5119) found in the Hacking Team dump into pre-compromised sites a few days after the company announced it was hacked (July 5) and Adobe patched the flaw (July 7). The actors delivered a second wave of attack by delivering another Flash zero-day exploit (CVE-2015-5122) related to the Hacking Team.

    Figure 1. Timeline of Flash exploits related to Hacking Team delivered to Taiwan and Hong Kong sites

    Note that, at the start of the first and second wave of attacks, the actors included the same two educational organizations’ websites in Taiwan among its targets.

    Figure 2. Screenshot of a religious organization’s site in Taiwan compromised to deliver CVE-2015-5122

    PoisonIvy and Other Payloads

    We found that all the compromised sites, save for the official site of a known Taiwanese political party, were injected with a malicious SWF using iframe which leads to the remote access tool (RAT) PoisonIvy, detected here as BKDR_POISON.TUFW,  as the final payload. PoisonIvy is a popular RAT backdoor available in the underground market and typically used in targeted attacks. This backdoor has been known to capture screenshots, webcam images, and audio; log keystrokes and active window; delete, search, and upload files; and perform other intrusive routines.

    The party’s site, on the other hand, has been observed to deliver a different payload embedded in a picture and detected as TROJ_JPGEMBED.F. The party’s site sends collected information to the same server as the other sites (223[.]27[.]43[.]32), leading us to believe that it is part of the same campaign.

    Figure 3. Photo where a final payload of Hacking Team Flash exploit campaign is embedded

    Although analysis is still ongoing to determine if this campaign is a targeted attack, we have found a suspicious domain wut[.]mophecfbr[.]com embedded in the payload which was listed in the command-and-control (C&C) list of a previously reported targeted attack dubbed “Tomato Garden.”

    Recommendations

    To protect machines from exploits and unwanted backdoor access, users should update Adobe Flash Player. You can verify if you’re using the latest version by checking the Adobe Flash Player page. It also helps to keep yourself updated with the latest news on popular software. Read more about recent Flash-related incidents and what users and companies can do on our blog post, “The Adobe Flash Conundrum: Old Habits Die Hard.”

    Trend Micro detects all malware and exploits related to this incident. The SHA1s are outlined below:

    • SWF_CVE20155122.A
      d4966a9e46f9c1e14422015b7e89d53a462fbd65
    • SWF_CVE20155122.B
      fdcdf30a90fa22ae8a095e99d80143df1cc71194
    • SWF_CVE20155122.C
      9209fee58a2149c706f71fb3c88fef14b585c717
    • BKDR_POISON.TUFW
      2dc1deb5b52133d0a33c9d18144ba8759fe43b66

    Timeline of posts related to the Hacking Team

    DATE UPDATE
    July 5 The Italian company Hacking Team was hacked, with more than 400GB of confidential company data made available to the public.
    July 7

    Three exploits – two for Flash Player and one for the Windows kernel—were initially found in the information dump. One of these [CVE-2015-5119] was a Flash zero-day.

    The Windows kernel vulnerability (CVE-2015-2387) existed in the open type font manager module (ATMFD.dll) and can be exploited to bypass the sandbox mitigation mechanism.

    The Flash zero-day exploit (CVE-2015-5119) was added into the Angler Exploit Kit and Nuclear Exploit Pack. It was also used in limited attacks in Korea and Japan.

    July 11 Two new Flash zero-day vulnerabilities, CVE-2015-5122 and CVE-2015-5123, were found in the hacking team dump.
    July 13 Further analysis of the hacking team dump revealed that the company used UEFI BIOS rootkit to keep their Remote Control System (RCS) agent installed in their targets’ systems.
    July 14 A new zero-day vulnerability (CVE-2015-2425) was found in Internet Explorer.
    July 16 On the mobile front, a fake news app designed to bypass Google Play was discovered.
    July 20 A new zero-day vulnerability (CVE-2015-2426) was found in Windows, which Microsoft fixed in an out-of-band patch.
    July 21 Analysis of the RCSAndroid spying tool revealed that Hacking Team can listen to calls and roots devices to get in.
    July 28 A recent campaign compromised Taiwan and Hong Kong sites to deliver Flash exploits related to Hacking Team.
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  



     

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