Fuzzing and injection attacks on APIs

Injection attacks on APIs can occur in different ways. In this section, we will explore why they occur and how to test for them in our APIs. We will also explore the art of fuzzing and how, if used ethically, it would be beneficial to our API security.

Fuzzing attacks

Fuzzing is an attack vector that involves sending random, unexpected, and invalid data inputs to an API to trigger vulnerabilities or unexpected behavior. This attack is like playing “what if?” with a system, asking endless hypothetical questions and scenarios to see if anything breaks or behaves unexpectedly. By continuously asking these “what if?” questions (test inputs) through fuzzing, we can find hidden problems in the software that we might not have found otherwise. Fuzzing is an awesome technique that’s used by security teams and vulnerability researchers to discover vulnerabilities in their APIs. However, it can also be leveraged by malicious actors to discover weaknesses in APIs for exploitation. The main aim of fuzzing is to test out error-handling mechanisms and to find gaps in the API’s input validation mechanisms.

When fuzzing, a security researcher uses an automated tool or script to systematically generate and send large volumes of test inputs. This could include invalid/unexpected data types, extra long inputs, and malformed data. This exercise aims to see how the API reacts and determine whether it can successfully identify the expected/valid data types when subjected to various test inputs. It also comes in handy to see whether it exhibits any abnormal behavior, such as crashes, memory leaks, or security vulnerabilities.

Once a vulnerability or an abnormal behavior occurs, the security personnel can try to remediate it or forward it to the necessary personnel for further investigation and remediation. On the other hand, attackers using this technique can now craft an attack plan with the observations they made from fuzzing. For example, they may send inputs that lead to buffer overflows, SQL injection, cross-site scripting (XSS), or other types of attacks.

This technique is extensively used by hackers due to its capability to find vulnerabilities without the need to access the source code. It is also very effective when it comes to identifying zero-day vulnerabilities. Zero-day vulnerabilities are those that are discovered by malicious actors or bug bounty personnel before the product vendors themselves know they exist.

While testing an API before deployment, it is advisable to fuzz it to avoid any surprises. To do this, you can use a fuzzing engine or API fuzzing; the steps, however, are almost the same, no matter which one you choose. They are as follows:

1. First, the fuzzer generates different types of inputs, such as random data, invalid inputs, or even malformed or corrupted files. These inputs are designed to push the API to its limits and potentially trigger unexpected behavior. These inputs can also be fetched from a wordlist.
2. The fuzzer then sends these generated or given inputs to the API being tested or the attacker. It could be a video file, a network request, or any other type of input that the program accepts.
3. The fuzzer closely monitors the API’s behavior while it processes the inputs. It checks if the API crashes, produces any error messages, behaves unexpectedly, or leaks sensitive information.
4. If the fuzzer detects a crash or abnormal behavior, it records the details of what caused it. This information is valuable for developers because it helps them understand where the API is vulnerable and how it can be fixed.

This process is repeated thousands or even millions of times with different inputs, hoping to uncover as many vulnerabilities as possible. By fuzzing extensively, the fuzzer increases the chances of finding flaws that could have been missed during regular testing.

This technique can also be useful during the enumeration phase, especially during engagements, to test private and partner APIs where documentation might be scarce. Fuzzers can be used to find endpoints and parameters that are used in the API. While conducting a pentest, be it a black box test where you have little to no information or a gray box test where some information has been offered by the client, it is important to further enumerate the API to get endpoints and more information that might not be obvious at first or may have been forgotten. This is especially important when you’re faced with APIs that have had previous versions. Fuzzing is the answer when you want to dig deeper to find attack surfaces that might have vulnerabilities but have not been mentioned in any documentation for whatever reason, allowing you to conduct a thorough pentest. One of the most important endpoints to secure is the admin endpoint; these are endpoints that are mostly used by administrators and have the highest privileges. A successfully exploited vulnerability on such an endpoint could mean an account takeover and would cripple an organization. So, it is important to ensure that every single endpoint is secure and thoroughly tested.

There is a multitude of fuzzers that can be found in the wild today and would be a worthy addition to your hacking arsenal. However, it is essential to acknowledge the OG fuzzers that have established their reputation over the years. These include Burp Intruder, OWASP ZAP, Postman, Restler-Fuzzer, and API-Fuzzer. We’ll go through some of these tools in this chapter to better understand how to use them when conducting fuzzing attacks. Another tool that comes in handy when fuzzing for endpoints is ffuf.

