API Enumeration with Kite Runner
Introduction to KiteRunner
Throughout the years web applications and their design have changed. World shifted from having static pages on the server for requested path, to each path leading to a piece of code. Heavy portion of interaction with modern web applications is done through APIs. And while there existed numerous tools for conventional web application enumeration, none were designed to target APIs specifically, until Assetnote release KiteRunner.
KiteRunner is a brute forcing tool specifically designed for API enumeration. Conventional enumeration tools, such as ffuf, dirbuster or gobuster were focused on discovering files and directories, which is great for older style web applications that host static files. However, with modern web applications and API implementations the are not so effective. To clarify, modern APIs may require correct HTTP method, headers, parameters, and values to give valid response. This is where KiteRunner comes into play.
One of the great advantages of KiteRunner is use of contextual information how that specific API was built. What authors of the tool, aka Assetnote, have done, is, they gathered OpenAPI/Swagger specifications from the internet. This is how contextual awareness is introduced to KiteRunner. With swagger files, they could understand the patterns of how modern API are built and requirements when interacting with one.
Let’s take a look at the simple example of API specification for Flask:
Following endpoint can only be reached by PUT or DELETE HTTP methods. Furthermore, within path there has to be an integer specified at the end, otherwise not found exception raised. Thus, unless with traditional wordlist file contained path and integer at the end, and was run with PUT or DELETE method, this endpoint would have been missed by the conventional tools.
With KiteRunner, possible endpoints and their requirements are automatically generated based on dataset of OpenAPI/Swagger files available, which increases the chance to find this type of endpoints.
KiteRunner also has functionality to replay particular request and send it to the proxy. This is extremely helpful in reconnaissance stage, where detection needs to be inspected furthermore. We can replay the request, then capture it with proxy of our choice, be in BurpSuite or OWASP ZAP and interact with it furthermore.
Let’s take a look at hands on examples, but first we need to install KiteRunner on our system.
KiteRunner is written in Go, making it cross platform. Since testing was done on Kali Linux, we can simply take pre-compiled binary from the tool’s GitHub page. As an alternative we can build the tool from the source code as well, which also gives option to modify the code if necessary. We will showcase building KiteRunner from source code.
First, we need to install Go:
Sudo apt install golang-go
After we have Go on our system, we must fetch the source code from the Github:
After navigating to local repository, we can compile the project:
This will fetch bunch of dependencies as well.
Next, we will create a symbolic link between location in $PATH variable and actual runner, which will make it possible to execute KiteRunner from any location.
ln -s $(pwd)/dist/kr /usr/local/bin/kr
Installing Generic University
Generic University is an open-source project, specifically designed to be vulnerable. It is meant to be a good practice platform, specifically for API testing and demos. Generic University has an API that is vulnerable to number of OWASP API top 10 vulnerabilities. Thus, it is ideal for our purpose to get more familiar with API testing and KiteRunner more specifically.
There is set of instruction contributed to the project that help spin up Generic University and all the dependencies that it needs to function. Kali Linux guide can be found on following URL – https://github.com/InsiderPhD/Generic-University/blob/master/KaliSetup.md
Enumerating an API with KiteRunner
For its purpose KiteRunner has two main commands: brute and scan. The scan tool is specifically for APIs and it uses contextual information learnt from OpenAPI/SWAGGER files. Brute command is more conventional and it requires regular wordlists to work. Luckily, you can use both approaches within single commands, specifying .kite files for scan and wordlist for brute force.
kr scan http://127.0.0.1 -w /home/kali/Downloads/routes-large.kite
The screenshot shows KiteRunner switching between HTTP methods and applying contextual information. For example, when it tried to reach out to /registercustomer endpoint, it used POST method, which makes sense if we depict endpoints functionality based on path – it should register customers.
They output above is prettified by KiteRunner, but other type of outputs, such as json and text can be specified with an -o flag. However, we see that there were quite a lot of status 404 responses, which we are not really interested in. We can omit these by adding status code 404 in –fail-status-codes.
kr scan http://127.0.0.1 -w /home/kali/Downloads/routes-large.kite –fail-status-codes 404
From the screenshot we see several status 500 responses and as an attacker this immediately seems interesting. First thing that comes to mind, is information disclosure, as in many cases server errors disclose detailed information about the server. To investigate this in depth we can replay the request and get all the details. It will show the reconstructed request and a response received from the server. For this we must copy full line from initial output and supply it to replay command.
kr kb replay -w /home/kali/Downloads/routes-large.kite “POST 500 [ 635495,34703, 260] http://127.0.0.1/api/users 0cf6836c0b7c65441c17d77419d09b3763dbd014“
This produces huge output, based on which we can learn further details regarding the target (truncated screenshot):
Additionally, we can replay the request and send it to the proxy of our choice. We simply have to add –proxy to the command and capture.
kr kb replay -w /home/kali/Downloads/routes-large.kite “POST 500 [ 635495,34703, 260] http://127.0.0.1/api/users 0cf6836c0b7c65441c17d77419d09b3763dbd014” –proxy=http://127.0.0.1:8080
From simple replay we already can see PHP minor version which is great information for an attacker.
We have covered main functionalities of KiteRunner, but there is quite a bit more to explore, which we will leave to the reader 😊.
Enumeration is the most crucial part in Offensive Security, where poor performance can lead to devastating results. Now knowing about an endpoint may result in false assumptions regarding security. KiteRunner is a fresh and great tool that tackles modern web applications and APIs in particular. It is exciting to see its development and integration with other security tools.