As most of you probably already know, ten days ago security researchers disclosed a very serious vulnerability in the OpenSSL library, which is used to power HTTPS on most websites today. The bug allowed an attacker to extract information that was supposed to be private, including SSL private keys, login data or any other information transmitted via the web site.
It was one the first security vulnerabilities (code named HeartBleed) to receive massive media attention. Every webmaster in the world has probably heard about it (at least we hope so).
HeartBleed Vulnerable Servers in the Wild
After 10 days of massive coverage, we expected to see every server out there patched against it. To confirm our expectations, we scanned every web site listed in the Alexa top 1 million rank. Yes, we scanned the top web sites in the world to see how many were still infected.
The results were interesting:
Top 1,000 sites: 0 sites vulnerable (all of them patched)
Top 10,000 sites: 53 sites vulnerable (only 0.53% vulnerable)
Top 100,000 sites: 1595 sites vulnerable (1.5% still vulnerable)
Top 1,000,000 sites: 20320 sites vulnerable (2% still vulnerable)
We were glad to see that the top 1,000 sites in the world were all properly patched, and that just 0.53% of the top 10k still had issues. However, as we went to less popular (and smaller) sites, the number of unpatched servers grew to 2%. That is not surprising, but we expected better.
Do you own a web site? Did you check if your server is vulnerable? If not, please check to see if your server is vulnerable by clicking this link: https://filippo.io/Heartbleed/.
We also wrote a blog post with some suggestions on how to patch your server if you have access to it: Patching HeartBleed
HeartBleed Attacks in the Wild
With that many vulnerable servers, it’s a given that people will attempt to exploit them. To combat that, we added some detection signatures on our servers to alert us any time we detected an attempt to trigger the HeartBleed vulnerability. It flagged the pattern used by the public HeartBleed exploit tools, which have a similar format.
Over the last week, our servers detected 48,417 attacks against this specific vulnerability. The bulk of them coming from Amazon EC2 instances, likely setup to do these scans. These were the top attacking IP addresses and their counts:
Update: Some of these scans, specifically those coming from an IP address starting with 54., are coming from Amazon EC2. These scans are part of the online tool referenced above to check your site to see if it’s vulnerable to the Heartbleed bug. The scans attempt to exploit Heartbleed to see if a site is vulnerable and are very unlikely to be malicious. However, if they reveal a vulnerability in a website, they illustrate that a website is susceptible to further attacks, like the 20,320 websites in the top million that are still exposed.
3809 SRC=141.212.121.193
1393 SRC=107.3.148.68
1084 SRC=216.200.166.3
974 SRC=54.82.84.163
954 SRC=54.82.248.65
929 SRC=54.242.172.173
926 SRC=50.16.96.85
925 SRC=54.82.248.31
921 SRC=54.221.162.7
919 SRC=75.101.243.125
912 SRC=54.221.166.250
905 SRC=54.81.153.80
891 SRC=54.227.161.5
877 SRC=54.198.5.96
867 SRC=54.82.205.119
865 SRC=54.234.12.248
862 SRC=54.227.94.136
860 SRC=54.82.249.111
827 SRC=213.175.105.1
639 SRC=23.22.245.215
If you are not patched, be aware that people are out there trying to test and exploit this vulnerability and get your server patched as quickly as possible.
Rianna MacLeod
Ben Martin
Luke Leal
Justin Channell
Art Martori
Denis Sinegubko
Peter Kankowski
3 comments
But that doesn’t include the 1,111,000 attack scans against sites that you ran right?
A scan to test the vulnerability doesn’t run the exploit for the vulnerability.
It’ s a probe packet, banner captured based, to retrieve information about version and configuration exposed.
Obviously the problem with heartbleed itself hasn’t been stated plainly enough:
If you _EVER_ had ANY SSL service (client or server!) that was running with a “heartbleed”-enabled version of openssl (or any of the follow up vulnerabilities), then you a) do have to patch to current _secure_ version of openssl and THEN b) replace all your client and server ssl certificates (ie. get or create new ones) on all services that use openssl for transport crypto.
The quality delivered is about the same as the “sitecheck.sucuri.net” website. Little hint there: Check for vulnerabilities, NOT some versions by upstream provider of software.
But I guess since the site is about fearing people into buying services from you, it is something that will never show (even though it is easily doable for the most part).
Too bad people use services like your company’s and then spread the lies being reported back as truth onto other services by other companies, which then just leaves a stinking pile of dung in the final data delivered, that is bigger the further you are away from the original website delivering bad data.
Read it, and then delete it or publish this comment, as you will. But know the implications it has even on your business to openly misinform people about vulnerabilities not there (or, at the least, using lenience where it is not due, to increase your quarterly statements).
Comments are closed.