Apache Struts probably means little to most people outside the software realm. CVE-2017-5638 even less so. But for credit company Equifax, these terms are likely reminiscent of what the people living in Troy must have felt when a giant wooden horse appeared at the gates of their city-state.
Circa 2017, some apocryphal stories claim that staff at Equifax’s headquarters in Atlanta, Georgia, used to share a running joke. ‘The company is just a hack away from financial ruin.’ Yet, at first glance, staff had little to fear. The credit-scoring company, founded just before the turn of the 20th century, had proved massively successful. Just two decades after its foundation, Equifax had offices throughout the United States and Canada. By the 1960s, the company had become one of the country’s largest credit bureaus. By then, Equifax’s archives had grown massively, holding financial information from millions of people.
Such accumulation of personal data had not gone unnoticed by regulatory bodies. In 1970, and shortly after Equifax created electronic records for all the information flowing through its corridors, the U.S. Congress held several hearings that directly led to the enactment of the Fair Credit Reporting Act (essentially, a charter that granted customers limited rights regarding personal information under the custodianship of corporate databases.)
But by holding so much financial data about so many people, Equifax had become a target of choice for those bent on exploiting those secrets.
‘We’ve been breached‘: How it happened
On March 8, 2017, Cisco staff found and reported a critical flaw in Apache Struts, an open-source framework that enables the creation of web-based Java applications. The vulnerability in question was identified as CVE-2017-5638. In short, Strut’s parser tool, Jakarta, could be manipulated to enable a malicious actor to upload files remotely to a server, and potentially run code on that compromised server.
Detecting a bug or vulnerability in a piece of software used by millions of people is not, in itself, uncommon. Internet Explorer, Mozilla Firefox, and countless other applications are routinely patched up to remove these problems. CVE-2017-5638 was no exception. The Apache Software Foundation issued a software patch, and the problem was quickly resolved.
Only in Equifax’s case, it wasn’t.
On March 9, IT staff at Equifax were advised to patch up their system, and here’s where the story becomes slightly obfuscating. It remains unclear why the company’s systems were not patched. Some claim that the member of staff who was supposed to carry out the task, did not. Whether this was intentional, or whether the patching operation failed, or the person didn’t know how to apply the patch remains unclear. The outcome was that Equifax’s Apache Struts framework remained unpatched, and thus, compromised and vulnerable. A second, unrelated issue exacerbated the company’s precarious position. Equifax, like many other companies, uses data sniffing tools that monitor encrypted traffic in and out of the network, precisely to detect data that might be exfiltrated illegally. But these tools require a public key certificate, which, by a cruel and unfortunate twist of fate, had expired some 10 months before, so the tool wasn’t inspecting the data properly.
The attack began on March 10, though Equifax would remain unaware of the breach until much later. From March to July of 2017, hackers had complete and unfettered access to the company’s financial records of millions of people. Reams of information were being taken right under Equifax’s nose, and the company didn’t have the first clue about it until July 29, when some network admins first realized that something was very wrong indeed.
In early September, the true scale of the catastrophe began to unravel. ‘We’ve been breached,’ was the message coming out of Equifax. Chief Executive Richard Smith called this unprecedented cyberattack the ‘most humbling moment in our 118-year history.’
Enter Self-sovereign identities: How would these have prevented the Equifax hack
The Equifax hack is a stark reminder of how the most sophisticated IT systems can be infiltrated by determined hackers if even a seemingly minor back door is left slightly ajar. To be fair, the Equifax data exfiltration, massive as it was, was the result of an unfortunate chain of events that led to the theft of tens of millions of personal records. So two questions arise: can this happen again, and could it have been prevented?
2017 is not so long ago, but it’s an eternity in digital terms. Technology evolves weekly. And one particular piece of technology, blockchain, has certainly evolved in leaps and bounds over the past four years. Blockchain (or decentralized ledger technology, DLT) is built around the concept of distributing information, data, around a network of nodes, with each node holding an identical copy of this dataset. In other words, it decentralizes information.
Equifax (and many other firms that have also fallen prey to hacks) were targeted because the millions upon millions of personal records were stored in single honeypot databases. Think of these databases as gigantic cookie jars. The temptation is just too great. And Equifax’s jar was overflowing with the good stuff.
Along with DLT comes Self-sovereign identity (SSI) a framework that empowers the individual to retain control and ownership of their personal data. We recently published two pieces on this very subject, SSI for Finance and SSI for the Enterprise. These provide additional background information on the SSI concept.
You can probably infer how SSI can prevent incidents like the Equifax debacle. By decentralizing that cookie jar, hungry hackers would no longer have just one single target to break into to sate their appetite. Now there would be hundreds, maybe thousands of nodes to break into. And the beauty of blockchain is that every node in the network is watching. If hackers attempt to tamper with one node, all other nodes would know right away, and take action. These two factors alone would prove disincentive enough.
Equifax is a credit scoring company. Its main business is to tell others what a person’s or business’s credit rating is, which would determine whether or not a third party engages in transactions with them. So there are three elements to this equation: Equifax, the individual or business whose credit history Equifax holds, and a third party that wants to find out what this score is (say, a mortgage company, or bank.)
Traditionally, the deal would work thus: The individual -let’s call her Harriet- wants to buy a car, so Harriet applies for a loan to her bank, which in turn consults Equifax to find out if Harriet is ‘safe’ to lend to (that is, she has no history of credit defaults, tax issues, or other financial issues that would raise questions about Harriet paying back the loan.) There’s a lot of paperwork involved, a lot of database searches, and a lot of queries. SSI frameworks would do away with all this cumbersome process through Decentralized Identifiers (DIDs), essential digital representations of Harriet, Equifax, and the lending institution. These DIDs are encrypted, and do not hold Harriet’s personal info. Just what’s relevant to her loan application. So Equifax -or any other such company- would no longer need to hold honeypot databases with millions of personal records. The cookie jar would be empty.
Equifax did not collapse. Its stock price did plunge by as much as 18.4% following the breach, but has long since recovered, and its shares are trading at around $179 at the time of writing. This is to say that the company survived a blow that would have outright knocked many other companies out of business. To be fair, SSI frameworks were not on any company’s radars in 2017. But they are now. Companies like Europechain, through its My.D identity platform can create infrastructures to prevent landmark events like Equifax from happening ever again.