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

Private Key detector misses secrets because it does not correctly align with PEM file format protocol specification(s) #2507

Open
0x736E opened this issue Feb 25, 2024 · 0 comments
Labels

Comments

@0x736E
Copy link

0x736E commented Feb 25, 2024

Please review the Community Note before submitting

TruffleHog Version

v3.0.0 and above

Trace Output

N/A

Expected Behavior

The 'Private Key' detector should detect all types of PEM formatted private key.

Actual Behavior

The 'Private Key' detector does not detect all types of PEM formatted private key:

  • Keys with headers or other meta-data
  • Keys which are formatted differently:
  • Keys which have headers not captured by current pattern:
    • PGP PRIVATE KEY BLOCK
    • YUBIKEY PIV PRIVATE KEY
    • SSH2 ENCRYPTED PRIVATE KEY
    • OpenVPN Static key V1
    • OpenVPN tls-crypt-v2 client key
    • ...
  • The current regex pattern allows for any printable character between the header and footer (or none at all)
    • This may cause lower performance as the engine tries to validate data which is captured between a header and footer as a private key which it should not because it is not valid base64 data

Steps to Reproduce

  1. Create a private key such as one of those mentioned above
  2. Scan the key with TruffleHog
  3. It will not produce findings for those keys

Environment

  • OS: All
  • Version: All versions

Additional Context

The 'Private Key' detector is designed to identify instances of private keys such as RSA Private Key. It does this by looking for patterns which match the PEM file format.

This format is specified in a number of industry standards:

Not all aspects of PEM formatted files are codified in such standards, for example:

  • Formatting of the Base64 data within a PEM formatted file is not strictly defined. Common practice is to format the data such that there are 64 characters per line, with a new line terminator. However this is not universal, and is not a strict requirement of the specification. In some cases, this may be 76 or 80 characters per line. It is possible this trend of breaking after 64 characters is actually borrowed from the way the RFC's are formatted in order to fit within an 80 character column and was never actually intended to be a standard, hence why it was not codified.
    • The only actual standard in this regard I have been able to find is on page 42 of RFC 821 - Simple Mail Transfer Protocol (SMTP). PEM formats originate in encrypted email exchange, and this RFC defines the maximum number of characters per line in an email message as 1,000 characters. So strictly speaking, no PEM key should be longer than 1,000 characters without a line-break. But as outlined above, this is not a strictly defined control and is not enforced.

References

@0x736E 0x736E added the bug label Feb 25, 2024
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

1 participant