
Heartbleed attacks seen in March 23rd server logs? - semiel
http://www.seacat.mobi/blog/heartbleed
======
semenko
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-...](http://blog.erratasec.com/2014/04/no-we-werent-scanning-for-
hearbleed.html)

~~~
0x0
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.

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

~~~
shimon_e
"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/](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?

~~~
btgeekboy
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?

------
0x0
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
> 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
It is weird and discouraging to see the rules enforced so selectively.

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

~~~
sp332
_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!

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

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

~~~
sillysaurus3
_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.

~~~
nl
_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.

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

~~~
firefox_citizen
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=956744)

[https://bugzilla.mozilla.org/show_bug.cgi?id=947149](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.

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

~~~
jacquesm
Ecatel in a list like that is a _really_ bad sign.

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

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

------
gojomo
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
Didn't someone say Neel Mehta found it through a code audit?

~~~
gojomo
Yes –
[https://news.ycombinator.com/item?id=7558015](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".

------
lxgr
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?

------
yiedyie
DD-WRT routers are also subject to this bug:
[https://news.ycombinator.com/item?id=7564041](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.

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

