Posts Tagged ‘hacking’

Bringing Access-Based Cache Attacks on AES to Practice

Thursday, November 25th, 2010

Personal computers are mostly used by a single person or shared between a group of users that trust each other, in cloud computing users usually do not trust each other: the owner of one process may have a great interest in the encryption keys used by a process owned by another user. Since the OS provides separate address space for each process, it may seem that the attacker has no way to steal the key. Turns out the attack may be practical.

To understand how the attack works we need to recall how memory is accessed by a program: Before requesting data from a memory chip, processor checks whether the data was recently accessed and saved in the cache. If the data is in the local cache, it can be accessed hundred times faster than otherwise. To make the implementation easier, the cache is designed in such a way that each memory location is allowed to be cached only in few places: to check that a memory location is cached, only these few places need to be checked.

Software implementations of the AES cipher commonly employ a look-up table. Which places in this table are accessed depends on which data is encrypted and which key is used. If an attacker, by accessing memory in his address space and checking how long it takes, can deduce what parts of the look-up table were accessed, he may deduce the key.

Cache-based side-channel attacks (SCA) against AES are known for a long time, what is new is the practicality of the attack:

[Our] spy process neither needs to learn the plain- or ciphertexts involved, nor their probability distributions in order [to] recover the secret key.

We describe how besides the key also the plaintext can be recovered without knowing the ciphertexts at all

We have a fully working implementation of our attack techniques against the 128-bit AES implementation of OpenSSL 0.9.8n on Linux. It is highly efficient and is able to recover keys in realtime. More precisely, it consists of two phases: in an [observation] phase, which lasts about 2.8 seconds on our test machine, about 100 encryptions have to be monitored. Then, an offline analysis phase, lasting about 3 minutes recovers the key.

Usually, implementing a counter-measure for SCA makes implementation slower, fortunately, the new processors give us a good way to prevent the attack and improve the performance simultaneously: AES Instruction Set (an extension to the x86 instruction set architecture for microprocessors from Intel and AMD) is already used by many software packages.

No Comments

Cryptographic pitfalls

Wednesday, October 27th, 2010

The field of cryptography is full of pitfalls. The same can be said about computer science in general, but in cryptography the pitfalls have a distinct character: you may never learn that you have fallen into one.

Let me give an example. Suppose you want to move N bytes starting at address A to the area starting at address B. Since every problem has a simple, fast and wrong solution, one can think that the problem can be solved by a simple loop that moves every byte number X from the first area to the second, where X goes from 0 below N. Once you try to use your program with overlapping areas, you will know that you have fallen into a pitfall: the copy will not look like a copy at all!

Let me now give a cryptographic example. Suppose you want to encrypt a message and decide to use the CTR mode. If you reuse the nonce (IV) for a different message, you compromise confidentiality of your messages, but you may never learn about this: the messages look as scrambled as they were with different nonces.

The confidentiality failure in this example is easy to show. For messages A and B and keystream X, the ciphertexts are A+X and B+X. If an attacker learns one message, he can calculate X and then the second message.

Not all cryptographic pitfalls are that easy to explain. Moreover, it seems that developers are not eager to fix the security problems unless there is a graphic depiction of the failure.

The padding oracle attack was published in 2002:

In many standards, e.g. SSL/TLS, IPSEC, WTLS, messages are first pre-formatted, then encrypted in CBC mode with a block cipher. Decryption needs to check if the format is valid. Validity of the format is easily leaked from communication protocols in a chosen ciphertext attack since the receiver usually sends an acknowledgment or an error message. This is a side channel.

In this paper we show various ways to perform an efficient side channel attack. We discuss potential applications, extensions to other padding schemes and various ways to fix the problem.

but it turns out that even in 2010 many developers continue to make the same mistakes over and over again:

