Extending fuzzing with Burp by FAST

I love Burp Suite, like really. It’s the most convenient tool to visualize what’s happening with apps, what requests look like and to test simple things like XSS injection.

At the same time, it’s really hard for me to do something more complicated, like implementing custom fuzzing with having to put all the markers into the Intruder. It’s unbelievably hard to make my own detects and run them in my own way. At the same time, fuzzing is a super important application testing technique. Recently I mentioned avoiding fuzzing as #5 in my Top 5 security audit fails https://medium.com/@d0znpp/top-5-my-own-security-audit-fails-d17320bbb980

Although on the surface, fuzzing may feel like it would take a lot of time, it’s in fact much easier for web applications than for binaries. The difference there is in the nature of vulnerabilities. Unlike binaries, web applications are using plaintext protocols to communicate with sources like DB, Filesystems, OS, other apps, etc. It means, that usually, you need to injection on 1–2 termination characters like escapes in a payload to achieve unexpected application behavior in the case of vulnerability there. You don’t need to carry about control sums, length validations and other complicated things related to binary protocols.

So, let’s take a look at how to do this fuzzing job much easier using FAST (it’s free to try).

1. Sign up here (it’s free) https://fast.wallarm.com/signup and login to create a testing policy https://my.wallarm.com/testing/policies/new#general
2. Define the policy name and description to reuse it later. Define where you need to put your payloads at “Insertion point” tab. I prefer to use smth like this “GET|POST|HEADER_X”, means fuzzing to all the GET/POST parameters and all the custom (X-*) request headers. Then uncheck all the checkboxes at “Attacks to test” to avoid OWASP Top-10 things covered by Burp itself (we are fuzzing now, isn’t it?)
3. Define how to fuzz at ‘Fuzz testing’ tab by setting payloads. My favorite way is to add 1 byte to the end of initial strings, like this:

If you don’t know the application which you are fuzzing, it’s better to not define additional fields there to identify all the anomalies.

4. Create the Test Run related to Test Policy you made here https://my.wallarm.com/testing (click “create test run” button on the right). Define test run name, select your testing policy, select “+Create new node”, set the checkbox “Run test on node” means, you will run all the tests from your machine, otherwise, Wallarm Cloud will be used. Set RPS limits for the entire test (RPS per test run, like 100) and one thread (RPS baseline, like 20, means 5 parallel threads). Click “Create and run”.

5. The test run token will be copied to buffer automatically. Now it’s time run FAST proxy+scanner docker by running a one-line command like this:

$ docker run -it -e WALLARM_API_TOKEN=<copied-token> -p8888:8080 wallarm/fast

Wait for the message like this:

Nov 11, 20:54:11 +0000 [info] Running a test set for the baseline #72820

6. Connect FAST to Burp as an upstream proxy here:

7. Run traffic through Burp and understand the magic there. Each request sent to the destination host you defined will be used as a baseline to generate fuzzing test based on it. In particular, it means, that your FAST docker will send requests with additional 1 byte you defined applied to each value of each GET/POST/HEADER_X parameter. Even in the case of sophisticated encodings like POST->JSON->params->BASE64->JSON->password, these payloads will be encoded in the right way at each nested encoding level.

8. Understand the results. Click at “Results” tab at https://my.wallarm.com/testing on a row, related to your test run.

Click on the rows related to anomalies detect to understand what happened there:

Wallarm FAST is able to identify anomalies by response status code, response length, response time, connection errors and response DOM structure. We are working on other metrics to extend it. You can also define your own criteria for how to identify anomalies by regexp on the response data, custom status codes, timing, etc at testing policy definition stage.

So, that’s all for now. Please feel free to share any feedback on FAST, I’ll be more than happy to listen to all the experts to improve it!

In my next article, I’ll show you how it’s easy to make your own detects based on FAST codeless DSL. Spoiler — this is a 10-lines XSS OOB detect:

generate:
        payload: 
          - "'\"><img src=//DNS_MARKER/><"
        method: 
          - postfix
detect:
        - OOB_DNS
meta-info:
        threat: 60
        type: xss

Thanks!