As you have doubtless heard by now, last Thursday news emerged of a major breach at the US credit referencing agency, Equifax. Although the company themselves have been reticent to provide many public details, what is known is that attackers were able to access internal databases and the details of up to 143 million people. There has been a raft of coverage regarding this incident in the US press however the numbers of people affected in the UK remain at the time of this writing, unknown and Equifax themselves remain resolutely close lipped. What is known is that Equifax hold credit details for up to 44 million people in the UK, and are regularly called upon for credit referencing purposes for organisation such as British Telecom, British Gas and Capital One among others. With regards the details that the as yet unknown attackers were able to access, these include; dates of birth, credit card numbers, telephone numbers, drivers licenses, addresses, and in the case of the US social security numbers (potential UK victims could well have had national insurance numbers purloined). Basically, the data sets that have been potentially acquired make identity fraud ridiculously simple. Although every week seems to bring news of yet another breach, the one that has impacted on Equifax has a potentially calamitous global impact.
Ironically, security watchers still don’t know exactly the mechanism the attacker(s) used to gain access to what was supposedly a resilient estate. Although Equifax have claimed that illegitimate access was gained via an unspecified “web application vulnerability” there has been some conjecture that access was as a result of a remote code execution vulnerability in the Apache Struts framework rather than common attack vectors such as SQL injection. Apache themselves however have been quick to attempt to distance themselves from this (a cynic may suggest to also distance themselves from the inevitable legal fall out). The attack vector itself remains as of now, unknown, and likely to stay that way for some time owing to the wacky world of Incident Response. One vulnerability however does not a disaster make, and this is what this article is all about.
Equifax are one of a trio of major international credit referencing agencies, and as such are global in both reach and scale. The external facing estate that Equifax and its suppliers manage is huge. Ironically perhaps, security seems to have taken a back seat, and over the course of this weekend research teams have examined the external estate, and found it to not be in a healthy state. On URLs associated with Equifax, researchers have found deprecated versions of software, verbose and detailed error messages that provide information of use to an attacker, and public facing authentication portals for popular and notoriously challenging to secure CMS systems. These would be common findings in any competent penetration test, but it appears that they have either been missed, or more likely unaddressed by Equifax. How could this be however that a company the size and significance of Equifax would allow this to come to pass?
The answer is perhaps best illustrated by an example. Imagine if you will that you are a network administrator for a small to medium size company. Your job is to keep everything IT related operational. Although you may want to patch all of your systems against security vulnerabilities as they emerge, you often can’t. You have to keep the legacy computer that handles finances online no matter what, even though the person who implemented it (and best understood it) has long since left the organisation. You have to make sure that the COO can still access their email, which means battling against filters. You have to make sure that users can move desks when teams fall out, and so just run a flat network as this makes your life considerably easier. Although you may have the time and buy in to push out Group Policy Objects on the Windows domain, patching all the office kit, and managing connections from home, from the train, from the hotel, and from suppliers premises consumes a lot of your time. And then there are the meetings, the innumerable meetings with project teams, asking when this will be delivered, when that will be deployed, when this weeks KPIs will be ticked off some seemingly arbitrary project plan? And let’s not forget the calls from vendors desperately trying to sell you things, to buy you lunch, to just have you look at the one CV. By the time the external penetration testers come on site, you are a frazzled state, and may point them at the one part of your estate you know to be secure, or may work around to sort out their findings (which you already know will be a sea of red points) eventually. This is just one scenario for a SME; now make it bigger. Now make the organisation full of contractors that are busy on the telephone to their accountants attempting to figure out how to evade IR35. Now staff the organisation with disinterested, disaffected, full time staff, who as well as being jealous of their overpaid contract colleagues, are also thinking about what microwave meal they can get from the supermarket, and how much time they may get to spend with their kids once they have fought back home through traffic, or on a packed commuter train.
In many organisations, security is a cost and an overhead, and this is something security suppliers and providers buy into too. Many vendors claim that their latest magic box or shiny gadget will help reduce management overhead. Typically they don’t. Many supposed magic bullets can often be found sitting in data centre racks, LEDs blinking slowly to themselves, as fans spin, and impenetrable log files remain unseen. But it’s not just hardware and software vendors. On a services front, many suppliers are equally culpable. I personally have been in a number of meetings with third party sales, business development, and even client project staff, where rather than asking for a full and thorough penetration test, a “box ticking” exercise has been requested. In order to assuage business demands driven by a board that may have recently read of incident A, or infection B, the message has trickled down that testing must be done. In order to fulfil this, automated vulnerability scanning software is to be used as a substitution for manual and costly penetration testing (which actually exploits findings, as well as finding more). In order to appease external auditors or suppliers, the same rule applies of running a software suite and claiming it is a test. Typically security services suppliers will happily go along with this as they get paid, and the risk remains with the client and not with them. Not only does this model fail to provide anything other than a veneer of security (well apart from the fore noted box ticking) it actually does most organisations a major disservice. From a company perspective I know that we have lost business because we have not played the box ticking game, and gone above and beyond it. On a number of our previous clients we have accessed all of their systems and data in minutes and recorded a bevy of critical findings that if actively exploited by an attacker could lead to total compromise of systems and client data sets. Have we been invited back to repeat testing of this ilk? Despite repeated contact attempts; we have not. More worrisome than being commercially ignored, I also know (because they have told me as much) that a number of clients have also not addressed the vulnerabilities that we have previously found for whatever reason, be it organisational issues such as those outlined in the previous paragraph, or acceptance of the risk from a business and commercial perspective.
Regardless of the attack vector used in the Equifax breach, which we may or may not ever know, what can be known is that the tick in the box approach to testing does not, and cannot work. This may have been an approach that some in Equifax took (again we will never know) but it is surprisingly common in organisations large and small. The demands that adequate and robust security can place on an organisation can be expensive not just in terms of time but also labour, and this is often forgotten by supposed security and risk professionals. It does not excuse lax security but it may go some way to explain it. It is also perhaps worth noting that for many commercial organisations, the goal is to maximise revenue and profit, and this is the primary driver rather than having an aggressive and pronounced security posture. The two are not incompatible, and arguably part of the job of any competent security provider of professional is to work with organisations to help them garner that fact.
As for Equifax, well we may never know how an attacker breached one of the largest credit referencing agencies in the world. What can be known is that somewhere, someone is potentially sat on a trove of data that if used in anger or for criminal profit could be massively damaging (and not just to Equifax but those whose data sets they hold, which is pretty much most of the developed world). What can you do to secure yourself in the interim? One simple mechanism is to distrust any email or telephone communication that purports to be from a third party (particularly financial bodies). If you are contacted; never respond to emails (and don’t click links in them either) or telephone calls and do not provide any personal information. Return calls only to those numbers you have checked independently and the same holds true for email communications. It should be noted that the Equifax breach can potentially facilitate consumer identity theft at scale, and this is why it should be treated as grave. Monitor your credit (although potentially not with Equifax as signing up to their service may make you exempt from pursuing legal action against them) closely. Most importantly of all, however until we, the public know the actual scale of this breach and what was accessed, heed the words of Hitchhikers Guide to the Galaxy, and don’t panic. Oh, and if you happen to commission penetration testing, please try to do more than box ticking too.