5 ms·

Production AWS keys on GitHub

35 points by jxf 13y ago

spydertennis 13y ago
I got hacked a month ago because of this mistake. Someone initiated 15 heavy duty aws instances on my account. Luckily aws support noticed the huge increase in billing and called me to confirm. Now my github is private haha.
- testaccount4 13y ago
  > Now my github is private That is not the solution. You're supposed to isolate secrets from the code repository.
- deleted 13y ago
  [deleted]
sahat 13y ago
I was charged over $1696.00 in AWS Usage fees for putting my production AWS keys on GitHub. So think twice before you put any production keys out there, for the whole world to see. UPDATE: As spydertennis mentioned, I also had 15 Double XL EC2 instances running in multiple regions.
- MasterScrat 13y ago
  Do you have any idea what they were doing? mining coins?!
oakwhiz 13y ago
I recommend putting your app's API keys into environment variables instead of configuration files for this reason.
- rrosen326 13y ago
  Could you go through this process? I just did something where I used a file that was outside my repo but I knew there must be a best practice that I just didn't know about. What is it?
  - spiralganglion 13y ago
    The implementation varies depending on your framework and personal preferences. For development, I usually use a file named .env in the same directory as my project, and then do whatever I can to guarantee that this file won't be added to my repo (or other public places). I use .gitignore_global to exclude .env files, for instance. For production, if you're running your app on a service like Heroku, they have commands you can execute to securely set environment variables on their server (since they discourage accessing the filesystem to load the .env file). For Rails, take a look at the dotenv-rails gem. It's pretty convenient. https://github.com/bkeepers/dotenv https://github.com/bkeepers/dotenv Here is the Heroku article on the topic (might not apply directly to your situation, but the principal is key): https://devcenter.heroku.com/articles/config-vars https://devcenter.heroku.com/articles/config-vars
    - a_bonobo 13y ago
      Rails 4.1 includes something similar to dotenv: https://github.com/rails/rails/blob/master/guides/source/4_1_release_notes.md https://github.com/rails/rails/blob/master/guides/source/4_1... A secrets.yml which is globally accessible via Rails.application.secrets, and should be in the default .gitignore from Github for Rails projects
Lockyy 13y ago
I did a quick check and found a few people with their Rails App's secret token on display in config/initialisers/secret_token.rb. I guess most people reading this will already be aware but it's in the same vein as the AWS keys problem linked. Make sure this stuff hasn't been left in your public repos.
catwf 13y ago
I did this once in a gist by mistake - meant to remove them before submitting it. Luckily someone spotted it and let me know so I could kill the access key.
needcaffeine 13y ago
If you use EC2, you can use IAM roles and your server can fetch temporary credentials from AWS. There's no need for your application to even know your AWS credentials. Read more: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles...
MasterScrat 13y ago
What exactly happens when someone takes advantage of these keys? Is it considered as "hacking", ie is the offender's Amazon account terminated? or is it "fair" in the sense that those credentials were willingly made public?
MasterScrat 13y ago
It would be interesting to have an application that Googles regularly this kind of sensitive information and tells you if it showed up somewhere public. Of course it would need a full list of your sensitive keys and password, which it practice would be quite dangerous...
mrThe 13y ago
https://github.com/search?p=1&q=Stripe.api_key+%22sk_live%22&ref=searchresults&type=Code https://github.com/search?p=1&q=Stripe.api_key+%22sk_live%22... #facepalm

35 points by jxf 13y ago

I got hacked a month ago because of this mistake. Someone initiated 15 heavy duty aws instances on my account. Luckily aws support noticed the huge increase in billing and called me to confirm. Now my github is private haha.

testaccount4 13y ago
> Now my github is private That is not the solution. You're supposed to isolate secrets from the code repository.
deleted 13y ago
[deleted]

sahat 13y ago

I was charged over $1696.00 in AWS Usage fees for putting my production AWS keys on GitHub. So think twice before you put any production keys out there, for the whole world to see. UPDATE: As spydertennis mentioned, I also had 15 Double XL EC2 instances running in multiple regions.

MasterScrat 13y ago
Do you have any idea what they were doing? mining coins?!

oakwhiz 13y ago

I recommend putting your app's API keys into environment variables instead of configuration files for this reason.

rrosen326 13y ago
Could you go through this process? I just did something where I used a file that was outside my repo but I knew there must be a best practice that I just didn't know about. What is it?
- spiralganglion 13y ago
  The implementation varies depending on your framework and personal preferences. For development, I usually use a file named .env in the same directory as my project, and then do whatever I can to guarantee that this file won't be added to my repo (or other public places). I use .gitignore_global to exclude .env files, for instance. For production, if you're running your app on a service like Heroku, they have commands you can execute to securely set environment variables on their server (since they discourage accessing the filesystem to load the .env file). For Rails, take a look at the dotenv-rails gem. It's pretty convenient. https://github.com/bkeepers/dotenv https://github.com/bkeepers/dotenv Here is the Heroku article on the topic (might not apply directly to your situation, but the principal is key): https://devcenter.heroku.com/articles/config-vars https://devcenter.heroku.com/articles/config-vars
  - a_bonobo 13y ago
    Rails 4.1 includes something similar to dotenv: https://github.com/rails/rails/blob/master/guides/source/4_1_release_notes.md https://github.com/rails/rails/blob/master/guides/source/4_1... A secrets.yml which is globally accessible via Rails.application.secrets, and should be in the default .gitignore from Github for Rails projects

Lockyy 13y ago

I did a quick check and found a few people with their Rails App's secret token on display in config/initialisers/secret_token.rb. I guess most people reading this will already be aware but it's in the same vein as the AWS keys problem linked. Make sure this stuff hasn't been left in your public repos.

catwf 13y ago

I did this once in a gist by mistake - meant to remove them before submitting it. Luckily someone spotted it and let me know so I could kill the access key.

needcaffeine 13y ago

If you use EC2, you can use IAM roles and your server can fetch temporary credentials from AWS. There's no need for your application to even know your AWS credentials. Read more: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles...

MasterScrat 13y ago

What exactly happens when someone takes advantage of these keys? Is it considered as "hacking", ie is the offender's Amazon account terminated? or is it "fair" in the sense that those credentials were willingly made public?

MasterScrat 13y ago

It would be interesting to have an application that Googles regularly this kind of sensitive information and tells you if it showed up somewhere public. Of course it would need a full list of your sensitive keys and password, which it practice would be quite dangerous...

mrThe 13y ago

https://github.com/search?p=1&q=Stripe.api_key+%22sk_live%22&ref=searchresults&type=Code https://github.com/search?p=1&q=Stripe.api_key+%22sk_live%22... #facepalm