Heartbleed Bug Exploited Over Extensible Authentication Protocol 44
wiredmikey (1824622) writes "While most organizations have patched the Heartbleed bug in their OpenSSL installations, a security expert has uncovered new vectors for exploiting the vulnerability, which can impact enterprise wireless networks, Android devices, and other connected devices. Dubbed 'Cupid,' the new attack method was recently presented by Portuguese security researcher Luis Grangeia, who debunked theories that Heartbleed could only be exploited over TCP connections, and after the TLS handshake. Unlike the initial Heartbleed attack, which took place on TLS connections over TCP, the Cupid attack happens on TLS connections over the Extensible Authentication Protocol (EAP), an authentication framework typically used in wireless networks and peer-to-peer connections.
The researcher has confirmed that default installations of wpa_supplicant, hostapd, and freeradius (RADIUS server implementation) can be exploited on Ubuntu if a vulnerable version of OpenSSL is utilized. Mobile devices running Android 4.1.0 and 4.1.1 also use wpa_supplicant to connect to wireless networks, so they're also affected. Everything that uses OpenSSL for EAP TLS is susceptible to Cupid attacks. While he hasn't been able to confirm it, the expert believes iPhones, iPads, OS X, other RADIUS servers besides freeradius, VoIP phones, printers, and various commercial managed wireless solutions could be affected."
The researcher has confirmed that default installations of wpa_supplicant, hostapd, and freeradius (RADIUS server implementation) can be exploited on Ubuntu if a vulnerable version of OpenSSL is utilized. Mobile devices running Android 4.1.0 and 4.1.1 also use wpa_supplicant to connect to wireless networks, so they're also affected. Everything that uses OpenSSL for EAP TLS is susceptible to Cupid attacks. While he hasn't been able to confirm it, the expert believes iPhones, iPads, OS X, other RADIUS servers besides freeradius, VoIP phones, printers, and various commercial managed wireless solutions could be affected."
Lots of things can be exploited. (Score:5, Insightful)
Of course, lots of things can be exploited if you have a vulnerable version of openSSL running ;-)
Simple solution is to patch it although it might be harder on some devices.
Re: (Score:1)
Simple solution is to patch it although it might be harder on some devices.
Agreed.
I do welcome these kind of reports, because they will motivate procrastinating managers. I know managers having big 'change resistance', with simple arguments like "Does it affect us?". These kind of report does tell them why it is much better to act now.
Re: (Score:2)
Hello William,
Simple solution is to patch it although it might be harder on some devices.
Agreed.
I do welcome these kind of reports, because they will motivate procrastinating managers. I know managers having big 'change resistance', with simple arguments like "Does it affect us?". These kind of report does tell them why it is much better to act now.
Maybe you could have your robot spell it to those procrastinating managers with something like "Danger, procrastinating managers!":
https://en.wikipedia.org/wiki/... [wikipedia.org]
Should have upgraded Openssl (Score:2)
When the Heartbleed exploit was announced, all users of vulnerable openssl versions should have upgraded.
Re:Should have upgraded Openssl (Score:5, Insightful)
Some android phones cannot be updated without rooting them, if the manufacturer hasn't released an update.
Re: (Score:2)
In which case the manufacturer should have upgraded OpenSSL and released (maybe even pushed) the update.
Re: (Score:2)
Well yes, they should have. Sadly for users this isn't always the case. :(
Re: Should have upgraded Openssl (Score:3)
Re: (Score:2)
I have a crappy, locked down Asus 7" cheapo tablet (don't blame me - I won it in a raffle). Anyway, it's still on Ice Cream Sandwich, but I did receive an OTA update shortly after the Heartbleed news - so I do think they must've patched it.
Then again, Asus is pretty much a tier one player these days, and a patch should've been expected.
Re: (Score:3, Interesting)
Re:Should have upgraded Openssl (Score:4, Insightful)
So get an unlocked phone and install CM. They're readily available.
That's not an Android problem. That's a carrier problem. At least with Android you can do something about it.
Re: (Score:2)
So get an unlocked phone and install CM. They're readily available.
That's not an Android problem. That's a carrier problem. At least with Android you can do something about it.
Yeah, that's the solution; Roll your own Carrier! AS soon as I jailbreak my phone, I'll be ready for when the carrier fixes their end. Problem solved!
I feel so much better now that I've got an Android MyTouch with version well, I don't know, what version does a 4-year-old phone that has never been upgraded have if it's in black? There are a few chrome highlights on it, so it's got to be a LITTLE modern...
Re: (Score:2)
Don't buy your phone from your carrier. It's that simple.
Re: (Score:1)
Re: (Score:2)
Re:Should have upgraded Openssl (Score:4, Informative)
It really depends on the phone. The HTC phone I bought recently has ROMs available before it officially went on sale. In fact, some unofficial ROMs like CM can have support and updates for a long time after the phone has been discontinued. (I bought the HTC phone because it has plenty of disk space, and it had a MicroSD slot, and with a quick app, the SELinux profile allowed for older apps to work with the external card without issue.)
I wouldn't discount Android just yet. Instead, I'd just be careful what model I buy, and watch features/specs.
If a SD card doesn't matter, a Nexus or GPE (Google Play Experience) device almost certainly will have the ability to unlock the bootloader in the future, so that may be the way to go.
Re: (Score:2)
The problem isn't android at all. The problem is that any phone past the 2 years release date is not supported. Heck, one year is often enough to never see an update. With CyanogenMod and other ROM makers out there supporting older devices supporting it by the Manufacturers shouldn't be an issue. Heck, they could hand off support to Cyanogen if they wanted, but that doesn't sell new handsets every 1.5 years.
Buying an Apple might get you updates beyond 2 years.
And good luck with any other OS.
Re: (Score:1)
The problem isn't android at all. The problem is that any phone past the 2 years release date is not supported. Heck, one year is often enough to never see an update. With CyanogenMod and other ROM makers out there supporting older devices supporting it by the Manufacturers shouldn't be an issue. Heck, they could hand off support to Cyanogen if they wanted, but that doesn't sell new handsets every 1.5 years.
Buying an Apple might get you updates beyond 2 years.
And good luck with any other OS.
Cyanogen (& other mods) thus far don't support a lot of the features in most models. Kinda defeats the purpose when to "upgrade" your 2y/o phone it means losing camera and wi-fi support.
Re: (Score:2)
It's not Android, it's the devices manufacture and also the cell network owner to an extent. Android gets patched but the company that makes your phone won't push those patches to your device after it's so old. 1.5+ years seems to be the average cutoff now.
Manufactures will never ever push these patches to devices they deem outdated. This is a major incentive for them to get users to buy a new device. This is one of the few times I feel laws need to be created forcing them to push updates for major or po
Re: (Score:3)
Phones are the least of the worries IMO. There are so many internet connected consumer electronics devices around that are based on some lightweight linux stack - SmartTVs, home routers, set-top boxes, NAS boxes, IP security cameras etc come to mind. These things will NEVER get patched because the development teams that put together the original firmware for the last years model are often even not around anymore. "Install Cyanogenmod" is not an option either.
With the "Internet of Things" wave raising, this
Re: (Score:2)
Yeah, been there, done that. Of course this means on systems where fixes have been made available. This doesn't cover Wireless Routers and other systems that use EAP unless those vendors have already done their own open vulnerability assessment. Hear that Cisco, Aruba, Linksys, NetGear et al?
Re: (Score:3)
Did _you_ know that your wireless router was using OpenSSL to manage EAP? Or did you just assume that having SSH blocked and not serving HTTPS would be enough?
And even if you did, is it even possible for you to upgrade a single library on your access point?
Try going back to the original CVE [mitre.org], the plethora [possible.lv] of [filippo.io] vulnerability [lastpass.com] checkers [mcafee.com], or any [mcafee.com] of [engadget.com] the [mashable.com] press [heartbleed.com] surrounding it. Every reference to Heartbleed pointed to HTTPS or, rarely, TLS and VPN services as being vulnerable to the bug. Now pretend that you don't
What? Bad interpretations (Score:5, Informative)
the expert believes iPhones, iPads, OS X, other RADIUS servers besides freeradius, VoIP phones, printers, and various commercial managed wireless solutions could be affected
Nowhere on his page [sysvalue.com] does the researcher say anything remotely like this. It's a really bad interpretation as he does not list any VoIP or printers or Apple products. Specifically to be vulnerable to this attack, the product must use a vulnerable version of OpenSSL. Certainly Apple does not use OpenSSL and there are other products that do not.
Re:What? Bad interpretations (Score:5, Funny)
the expert believes iPhones, iPads, OS X, other RADIUS servers besides freeradius, VoIP phones, printers, and various commercial managed wireless solutions could be affected
Nowhere on his page [sysvalue.com] does the researcher say anything remotely like this. It's a really bad interpretation as he does not list any VoIP or printers or Apple products. Specifically to be vulnerable to this attack, the product must use a vulnerable version of OpenSSL. Certainly Apple does not use OpenSSL and there are other products that do not.
If you post about a vulnerability and forget to mention the word "Apple" (whether or not it's even relevant), you just gave up tens of thousands of clicks.
Re: (Score:2)
Re: (Score:3)
In slides of his presentation he does mention iPads, iPhone and OSX. See Slide #18:
http://www.slideshare.net/lgra... [slideshare.net]
Re: (Score:2)
Re: (Score:2)
And note the question mark next to the list of Apple products, which is missing from every other line on that slide.
It's almost as if he knew that they didn't use a vulnerable version of OpenSSL.
Re: (Score:2)
Sure, but I just checked and apparently the WZR-HP-G300NH2 I'm using does contain a vulnerable OpenSSL. There is no mention of whether it is used for EAP, though. They do promise an update within a few days - back in April. No sign of one yet.
Confused (Score:3)
While he hasn't been able to confirm it, the expert believes iPhones, iPads, OS X, other RADIUS servers besides freeradius, VoIP phones, printers, and various commercial managed wireless solutions could be affected.
From what I've gathered [stackexchange.com], Apple deprecated their use of OpenSSL in OS X back in December 2012 and iOS never had OpenSSL at all. So is he suggesting that they're vulnerable via RADIUS because Apple continued building or using an implementation that built against OpenSSL even after they had deprecated their use of it and before the bug was even introduced? It's certainly possible, but I'm a typical Slashdotter, so I haven't read the article.
Re:Confused (Score:4, Informative)
If your back end RADIUS server is running EAP and EAPoL on some unixy box, then Apple get no say in what version of OpenSSL may be used. The device is just the conduit. That's the point of RADIUS+EAP+EAPoL.
Confused (Score:3)
While Apple discourages OpenSSL, it looks like there are using freeradius which does use OpenSSL instead of own open source Secure Transport library ( of goto fail fame ). However it seems like it is using version 0.9.8, i.e. heartbleed free.
$ otool -L radiusd | grep -e libssl -e libcrypto
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 47.0.0)
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 47.0.0)
Failure to understand the bug. (Score:1)
Having an unpatched version of OpenSSL is not sufficient to be exploitable. It must also be in use as a server.
Re: (Score:2)
In the case of EAP negotiation the Access Point is a server in some configurations/networks. I'm more worried if RADIUS servers are vulnerable.
Re: (Score:1)
That's not strictly true - the client is also vulnerable to Heartbleed. The server must be malicious in this case, but if a server is compromised and some malware is inserted somehow, that server could then scrape your client memory whenever you connect.
Debunked what? (Score:2)
who debunked theories that Heartbleed could only be exploited over TCP connections, and after the TLS handshake.
Do we really need a new name for the same vulnerability? None of this should come as surprise or news to any of us.
TLS works over any stream based channel with no dependencies on TCP. Obviously it is not limited to TCP.
Realization clients running OpenSSL stack would be vulnerable to the same problem is not news or novel information not previously well understood. Heartbeats are by construction a bi-directional affair. See also the original OpenSSL security advisory which explicitly stated the obvious:
Re: (Score:2)
Re: (Score:2)
Anything interesting for a script kiddie? (Score:2)
That is all very interesting, but all I want to know is how I can use this to get a ride on my neighbours' WiFi...