we show that widely used web development frameworks and web sites are using encryption incorrectly in a way that allows attackers to read and modify data that should be protected. It has been known for years in the cryptography community that encryption is not authentication. If encrypted messages are not authenticated, data integrity cannot be guaranteed which makes systems vulnerable to practical and dangerous chosen-ciphertext attacks, one of them being the padding oracle attack presented by Vaudenay at EuroCrypt 2002

What is the proper way to solve all such cryptography misuses once and for all? One approach is to educate the developers, but the experience shows that this approach is not that effective as one may hope. Another approach is based on the observation that if you cannot educate everyone who will use your tools, it pays to make tools that are hard to misuse.

Consider the CBC mode of encryption. One of its main drawbacks is that the message must be padded to a multiple of the cipher block size. This does not only increase the ciphertext size, but also allows to check the integrity of the padding during decryption. In most cases the size increase is negligible, but the ability to &lquot;check&rquot; integrity gives a false sense of security. This misunderstanding leads to spectacular attacks.

Recently, NIST published an addendum that will probably do more to prevent the CBC misuses, than all the warnings that CBC does not provide authentication:

This addendum to [NIST Special Publication 800-38A] specifies three variants of CBC mode that accept any plaintext input whose bit length is greater than or equal to the block size, whether or not the length is a multiple of the block size. Unlike the padding methods discussed in [SP 800-38A], these variants avoid ciphertext expansion.

The new mode does not only save space, but the fact that there is no authentication becomes obvious: if you change a bit in the ciphertext, then some plaintext becomes gibberish, but the decryption function does not even notice.

No Comments

Encrypted Backup

Wednesday, October 6th, 2010

BlackberryThe information people store  securely on their mobile devices (e.g. passwords and PIN codes) not only needs to be stored confidentially, its availability must be protected as well. The confidentiality benefits if the data is not replicated. For example,  even if your password is weak, but an attacker has no access to data encrypted with the password, the password weakness does not assist him.

On the other hand, the availability benefits from replication: if you store the only copy of your data on a device and the device is broken, the data is no longer available. To harmonize the confidentiality and the availability can be a challenge that is easy to fail. Consider the recent case of the extremely popular BlackBerry device.

According to ElcomSoft CEO Vladimir Katalov: All data transmitted between a BlackBerry Enterprise Server and BlackBerry smartphones is encrypted with a highly secure AES or Triple DES algorithm. Unique private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry smartphone user. Even more, to secure information stored on BlackBerry smartphones, password authentication can be made mandatory through the policies of a BlackBerry Enterprise Server (default, password authentication is limited to ten attempts, after which the smartphone’s wiped clean with all its contents erased).

Backup encryption uses AES with a 256-bit key. So far, so good. An AES key is derived from the user-supplied password, and this is where the problem arises.

In short, standard key-derivation function, PBKDF2, is used in a very strange way, to say the least.  Where Apple has used 2,000 iterations in iOS 3.x, and 10,000 iterations in iOS 4.x, BlackBerry uses only one. Another significant shortcoming is that it’s BlackBerry Desktop Software that encrypts data, not the BlackBerry device itself. This means that the data is passed from the device to the computer in a plain, unencrypted form.

There are two problems: the small iteration counter and the exporting of unencrypted data. The main purpose of PBKDF is to slow down the bruteforce attacks by using a large iteration counter and thus by using only one iteration the protection is effectively defeated.

The second problem is probably even more severe while its effect is not that obvious. The usual network security model is that the network is insecure while the endpoints are secure. Historically this was the case, but currently the security situation on the most the most commonly used desktop OS is so bad, that an antivirus is considered a must. In the modern world a security-cautious user knows that he cannot be sure who really “0wns” his desktop, and may decide to keep his the most confidential data on a mobile device.

Apparently, the BlackBerry’s backup procedure renders this strategy ineffective – an attacker who “0wns” user’s desktop gets all the mobile device secrets as well.

No Comments

Malware Enters a New Phase – SCADA Systems Under Attack

