TAG | security
A couple of months ago researcher Karsten Nohl demonstrated a security vulnerability that he called BadUSB. Basically it was a demonstration that an attacker could alter the firmware in a USB device to automatically attack anything it was plugged in to. At the recent DerbyCon, researchers Adam Caudill and Brandon Wilson demonstrated their version of the attack and released sample code for how to implement it. This really opens pandora’s box.
The problem here is that this is not actually a bug in USB. It is exactly how USB is designed to work (as insecure as that might be), and changing that behavior is likely to break a lot of other things. A good and effective fix for this vulnerability is probably years away.
In the mean time, take great care with USB devices. My suggestion is to never use another person’s USB device. Don’t use USB to transfer files, and make sure that any USB devices you do use are obtained directly in unopened packaging. There could still be exploits introduced in manufacturing, but at least you are as safe as reasonably possible.
Apple is getting taken to task for a couple of security issues.
First, their recently announced “Random MAC address” feature does not appear to be as effective as expected. The idea is that the iOS 8 device will use randomly generated MAC addresses to ping WiFi base stations when it is not actively connected to a WiFi network. This allows your phone to identify known networks and to use WiFi for enhanced location information without revealing your identity or allowing you to be tracked. Unfortunately the MAC only changes when the phone is sleeping, which is really rare with all the push notifications happening all the time. The effect is that the “random” MAC addresses are changed relatively infrequently. The feature is still good, but needs some work to be actually very useful.
Second, people are noticing their passwords showing up in Apples iOS 8 predictive keyboard. The keyboard is designed to recognize phrases you type frequently so it can propose them to you as you type, thus speeding message entry. The problem is that passwords often follow user names, and may be typed frequently. Research is suggesting that the problem is from websites that fail to mark their password fields. Apple is smart enough to ignore text in known password fields, but if it does not know that it is a password, then the learning happens. It is not clear that this is Apple’s fault, but it is still a problem for users. Auto-fill using the latest version of 1Password should protect against this.
Since it was introduced, Apple has had the ability to decrypt the contents if iPhones and other iOS devices when asked to do so (with a warrant).
Apple recently announced that with iOS 8 Apple will no longer be able to do so. Predictably, there has been a roar of outrage from many in law enforcement. [[Insert my usual rant about how recent trends in technology have been massively in favor of law enforcement here]].
This is really about much more than keeping out law enforcement, and I applaud Apple for (finally) taking this step. They have realized what was for Anonymizer a foundational truth. If data is stored and available, it will get out. If Apple has the ability to decrypt phones, then the keys are available within Apple. They could be taken, compromised, compelled, or simply brute forced by opponents unknown. This is why Anonymizer has never kept data on user activity.
Only by ensuring that they can not do so can Apple provide actual security to it customers against the full range of threats, potentially least of which is US law enforcement.
On July 2, Google engineers discovered unauthorized certificates for Google domains in circulation. They had been issued by the National Informatics Center in India. They are a trusted sub-authority under the Indian Controller of Certifying Authorities (CCA). They in turn are part of the Microsoft Root Store of certificates, so just about any program running on Windows, including Explorer and Chrome, will trust the unauthorized certificates.
The power of this attack is that the holder of the private key to the certificate can impersonate secure Google servers. Your browser would not report any security alerts because the certificate is “properly” signed and trusted within the built in trust hierarchy.
Firefox does not have the CCA in its root certificate list and so is not affected. Likewise Mac OS, iOS, Android, and Chrome OS are safe from this particular incident as well.
It is not known exactly why these certificates were issued, but the obvious use would be national surveillance.
While this attack seems to be targeted to India and only impacts the Microsoft ecosystem, the larger problem is much more general. There is a long list of trusted certificate authorities, which in turn delegate trust to a vast number of sub-authorities, any of whom can trivially create certificates for any domain which would be trusted by your computer.
In this case the attack was detected quickly, but if it had been very narrowly targeted detection would have been very unlikely and monitoring could have continued over very long periods.
As an end user, you can install Certificate Patrol in Firefox to automatically detect when a website’s certificate is changed. This would detect this kind of attack.
On Chrome you should enable “Check for server certificate revocation” in advanced settings. That will at least allow quick protection once a certificate is compromised.
Update: Microsoft has issued an emergency patch removing trust from the compromised authority.