Try Out Fuzzing With CI Labs

CI Labs is a preconfigured Ubuntu vm that can be accessed via RDP. It has CI Fuzz preinstalled and includes a test project that allows you to try out the workflow of fuzzing with CI Fuzz without installing anything on your device.

Contact us to get access to CI Lab. We will send you an IP address and credentials you can use to log in: https://page.code-intelligence.com/ci-labs/get-access.

The only requirement is that you need to have an RDP client installed.

On Linux, you can for example use rdesktop :

rdesktop -rclipboard:PRIMARY -f 34.141.205.169 

xrdp_login_screen

Open a shell and navigate to the source code directory of the test project ~/test_code/WebGoat.

WebGoat is a deliberately insecure java web application. The workflow and techniques described here can be used to fuzz any supported web application. Currently, Spring/Spring Boot and swagger/openAPI web applications are supported.

Besides web applications, CI-Fuzz can be used to fuzz C/C++ and java applications. To learn more about our java fuzzing capabilities, you can have a look at our Java fuzzer Jazzer, which we released as open source.


Before you can fuzz the application, you need to build it. This is necessary because CI Fuzz will create randomized requests to the application and analyze its behavior.


mvn clean install -DskipTests

 

build_webgoat

Open the WebGoat folder in Visual Studio Code. It comes preinstalled with our CI Fuzz extension.

open_webgoat_folder_in_vscode

Open the plugin by clicking the Code Intelligence Logo in the left sidebar and create a fuzzing project. Select "web application fuzzing" and click "submit".

project_creation_web_application_switch

project_creation_initialization_in_progress

The initialization should only take a few seconds. After this, you can add a web service.

add_web_service_screen_1

Click "Add Web Service", set a name, select "org.owasp" from the list of packages to be instrumented.

add_web_service_select_identifier_and_instrumentation_filter

Copy the shown command line snippet and go back to the terminal.

add_web_service_copy_java_agent_snippet
Start the WebGoat jar located at webgoat-server/target/webgoat-server-*.jar like normal, but additionally pass the -javagent snippet you copied to java:

java -javaagent:$HOME/bin/fuzzing_agent_deploy.jar=instrumentation_includes="org.owasp.**",service_name=projects/webgoat-bb8aeaea/web_services/WebGoat -jar webgoat-server/target/webgoat-server-8.0.0-SNAPSHOT.jar

Copying the command above will not work, because the randomly generated project name will be different for you.

Now the java classes will be instrumented at load time and WebGoat will be started.

start_webgoat_with_agent_snippet


Wait a moment until you see the output:


INFO: Got status 'OK' from fuzzing server

 

webgoat_running_ok_from_fuzzing_server

Go back to VSCode. Under "Web Services Ready For Fuzzing" a new green entry should be shown. Click on it. Click "Analyze Web Service". Select "Spring/Spring-Boot" as backend technology. Click Analyze. Click "Analyze Web Service".
Select "Add Fuzz Test" in the side column. Select "Java Agent Fuzz Test"

add_fuzz_test_java_agent_fuzz_test_marked
Enter a name for the fuzz test and set a check mark at the web service you want to fuzz in the list of available web services. Set a checkmark at "Project Policy" and "Target Policy". This will make sure that uninteresting responses of the application, like 4xx errors, will be ignored.


add_fuzz_test_select_name_and_web_service

add_fuzz_test_set_checkmark_for_project_and_target_policy


Click save and run the fuzz test using the yellow button at the top right. While the fuzz test is running, you can watch live how it covers more and more lines of code and discovers findings.

 

fuzz_test_first_run_coverage

 

fuzz_test_first_run_findings

 

Improving the coverage

In the first run, we found a few vulnerabilities, but the fast majority of them stays hidden behind the user login. Since the fuzzer can not just bypass the authentication, the parts of the application that are protected behind a login are unreachable for now. In the following, you will learn how to change this by teaching the fuzzer how to authenticate properly.

First open the WebGoat login page in your browser by typing

localhost:8080/WebGoat/login

and register a new user.

webgoat_UI_open_new_user_marked

webgoat_UI_add_new_user

After the new user was created successfully, logout again.

webgoat_UI_logged_in_logout_marked

Now we will log in again using the newly create user and capture the login request using the Firefox developer tools. Press F12 to open it and switch to the "Network" tab. This will show you all requests and responses send while you interact with the website.

webgoat_UI_login_with_opened_network_tab

Scroll to the top. The first request send is named "login". Right-click on it and copy the request headers.

webgoat_UI_successful_login_login_request_markedwebgoat_login_request_copy_headers_marked

Now switch back to VS Code and open the file myfuzztest_initial_requests.http. It is located in the folder .code-intelligence/fuzz_targets.

The file is empty by default. Paste the login request header you just copied.

vscode_paste_request_headers_to_initial_request_file

Now the fuzzer know in which way a login works for this specific web application. The only missing details are the credentials used for login. These are not in the request header, but in the request payload.

To see the payload, click the request, open the "Requests" tab and let Firefox display the raw request.

webgoat_copy_request_payload

Add this payload to the myfuzztest_initial_requests.http. The payload is separated from the header by a single empty line.

vscode_paste_request_data_to_initial_request_file_send_button_marked

Using the preinstalled rest client plugin, you can send HTTP requests right from VS Code. To do so, just click the "Send request" button.

vscode_rest_client_login_successful

The welcome.mvc in the response indicates that the login was successful.

When we start the fuzz test again, the fuzzer will send the initial request first, which leads to the login-protected application parts being fuzzable.

In comparison with the first run without authentication (bottom), the second run achieves a much higher coverage and discovers a higher number of findings. For example, the SQL Injections were not discovered before.

fuzz_test_second_run_coverage_and_findings_comparison

fuzz_test_second_run_findings