TAG | security breaches
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.
Infosec Institute published an article showing in detail how application signing on Android devices can be defeated.
This trick allows the attacker to modify a signed application without causing the application to fail its signature check.
The attack works by exploiting a flaw in the way signed files in the .apk zip file are installed and verified. Most zip tools don’t allow duplicate file names, but the zip standard does support it. The problem is that, when confronted by such a situation the signature verification system and the installer do different things.
The signature verifier checks the first copy of a duplicated file, but the installer actually installs the last one.
So, if the first version of a file in the archive is the real one, then the package will check as valid, but then your evil second version actually gets installed and run.
This is another example of vulnerabilities hiding in places you least expect.
Another from the “if the data exists, it will get compromised” file.
This article from the Washington Post talks about an interesting case of counter surveillance hacking.
In 2010, Google disclosed that Chinese hackers breached Google’s servers. What only recently came to light was that one of the things compromised was a database containing information about government requests for email records.
Former government officials speculate that they may have been looking for indications of which of their agents had been discovered. If there were records of US government requests for information on any of their agents, it would be evidence that those agents had been exposed. This would allow the Chinese to shut down operations to prevent further exposure and to get those agents out of the country before they could be picked up.
I had not thought about subpoenas and national security letters being a counter intelligence treasure trove, but it makes perfect sense.
Because Google / Gmail are so widely used, they present a huge and valuable target for attackers. Good information on almost any target is likely to live within their databases.