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

Late last week, I read a SearchSecurity.com blog that quoted Caleb Sima as saying, “…developers shouldn’t learn anything about security. It’s not their job.” I felt compelled to write about the piece, not to support or condemn that statement, but rather to encourage people to think about the bigger picture. 

You see, there are a variety of factors that play into what a security program should contain, and every organization is completely different. Security requirements can be influenced by whether a company is public or private, its vertical markets and even its size, among other things. They can also be impacted by the organization’s level of security awareness.  As a result, some companies may have IT departments that include one security-focused resource; others may have entire departments with multiple resources, while some don’t have any security experts on staff at all. This disparity makes it almost impossible to come up with a one-size-fits-all, cookie cutter approach to information security.

So, rather than focus on the development process, which is clearly just one aspect of security, each company really needs to think about how its overall security program should look when it’s mature. The underlying goal is always to define and develop a program that protects the confidentiality, integrity and availability of information assets. This requires taking the appropriate steps to evaluate the organization’s current risk landscape as well as the risk-reducing potential of available solutions.

Using this risk-based approach, companies will be able to see where they fall short when it comes to compliance, including for regulations and standards such as HIPAA, GLBA, and PCI, and mitigate gaps. Organizations will also be better equipped to address their unique risks with measures that are logical, efficient and cost-effective. Furthermore, companies will be in a position to effectively test the integrity of their existing security program so they can see where their current measures are sufficient and where they are not, and then weigh their priorities based on need.

It is not news to anybody that threats are present in every environment and, regardless of the existence of an information security program, incidents can and do occur. However, organizations that invest time and effort into implementing coherent information security practices reduce both the likelihood (probability) and scope of the episode. This translates into an enormous business impact. Failing to entrust data can be very costly, including the direct expenses associated with detecting, halting and repairing compromised systems, as well as the tangential expenses tied to attempting to restore a ruined reputation. There also are penalties for violating state and federal privacy laws under the principles of unfair or deceptive trade practices, and the inherent loss of productivity, which can result in tens of thousands of dollars a day based on loss of email usage alone. The implications – both financial and operational – skyrocket when malware spreads to other aspects of the computing environment such as servers, workstation operating systems, and file shares.

Think about it. Can your organization really afford to focus only on one piece of the puzzle?

Doug Landoll, CISSP, CISA, MBA
Practice Director – Risk & Compliance Management

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