
Heartbleed Alexa top 10000 - jmacd
https://gist.github.com/dberkholz/10169691
======
tinalumfoil
Notable Sites:

yahoo.com indiegogo.com metacafe.com mybet.com nascar.com okcupid.com pch.com
paypal-community.com browserstack.com creditkarma.com nasa.gov twitpic.com

The others are mostly porn sites, link shorteners, non-english or others
people normally wouldn't have an account/put private data on. These are the
sites I feel have the most significance on the list, sorry if I missed any.

~~~
level
netflix.com is another big one

~~~
joshfraser
Netflix has been fixed.

------
belorn
This is the problem with a monoculture in security libraries. Back when the
gnutls vulnerability came up earlier this year, some people seriously stated
that we should only have one tls library and that would ensure the security of
it.

Find a vulnerability in a browser, and a minority subset of all users get
effected. Find a issue with openssl, and key to the kingdom is there.

~~~
rabino
Not sure I agree. More eyes in a library should mean it is more secure. I
guess.

Having 200 broken TSL libraries is security by obscurity. Not very useful, and
a pain for sysadmins.

~~~
bitwizzle
It's not security by obscurity. It's security by diversity, which is arguably
a good thing.

~~~
lugg
Security by obscurity is also, arguably, a good thing by your logic.

Seeing as someone didn't get it... Security by diversity is secure in the same
way something is secure by obscurity. In other words, its not, its just harder
to find the insecurity.

~~~
belorn
Security by diversity means that any extreme rare vulnerability will only hit
a few individuals. The trade is that there will be more unique vulnerabilities
found.

In risk management, having risk spread out is general a favored tactic. Same
is true in biology. The chance that remote memory access vulnerability is so
rare, that 200 libraries (if equally used) would lower the effected number of
people with a factor of almost 200.

~~~
lugg
I'm not exactly disagreeing with you here. I just dont understand how that is
different from obscuring your attack surface making you less likely to be
targeted by some sort of mass generic attack vector.

Nobody argues security through obscurity doesn't work in some form, we argue
that it doesn't make you secure as a matter of fact. Much like using some
obscure SSL implementation. It sure does have the net effect of making you
less likely to fall victim but that isn't security that is obscurity.

~~~
bch
It's not about "obscure SSL implementations", it's "alternative
implementations", and letting different projects theoretically play off each
others strengths and mitigating consumer risk similar to investing in an index
or mutual fund rather than all-in with any single entity.

Also, there's nothing wrong with security through obscurity, but please don't
let that be your _only_ security.

~~~
lugg
As someone else has already pointed out that could be better classified as
risk management than the way I originally put it.

The problem with security through obscurity is that it is _not_ security. Kind
of what people mean when they bring it up.. At least in my circles anyway.

It _is fine_ to have security through obscurity but you can't, much like the
alternative implementation scenario claim it makes you more secure as a
result. Its exactly like when apple claimed they were more secure and couldnt
get viruses like their PC counterparts.

That is what I was trying to bring to the conversation when I made my first
post. I get the feeling were starting to move off topic / split hairs over
words now so I'm going to leave it at that I dont think I can explain myself
any further.

~~~
bch
> The problem with security through obscurity is that it is not security.

I'm sure we'd like each other if we sat down over coffee, and would find more
in common than, not, but I have to politely disagree with you here. It _does_
offer a degree of security, and I can give you a challenge that is measurably
testable:

Move your sshd from 22 -> (eg) 222, and watch the hack attempts disappear.

Now, in the context of "remote logins", moving telnet from 23 -> 223 offers a
_degree_ of security from a casual person connecting to port 23 and trying
their luck, but we all know that telnet is a poor remote access tool these
days. Switching from telnet to ssh is security by technology (encryption,
mechanism (ie: keys vs passwords)). Moving sshd from port 22 -> 223 keeps that
many more people from knocking on the door, no matter what other security is
setup. "Security by Obscurity" adds to "Proper" security.

Surely we're both on the same page that, given better options, security
_solely_ through obscurity is stupid.

------
robododo
How many of these have gotten new server keys? How many have invalidated all
prior session ids and cookies?

I have a feeling heartbleed will haunt us for a while.

~~~
JshWright
Hopefully they patch OpenSSL before they roll their keys...

------
FooBarWidget
I'm sure all the serious sites will be updated soon. But what I'm more worried
about is all those routers. My home router has an admin interface that's
served over SSL. I'm not so confident in that manufacturers will push out
updates for those routers quickly, or that people will update them at all.

~~~
stormbrew
This is a mixed bag, but I'd bet your router's running an older version than
1.0.1.

------
jpmattia
Anyone check banks and financial institutions yet?

~~~
voltagex_
The big four (?) banks in Australia seem to not be affected. I'm fairly sure
they run IIS, anyway.

~~~
ezzaf
The largest Australian bank (commbank) was reporting as vulnerable on
filippo.io/Heartbleed/ for some hours after the vulnerability became known. GE
Money Australia haven't fixed their vulnerability yet either.

~~~
voltagex_
Ah, I thought commbank was on IIS. I checked it when I posted that message and
it came up green.

------
patrickxb
Side question: Alexa still exists? People install that extension in their
browser???

~~~
mkr-hn
It's an extension now. SEO people seem to like it for the quick look at
rankings.

~~~
Tloewald
The question is, how much are its ratings worth based on who is using it?

~~~
bonestamp2
When I look up my site on alexa, the traffic stats are pretty close to what my
analytics are telling me. So, they seem to be reasonably useful, if nothing
else in a relative form.

