AWS - S3 Post Exploitation

Reading time: 5 minutes

S3

For more information check:

AWS - S3, Athena & Glacier Enum

Sensitive Information

कभी-कभी आप buckets में पढ़ने योग्य रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets.

Pivoting

विभिन्न प्लेटफ़ॉर्म S3 का उपयोग संवेदनशील assets स्टोर करने के लिए कर सकते हैं।
उदाहरण के लिए, airflow वहाँ DAGs code स्टोर कर सकता है, या web pages सीधे S3 से सर्व की जा सकती हैं। एक attacker जिसके पास write permissions हैं, वह bucket के code को modify the code करके अन्य प्लेटफ़ॉर्म पर pivot कर सकता है, या JS फाइलें बदलकर takeover accounts कर सकता है।

S3 Ransomware

इस परिदृश्य में, attacker अपने ही AWS account में या किसी अन्य compromised account में KMS (Key Management Service) key बनाता है। फिर वे इस key को दुनिया में किसी के लिए भी accessible बना देते हैं, जिससे कोई भी AWS user, role, या account इस key का उपयोग करके objects को encrypt कर सकता है। हालाँकि, objects को decrypt नहीं किया जा सकता।

attacker किसी target S3 bucket and gains write-level access को विभिन्न तरीकों से पहचानता/प्राप्त करता है। यह खराब bucket configuration के कारण सार्वजनिक रूप से उजागर होने से हो सकता है या attacker के AWS environment तक पहुँचने से भी। attacker आमतौर पर उन buckets को निशाना बनाते हैं जिनमें personally identifiable information (PII), protected health information (PHI), logs, backups, आदि जैसी संवेदनशील जानकारी होती है।

यह निर्धारित करने के लिए कि क्या bucket को ransomware के लिए लक्षित किया जा सकता है, attacker इसकी configuration की जाँच करता है। इसमें यह सत्यापित करना शामिल है कि S3 Object Versioning सक्षम है या नहीं और क्या multi-factor authentication delete (MFA delete) is enabled। यदि Object Versioning सक्षम नहीं है, तो attacker आगे बढ़ सकता है। यदि Object Versioning सक्षम है लेकिन MFA delete disabled है, तो attacker disable Object Versioning कर सकता है। यदि दोनों Object Versioning और MFA delete enabled हैं, तो उस विशिष्ट bucket को ransomware करना अधिक कठिन हो जाता है।

AWS API का उपयोग करके, attacker replaces each object in the bucket with an encrypted copy using their KMS key। यह प्रभावी रूप से bucket में मौजूद डेटा को encrypt कर देता है, जिससे बिना key के वह inaccessible हो जाता है।

अधिक दबाव डालने के लिए, attacker उस KMS key के deletion को शेड्यूल कर देता है जिसका उपयोग हमले में किया गया था। इससे target को अपनी डेटा recovery के लिए key delete होने से पहले 7-day फिराक मिलता है, अन्यथा डेटा स्थायी रूप से खो सकता है।

अंत में, attacker एक अंतिम फ़ाइल अपलोड कर सकता है, आम तौर पर नाम "ransom-note.txt" होती है, जिसमें लक्ष्य को उनकी फ़ाइलें कैसे पुनः प्राप्त करनी हैं इसके निर्देश होते हैं। यह फ़ाइल बिना एन्क्रिप्शन के अपलोड की जाती है, संभवतः target का ध्यान आकर्षित करने और उन्हें ransomware हमले के बारे में सूचित करने के लिए।

s3:RestoreObject

एक attacker जिसके पास s3:RestoreObject permission है, वह Glacier या Deep Archive में archived objects को फिर से सक्रिय कर सकता है, जिससे वे अस्थायी रूप से सुलभ हो जाते हैं। यह ऐतिहासिक रूप से archived डेटा (बैकअप्स, snapshots, logs, certifications, पुराने secrets) की recovery और exfiltration को सक्षम बनाता है जो सामान्यतः पहुँच से बाहर होते हैं। यदि attacker इस permission को read permissions (e.g., s3:GetObject) के साथ मिलाता है, तो वे संवेदनशील डेटा की पूरी प्रतियाँ प्राप्त कर सकते हैं।

aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'

s3:Delete*

जिसके पास s3:Delete* permission है, वह objects, versions और पूरे buckets को हटा सकता है, backups को बाधित कर सकता है, और तुरंत व अपरिवर्तनीय डेटा हानि, साक्ष्य का नाश, तथा backup या recovery artifacts के समझौते का कारण बन सकता है।

# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>

# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>

# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>

और अधिक जानकारी के लिए मूल रिसर्च देखें.