Burpsuite Burp Collaborator Module Introduction

Burp collaborator. is a new feature added from the Burp Suite v1.6.15 version, which is almost a completely new penetration test method. Burp collaborator will gradually support blind XSS,SSRF, asynchronous code injection and other types of vulnerabilities that are not yet categorized.

This article mainly introduces the use of Burp collaborator to probe these kinds of vulnerabilities.

Concept: In-band attack and Out-band attack (in-band and out-of-band attacks)

First, two concepts are introduced, the difference between in-band and out-of-band is the use of different communication channels.

In one attack, there is only one channel, which belongs to the In-band (in-band) attack:

Now, with more than one channel under the same attack, it belongs to the Out-band (out of band) attack:

General Web test Model

In a nutshell, the general Web test model is that we send payloads to the target and analyze the data returned by the target.

This model is easy to build and easy to understand, but this simple model misses a lot of bugs, such as:

1. "Super-blind" injection. "Blind SQL injection" means that when a payload destroys a normal SQL query, however, the content returned by the application does not have any helpful error messages. In some cases, however, a successful injection is completely indistinguishable from the return of the target application, meaning that there is no difference in whether the returned content or the time returned. As an example, injecting asynchronous logging function is a typical case.
2. The situation where the data needs to be stored. For example, the storage-type XSS can be found by first committing payloads and observing the return value. However, other storage-type bugs are difficult to find, for example, stored (or second-order) SQL injection, where data is stored in the database in a secure manner before being removed from the database and then stitching the SQL statements. To use a regular penetration model to discover this vulnerability, we need to explode the combination of each request, send the first request, then send the second request and then observe the return value.
3. We will also miss a vulnerability where a successful attack occurs only within the application and is not visible to the attacker. For example, a storage-type XSS attack successfully requires an administrator to access the administrative address.
4. There are also many situations involving internal systems interacting with external resources, such as SSRF and RFI.

Web test model after adding burp collaborator

Burp collaborator adds a new section to the traditional Web test model, and Burp collaborator features:

• Captures data interaction behavior of payloads triggered by burp and external systems
• Return data from Burp collaborator and Target data interaction is returned to the attacker
• Reliable detection of many new vulnerabilities.

The Burp collaborator module contains the following features:

• Burp collaborator servers are usually run on the public network.
• It uses its own private domain name, and this server is registered as the authoritative DNS server for that domain name.
• It provides a DNS service that can respond to any DNS requests to him
• It provides the HTTP/HTTPS service, using a valid SSL certificate
• Additional services, such as SMTP and FTP, can be added in the future.

Probing external service interaction (external service interaction attack)

Interaction with an external service occurs when a payload commits to the target application, causing the target to interact with the information through a network protocol and an external domain name.

This behavior is sometimes referred to as SSRF, and we are more inclined to call it an external service interaction ("External service interaction") attack, because in this case, many behaviors are not only triggered by the HTTP protocol, but also SMB or FTP.

An external service interaction can represent a serious vulnerability because he can allow the application server to attack other servers as a proxy. This parcel of the third-party system above the public network, the same organization under the internal system or monitoring the local service. Depending on the network structure, this can expose an internally vulnerable system to an external attacker.

Burp payload contains a list of random subdomains of the Brup collaborator primary domain. When an HTTP-based external service interaction attack occurs, the collaborator server receives a DNS query for the specified subdomain name. The DNS query received is sufficient to confirm that there is a problem. If a payload with http://... Begins with only one DNS interaction, it is almost certain that the destination server is blocking external HTTP requests. In this case, subsequent attacks can be targeted at other organization services or target other IPs. For this reason, burp separately reports the DNS and HTTP interaction behavior that is triggered.

In Burp's issue advisory, the Burp report shows all the details of the request and collaborator server interaction that attempted to make the target server interact with the external service.

Probe Out-of-band resource load (out-of-band resource load)

Out-of-band resource load occurs when a payload is sent to the target application, causing the target to try to get the content through a domain name first, and then consolidate the acquired content into the original return data.

This behavior is sometimes categorized as a remote file inclusion. But the remote file contains this noun has the meaning of PHP file contains. We're more inclined to call it the "Out-of-band resource load" attack, because in this case, sometimes the app gets the content from the outside and puts it into the application's return results.

Out-of-band resource load attack is a very high-risk issue where an attacker sends payload and then gets data from an application that can interact. In addition, this can also lead to the exposure of third-party systems or sensitive internal systems.

In addition, application processing of Out-of-band content exposes some important and unconventional attack surfaces.

Burp reports the interactive behavior information generated by collaborator server in detail and shows how the content is transferred back from collaborator to the application band and returned to the user.

Detect Out-of-band XSS (out-of-band XSS)

When an external resource load vulnerability has been identified, there is a good chance that Out-of-band XSS

Out-of-band XSS does not fall under the usual XSS classification

• is not a reflective type, payload is not sent to the target app in the current In-band request.
• Not a storage type, payload is not stored in the target application
• Not DOM XSS: There is no existing JavaScript.

Probing "super-blind" injection vulnerability
In the case where a code injection attack does not trigger any information that can be detected, we can confirm the injection success by triggering an external service interaction when the injection succeeds.

The types of payload that can be injected include SQL injection, XXe injection, OS command injection, and so on. With these payloads, burp does not need to obtain any returned information from the target server, but it can successfully detect an injection vulnerability. In this case, only one DNS query is needed to determine the presence of an injection vulnerability. External DNS queries are always allowed because the destination server requires a domain name query.

Probe Out-of-band Injection Vulnerability

When any type of external service interaction is detected, we can use collaborator server's return data to transfer the traditional input payloads to the target server. Because the target application handles collaborator return data, regular vulnerabilities exist, including SQL injection, Server-side code execution, and so on.

This vulnerability can be common and is not fully tested at this moment.

Detecting stored Out-of-band Vulnerability

The target application processes the data obtained from the collaborator server and stores it.

Probing stored Out-of-band resource load is straightforward:

Based on the behavior, we can test stored out-of-band XSS vulnerability:

Detecting blind stored types of vulnerabilities

We have described how to detect "super-blind" injection vulnerabilities, and we can also detect vulnerabilities that need to be stored before being removed by the target. The latency interaction with collaborator Server allows us to discover many of these storage-type vulnerabilities.

For example, the vulnerability of XSS blind play (Blind stored XSS), an attacker could not detect whether the attack was successful because the attacker did not have access to the background. However, we can commit the stored XSS payloads first and then use collaborator server to trigger the interactive behavior.

In this example, when an application administrator accesses a protected page, burp through collaborator server can determine the occurrence of a storage-type attack. Also, the managed address (that is, the back office address) can be known through the HTTP refer obtained from collaborator.

Support for other protocol types

The types of vulnerabilities in the above mainly involve DNS and HTTP protocols, and in fact we can also use other protocols to trigger Collborator and target application interaction behavior:

• Inject mail headers via SMTP protocol for probing
• Triggers an SMB share connection and crawls NTLM handshake
• Triggers an SSH connection and then fetches the authentication credentials.

Original: https://portswigger.net/burp/

Starter: https://www.91ri.org/

Translated in 2016.7.1.

Burpsuite Burp Collaborator Module Introduction