Title: Detecting and annoying Burp users
Date: 2021-05-03 14:00

I've been using some of those tricks on [websec.fr](https://websec.fr) for a
long time now, but it seems that there haven't really been documented publicly,
and since I've discussed a couple of them during
[Agarri](https://twitter.com/Agarri_FR)'s amazing [Burp
training](https://hackademy.agarri.fr/) last week, there is no point in keeping them
*super duper secret* anymore. Most of them all likely already deployed on your
favourite *darknet market* anyway.

# Detecting Burp users

## Detecting the web interface

Burp will by default open a web interface on its proxy listening address, so
requesting `http://localhost:8080/favicon.ico` and checking that it has
`a675f036bd20cd86921fad84c29a8d04` as md5 indicates that Burp is used, with its
default settings.

You can also try to resolve `http://burp`.

## Detecting the TLS man-in-the-middle

Since someone was crazy enough to [implement TLS in pure
javascript](https://github.com/digitalbazaar/forge), trying to establish a TLS
session in the browser to your website by using [raw
sockets](https://www.chromestatus.com/features/6398297361088512) and checking
that the `Issuer` is `PortSwigger` instead of your usual provider will give the
MitM away.

One can also give at try at Clouflares [mitmengine](https://github.com/cloudflare/mitmengine) as well.

## TLS ciphers support

Java doesn't play nice with [*modern* TLS
settings](https://www.ssllabs.com/ssltest/analyze.html?d=dustri.org): if you
try to browse [dustri.org](https://dustri.org) with Burp, you'll get `Received
fatal alert: no_application_protocol`.

<!--
Odds are that you can break [Burp's
Collaborator](https://portswigger.net/burp/documentation/collaborator) https
and smtps server-side exfiltrations with this as well if you configure your
application to only use ultra-modern TLS settings.
-->

## JA3 

Salesforce is doing some interesting work around TLS fingerprinting,
like [JARM](https://github.com/salesforce/jarm) and
[JA3](https://github.com/salesforce/ja3).
Burp usually has a JA3 of `53d67b2a806147a7d1d5df74b54dd049`.

## Infinitely chunked responses

This isn't really Burp-specific, but having a `/admin` webpage sending an
[infinite amount of chunks](https://github.com/Snawoot/httptrap/) will keep
Burp busy, since it doesn't have a timeout, and tries by default to wait until
everything is received before processing it. By default, web browsers are not
waiting for the end of the request, so you can implement a redirection in
javascript, they'll follow it, while Burp won't.

## Detecting the Burp browser extension recording

Burp is shipping with its own web browser, and allows to record complex flows
in it via an extensions, that can be detected by enumerating the
`EventListener` since it's adding some for `contextmenu`, `paste`, `keydown`,
`click`, `scroll`, …

## Brotli compression

Burp Pro doesn't support [Brotli](https://en.wikipedia.org/wiki/Brotli), while
every modern browser [does](https://www.caniuse.com/brotli), so just always
serve content compressed with it even if the browser doesn't advertise to
support it.

Edit: support for brotli was [added in Burp 2023.10](https://portswigger.net/burp/releases/professional-community-2023-10).

Or, if you want to be more sneaky, check if the client is using a modern
user-agent, without advertising `br` in its `Accept-Encoding` header.


## User-agent of the embedded browser

The web browser embedded by Burp is Chromium, with the current user-agent as of
today: `User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36`,
but it doesn't spoof the `navigator.platform`, leading to a detectable
disparity if the user isn't running on Windows.

If the user is running on Windows, `SEC-CH-UA: "Chromium";v="89", ";Not A
Brand";v="99"` will give Burp away, since nobody is running Chromium instead of
Google Chrome on this platform.

## Hackvector

Add some [hackvector](https://portswigger.net/bappstore/65033cbd2c344fbabe57ac060b5dd100)
tags in your webpage, and check if they were processed.

# Breaking stuff in Burp

## Breaking the crawler

Internally, the crawler uses CSV, as in "cheese separated values", which is
like "Comma separated values", but with `🧀` instead of a `,`.

Launching the crawler on a page with the following content will result in
`2.html` being added to the sitemap, as well as something like `🧀.html`,
instead of `2.html` and `%F0%9F%A7%80.html`:

```
<a href="🧀">one</a>
<a href="2.html">
```

## Confusing Burp's active scan

This is quite lame, but you can randomly:

- delay the answer of your web server for 20 seconds to confuse the SQLI scanner.
- query every `.burpcollaborator.net` url that you see in your logs,
  via tor/proxies, with a random delay, random content and with random
	repetitions. You can also blackhole the resolution of those urls on your
	servers a the DNS level.
- reply to dirbuster-like requests (in `resources/PayloadStrings/`). Bonus if
	you're not only throwing `200`, but also real-looking content.
- add the scanner's expected result into a comment in web pages. You can find
	them by spending a bit of time reversing Burp's slightly obfuscated `.jar`
	file. For example:
	- Parts of `/etc/passwd`/`win.ini`/`boot.ini`/`WEB-INF/(meta|web).xml`/`/etc/hosts`/… for LFI
	- `5929` to template injections
	- `111111` for shell injections
	- Parts of the output of `id` for template/shell injection
	- `alert("XSS")` for, well, XSS
- ask shodan.io for all the [Burp Collaborators](https://portswigger.net/burp/documentation/collaborator) on the internet and drop them server-side.

## Breaking the decoding

I wrote about this in [2018]( https://dustri.org/b/confusing-burps-display-with-fake-encoding.html ),
and it's still unfixed.


## Breaking the Intruder

Since Burp's [Intruder](https://portswigger.net/burp/documentation/desktop/tools/intruder)
uses `§` as marker for data to replace, we can use this to detect tampering.
Even better, since it seems that there is a bug in Burp making it replace `§`
with `Â` (aka `chr(0xc2)`), we can precisely detect if the tampering is due to
Burp or not:

```php
<?php
if (isset($_POST['x'])) {                                                        
  if ($_POST['x'] !== '§') {                                                     
    if ($_POST['x'] == chr(0xc2))                                                
      echo "Burp detected";                                                         
    else                                                                         
      echo "Tampering detected";                                                         
  }                                                                              
} else {                                                                         
  echo '<form method="post" enctype="text/plain"><input name="x" value="§"></form>';
} 
```

This means that the Intruder is unable to sent the `§`, so feel free
to add this character to madatory signed blobs everywhere.
It might be possible to use the
[grep extractors](https://portswigger.net/burp/documentation/desktop/functions/response-extraction)
to extract and correctly insert `§` characters to bypass this.