There’s good news about BadUSB

The good news about the recently-revealed BadUSB is that there actually is a cure: Atmel CryptoAuthentication. Hardware crypto engines were invented to protect software, firmware and hardware from exactly these types of attacks, among many others. These uber-tiny, ultra secure hardware devices can be easily and cost-effectively added to USB sticks (and other peripherals) by manufacturers, who are seeking to protect their customers by ensuring that only the proper and intended code is downloaded and used. Once installed into the peripherals, CryptoAuthentication devices will block the bad code. Period.

Let’s look at what Bad USB has uncovered: It is that everything with a processor is vulnerable to attack. Most people don’t really think of a USB stick, modern thermostat, home router, fax machine, PC mouse or trackpad, a camera, iPod, microwave, and other “things” as being computers; however, they are. In fact, they all have at least one processor, memory, ways to get stuff in and out, and code (firmware) that tells the processor what to do. That last piece is where the danger lies.

As any PC or smartphone user knows, code gets updated all the time to get rid of bugs and add features. Updating code opens up a processor that was previously running good code, to code altered by people with mal-intent, i.e. malware. This is how good embedded systems go bad. We recently saw malware that allowed an ATM to spit out 40 bank notes at a time if a certain code was entered. Real nice for those who know the code!

BadUSB is Bad for More Than Just USB

All systems with processors are vulnerable to bad code, which can do bad things to good systems. All it takes is a way to transfer bad code from one processor to another… and, that happens all the time. USB sticks, USB accessories, the Internet, wireless links like Wi-Fi or Bluetooth — you name it — can be vectors for diseased code. What BadUSB has revealed to us is that all embedded systems, unless equipped with robust protection mechanisms, are now vulnerable to catching diseased code. (Embola?)

Embola

One contracted, a machine infected with Embola can send private and sensitive information to bad guys, or let them take over your system for ransom or other mal-purposes. They can turn on cameras and microphones to spy, grab your photos and bank account information, or even mess with your car. Whatever they want they can have, and you most likely will never know it.

By now you should see the point, which is that every embedded system and PC needs protection. Everything that runs software is vulnerable such as wearables, phones, USB accessories, USB sticks, cameras, cars, printers, thermostats, ATMs, meters, microwaves, appliances, and whatever the IoT will become. Simply put: If it has a processor and connects to something else, it is hackable.

So, what can you do to protect against Embola? The answer is twofold:

1. Don’t let the bad code in, and
2. If it does get in, don’t let it run.

While this sounds pedantically simplistic, these steps are NOT being taken. These two functions have the self-explanatory names of secure download and secure boot.

Secure Download

Secure download uses encryption to ensure that the code that is received by the embedded system is kept away from hackers. The code is encrypted using an algorithm such as Advanced Encryption Standard (AES) by using an encryption key. That encryption key is created using a secret that is only shared with the target system. The encrypted code is sent to the target embedded system to be decrypted and loaded for its use. Along with the encrypted code, a seed is also sent to the target system.

The seed is a number (typically unique with each session) that is hashed during the encryption session with a secure secret key. The result of that hashing is called the digest or Message Authentication Code (MAC) and it is used to encrypt the code (i.e. the MAC is the actual encryption key). The seed is sent to the target system to enable decryption, and not useful to anyone unless it is hashed with the secret key, which is what the target system will do. The target system runs the same hashing algorithm with the identical shared secret key stored there and the seed, which results in the same digest (MAC) that was used to encrypt the code. That MAC can now be used as the decryption key to decrypt the code. At this point, the decrypted code can be ran in the target embedded system.

However, there is another step that can be taken that adds even more security, which is authentication using a digital signature. To use authentication, the unencrypted original code is hashed and signed by the code originator at the same time as the original encryption process. The originator uses a signing key on that hash of the code to make a signature. That signature is sent with the encrypted code and seed to the target system. Once the encrypted code is decrypted using the process noted above, the newly decrypted code will be hashed by the target system, just like was done by the originator, and then signed with the signing key stored in the target system. That signing key is the same as on the originator’s signing module, so if the decrypted code has not been altered, the signature made on the digest of that decrypted code and the signing key will be exactly the same as the signature that was sent over. These two signatures are compared and if they match then the code has been authenticated and can be safely run on the target system. What does this mean? No risk of Embola!

