Products + All Products + Software Integrity + Semiconductor IP + Verification + Design + Silicon Engineering
Posted by Amit Sethi on September 8, 2017
On Sept. 7, Equifax announced that attackers had stolen information from about 143 million people in the United States. Canadian and U.K. residents’ data was also stolen. However, Equifax has not yet revealed the number of people affected. We do not know the exact vulnerability that was exploited. Equifax stated only that “criminals exploited a U.S. website application vulnerability to gain access to certain files.” Whenever these types of events happen, it’s natural to ask questions such as what the vulnerability was, how this could have been prevented, and what lessons can be learned. Let’s try to answer some of these questions.
We don’t have much information about the exact vulnerability that was exploited. However, based on Equifax’s statement, it was probably a directory traversal vulnerability, a command injection vulnerability, or an insecure direct object reference vulnerability. All these are well-known web application vulnerabilities that can be used to get unauthorized access to files.
These types of events are generally the result of organizations not following secure software development practices. There are many layers in which problems can often be prevented but aren’t:
From a security perspective, Equifax’s response did not follow security best practices. They created a new website at https://www.equifaxsecurity2017.com/ that redirects users to https://trustedidpremier.com/eligibility/eligibility.html if they want to check whether their information was stolen. Neither website has an extended validation certificate. Users therefore have no idea whether these websites are truly affiliated with Equifax or were created by an attacker wanting to steal users’ information.
As a consumer who was curious about whether my information was stolen, I immediately noticed that these domains were not Equifax’s main domain, so I chose not to enter my personal information. Anybody can register a domain name containing “Equifax” and get a domain validation certificate for it. Organizations should not be encouraging users to enter personal information on unknown domains. Instead, it would have been much better to set up a site like https://www.equifax.com/breach so that users could clearly see that it belonged to Equifax.
As discussed above, breaches like this generally occur as a result of organizations not following secure software development practices. It is easiest and most cost effective to add controls early in the software development life cycle (SDLC). So performing architecture risk analysis or threat modeling early in the SDLC is critical. Many security issues can be prevented if the right architecture/design controls are added in the right places.
Developers should be trained in defensive programming so that they understand security vulnerabilities and how to prevent them. Developers and security teams should use static analysis tools that can help find implementation vulnerabilities. Code reviews and security testing should also be used to further reduce the likelihood of vulnerabilities ending up in production environments. Operations teams should keep a close eye on applications and watch for unusual behavior.
These are only a small subset of security activities that organizations should be performing. See the Building Security In Maturity Model (BSIMM) for a more comprehensive list of security activities. Also, keep in mind that you need to secure all your applications and systems.
Equifax stated, “We have found no evidence of unauthorized access to Equifax’s core consumer or commercial credit reporting databases.” This is not all that surprising. Organizations often focus on protecting their core systems but are laxer about applications/systems that they consider less critical.