TAG | security breaches
On Friday I was asked to come on The Social Network Show to talk about the fact and questions surrounding the theft of over 1 Billion passwords.
Tor just announced that they have detected and blocked an attack that may have allowed hidden services and possibly users to be de-anonymized.
It looks like this may be connected to the recently canceled BlackHat talk on Tor vulnerabilities. One hopes so, otherwise the attack may have been more hostile than simple research.
Tor is releasing updated server and client code to patch the vulnerability used in this attack. This shows once again one of the key architectural weaknesses in Tor, the distributed volunteer infrastructure. On the one hand, it means that you are not putting all of your trust in one entity. On the other hand, you really don’t know who you are trusting, and anyone could be running the nodes you are using. Many groups hostile to your interests would have good reason to run Tor nodes and to try to break your anonymity.
The announcement from Tor is linked below.
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.
The recent Ebay password compromise is just the latest in a string of similar attacks. Each time we hear a call for people to change their passwords. Sometimes the attacked company will require password changes, but more often it is just a suggestion; a suggestion that a majority choose to ignore.
Further exacerbating the problem is the tendency of people to use the same username and password across many different websites. Even if a compromised website does require a password change on that site, it has no way of forcing users to change their passwords on any other sites where the same password was used. This matters because a smart attacker will try any username / password pairs he discovers against a range of interesting websites of value, like banks. Even though the compromise may have been on an unimportant website, it could give access to your most valuable accounts if you re-used the password.
The burden on the user can also be significant. If a password is used on 20 websites, then after a compromise it should be changed on all 20 (ideally to 20 different passwords this time). People who maintain good password discipline only need to change the one password on the single compromised website.
Trying to remember a large number of strong passwords is impossible for most of us. Some common results are that the the passwords are too simple, the passwords all follow a simple and predictable pattern, passwords are re-used, or some or all of these at once.
Many companies and standards organizations are working hard to replace the password with a stronger alternative. Apple is using fingerprint scanners in its latest phones, and tools like OAUTH keep the actual password (or password hash) off the website entirely. Two factor authentication adds a hardware device to the mix making compromise of a password less damaging. So far many of these approaches have shown promise, but all have some disadvantages or vulnerabilities, and none appear to be a silver bullet.
For now, best practice is to use a password vault. I use 1Password but LastPass, Dashlane, and others are also well regarded. Create unique long random passwords for every website (since you no longer need to actually remember any of them). Don’t wait. If you are not using one of these tools, get it and start using it now.
Researchers recently announced the discovery of an incredibly dangerous bug in the OpenSSL encryption library. That library is used by about two thirds of websites, and many VPNs and other secure communications services.
The problem is in a memory leak that allows an attacker to request heartbeat responses which will contain up to 64KB of memory, and to do so over and over without being detected. This has already been shown to be able to capture the server’s RSA secret key. That is the key used to authenticate communications with the clients, and to encrypt the session keys. Other data could be captured as well, but those keys are really the biggest threat.
An attacker with that key could perfectly impersonate the server, or run man in the middle attacks undetectably.
It is unknown if, or how often, this attack has been run in the wild. It is entirely possible that major players, like national intelligence services, may have known about this for some time, and could have been silently intercepting traffic to certain websites, potentially for over 2 years. We just don’t know. There is a call for researchers to set up test sites to detect this activity going forward, but there is no way to know if it happened in the past.
The solution is non-trivial. All affected services need to install the recently available patch to fix the underlying problem. They then need to address the possibility that their keys have been stolen. All server certificates need to be revoked, so clients will know to reject them, and new certificates created and distributed. This is likely to take time, and many sites will be very slow to respond.