Headline
GHSA-q4pp-j36h-3gqg: Minimal `basti` IAM Policy Allows Shell Access
Summary
The provided Minimal IAM Policy for bastic connect
does not include ssm:SessionDocumentAccessCheck
. This results in the ability to get a shell session on the bastion, not just the intended access for Port Forwarding.
Details
basti connect
is designed to "securely connect to your RDS/Aurora/Elasticache/EC2 instances", using a bastion instance “with AWS Session Manager port forwarding capability to make the target available on your localhost.”
The Minimal IAM Policy allows port forwarding via the following statement:
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost",
"arn:aws:ec2:<your-region>:<your-account-id>:instance/<your-basti-instance-id>"
]
}
This statement does not include the following condition:
"Condition": {
"BoolIfExists": {
"ssm:SessionDocumentAccessCheck": "true"
}
}
As a result, the basti connect
minimal policy is logically identical to:
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost",
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell",
"arn:aws:ec2:<your-region>:<your-account-id>:instance/<your-basti-instance-id>"
]
}
A basti
admin would expect users under the minimal policy to be able to port forward. However, they could also get a shell on the bastion.
For more details on this footgun, see: https://ramimac.me/ssm-iam
PoC
Complete instructions, including specific configuration details, to reproduce the vulnerability.
Impact
Impact would depend on configuration/hardening of the bastion. I’ve seen examples where bastions have credentials to downstream systems in configuration or memory that would be exposed.
Summary
The provided Minimal IAM Policy for bastic connect does not include ssm:SessionDocumentAccessCheck. This results in the ability to get a shell session on the bastion, not just the intended access for Port Forwarding.
Details
basti connect is designed to "securely connect to your RDS/Aurora/Elasticache/EC2 instances", using a bastion instance “with AWS Session Manager port forwarding capability to make the target available on your localhost.”
The Minimal IAM Policy allows port forwarding via the following statement:
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost",
"arn:aws:ec2:<your-region>:<your-account-id>:instance/<your-basti-instance-id>"
]
}
This statement does not include the following condition:
"Condition": {
"BoolIfExists": {
"ssm:SessionDocumentAccessCheck": "true"
}
}
As a result, the basti connect minimal policy is logically identical to:
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost",
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell",
"arn:aws:ec2:<your-region>:<your-account-id>:instance/<your-basti-instance-id>"
]
}
A basti admin would expect users under the minimal policy to be able to port forward. However, they could also get a shell on the bastion.
For more details on this footgun, see: https://ramimac.me/ssm-iam
PoC
Complete instructions, including specific configuration details, to reproduce the vulnerability.
Impact
Impact would depend on configuration/hardening of the bastion. I’ve seen examples where bastions have credentials to downstream systems in configuration or memory that would be exposed.
References
- GHSA-q4pp-j36h-3gqg
- BohdanPetryshyn/basti@f6f218e