I don't like the EmergingThreat rules, not so much because of the rules themselves but because of the mentality of the people who use them. I scan the entire Internet. When I get clueless abuse complaints, such as "stop scanning me but I won't tell you my IP address", they usually come from people using the EmergingThreat rules. This encourages me to evade those rules.
The latest example is the Heartbleed attack. Rules that detect the exploit trigger on the pattern |18 03| being the first bytes of TCP packet payload. However, TCP is a streaming protocol: patterns can therefore appear anywhere in the payload, not just the first two bytes.
I therefore changed masscan to push that pattern deeper into the payload, and re-scanned the Internet. Sure enough, not a single user of EmergingThreats complained. The only complaints from IDS users were from IBM sensors with the "TLS_Heartbeat_Short_Request" signature, and from some other unknown IDS with a signature name of "Heartbleed_Scan".
That the rules can so easily be evaded is an important consideration. Recently, the FBI and ICS-CERT published advisories, recommending IDS signatures to detect exploits of the bug. None of their recommended signatures can detect masscan. I doubt these organizations have the competency to understand why, so I thought I'd explain it in simple terms.
Showing posts with label heartbleed. Show all posts
Showing posts with label heartbleed. Show all posts
Monday, April 28, 2014
Wednesday, April 09, 2014
Why heartbleed doesn't leak the private key [retracted]
I got this completely wrong!
So as it turns out, I completely messed up reading the code. I don't see how, but I read it one way. I can still visualize the code in my mind's eye that I thought I read -- but it's not the real code. I thought it worked one way, but it works another way.
Private keys are still not so likely to be exposed, but still much more likely than my original analysis suggested.
Private keys are still not so likely to be exposed, but still much more likely than my original analysis suggested.
600,000 servers vulnerable to heartbleed
Just an update on "HeartBleed". Yesterday I updated my "masscan" program to scan for it, and last night we scanned the Internet. We found 28,581,134 machines (28-million) that responded with a valid SSL connection. Of those, only 615,268 (600-thousand) were vulnerable to the HeartBleed bug. We also found 330,531 (300-thousand) machines that had heartbeats enabled, but which did not respond to the heartbleed attack. Presumably, this means a third of machines had been patched by the time we ran the scan last night.
Update: Some people have described this as "only 2% vulnerable". That's an unfair way of describing it. We scanned IP addresses. There are millions of IP addresses where port 443 traffic is redirected to a single load balancer. This throws off our counts.
Update: Some people have described this as "only 2% vulnerable". That's an unfair way of describing it. We scanned IP addresses. There are millions of IP addresses where port 443 traffic is redirected to a single load balancer. This throws off our counts.
Yes, you might have to change some passwords (#heartbleed)
There is some debate over whether this "HeartBleed" bug means you have to change your password. It might.
The HeartBleed bug grabs some random bits of memory. If a hacker wrote a script that would repeatedly query "login.yahoo.com" a thousand times per second, they'd probably get a hundred usernames/passwords per second.
Usernames and passwords go in HTTP requests just like cookies and URLs. If one is exposed, then so is the other. As I posted yesterday, here is a picture of grabbing part of a session cookie from a real website (Flickr, one of Yahoo's properties):
Luckily, sessions remain open for weeks, but the bug was only open for a couple of days. The only passwords you need to change would be ones that you entered in the last couple of days. Personally, I haven't entered any passwords over the last couple days, so I don't need to change any passwords.
At most, since hackers could have stolen the session cookies, you might want to log out and relogin to sessions on vulnerable servers.
From this article:
The HeartBleed bug grabs some random bits of memory. If a hacker wrote a script that would repeatedly query "login.yahoo.com" a thousand times per second, they'd probably get a hundred usernames/passwords per second.
Usernames and passwords go in HTTP requests just like cookies and URLs. If one is exposed, then so is the other. As I posted yesterday, here is a picture of grabbing part of a session cookie from a real website (Flickr, one of Yahoo's properties):
Luckily, sessions remain open for weeks, but the bug was only open for a couple of days. The only passwords you need to change would be ones that you entered in the last couple of days. Personally, I haven't entered any passwords over the last couple days, so I don't need to change any passwords.
At most, since hackers could have stolen the session cookies, you might want to log out and relogin to sessions on vulnerable servers.
From this article:
"I would change every password everywhere because it's possible something was sniffed out," said Wolfgang Kandek, chief technology officer for QualysThis is nonsense. If you didn't type in your password over the last few days, then you are likely safe. I've got hundreds of accounts, I'm changing none of them, because I didn't have to relogin over the last few days. I had persistent sessions.
Subscribe to:
Posts (Atom)