Recent API Security Incidents Show Perils of Ignoring Best Practices

Despite the fact that the costs associated with hacking and data breaches have arguably never been higher, recent API-related security incidents highlight the fact that basic API security best practices are still often not being adhered to.

Earlier this month, it was discovered that a vulnerability in the T-Mobile website made it possible for attackers to retrieve customer data, including email address, account number and phone IMSI number, using nothing more than a customer's phone number.

The vulnerability was made possible by a flaw in an API that the T-Mobile website uses to access customer data. By simply changing the value of the phone number parameter in a query to the API, the API would respond with the data for the customer with that phone number.

According to security researcher Karan Saini, who discovered the flaw, "T-Mobile has 76 million customers, and an attacker could have ran a script to scrape the data (email, name, billing account number, IMSI number, other numbers under the same account which are usually family members) from all 76 million of these customers to create a searchable database with accurate and up-to-date information of all users."

As Vice's Motherboard pointed out, the vulnerability could allow an attacker to execute social engineering attacks and perhaps even hijack customers' phone numbers.

A similarly significant security incident was also reported earlier this month by Australian IT outfit UpGuard. It discovered that global management consulting firm Accenture had been exposing sensitive data of its clients on publicly accessible servers. According to Tom's Hardware, this sensitive data included "secret API data, authentication credentials, certificates [and] decryption keys."

Specifically, the data exposed included internal access keys and credentials used by Accenture's Cloud Platform Identity API, which is used to authenticate credentials, as well as configuration files for the API and a plain text document containing the master access key for Accenture's account to the AWS Key Management Service. As Tom's Hardware notes, "this would have given an attacker access to an unknown number of credentials."

This data was hosted in Amazon AWS S3 storage buckets that had been configured to be publicly accessible, making their contents available for download by anybody who had the addresses of the buckets. By default, AWS S3 buckets are not public so this data is not exposed.

Interestingly, a similar faux pas by Verizon resulted in the data for some 14 million customers being exposed. In Accenture's case, the data that was exposed could have been used "to hack into and steal information from thousands of Accenture’s corporate clients, creating unimaginable damage" given the fact that Accenture Cloud Platform is used by 90% of the companies in the Fortune 100 companies and 75% of the companies in the Fortune 500.

So What Can We Learn From These Recent Security Incidents?

The most glaring lesson from the T-Mobile and Accenture incidents is that even large companies that should have the staff, knowledge and resources to implement API security best practices are not only not always doing so, they're falling short on some of the most basic best practices.

Specifically:

Authentication

The T-Mobile vulnerability was made possible by the fact that one of the company's APIs was not performing sufficient authentication on requests to ensure that the requests were coming from a user authorized to make such requests. Such vulnerabilities are inexcusable today and can only seep into production APIs if developers aren't well-versed in security best practices and rigorous testing is not conducted prior to APIs being deployed into production.

Credential Management

The Accenture incident highlights violations of a number of API security best practices. For example, internal credentials were stored in a place where they could have been accessed publicly and what's more, sensitive credential data, such as access keys, were not encrypted at rest.

It's not known whether Accenture was adhering to another best practice – credential rotation – but if not, these security best practice violations have the potential to be especially costly as there is the potential for exposed credentials to be exploited by attackers for prolonged periods of time.

Monitoring

Both the T-Mobile and Accenture incidents demonstrate the importance of active monitoring to ensure that any attacks are detected as quickly as possible. While Accenture is still investigating its incident, T-Mobile told Motherboard that it quickly addressed the flaw in its API and "there is no indication that [the vulnerability] was shared more broadly."

Yet a blackhat hacker contacted Motherboard and indicated that the vulnerability was widely known and some hackers "used it for quite a while." As proof, the hacker offered T-Mobile account data for Motherboard author Lorenzo Franceschi-Bicchierai, calling into question T-Mobile's claim and suggesting that the company might not have even been monitoring the usage of the vulnerable API to detect abuse.

Obviously, the fact that large companies are still failing to adhere to API security best practices after countless reminders of the damage that hacking and breach incidents can cause is a reminder that companies still have a lot of work to do. Until companies consider security a central part of their API strategies and not a standalone component of them, expect to see continued incidents like these.

 

Comments (1)

orubel

Considering that OpenAPI does not synchronize its data with the endpoint and can push elevated privileges from the API gateway, I would say start with the OpenApi Spec.