วิธีที่ผู้โจมตีสามารถใช้ข้อมูลเมตาของอินสแตนซ์เพื่อละเมิดแอปของคุณใน AWS

โดย Thyaga Vasudevan - VP of Product Management, Skyhigh Security

22 มีนาคม 2565 5 อ่านนาที

การย้ายไปยังสถาปัตยกรรมแบบ Cloud-Native สําหรับแอปพลิเคชันระดับองค์กรของคุณสามารถมอบมูลค่าทางธุรกิจมหาศาลเพิ่มขนาดและความคล่องตัวในขณะที่ลดภาระงานที่ยุ่งยากเช่นการแพตช์และการอัปเกรดโครงสร้างพื้นฐานของเซิร์ฟเวอร์

อย่างไรก็ตาม ในทุกสภาพแวดล้อมระบบคลาวด์ ไม่ว่าจะเป็น Amazon Web Services (AWS), Azure หรือ Google Cloud มีความเสี่ยงประเภทใหม่ ภัยคุกคามแบบ Cloud-Native เกิดจากบริบทใหม่และข้อกําหนดการกําหนดค่าที่คุณมีในสภาพแวดล้อมระบบคลาวด์ ในอดีตการตั้งค่าเริ่มต้นเช่นการเข้าถึงออบเจ็กต์ที่เก็บข้อมูลแบบสาธารณะได้ทิ้งข้อมูลที่ละเอียดอ่อนไว้ในที่โล่งและง่ายต่อการขโมยโดยทุกคนที่รวบรวมข้อมูลเพื่อหาจุดอ่อนเหล่านี้

การทําผิดพลาดในสภาพแวดล้อมใหม่เป็นเรื่องง่ายด้วยการตั้งค่าใหม่ที่ได้รับการแนะนําอย่างต่อเนื่องเมื่อมีการเพิ่มความสามารถใหม่โดยผู้ให้บริการระบบคลาวด์ การกําหนดค่าสภาพแวดล้อมระบบคลาวด์ของคุณเป็นความรับผิดชอบของคุณเสมอ AWS และบริษัทอื่นๆ ไม่สามารถควบคุมวิธีที่คุณใช้บริการของตนได้ พวกเขาเป็นแม่แบบสําหรับคุณที่จะสร้างจาก

การไม่เข้าใจผลลัพธ์ของการกําหนดค่าของคุณและวิธีสร้างแอปพลิเคชันแบบ Cloud-Native อาจส่งผลร้ายแรงได้ และแม้แต่ลูกค้าระบบคลาวด์ที่เชี่ยวชาญที่สุดก็สามารถได้รับผลกระทบจากผลกระทบเหล่านี้ได้

กรณีในประเด็นคือการละเมิดที่ Capital One ประสบเมื่อเกือบสามปีที่แล้วซึ่งผู้โจมตีสามารถเข้าถึงหมายเลขประกันสังคมจากบุคคลในสหรัฐอเมริกา 100 ล้านคนและหมายเลขประกันสังคมจากบุคคลในแคนาดา 6 ล้านคน ผู้โจมตีใช้เทคนิคหลายอย่างในการเข้าถึงข้อมูล แต่การเรียนรู้ที่สําคัญจากการโจมตีคือคุณลักษณะด้านความปลอดภัยที่ออกแบบมาเพื่อปกป้องการเข้าถึงเครื่องเสมือน – อินสแตนซ์ Elastic Compute Cloud หรือ EC – เพิ่มผู้โจมตี คุณลักษณะนี้เรียกว่าบริการ Instance Metadata หรือ IMDS

การโจมตีข้อมูลเมตาของอินสแตนซ์

