Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MongoDB] Creds not getting detected in latest version 3.78.1 & in older versions, getting verification error: context deadline exceeded #2991

Open
k-sau opened this issue Jun 19, 2024 · 7 comments
Labels

Comments

@k-sau
Copy link

k-sau commented Jun 19, 2024

TruffleHog Version

3.78.1
3.78.0

Trace Output

https://gist.github.com/k-sau/e44f532bd423776ff0c964fe150d2ec1

Expected Behavior

MongoDB creds should be detected

Actual Behavior

In 3.78.1 in mac sillicon chips based machine, it wasn't detecting at all but it is working fine in ubuntu.
In 3.78.0, it's detecting the credentials but failing to validate the credential which are on different region other than yours.

Steps to Reproduce

  1. Create dummy MongoDb credential of region which have ideally high latency from your region.
  2. Run the trufflehog scan on it from v3.78.1 & v3.78.0 on apple silicon chips machine.
  3. In v3.78.1, trufflehog will not even detect the mongodb pattern.
  4. And in v3.78.0, you will get: Verification issue: context deadline exceeded.

Environment

  • OS: Sonama
  • Version 14.5
@k-sau k-sau added the bug label Jun 19, 2024
@yilmi
Copy link
Contributor

yilmi commented Sep 29, 2024

@ahrav @dustin-decker - We also have the same issue, this is generating false negatives.

I tested the same set of valid credentials (10 credentials) and scanned them 5 times with the latest version of trufflehog (3.82.6). Each time a different set of credentials came back as verified, depending on which ones encountered the error: Verification issue: context deadline exceeded

MongoDB verification doesn't seem to have an explicit "context deadline" (unless I missed it) as the postgres verifier has, which leads me to think that this may affect other detectors.

This is a problem because this can lead folks to believe that a secret has been successfully rotated while this is not the case.

@rgmz
Copy link
Contributor

rgmz commented Sep 29, 2024

MongoDB verification doesn't seem to have an explicit "context deadline" (unless I missed it)

It inherits the timeout from the context, although this wasn't enforced until #3320. FWIW I often find the timeouts too short and manually increase them.

ctx, cancel := context.WithTimeout(ctx, detectionTimeout)
t := time.AfterFunc(detectionTimeout+1*time.Second, func() {
ctx.Logger().Error(nil, "a detector ignored the context timeout")
})
results, err := data.detector.Detector.FromData(ctx, data.chunk.Verify, matchBytes)

@ahrav
Copy link
Collaborator

ahrav commented Oct 1, 2024

I initially thought 10 seconds was enough for verification, but this logic likely fails with multiple credentials in a chunk. It would be better to give each detector a configurable context timeout. While it's more complex than using a single timeout across the detector fleet, I prefer moving towards more independent and configurable detectors.

@yilmi, after modifying the detectionTimeout as @rgmz suggested, are you still seeing the context timeout?

@zricethezav, what are your thoughts? @abasit-folio3 @kashifkhan0771, I’d also like your input.

@rgmz
Copy link
Contributor

rgmz commented Oct 1, 2024

initially thought 10 seconds was enough for verification, but this logic likely fails with multiple credentials in a chunk.

A single url can easily exhaust 10s. I think 10s per attempt with a much more generous timeout per chunk/detector would reduce the number of false negatives.

@yilmi
Copy link
Contributor

yilmi commented Oct 7, 2024

@rgmz / @ahrav - Is the only way to configure this timeout to compile the project myself or can I somwhow override this value?

@ahrav
Copy link
Collaborator

ahrav commented Oct 7, 2024

@rgmz / @ahrav - Is the only way to configure this timeout to compile the project myself or can I somwhow override this value?

I would like to be able to provide an override. @zricethezav @abasit-folio3 @kashifkhan0771 Could we get your opinions here.

@kashifkhan0771
Copy link
Contributor

I agree with this approach @ahrav

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants