Some time in 2010, Google, Adobe, and “dozens of other high-profile companies” were hacked by the Chinese government. The attack was done through a previously unknown vulnerability in Internet Explorer and considered to be highly sophisticated. The attackers copied intellectual property of these companies and accessed Gmail accounts of human rights activists.
Rather than directly hack into the accounts of those activists, the entire e-mail provider was compromised.
Earlier this month, an SSL Certificate Authority was hacked and used to issue 9 fraudulent SSL certificates for popular domains such as Google and Yahoo, 4 of which are used for securing e-mail and chat communications.
SSL is the magical encryption system used by your web browser so that when you connect to your bank’s website or login to your Gmail account, your private information is secured and not able to be viewed by anyone that has access to your Internet connection, such as everyone at the coffee shop at which you’re using your laptop, employees of the Internet Service Provider that you use at home, the neckbeards in the IT department at your work, any number of US government agencies, or some random attacker trying to steal your credit card information. The (highly simplified) way this encryption works is:
A company such as your bank or Google operates a website that they need to provide secure access to. Your bank contacts one of the trusted Certificate Authority (CA) companies that are in the business of selling SSL certificates and purchases one. After the CA company verifies that the person asking for the SSL certificate for the bank actually works at the bank, the certificate is issued, and people in charge of the bank’s website install the SSL certificate on their web server.
When you visit your bank’s website and switch to a “secure connection”, their web server shows its SSL certificate to your web browser and your web browser verifies that it is legitimate. Legitimacy here is defined as the certificate having been issued by a valid Certificate Authority, not expired, not revoked^*^, and that it was issued for the website you are currently visiting.
If all of these things are correct, your browser used to show a happy little padlock icon to let you know your connection was secure, but now it won’t really show you anything appreciably different unless your bank has paid extra money for an “Extended Validation” certificate, in which case your browser will show a green background (I’m convinced they chose green because it shows “we paid lots of money for this”) by the address bar.
If any of those conditions were not met, then your browser will freak out and not let you (easily) visit that website. It will instead show you scary warnings that someone is trying to tamper with your connection. (It’s probably that hipster next to you at the coffee shop.)
The way your browser verifies that the certificate was signed by a valid Certificate Authority is basically that it checks against a master list that it comes with which says, “here are the companies that we, the makers of your web browser, trust.” Those Certificate Authorities are big, reputable security companies like VeriSign, so when they say they trusted your bank when the SSL certificate was issued, you (and your browser) can believe them.
But what some people don’t know is that those big, reputable security companies acting as Certificate Authorities have also trusted some smaller, not-so-reputable companies to act as Certificate Authorities themselves and sign their own certificates for their own customers. Some of those customers have also been given Certificate Authority powers and now there are at least 1,482 Certificate Authorities in 52 countries that are trusted by most browsers due to this chain of trust. And trusted to sign SSL certificates for any website, not just websites in those countries or run by those companies.
With your web browser able to positively identify that you are visiting the real website for your bank, the encryption starts. All of the communications between your web browser and their web server are secured and unable to be viewed or tampered with by anyone along the Internet path between you two.
What happened in this recent fraudulent SSL certificate incident (more info) is that someone from Iran hacked into one of those 1,482 Certificate Authorities and used their servers to create their own SSL certificates for Google, Yahoo, and a few others. With these fraudulent but perfectly valid (according to everyone’s web browser) SSL certificates, the attackers could setup a fake website pretending to be Google or Yahoo, and if you visited them in your web browser, your browser would not only not freak out and stop you, but would positively tell you that you are viewing the real Google or Yahoo.
More likely, though, those SSL certificates were not used for a fake Google or Yahoo website, but were used by the Iranian government to transparently intercept all of the Internet traffic coming from their country to the real Google and Yahoo sites. This is called a man-in-the-middle (MiTM) attack. Instead of Iranians’ web browsers being shown the SSL certificates for the real Google and Yahoo websites, they were shown the recently created fraudulent certificates. Since these certificates were signed by a valid Certificate Authority, the web browsers showed no errors and still reported to their users that everything was properly encrypted. The Iranian government was then able to decrypt that traffic, view it, and re-encrypt the traffic with the real SSL certificates for Google and Yahoo and send it off. The web browsers, the users, and Google and Yahoo would have had no idea there was anything out of the ordinary going on. The Iranian government would have been able to view and capture passwords, e-mails, Google chats, Skype account information, and anything else Iranians were doing on these particular websites.
Again, rather than directly hack into the specific e-mail accounts of certain people, the attackers went after a much larger target and one that would show no signs of intrusion to end-users who were being monitored.
RSA, one of the most trusted names in security, sells a product called SecurID. It’s basically a little device that one keeps on his keychain that displays a random number when its button is pressed. Large organizations like financial firms and government agencies buy these devices and give them out to their employees so that any time those employees need to login to a system, they have to enter their password and the random number shown on their SecurID token. Except those numbers shown aren’t random, they’re actually cryptographically generated based on a master key (installed on the device by RSA before shipping out) and the current time.
When that employee logs into a system using SecurID, the system verifies that the number entered is actually valid based on the same master key and the (hopefully same) current time. If that employee tried to login an hour later with the same number and password, he could not get in. It’s a way to ensure that even if an attacker figures out an employee’s password, the attacker can’t login as that employee without stealing his SecurID device as well. And even if the attacker is somehow able to watch the employee’s network traffic and even went so far as to hack into an SSL Certificate Authority and generate fake SSL certificates so the employee would not suspect anything, the number and password the employee enters to login will not work again in the future.
Recently RSA’s SecurID servers were compromised and someone was able to access the master key information that is programmed into all of those SecurID devices trusted by so many companies. With those keys and an employee’s password, an attacker would theoretically be able to produce the same numbers as the SecurID devices and be able to login as that employee at any time.
So yet again, rather than breach the security of a particular company (or break the impossibly unbreakable encryption algorithms used by RSA SecurID), an attacker succeeded in compromising a much broader target.