“WAF Prevents Massive Data Breach at Equifax”… The headline that could have been, but wasn’t…

The entire Equifax saga is quite popcorn worthy in a way, with the daily revelations of new events and actions. That is, if you aren’t one of the roughly 50% of Americans who are affected by the hack.

From what we know now, Equifax was first hacked in early March. While details of how this breach happened are not available now, this primarily affected the API that banks and other institutions used to interact with Equifax. This was limited in impact and seemed to affect only a few persons. The big hack, however, happened later between mid-May and the 29th of July. This hack was the one that led to the data breach of roughly 143 Million records. Once Equifax identified the hack, they worked with an external firm to identify how this issue happened and released a breach notification on the 8th of September.

Post the breach, multiple issues came to light that made the entire situation worse. We’ll focus only on the ones that deal with security in general.

The first was a site that Equifax set up for people to identify if they were hacked. This site had a domain name that looked more like the URL of a phishing site – equifaxsecurity2017.com. The site was a stock WordPress site, with the admin user database open to the world. The site itself collected the last 9 digits of the user’s SSN’s & their last names. Given that the first 3 are the area number, this led to a caution against using the site, in case this data was stolen as well. The site itself used a free SSL certificate from Cloudflare, and OpenDNS blocked it as a phishing site for some time before this was remedied.

On the 9th of September, it was revealed that hackers exploited a vulnerability in the Struts framework on the Equifax website. This vulnerability had been revealed in March, along with a fix. Given that the patch was available for some time before the hack, the entire saga could have been prevented by testing and applying the patch in time.

Three days after the breach announcement, a new issue was discovered with the Credit Freeze process. The PIN generated by the system to set the Credit Freeze was simply the timestamp of the request for a freeze. Given that it was only 3 days since the hack was revealed, if anyone had frozen their credit in this time, it would have been very easy for hackers to brute-force the PIN and unlock the credit report!

Worse news followed on the 12th of September. The Equifax site that is used to set up credit monitoring had a Reflected Cross-Site Scripting vulnerability. This vulnerability could easily be exploited to steal the personal data of anyone who used to site, leading to further harm.

All of these problems have been caused by one vulnerability in the main website. The Apache Struts vulnerability had been fixed – but the site was hacked before it was patched. And we see these issues time and time again. Websites take some time to patch a vulnerability, they get hacked. And hackers have become smarter and have automated this type of hacking. Take the Coastal Credit Union, for example. Their site was hacked, a backdoor was placed, but not exploited. Why? Because someone ran an automated script to scan all sites with a specific vulnerability, the script found these sites, hacked them and left a backdoor for later use. This is something that we see more often than not.

 

Hey @barracuda why don’t you and @Equifax do business? pic.twitter.com/bNkDCmdx4p

— Nick Pericle (@nickpericle) September 25, 2017

While diligent patching is required, sometimes, it takes a while to test a patch and get it into production. These days, hackers wait for a company to release the patch; they then use the information in the release notes to build the tools to perform automated hacking campaigns. They can hack tens of thousands of sites during these campaigns, and cause widespread destruction. No site is too small – and not all hacks are about the business owning the site. Some of them are to build command & control servers for various malware, like Sathurbot.

Old software vulnerabilities are the gifts that keep giving. This is the reason why HeartBleed and ShellShock vulnerability scans are still being run by malicious actors, years after these major vulnerabilities have been fixed. Patching for a very new vulnerability is like trying to hit a fast-moving target. So what can you do? You can deploy the Barracuda Web Application Firewall. The Barracuda Web Application Firewall protects your web, mobile and API-based applications from all application attacks, including OWASP Top 10, Application DDoS and more. It has both negative (signature-based) and positive (application learning based) security, that protects against all known and unknown (zero day) vulnerabilities. Easy to deploy and maintain, it is your best defense against being Equifaxed.

 

Additional Information

Barracuda Vulnerability Manager and Barracuda Vulnerability Remediation Service: The Barracuda Vulnerability Manager (BVM) is a cloud-based solution that pinpoints vulnerabilities in your websites and web applications quickly and easily—even if you don’t have extensive knowledge about website security. It provides in-depth insight into the vulnerabilities that expose your institution to attacks from inside and outside the organization.

The Barracuda Vulnerability Remediation Service (BVRS) is a free add-on to the Barracuda Web Application Firewall. The BVRS enables automatic scanning, remediation, and maintenance of web application policies.

Barracuda Cloud Ready Initiative: Migrating workloads, apps, and data to the cloud can make your business more responsive and agile, and make it easier to scale rapidly as opportunities arise. Barracuda’s “Cloud Ready” initiative is intended to eliminate those concerns and help you move to the cloud faster, more cost-effectively, and with greater confidence.

 

---

Tushar Richabadas is a Product Manager for the Barracuda Web Application Firewall team in our India office. You can connect with him on LinkedIn here.