My situation had no ill consequences, but it could have if I had used my actual email for the script or if my project was bigger and I had used AWS or another cloud provider and hardcoded those credentials.
In a later class I did learn how to safely pass credentials to my scripts without fear of leaking them on GitHub, but leaked credentials remained on my mind.
I won't get into scenarios where credentials are stored properly but stolen via a vulnerability, only where a developer or other AWS user hardcodes their credentials into a GitHub repository or a website.
Canary Tokens can be a word document, QR code, AWS API key, or many other file types to suit various needs.
It looks exactly the same as how a developer would store this information and contains everything needed to make a successful connection to the AWS API. Nothing beyond that works to prevent an attacker from actually abusing these keys.
It is likely that they were using a crawler to scan websites for credentials or vulnerabilities but could have been testing the collected credentials manually.
This information helped me to create a script that tests AWS API keys to see if they are valid.
My data is not large enough to say definitively that if you hardcode credentials into your decently trafficked e-commerce website you will have a couple days to fix them before they are used.
In this case too, a crawler may have picked up the keys much earlier, and they were not tested until days later.
The AWS API keys I posted to GitHub were tested much sooner.
Clearly, if you post your AWS credentials, they will be picked up and used by someone, whether it is a security company, researcher, or attacker.
There is no way to undo posting credentials when things like the wayback machine exist.
Luckily, there are tools like GitGuardian , GitLeaks, TruffleHog , and RepoSupervisor that can be integrated into your Continuous Integration and Continuous Deployment pipeline and scan for hardcoded credentials before the code goes into production.
I created a script that can verify if an AWS API key works; you can find it at the end of this article in my GitHub account.
My reasoning for creating my own script was that many of these tools include features that would not be useful if your goal is only to verify whether the keys work, while some tools that can do this are made for exploiting that access.
I wanted to create a simple script that anyone in IT could look at and understand so QA, junior developers, interns, and new analysts who find an AWS API key can quickly verify it without putting it into a tool they do not fully understand.
Hardcoding credentials happen more often than you might think.
There is a reason that entire companies exist to scan for these credentials.
If you are writing code, do your best not to hardcode credentials; someone will find them.
Use IAM permissions in AWS to limit each API key to only the permissions it needs.
This Cyber News was published on isc.sans.edu. Publication date: Mon, 11 Mar 2024 01:43:20 +0000