Understanding API attack vectors

With there being an increase in the number of cloud service providers and the adoption of microservice environments and mobile applications, APIs have become a fundamental pillar of modern applications. They power a lot of digital platforms, including those belonging to eCommerce giants, financial providers, and social platforms, as well as educational applications and essential services such as mapping and location-based applications. This has also increased their attractiveness to malicious actors targeting said platforms. Some companies find that hackers spend more time probing their APIs than the companies themselves allocate to maintaining them. To properly secure your APIs, you must understand their attack vectors. Often, APIs serve as the initial entry point into systems, enabling lateral movement across systems and granting access to underlying systems, sensitive data, and workloads. Due to their popularity, they have quickly risen to become a critical attack surface for any organization using them. While traditional application security measures and tools are still relevant, they fall short when it comes to addressing the unique security vulnerabilities posed by APIs.

Attack vectors are explained as the specific paths and methods that attackers leverage to exploit vulnerabilities in an application/system to gain illegal access or exfiltrate sensitive information. It describes the method or technique that’s used to launch an attack and how it exploits weaknesses or flaws in the targeted system. Oftentimes, the term attack vector is mixed in with the term attack surface. An attack surface specifies all the possible entryways that an attacker can use to compromise your organization’s system. This means that it is the sum of all the attack vectors in your organization’s environment; APIs in general are an attack surface.

APIs, like many other components of an application, can be vulnerable to several attack vectors, and understanding these vectors is a crucial step to secure your organization’s applications. There are two different attack vectors that you should be on the lookout for – active attack vectors and passive attack vectors:

• Active attack vectors are those where the attacker actively seeks to destroy, modify, or harm victim systems and cause disruptions in an application. An example would be a Denial of Service (DoS) attack. These vectors are often intrusive and thus easier to trace.
• Passive attack vectors, on the other hand, are where an attacker exploits vulnerabilities to gain information, eavesdrop on, intercept, or observe data without causing any operational disruptions or raising suspicion, and these are not as noticeable or intrusive. An example would be phishing attacks.

Regularly leveraged attack vectors include injection attacks, security misconfigurations, Distributed Denial of Service (DDoS) attacks, authentication and authorization attacks, business logic attacks, and API key and token theft.

Types of attack vectors

To understand the aforementioned attack vectors, we will dissect each of them to further understand their origins and characteristics. This will factor in both attacking and defending.

Security misconfigurations

Most API attack vectors leverage the human error factor of API development, and the most prevalent attack vectors involve misconfigurations and weak links between APIs deployed within each software component. Security misconfigurations occur when a security feature or option is not configured securely or not configured at all. They happen when mistakes are made while setting up or exposing services to the internet. They can come in various forms and sizes, but they can still serve as an entry point for attackers. These mistakes can create vulnerabilities that attackers can take advantage of. It is important to note that sometimes, even the default settings of a service can be a misconfiguration.

Misconfigurations are dangerous in that they can happen at any level of the API stack and in different parts of the API, such as the settings on the server, the way access is controlled, how authentication works, or even the encryption settings. One error could result in very severe repercussions for both the consumers of the API and the organization. A misconfiguration might cause a leak in sensitive information; it could also be the cause of unauthorized access to restricted systems or functions. Attackers can exploit these security gaps and potentially cause a lot of harm. Common mistakes include leaving default passwords, leaving open ports that attackers can easily find, and enabling unnecessary features such as HTTP verb and logging capabilities. It is important to understand that any information about a service can be useful to an attacker. For instance, when using a web server, it may accidentally reveal its version number in the response it sends back. Also, if someone purposely sends incorrect requests to a service, they may get error messages that reveal details about the software used or even filenames and locations. It’s also important to make sure that only necessary services are exposed and that unnecessary access is restricted. One common type of misconfiguration involves failing to apply the latest security patches. This can occur at the operating system (OS) level for the machine hosting the API or for the API itself, such as a patch for the programming language that’s used to develop the API. This attack vector is particularly easy to exploit and detect using automated tools, making it extremely attractive to all levels of hackers. It could also have a severe impact on the organization, especially if the misconfiguration eventually leads to a full server compromise.

