4 ms·

Early Warning Detectors Using AWS Access Keys as Honeytokens

160 points by StabbyCutyou 10y ago

cddotdotslash 10y ago
This should also be called "how to get your account locked by AWS in 15 minutes or less." AWS is not fond of finding AWS keys laying around (limited permissions or otherwise). I once committed a key to a GitHub repo and AWS called me within 15 minutes. I've seen cases where they will then lock your account (preventing it from creating new EC2 resources) until the key is deleted. Seriously, don't do this. EDIT: as others have mentioned, private repos would be fine (and a good idea).
- jakobdabo 10y ago
  Recently Github crippled (unfortunately) the Search function so that you can't search something in all the repositories at once (if you try it says that you "Must include at least one user, organization, or repository"). I used to use it to find out how other people use different library functions in the wild and it helped me to find good code examples many times in the past (especially when there were no documentation on the API). I wonder if there is any other code searching service with comparable coverage and quality.
  - wahnfrieden 10y ago
    Works for me: https://github.com/search?q=test&type=Code&utf8=%E2%9C%93 https://github.com/search?q=test&type=Code&utf8=%E2%9C%93 Is this not what you're talking about?
    - jakobdabo 10y ago
      Hmm, your link shows me the same "Must include at least one user, organization, or repository" message that I've mentioned. Maybe they removed the feature only for not logged in users. Can't check it right now as I don't have my Github password on my phone.
      - natdempk 10y ago
        This is the case. I checked this via incognito mode.
- theamk 10y ago
  The whole point is that AWS (nor any other outside party) would not find the keys. The article explicitly mentions: On servers in a text file in ~/.aws/credentials (where a lot of tooling saves AWS credentials) On your developer laptop in the same locations In application or systemd environment variable configuration files In files named ’credentials’ or in application configuration files in private, sensitive Github repos Unless amazon somehow has access to private github repos, they should not see the keys
- tobz 10y ago
  Yeah, putting the keys on Github seems pointless and contrived: there's no remediation to putting a known-bad key out in the open. What are you going to do: block their IP? Oh boy. I see value in the other examples, though, because they are dead simple tripwires, and, unless AWS is scanning your instances, they should never see this and it shouldn't be a problem.
  - jenandre 10y ago
    The idea is to use private repos on Github, not public ones, which just tell you that yes, someone can read a public repo and misuse a key. Not that your private repos have potentialyl been compromised.
- bjoernw 10y ago
  I think you misunderstood the post. What are you testing when you post your aws honey token to a public repo? This is meant for intrusion detection.
- osi 10y ago
  I don't think you read the article. They only mention putting them in private places, as a honeypot to alert about an intrusion.
c4urself 10y ago
Great idea, we had part of a private repo accidentally made public at some point and these kind of honeypot keys would've been triggered pretty quickly and let us know. Would definitely be a cool way to know if something has been leaked.
merb 10y ago
> On servers in a text file in ~/.aws/credentials (where a lot of tooling saves AWS credentials) well that sounds clever.
- alexsmolen 10y ago
  Yeah, I think it’s tricky to figure out how to place it somewhere that attackers would look but AWS tooling wouldn’t, by default, since otherwise they may be used in legitimate operation.
  - philsnow 10y ago
    non-[default] profile seems like it would work. I don't think aws-sdk/boto/etc will use non-default creds if you don't explicitly tell it to.
ratsz 10y ago
Using this method, you could have revoked AWS keys notify you if someone who recently quit your team or was fired is attempting to access your systems.
cyberferret 10y ago
Nice write up and 'how to' guide. I am going to implement this in our organisation. All private repos here, but we once had some inadvertently commit a development '.env' file with credentials in it to our remote Git repo (they did it before we added '.env*' to our .gitignore file). We might start peppering our .env files with honeypot keys just to track if they have somehow been compromised outside the company.
goblin89 10y ago
This is great for a simple setup. Obviously there’s no reason not to extend this beyond AWS— * Login credentials: feed in response to detected phishing emails * SSH keys: have SSH trigger an alert if certain keys log in * Database entries: filter out the special ones in legitimate queries The pain, at least for a small organization, is in managing: reacting appropriately to alerts, ensuring honeytokens are properly rotated.
jxramos 10y ago
Nice application of disinformation! Keep up the good work.
sparky_ 10y ago
This is one of those rare ideas that is so stupidly simple, that it comes back around to being brilliant. Setting this up myself tomorrow.

