A number of vulnerabilities exist on the web, but the majority of them are not triggered directly. This is because they do not produce any specific output or error. However, is the output or error the only way to determine whether the vulnerability exists or not?

So, today in this article of the series of Burp Suite for Pentester, you’ll learn how to detect out-of-band or blind vulnerabilities using one of the most amazing features of Burp Suite, i.e., Burp Collaborator.

Table of Content

• Introduction to Burp Collaborator
• Detecting vulnerabilities with Collaborator Client
  • Blind Remote Command Execution
  • Cross-Site Scripting Detection
  • Blind XXE
  • Server-Side Request Forgery
  • Fuzzing for SSRF Detection

Introduction to Burp Collaborator

Burp Suite’s Professional edition offers one of its best features: “Burp Collaborator.” This feature helps users determine or detect vulnerabilities that interact with external services but do not cause any noticeable difference in the content of the application’s responses when they inject specific payloads.

In simpler terms, this collaborator essentially serves as a network service that Burp Suite uses to detect out-of-band vulnerabilities. It works by injecting payloads into the application and then waits for the response to analyze any unusual behaviors.

Being a network service, Burp Collaborator operates seamlessly with both a server and a client to fetch the hidden responses made by the application. So, let’s take a deep dive with what these server and clients are, and where we can find them.

Burp Collaborator Server

Burp Suite uses the Burp collaborator server as a service while auditing or testing vulnerable web applications to find sections that interact with an external system. However, this Burp server only responds to the interactions it receives from the other systems by continuously polling its client to determine whether any of its payloads have triggered interactions or not.

By default, Burp uses the public Collaborator Server provided by PortSwigger, but it even offers the feature to host or deploy a private Collaborator Server too. Thereby, in order to modify the server configuration, simply head to the Project option and then switch to the Misc tab there.

However, for this section, we’ll be using the default collaborator server. But before following up further, let’s do a health check by hitting the Run heath check button in order to be sure that our collaborator is working properly.

Great from the below image we can see that our collaborator server has passed all the tests.

Burp Collaborator Client

Burp Collaborator Client is a tool to make use of the Collaborator server during manual testing. This collaborator client helps us to generate payloads such that we can use them over at the injection points in the vulnerable applications with Burp’s Intruder or Repeater.

However, with this client, we can even poll the collaborator server when there seems to be a network interaction with the injected payload.

The Burp Collaborator Client resides within the Burp tab at the top left section, as shown in the image.

As we move forward by hitting the Client option, we will be redirected to a new window. This window is the Collaborator client. Dropping several options within it, there are two important ones – Copy to clipboard; & Poll.

As the name suggests, the “Copy to Clipboard” option simply copies the generated payload(s), allowing us to paste them wherever needed. On the other hand, the “Poll Now” option enables us to poll the server immediately, rather than waiting for the default time of 60.

Nevertheless, the “Number to Generate” and “Poll Every” options are also important. In the “Number to Generate” section, we can modify the number of payloads to be generated, ranging between 1-10. This helps when performing fuzzing. On the other hand, if performance is not a concern, we can reduce the time (in seconds) in the “Poll Every” option. This will automatically poll at a quicker interval.

Detecting vulnerabilities with Collaborator Client

Up till now, you might have had a clear vision about what Burp Collaborator is and its client, and where to find them. So, let’s use this amazing feature to have some practical exposure by detecting and finding the most crucial out-of-band vulnerabilities.

Blind Remote Command Injection

Remote Command Injection, or OS Injection, is a vulnerability in which the attacker tries to perform system-level commands directly through a vulnerable application to retrieve information from the web server.

But there are times when the results of the injected commands are not displayed back at the application, and even the error messages are not returned. So, does the command injection exist in such a situation?

Let’s find it out !!

Setting Up the Target

Head to the bWAPP vulnerable application and opt for OS Command Injection—Blind by setting the security level to low.

 

Over there, as we tried to ping our local machine with “127.0.0.1”, we didn’t get any output neither any error, just we got a message “Did you captured our GOLDEN packet?”.

So, with this output, we can’t determine whether the application is suffering from OS command Injection or not.

Thereby, in order to confirm this, we’ll be using the Burp collaborator, which will pop out the response if the application somewhere or the other tries to interact with any other external service(DNS; HTTP; SMTP).

Let’s copy the collaborator payload by navigating to Burp at the dashboard and then opting for Burp Collaborator Client.

Testing with Burp Collaborator

Now this time we’ll modify the input value, i.e., along with the IP we’ll inject the collaborator payload too, and will hit the “Ping” button

127.0.0.1|nslookup <Burp Collaborator copied payload>

As soon as the page reloads, we still see the same output, but over at the Burp Collaborator Client’s window, new entries fill in as we hit the Poll now button. Let’s check them out.

With the first response, we could notice that the application used the DNS service as the payload was bound with the nslookup command. Thereby this confirms that the web-page is vulnerable to OS Command Injection.

Cross-Site Scripting Detection

Malicious scripts inject themselves into trusted websites in a client-side code injection attack known as Cross-Site Scripting, and these scripts trigger when the user visits the specific suffering web page.

But many times, we never know where our injected payload will end up or when it will be executed.

To determine whether our payload executes or an external service triggers it, we’ll use Burp Collaborator, which dumps the responses in the client window as soon as it gets hit.

Setting Up the Target

By initiating back into the bWAPP application and opting for the XSS – Stored (User-Agent), we’ll thus see that our user-agent value stores itself into the database.

 

Now, turn ON the browser’s poxy and head to the Burpsuite’s Proxy tab, and capture the ongoing HTTP Request.

So, in order to manipulate this User-Agent, let’s first copy the Collaborator payload by moving the Collaborator Client window.

