I know I’m a little late to the game, but I figured I’d share my .02 regarding the most recent, and largest to date data breach…Equifax.
On September 7th, Chairman and and CEO Rick Smith of Equifax had the following video announcement. They discovered “unauthorized access” on July 29th, hired Mandiant, and now are disclosing that the breach jeopardized the personal information of 143 million American consumers’ data…potentially more than half of all Americans. Not good at all. To be specific, they also outlined that 209,000 credit cards were exposed as well as 182,000 people’s Personal Identifiable Information such as names, address, phone numbers, email addresses, etc for example). These were part of their ‘dispute documents’ which were leaked. All we know for sure is that Equifax stated “PII”. This was specific to US, Canadian, and UK consumers.
What makes this worse is that the CFO and two presidents of Equifax’s business units sold share between 3 and four days after the breach was discovered. Equifax reported that these people had no knowledge of the breach and were not subject to insider trading laws. At the same time, SEC filings show the sales worth 1.8 million were not pre-planned. Working for a publically traded company, General rule of thumb, is not to trade when the company creates a blackout period. In the event there is some non-public information they become subject to said blackout period until the announcement is made public. I can’t believe that a breach was detected, Mandiant was contracted, and at no time the CFO wasn’t made aware of this. Incident Response plans almost always notify HR, Finance, Payroll, Legal, and Marketing in the event of a serious incident. Either this is gross negligence or insider trading. Pick one.
An additional note: At this time there is no attribution as to who the attacker(s) are.
How it Happened
Well first off, I don’t work for Mandiant. I don’t have inside knowledge on this. However, I can guess. Originally, I was thinking Eternal Blue was still going strong so that’d be a strong possible candidate. However, Equifax is now stating that it was a “web application vulnerability on a US server”. Now with a little more information, I think a more probable guess would be the Apache Struts Remote Code Execution Vulnerability. Based on statements, I think the Struts RCE Vuln is more probable than a SMB exploit simply due to the statement that the corporate data was not affected. I believe this most likely affected their DMZ infrastructure rather than their corporate networks. Keep in mind the analysis is far from complete and this is all guesses based on hearsay.
The REST Plugin in Apache Struts2 is using a XStreamHandler with an instance of XStream for deserialization without any type filtering which could lead to Remote Code Execution when deserializing XML payloads. An attacker could use this flaw to execute arbitrary code or conduct further attacks.
What do I do now as a consumer?
It’s safer to assume your personal data is in the hands of bad-guys. Honestly, this is the way you should think regardless if your data was stolen or not. With that said, there are several things you can do. The first of which, I highly do NOT recommend.
Equifax is also offering their own program. Again, I DO NOT RECOMMEND IT. If you read the fine print, by using their service, you’re waiving any claim to sue in class action. Shady shady shady!
However, a few of the other things you can do which I DO recommend are:
- Pay attention to phishing and spam. You will undoubtedly be receiving email either from or regarding the data breach. Do not click on any links contained within the emails unless you 100% know and trust. This is a general rule applicable to all emails. Not just specific to the Equifax incident. Pay attention to syntax, spelling, URLs, etc. All are potential indicators of malicious phishing.
- Check your credit reports. I recommend you do this every three months regardless of identity theft risk. Keep an eye out for new accounts you didn’t open, late payments on debts you don’t recognize and anything else you don’t immediately recognize. If you see something, report it immediately. You can get You can get those reports here. (UK citizens can find links to credit agencies here.)
- Put a hold on your credit. It’s also known as a credit freeze. . It restricts access to your credit report which in turn makes it more difficult for identity thieves to open new accounts in your name. That’s because most creditors need to see your credit report before they approve or deny a new account. If they can’t see your file, they may not extend the line of credit. I should also mention that putting a freeze on your credit does not in any way negatively affect your credit score. This will not affect you from getting pre-screened offers for credit. In that case you can call call 888-5OPTOUT (888-567-8688) or opt-out online.
- Set fraud alerts. When a fraud alert is set, credit card companies are required to verify your identity before opening account. This along with a credit freeze is a good way to lock down your credit and personal identity. In order to set a fraud alert, you need to call one of the big three credit companies and ask for an alert. It will last 90 days. After that you need to call and renew the alert. It’s a hassle and the credit card companies do that on purpose. All you need to do is call one of the three
- Rinse and Repeat. Do this for your loved ones. I personally recommend putting a freeze on any children you have under 18. They don’t need their line of credit anyway and children are often used in identity theft and never know about it until it’s too late.
- File Your Taxes EARLY. Lots of people fall victim to identity theft at tax time. They go to file their taxes only to find out someone has already filed under their name. The best way to prevent this from happening is filing as early as possible. The IRS also has a guide to address tax fraud.
What do I do now as a InfoSec Department?
You don’t want to be the next headline on KrebsOnSecurity.com or CNN right? Well, here are just a handful of the recommendations I have regarding addressing this sort of attack situation.
- Patch Management. In this circumstance, the patch wasn’t released until September 7th (coincidence?).
- Application Control. Again, this wouldn’t have necessarily prevented the breach, but would have severely restricted the capability of the attacker and limited their ability to commence reconnaissance and lateral movement. that commands such as “powershell”, “cmd”, “cscript”, “echo”, “ftp” are particularly powerful and need to either be restricted, flagged, or vetted with either application control and least privilege solution.
- Credential Management. I talk enough about this as it is. This prohibits brute-forcing and lateral movement (a la pass-the-hash).
- Frequently changing.
- Systems Monitoring. Integrity monitoring solutions such as tripwire can detect an anomaly in the file integrity of a solution and would have been extremely helpful in alerting the event much sooner. Additional monitoring event logs with a SIEM would have been extremely helpful. Security Researcher C0mmand3rOpSec stated:
“Regardless of vuln…you shouldn’t have OS commands in your web requests/logs.”
- GDPR – The EU General Data Protection Regulation (GDPR) is the most important and significant change in data privacy regulation in 20 years. This is especially relevant to the UK consumer data that was leaked from the US based application server. I am far from a GDPR expert yet, but I do know that the controls specific to the GDPR may have prevented the exfiltration of UK consumer date.
No matter what happened, this is bad. It’s bad all the way around. It’s bad for consumers, and bad for Equifax. I think that proper security controls could have prevented this breach. At a minimum, I believe that notifications and warnings could have gone out much sooner that would have prevented the leaking of so much consumer data. I also think this could have been handled better. After the breach, Equifax has three different domains addressing the data breach:
First off, SEO trust is firmly established at Equifax.com. Why they’d stand up two different domains to address this issue boggles me. This opens up a huge risk to phishing. It would have been just as easy and more reputable to use Security2017.Equifax.com or something similar.
I believe that the incident response plans notifying business leaders was improperly followed or the leadership itself was grossly negligent. I believe this could have been prevented.