Share Thread:  
HEARTBLEED: Yes, the NSA and probably everyone else knows all your passwords
Before the tinfoil hat shit goes out of control:
  • The heartbeat vulnerability is not a computer virus
  • There is nothing to check on your own home computer, because the problem exists on servers
  • You can use a few tools (like Chromebleed) to detect compromised servers
  • Don't change your passwords until you know your website owner has fixed the problem

The problem:

A programmer who worked on OpenSSL, which is very widely used because it's been considered mostly-harmless for so long, made a very rooky programming mistake.

SSL is actually a misnomer. The Internet is mostly secured with Transport Layer Security, or TLS. SSL (secure sockets layer) is what came before TLS. SSL was originally written by some smart people at Netscape back in the 90s who were trying to figure out how to do secure business transactions over the Internet using public key cryptography.

So this programmer who maintains TLS did not do any length checking of data that came in over the network port while copying it around in memory. Further, he trusted the user to specify what the heartbeat message was. We programmers call this "validation".

The reason why this bug was introduced? He was adding in a feature called a "heartbeat". This was added to OpenSSL to improve performance for users who need to send frequent bursts of data at short intervals but want to keep the network connection open. In order to do this, secure "heartbeat" messages are passed between you and the computer you connect to to leave the encrypted network channel open.

The trouble is, because of the way OpenSSL was programmed, you can send trash messages to the server. When they arrive at the server, the programming code doesn't check the bounds of the data and can overread past the point in memory where it is supposed to stop---reading some other part of memory where the program is running. Maybe another user's credit card information is in that memory location. You can overread up to 64KB of memory and the server will send the contents back to you, encrypted. Since you already hold the decryption key, it is trivial to decrypt the message and read the contents.

If you slam the server with enough requests, you can read all sorts of random locations in memory, collecting fragments and then sifting through them looking for chunks of sensitive information, like passwords and things like that. That's Heartbleed.

This vulnerability has existed in OpenSSL since December 2011 and was only discovered a few months ago. When the researchers published a script that easily demonstrates this exploit showing a Yahoo! user's login and passwords, they also collected a list of the Internet's Top 1000 websites and scanned them (most were vulnerable).

The problem is even worse than just sloppy bounds checking in a small piece of C code. The OpenSSL programers decided not to use the memory protection facilities found in most modern compilers and wrote their own. Given that they made this huge flaw in only 5 lines of C code, what else could be lurking in there? It is Open Source, so no doubt more people are auditing OpenSSL looking for more flaws like this and there will be more bugfixes and patches in the future.

This bug was out there for a very, very long time. No doubt plenty of blackhat security gurus might have known about the flaw, chose to say nothing, and took advantage of this flaw to extract crucial data. Google was vulnerable. If my target was a specific Google user, I could write a bot that keeps hitting Google for a year until that magic packet arrives with my target's username and password in it, then proceed to login and read their entire account plus perhaps a few snippts of their email traffic. There's no telling.

People also don't generally log every single network packet that enters and exits their systems (not enough disk space in the world for that), so unless you had the money to burn to buy entire rooms full of hard drives to store that much data to sift through it later looking for traces of this attack, you have no records to know whether someone attempted it or not.

One of the programmers who worked on a crucial C library used to compile most software had this scathing thing to say about OpenSSL:

You might be thinking to yourself: "Well, I use a Mac/Windows so I'm OK--those losers paid the price for using shitty software." The fact is is that Transport Layer Security is extremely complicated under the hood and it is very difficult to test, and no version of TLS is safe from bugs and flaws. Microsoft patches SSL/TLS regularly and it has had huge gaping flaws similar to Heartbleed appear and require midnight patches in a flash. Apple had to rush out a patch last year to all iOS devices and Macs. Linux machines often have to patch and repatch OpenSSL (or GnuTLS for those who use that TLS stack).

There's a big difference between reliable software and safe software. OpenSSL works very well and it is extremely reliable. But so are some DOS programs. Safety depends on how easy it is for an attacker to find and exploit a weakness, and almost all software that you use has some measure of un-safetyness about it.

This time around it wasn't desktop computer users running around like crazy, but almost every Internet server admin on planet Earth.

So, hopefully everyone has patched themselves, but if you're still worried about it, install Chromebleed:

Or if you don't trust a browser plugin, then use this site and hit it against your favorite websites to see if they're still vulnerable:
You can also download LastPass and it tells you what sites you have been to that have and have nit been patched, and lets you know when you need ti change your password as more sites become secure.
tolerance for failure meter... LOW
In order for somebody to use this to get your passwords, they would have to first exploit the site in question and get the private key. Easy enough after reading up on the problem. But then they would have to either spoof said website and get you to browse to it or they would have to sniff your traffic. Presumably the NSA can sniff your traffic as they are reported to be tapped into fiber everywhere. Your average hacker however would have a bit more difficult time pulling this off. Website spoofing on a public net IE coffee shop wifi would be their best bet.

In short, if all your surfing is from home or via mobile network you are probably safe from everything except the NSA. No different than any other day.
The law? The law is a human institution...

You don't need the server's private key to get at the data. You already have the server's public key and you sent the server your own public key for the server to pair up against the server's private key so you're already reading all the traffic from the server in plaintext anyway.