Before we get into the practical bit, it’s worth mentioning that when fuzzing endpoints and parameters, the result will be as concise as your fuzzing wordlist. Wordlists should be generated according to the practices of developers when it comes to naming. For instance, you should not use a Swahili list of endpoints to test an endpoint that was created by developers using English as their primary language. Back to ffuf, it is a user-friendly fuzzer written in Go that can effectively ensure comprehensive coverage of all your endpoints during reconnaissance.

To install ffuf on your machine, use the following command:

git clone https://github.com/ffuf/ffuf ; cd ffuf ; go get ; go build

If you are using macOS, you can install it using Homebrew by running the following command:

brew install ffuf

To utilize ffuf for this purpose, you can run the following command:

ffuf -u "http://localhost:8888/FUZZ" -w /usr/share/wordlists/seclists/Discovery/Web-Content/api/api-endpoints.txt

-u should be used when you’re specifying the URL that you want to fuzz, while -w specifies the wordlist. Here, we'll use the Seclists wordlist. This can be cloned from GitHub by running the following command:

git clone https://github.com/danielmiessler/SecLists.git

If you’re using Kali Linux, you can simply install it by running the following command:

apt -y install seclists

By providing the appropriate wordlist, this tool will aid in identifying and mapping your API endpoints accurately. ffuf also offers the capability to fuzz objects and parameters, making it an amazing tool for comprehensive testing and a worthy tool for your arsenal.

While testing an API, it is essential to be able to interpret the status codes that they return correctly. Some of the reasons for this are that it helps validate the success of requests, ensuring that the API responds as expected to valid inputs. Secondly, it enables the detection of error conditions and potential vulnerabilities within the API as specific status codes indicate issues that require further investigation. Thirdly, these codes can reveal security vulnerabilities, such as authentication or authorization weaknesses in the APIs. Lastly, they provide valuable feedback on API behavior, uncovering inconsistencies or weaknesses that attackers could exploit. By closely analyzing status codes during API fuzzing, you can understand which tests require more attention.

Although developers can use status codes for reasons other than the standard ones, here is a list of popular status codes and their meanings:

Status Code	Description
200	OK: The request was successful
201	Created: A new resource was successfully created
202	Accepted: The request has been accepted for processing
301	Moved Permanently: The requested resource has permanently moved to a new location
302	Found: The requested resource has temporarily moved to a different location
400	Bad Request: The request is invalid or malformed
401	Unauthorized: Authentication is required and has failed or has not been provided
403	Forbidden: The server understood the request but refused to authorize it
404	Not Found: The requested resource could not be found
405	Method Not Allowed: The request method is not supported for the requested resource
500	Internal Server Error: An unexpected error occurred on the server
502	Bad Gateway: The server received an invalid response from an upstream server
503	Service Unavailable: The server is currently unavailable
504	Gateway Timeout: The server did not receive a timely response from an upstream server

Table 5.1 – API response codes

The next tool we'll look at is Burp Intruder.

Burp Intruder

Fuzzing with Burp Intruder becomes easier when utilizing status codes as they provide a clear indication of which responses to filter out and which ones require a more thorough investigation. By paying attention to status codes, you can easily differentiate the requests that were successful from those indicating potential issues and vulnerabilities. While fuzzing our vulnerable API, we are going to include a section of endpoints that we already know so that we can see the difference between a successful response and a negative one.

Kali Linux has Burp Suite installed by default. For other OSs, you can install it by following the instructions on the official PortSwigger website: https://portswigger.net/burp/documentation/desktop/getting-started/download-and-install.

Start up Burp Suite and let's begin.

First, you’ll need to configure Burp Suite by setting the scope to focus on our vulnerable API. In our case, the API is running on localhost port 8080. To do this, follow these steps:

1. Click on Target in the main menu. It’s labeled as 1 in the following screenshot:

Figure 5.1 – Burp Suite’s settings

2. Navigate to Scope settings (2). A window will open where you can add the URL of the vulnerable URL.
3. Click Add and add the URL when prompted:

Figure 5.2 – Adding a scope

4. Click OK within the prompt.
5. Next, ensure that FoxyProxy is running on your browser of choice.

Now, you’ll need to navigate to the URL of the API on your browser. When you do this, Burp Suite will record the request on the Site Map tab of Burp Suite. Let’s begin the process:

1. Right-click on one of the requests you recorded and choose Send to Intruder. You can also do this by clicking on the request and then pressing Ctrl + I:

Figure 5.3 – Send to Intruder

2. Navigate to the Intruder tab:

Figure 5.4 – The Intruder tab

