You know the lock icon that pops up next to URLs to tell you a website will keep your information safe? It turns out it has actually left your private data unsecured for more than two years.
Websites encrypt your information, like emails, passwords and credit card numbers, so if anyone tries to snoop, they get a gibberish code and your data stays between you and the people you want to send it to. At least that’s the way it’s supposed to work. This week, researchers found a hole in OpenSSL, the lock that an estimated two-thirds of websites use. They’re calling the bug “Heartbleed.”
What’s more, any attacks let in due to the bug can’t be traced, experts say. This is a gaping security hole with “epic repercussions,” director of security firm AlienVault Labs Jaime Blasco says, even if you’re starting to become numb to all the data breaches of late.
Here are 5 rules for using the Internet after Heartbleed.
1. Trust no one
Run the websites you have accounts with through tools like the Heartbleed test to see if they’re vulnerable or if the security gap has been patched before logging on. The page is fielding about 4,000 searches a minute, Milan-based freelance developer Filippo Valsorda said. Download the Chrome browser extension, Chromebleed, to receive notifications when you land at a website that hasn’t fixed the problem yet. “In computer security, you never know when there’s going to be a vulnerability,” says Joost Bijl, marketing manager at the security firm Fox-IT.
2. Change your passwords and use two-step verification
‘Heartbleed’ bug threatens sensitve data, and more
Website companies are racing to fix a major security flaw caused by a software bug called Heartbleed. Goldman Sachs mulls closing its dark pool, Sigma X. 20 hurt in Pennsylvania school stabbings.
“Change your password” is a mantra consumers have heard for years. It sounds simple and experts say it’s still the first step users should take to protect themselves in case their communications were intercepted due to Heartbleed over the last two years. The safest move would be to change all your passwords, given the dominance of OpenSSL, the technology associated with the bug. Many companies, including GoogleGOOG+0.05% , FacebookFB+0.05% , Twitter and PayPal offer two-step authentication, asking users a security question or sending a code via text message when someone tries to log in from a new machine. “If someone lifts your password, then they still can’t log in,” Bijl says.
3. Be wary of public Wi-Fi networks
Turn off the setting that autoconnects your smartphone to public Wi-Fi networks, which can be exploited by malicious hackers. Airport and hotel Wi-Fi connections are convenient, but experts say these unsecured connections leave you open to attacks. When you do use them, set up a virtual private network to secure your Internet traffic. There are some free VPN services, though many charge monthly rates.
4. Monitor recent account activity
Some companies, like Google, offer email activity reports that show where and when an account was accessed. On Gmail, click on the small “details” button at the bottom of your inbox for a report complete with timestamps, maps and IP addresses. If a timestamp doesn’t match up with your usage, change your password (and remember rule No. 2, two-step verification).
5. Install all the annoying security updates and read the alerts
Everyone’s guilty of snoozing the prompts to install a security update and reboot, or ignoring an alert message to get to a Web page. These updates guard your computer from malware and other threats, and also fix any security gaps that might have gone undetected when you first downloaded software. If a security alert pops up on a familiar website, users sometimes ignore the notice and hit accept to move on, but can get caught in what are known as “man in the middle” attacks where a hacker eavesdrops on communications. “Users really don’t care and usually they don’t read those messages,” Blasco says. “Please read the messages and try to understand what you’re doing before you really make a mistake and your data can be compromised.”
There’s good news, bad news, and worse news regarding the “Heartbleed” bug that affected nearly two-thirds of the Internet’s servers dependent on SSL encryption. The good news is that many of those servers (well, about a third) have already been patched. And according to analysis by Robert Graham of Errata Security, the bug won’t expose the private encryption key for servers “in most software” (though others have said several web server distributions are vulnerable to giving up the key under certain circumstances.)
The bad news is that about 600,000 servers are still vulnerable to attacks exploiting the bug. The worse news is that malicious “bot” software may have been attacking servers with the vulnerability for some time—in at least one case, traces of the attack have been found in audit logs dating back to last November. Attacks based on the exploit could date back even further.
Security expert Bruce Schneier calls Heartbleed a catastrophic vulnerability. “On the scale of 1 to 10, this is an 11,” he said in a blog post today. The bug affects how OpenSSL, the most widely used cryptographic library for Apache and nginx Web servers, handles a service of Transport Layer Security called Heartbeat—an extension added to TLS in 2012.
Heartbeat allows a connected Web client or application to send messages to keep a connection active during a transfer of data. When a Heartbeat message is received, the server usually simply echoes back what it got to the sender. However, starting with the initial implementation of Heartbeat in OpenSSL 1.01 (and in all subsequent releases up to OpenSSL 1.01f, including the OpenSSL 1.0.2 beta) the extension could be fooled into sending back the contents of its memory buffer by sending a request that advertised itself as 64 kilobytes long but in fact had no content—resulting in “Heartbleed.” Any information still in that buffer from a previous session, such as decrypted usernames and passwords, could be obtained by an attacker in the response message.
Your key is (probably) safe
In a post to the Errata Security blog, Robert Graham explained that it is highly unlikely that private key data would be stored in the memory buffer that could be leaked using the Heartbleed exploit. “What you can eavesdrop on with Heartbleed hacks is dynamic stuff, stuff that was allocated only moments ago,” he wrote.
“What you probably can’t get is static information. Certainly, you can’t get any static information that hasn’t been freed, and you probably can’t get static information that was freed long ago, such as program startup. It’s a great way to steal passwords from recent logins, but it’s unlikely to give private keys.”
However, researcher David Litchfield said that the default Web server distribution on FreeBSD will give up the private key if the attack is the first request after the server is reset. Others claim to have successfully retrieved keys under other circumstances with the exploit.
A scan performed by Graham Tuesday night found that of the 28 million servers and other devices that responded to an SSL connection request, only about 600,000 were vulnerable to attack using Heartbleed. “We also found 33,531 machines that had Heartbeats enabled, but which did not respond to the Heartbleed attack,” Graham wrote. “Presumably, this means a third of machines had been patched by the time we ran the scan last night.”
Closing the barn door
The reduced likelihood of exposure of private certificates—which would allow an attacker to masquerade as the attacked server or client—is cold comfort, however, considering that usernames and passwords on some systems may have been exposed for months or years by the vulnerability, which has been part of every OpenSSL release since March 2012. There are signs that exploits for the vulnerability were in use by someone for some time before the vulnerability was revealed.
Ales Teska, of the mobile security provider SeaCat.mobi, wrote in an email to Ars that his company’s service, while not vulnerable to the Heartbleed exploit, acted as a sort of “honeypot” for attacks based on the exploit because of its use of OpenSSL. “Our OpenSSL-based software was logging Heartbleed attack attempts to its logs by coincidence,” he wrote, starting on March 23. When upgrading the OpenSSL on two test servers, he checked the logs of the servers and found “these two servers are actually logging such an attempt to the log file (as a generic OpenSSL handshake issue).” SeaCat.mobi has detailed the attempted attacks in a blog post.
Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart.
Apache and nginx servers aren’t the only potential victims of the OpenSSL vulnerability. A malicious server can be used to attack client applications that use OpenSSL 1.0.1. Fortunately, few Web browsers do—Chrome on Android 4.1.1 may be vulnerable, for example, since it uses OpenSSL 1.0.1e, but most Chrome and all Firefox browsers use the Mozilla Network Security Services (NSS) libraries. Apple uses its own cryptographic services for OS X and iOS; an earlier, unaffected version of OpenSSL is included in OS X, but Apple discourages its use.