Tough Week for Security on the Internet

A bunch of items that are sitting on a motorcycle

Have you ever had a week where you want to throw your computer in the trash?  Well, for security-minded netizens, this might have been one of those weeks.  This week has seen two major security issues surface that impact a large number of the internet's users.

Google Finds a SHA1 Collision - First blow to Security

The first exploit this week, you can thank Google for disclosing.  SHA1, which is one of the tools available to run a "hash" on files, has encountered the first ever documented collision.  "Why does this matter?" I hear you saying.

One reason this is an issue is because a SHA1 hash is commonly used to check that a file has not been changed or modified.  Even adding an extra space completely changes the SHA1 value of a file and now that Google has proven it is possible to effectively forge the SHA1 hash,  malicious users can now, given enough processing power, inject dangerous code into a file and have it pass SHA1 hash checks.

Another issue that stems from this exploit is password validation for some sites.  SHA1 was considered to be superior to MD5 (another hash algorithm) because it had not yet had a hash collision, but it is still considered a lazy way to do password encryption.  Going into proper methods for encrypting password hashes is a topic for another blog post, but suffice it to say, while it was not best practices, many sites and providers used SHA1 for the speed.

Any service or system that uses SHA1 is susceptible to this issue, and unfortunately, there is no way to fix SHA1.  Services/Systems will need to upgrade to a different hash algorithm.

This exploit isn't new news.  It has been theoretically possible for a while, and most (if not all) SSL Providers switched from SHA1 to  SHA2 family of functions in January 2016.

Actually taking advantage of this exploit does require an extreme amount of processing, but can be lessened by using GPU Assisted Cracking and Clustering.

Just when google thought they had made the largest security news for the week, CloudFlare decided to take it up a notch with CloudBleed.


CloudFlare Suffers from CloudBleed

CloudBleed is similar to the HeartBleed exploit found in 2014, but it only impacts sites that used CloudFlare Proxy Services.  This means sites that use CloudFlare strictly for DNS (like us) are not impacted.

XKCD does a really good explanation of HeartBleed here.  You can assume that CloudBleed works along the same lines.

CloudBleed worked in the same way HeartBleed did, but because CloudFlare serves sites from all around the world, you could have had data from a  site on another server show up as garbage on your CloudFlare enabled site.

This exploit was a part of a new HTML parser that CloudFlare had been migrating to, called CF-HTML. It was first implemented as a part of the 'Automatic HTTP Rewrites' feature on September 22, 2016.

CF-HTML was also a part of the 'Email Obfuscation' and 'ServerSide Excludes' features.  As soon as Google's Project Zero notified CloudFlare, action was taken and approximately 40 minutes after the report.  Impacted services were disabled for users to prevent further data leak.

The largest impact for sites was on February 13th, 2017 with a peak of ~3500 websites.

The full technical explanation of CloudBleed can be found here.

The good news is, at least at this time, that the impact was limited to mostly small, forgotten websites. 

The not so good news is that some sites that had data dumped on their pages have been cached in popular search engines like Google and Bing.

What do I need to do?

Chances are, nothing.  

If you are worried that your credentials might have been leaked on a website that uses CloudFlare, go ahead and change your passwords.  It won't hurt anything, and it is good practice to rotate/change your password regularly.  If you have the ability to use 2-factor authentication, I recommend doing so.  More so because passwords are weak than because of this exploit.

If you are worried your site was compromised by CloudBleed, change any security keys you might use, and force all your users to re-login and change their passwords.  ( An easy way for WordPress users to generate new salt keys here.)