In this article, we will look at the new BCheck feature in Burp Suite professional that was added in version 2023.6.2. We’ll discuss the benefits and how they can improve Burp’s vulnerability scanner. We will also cover examples of use cases and what you should consider when developing your own BCheck scripts.
BCheck allows you to write scripts that are used within Burp’s scanning engine. We will not go into detail on how to write your own script because Portswigger has already explained this well on their documentation page for BCheck.
You can write many different BCheck scripts that you can enable or disable at any time to customise your scanning process.
Burp Suite has for a long time offered the possibility to write your own extensions, which has given the tool great customisation possibilities. Writing extensions is still a good idea for solving complex tasks, but can be a bit painful if you want to have many tasks with the goal of solving many simple but different tasks.
BCheck solves this problem by making it easier to create many different tasks with a user-friendly scripting language.
It is possible to develop a BCheck script in Burp Suite while using it, making it easier and faster to perform custom scans on the go.
Another major benefit is that the community can provide scripts for others to use, making Burp Suite even more community-friendly.
Improve your vulnerability scanning
The customisation and the fact that BCheck runs within Burp’s scanning engine provide the opportunity to improve your vulnerability scanning, but the improvements are only as good as the scripts fed to it.
You should see this as an advantage as it gives you the opportunity to contribute to Burp’s vulnerability scanner with your knowledge and experience. Using these two factors to develop unique BCheck scripts will definitely improve your vulnerability scanning.
Suggestions to improve your scripts
As always, in my opinion, you should have/develop scripts that are adaptable to your goal. You should prioritise quality over quantity (most of the time) to have a relevant scanning process during testing.
A very basic example would be if you scan for SQL injections in an application and you spray payloads that are for MySQL, Oracle and PostgreSQL, but the application only uses MySQL as its database. Then ~67 percent of what your scanner is doing is performing useless requests to the application (if the same payload amount is used for each DBMS).
It’s common among new hackers to make this “mistake” and that’s fine. Just think about the types of scanning processes performed and add your own developed scripts to make your scanner more adapted.
Examples of usage
You can use BCheck for many different purposes, some examples could include:
- Detecting services running on the system
- Collecting resources from the target’s HTTP responses
- Performing automated recognition of assets
- Scanning input sections for potential vulnerabilities
- Automatically creating your own wordlists
- Discovering errors in the application
- Scanning for CVE‘s
Keep in mind that BCheck is still in beta. It will be interesting to follow its development process and how the community can help to improve Burp’s scanner by providing own scripts for others to use!
Custom written BCheck scripts
I have written some BCheck scripts to perform various tests that could potentially lead to a security issue in a web application. We present some of them below and you can find future scripts on our Github!
These are some of my scripts that I personally use but as mentioned before, you should keep things as unique as possible. I therefore include my own unique payloads when using these scripts for my own use, but these payloads are not presented in the scripts shared below. This is because if I were to share my unique payloads in these scripts, they would not remain unique anymore. I therefore recommend that you add your own unique payloads along with those provided within the scripts.
This script scans various insertion points for a template injection vulnerability using template syntax from common template engines. It also looks for some behaviours that are presented in a blind-based template injection.
Web application firewall bypass
When a new host is detected, the script is activated and performs a test on the web application firewall (WAF). The script does this by adding a customised GET parameter to the URL. Various payloads are then added to the newly created parameter that are specifically designed to bypass general firewalls.
(I have managed to bypass many strict firewalls with this script, even with the default payloads)
Restricted path bypass
To access restricted endpoints, the script uses a combination of payloads that attempt to trigger a normalisation in the URL path that hopefully bypasses the rules and provides access to the restricted endpoint.
The script also includes some techniques that usually work for reverse proxies.
Server technology discovery
Whenever a new host is detected, it looks for a technology in the response headers. If it’s not able to extract it, it tries to trigger different status codes to see if the technology is leaked on other pages based on the status code. This could for example be a default 404 page that reveals the technology used in the application.
Backend language discovery
This script uses regex rules to detect file extensions presented in the HTTP responses from the application being tested. When an extension that is likely to be used by the application’s backend is discovered, it is reported to Burp’s dashboard.
BCheck scripts are a great benefit to Burp’s scanner because you can customise the scanning process by developing your own scripts. It offers a user-friendly scripting language that can be written directly in Burp Suite and the script can be shared with the community. This allows other hackers to create and share their own scripts with each other. Finally, it allows the scanner to test more areas within our target which makes our personal goal with the scanner easier to achieve.