3. On the Intruder tab, you must specify the position of the payload. To do this, click on the Position tab and highlight the part of the request that contains the endpoint. We’ll use the Add § button to mark this position as the target for our fuzzing. By doing so, the payload we set will be injected specifically into that area of the request:

Figure 5.5 – Setting the payload

4. Now, let’s check out the Payloads option, which is labeled as 1 in Figure 5.6. This is where we’ll set up our payload configuration.
5. On this tab, choose Simple list as the type of payload (2):

Figure 5.6 – Loading the wordlist

6. Next, load the wordlist by clicking on the Load ... button (3).

   We’ll be using the wordlist located at /usr/share/seclists/Discovery/Web-Content/api called api-endpoints.txt.

7. Choose the wordlist (4).

   Now, we can add a few known endpoints.

8. Upon selecting Add in the Payload settings section, add the /api/users/login and /api/users/register endpoints:

Figure 5.7 – Adding endpoints

9. Unselect the URL-encode these characters option in the Payload encoding section to ensure that the payloads are sent without URL encodings:

Figure 5.8 – Payload encoding off

10. Click Start attack and wait for the results to come in:

Figure 5.9 – Start attack

Burp Intruder will automatically send different payloads from the wordlist to the selected endpoint, checking for any endpoints.

After the attack is complete, we’ll review the results. To differentiate between passed and failed endpoints, we can check the length of the responses or the status code. This will help us identify which endpoints are legitimate and which may be wrong. Looking at the results, we can see that the legitimate endpoints have a response of 404 and a length of 450+:

Figure 5.10 – Burp Intruder results

To fuzz inputs, you’ll need to send a request that contains inputs such as login credentials to the intruder and follow the same steps except for the wordlist. Seclists provides a fuzzing list that would be valuable for this step.

Another handy tool is the RESTler fuzzer.

RESTler

The RESTler Fuzzer, developed by Microsoft Research, is a fuzzing tool that’s tailored for REST APIs. It leverages the OpenAPI/Swagger specification to create and execute tests on the chosen API. What sets RESTler apart is that it learns from past results. By analyzing earlier requests, it predicts potential issues in subsequent requests and understands the connections between different requests. This ensures the availability of necessary data, enhancing the efficiency and organization of the testing process.

RESTler identifies bugs in two main categories:

• Error code bugs: Whenever RESTler receives a response with a status code of 500 (known as Internal Server Error), it considers it a bug. This type of bug is reported to help highlight potential issues within the API.
• Checkers: It uses checkers to actively search for specific bugs during the fuzzing process. These checkers execute targeted additional requests or sequences of requests at specific points, guided by the context of the API. Some checkers focus on finding more instances of the 500 error, while others target specific logic bugs, such as resource leaks or hierarchy violations. To learn more about the different checkers and their descriptions, you can refer to the Checkers section on the official documentation at https://github.com/microsoft/restler-fuzzer/blob/main/docs/user-guide/Checkers.md.

Once RESTler identifies a bug, it categorizes and organizes it into bug buckets for better management. RESTler also provides a replay log that can be used to reproduce the discovered bug, aiding in further investigation and analysis. To use this tool, we’ll be using the crAPI vulnerable API. After following the setup instructions provided in this book’s GitHub repository and starting the API, we can access the interactive Swagger specification interface at http://localhost:8888/docs. The OpenAPI specification is available in the demo_server directory as swagger.json. Our commands will consist of compile, test, and fuzz. The compile command generates a RESTLer grammar:

restler/Restler compile --api_spec [swagger file]

Here’s the command on the interface:

Figure 5.11 – RESTler compile mode

After running this command a new sub-directory is created that contains the necessary files and RESTLer grammars to test and fuzz:

└─$ ls  Compile
config.json                   dependencies_debug.json  engine_settings.json  preprocessed                 StdOut.txt
custom_value_gen_template.py  dependencies.json        grammar.json          restler-20230602-103201.log  unresolved_dependencies.json defaultDict.json              dict.json                grammar.py            StdErr.txt

The test command quickly executes all endpoints and methods within the compiled grammar for debugging and assessing coverage.

You can run the following command to use RESTler’s test mode:

restler/Restler test --grammar_file Compile/grammar.py --dictionary_file Compile/dict.json --settings Compile/engine_settings.json --no_ssl

Here’s the command on the interface:

Figure 5.12 – RESTler’s test mode

Finally, fuzz mode explores the RESTLer grammar more extensively to uncover bugs. We’ll allocate sufficient time for the tool to gather bugs and checkers for analysis.

We’ll be using the following command:

