Hunting Secrets

Applications are hemorrhaging sensitive data. In many cases, the culprit is marketing and analytics libraries that indiscriminately collect user behavior data. And sometimes, sensitive data gets leaked because of poor design or programming errors.

A few years ago, I wrote an extension called Paramalyzer for one of my favorite web pentesting tools: Burp Suite. More recently, I have added a piece of functionality I call Secrets Hunter, which was built to help search for cases where applications expose sensitive data in URLs and out-of-scope services (such as analytics services). This is included in version 2.2.1 of Paramalyzer.

What's a secret?

In Paramalyzer, a secret can be any sensitive information, such as usernames, passwords, tokens, or session cookies. It may also include Personally-Identifying Information (PII), such as names, addresses, and phone numbers, or even industry-specific information such as Protected Health Information (PHI) or Nonpublic Personal Information (NPI). The application should keep its secrets between itself and the user (including the user's browser). Yes, there are circumstances where an application may share secrets with other systems, such as when interacting with specific API endpoints. However, those systems should be considered part of the scope of the application.

So how does Paramalyzer find secrets?

I made the following video as a sort of TL/DR for those who are already familiar with Burp Suite and just want a quick 1-minute run-through:

-Video now unavailable.

The basic workflow for using Secrets Hunter is quite simple:

1. Define the target scope of your application in Burp Suite.
2. Create a baseline of data for Paramalyzer by stepping through all of the application's functionality. It is best to avoid submitting invalid data such as attack payloads while creating a baseline.
3. Run Paramalyzers Analyze function on its main tab.
4. Review the resulting table and curate the list of parameters that qualify as secrets.
5. Import those secrets into the Secret tab.
6. Press the "Hunt Secrets!" button.

When you start searching for secrets, Paramalyzer will automatically perform the following actions:

1. Create a list of search values based on the parameters defined as secrets. Currently, there is a cap of 20 unique values per secret.
2. Add MD5, SHA1, and SHA256 hashes as values for any secrets that have the Hunt Hashed checkbox selected.
3. Dedupe the list.
4. Search all proxy history for matches against any of the values on the list.

This will identify two types of issues, as follows:

• Are any secret values showing up in URLs?
• Are any secret values showing up in requests that are not defined to be within the target scope of the application?

The results window can help you quickly examine and verify each instance.

That's all there is to it! Please visit the official documentation page if you are interested in a more detailed walkthrough of Paramalyzer's capabilities.

Where to get it

As of this blog post, Portswigger has not yet updated the BApp Store version of Paramalyzer to v2.2.1, but you can download the jar file from the releases tab of the Paramalyzer GitHub repo. Just make sure you first uninstall any previous versions to avoid confusion.

We will update this when it gets into the BApp store, don’t worry!

Reporting Issues and Feature Requests

Paramalyzer is a bit of a complicated mess to develop, especially if you are unfamiliar with Java and Gradle, so I have no expectation of receiving pull requests (though they are very welcome). If you have ideas or issues with the extension, please submit them as an issue in the GitHub repository.