In the malware mitigation market, there are divisions among the vendors. The perspective of the vendor, detection philosophy and technology approaches are examples of the vendors’ different views.

Most legacy network security devices have developed some semblance of controls to fight malware.  Similar to the approach of traditional AV vendors, it is relatively easy for a network security device such as a content-aware firewall or intrusion prevention system, to stop identified malware once the vendor has developed signatures or detection mechanisms that look for known instances of malware “breeds”.  For known malware threats, this signature approach can be effective.

However, known threat detection mechanisms have been rendered less effective with the advent of the “commercial” malware market.  This quickly growing black-market offers a forum for criminal enterprises to market their own malware-creation suites. Some even offer technical support. 

These user-friendly, GUI-based software suites enable criminal-entrepreneurs to very easily create their own customized versions of malware.  Each variation created can be encrypted and packed to create a new and unique signature for each malware package.  As a result, each new malware breed requires known threat detection vendors to obtain, deconstruct and develop a new detection signature for the malware package variation in order to detect and block it. Some of the more sophisticated malware creation tools even provide a polymorphic repacking function that is executed in an automated fashion for each new victim host.  Each time a new victim host is exploited, the malware creates a unique variation to transmit to the next targeted system.

Perhaps not surprisingly, this new evolution in malware development has created multiple, unpredictable variations. It also has spawned new technologies and detection philosophies based on the behavior of the new malware and/or compromised host. 

One approach to combat malware is to use a virtual environment within a network device or host agent. This can enable the security device to determine the behavior of malware that is plucked off the network once it is allowed to run in this safe environment.  Based on the captured malware’s behavior, the source IP address is then added to a known “bad-actor” database and optional controls can be added to restrict that infected host’s network access.

Other vendors utilize a network sensor to detect malware callback or “command and control” (CnC) traffic behavior.  Once a malware-infected system is identified, steps can be taken to quarantine and decontaminate the host. The CnC traffic detection approach, however, requires accurate and timely intelligence regarding the CnC networks’ methods of communication as well as up-to-date knowledge of the active CnC networks.

Building on this, another approach to countering malware threats is to work with companies that offer malware threat intelligence services. These services can include building and maintaining databases that aggregate malware infected or suspicious IP addresses and identifying active players in malware organizations and botnet networks. Companies that provide malware threat intelligence services typically build their malware intelligence databases by infiltrating malware organizations using human intelligence efforts, performing dedicated malware reverse-engineering research, utilizing “honey-pot” networks (fake hosts and networks) and by forming alliances with Managed Security Service Providers.

It is safe to say that almost every organization has a vested interest in keeping their customers and end-users safe. By working with companies that provide malware threat intelligence services, an enterprise can drastically reduce the risk of an infected user inadvertently exposing sensitive personal information to a bot or malware agent that is active on the customer’s system. It can also integrate malware intelligence into the front-end of an application to limit access to infected hosts, or utilizing the intelligence in their log management life-cycle to notify potential compromised users before the information can be used by the criminals who control the malware agent. Numerous security vendors are beginning to utilize this type of malware specific intelligence in their products or enabling the customer to integrate this information into products.

However, another effective method is a host-based approach that can be divided into pre-incident and post-incident areas of concentration. A pre-incident approach utilizes process and tools to perform regular auditing of machines in the environment, application white listing and process behavior analysis.  A number of vendors provide software solutions that offer value in this pre-incident space.  This approach can present some challenges but overall, it looks promising provided the deploying organization uses an effective method to reduce the potential impact of this type of tool could have on the business during deployment. The post-incident approach utilizes investigative or forensic examination of infected machines to determine the extent and impact of a malware incident.  This can be accomplished through the use of host examination tools that verify the existence of malware through memory analysis among other techniques.  The use of investigative and forensic tools to safely analyze infected systems is necessary to effectively determine the extent of the breach and identify the exact data compromised.  Organizations that are serious about measuring and addressing the impact of malware incidents should acquire a software suite especially tailored for the unique challenges of malware investigation or forensics.