Injection attacks

Injection attack is an umbrella term for several attack types. They occur when an application fails to properly distinguish between untrusted user data and code. This untrusted user data can be injected from various sources, including HTTP request parameters, headers, cookies, or even stored resources such as malicious files or user-modifiable files. Types of injection attacks include command injection, Structured Query Language (SQL) injection, NoSQL injection, XML injection, and Lightweight Directory Access Protocol (LDAP) injection. The most exploited type of injection attack is SQL injection. This type of injection focuses on exploiting the database of the application and might lead to the destruction of a database. To exploit it, an attacker manipulates the input data to execute unintended SQL queries on the backend database of an API. Command injections, on the other hand, lead to the execution of unintended and often malicious OS commands on the systems running the applications. This happens when input is directly concatenated with a system command without proper validation or sanitization. A successful command injection attack can lead to the execution of arbitrary commands on the server, potentially enabling unauthorized access or further exploitation.

XML injection is an attack where an attacker injects malicious data into XML data that’s exchanged between the client and the API. By manipulating XML input, attackers can tamper with the structure, content, or behavior of XML documents, which can lead to issues such as unauthorized data access. LDAP injection is a specific type of injection attack that targets APIs that use LDAP for authentication and directory services. Attackers exploit inadequate input validation to inject malicious LDAP statements, leading to the manipulation of LDAP queries.

Injection attacks have the potential to result in data breaches and manipulation, particularly if an attacker can dump or modify databases containing user data.

APIs are vulnerable to these attacks mainly because developers fail to implement input validation and sanitization before they reach the API code. This leads to the API treating this input as legitimate code and running it. These attacks could lead to data breaches, loss, and even complete server takeover. Injection flaws are very common and some are very easy to successfully exploit.

Man-in-the-middle (MITM) attacks

MITM attacks are a type of API attack vector where an attacker intercepts and modifies the communication between the API client and the API server. In an MITM attack, the attacker positions themselves between the client and the server, secretly relaying and altering the information exchanged between them. This attack can be leveraged to gain valuable information, such as login credentials, and to analyze the interaction between client and server, which could lead to other attacks. Here are some exploits that can be researched using MITM techniques:

• Extracting API keys: Malicious actors intercept and extract API keys while they are being transmitted and use them in scripts to deceive the server into believing the communication originates from a valid user.
• Stealing user credentials and authentication tokens: MITM attackers can capture user credentials or authentication tokens during transit. Those stolen credentials can then be used to trick the server into accepting the communication as legitimate.
• Manipulating transaction requests: Attackers can modify transaction requests that are made through the API, resulting in the server performing actions different from those initiated by the genuine client.
• Investigating API vulnerabilities: Attackers can also employ MITM attacks to investigate the presence of API vulnerabilities, such as broken object-level authorization (BOLA). Once discovered, these vulnerabilities can be exploited to gain access to data that would typically be restricted for a particular user.
• Understanding API protocols: By analyzing the API protocols in use, attackers can create scripts that mimic genuine traffic patterns, enabling them to impersonate legitimate clients.

The ability to MITM API traffic opens up a lot of possibilities for bad actors. Several factors open up the possibility of an MITM attack in an API. One of those factors is insecure or invalid certificates as improper configuration or usage of digital certificates can weaken API security. APIs that use self-signed or expired certificates, or those that do not validate the server’s certificate during the SSL/TLS handshake, are vulnerable to certificate-related MITM attacks.

The lack of encryption is also a major factor that can make an API vulnerable to MITM attacks. APIs that transmit data over insecure channels without encryption, such as HTTP instead of HTTPS, are highly vulnerable to MITM attacks. Without encryption, attackers can intercept and view the sensitive information that’s exchanged between the client and server.

The insecure configuration of trust stores also factors in. APIs that utilize improper or insecure configurations for trust stores, which store the trusted certificates and certificate authorities, can be vulnerable to MITM attacks. Attackers can exploit misconfigured trust stores to insert their malicious certificates or intercept the communication. Weak security measures on the client side, such as using untrusted networks or devices, can expose APIs to MITM attacks. If the client device or network is compromised, attackers can intercept and manipulate API communication before it reaches the server.

