Protecting the AWS Systems Manager Agent (SSM)

#aws #cloudsecurity #ssm

What is a Systems Manager (SSM) agent? Usually, when Development or DevOps teams deploy their code or software on their infrastructure they will use SSH with a bastion host to reduce the exposure of your network.

If you use an SSH connection to your private EC2 without a bastion, stop reading and implement a bastion host to connect to your private network(ASAP!).?

https://aws.amazon.com/blogs/security/how-to-record-ssh-sessions-established-through-a-bastion-host/

The SSM agent allows you to communicate with your EC2 or Service in a secure(Enable TLS 1.2) channel that the agent implements with the AWS system Manager. In other words, you can send commands to your EC2 to be executed without using a direct connection to your EC2.

The AWS SSM also allows you to upload scripts to the AWS console and send them to your EC2.

AWS SSM Agent is installed by default on Amazon Linux, Amazon Linux 2, SUSE Linux Enterprise Server (SLES) 12 and 15, Ubuntu Server 16.04, 18.04 LTS, and 20.04 base Amazon EC2 AMIs. You must manually install SSM Agent on other versions of Amazon EC2 for Linux, including non-base images and even more (MacOS and Windows are also supported).?

Are there any downsides of using an SSM agent? With great power comes great responsibility.

Problem 1: The SSM agent creates a local user account with the name ‘ssm-user’ and adds it to /etc/sudoers (Linux and macOS) or to the Administrators group (Windows).? Any vulnerability in the agent can lead to privilege escalation.

Solution 1: Turn off ssm-user account administrative permissions and keep your agent updated(https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-ssm-user-permissions.html).

Problem 2: IAM policy with high privileges allows SSM read/write/execute("ssm": "*") to all the resources("Resource": "*"). This will provide access to any EC2 instances that have SSM agent enabled(Lateral movement).

Solution 2: Avoid using wildcards in your policies. Instead, list only the actions you need in order to prevent any risk or exposure to your EC2s.

Problem 3: The IAM service allows you to use StartSession/SendCommand API calls. If an attacker has managed to obtain AWS keys with those permissions, he will be able to send commands to your EC2 instances or even connect to them if start-session is enabled.?

aws ssm send-command? --instance-ids "{INSTANCE-ID}"? --document-name "{SCRIPT NAME}" --parameters commands="{PAYLOAD}"

aws ssm start-session --target instance-id

Solution 3: Restrict permission to sendCommand and StartSession APIs only for users that must have them, if not needed disallow the usage of them. Monitor SSM API calls on Cloudtrail and creates alerts if someone attempts to use those API.

Problem 4: Attacker got access to the IAM credentials of an EC2 instance. He now can manipulate the SSM agent to intercept EC2 messages and SSM sessions.

1. EC2 messages: The agent will keep the connection open for approximately 20 seconds and listen for messages such as SendCommand. The attacker can call ec2messages:GetMessages on his own and intercept any SendCommand that was sent to the agent.
2. SSM Sessions: When the SSM agent is being executed it will create many Websocket connections and listen to messages such as StartSession. The source code for the SSM Agent is available here (https://github.com/aws/amazon-ssm-agent/) and in particular the part to perform the WebSocket connection (https://github.com/aws/amazon-ssm-agent/blob/21c85d674bbb44dd13cd8738d1b9d86658a6b18e/agent/session/contracts/agentmessage.go#L73). Just like with EC2 messages AWS the attacker only needs to make sure the connection is the newest one. This also allows you to send back messages to someone that is trying to start sessions.?

For more details read this research https://frichetten.com/blog/ssm-agent-tomfoolery/

Solution 4: Monitor the SSM agent connection on CloudWatch and the output from the SSM agent.