Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Heartbleed Bug Exploited Over Extensible Authentication Protocol

samzenpus posted about 2 months ago | from the protect-ya-neck dept.

Security 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."

cancel ×

44 comments

Sorry! There are no comments related to the filter you selected.

Lots of things can be exploited. (4, Insightful)

ls671 (1122017) | about 2 months ago | (#47147017)

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:Lots of things can be exploited. (1)

William Robinson (875390) | about 2 months ago | (#47147145)

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:Lots of things can be exploited. (1)

ls671 (1122017) | about 2 months ago | (#47147335)

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 (1)

grahamm (8844) | about 2 months ago | (#47147025)

When the Heartbleed exploit was announced, all users of vulnerable openssl versions should have upgraded.

Re:Should have upgraded Openssl (5, Insightful)

Grantbridge (1377621) | about 2 months ago | (#47147077)

Some android phones cannot be updated without rooting them, if the manufacturer hasn't released an update.

Re:Should have upgraded Openssl (1)

grahamm (8844) | about 2 months ago | (#47147109)

In which case the manufacturer should have upgraded OpenSSL and released (maybe even pushed) the update.

Re:Should have upgraded Openssl (1)

Grantbridge (1377621) | about 2 months ago | (#47147161)

Well yes, they should have. Sadly for users this isn't always the case. :(

Re: Should have upgraded Openssl (2)

jd2112 (1535857) | about 2 months ago | (#47147605)

But that costs money! If the users want a secure device they can just upgrade to a new phone. Just because you still have 15 months left on your contract is no excuse.

Re:Should have upgraded Openssl (1)

Rob Y. (110975) | about 2 months ago | (#47149323)

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:Should have upgraded Openssl (2, Interesting)

CastrTroy (595695) | about 2 months ago | (#47147213)

Which is why my next phone won't be Android. I'm not sure what OS it's going to be running, but Android seems to be the worst at getting updates. Many phones don't even get a single update after they are shipped. Also, the updates from many phones are carrier specific because they had carrier specific firmware when they were originally sold, So there might be an update for your phone, but you can't easily install it because it's not for your carrier. If you go with a smaller carrier, you are often out of luck. After being burned by this type of situation with Android on my first real smart phone, I will not go with Android again.

Re:Should have upgraded Openssl (3, Insightful)

TechyImmigrant (175943) | about 2 months ago | (#47147267)

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:Should have upgraded Openssl (1)

Vitriol+Angst (458300) | about 2 months ago | (#47156123)

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:Should have upgraded Openssl (1)

TechyImmigrant (175943) | about 2 months ago | (#47156337)

Don't buy your phone from your carrier. It's that simple.

Re:Should have upgraded Openssl (1)

olsmeister (1488789) | about 2 months ago | (#47147271)

Maybe it's the phone and not the OS. My Galaxy S3 has received many updates over the years.

Re:Should have upgraded Openssl (1)

hermitdev (2792385) | about 2 months ago | (#47147279)

So your solution is what, exactly? Go from a phone you can root and put on a custom OS (i.e. cyanogen) that (potentially) fixes security issues to what? An iPhone? A Windows phone? A "dumb" phone?

Re:Should have upgraded Openssl (3, Informative)

mlts (1038732) | about 2 months ago | (#47147321)

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:Should have upgraded Openssl (1)

Archangel Michael (180766) | about 2 months ago | (#47147411)

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:Should have upgraded Openssl (1)

CaptnZilog (33073) | about 2 months ago | (#47152017)

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:Should have upgraded Openssl (1)

Krojack (575051) | about 2 months ago | (#47147973)

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 possible minor security holes.

Re:Should have upgraded Openssl (0)

Anonymous Coward | about 2 months ago | (#47148645)

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 possible minor security holes.

To an end user the distinction is irrelevant.

What matters is that their handset isn't getting updates.

Further It's Android's distribution model which allows those third parties to gum up the system. So Google can be held responsible for enabling the behavior (nothing forced them to open source their OS so everyone and the mother could make proprietary tweaks to ensure that only their versions worked on their phones).

Re:Should have upgraded Openssl (0)

Anonymous Coward | about 2 months ago | (#47151521)

Consider, that if you bought a $99 iPhone, you would have the exact same problem. The range of sub-$100 iPhones haven't received updates in a while, and ALL are 100% vulnerable.

Also consider, that if you have the technical know-how (I'm assuming you do not, most non-techies get frustrated with Android), it is trivially easy to fix it yourself. This is impossible to do (legally) with an iPhone.

Re:Should have upgraded Openssl (2)

savuporo (658486) | about 2 months ago | (#47147427)

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 will only get worse.

I'm not sure there is a reasonable solution there, zero day exploits will continue to be around, and companies will continue to build "embedded" devices that are not really designed to take frequent software updates.

Maybe there is a room on market for consumer oriented security certification brand, which basically tells the buyer - yes, we have reviewed and tested the software stack on this device, and its reasonably safe and sound and the company behind it is reasonably committed to keeping it secure ?

Re:Should have upgraded Openssl (1)

Virtucon (127420) | about 2 months ago | (#47147197)

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:Should have upgraded Openssl (2)

Minwee (522556) | about 2 months ago | (#47147503)

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 know the implementation details of WPA and EAP. Based on all of that, why would you even consider updating or replacing every wireless device you have which don't use HTTPS unless the manufacturer told you?

Moreover, when have manufacturers of popular wireless equipment _ever_ produced timely and relevant updates without at least eight months lead time and court cases in at least three countries?

What? Bad interpretations (4, Informative)

UnknowingFool (672806) | about 2 months ago | (#47147041)

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 (4, Funny)

sessamoid (165542) | about 2 months ago | (#47147147)

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:What? Bad interpretations (2)

mlw4428 (1029576) | about 2 months ago | (#47147581)

It's more likely that the person who wrote the apple slashdot submission didn't apple understand the apple article and just apple wanted apple apple apple apple apple apple.

Re:What? Bad interpretations (2)

wiredmikey (1824622) | about 2 months ago | (#47147175)

In slides of his presentation he does mention iPads, iPhone and OSX. See Slide #18:

http://www.slideshare.net/lgra... [slideshare.net]

Re:What? Bad interpretations (1)

UnknowingFool (672806) | about 2 months ago | (#47147249)

I didn't see the presentation until now. I read his page which he put up after the presentation that contains about 90% of the slides.

Re:What? Bad interpretations (1)

Minwee (522556) | about 2 months ago | (#47147513)

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:What? Bad interpretations (1)

Rich0 (548339) | about 2 months ago | (#47148719)

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 (2)

Anubis IV (1279820) | about 2 months ago | (#47147093)

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 (3, Informative)

TechyImmigrant (175943) | about 2 months ago | (#47147287)

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 (2)

DaphneDiane (72889) | about 2 months ago | (#47147451)

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. (1)

Anonymous Coward | about 2 months ago | (#47147095)

Having an unpatched version of OpenSSL is not sufficient to be exploitable. It must also be in use as a server.

Re:Failure to understand the bug. (1)

Virtucon (127420) | about 2 months ago | (#47147207)

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:Failure to understand the bug. (1)

Anonymous Coward | about 2 months ago | (#47147299)

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? (1)

WaffleMonster (969671) | about 2 months ago | (#47147291)

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:

OpenSSL Security Advisory [07 Apr 2014]
 
TLS heartbeat read overrun (CVE-2014-0160)
 
A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

It's a fucking disgrace (0)

Anonymous Coward | about 2 months ago | (#47147307)

This industry needs to be slapped with liability for software flaws. There's the bug of the decade in OpenSSL and it takes an independent researcher to point out that the bug can be exploited in other ways than the original demo exploit showed? None of the involved multi-billion dollar companies can see that for themselves? These companies need a beating with a legal cluebat, FFS!

Re:It's a fucking disgrace (1)

DarwinSurvivor (1752106) | about 2 months ago | (#47148855)

That's right, set a legal precedent that would prevent any company from ever contributing to open source projects in fear of legal action. That aught to ensure that bugs never get missed in the future!

Re:It's a fucking disgrace (0)

Anonymous Coward | about 2 months ago | (#47149067)

If a product doesn't work because some open source software simply fails, customers can already return the product and get their money back. Software liability would increase the stakes, but nothing would change fundamentally if you exclude source code from liability claims. The liability from failing to make sure that the software is fit for purpose would fall to the entity which creates the binary to provide a service or product.

Re:It's a fucking disgrace (1)

DarwinSurvivor (1752106) | about 2 months ago | (#47152857)

I'm not sure the line is as distinct as you present it to be. What about companies that only link to the libraries? What about companies that distribute their product as source code (shopping carts written in PHP for instance have no binaries)? And what about companies running (but not developing or distributing) this vulnerable code but handling sensitive data (hospital using OpenSSL for the HTTPS on their website)?

Hello ?!? This is already known for month ! (0)

Anonymous Coward | about 2 months ago | (#47149065)

This is hardly news. The wpa_supplicant maintainer discovered that the 8th of april [gmane.org] , only one day after heartbleed was disclosed.

Everyone wants his share of fame, I guess.

Anything interesting for a script kiddie? (1)

rduke15 (721841) | about 2 months ago | (#47150987)

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...

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>