/restler/Restler fuzz --grammar_file Compile/grammar.py --dictionary_file Compile/dict.json --settings Compile/engine_settings.json --no_ssl --time_budget 0.5

Here’s what it looks like on the UI:

Figure 5.13 – RESTler’s fuzz mode

The bugs and checkers we want to analyze will be in the bug_buckets folder by default. To print out the overview, run the following code:

└─$ cat bug_buckets.txt
InvalidValueChecker_500: 1
InvalidDynamicObjectChecker_20x: 2
PayloadBodyChecker_500: 2
main_driver_500: 1
UseAfterFreeChecker_20x: 1
Total Buckets: 7
-------------
InvalidValueChecker_500 - Bug was reproduced - InvalidValueChecker_500_1.replay.txt
Hash: InvalidValueChecker_500_5f9bb084cbb3a2529b26bf690142685a65bd355b
GET /api/blog/posts?page=1&per_page=1 HTTP/1.1\r\nAccept: application/json\r\nHost: localhost:8888\r\nauthentication_token_tag\r\n
--------------------------------------------------------------------------------
InvalidDynamicObjectChecker_20x - Bug was reproduced - InvalidDynamicObjectChecker_20x_1.replay.txt
Hash: InvalidDynamicObjectChecker_20x_080f3c85aec4b427307e03c004ffe30a 9e899238
POST /api/blog/posts HTTP/1.1\r\nAccept: application/json\r\nHost: localhost:8888\r\nContent-Type: application/json\r\nauthentication_token_tag\r\n{\n    "id":1,\n    "body":fuzzstring}\r\n
GET /api/blog/posts/_READER_DELIM_api_blog_posts_post_id_READER_DELIM HTTP/1.1\r\nAccept: application/json\r\nHost: localhost:8888\r\nauthentication_token_tag\r\n
--------------------------------------------------------------------------------
[SNIPPED]

Here, you can analyze the results of the fuzzer to further understand the results of the scan, as well as to get further information about the bugs found.

In a nutshell, RESTLer allows us to fuzz our APIs through a simple process of compiling, testing, and fuzzing to acquire the results. Other tools help in API fuzzing that have not been discussed in this session, so feel free to experiment and find a fuzzing tool that works for you.

Next, we’ll cover injection attacks.

Injection attacks

Injection attacks on APIs refer to security vulnerabilities that allow malicious actors to inject and execute unauthorized code or commands through the input parameters of an API. These attacks exploit weaknesses in the API’s input validation and sanitization mechanisms, enabling attackers to manipulate data, execute arbitrary commands, or access sensitive information.

Databases are an essential component of modern computing systems that are used for storing, organizing, and managing vast amounts of data supplied by consumers. There are several types of databases, each designed to address specific requirements and use cases. The more common database types are relational databases, which use SQL to manage data, and NoSQL databases such as MongoDB and Redis, which offer a non-relational approach to data storage.

SQL injection is a widespread and well-known type of injection attack that poses a threat to web applications and APIs. It is crucial to assess the security of your API against SQL injection vulnerabilities.

To illustrate how to exploit the injection attack vector, we’ll be using crAPI, an intentionally vulnerable API by OWASP that can easily be added to your home setup. crAPI’s purpose is to teach, learn, and practice how to exploit common vulnerabilities that occur in modern API-based applications, including those in the OWASP API Security Top 10. The API’s installation instructions can be found in the project’s GitHub repository. After installing it in your home lab, you can find it on your localhost at port 8888: http://localhost:8888/.

In this context, we will focus on testing the login endpoint of crAPI to determine if it is susceptible to this type of attack. Two essential tools in testing and applying SQL injections are Burp Suite and SQLMap. We’ll start by fuzzing, where we’ll use Burp Intruder with a common SQL injection wordlist on our email login parameter.

You’ll need to follow the steps we performed in the previous section while using Burp Intruder to fuzz this attack. However, instead of loading the api-endpoints.txt payload, you’ll need to use the /usr/share/seclists/Fuzzing/SQLi/Generic-SQLi.txt wordlist as your payload:

Figure 5.14 – Loading the wordlist

However, after running the attack, you won’t receive any positive responses:

Figure 5.15 – Burp Suite injection result

To further test for SQL injection, we can utilize the powerful SQLMap tool. Designed specifically for detecting and exploiting SQL injection vulnerabilities in web applications, it automates the identification and exploitation process, making it a valuable asset for security researchers and ethical hackers.

