Heartbleed attacks seen in March 23rd server logs?

http://www.seacat.mobi/blog/heartbleed

by semiel • 12 years ago

94 35 12 years ago

seacat.mobi

cpt1138• 12 years ago

DNS lookups of the servers that the requests came from:

54.186.135.68 ec2-54-186-135-68.us-west-2.compute.amazonaws.com United States flag United States, WA, Seattle

220.181.159.76 China flag China, 22, Beijing

54.193.75.203 ec2-54-193-75-203.us-west-1.compute.amazonaws.com United States flag United States, CA, San Francisco

5.61.43.116 Germany flag Germany

173.45.70.84 54.46.2d.static.xlhost.com United States flag United States, OH, Columbus

54.72.158.29 ec2-54-72-158-29.eu-west-1.compute.amazonaws.com United States flag United States, WA, Seattle

113.64.221.42 China flag China, 30, Guangzhou

83.222.250.151 . United Kingdom flag United Kingdom

62.210.125.141 62-210-125-141.rev.poneytelecom.eu France flag France

54.197.30.237 ec2-54-197-30-237.compute-1.amazonaws.com United States flag United States, WA, Seattle

80.82.70.118 hosted-by.ecatel.net Netherlands flag Netherlands

80.82.70.106 hosted-by.ecatel.net Netherlands flag Netherlands

209.126.230.70 internetsurvey-1.erratasec.com United States flag United States, CA, San Diego

183.60.244.46 China flag China, 30, Guangzhou

Aqueous• 12 years ago

An assortment of IPs? Seems like a botnet.

jacquesm• 12 years ago

Ecatel in a list like that is a really bad sign.

psykovsky• 12 years ago

Why is that? Their reputation isn't one of the best, where I come from...

malanj• 12 years ago

Wow - this seems really big: It basically means that someone was scanning the Internet for this vulnerability on 23rd March 2014 already. Maybe even before. That's two weeks before the vulnerability was published.

edit: I guess I'll actually have to change all of my passwords.

Terr_• 12 years ago

Just make sure you change them AFTER the services are fixed, or you'll simply be delivering your new ones into the hands of ten thousand scriptkiddies instead of a few uberhaxors.

0x03• 12 years ago

This submission should have a more attention grabbing headline! It's not just another SaaS asking users to change their passwords, this is actual (probable) evidence of the vulnerability being exploited weeks before being published.

Someone must have known about this and kept it secret for quite some time. And proceeded to scan huge parts of the internet.

Not surprising, considering the bug was found and published independently by two entities: Blackhats must also have found this one independently, too.

But now it's all that much harder to dismiss and delay password changes and key revocations.

semiel• 12 years ago

This submission should have a more attention grabbing headline!

Funnily enough, it looks like the mods changed the title to something more attention-grabbing. I left it with the original title because of HN's policies on titles, but apparently there is wiggle room.

Impressively, it got to #10 even with a bad title. Apparently people do read TFA!

hnha• 12 years ago

It is weird and discouraging to see the rules enforced so selectively.

gojomo2• 12 years ago

This sort of active exploitation, showing up in different teams' logs/honeypots, might help explain the nearly-simultaneous discovery by different researchers (Mehta at Google and others at Codenomicon) just recently.

tlrobinson• 12 years ago

Didn't someone say Neel Mehta found it through a code audit?

gojomo2• 12 years ago

Yes – https://news.ycombinator.com/item?id=7558015 – but not sure that wholly rules out the chance the audit of that code started because of other anomalies, which focused suspicion.

Would love more detail from each of the researchers, in their own words, even if the full story is still just a mundane variant of, "we're always reading code, we just happened to be reading this code this week, it looked buggy, we confirmed danger and reported to OpenSSL".

hackinthebochs• 12 years ago

