In many of the articles I write here on my blog, I’ve shown you how to demonstrate API exploitability through remote code execution. It sometimes feels like security theater when I use reverse shells to get a foothold on an API server.
Ya, it’s cool. It’s impactful. But it’s smoke and mirrors.
If I have to be honest, when I report actual security vulnerabilities in an API to a vendor, I rarely write exploits that trigger a reverse shell. It’s simply not necessary to prove API exploitability. And I don’t want the responsibility or liability of actually getting a shell on a server unless it’s part of a more extensive engagement in which I need to pivot deeper into the apps and infrastructure.
And sometimes, the project scope may not allow me to catch shells, especially in production environments.
In this article, I will show you what I actually do in these cases. All thanks to a neat feature in Burp Suite Professional called Burp Collaborator.
What is Burp Collaborator?
The Burp Collaborator is a network service that Burp Suite uses to capture the results of many kinds of vulnerabilities it can’t catch on its own.
When Burp Collaborator is used, Burp sends payloads to the API being tested that are designed to cause interactions with the Collaborator server when certain vulnerabilities or behaviors occur. Burp periodically polls the Collaborator server to determine whether any of its payloads have triggered interactions:
How does it work?
PortSwigger hosts a set of cloud servers that implement several mock network services that it uses as collector endpoints.
These servers typically resolve to *.burpcollaborator.net and *.oastify.com, and provide the following services:
- DNS services that answer any lookup on its registered domains (or subdomains) with its own IP address.
- HTTP/HTTPS services that use a valid, CA-signed, wildcard TLS certificate for its domain names.
- SMTP/SMTPS services
If you aren’t comfortable sending responses to your attack payloads to PortSwigger’s hosted services, you can host your own private Burp Collaborator server. This might be useful if you are in constrained environments that can’t reach out to the Internet directly.
Using Burp Collaborator in the real world
Since most of my work cannot be disclosed publicly, I really can’t show you some of the more interesting ways I have used Burp Collaborator. I have written about using out-of-band application security testing (OAST) for blind SSRF detection in an API showcasing an attack against crAPI. But I can give you a better understanding of how to use Burp Collaborator by walking you through some security research for CVE-2023-40044, which is now public.
CVE-2023-40044: RCE in WS_FTP
There is an excellent writeup for CVE-2023-40044 by the folks over at AssetNote. I encourage you to read it.
Go ahead. I’ll wait.
TL;DR – In summary, there is an unauthenticated insecure deserialization vulnerability in one of the IIS modules for the WS_FTP server that allows an attacker to craft a single HTTP POST request that ultimately leads to remote code execution (RCE) on the server.
This is all caused by a dangerous sink used during deserialization. If this concept is new to you, I recommend you check out the Deserialization Cheat Sheet published by OWASP.
To demonstrate exploitability, the security researchers crafted an attack payload using ysoserial.net that used nslookup to send a DNS request to a Burp Collaborator collector.
The result? When WS_FTP receives the HTTP request and deserializes the payload body, it will try to resolve the custom DNS name Burp Suite generated for them and show the event in the Burp Collaborator UI, ultimately demonstrating the deserialization vulnerability via RCE.
How to use Burp Collaborator in your own exploits
So how does this apply to your API exploits?
How many times have you come across potential arbitrary code execution through an injection attack, deserialization, or out-of-band writes? Any one of those situations is perfect for using Burp Collaborator.
Don’t stop there though. You could use the mock servers to test for open redirects, SSRF, and even blind XML External Entity (XXE) vulns. The point is to be creative; if you can craft a DNS or external HTTP request, Burp Collaborator is your friend. And it will stand guard, watching for requests even when you aren’t looking for them.
Let me show you how quickly you can stand up a Burp Collaborator collector.
Generating your Burp Collaborator custom domain
To generate your own custom Burp Collaborator subdomain, all you have to do is click on the Collaborator tab and then click the Copy to Clipboard button.
If you don’t want to use the default Collaborator servers and route requests to your own instead, you can configure that in the Project > Collaborator settings.
Interacting with your Burp Collaborator collector
OK. So in the clipboard is our custom subdomain, ending in oastify.com. To try it out and see it in action, let’s use nslookup and then curl to see it interact with DNS and HTTP.
As you can see from the screenshot, the DNS resolves the subdomain to a server in Amazon AWS. And if we curl directly to it, we get some HTML content.
Now let’s see how these requests look in Burp Suite.
There they are right in the Collaborator tab. Both requests. If you don’t see anything right away (or are impatient), click the Poll Now button.
What’s neat is you can dig into the DNS query or HTTP request/response, allowing you to see the exact payload sent. Useful if you also want to exfiltrate data using Collaborator during your testing.
Limitations with Burp Collaborator
I think it’s only fair to discuss a few limitations with the Burp Collaborator. One of the most significant issues is that you can’t easily export the results. It’s not an issue if you are just trying one or two requests at a time. However, if you were to do something more at scale, you could have hundreds, if not thousands, of events that you must manually sift through.
I did find an interesting article on manually polling by directly interacting with the collector to accomplish this. However, I have yet to try that to know how stable and efficient that might be.
Conclusion
I hope I’ve shown you how to prove API exploitability with the use of Burp Collaborator. It is a more passive methodology that allows you to demonstrate the criticality of arbitrary code execution without actually producing a backdoor shell to the server infrastructure.
This reduces your potential liability while giving the vendor more confidence you haven’t been mucking around in their infrastructure too much while verifying the exploitation of the vulnerability. It’s easy to track at the network level and easily repros to prove your findings.
So give it a try. It may not be as cool as a reverse shell, but it proves the exploitability just as well.
Good luck!
One last thing…
Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.
