Bchecks are custom scan checks that can be implemented in both Burp Suite Professional and Burp Suite Enterprise.
Bchecks allow you to check for specific issues with relatively low overhead. This article will cover what Bchecks are, some popular bchecks and repositories, as well as how to start creating your own. As a heads up, I am learning about Bchecks by doing this article. Some of the information here could be somewhat incorrect. I promise to go back and revise as I discover flaws in my logic or explanations.
When to use a Bcheck?
Bchecks are great for automating the process of finding known issues. Bchecks are small snippets of code that hook into Burpsuite and perform these checks in the background while you are navigating through an application. They are great for picking up on small details that you might otherwise miss or overlook. Later in this article we'll see an example of what a Bcheck might look like that is responsible for catching AWS Keys in code. The beauty of Bchecks is that as a penetration tester or bug bounty hunter it is possible to create custom bchecks in order to catch small details that you are looking for specifically. They are a great way to improve the coverage of your Burp scanning.
Bcheck Breakdown - The Building Blocks of Bchecks
To get started take a look at https://portswigger.net/burp/documentation/scanner/bchecks/bcheck-definition-reference which goes over the various components of bchecks and their purposes.
Ok so the first component we need is simply some metadata about the bcheck itself. What is this for? Well when you later go to import the bcheck into Burp Suite this information will be used to describe the purpose of this bcheck, the author (You!), and tags that indicate it's use case (for example, sqli, xss, directory bruteforcing, etc.)
The metadata for a bcheck will look like this:
metadata: language: v2-beta # bcheck language definition name: "Wordpress Indicators" # The name of the bcheck description: "Tests for common WordPress directories" # description of bcheck author: "Your Name" # obvious tags: "wordpress" # tags associated with the kind of bcheck
As described in the code above, this information is necessary for providing context about what the bcheck will do and perform when it is being used.
Bcheck Control Flow Keywords
There are a couple of important Bcheck Control Flow Keywords to be aware of to make the most used of your bchecks. Control flow keywords manage the logic of your Bcheck. Some bchecks are very simple (Ex: See if "is_admin" exists in the response body. If so then report the issue). Others are far more complication (Ex: If the response body contains a specific keyword, send another request to a different endpoint, and send to another endpoint after that). Understanding Bcheck control flow keywords will help give you the tools needed to make advanced bchecks.
Some control flow keywords to know:
1. "run for each"
- This keyword defines an **array variable** that can be iterated over.
- When the variable is called the check runs once for each item in the array
If we wanted some example code it could look like this:
run for each:
wp_dir = "{base.response.url}/wp-content/admin", "{base.response.url}wp-content/edit"
This could be used to iteratively request pages tied to wordpress. This kind of check would be great to brute force any page used by the site to try to find the default wordpress login page.
2. "define"
- define allows us to set a variable with "inner scope" meaning that the variable is only accessible within that inner scope of a function call (at least that is how I understand it at the moment)
3. "given...then"
- this one is essential as all bchecks most have this conditional included. It's akin to if->then statements in normal programming languages and is used to trigger a response depending on certain conditions.
Ex: The below is a reference to a bcheck here: https://github.com/PortSwigger/BChecks/blob/main/examples/leaked-aws-token.bcheck that looks for a leaked AWS token in the response header.
As seen below, if the latest response includes any pattern that matches the regular expression listed below, Burpsuite will record a finding that there is a leaked AWS Access Key ID.
given response then
if {latest.response} matches "AKIA[0-9A-Z]{16}" then
report issue:
severity: high
confidence: firm
detail: "Leaked AWS Access Key ID."
remediation: "Replace your keys and ensure keys are no longer revealed."
end if
Bcheck Reserved Variables
Just like in some programming languages there are words and phrases built into the coding language that should not be re-used as they are leveraged for a specific purpose within the language you are using. For Bchecks, some **reserved variables** include
- request (The outgoing request)
- response (The response from the application)
Ex: The bcheck below defines a variable called "potential path" that defines two common git configuration directories. Given the host (domain) of the site you are on, send a GET request to each potential path. If the response body contains the string "[core]" then report the issue to the Burp suite dashboard.
Note: "given host" means that when you begin scanning your application, Burpsuite will scan each new host once using the associated bcheck
This is a simple way to have your application search for hidden directories without even thinking about it!
metadata:
language: v1-beta
name: "Host-level"
description: "Tests for exposed git directory"
author: "Carlos Montoya"
run for each:
# you could add more values to this list to make the check repeat
potential_path = "/.git/config", "/.git/config~"
given host then
send request called check:
method: "GET"
path: {potential_path}
if "[core]" in {check.response.body} then
report issue:
severity: info
confidence: certain
detail: `Git directory found at {potential_path}.`
remediation: "Ensure your git directories are not exposed."
end if
There are a few other reserved variables in Burpsuite. I'd recommend reviewing https://portswigger.net/burp/documentation/scanner/bchecks/bcheck-definition-reference#metadata to learn more about these and build some of your own to understand how they work.
Reporting Issues with Bchecks
Of course one of the benefits of using bchecks is the fact that Burpsuite will automatically flag issues caught by bchecks to the Burpsuite dashboard.
To do this we use the "report issue" phrase to provide a description of the issue:
if "[core]" in {check.response.body} then
report issue:
severity: info
confidence: certain
detail: `Git directory found at {potential_path}.`
remediation: "Ensure your git directories are not exposed."
The example above looks in the response body for the "[core]" keyword and then reports this to the Burpsuite dashboard for you to review.
Again, the great thing about bchecks are that they let you free up your brain to focus on more novel problems rather than needing to perform each of these checks manually.
Closing thoughts
While this was a very short article on bchecks I intend to cover them in more depth later and will also provide some recommendations (once I have a chance to play around with them a bit more.)
As you move on with your security career, I want you to think about what it is you think YOU could use bchecks for? Do you have an app you test a lot and want to make sure issues stay remediated? A bcheck could help with that. Do you notice common patterns in web applications that sometimes indicate a vulnerability? A bcheck could help.
Think of all of the creative ways you could use something like this and try them out.