This is at least somewhat reassuring to me--it means that we do have enough expertise out there being vigilant against their server logs such that attacks with serious implications can be identified in a matter of days/weeks. If people start finding evidence of exploitation in logs dating back a year, then I would really worry.

semenko• 12 years ago

ErrataSec, at least (their IPs are implicated in the logs) says this is a false-positive generated by the minimalist SSL implementation in masscan:

http://blog.erratasec.com/2014/04/no-we-werent-scanning-for-...

0x03• 12 years ago

Counterpoint: if the tool is 6 months old, why did these logs only show scans happening in the few weeks leading up to this bug's disclosure?

At this point I'd just assume the worst, and change all the passwords, keys and sessions.

mikeash2• 12 years ago

I thought that was just when their logs began. Presumably older ones were deleted.

tptacek• 12 years ago

If masscan does generate these false positives,

and masscan has been available for 6 months,

and masscan is widely used across the global internet,

then a log going back to January SHOULD have masscan false positives in them before March.

It seems like:

* Either Robert Graham is wrong that masscan can create these log entries (unlikely)

* masscan isn't used widely enough to ambiently generate errors since its release (maybe)

* This operator managed somehow to truncate or alter their log configuration (maybe)

* Some other heretofore unknown TLS scanning tool generates a different false positive (maybe)

* Some heretofore unknown entity knew about Heartbleed and scanned the Internet for it (maybe)

The evil unknown heartbleeder isn't the most likely scenario in this list.

snori74• 12 years ago

Yes, that's probably the case. Note that apparently MediaMonks also have logs which might show earlier exploitation too:

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intell...

nl2• 12 years ago

One interesting thing about Heartbleed that I don't think I've seen discussed enough is just how badly screwed anyone relying on SSL to protect against state-actor level monitoring is.

Assuming that state actors (at least NSA, possibly others) are engaging in bulk traffic collection against websites protected by HTTPS, and assume that the agencies used the heartbleed attack to grab as many private keys as they could.

Prior to Heartbleed you were protected. Now (unless the service used perfect forward) security the agencies can decrypt all your communications done under the old key (which usually means in the past 2 years).

sillysaurus32• 12 years ago

If you aren't using perfect forward secrecy, then presumably you don't care about that. If you do care about that, then you must use perfect forward secrecy.

I doubt that PFS will protect against the aforementioned parties, though.

nl2• 12 years ago

If you aren't using perfect forward secrecy, then presumably you don't care about that. If you do care about that, then you must use perfect forward secrecy.

Unfortunately, I think "you" that is affected by this and the "you" that needs to care enough to deploy PFS are two different people. And I suspect that in 99.999% cases the you that cares doesn't know about PFS or how to check if their service uses it.

I had to Google it, and knowing to look for "ECDHE" or "DHE" in the certificate information isn't something many would know.

gpvos• 12 years ago

PFS has only really been in the news since a few months. If you weren't a real security expert, you may not have known about it, even if you did care.

willvarfar• 12 years ago

So, if it wasn't the researchers who found the bug scanning for it, and this started after they found the bug, they'll now know they are compromised by other means by someone with the know-how to make use of this... Possibly by a bad apple, possibly technically. Scary.

yiedyie• 12 years ago

DD-WRT routers are also subject to this bug: https://news.ycombinator.com/item?id=7564041

This should be the biggest breach in the history of internet security.

At least when you knew that your communication was in plain text, you didn't transmit sensible data.

lxgr• 12 years ago

This is not really the topic of the blog post, but two statements confuse me:

SeaCat client for iOS and Java/Android is not affected since it is using other SSL implementation than OpenSSL (platform specific one)

Does this mean specific to SeaCat or to Android? If it's the latter: Android is using OpenSSL internally as its Java SSL provider, and Android 4.1.1 is vulnerable to Heartbleed.

and it is running in a client mode.

Doesn't Heartbleed affect OpenSSL in client mode as well?

Heartbleed attacks seen in March 23rd server logs?

Related Stories