The two levels or security provided by secure down load with authentication is obviously very robust. It will ensure that code that was received has been kept secret during transmission and has not been tampered.

Secure Boot

Secure boot also uses digital signatures to ensure that the code to be booted when the target system starts up matches the code that the manufacturer intended and has not been tampered with. It sort of works in a similar way as secure download. If the code to be booted has been altered, then the signature made by hashing the digest of that code with a secret signing key will not match the signature from the manufacturer. If they don’t match, the code will not load.

These methods are easy and inexpensive to implement and already exist. You should be able to see by now how Atmel has you covered. Ready, set, get secure!

 

Security researchers release BadUSB attack code

Back in August during this year’s Black Hat Conference, Security Research Labs researchers Karsten Nohl and Jakob Lell warned of a serious flaw in USB devices that they dubbed “BadUSB.” As the duo revealed, the flaw can be abused by hackers to reprogram essentially any USB to wreak havoc as it impersonates other devices.

Now a few months later, a pair of other researchers, Adam Caudill and Brandon Wilson have published the attack code on Github in an attempt to put pressure on USB manufacturers to fix the problem or else leave countless users vulnerable.

During the Derbycon security conference in Louisville, Kentucky, Caudill took the stage to explain to attendees, “The belief we have is that all of this should be public. It shouldn’t be held back. So we’re releasing everything we’ve got. This was largely inspired by the fact that [SR Labs] didn’t release their material. If you’re going to prove that there’s a flaw, you need to release the material so people can defend against it.”

The researchers believe that publicly releasing the USB attack code will enable penetration testers to use the technique, thereby proving to clients that USBs are nearly impossible to secure in their current form.

“Writing code for these devices is far from easy, especially when trying to patch the existing firmware. It’s not something that just anyone can jump into — while we have made it easier for people to apply simple patches and provided some insight to the process, these aren’t the patches that will lead to a firmware based worm or something of that nature — these are the type of patches that will make small changes to existing features, or add simple new features,” Caudill wrote in a recent blog post. “So, to do anything still requires a lot of knowledge and skill — in general, as I said earlier, the kind of people that have what it takes to do this, could do it regardless of our release.”

So, why release the code? According to the duo, this is meant to push manufacturers to treat this issue with the kind of seriousness it deserves and to raise user awareness around the fact that as long as users trust devices, attacks will be possible and successful.

“Device manufactures were quick to dismiss the ‘BadUSB’ threat — on one hand, what was presented at Black Hat was possible via other means, so wasn’t really a new threat — but they showed no indication of trying to address the issues under their control,” Caudill explains.

While it will take years for any changes made by device manufactures to have an impact because of the number of devices in circulation now, Caudill urges that if they keep ignoring the issue, then it will never be improved.

“People look at these things and see them as nothing more than storage devices,” Caudill told Wired. “They don’t realize there’s a reprogrammable computer in their hands.”

Now that the bug Karsten Nohl calls “unpatchable” has been released to the public, USB security is undoubtedly compromised. Hackers using BadUSB will gain a new tool that can dish out serious attacks. What this means is that the only means of addressing the problem is to add an additional layer of security over the USB firmware.

USB drives that users plug into their computer could already result in an attack that can’t be avoided unless the user knows exactly where a USB has been, from the time of its production in a factory to the time it reaches the current user.

The good news about BadUSB is that there is a cure: Atmel CryptoAuthentication. Hardware crypto engines were invented to protect software, firmware and hardware from exactly these types of attacks, among many others. These uber-tiny, ultra secure hardware devices can be easily and cost effectively added to USB sticks (and other peripherals) by manufacturers, who are seeking to protect their customers by ensuring that only the proper and intended code is used. Once installed into the peripherals, CryptoAuthentication devices will block the bad code. Period.

Atmel’s experience matters when finding a solution to fight real-world attacks. Isn’t it time you plug with trust?

In conclusion Caudill asks, “Has this been blown out of proportion?” His answer: “Yes.”