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

    We have discovered a new vulnerability that allows attackers to perform denial of service (DoS) attacks on Android’s mediaserver program. This causes a device’s system to reboot and drain all its battery life. In more a severe case, where a related malicious app is set to auto-start, the device can be trapped in an endless reboot and rendered unusable.

    The vulnerability, CVE-2015-3823, affects Android versions 4.0.1 Jelly Bean to 5.1.1 Lollipop. Around 89% of the Android users (roughly 9 in 10 Android devices active as of June 2015) are affected. However, we have yet to discover active attacks in the wild that exploit this vulnerability.

    This discovery comes hot on the heels of two other major vulnerabilities in Android’s media server component that surfaced last week. One can render devices silent while the other, Stagefright, can be used to install malware through a multimedia message.

    How it Works

    To get inside the device, attackers lure Android device owners to either install a malicious app or go to a malicious site that contains a malformed media file, which ends up in one of the following:

    • Once the malformed .MKV file is introduced into mediaserver via the app, the function will fall into an endless loop beyond the user’s control. The whole system will have to slow down until the system reboots or the battery is drained.
    • If the user is lured to a malicious site with the .MKV file, the mediaserver function will also enter an endless loop and experience the same issues once the user hits “Play.”

    The vulnerability is caused by an integer overflow in parsing .MKV files, which causes the device to fall into an endless loop when reading video frames. The related source codes are shown below:

    frameworks/av/media/libstagefright/matroska/MatroskaExtractor.cpp
    610 size_t srcOffset = 0;
    611 size_t dstOffset = 0;
    612 while (srcOffset + mNALSizeLen <= srcSize) {
    613 size_t NALsize;
    614 switch (mNALSizeLen) {//mNALSizeLen read from mkv file can be 4
    615 case 1: NALsize = srcPtr[srcOffset]; break;
    616 case 2: NALsize = U16_AT(srcPtr + srcOffset); break;
    617 case 3: NALsize = U24_AT(srcPtr + srcOffset); break;
    618 case 4: NALsize = U32_AT(srcPtr + srcOffset); break;
    619 default:
    620 TRESPASS();
    621 }
    622
    623 if (srcOffset + mNALSizeLen + NALsize > srcSize) {
    624 break;
    625 }
    626
    627 if (pass == 1) {
    628 memcpy(&dstPtr[dstOffset], “\x00\x00\x00\x01″, 4);
    629
    630 memcpy(&dstPtr[dstOffset + 4],
    631 &srcPtr[srcOffset + mNALSizeLen],
    632 NALsize);
    633 }
    634
    635 dstOffset += 4; // 0x00 00 00 01
    636 dstOffset += NALsize; //when NALsize == 0xfffffffc, endless loop
    637
    638 srcOffset += mNALSizeLen + NALsize;
    639 }

    Proof of Concept (PoC)

    We created two PoC scenarios to better understand how this flaw works, as follows:

    Scenario 1: Attack From Local Application

    The first scenario simulates a DoS attack caused by a malicious app (.APK) that uses a malformed .MKV file (filename loop.mkv).

    Figure 1. CVE-2015-3823 PoC of DoS attack using a malicious app

    The app creates a new mediaserver command every second to play the malformed .MKV file. Even if the user terminates the malicious app, the mediaserver will continue to loop until the system resource or battery is exhausted.

    Figure 2. Mediaserver exhausts CPU resource

    Scenario 2: Attack From Remote Website

    In the second scenario, the malformed .MKV file was embedded into an HTML page. Using the mobile Chrome browser, we opened the webpage and clicked “Play,” prompting the same results as the first scenario.

    Figure 3. Source code for the malformed web page

    Potential Threat Scenarios

    Similar to the Android mediaserver flaws mentioned earlier, this threat comes in using either one of these two methods: a malicious app or a malicious website. Using a malicious app, attackers can easily decide when to start or stop attacks on the device. We already know how this leads devices to reboot and drains batteries. However, in a worst case scenario, the app may be set as an auto-start service that runs every time users open their device, thus not giving them a chance to uninstall it. This endless reboot may render Android devices unusable unless the devices are opened in safe mode and the app is removed.

    Getting rid of the app is quite problematic. It may be difficult to locate the app once downloaded. Attackers may opt to keep it hidden and silent for a long time and only trigger the attack days or months later. Users may believe it is not installed and attribute the reboots to problems in the Android system. Devices with customized Android OS but have the same mediaserver program installed are also affected by this threat.

    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.

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

    Disclosure Timeline 

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

    • May 19: We reported the issue with corresponding POC to the Android Security Team.
    • May 21: The Android Security Team accepted it as a moderate severity vulnerability and assigned ANDROID-21335999 for it.
    • May 22: The Android Security Team assigned CVE-2015-3823 for it.
    • July 31: the Android Security Team confirmed a fix was available and agreed with Trend Micro on a disclosure schedule.
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Earlier this week Zimperium zLabs revealed an Android vulnerability which could be used to install malware on a device via a simple multimedia message. This vulnerability, now known as Stagefright, has gained a lot of attention for the potential attacks it can cause. Stagefright makes it possible, for example, for an attacker to install a spyware app in a targets phone without their knowledge just by sending an MMS.

    Versions of Android from 4.0.1 to 5.1.1 are affected; this represents 94.1% of all Android devices in use today.

    We independently discovered this vulnerability as well; this blog post will disclose more details about this particular flaw.

    Vulnerability analysis

    Like the previous Android vulnerability we found, this vulnerability is in the mediaserver component, which is responsible for handling open media files.

    The version of mediaserver in the vulnerable versions cannot correctly handle a malformed MP4 file. When such a MP4 file is introduced into mediaserver, it may trigger a heap overflow and overwrite data in the heap. This can lead to code execution, which may lead to an app being downloaded onto the device.

    The root cause of the vulnerability is an integer overflow when parsing an MP4 file, causing memory to be written out of the buffer. Specifically, it occurs when mediaserver it parses tx3g-flagged data; this is normally used to provide text subtitles.

    The affected code can be found in frameworks/av/media/libstagefright/MPEG4Extractor.cpp:

    1890         case FOURCC('t', 'x', '3', 'g'):
    1891         {
    1892             uint32_t type;
    1893             const void *data;
    1894             size_t size = 0;
    1895             if (!mLastTrack->meta->findData(
    1896                     kKeyTextFormatData, &type, &data, &size)) {
    1897                 size = 0;
    1898             }
    1899             //
    For example,fist time chunk_size == 0x100000,second time chunk_size == 0xFFF00001. Then 0x100000 + 0xFFF00001 = 1, allocate 1 byte indeed.
    1900             uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];
    1901             if (buffer == NULL) {
    1902                 return ERROR_MALFORMED;
    1903             }
    1904
    1905             if (size > 0) {
    1906                 memcpy(buffer, data, size);//
    Still writes 0x100000 bytes in 1 byte buffer
    1907             }
    1908
    1909             if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))
    1910                     < chunk_size) {
    1911                 delete[] buffer;
    1912                 buffer = NULL;
    1913
    1914                 // advance read pointer so we don't end up reading this again
    1915                 *offset += chunk_size;
    1916                 return ERROR_IO;
    1917             }
    1918
    1919             mLastTrack->meta->setData(
    1920                     kKeyTextFormatData, 0, buffer, size + chunk_size);
    1921
    1922             delete[] buffer;
    1923
    1924             *offset += chunk_size;
    1925             break;
    1926         }

     

    Proof-of-concept demonstration

    We tested three scenarios which can be used to attack mediaserver. WE used the adb shell top | grep mediaserver command to the process; we can see that because mediaserver‘s PID (Process Identification Number) changed, the process crashed and restarted.

    Scenario #1: Attack from an Application

    Here, we demonstrate how this vulnerability can be exploited from within an app. The specially crafted MP4 file will cause mediaserver‘s heap to be destroyed or “exploited”. Here it only crashes, but an attacker can construct a specific data block to fill the heap and gain control of the execution flow.

    Figure 1. Debugging output of mediaserver crashes

    Scenario #2: Attack from URL

    We embedded the same malformed MP4 file (named mp4.mp4) into an HTML file as below, which is then uploaded to a web server. When using the built-in WebView in Android 5.1.1 (as used by the Twitter app) to access the website, the same problems seen in scenario #1 happen.

    Figure 2. HTML code for embedding MP4 file

    In addition, even though the mobile Chrome browser disables preloading and autoplay of videos embedded with the <video> tag, the malformed file still causes the mediaserver heap overflow. Somehow this limitation has been bypassed.

    Scenario #3: Attack from MMS messages

    This particular scenario is the one that has received a great deal of attention. We can attach this MP4 file to a MMS and send it to victim’s phone. On our test device (a Nexus 6 running Android 5.1.1), the mediaserver process crashed twice when it received the MMS. This method is particularly dangerous as it involved no user interaction: the mere act of sending the file is sufficient to target the vulnerable device.

    Figure 3. Attaching the malformed mp4 file to a MMS message

    This vulnerability is fairly potent as it can be effectively controlled by the attacker, which means he can decide when to start the attack and also when to stop. The mediaserver deals with multimedia-related tasks, such as opening and reading MP4 files, decoding/encoding an MPEG4 stream, taking a picture, record the video/audio/screen, read/write pictures and videos from/to the SD card, and so on. An attacker would be able to run their code with the same permissions that mediaserver already has as part of its normal routines.

    Users have relatively little recourse to deal with this threat.  They may not even be able to detect this threat, given that the initial compromise (the MMS message) doesn’t appear to be malicious in any way. Users can disable the autofetch of MMS content, which will mean that the user will have to open the MMS message before any attack.

    A patch has been delivered by Google, but when it will arrive to user devices depends on the device OEMs. In addition, customized Android versions that did not modify mediaserver are also at risk. We will continuously monitor for the existence of new threats that target this vulnerability.

    On-device security solutions like Trend Micro Mobile Security can add a layer of protection against threats like these as well.

    Disclosure Timeline

    We responsibly disclosed this vulnerability to Google, and this is the timeline of our exchanges with them:

    • May 19: Reported vulnerability to Android Security Team, with a proof-of-concept attack
    • May 22: Android Security Team assigned ANDROID-21336907, marked it as a High severity vulnerability.
    • May 26: Android Security Team assigned CVE-2015-3824 to the vulnerability.
    • July 28: Android Security Team confirmed a fix was available, agreed with Trend Micro on a disclosure schedule.

     

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

    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  

    This 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  



     

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