[HN Gopher] AWS Account Takeover via Log4Shell
___________________________________________________________________
AWS Account Takeover via Log4Shell
Author : naltun
Score : 46 points
Date : 2021-12-22 20:38 UTC (2 hours ago)
(HTM) web link (www.gigasheet.co)
(TXT) w3m dump (www.gigasheet.co)
| anonymouse008 wrote:
| [Edit] too funny, the first three comments are all similar
| messages with three different communication styles (this one the
| most terse, I have much to learn)...
|
| > The AWS account takeover was possible because a highly
| privileged IAM role had been assigned to the EC2 instance running
| the vulnerable Docker container app. While the Log4j2
| vulnerability allowed initial access to the Docker container, the
| privileged IAM role enabled lateral movement and ultimately a
| total compromise of the AWS account.
|
| Saving you a click... who would realistically give such a high
| permission set IAM to an EC2?
| thelittleone wrote:
| Because many people setting up AWS don't know this.
|
| Perhaps AWS should create a giant red alert that customers must
| acknowledge before applying such a configuration.
| ThalesX wrote:
| Where would the giant red alerts stop? They already have it
| for S3 after so many people left their buckets open. But is
| it also not our responsability to properly understand the
| tools we use?
| cddotdotslash wrote:
| This is a helpful writeup in terms of specific queries to look
| out for, but _any_ RCE on a host with privileged IAM access is
| going to lead to this scenario.
|
| > The AWS account takeover was possible because a highly
| privileged IAM role had been assigned to the EC2 instance running
| the vulnerable Docker container app
|
| This attack isn't unique to Log4Shell; it's a symptom of giving
| your (compromised) EC2 instance global admin access.
| yabones wrote:
| To me this is less about log4j, and more about giving everything
| root.
|
| > The AWS account takeover was possible because a highly
| privileged IAM role had been assigned to the EC2 instance running
| the vulnerable Docker container app
|
| The mistakes are, in order:
|
| 1. Binding an administrator IAM role to an EC2 instance, which is
| never ever a good thing to do, and
|
| 2. Running a docker container with full root privs - docker is
| not as much a security barrier as you think it is - it's only
| slightly better than running the application as root on the VM
| itself.
|
| So yes, the log4j vulnerability is dangerous, but not nearly as
| dangerous as running everything as root all the time.
| la6471 wrote:
| Click bait title which the author gingerly clarifies in the
| article to be result of poor security practices. It is obvious
| isn't it?
| kristianpaul wrote:
| That too, or he asumes everyone runs ec2 instances with Admin
| role as when people used to run LAMP as root...
| kristianpaul wrote:
| Once again its no the vulnerability but how permissions are
| assigned to applications.
| nrdvana wrote:
| Both are problems, but to me the biggest facepalm goes to log4j
| because anyone in their right mind should assume that log
| messages are untrusted input and should absolutely never have
| been parsed for control sequences. It's another prime example
| of Java over-engineering everything that should have been
| simple.
| tokamak-teapot wrote:
| Advert for gigasheet
___________________________________________________________________
(page generated 2021-12-22 23:01 UTC)