The Internet was rocked last week when a two-year-old bug in OpenSSL was revealed. Heartbleed, as the vulnerability is known, can result in massive information disclosure through simple requests that require no privileges, and leave no logs. Anything from command history to other users’ credentials to private keys can be exposed, and the aftershocks of this revelation will go on for months as SysAdmins try to patch their systems and data losses are reported. CVE 2014-0160 details the vulnerability.
In short, OpenSSL is an open source implementation of SSL and TLS widely used throughout the web. It provides the basis for encryption of web sites, secure FTP servers, mail servers, VPN endpoints and more. To reduce the load imposed by encryption, a heartbeat function was introduced to serve as a kind of keep-alive for secure sessions that weren’t actively passing data. This is defined in RFC 6520.
The bug comes about from a missing bounds check that enables attackers to request the heartbeat along with large amounts of data from memory, 64KB at a time, which can include all sorts of privileged information. Since this is a heartbeat request and not an actual application check, an attacker exploiting this vulnerability leaves no trace in the logs, nor does he even need credentials… only an established SSL session.
OpenSSL 1.0.1 through 1.0.1f are vulnerable to Heartbleed unless compiled with the option OPENSSL_NO_HEARTBEATS. 1.0.1g and later, or versions 1.0.0 and earlier are not vulnerable. Knowing which versions are impacted is one thing. Knowing your systems are not vulnerable is something else. OpenSSL can be used to provide the SSL/TLS functionality for any number of services. You can find it in Linux systems and third party applications on Windows. You can also find it running on load balancers and reverse web proxies. While Windows admins using IIS won’t have to worry about Heartbleed on their web servers, they may still be vulnerable if a load balancer or reverse proxy or SSL offload component in front of their webservers is using OpenSSL.
Since OpenSSL can be compiled into any number of systems for several different protocols, one approach to identifying the vulnerability requires that you check all systems for any SSL or TLS service. You can use Nmap to scan your network ranges, examining common SSL or TLS ports, using this command syntax.
nmap -sS -p 443,993,995,465 -iL ./ip_addresses.txt
where the list of IPs is the file ip_addresses.txt. If you use any other encrypted services, add them to the ports list. Once you identify an IP address, you can examine the specific system to see if it is vulnerable. Of course, that can take a lot of time and effort, and you will have to eliminate all the systems that, while running a service offering encrypted transport, aren’t using OpenSSL from the truly vulnerable ones.
A better approach is to use a vulnerability assessment tool, like GFI LanGuard, to evaluate your systems to confirm whether or not they are vulnerable. Using GFI LanGuard to check you systems is straightforward.
1. You scan the device using a scanning profile that does vulnerability assessment (e.g. “High Security Vulnerabilities”).
Specify scan target. There is no need to specify administrative credentials on the scanned devices.
Set scanning profile (The default “Full Scan” is ok too, just that the scan takes longer)
Click on “Scan” button
2. If the device is running a service vulnerable to Heartbleed, the vulnerability will show in the scan results.
3. Then you can either update the version of OpenSSL to 1.0.1g or later, or you can recompile OpenSSL with the OPENSSL_NO_HEARTBEATS option. For closed systems like load balancers or other appliances, you may need to work with your vendor to obtain an update, bypassing the impacted system(s) until the vendor has a patch.
The Heartbleed bug is being billed by some in the security field as catastrophic. That may be an understatement. On a scale of 1 to 10: this is an 11. Since so many systems are vulnerable, have been for perhaps two years, and there’s no good way to tell if a system has been exploited, the ramifications of this make PRISM seem like a rainbow.
Just because IIS doesn’t use OpenSSL, don’t assume you are immune to this. There are plenty of third party applications for Windows that use OpenSSL, and there may be devices between your servers and the Internet that do too.
SysAdmins should patch vulnerable systems immediately, and then reset all privileged account passwords and change encryption keys. Users should first confirm that web sites have been patched, and then change their passwords. This may be the event that finally pushes multi-factor authentication into the mainstream.
Heartbleed has really rocked the boat, but with GFI LanGuard, admins can quickly find the systems they need to patch and prevent any major hemorrhages – Try it out for free today!
Copyright Source : https://www.gfi.com/blog/how-to-confirm-your-systems-arent-suffering-a-major-heartbleed/
No comments:
Post a Comment