RevSuit v0.7.1 releases: Flexible and Powerful Reverse Connection Platform

RevSuit – A Flexible and Powerful Reverse Connection Platform

RevSuit is a flexible and powerful reverse connection platform designed for receiving connections from the target hosts in penetration. It currently supports HTTP, DNS, RMI, LDAP, MySQL, and FTP protocols.

Flexible:

1. RevSuit can set flexible rules to capture different connections.
2. Deploy and run via binaries without worrying about nasty dependency errors.

Powerful:

1. Allows to customize the response for different connections through rules and supports dynamic response generation using template variables.
2. Support a variety of protocols, and support the in-depth utilization of some protocols, such as DNS rebinding, MySQL Load Local Data, JDBC Deserialize Exploit, FTP Passive Mode SSRF, etc.
3. Native support for use with scanners.
4. Support push notifications to popular office software.
5. Other thoughtful and detailed features.

Use with Scanner

RevSuit was split from my scanner project, so its native support works with scanners.

From RevSuit’s perspective, we call a scanner a client.

Establish connection

RevSuit uses HTTP Server-sent Events (SSE) to establish a one-way communication channel with the client.

The API for the channel is: /revsuit/api/events?message. The client first needs to add the Token: your token header to the Header, and then access the API to establish the channel. When the platform receives a new connection, the flag captured by the rule will be passed to the client through this channel.

Here is a simple demo using Golang’s sse library as an example.

Multi-client

As shown above, RevSuit supports multiple clients, and each client in the connected state receives a push of flag, so distributed scanning can be supported.

Temporary storage queue

RevSuit will store the flag temporarily in the queue when there is no client connection and send it when the client connects, so you don’t have to worry about missing the vulnerability because the client disconnects. (This is especially helpful for discovering delay-triggered vulnerabilities.)

Use flagGroup

In a real-world vulnerability scanning scenario, you may send a large number of different payloads for a single vulnerability point, and they may all be valid, which can result in the backlink platform receiving many requests, yet they are caused by the same vulnerability. If you don’t want the client to receive so many flags for the same vulnerability, you can take advantage of the flagGroup feature of rule’s flagFormat.

FlagGroup is the content matched by the anonymous group in the flagFormatfield of the rule. The platform will check the content matched in the grouping, and the flag is only pushed to the client when the content(flagGroup) is captured for the first time.

For example, SSRF scanning.

Firstly create a rule like the following:

http:

  - name: ssrf

    flag_format: (ssrf[a-z0-9]{6})[0-9]{1,3}

    rank: 0

    push_to_client: false

    notice: false

    response_status_code: "200"

    response_headers: { }

    response_body: "Here is a SSRF!"

Suppose our target is https://www.testvuln.com?url=api.com&p=useless, and for SSRF we have 5 payloads. The final request sent by the scanner may be [‘https://www.testvuln.com?url=http://revsuit.com/ssrfa98oni1&p=useless’,’https://www.testvuln.com?url=http://revsuit.com/ssrfa98oni2&p=useless’, … ,’https://www.testvuln.com?url=//revsuit.com/ssrfa98oni5&p=useless’]. They may all attack successfully.

However, because anonymous grouping is used in the rule’s flagFormat, The platform will query the connected flagGroup, in this case, ssrfa98oni, and push the flag to the client only at its first appearance, so the client will only receive one flag:ssrfa98oni1. It already proves that the url parameter of the target is vulnerable.

Multi-module collocation

In actual penetration testing scenarios, certain tasks can be done easily and quickly by combining and matching various modules of RevSuit. The following is an example of a blind XXE in Java Web, showing how to use RevSuit’s HTTP and FTP modules, combined with template variables, to quickly complete a port scan.

First, create an HTTP rule to return evil.dtd, customize the response to the contents of dtd so that it goes to connect to RevSuit’s FTP service, and use template variables to pass the Host and Port to be scanned to FTP via FTP’s user and password.

Then create an FTP rule that receives the Host and port to be scanned from the user and password template variables, set to Pasv Address.

Then use BurpSuit to launch the scan, by setting the host and port parameters in the evil.dtd URL to set the target of the port scan.

The running effect is as follows:

It is because the FTP connection will be crashed if Passive Address is not accessible, we can determine whether the port is open or not based on whether the connection exits normally. For this example, we successfully detected that port 8005 and 8080 are open.

Changelog v0.7.1

Bug Fixes

• fix the error that the maximum length of http rule response body is 191 when using mysql (bf8a43f)

Install & Use

Copyright 2021 Li4n0