Leaky APIs expose customer data for free to anyone who knows the URL. What are you doing to protect your customers from hackers targeting your APIs?
“Leaky” is almost never a good thing. The whole idea, in just about any case, is to make things that don’t leak and to plug things that do.
And that’s true of cyber security, as demonstrated by a couple of recent incidents involving leaky APIs (application programming interfaces).
A couple of weeks ago it was researcher and pen tester NinjaStyle who announced in a blog post that the full contact information of everybody who had attended the 2018 Black Hat conference in Las Vegas, including him, was available in plaintext.
He had hacked his own badge and demonstrated that he could access the data of everybody else who had attended, thanks to a “legacy” API (i.e., a leaky API) used by the BCard maker ITN International.
Once notified, the company moved quickly—NinjaStyle reported the vulnerability was closed within 24 hours, when ITN disabled the API.
Then came word late last week from wireless provider T-Mobile that about 3% of its customers had been affected by “an incident that … may have impacted some of your personal information.”
While 3% sounds small, for a giant like T-Mobile, it is still a big raw number—in the range of 3.2 million customers.
That information could have included “name, billing zip code, phone number, email address, account number and account type (prepaid or postpaid).”
While the company was vague about how the breach occurred, Threatpost reported that the attack “targeted a specific leaky API tied to an undisclosed part of its website.”
The company said the attack occurred early Aug. 20, from what it called “an international group,” but was detected and shut down quickly.
T-Mobile also said no financial data, including credit card information and Social Security numbers, were involved. And they added that “no passwords were compromised.”
But that last phrase was very carefully worded, and is open to some debate. Motherboard reported that a T-Mobile spokesperson acknowledged that “encrypted passwords” were included in the compromised data but were not considered compromised, because of the encryption. However, she declined to specify how they were encrypted or what hashing algorithm was used.
A couple of experts told Motherboard it might be “an encoded string hashed with the notoriously weak algorithm called MD5, which can potentially be cracked with brute-forcing attacks.”
Which means customers should assume their passwords have been compromised and change them. T-Mobile’s CEO John Legere acknowledged in a tweet that “it’s always a good idea to regularly change account passwords.”
However, simply changing passwords—while that should be an automatic, basic response—doesn’t mean the threat from the hackers is gone. Amit Sethi, senior principal consultant at Synopsys, noted that information compromised by leaky APIs “can potentially be used in targeted attacks where attackers can impersonate customers to T-Mobile’s customer service representatives.”
Besides that, the attackers might also try to impersonate the customers to other wireless carriers in an attempt to “port out,” or hijack, their phone numbers. That could allow the attackers to intercept calls and messages while the legitimate customer phone goes dark.
“People who are impacted should ensure that they have set up a PIN with T-Mobile that they use to authenticate to customer service representatives, and that is required to port their phone numbers to another carrier,” Sethi said.
T-Mobile says it monitors all accounts for that kind of attempted fraud. But the company has urged customers to do what Sethi recommended—create a PIN for authentication.
Indeed, this is only the latest in a yearlong string of leaky APIs discovered on the carrier’s website. Last October T-Mobile reported that an API had been exposing personal and account data on its website (and some hackers confirmed they had been using the API for weeks). In February, in response to a surge in port-out scams, T-Mobile issued a warning to customers and asked them to set PINs for additional account protection. But in May another API was found to return personal and account data, including “references to” those same PINs (though it’s not clear whether the PINs were exposed in plaintext).
Whatever the cause, the recent breaches make one thing obvious: Organizations should look for security weaknesses in the APIs they are using.
Gary McGraw, vice president of security technology at Synopsys, said this kind of thing “happens all the time. In many cases APIs and other interfaces are set up for ‘internal use’ and then over time start being used ‘externally’ as well. Chaos results.”
“Internal security policy—the way to treat and trust employees—is often significantly more permissive than external security policy—the way you treat customers on the internet.”
Sethi said that without more details from the companies, “it’s hard to comment on what exactly the root cause was.”
“However, this [the leaky API] is a perfect example of something that probably would not have been found through an automated scan. A manual penetration test is generally required to find this type of issue,” he said.
McGraw added that a little paranoia might improve security during development. “Developers often build these things to ‘get something done,’ and don’t think about who might be getting the wrong something done or how their cute little bridge can be abused,” he said.
“Developers are the most optimistic people in the world, and their default approach to what people might do often reflects that optimism.”
And there are a couple of things multiple experts say consumers should do to keep themselves out of the “low-hanging fruit” category. They include: