What IT Managers Should Know About Heartbleed

Best Practices to prevent attackers from getting exposed to your network or servers and provide highest level of security

It is all pervasive that the Heartbleed bug is a vulnerability discovered in the TLS heartbeat mechanism built into certain versions of the popular OpenSSL library. OpenSSL is one of the technologies employed by many sites online to create an encrypted communication session between a user and a website.

Has something like this happened before?
Yes, attacks on TLS and OpenSSL have happened in the past. In 2011, the BEAST (Browser Exploit Against SSL/TLS) exploit was created which took advantage of a weakness found in TLS version 1.0 first discovered in 2002 in order to stealthily steal authentication tokens and decrypt the communication between a web server and a browser. What’s unique about Heartbleed is that there was not a requirement to intercept communications between a user and a server.

Who is affected?
If you use the Internet, it is all but guaranteed that you have been impacted in some fashion by the Heartbleed bug. While reports have stated various numbers of sites potentially exposed to Heartbleed - as many as two-thirds of all sites on the Internet using SSL/TLS - we can safely say that no corner of the Internet is untouched by this bug.

From the websites you use on a daily basis to devices like IP phones and routers, millions of devices and sites rely on OpenSSL to provide secure communications. In fact, Heartbleed potentially impacts many users and devices other than servers. Researchers have demonstrated “reverse” Heartbleed POCs that provides the potential for a malicious server to attack a client instead of a client attacking a server.

How does it work?
The flaw in OpenSSL was introduced in OpenSSL version 1.0.1 and has persisted through subsequent versions up to version 1.0.1f. The flaw exists in a call to memcpy() that failed to do bounds check. An attacker can force OpenSSL to send back the contents of server memory, in 64KB chunks. Inside those 64KB chunks of server memory can be confidential information such as usernames, passwords, the secret keys used to encrypt data, credit card numbers, or other information that would normally be encrypted and not viewable. In other words, a vulnerable server can be exploited to reveal sensitive information that it shouldn’t. This can lead to identity theft or other types of cybercrime.

Should IT managers be worried?
Yes. If you are an Internet user, there is a chance that an attacker was able to grab a chunk of server memory that contained some of your personal information, including the username and password. Further, while this bug was only discovered a few days ago, the bug itself has existed for over two years - there is no way to know if someone discovered the bug on their own and quietly exploited it to collect a vast wealth of sensitive and confidential information.

How can one check the exposure?
On the server side of the equation, there are multiple things you should do as a best course of action to provide the highest level of security to your employees, users and customers:

  1. Ensure you have appropriate IPS signatures deployed to monitor and mitigate any potential attacks on your infrastructure. A Hot Update to the customers with IPS signatures to detect and prevent Heartbleed attacks from the vendors is critical. In situations such as this, our threat research teams are able to respond to urgent or immediate security incidents promptly to protect our customers (and our customers’ customers) from exploitation. 
  2. Determine the extent of the bug in your systems: how many systems are you using that use OpenSSL? How many of those are using OpenSSL 1.0.1 through 1.0.1f?
  3. Deploy the patch as soon as possible to all systems affected.
  4. If it is determined that your systems were impacted by Heartbleed, you may want to consider revoking all of your certificates/key pairs used, and have your Certificate Authority issue replacements. While it is still uncertain as to the feasibility of an attacker successfully obtaining your secret key through Heartbleed, current research is unable to completely eliminate the possibility. For many companies, replacing all of their certificates in their PKI is a massive task - but a very necessary one: due to the silent nature of the attack and the amount of time the bug has existed, you may want to assume that your secret keys have been compromised and are no longer secret. Force all users to reset their passwords upon next login.
  5. For cases where you are working with customers who use your web assets, send an email to them outlining your current fix status and directing them to your site to change their passwords. Remember though: use best security practices when crafting your email - don’t send a password reset link through email. Phishers and malware authors will undoubtedly use this opportunity to trick unsuspecting users to visit copycat sites in the hopes of obtaining credentials or installing malware.
  6. Have your PR team make a public statement, both on your site and through your social media channels - reassure your users that you have fixed the issue and it is safe to use your services again. It is much better to address your response to Heartbleed than it would be to remain quiet and have your users question your response.
  7. Finally, you should do an internal post-mortem analysis of all systems affected and the information handled by those systems in order to determine the type of information that was exposed and possibly leaked. Your risk assessment teams should react accordingly.

 

Lebron XIII Elite PE


Add new comment