In conclusion, the nature of the continually evolving malware threat and the criminal innovations that are taking place at a record pace require enterprises to adopt a multi-faceted approach to malware if they even hope to have a chance. Attack surface management, active controls at either the host and/or network combined with an effective investigative capability will provide organizations the toolset needed to help mitigate the impact of malware on its’ business. A countermeasure or compensating control used in isolation will likely not provide the breadth needed to cover all the possible attack vectors presented by modern malware threats.

Steve Richards
Solutions Engineer – Accuvant

Last year, during the 2009 Black Hat event in Las Vegas, two security professionals presented research about the possibility of SMS attacks across a GSM network. Since that time, the frequency of inquires from our clients about how to protect the enterprise from mobile-based attacks has increased. Although we personally have not seen mobile malware attacks “in the wild” and think mobile attacks will be a relatively low priority for attackers for this year – we do believe that the concerns about enterprise management of cell phones in the corporate environment are legitimate for a couple of reasons.

Back in the late ‘90’s, many companies standardized on BlackBerrys. This meant that network and security folks only had to worry about one mobile operating system and a single enterprise management system to control device encryption, antivirus and malware detection. But things have changed. Employees are now buying (and using) Windows Mobile, Palm, Apple, Symbian, Android and whatever other types of phones and operating systems that they want. With the various operating systems, it can be extremely difficult for companies to manage and secure all of the disparate mobile devices found in their environment.  This has made the conditions ripe for a multitude of different mobile device attacks.

For instance, hackers sometimes impersonate carriers and send SMS and MMS messages to users’ phones. The hackers provide hyperlinks and ask for account information under the guise that they’re planning to activate new services. When victims click on the links, they can download malware that can expose personal data, including emails, contact lists and calendars.  Compounding this issue is the myriad of apps folks put on their phones, which makes the probability that they willingly download an infected file much greater because their ability to determine its validity is limited.

Bluetooth, because it offers a more open delivery system, also is being leveraged to attack smartphones. For example, a hacker could walk by or stand in close proximity to unsuspecting users (somewhere within 10 to 30 meters), and use Bluetooth to send viruses or browse any unencrypted personal data. Most phones and Bluetooth headsets are configured to use a default password – and many users never change this password. This type of attack is becoming increasingly common in hot spots such as restaurants, hotels and airports.

I know … it’s all very interesting, but why should you care? The reason: viruses on mobile devices provide an often-undetectable entry point into corporate networks. As soon as employees sync their phones with their laptops or desktops, they’re introducing viruses, malware and bots back into the corporate network.

Fortunately, there are measures you can take to protect your users and your company.  For example, you can install software on corporate mobile devices that detects when someone is trying to attack using an MMS message or Bluetooth and blocks the attack automatically. There also is software that encrypts mobile device data so that the information cannot be accessed when devices are lost or stolen. And, if the enterprise standardizes on RIM-based smart phones, they can easily enforce “kill pills” – which are designed to kill all the data on mobile devices when they are lost or stolen.

However, mobile security software isn’t a silver bullet. It is important for companies to enforce policies and implement processes for employee use of phones. And, user education is one of the most valuable steps a company can take. It is their responsibility to provide users with as much protection as possible, but it’s also up to the users to know what applications they are using on corporate owned mobile devices and what they’re clicking on, along with who’s contacting them and why.

Matt Bossom 
Accuvant Program Manager – Technology Solutions

Last week, NetworkWorld published an article  under the headline “RSA 1024-bit private key encryption cracked.”  RSA encryption was one of the first widely-used asymmetric key algorithms, meaning it used two keys, one public and one private.  A message encrypted with the public key couldn’t be decrypted without the private key, the idea being that your public key would be published so that anybody could encrypt messages with your key and send them to you, and the private key is kept secret so that only you could decrypt and read those messages. 

This asymmetric encryption idea was such a huge improvement over previous shared-secret cryptosystems that it is used in everything from web browsers, where it protects sensitive transactions like online banking and shopping cart checkouts, to cryptoprocessors used in banking mainframes, embedded devices like iPhones and mp3 players, and credit-card sized smart cards like those that protect premium satellite and cable TV content.  The most common use of RSA is probably in web browsers and web servers, with an installed base of more than one billion personal computers.

