advertisement
advertisement

Here’s Why Equifax Yanked Its Apps From Apple And Google Last Week

A security researcher discovered a shocking vulnerability: “They quite frankly didn’t know what they were doing.”

Here’s Why Equifax Yanked Its Apps From Apple And Google Last Week
[Photo: Flickr user Wiyre Media]

Last week, after news broke that Equifax was the victim of a critical security flaw that exposed hundreds of millions of Americans’ personal data, the company quietly took down its mobile apps from Apple’s App Store and Google Play. I wrote about this at the time, but wasn’t quite sure why the apps were removed. Now we finally have an idea.

advertisement

Security researcher Jerry Decime wrote a LinkedIn post a few days ago claiming to have initially discovered a vulnerability. Once he learned that Equifax had a huge breach, he wondered how secure its mobile programs were and decided to test them. He found shocking results: Though Equifax’s app used the secure HTTPS protocol to authenticate, once users were in the app, it used just HTTP in a number of locations, which makes the app vulnerable to interception. This means that any data communicated between users and Equifax is not encrypted.

The vulnerability was serious, but likely a separate issue than what caused the massive breach–although both incidents together indicate a pattern of negligence on Equifax’s part.

The HTTP error, says Decime, makes the program vulnerable to what’s called a “man-in-the-middle” attack–an attack where communications become intercepted by a third party. A hacker could conceivably launch an attack that fed Equifax users a window that prompted them to enter their personal data, which would then be collected by the attacker. 

“This is really why we have that cryptography,” Decime tells me, explaining why the entire app should be using the HTTPS protocol, which encrypts all the data transferred. “It’s ultimately to mitigate those man-in-the-middle attacks.” He goes on: “They weren’t using crypto for critical interfaces, allowing attackers to inject their own markup including JavaScript.” 

This is a huge error, and one that can’t be chalked up to a simple mistake. Decime described Equifax’s lack of understanding of mobile platforms “damning,” going on to say, “They quite frankly didn’t know what they were doing.”

According to Decime, he noticed the error on Thursday and instantly reported it to Equifax. Within an hour, he received a response from a VP. In all his years of being a security researcher, Decime has never had such a swift and high-level response, he says. After that, however, all communication with Equifax died.

advertisement

“They definitely got freaked out,” says Decime, who noticed that the apps were taken down shortly after. Fast Company reviewed Equifax’s exchanges with Decime–indeed a VP did respond to him who promised to “stay in touch.” After that, crickets.

Equifax didn’t immediately respond to a request for comment.

While it’s good that Equifax’s response was so swift, it is concerning that apps had such a critical flaw. And it’s a lesson every application developer should note: They must not use HTTP for anything that could allow third parties to attack the applications in a way that they could then control the user experience.

In a follow-up email, Decime summed it up thus: “All mobile applications should be using HTTPS for all transactions these days, even ones that don’t ask for sensitive information. If an attacker can gain control of an application through injecting their own markup, they can phish the user for any information they wish and appear as if the request is coming directly from the application.”

About the author

Cale is a Brooklyn-based reporter. He writes about business, technology, leadership, and anything else that piques his interest.

More