Heartbleed attacks seen in March 23rd server logs? | Hacker News Reader

Heartbleed attacks seen in March 23rd server logs?

seacat.mobi

94 pointssemiel35 comments

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

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.

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

It looks like they had been logging since January and it only started a few weeks ago;

>We haven't observed this during Jan, Feb and first half of March.

Thanks for the quote. You read better than I, clearly.

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.

"Although this is painful for the security community, we can rest assured that infrastructure of the cyber criminals and their secrets have been exposed as well." http://heartbleed.com/

Sounds like they may have scanned the whole internet themselves.

Google reissued their cert on 12 Mar. I assume that is when they discovered it?

I don't know how often they've reissued their certificate in the past, but the certificate's good for almost exactly 90 days. (89.6, to be exact.) Perhaps it was simply time to make another?

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

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.

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

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

Weird? Really? You want an article called i.e. "jQuery destroys your website" to get as much relevance as this one? people don't have time to read every single article, they want to skim and focus on the important ones (or at least important for them)

It's insane to expect rules to be set apart from their real-life priority: It would be like asking for the same journalistic standards from a war journalist and from fashion magazines for teenage girls.

It's insane to expect rules to be set apart from their real-life priority

But that is how the rules have been enforced, until recently. Expecting consistent behavior is not insane. Not knowing what the title of your submission will be after you submit it is insane!

Rules exist for the sake of organization (not the other way around), therefore they have exceptions, like when the police kills an armed criminal despite murder being a serious crime.

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

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.

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.

Yeah, it's pretty crazy that it's so difficult. It's one of those problems that few people want to make easy.

I ordered something online yesterday, and checked the cipher settings. Turns out my bank doesn't have PFS, and a well-known French payment provider (Paybox) even uses the insecure RC4 cipher.

If the browsers let users who click on the padlock know that it's insecure, the providers would have an incentive to upgrade.

For Firefox, people have reported bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=956744

https://bugzilla.mozilla.org/show_bug.cgi?id=947149

but they don't seem to be getting much attention. Hopefully Heartbleed will help speed things up.

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.

PFS is nothing new, IPsec introduced it in RFC 2412 (November 1998). Benefits of using PFS have been clear since that. Also SSLv3 supports PFS cipher suites. But just as usual, even if something is available, it doesn't mean it's generally adpoted for extended use.

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

An assortment of IPs? Seems like a botnet.

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

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

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.

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.

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.

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

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

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.

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?

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.

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.

Reply on news.ycombinator.com