------
philip1209
A browser extension that warns of vulnerability would be amazing.

~~~
josh-wrale
If someone builds this, please do not make the client actively poll the sites
visited. Doing so seems likely, IMHO, to land you or even your users in jail
for Computer Fraud and Abuse violations (e.g. someone visiting
healthcare.gov).

[https://en.wikipedia.org/wiki/Morris_worm](https://en.wikipedia.org/wiki/Morris_worm)

If you do this, reference a centralized list/registry. Don't risk the
reputations of your users.

~~~
0xdeadbeefbabe
The fraud is that these vulnerable sites are risking their users' private
data, while pretending they are not.

~~~
josh-wrale
Security is a best effort thing. Get used to it. Make note of which providers
fell short here and act accordingly. Questions?

~~~
0xdeadbeefbabe
Imprisoning users who check for the vulnerability doesn't seem like a best
effort. It also doesn't seem likely.

~~~
josh-wrale
I see you're conflating my arguments. Anyway, I'll upvote you and step aside.

Edit: On second thought. Go ahead and conflate them. As I said, don't risk the
reputations of your users. That goes for everyone.

------
allochthon
I'm hoping to find a list of largish sites that were vulnerable to this bug
just prior to the recent disclosure, so that I can know how to prioritize my
password changing. (These forced password rotations are happening quite a lot
these days.)

------
ef47d35620c1
It's a client problem too. Many people are over-looking that.

~~~
iscrewyou
I've been looking everywhere for an answer but this may just be right place to
ask.

What can a user or a client do to protect itself? Sites can patch things up
(some sooner and some later). But meanwhile, what measures should the client
take while waiting for the sites to be patched up?

~~~
regecks
Ask whoever wrote your client software to rebuild it with a new version of
OpenSSL. Or, if its open source, try relink it yourself.

I guess through some convoluted MITM attack, somebody could (for example) try
and exploit your email client, or similar.

------
ArloL
Everyone should at least consider donating to the OpenSSL foundation:
[https://www.openssl.org/support/donations.html](https://www.openssl.org/support/donations.html)

~~~
rpearl
They write terrible, terrible code. Can I donate to some smart people looking
to replace OpenSSL with something reasonable?

------
elwell
Is there a quick way to test a site actively (i.e., without going and checking
the openssl version)?

~~~
jetpks
Yes. I've been using this tool:
[http://filippo.io/Heartbleed/](http://filippo.io/Heartbleed/)

It was published in a comment in one of the other heartbleed threads.

~~~
elwell
This tool is just great, thanks!

------
molf
So only a little over 12% is still vulnerable (and possibly ~30% not using
OpenSSL). And that number is still shrinking quickly. For example: Netflix,
Yahoo, NASA and OKCupid have updated in the mean time.

~~~
euphemize
I've just checked a bunch of sites on this list and it seems a lot have been
patched, only in the last hour since your comment.

~~~
Jare
Also note that many non-SSL domains will be using SSL in subdomains, e.g.
login.blahblah.com

------
sukuriant
So, these are dumb questions; but,

1) was this list made legally?

2) is viewing the list legal?

~~~
pilom
1.) If it was made in the US, probably not. Reading the memory of a webserver
would be pretty easy for a lawyer to argue is "unauthorized use of a computer
system." That is the basic definition presented in the Computer Fraud and
Abuse Act.

2.) I don't know enough to be able to argue one way or another on this point.
However, if you download the list or disseminate the list you are likely
increasing your possible exposure.

------
abc123xyz
Rapidshare is still vulnerable, search for "enc" session cookie, can login as
any user then by editing this cookie :D it also works via their api

fun fun fun

~~~
abc123xyz
Still works...

[http://i.imgur.com/RLXeySY.png](http://i.imgur.com/RLXeySY.png)

~~~
abc123xyz
[http://api.rapidshare.com/cgi-
bin/rsapi.cgi?sub=getaccountde...](http://api.rapidshare.com/cgi-
bin/rsapi.cgi?sub=getaccountdetails&cookie=3C2B008E27EB39EA76E1E328541B5621D5906F6083532179DC2522DD7F2299051490986E91AFE405562FC3773CB02AE1)

accountid=46048788 firstname=mandeep lastname=sihag servertime=1397038309
addtime=1359871506 username=heavenlybeast directstart=1 country=IN mailflags=n
language=en jsconfig= email=heavenlybeast@live.com curfiles=36
curspace=1213591844 rapids=0 billeduntil=0 nortuntil=0 maxspacegb=10
additionalspacegb=0 maxdaytrafficmb=100 additionaldaytrafficmb=0
traffictoday=20511350 accounttype=0 valid=1 payabo=0 promocode=0 promotype=0
promovaliduntil=0 maxfilesize=300000000

------
newman314
popsugar.com phpnuke.org toshiba.com torcache.net ucla.edu uiuc.edu
utorrent.com ifttt.com

------
3rd3
Would it make sense for everyone to change their passwords because of this?

~~~
carbocation
Many servers will still be vulnerable, so now you have 2 problems.

Zawinski meme aside, perhaps it would make sense to do it on a server-by-
server basis when the machines are verified patched. (Though, even then, how
do you know they aren't passing information back to an Internet-exposed-but-
unpatched database server?)

------
henryaj
Heh. Alexa.com is on the list.

------
maximux
I wish we could dump openssl and recompile all needed software to use polarssl

