Heartbleed Alexa top 10000(gist.github.com)
gist.github.com
Heartbleed Alexa top 10000
https://gist.github.com/dberkholz/10169691
20 comments
Airbnb.com apache.org dreamhost.com ifttt.com wer ones I noticed.
There are a couple of big european retailers in the list (darty, castorama).
There are a couple of big european retailers in the list (darty, castorama).
Ha, what sort of idiot would have private data on a non-English site? Oh wait, that would be the majority of the population of the planet.
Avast is pretty bad given that they make virus protection
As of earlier this morning Amazon.com was also vulnerable. OkCupid is also on this list.
slack.com
edit: I contacted the developers and they were super fast to patch everything, roll keys, etc. It's contained now.
edit: I contacted the developers and they were super fast to patch everything, roll keys, etc. It's contained now.
jd.com is huge in China.
Notable edu sites:
(www)gatech.edu (www)ucla.edu (www)uiuc.edu
I mean really? These are top engineering schools too.
(www)gatech.edu (www)ucla.edu (www)uiuc.edu
I mean really? These are top engineering schools too.
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.
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.
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.
Having 200 broken TSL libraries is security by obscurity. Not very useful, and a pain for sysadmins.
It's not security by obscurity. It's security by diversity, which is arguably a good thing.
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.
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.
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.
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.
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.
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.
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.
Also, there's nothing wrong with security through obscurity, but please don't let that be your only security.
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.
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.
> 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.
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.
Then you're advocating risk management, and not security.
Risk management and security is two sides of the same coin.
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.
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.
It's not harder to find the insecurity. At all.
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.
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.
There is OpenSSL, nss, and GnuTLS. That's 3. Two of those have had major breaches this year.
How many more libraries do you think will provide adequate security?
How many more libraries do you think will provide adequate security?
If each of those where equally used, and same with different key handling system, security by diversity would help. For example, the gnutls vulnerability only effected x509 resolving of the certificate chain, so those handful of people who use the pgp model were not effected.
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.
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.
[deleted]
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.
I have a feeling heartbleed will haunt us for a while.
Hopefully they patch OpenSSL before they roll their keys...
This will be similar to the trendnet webcam "/anony/mjpg.cgi" ordeal. To this day there are still many webcams on the internet that can be viewed by anyone and the owners of the webcam have no idea whatsoever.
We're going to have fallout from this for at least the rest of this year and well into the next.
We're going to have fallout from this for at least the rest of this year and well into the next.
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.
This is a mixed bag, but I'd bet your router's running an older version than 1.0.1.
Home routers have bigger issues to worry about before they get to Heartbleed.
Hah, I'd be glad if my router used SSL. If anyone wants to fire up binwalk and run it over a few router firmwares, it'd make for an interesting blog post.
Not sure if routers use TLS or just some utilities of OpenSSL. Could anyone confirm?
my ASUS router uses the 1.0.0 branch so it shouldn't be vulnerable to this bug
Anyone check banks and financial institutions yet?
The big four (?) banks in Australia seem to not be affected. I'm fairly sure they run IIS, anyway.
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.
Ah, I thought commbank was on IIS. I checked it when I posted that message and it came up green.
My bank (PC Financial) has been offline all evening. I wonder if it's related.
UK Barclays is vulnerable.
Side question: Alexa still exists? People install that extension in their browser???
It's an extension now. SEO people seem to like it for the quick look at rankings.
The question is, how much are its ratings worth based on who is using it?
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.
Exactly.
A browser extension that warns of vulnerability would be amazing.
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
If you do this, reference a centralized list/registry. Don't risk the reputations of your users.
https://en.wikipedia.org/wiki/Morris_worm
If you do this, reference a centralized list/registry. Don't risk the reputations of your users.
The fraud is that these vulnerable sites are risking their users' private data, while pretending they are not.
Security is a best effort thing. Get used to it. Make note of which providers fell short here and act accordingly. Questions?
Imprisoning users who check for the vulnerability doesn't seem like a best effort. It also doesn't seem likely.
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.
Edit: On second thought. Go ahead and conflate them. As I said, don't risk the reputations of your users. That goes for everyone.
Right but exploiting Heartbleed to dump memory of the target webserver is most likely "unauthorized use of a computer system" and thus in violation of the CFAA.
Can't you just check if heartbeat is enabled and poll what version of library is used? If no, could you check by setting the payload size lower than the payload? That way you know the site is vulnerable without receiving anything you shouldn't have received.
I'm updating the Shodan Chrome plugin atm to show the data that it's collecting on heartbleed:
https://chrome.google.com/webstore/detail/shodan/jjalcfnidlm...
https://chrome.google.com/webstore/detail/shodan/jjalcfnidlm...
This bookmarklet works for me:
javascript:void(open('http://filippo.io/Heartbleed/#'+document.location.hostname))
javascript:void(open('http://filippo.io/Heartbleed/#'+document.location.hostname))
There's this, but I haven't tried it yet: https://github.com/PwnicornDev/heartbleed-test.crx
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.)
It's a client problem too. Many people are over-looking that.
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?
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?
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.
I guess through some convoluted MITM attack, somebody could (for example) try and exploit your email client, or similar.
Everyone should at least consider donating to the OpenSSL foundation: https://www.openssl.org/support/donations.html
They write terrible, terrible code. Can I donate to some smart people looking to replace OpenSSL with something reasonable?
Is there a quick way to test a site actively (i.e., without going and checking the openssl version)?
Yes. I've been using this tool: http://filippo.io/Heartbleed/
It was published in a comment in one of the other heartbleed threads.
It was published in a comment in one of the other heartbleed threads.
This tool is just great, thanks!
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.
So, these are dumb questions; but,
1) was this list made legally?
2) is viewing the list legal?
1) was this list made legally?
2) is viewing the list legal?
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.
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.
The answer to (2) is Yes regardless of what is the answer to qestion (1).
Yes, it's entirely legal.
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
fun fun fun
Still works...
http://i.imgur.com/RLXeySY.png
http://i.imgur.com/RLXeySY.png
http://api.rapidshare.com/cgi-bin/rsapi.cgi?sub=getaccountde...
accountid=46048788 firstname=mandeep lastname=sihag servertime=1397038309 addtime=1359871506 username=heavenlybeast directstart=1 country=IN mailflags=n language=en jsconfig= [email protected] 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
accountid=46048788 firstname=mandeep lastname=sihag servertime=1397038309 addtime=1359871506 username=heavenlybeast directstart=1 country=IN mailflags=n language=en jsconfig= [email protected] 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
popsugar.com phpnuke.org toshiba.com torcache.net ucla.edu uiuc.edu utorrent.com ifttt.com
Would it make sense for everyone to change their passwords because of this?
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?)
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?)
If you logged in (as in, typed your username and password) in to the site during the time the exploit has been disclosed and the site has been vulnerable, I would change your password.
Otherwise, insist that the site owners invalidate all existing sessions.
Otherwise, insist that the site owners invalidate all existing sessions.
Heh. Alexa.com is on the list.
I wish we could dump openssl and recompile all needed software to use polarssl
[deleted](1)
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.