Secure your APIs
Over the last few months, there have been a handful of public API compromises. These compromises included a “legacy” API that leaked personal information of BlackHat conference attendees, and what seem to be two separate T-Mobile leaks – one which leaked personal information, and another where both AT&T and T-Mobile leaked customer’s account PINs.
An API, or Application Programming Interface, is as the name suggests, a way in which one piece of software can interact with another. A simple example is a mobile Twitter application like TweetDeck. TweetDeck uses the Twitter API to get the basic data, perform basic actions, and provide various functionalities like lists and columns. So when you use TweetDeck to view your timeline and send tweets and direct messages in a nice, customized user interface, you are using the Twitter API.
How the leak at BlackHat happened
BlackHat is one of the largest cybersecurity events in the world and is held annually at Las Vegas. One of the attendees at BlackHat this year was a Colorado-based pen tester and security researcher who goes by the handle NinjaStyle. NinjaStyle happened to notice that his badge had an NFC tag, which is a type of chip that can store and transmit data to another NFC device. These tags are used at conferences like BlackHat as a convenient and efficient way to exchange contact information. Because the NFC tag on the conference badges could be read using a standard tag reader app, NinjaStyle was able to deconstruct the BlackHat app and find the API it used to communicate with the application server. With the information on the tag (eventID and badgeID) he was able to retrieve all the info associated with the tag – Name, email address and more – over the unauthenticated API. He then tried to brute force all the BlackHat attendee’s information. After a bit of digging, he was able to identify that a specific range of badgeID’s yielded the information of every attendee, and he managed to extract all the information in six hours. BlackHat later confirmed this leak, and their partner shut down the API, calling it a “legacy” API.
T-Mobile two leaks
In this next set of examples, we look at two T-Mobile leaks, the first being a leaky API that revealed sensitive customer information. T-Mobile said that its cybersecurity team found the breach and stopped it before it went too far. According to them, only about 3% of customers (about 2.3 million) were affected in the breach, and the information that was leaked included name, billing zip code, phone number, email address, account number, account type, and encrypted passwords.
The second leak occurred via Apple’s online store. The Apple online store exposed partial SSNs and PINs of potentially 77 Million T-Mobile customers. The online store used an API to interface with the T-Mobile systems. This API was used when customers buying a new iPhone opted for monthly payments via T-Mobile. The site then took the customers to an authentication form that asked for the last four digits of their SSN and their T-Mobile PIN. The potential leak occurred at this point – the API did not rate-limit queries and allowed unlimited tries. This meant that the API could be brute-forced, and information was stolen. The likely culprit here was the API not having a rate-limit enforced with a lockout after a few failed attempts.
In a different, but similar vulnerability, the PINs of AT&T customers who purchased insurance through Asurion were in danger. Anyone who knew an AT&T customer’s number could enter it into the form, and then brute force the PIN for that number using unlimited entries.
How to protect your APIs
APIs are extremely prevalent today. The number of systems that speak to each other to accomplish various functions – from buying a phone on a payment plan to paying for lunch online – is enormous, and all of them use APIs. APIs require significant security to ensure that they don’t become the All-New happy hunting ground for hackers. The vulnerabilities that were seen in these cases were standard web application vulnerabilities that have been known about for years – and have known defenses, both in terms of programming practices (non-guessable/non-enumerable ID’s) and defense techniques (rate-limiting, lockouts). In all these cases, simply following long-established good practices would have stopped these leaks from destroying hard-won customer confidence and causing lasting damage to customer information.
One of the easiest ways to securely deploy and protect an API is to use a web application firewall with API protecting capabilities. The Barracuda WAF family provides full protection for web and API applications wherever they are hosted. The BWAF family can protect the entire API attack surface. As a reverse proxy, it intercepts all traffic and covers all parts of the application, including dynamically generated URLs and URLs with resource names as directories. In addition, it also provides the following security capabilities:
- Providing a Secure TLS Fronted to API Service
- Enforcing Verb-based Security Constraints and Access Control
- API Session Security
- API Authentication and Authorization
- Protecting XML and JSON Parsers
- Preventing API Abuse from Rogue Consumers (Anti-farming)
- Filtering Malicious Data from Untrusted User Inputs in JSON/XML
- Filtering Malicious Data from Untrusted User Inputs in URL Path
- Uninterrupted API Delivery with Virtual Patching
- Centralized API Auditing and Analytics
The BWAF family also ensures enhanced API delivery. It allows your API to scale, by providing connection multiplexing between clients and the backend servers, reducing the load on the backend servers. It provides caching and compression capabilities to speed up API delivery and reduce load on the servers. Most importantly, it also helps ensure SLAs for APIs – it can enforce different service levels for different parts of the API, using built-in rate-control and brute-force capabilities.
For more information on the Barracuda WAF and WAF-as-a-Service, visit our corporate site at www.barracuda.com/waf.