IMDS เวอร์ชัน 1 (IMDSv1) เปิดตัวในปี 2012 เพื่อให้อินสแตนซ์ EC2 สามารถโต้ตอบกับบริการอื่นๆ ของ AWS ได้อย่างปลอดภัยยิ่งขึ้น แทนที่จะทิ้งคีย์ AWS ไว้บนอินสแตนซ์ ลูกค้าสามารถให้อินสแตนซ์ EC2 สืบค้นบริการข้อมูลเมตาเพื่อรับข้อมูลประจําตัวและเรียกใช้ AWS API ไปยังบริการอื่นๆ ของ AWS ได้ ตัวอย่างเช่น หากอินสแตนซ์ EC2 มีข้อมูลลูกค้าบางส่วน อินสแตนซ์ก็สามารถใช้ IMDSv1 เพื่อจัดเก็บข้อมูลนั้นในบัคเก็ต Amazon Simple Storage Service (S3) ได้ ความสามารถที่แน่นอนนี้เองที่ผู้โจมตีใช้ในการดึงข้อมูลที่ละเอียดอ่อนจากบัคเก็ต S3 ที่ใช้ในการจัดเก็บข้อมูลเกี่ยวกับลูกค้า Capital One

ในการทดสอบของเราเองเราสามารถทําซ้ําว่าการดึงข้อมูลนี้สามารถทํางานในแอปพลิเคชันใด ๆ ได้อย่างไร ในตัวอย่างของเรา ทีมนักระบาดวิทยาได้สร้างแอปพลิเคชันแบบ Cloud-Native ใน AWS พร้อมแดชบอร์ดสาธารณะเพื่อแสดงข้อมูลที่แสดงความคืบหน้าในการวิเคราะห์จีโนมของไวรัสด้วยสายตา

 

ในระหว่างขั้นตอนการพัฒนาแอปพลิเคชันนี้ ทีมงานต้องเผชิญกับความท้าทาย ทรัพยากรส่วนใหญ่ใน Virtual Private Cloud (VPC) ควรถูกซ่อนจากอินเทอร์เน็ต ทรัพยากรเดียวใน VPC ที่มีไว้สําหรับมุมมองสาธารณะคือแดชบอร์ด

บัคเก็ต S3 ที่โฮสต์ข้อมูลจําเป็นต้องรักษาความเป็นส่วนตัว ในการดึงข้อมูลจาก S3 ไปยังแดชบอร์ดสาธารณะ พวกเขาได้เพิ่มพร็อกซีย้อนกลับ โดยทําหน้าที่เป็นคนกลาง สิ่งที่ต้องทําคือการค้นหาโดย Google อย่างรวดเร็วและโค้ดสองสามบรรทัดเพื่อเพิ่มสิ่งนี้ลงในแอปพลิเคชัน

 

สําหรับทีมนักระบาดวิทยาพร็อกซีย้อนกลับเป็นโซลูชันพื้นฐานที่สง่างามซึ่งทํางานได้อย่างสมบูรณ์แบบสําหรับกรณีการใช้งานของพวกเขา สิ่งที่พวกเขาไม่รู้ก็คือมันทําให้พวกเขาถูกละเมิดครั้งใหญ่

อินสแตนซ์การประมวลผลที่เรียกใช้พร็อกซีย้อนกลับได้รับมอบหมายบทบาท IAM ที่มีสิทธิ์เข้าถึงบัคเก็ต S3 ส่วนตัว ข้อมูลประจําตัวสําหรับพร็อกซีย้อนกลับเพื่อเข้าถึง S3 ได้มาจากข้อมูลเมตาของอินสแตนซ์

ผู้โจมตีที่เข้าชมไซต์และสนใจข้อมูลของพวกเขาสังเกตเห็นว่าทีมได้อ้างอิงที่อยู่ IP ของพร็อกซีย้อนกลับในแดชบอร์ด จากนั้นผู้โจมตีจะตรวจสอบเพื่อดูว่าสามารถเชื่อมต่อได้หรือไม่ หลังจากยืนยันการเชื่อมต่อแล้ว ผู้โจมตีจะตรวจสอบเพื่อดูว่าพวกเขาสามารถเข้าถึงข้อมูลเมตาของอินสแตนซ์ผ่านพร็อกซีย้อนกลับได้หรือไม่ ความสําเร็จ

