Detecting AWS Canaries without Detonating them
Today we’re unveiling a novel way to identify canarytokens.org canaries completely statically without setting them off. Thinkst offers self hosted, and paid alternatives that are protected from these techniques. We’re open sourcing this capability and including it in TruffleHog
What enabled this research was Tal Be’ery’s blog in October which cracked the case on decoding account IDs from access IDs, and our subsequent integration of his work into TruffleHog.
This allowed us to enumerate the account IDs used by canarytokens.org, and ultimately discover which keys belong to Thinkst AWS accounts completely statically.
Overview
Canary tokens are fake credentials you place in vulnerable locations, meant to bait a hacker into using them. Once used, they set off an alert, and let you know that the vulnerable location has been compromised.
If an attacker has a way to know ahead of time that the fake credential is a canary without setting it off, this allows the hacker to avoid the trap.
One consequence of TruffleHog secret verification is it sets these canaries off, even when defenders just want to clean all the credentials out of their environment.
This new TruffleHog feature gives attackers a new tool to avoid canary traps, and allows defenders to scan for credentials without setting off unnecessary alerts.
Methodology and Enumeration
Prior to this research, Canary tokens were relatively easy to spot, because their ARN’s say “canarytokens.com”.
To retrieve that information, you can make a stateless and harmless getCallerID API call, but this does set off the canary (and shows up in cloudtrail logs).
Using that method to identify Canaries, we scanned large swaths of public GitHub repositories looking for Canaries; every time we found one, we added the account ID to a list. We sampled approximately 500 canaries and identified about a half dozen unique AWS accounts. The data we scanned was relatively recent, and better coverage for all of Thinkst amazon accounts is possible with a deeper look into older keys.
Amazon has a limit to how many keys you can generate per account, so it’s likely Thinkst constantly generates new accounts when they hit that limit. In this regard, our research allows us to identify recently generated canaries, but further analysis would be required to identify older ones.
Note, one could stay on top of all the newest accounts created by simply generating new canary tokens every day and checking for new accounts to pop up.
Detection
Now that we have a list of amazon account ID’s, all we need to do is decode hardcoded AWS ID’s and see if the account ID matches our list. Here's some python pseudo-code to understand how this works:
Canary token identification is now natively included in TruffleHog (link to PR) and we will make a best effort to keep the account ID’s up-to-date. Importantly, we are not making an effort to include account ID’s associated with Thinkst’s paid offerings, which you can learn more about: https://canary.tools
Try it out by running the following command on a canary:
Conclusion
Canary tokens remain a powerful and important security tool for detecting hackers. Not just AWS canaries, but also URL, SQL Server, Docx,SSH and all the other canary types Thinkst supports are important tools in the defender toolkit. This new TruffleHog feature does make the AWS canaries less effective, if the attacker is sophisticated enough to search for them with TruffleHog.
Because this methodology is straightforward we are confident that attackers would have independently discovered this methodology, and we believe transparency and openness for both sides, is the best most effective long term strategy to the collective industry moving the needle forward on security.