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


  • Recent Posts

  • Calendar

    April 2015
    S M T W T F S
    « Mar    
     1234
    567891011
    12131415161718
    19202122232425
    2627282930  
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Ziv Chang (Director, Cyber Safety Solution)




    The security of an enterprise is not only dependent on the organization itself, but also on the security of their IT supply chain and contractors. These represent potential weak points into the security of any organization.

    Third-party contractors and suppliers have been used to compromise larger organizations. Target’s breach began with a breach of a contractor involved in heating, ventilation, and air conditioning (HVAC) solutions.  A 2011 hack on Lockheed Martin was blamed in part on information stolen from a hack on RSA that compromised SecureID tokens. HAVEX has been tied to attacks on Industrial Control Systems (ICS).

    These reported cases are only the tip of the iceberg. Many supply chain vendors have insufficient personnel or resources to dedicate to security; they may have no good ways to determine if they have been the victims of a targeted attack.

    Twists and Turns

    The threat actors who would target parts of the IT supply chain use various “twists and turns” as part of their Tactics, Techniques and Procedures (TTP). These can include:

    • Compromising source code
      • If hackers can access and modify the source code of a vendor, they can easily insert a backdoor into the source code. This would provide easy access to any customers of that vendor via persistent backdoors. This can be done via compromising servers holding source code, systems used for research and development, or acquiring credentials to source control services in use. The HAVEX malware family (known externally as Dragonfly/Energetic Bear) is known to have used Trojanized versions of ICS software.
      • While such an attack would be of immense value, multiple systems and accounts would need to be compromised. For example, credentials for source code control systems should be separate from other credentials (like email). Alternately, the servers themselves may be attacked (whether these are located on premise or in the cloud). This kind of access would require a fairly wide-ranging breach of the target organization.
    • Compromising firmware
      • If attackers are able to access and modify the binary code of systems provided by a vendor, an attacker may choose to modify the code to add backdoors, which can then be pushed out via existing autoupdate mechanisms. Customers will receive this malicious code when the update is pushed out to their systems. The Equation Group is believed to have used malicious hard drive firmware in their attacks.
      • The challenges to compromising firmware would be similar to compromising source code, with an additional problem to consider: technical information would be necessary to actually create firmware that would actually run on target devices. This would have to be acquired within the organization itself, or by analysis of existing publicly available hardware.
    • Compromising websites and internal portals
      • Attackers can also attempt to compromise websites and internal portals used by a vendor to communicate with their customers. This can be used in a watering hole attack against the vendor’s customers. HAVEX also used this tactic to target organizations using specialized ICS/SCADA equipment.
      • For this attack to be successful, the attacker must be able to gather some information about the normal browsing patterns of both the vendor and the customer. In addition, to actually compromise any web servers, credentials for webmasters or server administrators need to be obtained as well. This poses some burdens on an attacker to be familiar with the vendor’s network, but not as difficult as the two preceding scenarios.
    • Spear phishing from trusted vendor email accounts
      • An attacker that controls vendor systems and credentials can easily send emails to clients that appears to be legitimate. High-level personnel can be easily victimized in this manner.
    • Direct network access from trusted vendors
      • A vendor’s access to their client’s network can also be abused. For example, if a vendor has access to a client network via VPN, an attack at the vendor could compromise the credentials needed to access the VPN. Similarly, secure tunnels could be accessed via compromised credentials.

    An attacker would enter the IT supply chain as he would any other organization. We’d earlier discussed how organizations become the victim of targeted attacks. Email is still a favored infection vector, with both malicious attachments and links to sites used to lure in users. These messages are made to appear to come from other organizations (which are preferably relevant to the target).

    Potential Solutions

    Some might say that the security of vendors is not part of the responsibilities of a network administrator, who already has to worry about their organization’s security. While this may be true, the security of vendors has a direct impact on an organization’s security. Here are some guidelines that can be used:

    • Protect your own network
      • Does your own organization already have sufficient defenses against targeted attacks? Are sensors and an incident response team in place to mitigate any attacks? Are security solutions in place on both endpoints and gateways? Before an organization can even consider discussing security issues with vendors, they must be sure that their own house is in order.
    • Coordinate security policies
      • As much as possible, vendors and clients should have reasonably similar security policies. Inconsistent policies can create security weaknesses in one organization that can be used for lateral movements to the other.
    • Code, binary, and firmware auditing
      • Patching and updating procedures should be examined to ensure that proper auditing is performed before new software/hardware is introduced into an organization. Source code audits can find hidden backdoors, hardcoded credentials, and other potential vulnerabilities. Binary audits can check file hashes to ensure that only unmodified versions of software are installed.
    • Coordinate security teams
      • Security resources of vendors and clients should work together to protect their overlapping networks. Sharing of threat intelligence and regular meetings can ensure that any potential threats are dealt with adequately and as quickly as possible.

    We’ve earlier discussed how companies need to focus on protecting what is most important to them – their core data – and do so in a well-thought out manner. An aspect of data protection that can be overlooked is how others access your data. If an organization fails to consider that, then their data protection is only as good as the weakest link. A complete security and privacy risk assessment must consider the security of an organization’s third-party IT providers.

    Aside from the above, vendors should undertake steps to protect their own systems. Products such as the InterScan™ Messaging Security software and virtual appliance, Hosted Email Security, and ScanMail™ for Microsoft Exchange™ are all designed with the technology designed to help detect threats that enter via email. Combined with Web reputation and advanced sandboxes to inspect attachments, these tools are able to help detect various threats that attempt to enter an organization’s network. Solutions such as Deep Discovery can also be used as part of a custom defense strategy to help organizations discover and mitigate attacks as well.

     
    Posted in Targeted Attacks |



    I do not exaggerate when I say that it is only a matter of time before your company has to deal with a targeted attack, if it has not yet. In 2014, we saw many victims grapple with an invisible enemy. A very big and recent example of this is the Sony attack which caused a lot of problems from the company, as well as the leakage of a lot of data. As threat defense experts, we strive to make the invisible visible: what are the most important things you should have learned from the cyber-attacks in 2014? What lessons can we bring into 2015?

    Secure your data in the cloud

    lessons2

    Accountability for cloud computing security became very clear in 2014. Cloud computing is a powerful capacity extender that is increasingly adopted by small, medium, and very large enterprises alike. And while users can expect a certain level of security under the “shared responsibility” model — such as in the way cloud service providers run cloud services and infrastructure including physical hardware and facilities — users must not forget that access to data in the cloud can be wholly compromised at their end.

    In what turned out to be a prevalent “developer bad habit” discovered in March, for instance, thousands of secret keys to private accounts were found to be accessible in GitHub, a code-sharing site. This is the equivalent of having consumer user names and passwords leaked in public forums. In some ways this is even more critical, since the exposure of the keys mean that thousands of secret company documents, applications, software can be accessed by threat actors. And since the intruder will essentially log in as the developer, he/she can wipe out entire environments or hold them hostage.

    In a much more fatal example, Code Spaces had to close down in 2014 after an attacker gained access to its control panel account and started deleting customer databases indiscriminately. For a business whose nature relies so strongly on software services, “paranoid security” should be a foregone conclusion. Cloud services have two- or multi-factor authentication options, completely private modes, or identity-/role-based management that can greatly reduce or make intrusions like this much more difficult for attackers.

    Read the rest of this entry »

     
    Posted in Targeted Attacks | Comments Off



    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
     
    Posted in Vulnerabilities | Comments Off



    Earlier today, Google researchers Bodo Möller, Thai Duong, and Krzysztof Kotowicz released a paper discussing a serious bug in SSL 3.0 that allows attackers to conduct man-in-the-middle attacks and decrypt the traffic between Web servers and end users.

    For example, if you’re shopping online with your credit card, you may think that your information is secure but thanks to this bug (known as POODLE) it may actually be at risk. An attacker can hijack your transaction, retrieve your credit card information, or even change your order.

    The bullet points below summarize some key points of this vulnerability:

    • CVE ID: CVE-2014-3566
    • Popular name: POODLE (Padding Oracle On Downgraded Legacy Encryption)
    • Vulnerabilty: SSL 3.0 fallback bug
    • Attack vector: Man-in-the-middle

    How does the POODLE attack work?

    According the paper, the key issue is the integrity of the padding on SSL 3.0 block ciphers. This padding is not verified by the protocol. This will allow an attacker to alter the final block of the SSL cipher if the hacker can successfully hijack the connection from an end user to the Web server. This can lead to the attacker being able to successfully decrypt any encrypted traffic that they are able to capture.

    SSL 3.0 is an older encryption protocol that has been around for 15 years. It has been succeeded by TLS (which is now at version 1.2). However, TLS clients and servers will downgrade to earlier versions of the protocol if one side of the transaction does not support the latest version.

    Consider the example below. The browser supports version of TLS up to 1.2. In the first handshake, the browser uses the highest protocol version (TLS 1.2) that it supports. If that handshake fails, the browser will retry with earlier versions (TLS 1.1, then TLS 1.0). The attacker then will make it so the browser will downgrade versions up to SSL 3.0, at which point the POODLE vulnerability can then be exploited to decrypt any communications between the two parties.

    Sniffer 2-01

    Figure 1:  Attackers may force the communication between a client and server to downgrade from TLS to SSL 3.0 to be able to decrypt the network communication

    Countermeasures

    This vulnerability can be avoided if the SSL 3.0 protocol is disabled. Site administrators can disable support for this on their side; for example these instructions show how to do this in Apache.

    End users can disable SSL 3.0 support on their end as well, through the following steps:

    • For Chrome users, running Chrome with the command Chrome.exe  –ssl-version-min=tls1 will specify that the minimum version of SSL that will be used is TLS 1.0.
    • In Firefox, type about:config in the search bar to change settings. Search for the keyword security.tls.version.min and set the value to 1 to disable SSL 3.0 support.
    • Internet Explorer users can follow the steps in Security Advisory 3009008 to disable SSL 3.0

    For enterprises they can do server patch via the following steps:

    Note, however, that disabling SSL3.0 is not a practical step for all users, especially since it can still be needed to work with legacy systems. The security advisory from OpenSSL.org recommended the usage of TLS_FALLBACK_SCSV mechanism to web servers, to ensure that SSL 3.0 is used only when necessary (when a legacy implementation is involved). This way, attackers can no longer force a protocol downgrade.

    We will continue to proactively monitor for threats that use this vulnerability and provide updates and solutions as necessary.

    Update as of 1:48 PM, October 15, 2014

    Trend Micro Deep Security customers are protected from attacks that may leverage POODLE vulnerability via the following DPI rules:

    • 1006293 – Detected SSLv3 Request
    • 1006296 – Detected SSLv3 Response
     



    When it comes to targeted attacks, attackers are not omniscient. They need to gather information in the early stages to know the target they may gather information from various sources of intelligence, like Google, Whois, Twitter, and Facebook. They may gather data such as email addresses, IP ranges, and contact lists. These will then be used as lure for phishing emails, which inevitably result in gaining access in the targeted organization’s network.

    Once inside, the attackers will begin the lateral movement stage. In this stage, attackers will perform port scans, services scans, network topology mapping, password sniffing, keylogging, and security policy penetration tests. The goal is to find more confidential information and find a stealthy method of access.

    The lateral movement allows the attackers information they can then use to their advantage. They are now aware of existing security weak points, firewall rule setting flaws, and the wrong security equipment deployment. They also now have the latest network topology, password sets, and security policies.

    They can use this newfound knowledge even after their attempts have been discovered. Often times, efforts to thwart existing and prevent new attacks involve removing the malware and monitoring for network activity. But since attackers are aware of the topology, they can try new ways to gain access easily without being noticed.

    Earlier, we posted an entry detailing how IT administrators can protect enterprises from targeted attacks and breaches via looking at their network vulnerabilities.  In this blog post, we want to tackle how network topology can aid in defending the enterprise network from risks pose by targeted attacks.

    Changing the Network Topology

    It’s not enough to change passwords and remove the malware. To protect an organization from targeted attacks, changing the network topology should also be considered.

    Network topology refers to how devices are connected within a network, both physically and logically. The term refers to all devices connected to a network, be it the computers, the routers, or the servers. Since it also refers to how these devices are connected, network topology also includes passwords, security policies, and the like.

    If the targeted organization changes the network topology, the attackers’ gained knowledge will become useless to their attacks. If the threat actors attempt to enter the network using the old method, it will be flagged by the new(er) security policies put in place. Changes like moving the “location” of the target data or moving segments will require a longer period of time for attackers to find the targeted data. This length of time can prove invaluable as it can give admins more time to detect the malicious activity before any real damage can be done.

    Read the rest of this entry »

     
    Posted in Targeted Attacks | Comments Off


     

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