ACM.68 Do you know where all your credentials and secrets are being output in logs, debug information, or in the AWS console?
This is a continuation of my series on Automating Cybersecurity Metrics.
I must digress for a moment from the networking topics I’ve been writing about because I’m getting a lot of bugs trying to execute CloudFormation scripts. Those bugs led me to a post on debugging. The post on debugging (up next) led to this warning on sending and share debug output and logs generated by AWS tools, or any other tools for that matter.
One of the things you can do is add debug to the end of CLI commands to get debug output as we’ll see in the next post.
You can do the same with Boto3 (the AWS Python SDK I wrote about here):
What does your debug output contain?
WARNING. Your debug output contains AWS credentials that can be used to access your account. Be careful where you store and with whom you share your debug output.
I’ve had AWS support people ask me to send the output of this debug stack to them before. I’m sure they are just trying to do their job but big huge warning:
This output has a security token in it that can access your AWS account - without MFA - because it is an active session token.
I’m going to show you how we can leverage these tokens in a later blog post but for now, any time you output and share logs or debug information be aware of any sensitive data it may contain. Remove it before your share the logs. The token in this case should provide access for only a limited amount of time, but a limited amount of time is all a nefarious actor needs to insert a new user or other type of permissions or way to execute a command to gain a foothold. From that point on the person doesn’t need your stolen credentials anymore. They have their own.
Should you ever share your credentials?
You might also want to report this problem to AWS if it happens to you when contacting AWS support as the person requesting the information may not be aware implications. Or maybe they are. Maybe they just need additional security training.
AWS does a good job of ensuring people that work there have the best intentions and tries to weed out people who don’t, such as the Capital One Hacker who got let go by AWS prior to that security incident. It’s not easy for any organization to ensure that someone internally is not trying to steal or access customer data.
AWS also tries to separate customer data from employees, so AWS employees should not have access to your account or your data directly if that still holds true. But if you hand over your credentials to someone — then AWS can’t help you.
You may think that it’s ok to share your credentials with a coworker or even an AWS support person. You might want to read about the story I heard from a coworker of Edward Snowden that I wrote about in my book. I can’t verify the account but I suspect it is true.
Having someone work in your company who has malicious intentions or even someone who just makes a mistake and leaks sensitive or security-related data is known as an insider threat. Unfortunately, it happens, like it or not. I write about the concept of trust and how it affects governments, companies, managers, coworkers, business partners, and even parents and kids in my book at the bottom of this post.
This is a challenging topic no matter any way you look at it, but don’t share your personal credentials with anyone unless you don’t mind them taking actions that look like they are coming from you. That includes AWS access keys and secret keys, SSH keys, or any other type of key or credential that shows up in the logs associated with your name.
Individual credentials are critical for cybersecurity
Besides potential abuse by someone who is not the original recipient of the credentials, organizations need to be able to use credentials to pinpoint exactly who took what actions in an account. If you can’t do that you might be in a world of hurt when it comes to a security incident.
Most security best practice frameworks contain the recommendation or requirement that each individual in an organization has their own credentials and shared credentials are not used to access systems. Your organization will not be PCI compliant, for example, if you create one user name and password for AWS and share it with all your developers who have access to credit card data. The credentials and IDs help you create separation of duties in accounts and they track who took what actions.
If you can’t prove what actions someone took and you have a security incident, you may not be able to press charges. Your evidence may fall apart in court. This is why you need separate credentials for each user and users should not share credentials.
Other places to avoid storing, sharing, or outputting credentials
Other tools do output lots of useful information for attackers as well. I love it when I pentest an ASPX website with debug on and it contains lots of juicy credentials, for example. 🙂 Sometimes I only get the debug output after inputing some value the system doesn’t expect which then makes debug output accessible to me.
Developers have been known to share credentials in slack, which contributed to a recent Twitter breach, and also on Confluence or other internal content sharing or project management sites.
Also beware of outputting this debug content into a file in a directory that is associated with your GitHub repo or you may end up publishing the file to GitHub.
This debug output is not the only place you may find credentials. If people add sensitive data to certain properties of AWS resources it may be visible to the wrong people.
- When I started using AWS I wrote a blog post at Capital One about how our Chef credentials got output into the AWS console when you viewed the start up details for an EC2 instance. That has since been fixed.
- If you store secrets in the AWS metadata it is visible to anyone with console access or programmatic access to retrieve that data.
- If you use secrets in CloudFormation, depending on how you handle them, they may show up in the CloudFormation console.
- If you do not encrypt Lambda environment variables the data is available to anyone who can describe your Lambda functions and read the variables.
These are just a few examples. And by the way I’m going to check for things like that on an AWS penetration test or cloud security assessment. 🙂
Stolen and abused credentials are one of the number one contributing factor to most data breaches and security incidents. Be very careful to understand and prevent credentials from making their way into logs and output accessible to the wrong people who may use them in appropriately or maliciously. Ensure that only the person assigned to a single set of credentials is allowed to use them. Explain to people the implications and problems with shared credentials should a security incident or data breach occur.
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