160 points by StabbyCutyou 10y ago

This should also be called "how to get your account locked by AWS in 15 minutes or less." AWS is not fond of finding AWS keys laying around (limited permissions or otherwise). I once committed a key to a GitHub repo and AWS called me within 15 minutes. I've seen cases where they will then lock your account (preventing it from creating new EC2 resources) until the key is deleted. Seriously, don't do this. EDIT: as others have mentioned, private repos would be fine (and a good idea).

jakobdabo 10y ago
Recently Github crippled (unfortunately) the Search function so that you can't search something in all the repositories at once (if you try it says that you "Must include at least one user, organization, or repository"). I used to use it to find out how other people use different library functions in the wild and it helped me to find good code examples many times in the past (especially when there were no documentation on the API). I wonder if there is any other code searching service with comparable coverage and quality.
- wahnfrieden 10y ago
  Works for me: https://github.com/search?q=test&type=Code&utf8=%E2%9C%93 https://github.com/search?q=test&type=Code&utf8=%E2%9C%93 Is this not what you're talking about?
  - jakobdabo 10y ago
    Hmm, your link shows me the same "Must include at least one user, organization, or repository" message that I've mentioned. Maybe they removed the feature only for not logged in users. Can't check it right now as I don't have my Github password on my phone.
    - natdempk 10y ago
      This is the case. I checked this via incognito mode.
theamk 10y ago
The whole point is that AWS (nor any other outside party) would not find the keys. The article explicitly mentions: On servers in a text file in ~/.aws/credentials (where a lot of tooling saves AWS credentials) On your developer laptop in the same locations In application or systemd environment variable configuration files In files named ’credentials’ or in application configuration files in private, sensitive Github repos Unless amazon somehow has access to private github repos, they should not see the keys
tobz 10y ago
Yeah, putting the keys on Github seems pointless and contrived: there's no remediation to putting a known-bad key out in the open. What are you going to do: block their IP? Oh boy. I see value in the other examples, though, because they are dead simple tripwires, and, unless AWS is scanning your instances, they should never see this and it shouldn't be a problem.
- jenandre 10y ago
  The idea is to use private repos on Github, not public ones, which just tell you that yes, someone can read a public repo and misuse a key. Not that your private repos have potentialyl been compromised.
bjoernw 10y ago
I think you misunderstood the post. What are you testing when you post your aws honey token to a public repo? This is meant for intrusion detection.
osi 10y ago
I don't think you read the article. They only mention putting them in private places, as a honeypot to alert about an intrusion.

c4urself 10y ago

Great idea, we had part of a private repo accidentally made public at some point and these kind of honeypot keys would've been triggered pretty quickly and let us know. Would definitely be a cool way to know if something has been leaked.

merb 10y ago

> On servers in a text file in ~/.aws/credentials (where a lot of tooling saves AWS credentials) well that sounds clever.

alexsmolen 10y ago
Yeah, I think it’s tricky to figure out how to place it somewhere that attackers would look but AWS tooling wouldn’t, by default, since otherwise they may be used in legitimate operation.
- philsnow 10y ago
  non-[default] profile seems like it would work. I don't think aws-sdk/boto/etc will use non-default creds if you don't explicitly tell it to.

ratsz 10y ago

Using this method, you could have revoked AWS keys notify you if someone who recently quit your team or was fired is attempting to access your systems.

cyberferret 10y ago

Nice write up and 'how to' guide. I am going to implement this in our organisation. All private repos here, but we once had some inadvertently commit a development '.env' file with credentials in it to our remote Git repo (they did it before we added '.env*' to our .gitignore file). We might start peppering our .env files with honeypot keys just to track if they have somehow been compromised outside the company.

goblin89 10y ago

This is great for a simple setup. Obviously there’s no reason not to extend this beyond AWS— * Login credentials: feed in response to detected phishing emails * SSH keys: have SSH trigger an alert if certain keys log in * Database entries: filter out the special ones in legitimate queries The pain, at least for a small organization, is in managing: reacting appropriately to alerts, ensuring honeytokens are properly rotated.

jxramos 10y ago

Nice application of disinformation! Keep up the good work.

sparky_ 10y ago

This is one of those rare ideas that is so stupidly simple, that it comes back around to being brilliant. Setting this up myself tomorrow.