Having good security hygiene is standard practice when building cloud infrastructure. It is, however, quite difficult to think of all potential risks when doing so. This blog describes a situation on Amazon Web Services (AWS) that can be easily prevented, but also the risks involved in having this risk exposed.
Recently, when doing some preparations for an upcoming migration to AWS, I’ve been going through some scripts that set up the application environment for a Java application. One thing in particular stood out, which was the unintended exposure of root access to the customer application.
A script installing a Java application on an Amazon Linux 2 instance contained the following instruction:
This immediately raised a red flag with me, because this could mean the application data needs to read and write to this folder, and the application user could very well be EC2-user. Now you tell me, “the application is not running as root, so this is good practice”. Well, perhaps in a Docker container, but keep in mind we are talking about Amazon Linux 2 here.
The EC2-user on Amazon Linux 2 by default is a member of the group wheel. This is a group that allows administrator access. Because of the nature of the EC2-user and the way people get access to Amazon EC2 instances through the command line, no password is set at any point. Because of this, the sudoers file does not ask for a password whenever calling sudo as EC2-user.
Going back to the Java application configuration, going over the rest of the script, it shows the application is managed through systems, and is accompanied by a service file. The contents of this file are:
Note the User parameter. It is set to EC2-user. This confirms that the application is run as the EC2-user.
So now you have your Java application running as an administrator user, not as root. What’s so bad about that? Well, we’ve all seen these Remote Code Execution (RCE) vulnerabilities. An RCE enables an attacker to run any bit of arbitrary code on a vulnerable system. If your Java application is vulnerable to, let’s say, Log4Shell, an attacker would be able to spawn a shell on your system as EC2-user. Running any other command from that point on would be as easy as running sudo any command.
We can go far beyond this hypothetical situation in which we dive into what other possibilities this gives an attacker, but that would be a rabbit hole on its own. It suffices to say that with root access, the attacker can hide their evidence quite easily while being able to access any data on the system and possibly beyond. The solution in this case would be to limit the user used by the application. Create a new user with the least privilege needed for the application to work.