AWS Account Takeover via Log4Shell
gigasheet.co
gigasheet.co
> 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.
When was that, exactly?
I just grabbed by copy of CGI Programming on the World Wide Web by Gundavaram from 1996, and on page 368 it says:
> Most servers are set up to run with the user identification (UID) of "nobody," which means that your scripts have to be world executable. The reason for this is that "nobody" has minimal privileges.
Sure, there would always have been a few idiots who ran everything as root, but my recollection, backed up by the well-respected O'Reilly & Associates here, is that running internet-facing services with restricted privileges was the majority position for at least as long as web servers have had version numbers of 1.0+.
Because in an alternative universe, they could have chosen to treat log messages like SQL where parameters are passed separately.
Obviously some people must believe that logs should be trusted input, otherwise we wouldn’t be in this situation.
That said I consider both logs and error exceptions as untrusted input, but purely on practicality.
They did chose to do this. The vulnerability arises even when this is done correctly.
Pseudocode:
log("example: %s", userInput)
Log4j is not java. In fact, you can have log4c# or log4rust or log4fortran with precisely the same design, and consequently the same design problems and vulnerabilities.
> 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.
> 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?
Perhaps AWS should create a giant red alert that customers must acknowledge before applying such a configuration.
For that, those who built the tools must communicate how the tools work. It's not our responsibility, nor is it even possible, to read the mind of the people who made the tools.
Your comment fails to prove, or suggest, that OP's claim that AWS is too difficult to use securely by default is false. To first be in a position to refute OP's point you would need to prove, for starters, that no such vendor exists, which is absurd because they do exist, don't they?
In fact, if anything it supports OP's claim, as you've just pointed out that AWS even tries to profit from their problem of making it too difficult to use it securely by default by selling a premium service to audit credentials.
Simply reading the docs and attempting to divine the right subset of permissions can be nearly impossible. Usually you must guess, then exercise the software until it fails, then look in CloudTrail to see which permissions got denied, then try a new covering set, and repeat until nothing breaks. To say this is frustrating would be an understatement.
The same people who think docker/k8s is what everyone should use and that java is a slow language?
From [1]: "CloudTrail records two types of events: Management events capturing control plane actions on resources such as creating or deleting Amazon Simple Storage Service (Amazon S3) buckets, and data events capturing data plane actions within a resource, such as reading or writing an Amazon S3 object.