Given such pervasive use of asymmetric crypto, and RSA’s algorithm in particular, news that 1024-bit private key encryption has been cracked would be alarming indeed.  Fortunately for all the online shoppers out there, this is another example of headline hyperbole.  The article outlines the findings of a paper titled “Fault-based attack of RSA authentication” that describes an attack the authors carried out on an encryption library that implements the RSA algorithm, called the OpenSSL library.  In order to perform the attack, the authors had to tamper with the power supply of the computer they were attacking, lowering the voltage just to the point where the computer would still operate, but occasionally operate incorrectly.

So, the first thing to note is that the thing that was cracked was the OpenSSL library’s version of the RSA algorithm.  The paper did not find any weaknesses in the actual RSA algorithm itself.  And the second point of interest is that the attack required physical access to the power supply of the target system.  For example, to carry out this attack on an online banking server, the attacker would need physical access to the online banking server’s power supply, which means they would need to be inside the bank’s data center.  Given the “wealth” of other targets available to an attacker standing inside of a bank’s data center, theft of the online banking web server private SSL key by a difficult and time-consuming voltage regulation attack seems rather unlikely.

These restrictions make the attack sound like something that is purely theoretical, and not useful in real life.  While it is true that online shopping and banking probably aren’t under much threat from this kind of attack, RSA and related algorithms are used in many other applications.  This kind of attack is most likely to be carried out against systems that are designed to operate in a public environment: smart grid electric meters for example, or consumer electronics devices like iPhones and game consoles – any device with a private key embedded in the hardware that could, if extracted, be used to impersonate the device or card. 

While this kind of attack is most useful against embedded devices, the paper’s author’s claim that one of their contributions with this research is demonstrating that voltage-manipulation fault injection attacks can be applied to larger devices like the microprocessors found in desktop PCs and servers.  The really strange thing about this paper is that while the researchers claim to have implemented the attack on a full-size SPARC/Linux/OpenSSL workstation, the actual hardware was a Xilinx Virtex2Pro FPGA, which was emulating a SPARC CPU, and which the researchers claim is representative of an off-the-shelf commercial embedded device. It seems as if they are trying to have it both ways – i.e. it is an attack against a full-size workstation, and by the way it also is an attack against something you might see in a typical embedded system. (What kind of embedded system would be running Linux on an emulated SPARC on an FPGA?  Maybe an embedded cryptoprocessor or something).

The attack seems to be based on causing short-lived faults in the CPU during one of the RSA signature algorithms used by OpenSSL.  Since this kind of attack has been around for a while, the OpenSSL library actually contains some code to counter it.  According to the paper, the signature is first generated with the private key rather quickly using Chinese Remainder Theorem style multiplication.  Then the signature is checked, using the public key.  If the signature is invalid, the system assumes it was attacked and goes to a slower, but supposedly more attack-resistant signature mechanism, i.e. left-to-right squaring.

According to the paper, the results of the fallback left-to-right squaring RSA signature are not checked before the signature is sent to the other party.  That is probably the bug in OpenSSL.  Because the result isn’t checked, an invalid signature is sent.  The recipient can use these invalid signatures to infer information about the private key and with enough invalid signatures and processing time, the entire private key can be broken.

While the NetworkWorld headline is an exaggeration, the paper itself could probably be summarized in the following three sentences:

1. It is possible to perform fault-based crypto attacks against microprocessor systems, at least when they are implemented in an FPGA.
2. The OpenSSL RSA signature algorithm’s fallback algorithm, left-to-right squaring, is also vulnerable to fault-injection style attacks, even though it was supposedly chosen as the fallback algorithm because of its increased resistance to such attacks.
3. The OpenSSL RSA signature algorithm apparently doesn’t check the result of the fallback algorithm prior to sending signed messages.

The paper does present an attack that might be used to jailbreak the next iPhone or Xbox, or clone satellite TV or cable cards, at least if any of those systems use a vulnerable version of OpenSSL.  However, a more accurate headline might have been “Obscure bug in OpenSSL library poses little risk to consumers.”

Phil Brass
Managing Principal Consultant – Accuvant LABS