ผ่านพร็อกซีย้อนกลับและจากข้อมูลเมตาของอินสแตนซ์ ผู้โจมตีจะเปิดเผยข้อมูลประจําตัวไปยังบัคเก็ตพื้นที่จัดเก็บ S3 ส่วนตัวของทีม

 

ตอนนี้ด้วยการเข้าถึงบัคเก็ต S3 ผู้โจมตีสามารถขโมยข้อมูลที่มีความละเอียดอ่อนสูงที่ทีมเก็บไว้สําหรับแอปพลิเคชันของตนได้ ผู้โจมตีเพียงแค่ซิงค์บัคเก็ต S3 เป้าหมายกับบัคเก็ต S3 ของตนเองในบัญชี AWS อื่น และข้อมูลก็เป็นของพวกเขา

 

การโจมตีประเภทนี้เป็นเพียงหนึ่งใน 43 เทคนิคที่ MITRE อธิบายไว้ในเฟรมเวิร์ก ATT&CK สําหรับสภาพแวดล้อมระบบคลาวด์: https://attack.mitre.org/matrices/enterprise/cloud/

วิธีที่ AWS ลดการโจมตีข้อมูลเมตาของอินสแตนซ์

เพื่อปรับปรุงความปลอดภัยของบริการนี้ AWS ได้เปิดตัว IMDSv2 ซึ่งเพิ่มการป้องกันใหม่หลายชั้น

ใน IMDSv2 ผู้ใช้ภายนอกจะถูกบล็อกไม่ให้รับข้อมูลรับรอง โดยอนุญาตให้รับเฉพาะทรัพยากรแอปพลิเคชันเท่านั้น อ่านเพิ่มเติมเกี่ยวกับชั้นการป้องกันนี้และ IMDSv2 ที่นี่: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

อย่างไรก็ตาม ความท้าทายยังคงอยู่ที่ IMDSv1 ยังคงมีอยู่ ไม่มีสิ่งใดใน AWS ที่ป้องกันไม่ให้ลูกค้าใช้ IMDSv1 และคุณยังสามารถใช้งานได้ตามค่าเริ่มต้นสําหรับอินสแตนซ์ EC2 ทั้งหมดของคุณ ดังที่เราได้กล่าวไว้ก่อนหน้านี้ AWS ไม่ใช่ความรับผิดชอบในการตรวจสอบให้แน่ใจว่าคุณใช้ระบบคลาวด์อย่างปลอดภัย ความรับผิดชอบนั้นตกอยู่กับลูกค้าแต่เพียงผู้เดียว

ในการโจมตีที่เราเพิ่งอธิบายพร็อกซีย้อนกลับได้รับการกําหนดค่าไม่ถูกต้องเพื่อให้คําขอภายนอกเข้าถึงทรัพยากรภายในได้ หากทีมได้กําหนดค่าอินสแตนซ์การประมวลผลให้ใช้ IMDSv2 การเข้าถึงโดยไม่ได้รับอนุญาตโดยผู้คุกคามภายนอกจะถูกบล็อก

Skyhigh Cloud Native Application Protection สามารถช่วยได้อย่างไร

ที่ Skyhigh Securityเรามีหลายวิธีที่สามารถช่วยคุณตรวจจับและป้องกันการโจมตีเช่นนี้ได้ Skyhigh Cloud Native Application Protection Platform (CNAPP) เป็นแพลตฟอร์มการรักษาความปลอดภัยแบบ Cloud-Native ของเราที่ให้คุณตรวจสอบและอัปเดตการกําหนดค่าใน AWS, Azure, GCP พร้อมกับมาตรการรักษาความปลอดภัยเพิ่มเติมมากมายที่คุณสามารถอ่านได้ที่นี่

การใช้การผสานรวม API โดยตรงกับ AWS ทําให้ Skyhigh CNAPP ตรวจสอบ Amazon CloudWatch ซึ่งเป็นบริการตรวจสอบแอปพลิเคชันและโครงสร้างพื้นฐานอย่างต่อเนื่อง เพื่อระบุเวอร์ชันของ IMDS ที่คุณใช้ในทุกอินสแตนซ์ EC2

