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

  • Recent Posts

  • Calendar

    December 2014
    S M T W T F S
    « Nov    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • Email Subscription

  • About Us

    We have discovered a vulnerability in Android that affects how cross-signed certificates are handled. No current Android release correctly handles these certificates, which are created when two certificates are signed with a looped certificate chain (certificate A signs certificate B; certificate B signs certificate A). We’ve already notified Google about this vulnerability, and there is no fix and no timeframe for a fix from them.

    When a specially-constructed malformed certificate is introduced into an Android device (either by a new app being installed or by importing a certificate), the system may behave in unexpected ways. It may either slow down or hang the device until it is forced to reboot.

    Vulnerability Description

    The vulnerability is caused by two common used classes in the Android framework – the JarFile and KeyStore classes. Any Android features implicitly or explicitly using the either of two classes may be at the risk to be attacked by cross-signed certificates.

    • Android commonly used class JarUtils (./libcore/luni/src/main/java/org/apache/harmony/security/utils/JarUtils.java) – These may be used by the JarFile class. It is used to verify a jar package’s certificates and signature files. Unfortunately, the JarUtils class cannot properly deal with a loop certificate chain and falls into endless loop. The problem happens in all Android versions.
    • Android external KeyStore providers’ classes (Such as ./external/bouncycastle/src/main/java/org/bouncycastle/jce/provider/JDKPKCS12KeyStore.java) – These are used to process PKCS#12 file for the Android KeyStore. If the PKCS#12 file contains a loop certificate chain, the processing in the codes will also fall into endless loop.

    Proof of Concept

    We will demonstrate this vulnerability with two different scenarios. In one scenario, a specially crafted app is installed onto the device. In the other, a specially crafted keychain is imported.

    By manipulating the signing process using different certificate signing requests, we can easily generate a pair of cross-signed certificates: A.cert whose issuer is B.cert, and B.cert whose issuer is A.cert.

    In scenario #1, we will install a new app signed by one of the above certificates. We create a new app called LoopCertsChain, signed by A.cert, and try to install it onto an Android device. (The screenshots below are on a device with Android 4.1.2, although versions up to 4.4 are affected.) We get the following UI, which never ends.

    Figure 1. Attempting to install app

    Upon closer examination, we find a key process (system_server) in Android keeps using up system resources until it is killed, which triggers a device reboot. The user has no choice in the matter.

    Figure 2. system_server process consuming more resources

    In the second scenario, we import a malformed PKCS#12 file with a loop certificate chain into Android.

    Figure 3. Keychain being imported

    The corresponding Android process com.android.certinstaller also falls into a loop until it is killed.

    Figure 4. com.android.certinstaller process consuming more resources

    This vulnerability does not have any direct security implications at this time. However, it is possible that future research may reveal that further problems exist in these portions of Android that may have more direct consequences, such as running arbitary code.

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

    We noticed that there has been a spike in infections related to the malware URSNIF. The URSNIF family is known to steal information such as passwords. Spyware are always considered high risk, but these URSNIF variants can cause damage beyond info-stealing. These URSNIF variants are file-infectorswhich is the cause of the noted spike in detection counts.

    Infection Data

    Based on feedback from the Smart Protection Network, the countries most affected are the United States and the United Kingdom. These two countries comprise nearly 75% of all the infections related to these URSNIF variants. Canada and Turkey are the next countries most affected.


    Figure 1. Countries affected by URSNIF spike, based on data gathered for December 2014 so far

    Additional feedback shows that education, financial, and manufacturing were among the industries affected by this spike.

    URSNIF, the File Infector

    Normal PE infectors use the host file to execute its code or execute its code before executing the host’s file code. It patches the host files by inserting malicious code through techniques like cavity, appending, pre-pending viruses, or entry point obfuscation. However, this URSNIF variant, detected as PE_URSNIF.A-O, seems to insert the host file into its resource section.


    Figure 3. Embedded .PDF file in URSNIF’s resource section

    It infects .PDF, .EXE, and .MSI files found in all removable drives and network drives. URSNIF packs the found files and embeds them to its resource section.  When these infected files are executed, they will drop the original file in %User Temp% (~{random}.tmp.pdf, ~{random}.tmp.exe) and then execute it to trick the user that the opened file is still fine.


    Figure 3. Visual representation of infection chains for .PDF, .EXE, and .MSI files

    After deleting the original .PDF file, it will create an .EXE file using the file name of the original .PDF file. As for .MSI and .EXE files, it will insert its code to the current executable. It will only infect .EXE files with “setup” on its filename.


    Figure 3. Difference between an infected (top) and clean (bottom) .PDF file. The infected file is 3.18 MB while the clean file is 2.89 MB.

    For MSI files, they will execute the original file first before executing the malware code. For .PDF and .EXE files, they will produce a dropper-like Trojan, which will drop and execute the original file and the main file infector.

    Expansion of Routines

    The malware family URSNIF is more known as a spyware. Variants can monitor network traffic by hooking network APIs related to top browsers such as Internet Explorer, Google Chrome, and Mozilla Firefox. It is also known for gathering information. However, the fact that a family known for spyware now includes file infectors shows that cybercriminals are not above tweaking established malware to expand its routines.

    The expansion into file infection can also be seen as a strategic one. A different file infector type (e.g., appending) requires a different detection for security solutions; not all solution may have this detection. Another notable feature for this particular malware is that it starts its infection routine 30 minutes after its execution. This could be viewed as an anti-sandboxing technique as most sandbox tools monitor malware for about two to five minutes only.

    Countermeasures

    Users should then be vigilant about protecting their devices against threats, including URSNIF. Paying attention to the little details can actually help, as we can see in the comparison of the .PDF files above.

    As this variant can spread via removable drives and network shares, users must also exercise additional safety measures. Users should never plug removable drives into unknown computers or computers that aren’t protected by some form of security solution. IT admins should also properly configure network shares. For example, computers shouldn’t be given blanket access within the network. Network access can also be configured to read only, not read-write.

    Users should also rely on security solutions that are able to keep up with the ever dynamic threat landscape. URSNIF variants often arrive via spammed messages and Trojan dropper/downloader malware. Users need a comprehensive security solution that goes beyond detecting and blocking malware. Features like email reputation services which can detect and block spam and other email-related threats can greatly boost a computer’s security.

    Trend Micro detects infected .PDF and .EXE files as PE_URSNIF.A2. Infected .MSI files are detected as PE_URSNIF.A1.

    Hash of the related file:

    • dd7d3b9ea965af9be6995e823ed863be5f3660e5
    • 44B7A1555D6EF109555CCE88F2A954CAFE56B0B4
    • EFC5C6DCDFC189742A08B25D8842074C16D44951
    • FD3EB9A01B209572F903981675F9CF9402181CA1
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Last week we wrote about a sudden hike in crypto-ransomware variants across the Europe, the Middle East and Africa (EMEA) region, specifically seen in Spain, France, Turkey, Italy, and the United Kingdom. In this blog post we will discuss another strain of ransomware known as REVETON, which was seen infecting systems in the United States with a new infection method: arriving as a .DLL versus the traditional .EXE.

    REVETON Making a Comeback (Yet Again) 

    Over the past few months spanning October up to the last weeks of November, we observed a noticeable increase in REVETON malware variants, in particular, TROJ_REVETON.SM4 and TROJ_REVETON.SM6.

    Earlier this year, we reported a sudden wave in malware in the form of mobile ransomware, which appeared to originate from the same Reveton cybercriminal group. Some groups may have expanded their efforts into creating new infection methods as seen in the recent increase and expansion to other regions.

    The fact that REVETON is making a comeback (again) is a bit surprising, considering that crypto-ransomware has become the dominant ransomware strain in the landscape. REVETON and other PC-locking ransomware often rely on social engineering in order to convince users that they need to pay a fee.

    Old Tactics, But New Infection Methods for REVETON

    Similar to older REVETON or police ransomware variants, the recent wave of REVETON malware variants detected as TROJ_REVETON.SM4 and TROJ_REVETON.SM6 are both equipped with the capability to lock the screen of the affected users’ systems.

    Its behavior rings similar to previous REVETON variants, which threaten users that they need to pay their local police a fine. In these new samples, the REVETON malware displays “warning” messages from the Homeland Security National Cyber Security Division and the ICE Cyber Crime Center informing users that their computer has been blocked for the reason that “the work of your (the user’s) computer has been suspended on the grounds of unauthorized cyber activity.”

    Below is the warning message along with a MoneyPak form to transfer the payment of $300 USD. The message also warns users that they have only 48 hours to pay the fine.


    Figure 1. Fake warning messages from Homeland Security and the ICE Cyber Crime Center

    (more…)

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

    Patches to fix the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability in SSL first discussed in October have been gradually put in place since its discovery. We’ve recently uncovered that some transport layer security (TLS) implementations may be vulnerable to a variant of the same POODLE attack. This means that secure connections protected via TLS can, in certain conditions, be vulnerable to man-in-the-middle (MITM) attacks, leading to encrypted traffic being decrypted by an attacker.

    How Does POODLE Affect TLS?

    The original POODLE bug was a flaw in how SSL 3.0 processed the padded data if a cipher was used in cipher-block chaining (CBC) mode. Later protocols (TLS 1.0 up to 1.2) were not thought to be vulnerable to this issue.

    However, in some cases, POODLE-like attacks can be mounted against TLS protocols as well, if code is reused by the implementations. Adam Langley, a security expert working for Google, noted on his blog that:

    This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken. An IETF draft to prohibit RC4 is in Last Call at the moment but it would be wrong to believe that RC4 is uniquely bad. While RC4 is fundamentally broken and no implementation can save it, attacks against MtE-CBC ciphers have repeatedly been shown to be far more practical. Thankfully, TLS 1.2 support is about to hit 50% at the time of writing.

    How Can This New POODLE Attack Be Exploited?

    Exploiting this attack would be similar to the original POODLE attack. If an attacker is able to carry out MITM attacks, it is possible that they could be used to decode encrypted traffic and allow an attacker to read that user’s traffic. A single character can be decrypted using 256 requests to the original HTTP server; an eight-character password would require 2,048 requests.

    A CVE ID, CVE-2014-8730, has been assigned to this vulnerability. System administrators should consider modifying their TLS configurations to support more secure protocols, cipher modes, and algorithms. End users can use various online testing tools to check the security of sites that they use.

    How To Bite Back 

    There is no “patch” that can be directly applied as the vulnerability lies in the protocol, not in the implementation. Reports have confirmed that application delivery networking vendors such as F5 Networks and A10 Networks have announced that the flaw exists in some of their products, to which the vendors have already issued patches and workarounds. It is thus recommended to apply patches provided by your vendors if vulnerable.

    In addition, we advise users to apply the latest Trend Micro™ Deep Security™ update DSRU14-038. We released a rule for Deep Security users which will help detect the traffic from POODLE exploits. The rule is identified as:

    • 1006401 – Identified Too Many TLS Alert Messages In TLS Traffic
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Recent events – both in the United States and in Japan – have forced IT administrators everywhere to reevaluate the possibility of insider threats. Because of their very nature, it can be difficult to handle these problems, particularly because the mindset needed to handle them can vary.

    The insider threat can be broken down into three issues: why do people within become threats, what damage can they do, and how these can be prevented.

    Why do people become insider threats?

    It can be difficult to understand the motivation of people who are insider threats: they act against an organization that they are (or were) a part of and indirectly act against their own interests.

    One model we can use to examine motives is espionage. If not quite as severe, the basic question is similar. The motives of would-be spies are frequently described using the acronym MICE:

    • M – Money
    • I – Ideology
    • C – Coercion
    • E – Ego

    Frequently, more than one of these motives is in play. Depending on what the motivation is, the nature of the attack may also differ: for example, an insider interested primarily in monetary gain might prefer to set up a quiet way to steal (and sell) confidential or proprietary information. Someone else driven by a sense of personal grievance might do a series of attacks like defacing the company’s website or, worse, conducting information theft- in either case, they would be a more “demonstrative” attack meant to highlight that something did happen.

    What is obvious is that trying to determine what drives somebody to become a “threat” to their own organization is a complex, multi-faceted question with no single answer.

    However, employee discontent is a powerful incentive towards becoming an insider threat. Example of these include pay cuts, layoffs, or other activities that can cause otherwise placid employees to become disgruntled. If an organization is slow to remove access, former employees can still pose an “insider threat” if they still have access to the network.

    Employee discontent is just one of the possible motives behind an insider attack. Another would be ego: an employee who may have not received the response he believes he deserves (be it blame or praise) may lash out. Other insider attacks are deliberate and premeditated; these are performed by employees who join companies to specifically gather insider information.

    (more…)

     
    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