Detecting malicious OOB: Part -1: Hunting for OOB server - Interact.sh

What's OOB?

OOB (also known as Out of band) is often referred to as an external interaction by an application. Applications very often have functionality to interact with external sources on the Internet for various purposes. This functionality is often abused for SSRF (Server side request forgery) among other vulnerabilities.

What's needed for testing an OOB interaction?

For testing the presence of SSRF vulnerability of any other vulnerability (like Blind SQL) which involves OOB, security researchers use various tools such as "Burp collaborator", "Interact.sh", "DNSBin", "DNSObserver". A unique URL is generated by respective tools and these URLs are used in payloads. When the vulnerable server sends request to the URL generated by the tool, the tool captures the request and documents the request.

Online OOB testing tools v/s self-hosted:

Security researchers and attackers use either an online or a self hosted tool. Below are few online options for security researchers:

The need for detecting malicious OOB interaction:

As mentioned earlier, OOB interaction is very often associated with legitimate functionality and malicious vulnerability exploitation. Below are few examples of how malicious OOB interaction problem exists:

• Out of Band SQL Injection

• Out of Band Remote File Inclusion

• Out of Band SSRF exploitation

It's quite evident that exploitation of the vulnerability might involve an OOB interaction. Detecting the OOB interaction would mean the detection of a possible exploitation attempt. One way of differentiating malicious OOB v/s legitimate OOB interaction boils down to the destination. If we are able to identify if the destination host might be hosting a tool that's used to test OOB interactions.

Detecting Interact.sh

We've established the fact that there are several alternatives to Burp collaborator and Interact.sh which don't require registration, but why are we behind Interact.sh?

The reason for that is very simple, most of the discussed tools are easy to detect using the URL pattern. However, for "Interact.sh", it generates unique URLs on a domain of attackers choosing. This opens up a tremendous attack surface as it'd allow anyone to host their own server (for OOB testing) and integrate with latest offensive security tools like Nuclei, Burp, etc.

Detecting Interact.sh

A simple GET command provided an insight into the response that Interact.sh gives for a rrequest. If the response is carefully observed, there's a header that's unique to the way Interact.sh gives response. The X-Interactsh-Version header. The header can be modified using the source code or by giving command line parameter: check this & this.

A simple Shodan search resulted in ~400 hosts on the Internet. Don't get me wrong, it's possible to modify this through code but it's a good start.

Final thoughts

• By detecting Interact.sh or all the tools mentioned in the post, it's still possible that the attack might slip out of the hands as an adversary might simply host a python HTTP server (python -m SimpleHTTPServer) to host a server and record OOB interactions.

• While this doesn't detect all possible malicious OOB interactions, something's better than nothing and considering that Interact.sh is a very popular tool that's used by security researcher (and possible attackers), it's a good thought to stay a step ahead.

• If you are a cloud security provider and you see someone is using your platform for hosting interact.sh, there's a very good chance that they're abusing your Terms of Service (or depends on your agreement with them) and hence you need to start looking at it.

• In the next parts, we'll talk about how we can detect malicious OOB communication using host based artefacts such as process-network communication, etc. If you would want me to dive me into something adjacent, please feel free to ping me: @pbssubhash

Until then, Good Bye!