Monday, September 27th, 2010
SCADA Systems Under Attack

SCADA Systems Under Attack

It is well known that back in days of IBM PC and MS-DOS malware was mostly created as a hobby to drive vanity of their creators, as a result it was not unusual to cause dire consequences such as formatting the hard-drive. Currently, malware is mostly created for financial gains, such as selling botnets of infected hosts for spam distribution or collection of credit card numbers, as a result it is specifically created to be as stealthy as possible. Recent events hint that we entering a new phase.

Stuxnet is the first publicly known worm to target industrial control systems, often generically referred to as SCADA systems. Not only did Stuxnet include malicious STL (Statement List) code, an assembly-like programming language, which is used to control industrial control systems, it included the first ever PLC (programmable logic controller) rootkit hiding the STL code. It also included a zero-day vulnerability to spread via USB drives, a Windows rootkit to hide its Windows binary components, and it signed its files with certificates stolen from other unrelated third-party companies. All of these characteristics are noteworthy in their own right, however when they all converge within one threat it is clear that there is a special force at work.

As a side-note: industrial systems were designed to be separate from public networks and, once this assumption turns out to be false, the security failures become inevitable.

No Comments

Letting some air out the Tire Pressure Monitoring Systems (TPMS)

Sunday, August 22nd, 2010

Flat TireIronically when a security system contains flaws, it introduces new security problems.

Tire Pressure Monitoring Systems (TPMS) have been compulsory in new automobiles in the US since 2008. The TPMS is supposed to increase car security by reporting low tire pressure. Shortly after the plan became public, the security implications were obvious.

the people who are designing these systems are putting ”zero thought into security and privacy issues.

Now it’s possible to build intelligent improvised explosive devices (IED) capable of attacking specific targets! Or mines that will only disable vehicles with certain tires, e.g. those usually encountered on humvees, while leaving legitimate, civilian traffic alone.

Of course, the implications were obvious only to “professional paranoids”. Now, once the system becomes widely deployed, its security was evaluated is a recent research paper, excerpts of which are quoted below. And while the IED comment is meant as a joke, highway robbers are well known for making drivers pull over by puncturing their car tire.  The vulnerabilities of the TPMS show that they can virtually puncture the tire of a specific car.

This paper presents a privacy and security evaluation of wireless Tire Pressure Monitoring Systems using both laboratory experiments with isolated tire pressure sensor modules and experiments with a complete vehicle system. We show that eavesdropping is easily possible at a distance of roughly 40m from a passing vehicle. Further, reverse-engineering of the underlying protocols revealed static 32 bit identifiers and that messages can be easily triggered remotely, which raises privacy concerns as vehicles can be tracked through these identifiers. Further, current protocols do not employ authentication and vehicle implementations do not perform basic input validation, thereby allowing for remote spoofing of sensor messages. We validated this experimentally by triggering tire pressure warning messages in a moving vehicle from a customized software radio attack platform located in a nearby vehicle.

at the end of only two days of sporadic experiments involving triggering the TPMS warning on and off, we managed to crash the TPMS ECU and completely disabled the service.

We attempted to reset the system by sending good packets restarting the car, driving on the highway for hours, and unplugging the car battery. None of these endeavors were successful. Eventually, a visit to a dealership recovered the system at the cost of replacing the TPMS ECU.

No Comments

More functionality = less security

Sunday, July 11th, 2010

It’s often easier to make a complex system from ready parts. Instead of providing specific functionality, the resultingBusiness conference device does a lot more than you actually need. In so far as the system manages to do what is needed, nobody should complain about the extra functionality. However the extra functionality usually has severe consequences for the device’s level of security. An interesting example of this was presented at Hack in the Box this year.

A wireless presenter – designed to allow only a couple of functions (next/previous), easily achieved with a mouse and a keyboard – can allow someone to take over your computer while you make a presentation.

No Comments