heartbleed_cupid

Heartbleed, Cupid and Wireless

Since my presentation on cupid has gotten quite a bit of attention, I feel it’s necessary to provide a bit more context about this issue and what it is exactly. I’ve received some questions and I’ll try to post all the answers here.

 

What is cupid?

cupid is the name I gave to two source patches that can be applied to the programs “hostapd” and “wpa_supplicant” on Linux. These patches modify the programs behavior to exploit the heartbleed flaw on TLS connections that happen on certain types of password protected wireless networks.

hostapd is a program that sets up a configurable Access Point on Linux, so it is possible to create almost any kind of Wireless Network configuration and let clients connect to it.

wpa_supplicant is a program used to connect to wireless networks on Linux and also on Android.

Interesting side note: both hostapd and wpa_supplicant were written by the same author and share a lot of code, so the patches are very similar.

 

How does the attack work?

This is basically the same attack as heartbleed, based on a malicious heartbeat packet. Like the original attack which happens on regular TLS connections over TCP, both clients and servers can be exploited and memory can be read off processes on both ends of the connection.

The difference in this scenario is that the TLS connection is being made over EAP, which is an authentication framework/mechanism used in Wireless networks. It’s also used in other situations, including wired networks that use 802.1x Network Authentication and peer to peer connections.

EAP is just a framework used on several authentication mechanisms. The ones that are interesting in this context are: EAP-PEAP, EAP-TLS and EAP-TTLS, which are the ones that use TLS.

To exploit vulnerable clients, hostapd (with the cupid patch) can be used to setup an “evil” network such that, when the vulnerable client tries to connect and requests a TLS connection, hostapd will send malicious heartbeat requests, triggering the vulnerability.

To exploit vulnerable servers we can use wpa_supplicant with the cupid patch. We request a connection to a vulnerable network and then send a heartbeat request right after the TLS connection is made.

I saw a misconception on a lot of sources regarding heartbeat and it is a common question that I get: It’s not necessary to fully establish a TLS connection to perform the heartbleed attack. No actual keys or certificates need to be exchanged.

I have found it to be possible to send and receive heartbeat responses right after a “Client Hello” message (before certificates are presented or session keys are exchanged).

 

Do I need to provide a valid user/password to exploit this vulnerability?

In short, no. The vulnerability is triggered before a valid password needs to be presented. Sometimes in order to exploit a vulnerable server you must present a valid username (not password), as the specific EAP mechanism may request a valid username/realm to redirect the user to the proper authentication server.  But this can be easily sniffed off the air when a regular user tries to connect.

 

How to spot vulnerable systems:

You basically use cupid to trigger the vulnerability and look for a behaviour consistent with heartbleed on a packet sniffer.

The following image shows wpa_supplicant_cupid exploiting a vulnerable network:

heartbleed_cupid_img1

 

First we provide a username (EAP Identity), then we will create a TLS connection over EAP to authenticate (using EAP-PEAP). Note that cupid sends heartbeat requests right after “Client Hello”, there’s no need to perform the full TLS handshake. Up to 64kb of memory can be read for each heartbeat request.

 

The second image shows hostapd_cupid exploiting a vulnerable client in the same fashion:

heartbleed_cupid_img2

 

Note that, in this case, we didn’t even send a “Server Hello” message. The vulnerable client requested a TLS connection, sent a “Client Hello”, and we proceeded to send an heartbeat request. The client is happy to respond, leaking up to 64kb of process memory.

 

What is present on the memory that can be read?

Not enough testing was made to go into such detail, so we can only speculate. Most of the memory is zeroed out, but cursory inspection found interesting stuff on both vulnerable clients and servers. I can speculate that most likely the private key of the certificate used on the TLS connection is in memory. What can also be in memory is the user credentials used for authenticating the connection.

 

What software is affected?

Note that I’ve done very limited testing on this. I have confirmed however that on Ubuntu, if you are using a vulnerable version of OpenSSL the default installations of wpa_supplicant, hostapd, and freeradius can be exploited.

Android 4.1.0 and 4.1.1 use a vulnerable version OpenSSL. Also, all versions of Android use wpa_supplicant to connect to wireless networks, so I have to assume that these are probably vulnerable.

Regarding vulnerable clients:

If you have an Android device running 4.1.0 or 4.1.1 you should avoid connecting to unknown wireless networks unless you upgrade your ROM.

If you have a Linux system/device you’re using to connect to wireless networks you should make sure to upgrade your OpenSSL libraries, so if you followed heartbleed mitigation recommendations you should be fine.

 

Regarding vulnerable servers:

If you have an home router you are probably safe from this specific attack vector. This is because most home routers use a single key for Wireless Security (a pre-shared key), and do not use EAP authentication mechanisms.

 

If you have a corporate wireless solution on your company you should look at this problem, since most of the managed wireless solutions use EAP based authentication mechanisms. And some companies use OpenSSL. You should look at having your equipment tested or contacting your vendor and ask for more information.

You should also look at this issue if you have any type of EAP authentication mechanism on your corporate network. Note that 802.1x Network Access Controlled wired networks might also suffer from this problem.

You can contact us at SysValue if you need assistance on testing your corporate network regarding this issue.

 

Conclusion:

I hope this comprehensively addresses all the questions you have about cupid. I’ve put the source code online so that you can test more networks and devices. Please let me know of the results of your testing so I can update this post with the types of devices and configurations that are affected / not affect by this issue.

 

References:

Article written by Luis Grangeia