Heartbleed Poses Risk to Clients and the Internet of Things

While most of the focus on Heartbleed has been on vulnerable public websites, the bug affects much more than this. While most popular sites are no longer vulnerable, this does not mean that end-users can drop their guard. More details after the jump.

Heartbleed equally affects client software such as Web clients, email clients, chat clients, FTP clients, mobile applications, VPN clients and software updaters, to name a few. In short, any client that communicates over SSL/TLS using the vulnerable version of OpenSSL is open to attacks.

In addition, Heartbleed affects various other servers aside from Web servers. These include proxies, media servers, game servers, database servers, chat servers and FTP servers. Finally, hardware devices are not immune to the vulnerability. It can affect routers, PBXes (business phone systems) and likely numerous devices in the Internet of Things.

Attacking these software and hardware servers through the Heartbleed vulnerability is done in a similar manner as an attack to vulnerable websites. However, attacks on clients can happen in essentially the reverse manner.

Typically, exploitation of Heartbleed has been described as an attacking client sending a malicious Heartbeat message to a vulnerable server and the server exposing private data. However, the reverse is also true. A vulnerable client can connect to a server, and the server itself can send a malicious Heartbeat message to the client. The client will then respond with extra data found in its memory, potentially exposing credentials and other private data.

Figure 1. How a vulnerable client is attacked is essentially the reverse of an attack on a server

Fortunately, while clients are vulnerable, it may be difficult to exploit them in real-world scenarios. The two main vectors of attack are instructing the client to visit a malicious SSL/TLS server or hijacking a connection through an unrelated weakness. Both present an added complication for the attacker.

Directing the client to a malicious server
The simplest example of how a client may be exploited is through something like a vulnerable Web browser. One simply has to convince a victim to visit a malicious URL in order to allow the attacking server to gain access to the client Web browser memory. This puts at risk content such as previous session cookies, websites visited, form data and authentication credentials.

Most popular Web browsers do not use OpenSSL, but the NSS (Network Security Services) libraries, which are not vulnerable to Heartbleed. However, many command line Web clients do use OpenSSL (e.g., wget and curl) and are vulnerable.

The attacker’s need to trick a user into visiting a malicious site may mitigate some risk, but it is not always necessary. Imagine an online language translation service where you provide an automated service with a URL to a page in the French language and the service will translate the content to English. Behind the scenes, the service is fetching the content of the French page using their own backend client. If you provide the URL of a malicious server, the backend client can be exploited and the attacker may retrieve sensitive information such as code or credentials from the translation service.

Hijacking a connection
Directing clients to a malicious server as described above requires clients that can be instructed to visit arbitrary servers. However, many clients may only contact a preset, hardcoded domain. In these cases, the client may still be exploited. On shared open networks such as some public WiFi networks, traffic can be visible and altered by others, allowing attackers to redirect vulnerable clients. Normally, SSL/TLS (e.g. HTTPS, encrypted Web browsing) is one of the solutions to this problem, since the encryption prevents eavesdropping and redirection. However, one can send malicious Heartbeat messages prior to the SSL/TLS session being fully established.

An attacker can join a public network and eavesdrop on potential victims. When a potential victim uses a vulnerable client to establish an SSL/TLS connection with a legitimate server, the attacker redirects the connection to the malicious server. Before the SSL/TLS connection is fully established and has a chance to block any redirection, the attacker can send a malicious Heartbeat message extracting contents from the memory of the victim’s computer. This can include private data such as authentication credentials.

Figure 2. How an attacker can hijack and redirect a vulnerable client on a shared, open network

In addition to previous guidance, we also recommend the following:

• Avoid visiting unknown domains with any client software, which accept Heartbeat messages using the vulnerable OpenSSL libraries.
• Stop using proxy services that have not been patched.
• Update software and hardware as vendors make patches available.
• Use a VPN client and service confirmed as not vulnerable to Heartbleed when on public networks.

Source: Symantec

Back to top