Vulnerability in OpenSSL "Heartbleed"

Vulnerability in OpenSSL: Heartbleed

A few days ago, information was released about a serious vulnerability, Heartbleed, in the OpenSSL package (CVE-2014-0160 “TLS heartbeat read overrun”). This flaw enables attackers to access sensitive data, including private keys, usernames, passwords, and VPN data.

The Heartbleed vulnerability leaves no traces in log files, making it impossible to determine if data leakage has occurred. It is important to note that Heartbleed is not an exploit and cannot be used to gain direct unauthorized access to a vulnerable server. However, data obtained by an attacker can be used for subsequent attacks on the vulnerable system.

Affected OpenSSL Versions

The vulnerability exists in a limited range of OpenSSL versions — from 1.0.1 to 1.0.2-beta1. These versions are typically included in popular operating systems:

• Debian 7.x Wheezy (stable)
• Ubuntu 12.04.4 LTS
• CentOS 6.x
• Fedora 18
• OpenBSD 5.3
• FreeBSD 10.0
• NetBSD 5.0.2
• OpenSUSE 12.2

Older operating systems (e.g., CentOS 5.x, FreeBSD 8.x) run earlier versions of OpenSSL that are not affected by this vulnerability. You can check the OpenSSL version using the command openssl version:

# "Old" version, no vulnerability:
server1# openssl version
OpenSSL 0.9.8o 01 Jun 2010

# Vulnerable version, update required:
server2# openssl version
OpenSSL 1.0.1e-15 11 Feb 2013

Updating OpenSSL

Updating OpenSSL can be done using the standard package manager. For CentOS and other RHEL systems, execute the command:

yum update

For Debian/Ubuntu:

apt-get update && apt-get upgrade

For Arch:

pacman -Syu

After updating, it is advisable to reboot the server. If a reboot isn’t possible, stop and restart all services that rely on SSL, such as Apache, NGINX, mail services, VPN, etc.

It is highly recommended to request a reissue of SSL certificates used on your websites. Verify the procedure for revoking old keys and issuing a new certificate with the relevant company; this usually does not incur additional costs.

Security Best Practices

From a security standpoint, we recommend changing your passwords. Here are some best practices:

• Use a password manager. There are both commercial products (1Password, LastPass Premium) and free/open-source options (KeePass).
• For SSH, configure access with keys and consider switching to two-factor authentication.
• Avoid reusing passwords; generate a unique password for each resource using a password manager.
• Regularly update your operating system and installed packages.
• Stay informed about the latest news in IT security; subscribe to relevant mailing lists.

Temporary Mitigation

A small update (April 10, 2014): A solution was proposed for logging and blocking Heartbeat requests to HTTPS (port 443) using iptables with the following rules:

# Log rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 
"52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"

# Block rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 
"52=0x18030000:0x1803FFFF" -j DROP

While these iptables rules can provide temporary mitigation, updating OpenSSL is essential.