Back into the proxy tab & modify the User-Agent with the image tag and hit the forward button.

<img src="http://copied_payload_value">

Confirming the XSS Vulnerability

As soon as we do so, we got the alteration in our Client window, the burp payload has been triggered by an external service, which thus confirms that there is a Cross-Site Scripting exists up.

NOTE –

However, this is a basic demonstration since the vulnerable application has been hosted locally. In real-life scenarios, it takes more time for the administrator or developer to execute the attack, as many applications store user-agent information in their databases. In order to explore more about Blind XSS exploitation, visit our previous article from here.

Blind XXE

XML External Entity (XXE) attacks are becoming increasingly common today, as nearly every application handles and parses XML inputs. However, most of these attacks are blind, as the improperly configured XML parser processes the malicious content without rendering it directly on the visitor’s screen.

But these Blind XXE vulnerabilities can be encountered with some great tools, I hope you’re getting me. Yes, Burp Collaborator, it can even detect the blind XXE triggered. Let’s check it out how.

Step 1: Access the Lab

Login into the PortSwigger academy and drop down till XML external entity (XXE) injection and further choose the lab as “Blind XXE with out-of-band interaction” and hit “Access the lab” button.

Step 2: Exploring the E-commerce Webpage

There as we do so, we’ll be redirected to an e-commerce web-page; let’s check out the details of the “Vintage Neck defender”.

Step 3: Capturing HTTP Request in Burp Suite

Over in the details of the item, as we scroll down to the bottom, we got something like “Check Stock”. Seems to be suspicious, let’s turn ON our burpsuite monitor and capture the on-going HTTP Request for the Stock values.

And there we go; We got the XML queries that are dumping the data out of this.

Step 4: Injecting Payload for XXE Detection

Time to modify the content and check for an XXE vulnerability, to detect let’s co

py the Collaborator payload value!!

Step 5: Modifying the Request in the Repeater Tab

Now, let’s first share the request to the Repeater tab and then we’ll inject the copied payload into the XML data and call up the value within the productID as shown in the below image  –

<!DOCTYPE stockCheck [ <!ENTITY xxe SYSTEM "http://payload_value_.burpcollaborator.net"> ]>

Step 6: Sending the Request and Checking for Responses

Now, as soon as we hit the “Send” button we got the response in the Repeater tab.

But wait, it’s an error an “Invalid Product ID”!! Now what?

Let’s check out the collaborator, did the request hit at the background or not. And there it is, this time, not only the DNS but also an HTTP service has also been triggered.

Step 7: Checking the HTTP Response

Let’s take a look at the HTTP response. There it offers us a Request and a Response from the collaborator.

Over in the request tab as the host has been modified, thereby over in the response, we got the section injected into the HTML which confirms the detection and exploitation of the XXE vulnerability.

Server-Side Request Forgery

SSRF or Server-Side Request Forgery is the most crucial web-application vulnerability where the attacker can use the vulnerable application to send a crafted HTTP Request to a third-party server or application to fetch internal information, banners, or open ports. However, most of the time, the response from the application comes in the form of an error. But there are instances where a possible SSRF occurs without any error, i.e., in a Blind scenario. In such cases, we can rely on our helpful tool, “Burp Collaborator.”

Let’s start.

Accessing the Lab

Back into the PortSwigger Academy, switch to Blind SSRF with out-of-band detection and hit the Access the lab button.

>

As soon as we do so, we’ll be redirected back into the shop page, but this time content is somewhat different. Let’s check the second item within it.

But before accessing the item, let’s turn our Burp monitor and capture the ongoing HTTP Requests for it, and as it captures them, we’ll throw it directly to the repeater.

Manipulating the Request

Over in the request section, the referer value seems to be injectable let’s manipulate it.

Back with the collaborator client window, copy the payload, and modify the referer with it.

And there we go, as we hit the “Send” button, we received the 200 OK, but where is the output, is it vulnerable or did our payload trigger??

Back in the Collaborator client window, when we hit the “Poll Now” button, our responses appeared in front of us. This confirms that a possible SSRF vulnerability exists.

Let’s open the browser again. Cool, the lab is cleared.

Fuzzing for SSRF Detection

Over in the previous section of PortSwigger’s lab, we’ve encountered the Blind SSRF with a single payload. But what if the payload didn’t work ??

Thereby, for such situations, we can fuzz the injection points in order to determine the SSRF’s crucial hit.

Navigating to the Mutillidae Application

Let’s move to the Mutillidae application and then we’ll navigate to OWASP 2017 | A1 – Injection

(Other) | Application Log Injection | DNS Lookup.

>As soon as we reach there, we got an input field to enter the IP Address, let’s enter the localhost IP.

Configuring Burp Suite and Fuzzing

Before hitting the “Lookup DNS” button, let’s first configure our Burp monitor to intercept the passing HTTP request. Once it captures the request, we can then share it with the Intruder tab for further exploitation.

>

Over in the intruder tab, we’ll modify the injection point and set the payload position at the IP address we’ve entered.

Now time to take help. Back into the collaborator client window, set the number to generate to 10, and hit the copy to clipboard button.

In the payload section, simply click the “Paste” button to transfer all the copied payloads into the empty box. Then, click the “Attack” button to initiate the fuzzer and begin the process.

And there we go, every payload has the same length. Let’s check whether the collaborator does offer something or not.

Great !! From the image below, we can see that the application triggers a large amount of DNS service.

Confirming the presence of an SSRF vulnerability.

To learn more about Burp Suite for Pentesters. Follow this Link.

Author: Geet Madan is a Certified Ethical Hacker, Researcher, and Technical Writer at Hacking Articles on Information Security. Contact here