Data breaches are never fun. Not for the individuals who've had their personal information stolen and certainly not for those handling the breach. Many late nights are worked, many tough decisions made in the heat of the moment all the while wondering what's next. There's blood in the water so who's circling? What other systems could be at risk?

That's where researchers like myself tend to come in. I had some free time last Thursday evening, a week after rumors of the July 29th breach discovery started to hit a few news sites and fatefully decided to download the Equifax mobile application to my iPhone. Within minutes of using the application I'd noticed a critical oversight in the client-side implementation of the application.

While the authentication solution for the application was properly using HTTPS, complete with validation of root trust of the server certificate, there were other areas in the app like the product comparison area which were making requests over the clear-text HTTP protocol, an area I could evaluate within my own environment without impact to any Equifax owned servers :

GET http://www.equifax.com/cs/Satellite?pagename=compare_products HTTP/1.1

In the mobile application space such requests can allow an attacker on a rogue WiFi or cellular network to intercept and modify response traffic, allowing the application user experience (UX) to be hijacked. Sometimes the use of HTTP isn't entirely bad as the application context may not allow UX hijack and instead simply result in the ability to tamper with data, but not for the Equifax mobile application. It allowed the full rendering of markup and scripts within the application UX as well as GET and POST requests to non www.equifax.com domains, making it easier for an attacker to spoof the application UX.

In short order I'd found multiple exploitable areas of the web app and wrote a simple proof of concept (POC) in The Fiddler, one of my go to debugging proxies, demonstrating the ability for an attacker to prompt users for their authentication credentials and other sensitive information.

With the attacker now in control of the application UX, it doesn't matter if the application was never intended to ask for sensitive information because the attacker could ask for anything, all while exploiting the users trust that it is a legitimate request from the application. For applications which by default don't and would likely never ask for sensitive information, an attacker might inject an HTTP response with a claim that the user won a chance contest and simply needs to provide credit-card information to validate their identity and shipping address.

Of course in the context of the Equifax mobile application, highly believable attacks could range from an ask for credit-card details, information pertaining to password reset, bank account information or even a simple ask for the users application credentials utilizing slightly modified HTML from the application itself. If the user believed Equifax was offering free promotional identity protection services, what information wouldn’t the user unknowingly give up to an attacker? Maybe a lifetime of credit fraud monitoring would be worth providing banking information? Surely in the wake of what may well be one of the worst data breaches yet it doesn't take a lot of creativity to come up with scenarios in which an attacker could leverage this vector.

I submitted the vulnerability to security@equifax.com as soon as I'd finished my disclosure write up and within the hour was contacted by an Equifax VP to let me know it was being handled by their response team. In less than 24 hours, what I can only assume to be a very busy response team, likely running on little sleep had managed to not only validate my findings but pulled the Equifax mobile application off both the Apple App Store and Google Play Store. They also triggered a shut-down of the application through its automatic update check which fires off when the application first starts in order to protect users who'd already installed and may use the app in the future.





Given the gravity of the vulnerabilities in the Equifax mobile application this was without question the right move, but also raises some interesting observations when it comes to incident response. Could this have been avoided if Equifax would have taken proactive measures to review the remainder of their public Internet facing space as part of their incident response to the initial data breach?

I understand how it may have been missed, perhaps incident responders were focused on identifying issues within the Equifax server environment and didn't consider that it would be prudent to review their mobile application space. However, it is still disappointing that it wasn't evaluated sooner and leads to some advice I've provided to teams over the years:

Do a risk assessment of your applications. Determine where there may be weak spots and how an attacker might use those weaknesses for malicious purposes. These activities can be fun for development teams but must always be lead by seasoned security staff who have the ability to think creatively. Not every weakness identified must be fixed, rather the findings should be prioritized and plans put in place to either address them through direct mitigation or be aware of the issues in the event of a compromise.

Practice, practice, practice. Run mock compromise drills to identify where and what needs to be done in the event of a compromise. From these drills, develop response strategies, create run books, and ensure you have the systems in place necessary for a response.

Understand your environment. Have an application and system inventory, know who to contact and have identified resources who may not be members of the full time security staff, but who can assist as necessary.

Perform regular pen-tests of applications and rank them by level of concern so that when an incident does happen you can more appropriately focus your resources.

At the very start of your incident response do an immediate inventory of not only every system impacted, but also consider the wider environment. Ensure that those systems are evaluated by staff and pen-testers.

Go public only after you are confident that your environment is completely hardened and there's not that one mobile application which could provide an easy path for compromising your users.

As someone who's been in the security industry for nearly two decades now, there's one thing I know, compromises happen and will always happen. Ultimately when they do happen, it's critical to manage the incident in a way which doesn't make the situation worse and failing to identify low-hanging problems like a poorly secured mobile application after announcing a breach simply make things worse for everyone. Hopefully the lessons learned here can be applied within other businesses and perhaps lead to a more secure Internet.

DISCLAIMER: my research in this space was focused within my own environment on a personally owned device. As a security researcher I both appreciate and support ongoing efforts such as the DMCA Security Research Exemption for Consumer Devices which allows security researchers acting in the best interest of the public and in good faith to inspect their own devices up to and including installed applications.







































