Heartbleed Alexa top 10000
gist.github.com
gist.github.com
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.
There are a couple of big european retailers in the list (darty, castorama).
edit: I contacted the developers and they were super fast to patch everything, roll keys, etc. It's contained now.
(www)gatech.edu (www)ucla.edu (www)uiuc.edu
I mean really? These are top engineering schools too.
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.
Having 200 broken TSL libraries is security by obscurity. Not very useful, and a pain for sysadmins.
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.
It's harder to get a generic exploit that will give you access to a lot of targets. But I'd argue that finding an exploit for a particular target would be easier.
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.
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.
Also, there's nothing wrong with security through obscurity, but please don't let that be your only security.
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.
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.
Lets make an analogy of an investor. If person invest in a single company and it goes bankrupt, the investors might loose his roof over his head and the food on the table. This in turn effects his personal security.
In order to mitigate this risk, he uses risk management to diversify his risks. He might not be able to spend the same amount of time per investment and this increasing the general risk, but high risk events like bankruptcy is spread out and is unlikely to cause a large impact.
How many more libraries do you think will provide adequate security?
Sadly, even if those options are available, gnutls is not common on the web, and https with pgp is even less common. Worse, some propose that we should use such options less in favor of one and only one library in the name of security.
I have a feeling heartbleed will haunt us for a while.
We're going to have fallout from this for at least the rest of this year and well into the next.
https://en.wikipedia.org/wiki/Morris_worm
If you do this, reference a centralized list/registry. Don't risk the reputations of your users.
Edit: On second thought. Go ahead and conflate them. As I said, don't risk the reputations of your users. That goes for everyone.
javascript:void(open('http://filippo.io/Heartbleed/#'+document.location.hostname))
https://chrome.google.com/webstore/detail/shodan/jjalcfnidlm...
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?
I guess through some convoluted MITM attack, somebody could (for example) try and exploit your email client, or similar.
It was published in a comment in one of the other heartbleed threads.
1) was this list made legally?
2) is viewing the list legal?
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.
fun fun fun
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
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?)
Otherwise, insist that the site owners invalidate all existing sessions.