< is >

Walkthrough

Templates

Configured containers for studied web applications are available for download. After downloading the desired compressed package, and running docker-compose up you can access the web applications on port 8085.
By default, the original versions of applications are loaded. The credentials used to login to these instances are available in CREDENTIALS.txt file in each compressed package.

To test the debloating process, you can either debloat the applications yourself (described below) or you can test the currently debloated versions. To do that, SSH into the "web" container (you can use ssh_web.sh script available in root directory of the project), navigate to /var/www/html/ and move the files from file_debloating or function_debloating directories to the parent directory. You can make sure the permissions are correct by issuing chown -R www-data:www-data * in /var/www/html/.

Administration Panel

This panel is accessible at http://localhost:8086/admin. Within this panel you can perform tasks such as:

  • Add new software and prepare it for debloating
  • View coverage of application usage profiles and covered vulnerabilities
  • Perform file and function level debloating
  • Map CVEs to files, functions and lines of web applications

Adding a new software

You can host and debloat multiple versions of different web applications at the same time. As such, "WEB APPLICATIONS" subsection will allow you to add different versions of web applications.

1. Adding a new software: First, create an entry for your target application.

2. Adding a new software version: Add an entry for the version of each software you wish to debloat.
3. Preparing web application for debloating: Under "Debloating", add the directory of your target application.

4. Preparing software for debloating: By clicking on rewrite destructors, the application will be prepared for debloating. This step make sure the debloating engine records the correct code coverage for all destructors within the application. This action needs to be done only once and will rewrite destructors to match our scheme.

5. Rewrite Destructors output

At this point your application is prepared and you can start recording code coverage by running various tests. Make sure you setup required cookies or environment variables via .htaccess file to map your requests to test categories within the database.

Dynamic Analysis

This section presents the reports on which vulnerable files, functions or lines within each application was executed during selected tests. Additionally we can debloat target web applications at the file or function level.

- Reports
You can select multiple test categories and use the buttons over the top to aggregate the coverage of tests. You can also export the report as CSV.

- Covered vulnerable files
This view lists vulnerable files for target web application and marks the ones that were executed during our tests. In this example, file level debloating can remove the vulnerable files that were not executed and as a result, remove those CVEs.

- Performing file and function level debloating

- Debloating results
After clicking on file or function debloating, you will see the list of removed files and functions.
- File debloating logs

- Function debloating logs

At this point, the target application has been debloated. This can be tested by using the application normally and then navigating to one of the files or functions that has been removed to trigger an error.

Mapping CVEs

By following the steps below, under "VULNERABILITIES" subsection, we can add new CVEs and mark vulnerable files, functions and lines in our target applications.

- Adding a new CVE

- Mapping CVE to vulnerable files

- Mapping CVE to vulnerable functions (Line number points to the first statement within the function)

- Mapping CVE to vulnerable lines

Breaking RCE exploit on Mangento 2.0.5 (CVE-2016-4010)

To demonstrate how an exploit attempt can fail after debloating, you can test CVE-2016-4010. This exploit targets an unsafe deserialization on shopping cart information in guest checkout. The gadget chain starts with Credis_Client class which is the redis client used in Magento and this module is not enabled or used by default. This is a common theme for most classes used in PHP Object Injection gadgets, they are from classes that are not used. And as this is the case for this class, both file and function level debloating will successfully remove this class and exploit attempt will fail.

Follow these steps to reproduce this scenario:
  1. Get the exploit from https://www.exploit-db.com/exploits/39838.
  2. Follow the steps and exploit the original version of Magento 2.0.5.
    In this example our exploit runs php_info() on the remote server.
  3. Copy file or function debloated version of Magento 2.0.5 to apache root (or debloat it yourself from the debloating panel) and try the exploit again.
    The class that initiates the gadget chain is removed during debloating and this makes the exploit fail.