API attacks – why they’re particularly challenging for telecoms
A barrage of criticism has been levied at telecom providers recently regarding the alleged simplicity of the attacks carried out against Application Programming Interfaces (APIs). But telecoms face some unique challenges when it comes to securing their APIs as they service thousands of applications over an ever-growing base of devices as the IoT expand. In addition, many are saddled with a sprawling IT estate and inherited systems, including older legacy APIs, that is then further disrupted by subscriber growth and M&A activity. Consequently, a disproportionate amount of the telecom ecosystem runs on APIs compared to other businesses.
The recent headline-grabbing API attacks have also been more sophisticated than first meets the eye. Attackers are now combining multiple attack methods from the menu of the OWASP API Top Ten, with API2 (Broken User Authentication) being combined with API3 (Excessive Data Exposure) and API9 (Improper Assets Management). Telcos are not alone in this regard, with the first half of 2022 showing a marked trend in attacks against undocumented or ‘shadow’ APIs and tactical assaults that use multiple OWASP threats or API10+ as covered in the API Protection Report.
In one of the attacks carried out this year, the abused APIs were meant for a development testing environment but were inadvertently publicly exposed. During the reconnaissance of the network, the attackers determined that the APIs were unauthenticated and unauthorised, responding with customer data from a live database. Checks on the key input parameter which give a key identifier for each user also weren’t in place which made it a trivial exercise to then launch a bot attack to iterate through different user IDs before returning the customer data.
A wake-up call
It’s important to note that this type of attack can be lightning quick, taking just minutes to execute if there is insufficient security in place. As a result, operators worldwide are now realising that they need to discover the APIs on their network, put in place detection to identify when and how an attack is manifesting and defend their APIs.
In another example, a large mobile operator with over 100 million subscribers recently carried out a discovery exercise to verify the APIs over its infrastructure. It found over a thousand unprotected API servers, equivalent to 18 percent of its server base, were publicly exposed. Over 30 percent of its API servers had SSL issues such as invalid or expired certificates which would have made it possible for an attacker to launch a Man-in-the-Middle attack.
The telco also discovered over 107 files that could expose private keys which, in the wrong hands, could have been used to access mission critical business information. Plus, despite an earlier rigorous patching campaign to address the threat posed by the Log4Shell vulnerability, five APIs were discovered that remained vulnerable to this issue.
Yet another attack against one of the largest telecom providers in the world saw the number one OWASP exploit – Broken Object Level Authorisation – used to enumerate access to the API to carry out an account takeover (ATO) attack with the end goal of SIM swapping.
The criminals sought to obtain information about a customer account by enumerating whether cell phone numbers could be transferred to the provider’s network. Once the attacker discovered transferable phone numbers, they attempted to impersonate the account owner to manipulate an employee into transferring the cell number onto a SIM card in the attacker’s possession. From this point, the attacker could then take control of the victim’s sensitive accounts by completing SMS-based 2FA.
Detecting such attacks is difficult because it sees traffic rotated across multiple IP ranges from known malicious Bulletproof Proxies. However, there are tell-tale giveaways. The timing of the request was too perfect, with attackers initiating a single API endpoint request per IP at two second intervals, resulting in nine million malicious requests, and there was a high IP to request ratio, as each phone number had been attempted from over 200 IP addresses. Because the telco was able to spot this suspicious activity, the attack was successfully blocked during the ten hours it persisted.
Improving API security
With attackers using a wider variety of tactics, techniques, and procedures (TTPs), the onus is now on telecom providers. But if, contrary to opinion, these attacks are sophisticated and the telecom estate is difficult to secure, what can be done to secure these APIs?
Firstly, discover what you’re dealing with by documenting your APIs and use a runtime inventory to ensure all APIs are known. If APIs are spun-up and forgotten the attacker can analyse them at their leisure and undetected.
Secondly, it’s important to note that even perfectly coded APIs can still be vulnerable to abuse, so while incorporating security testing into the development process (aka ‘shift left’) is key, all APIs should be regarded as vulnerable. This is because business logic abuse, whereby the attacker probes the API and uses legitimate requests to gain access, can be used against these APIs.
For this reason, it’s vital to know what ‘normal’ behaviour looks like for that API and to monitor for any deviation from this through traffic analysis. Many of the existing API security mechanisms in place, such as WAFs or API Gateways, rely upon signature-based detection when what is needed is behaviour-based analysis that can spot suspicious requests.
The final piece of the puzzle is defence. Being able to look at your API infrastructure through the eyes of an attacker can enable the business to identify its publicly exposed APIs and where they are hosted, carry out critical patching, and continuously monitor them. Should an attack occur, the incident can be dealt with in numerous ways, from real-time blocking to employing deception and deflection techniques to frustrate the attacker to cause them to abort the attack.
For instance, in the case of the multi-faceted API10+ attack mentioned above, the discovery phase would reveal any shadow or publicly exposed APIs, while detection would determine if authentication was in place and whether the APIs were transacting any sensitive data in their response. Finally, the defence element would act upon the knowledge that there was an attacker perpetrating a bot attack and would natively block the traffic and deflect the attacker.
Having in place a security strategy that covers the entire API lifecycle and seeks to discover, detect, and defend against these attacks is the only way that telecom providers can hope to counter these attacks, particularly given the complexity of their API estate and service offerings.