DoS and DDoS attacks

DoS and DDoS attacks are attack vectors that pose a significant risk. Their main objective is to render an API endpoint inaccessible to legitimate users. In a DoS attack, a single source generates fake traffic to overwhelm the target API, making it easier to block. On the other hand, a DDoS attack involves fake traffic originating from numerous sources, making it more challenging to mitigate.

During these attacks, malicious actors flood an application or API endpoint with requests, aiming to disrupt the services offered. Rather than intending to steal or modify user data, the objective is to exhaust a limited resource within the API infrastructure.

To successfully carry out a DDoS attack, an attacker will create a network of infected internet-enabled devices known as a botnet. Each device is referred to as a bot or zombie and can be anything from smart home devices such as a thermostat to a traditional desktop or laptop. When the attacker is ready to execute the attack on the target API endpoint, they will issue commands to their botnet, typically using a command and control (C&C) infrastructure. These commands instruct the bots to send data to the target API endpoint to overload and collapse its systems. This type of attack is more elusive compared to DoS attacks since each bot mimics a seemingly genuine user. Distinguishing individual bots from the vast pool of internet traffic can be a challenging task. Additionally, DDoS attacks have the potential to expose security flaws by overwhelming firewalls and automated security tools. DDoS attacks can serve as a smokescreen to mask other malicious activities. By overwhelming security measures, attackers can create chaos and confusion, diverting the attention of security personnel and making it easier to infiltrate the system or carry out additional attacks while defenders are occupied with mitigating the DDoS attack.

DoS and DDoS attacks exploit the fact that even the most secure applications have hardware limits. They overwhelm the CPU cycles and processor power of the API’s hosting server. APIs that lack proper rate-limiting configurations are particularly vulnerable to these attacks. It’s worth noting that a legitimate user can unintentionally cause a DoS scenario by accidentally requesting excessive data from the API.

Companies that depend on a constant flow of information through APIs for their day-to-day operations face a constant risk of disruption and potential paralysis. Additionally, hackers can use DoS/DDoS attacks as a powerful weapon to extort targeted companies as a ransom can be demanded in exchange for the restoration of normal business operations. Even a brief slowdown or complete blockage of services could result in significant financial losses and undermine the trust of users.

Authentication and authorization attacks

Authentication and authorization attacks are those that target vulnerabilities in the authorization and authentication mechanisms in an API. Authentication mechanisms help prove that you are who you say you are, while authorization mechanisms determine what kind of permissions you have in that system. These attacks aim to gain access to resources and functions without the correct credentials and permissions.

One type of authentication attack is a brute-force attack. This is where an attacker tries to guess the username and passwords of a particular application using a trial and error method. This attack is successful when weak or easily guessable credentials are used, or if the API lacks protections against repeated login attempts. This attack is particularly dangerous since there are numerous tools available for executing this attack and the attack is very easy to start.

Another attack that is possible due to inadequate authentication mechanisms is credential stuffing. In this attack type, attackers use usernames and passwords from data breach dumps or the dark web and automatically try them on various accounts in the API. Since a lot of users reuse passwords, this attack can be very effective. Session hijacking attacks involve stealing a user’s session token or identifier to impersonate them and gain access and permission to certain resources. This can be achieved through methods such as session fixation, where attackers set the session ID to a known value, session sniffing, where they intercept and capture session data, or session sidejacking, where they eavesdrop on network traffic to capture session information.

Another type of attack is the Insecure Direct Object References (IDOR) attack. During this attack, the attacker manipulates parameters or object references in API requests to access resources or perform actions that they should not be allowed (authorized) to perform. By exploiting a vulnerability in the authorization mechanism, attackers can also elevate their privileges within the API, gaining access to restricted functionalities or sensitive data. We’ll explore this and other attack vectors later in the chapter.

We’ll begin by looking at fuzzing and injection attacks.