It could be just my perception but it seems like the authors of Heartbleed exploit code are focusing on www and email servers.
Doesn't OpenVPN use OpenSSL?
Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
31–40 of 78 posts
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#32Will these automated tools work on vulnerable Android devices? If so this seems a little irresponsible, I mean it is one thing to stick it to lazy sysadmins but making it easy to exploit peoples phones seems evil.
Don't think so, but some of the other tools out there probably would.
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#33It could be just my perception but it seems like the authors of Heartbleed exploit code are focusing on www and email servers. Doesn't OpenVPN use OpenSSL?
I believe so, yes. It often provides a certificate with the configuration settings. Many screen sharing and remote access tools use some form of TLS/SSL too.
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#34This should be a useful tool on its own, but I wrote it primarily because the pattern-matching rules for Snort are inadequate. IDS vendors won't fix their stuff until I can prove they are inadequate. Ugh. In the old days the mantra of full-disclosure was "well, if we don't make exploit tools, then the vendors won't issue patches." And then it became "well, if we don't make exploit tools, then the sysadmins won't patc…
I, for one, am glad that a good chunk of the security community still has its old Wild West spirit of "anarchy and chaos" that was present back during the early hacker groups of the '80s and '90s. In addition to the existence of tons of highly casual security conventions (compared to the strict cons for programming languages and frameworks), it shows that many have not forgotten their roots, and have not succumbed to…
In addition to the existence of tons of highly casual security conventions (compared to the strict cons for programming languages and frameworks)
There are plenty of casual PLs conventions, meetups, hackathons, unconferences, just about any format you want. If anything I think that community is more welcoming and casual than the computer-security convention scene, which has a heavy tilt towards big-money, "rockstar" conferences like DEF CON and Black Hat, full of corporate and government presenters and attendees. There are conferences like that outside of security, like videogames (E3, GDC), but security really takes it to ridiculous levels, even holding the damn things in places like Las Vegas and Abu Dhabi.
What that portion of the security scene's image most reminds me of outside tech is the rockstars they'd like to be: a manufactured pretense of "anarchy and chaos" sold as a business's brand image.
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#35Will these automated tools work on vulnerable Android devices? If so this seems a little irresponsible, I mean it is one thing to stick it to lazy sysadmins but making it easy to exploit peoples phones seems evil.
I'm confused how openSSL on Android is a problem... isn't openSSL a server technology? Do the clients use a heartbeat for something? Or is this only relevant when you're running a server on your client device? Is OpenSSL always running as a server on Android?
You can check for vulnerable clients using this site https://reverseheartbleed.com/
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#36Earlier quoted context omitted.
I'm confused how openSSL on Android is a problem... isn't openSSL a server technology? Do the clients use a heartbeat for something? Or is this only relevant when you're running a server on your client device? Is OpenSSL always running as a server on Android?
Heartbeat goes both ways. If you can be tricked to accessing a malicious HTTPS server, it can extract data from the client . http://blog.meldium.com/home/2014/4/10/testing-for-reverse-h...
... wow, the media firestorm around heartbleed was so fixated on the server-side issue that this completely slipped by me. I guess it's only relevant to one particular Android version and a handful of Linux-based versions where patching is expected to occur automatically and quickly, and nobody cares about desktop Linux.
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#37Earlier quoted context omitted.
I'm confused how openSSL on Android is a problem... isn't openSSL a server technology? Do the clients use a heartbeat for something? Or is this only relevant when you're running a server on your client device? Is OpenSSL always running as a server on Android?
Android 4.1.1 is the vulnerable version. Google says only 4.1.1 is vulnerable. There are a handful of services on Android that use openssl and, I suppose, could present open ports for there to be an attack vector. See http://www.pcmag.com/article2/0,2817,2456507,00.asp
You can also MITM outgoing SSL connections and use heartbleed on them. The vulnerability is accessible before the certificate checks are completed, so the standard MITM prevention measures don't help you there.
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#38I have a few ubuntu servers. When I do a "check for heartbleed" check with various tools, it says they are not vulnerable. However, these servers were installed 6 months ago and not updated for at least 2 months. How can they not be vulnerable?
Most reports about Heartbleed kept repeating that the vulnerability was introduced 2 years ago (Dec '12, which isn't even 2 years - but anyway) it was committed to a version of OpenSSL (v1.0.1) that wasn't widely distributed until the middle of last year. The time surface of the Heartbleed attack is a lot smaller than what most think. Debian and the BSD projects moved to v1.0.1 earliest, around March/April last year.…
Fedora has been on OpenSSL 1.0.1 since maybe March 14, 2012 (that was when the .spec was bumped, anyway)[0]. So quite a long window for Fedora users, unfortunately.
[0]: http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?h=f18...
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#39This should be a useful tool on its own, but I wrote it primarily because the pattern-matching rules for Snort are inadequate. IDS vendors won't fix their stuff until I can prove they are inadequate. Ugh. In the old days the mantra of full-disclosure was "well, if we don't make exploit tools, then the vendors won't issue patches." And then it became "well, if we don't make exploit tools, then the sysadmins won't patc…
In this particular case, the bit about IDS isn't that ground breaking, it's just that the IDS checks for the malformed heartbeat request at the start of a packet, so instead he sends it at the end of a packet, namely appending it to the SSL handshake request. It's not like any hacker ever won't figure it out. I do agree with responsible disclosure for actual security holes, but this isn't it.
Re: Heartleech: Automated OpenSSL private key extraction tool using Heartbleed
#40This should be a useful tool on its own, but I wrote it primarily because the pattern-matching rules for Snort are inadequate. IDS vendors won't fix their stuff until I can prove they are inadequate. Ugh. In the old days the mantra of full-disclosure was "well, if we don't make exploit tools, then the vendors won't issue patches." And then it became "well, if we don't make exploit tools, then the sysadmins won't patc…
Granted, this is weapon grade quality. However, most checks for heartbleed out there could be considered weapon grade or at least not far off[1], this one does not add anything a somewhat experienced developer could not have added. This time, the bug is just too clear, too easily exploitable. I appreciate that someone saw the IDS signatures were inadequate and wrote a proof showing that.
[1] hey, they read some bytes of server memory, it's fairly simple to move on from there and read more.