Custom HTTP and DNS Endpoints for Attacks

Wapiti’s attack modules, such as Server-Side Request Forgery (SSRF) and Log4Shell, often test for vulnerabilities by attempting to make a server fetch a URL or resolve a DNS query under your control. These URLs or domains are referred to as endpoints. By default, Wapiti uses public endpoints, but it is highly recommended that you set up your own for privacy, improved detection, and flexibility, especially in local network environments.

What are endpoints used by Wapiti?

Some attack modules, like SSRF, inject the URL of an external endpoint into parameters of URLs and forms. If the target is vulnerable, the server will fetch the endpoint URL. The endpoint script will log this request. After the attack finishes, Wapiti queries the internal endpoint to see if the vulnerable script fetched the external URL.

Differences between External and Internal Endpoints

If you don't define custom endpoint URLs with --external-endpoint and --internal-endpoint, the default endpoint used is http://wapiti3.ovh/ for both.

Why should you set up your own endpoints?

• Privacy: While Wapiti provides default endpoints, setting up your own endpoint gives you full control over the data. Even though the Wapiti administrator (for wapiti3.ovh) doesn’t monitor the data, it is better to manage this on your own infrastructure.
• Detection: The default wapiti3.ovh domain is hardcoded in Wapiti’s source code, making it easier for intrusion detection systems to flag your scans. Custom endpoints reduce this risk.
• Network Limitations: If the target is on a local network and cannot access external domains, you’ll need to set up your own endpoints on that network. For example:
  • External endpoint: http://192.168.1.85/ (requested by the target)
  • Internal endpoint: http://127.0.0.1/ (queried by Wapiti after the attack)

Endpoint Configuration Options

• --external-endpoint EXTERNAL_ENDPOINT_URL
  This option defines the URL that serves as the external endpoint for the target during attacks. For instance, in SSRF or XXE attacks, this URL is injected into target parameters, and the server will fetch resources from it if vulnerable. Example:

  wapiti -u "http://target.com" --external-endpoint "http://192.168.1.85/"

• --internal-endpoint INTERNAL_ENDPOINT_URL
  This option sets the URL that Wapiti (the attacker) will query to check if the target fetched the resource after an attack. It’s usually queried after the attack concludes to verify if the target reached out to the external endpoint. Example:

  wapiti -u "http://target.com" --internal-endpoint "http://127.0.0.1/"

• --endpoint ENDPOINT_URL
  This option sets a single URL that will serve as both the external and internal endpoint, simplifying the setup when both parties use the same URL. Example:

  wapiti -u "http://target.com" --endpoint "http://192.168.1.85/"

DNS Endpoint for Log4Shell Attacks

• --dns-endpoint DNS_ENDPOINT_DOMAIN
  The Log4Shell attack module uses this option to define a DNS domain that serves as the endpoint for detecting vulnerabilities related to the Log4j vulnerability. The domain will be queried by the target, and Wapiti will check if the DNS request was made to confirm the attack's success. Example:

  wapiti -u "http://target.com" --dns-endpoint "log4shell.mydomain.com"

Modules Using Endpoints

The XXE module also uses these endpoint options similarly to SSRF, where an external entity is injected into XML files. The attack flow and endpoint usage are detailed in the doc/xxe_module.md file.