To test with SQLMap, we’ll save the login request to a file by selecting the Copy to File option after right-clicking on the Request tab. We’ll save it as sqli.req. To perform the SQLMap test, we need to modify the parameter, setting * as the email and * as the password in the request file:

{"email":"*","password":"*"}

The SQLMap command we’ll use is shown here:

sqlmap -r sqli.req --technique=BEUSTQ --level=5 --risk=3 –batch

Running this command should give us the following output:

└─$ sqlmap -r sqli.req --technique=BEUSTQ --level=5 --risk=3 --batch
        ___
       __H__
 ___ ___[.]_____ ___ ___  {1.7.2#stable}
|_ -| . [.]     | .'| . |
|___|_  [(]_|_|_|__,|  _|
      |_|V...       |_|   https://sqlmap.org
[!] Legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting @ 21:21:12 /2023-06-25/
[18:10:12] [INFO] parsing HTTP request from 'sqli.req'
custom injection marker ('*') found in POST body. Do you want to process it? [Y/n/q] Y
JSON data found in POST body. Do you want to process it? [Y/n/q] Y
[18:10:30] [INFO] testing connection to the target URL
[[SNIPPED]
[18:14:24] [INFO] testing 'MySQL UNION query (random number) - 1 to 10 columns'
[18:14:24] [WARNING] (custom) POST parameter 'JSON #2*' does not seem to be injectable
[18:14:24] [CRITICAL] all tested parameters do not appear to be injectable. If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could try to use option '--tamper' (e.g. '--tamper=space2comment') and/or switch '--random-agent'
[18:14:24] [WARNING] HTTP error codes detected during run:
400 (Bad Request) - 17564 times

Let’s break down the different components of this command:

• sqlmap: This is the command that’s used to execute SQLMap.
• -r sqli.req: This option specifies the path to the requested file (sqli.req, in this case) that contains the captured login request. SQLMap will analyze and test this request for SQL injection vulnerabilities.
• --technique=BEUSTQ: This option sets the technique to be used by SQLMap to test for SQL injection. In this case, the BEUSTQ technique is specified. SQLMap offers various techniques to exploit different types of SQL injection vulnerabilities.
• --level=5: This option sets the testing level of SQLMap. The level ranges from 1 to 5, with 5 being the highest level of thoroughness. Setting it to 5 ensures that SQLMap performs an extensive search for vulnerabilities.
• --risk=3: This option sets the risk factor for SQLMap. The risk factor ranges from 1 to 3, with 3 being the highest risk level. Setting it to 3 indicates that SQLMap should be more aggressive in its testing.
• --batch: This option enables batch mode in SQLMap, which allows it to automatically test and exploit the detected SQL injection vulnerabilities without user interaction.

After executing this command, we found that the login endpoint is not vulnerable to SQL injection. It is crucial to thoroughly test every endpoint in your API that interacts with the database through user-supplied inputs.

NoSQL injection in APIs refers to security vulnerabilities that allow attackers to manipulate NoSQL database queries through API input parameters, leading to unauthorized data access or modification. NoSQL databases, such as MongoDB, use different query languages and data models than traditional SQL databases, making them susceptible to different types of injection attacks.

Unlike SQL injection, where attackers exploit the structure and syntax of SQL queries, NoSQL injection attacks target the unique characteristics of NoSQL databases. These attacks typically involve injecting malicious input into API parameters that are directly used in NoSQL queries or commands.

We’ll test for this vulnerability on crAPI using the /community/api/v2/coupon/validate-coupon endpoint. To start, we'll capture a request to the endpoint and send it to the Burp Repeater tool. We'll manually try out NoSQL payloads to see if we will get any unusual responses.

The payload we’ll test first will be {"$ne": null}. The {"$ne": null} expression is a way to specify a condition in MongoDB queries to retrieve documents where a field is not equal to null. This will retrieve the first coupon_code endpoint that is not null, giving us a response containing a valid coupon:

Figure 5.16 – NoSQL exploitation 1

Now, let’s try to get another coupon that is not equal (ne) to the one we already have. To do that, we’ll use the {"$ne": "TRAC075"} payload:

Figure 5.17 – NoSQL exploitation 2

With that, we’ve seen how exploiting injection attacks on APIs, including SQL injection and NoSQL injection, pose serious threats to the security and integrity of systems. These vulnerabilities can be exploited by attackers to gain unauthorized access, manipulate data, and compromise the overall functionality of an API. Developers and security professionals need to be careful and implement robust security measures to prevent and mitigate injection attacks. This includes thorough input validation, parameterization, and sanitization techniques, as well as regular security audits and updates.