I ran into a serious issue while using AWS Amplify to develop an S3 browser. During our testing phase, we mistakenly hardcoded our IAM user's access key and secret key in the JavaScript code. This IAM user was granted full permissions, including the ability to delete resources. Unfortunately, we later discovered that several of our S3 buckets had been deleted. After checking CloudTrail, we noted that the deletion came from a random IP address, and the user agent indicated that it was executed through software called S3 Browser. Since we never made the code public — it was only deployed on ECR for scanning — we're puzzled about how the credentials were exposed. How did this happen, and what can we do to prevent it from occurring again?
5 Answers
Sounds like your credentials might have been leaked right from the client-side code you wrote. You mentioned you were in testing, but anyone with the URL could have accessed it, even someone internal. Always refrain from using long-lived credentials in code!
You definitely need to stop exposing IAM credentials in client-side code! It's crucial to use AWS Amplify's Auth or Cognito to give your app temporary, limited access credentials. Also, make sure your web client isn't public. Was your ECR image made public by any chance?
There are a few potential leaks here: your image might have been pushed to a public repo, or the app incorrectly sent the keys to the client. For future security, ditch using access keys or secrets in favor of IAM roles that only have the permissions needed.
Make sure to take the following steps:
- Delete the compromised IAM user and review other SSO/Identity Center users.
- Check your IAM roles for any unrecognized external accounts.
Always remember:
- No credentials in your code.
- Avoid creating unnecessary IAM users.
Honestly, leaking happened because you wrote the keys into a client-side application. Anyone with basic coding knowledge can extract them without much trouble. The S3 Browser just indicates that your attacker used the easiest method to exploit the keys.
Exactly! Limiting permissions with IAM roles is a smart move. Even the end user shouldn't see what's going on with S3.