เมื่อ CloudWatch บันทึกอินสแตนซ์ที่ใช้งานอยู่โดยใช้ IMDSv1 Skyhigh CNAPP จะสร้างเหตุการณ์ด้านความปลอดภัย โดยแจ้งให้คุณอัปเดตการกําหนดค่าของคุณเป็น IMDSv2 ซึ่งจะป้องกันการเข้าถึงข้อมูลประจําตัวของคุณโดยไม่ได้รับอนุญาตโดยผู้ใช้ภายนอก

เหตุการณ์นโยบาย Skyhigh CNAPP สําหรับการกําหนดค่าเวอร์ชัน IMDS

แนวทางปฏิบัติที่ดีที่สุดในการบังคับใช้ IMDSv2 บน EC2 instance ของคุณสําหรับโค้ดภายในเครื่องและผู้ใช้ทั้งหมด เมื่อคุณระบุว่าต้องใช้ IMDSv2 แล้ว IMDSv1 จะไม่ทํางานอีกต่อไป AWS มีคําแนะนําทีละขั้นตอนเกี่ยวกับวิธีกําหนดค่าอินสแตนซ์ของคุณเพื่อใช้ IMDSv2 ที่นี่

นอกเหนือจากตัวอย่างการโจมตีนี้ Skyhigh CNAPP ยังช่วยให้คุณใช้ชุดแนวทางปฏิบัติที่ดีที่สุดเพื่อปกป้องแอปพลิเคชันบนคลาวด์ของคุณ:

• ตรวจสอบการกําหนดค่าของคุณอย่างต่อเนื่อง ด้วย Skyhigh CNAPP คุณสามารถสแกนเทมเพลต AWS CloudFormation ก่อนที่จะเข้าสู่การผลิต จากนั้นตรวจหา "ความคลาดเคลื่อน" ใดๆ ในการกําหนดค่าของคุณเมื่อเวลาผ่านไป สิ่งนี้ช่วยให้คุณสามารถตรวจจับการกําหนดค่าที่ไม่ถูกต้องและบังคับใช้โมเดลที่มีสิทธิ์น้อยที่สุดสําหรับการอนุญาตทรัพยากร
• บังคับใช้ Zero-Trust ใช้ zero-trust เป็นวิธีการที่อนุญาตให้เรียกใช้และสื่อสารระหว่างกันได้เฉพาะทรัพยากรเฉพาะเท่านั้น อย่างอื่นถูกบล็อก
• สแกนหาช่องโหว่ของโค้ด โดยเฉพาะอย่างยิ่งกับโมเดลการกระจายซอฟต์แวร์แบบเปิด เช่น Docker สิ่งสําคัญคือต้องตรวจสอบทรัพยากรแอปพลิเคชันของคุณเพื่อหาช่องโหว่อย่างต่อเนื่อง
• ตรวจจับความผิดปกติและภัยคุกคาม ด้วย User and Entity Behavior Analytics (UEBA) คุณสามารถประเมินเหตุการณ์ระบบคลาวด์นับล้านรายการเพื่อเปิดเผยกิจกรรมที่ผิดปกติและภัยคุกคามที่แท้จริง เช่น การโจรกรรมข้อมูลประจําตัว
• เรียกใช้ DLP บนอ็อบเจ็กต์ที่เก็บข้อมูล เช่นเดียวกับบริการระบบคลาวด์อื่นๆ ที่คุณอนุมัติ เครือข่าย หรือตําแหน่งข้อมูลของคุณภายใน AWS คุณสามารถและควรจัดประเภทข้อมูลของคุณภายใน S3 และเรียกใช้ data loss prevention เพื่อหยุดความพยายามในการลักลอบนําเข้า

ติดต่อเราเพื่อพูดคุยเกี่ยวกับการใช้มาตรการเหล่านี้ในองค์กรของคุณเอง

กลับไปที่บล็อก