The bug is in TLS over the network socket. For the bug to "work", all you need to do is open any SSL/TLS session to a machine with the vulnerability and after the PX exchange (which most web browsers and web stacks already do), you then craft a garbage heartbeat message to keep-alive the SSL/TLS socket connection.

If the server is using 1.0.2 beta of OpenSSL or any release of 1.0.1-1.0.1f as the TLS stack, it will cause an overread of the memory location and the contents will be returned back to you encrypted using the certificate which you already have because you already exchanged keys with the server upon connecting.

Most TLS client stacks already take care of handling the crypto exchange for you and hand you a socket connection that auto-manages the TLS exchange for you so it appears to you exactly the same as an unsecured stack. All TLS stacks allow you to craft your own packets to send directly to the socket. In the OSI network model, TLS is usually level 5 on the stack or level 6 if it's all implemented in client software.

OpenSSL (libssl if you're looking at what to patch) source code is freely baked everywhere. Lots of embedded hardware runs it. I have a compromised printer in my house I can't do anything about it until Brother issues a firmware patch, but I don't send SecurePDF docs from my printer so I don't make use of the crypto shit the printer has on it. But it does answer port 443 and I already tested it for heartbleed and I was able to read some of the printer's memory.
Out of all the online shit I use I've only got like 5 emails today from service providers telling me they're either in the clear or they weren't vulnerable and it's a good idea to change passwords and rotate SSL certificates.

Asstons more companies have yet to say a thing. I noticed already Cisco was fucked by this. If you use Cisco AnyConnect to connect to your work office network--don't use the iOS client for a while til they patch it. It's busted. Since this vulnerability is broadcasted to the whole world, the safest bet is to not login to shit you know is not secure, that way your own data is likely to not be floating around in their server's memory to be extracted until they do patch themselves up and rotate SSL certs.

I've avoided logging into anything banking-related for a while. I figure at least a week before enough people get their act together it will be safe again for 80% of the shit that's out there.
Now's the tinfoil hat shit:

Even in perfectly coded TLS 1.2 (which everyone should be using), the weakest link are all the Certificate Authorities around planet Earth. GlobalSign/Verisign are not the default CA's in some countries and outside the United States there are plenty of other CAs which your browser trusts their certificates implicitly.

X.509 Certificates are not "regionalized", whereas the person handing you their certificate is confined to only certain CAs. I could be in Russia and hand you a GlobalSign certificate generated in the USA. Or I could be in Kenya and hand you a certificate I generated from a European CA.

It is up to each individual CA to validate the applicant who is requesting a sub-certificate for their internet domain and some are pretty shitty. Trusted root CA's have been "blacklisted" by operating system vendors in the past---usually by issuing security patches to remove those CAs out of your computer's trusted keystore.

Regionalizing root CAs and including a LOT more identifiable information about the requestor into the certificate when it is baked would go a long way to making SSL/TLS more trustworthy, even with a phone and an address that has to be validated regularly---say every 5 months---or the CA revokes. But X.509 is shitty when it comes to revoking trust and that's a whole other ball of wax.

In short, nothing is secure. Don't rely on SSL/TLS to encrypt your traffic. Sending self-encrypted shit through a SSL/TLS tunnel is far better than sending naked text through SSL/TLS, as long as you make sure you close down your network ports before you start running decryption or do the decryption somewhere else behind your DMZ.

More people should be auditing this shit. We have all these billions of dollars of cash floating around chasing the next shit startups but nobody can find the time to pay someone to peer back all the foundation code everything runs on.
I got two warning emails: my bank, and my online software for my practice. It appears that my bank has corrected things as I needed to double-verify when I signed in today. Is my assumption likely? My practice software/server said they weren't affected but urged us to change our passwords.
Lots of info about this here:


What versions of the OpenSSL are affected?
Status of different versions:
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

How common are the vulnerable OpenSSL versions?
The vulnerable versions have been out there for over two years now and they have been rapidly adopted by modern operating systems. A major contributing factor has been that TLS versions 1.1 and 1.2 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due to earlier attacks against TLS (such as the BEAST).

How about operating systems?
Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:
Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
CentOS 6.5, OpenSSL 1.0.1e-15
Fedora 18, OpenSSL 1.0.1e-4
OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
NetBSD 5.0.2 (OpenSSL 1.0.1e)
OpenSUSE 12.2 (OpenSSL 1.0.1c)
Operating system distribution with versions that are not vulnerable:
Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
SUSE Linux Enterprise Server
FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013
FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013
FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)


Heartbleed bug: Check which sites have been patched

Test your server for Heartbleed (CVE-2014-0160)

[Image: pa2aheartbleed_zpse70d9c3c.jpg]

[Image: pafoaheartbleed_zpsa93be19b.jpg]

Possibly Related Threads…
Thread Author Replies Views Last Post
  Obama Regime Demanding Web Firms Turn Over User Account Passwords… middlefinger 0 534 07-25-2013, 09:56 PM
Last Post: middlefinger

Users browsing this thread: 1 Guest(s)

Software by MyBB, © 2002-2015 MyBB Group.
Template by Modogodo Design.