สิ่งที่คุณต้องรู้เกี่ยวกับ ransomware บน AWS

แม้ ransomware จะเป็นปัญหาใหญ่ในดาต้าเซ็นเตอร์ แต่ผมค่อนข้างสงสัยว่ามันจะเป็นปัญหามากขนาดนั้นบนคลาวด์หรือไม่ ส่วนตัวแล้วผมไม่เคยเจอเหตุการณ์ลักษณะนี้เลย และเริ่มคิดว่ามันเป็นเพียงเรื่องในทางทฤษฎีมากกว่าอย่างอื่น ปรากฏว่าผมเข้าใจผิดไปเล็กน้อย เอาจริง ๆ คือผิดเต็ม ๆ ไม่เพียงแต่เป็นปัญหาที่ใหญ่กว่าที่ผมคิด แต่รูปแบบการโจมตีใน Amazon Web Services (AWS) ยังแตกต่างจากที่ผมคาดไว้ด้วย

ในงานประชุม AWS re:Inforce ผมได้เข้าร่วมเซสชันที่ยอดเยี่ยมซึ่งนำโดย Kyle Dickinson, Megan O’Neil และ Karthik Ram ห้องเต็มจนล้น และเจ้าหน้าที่ประจำห้องต้องปฏิเสธผู้เข้าร่วมอีกหลายสิบคน บทความนี้เป็นการสรุปเนื้อหาจากเซสชันดังกล่าว ผสมกับประสบการณ์และข้อแนะนำของผมเองเกี่ยวกับ AWS ransomware ข้อผิดพลาดหรือสิ่งที่ตกหล่นใด ๆ เป็นความรับผิดชอบของผม ไม่ใช่ของพวกเขา

ประเด็นสำคัญ:

• ผู้โจมตีด้วย ransomware พุ่งเป้าไปที่สภาพแวดล้อม Amazon Web Services (AWS) มากขึ้นเรื่อย ๆ โดยมักอาศัยช่องโหว่ด้านการเข้าถึงข้อมูลประจำตัว การตั้งค่าพื้นที่จัดเก็บข้อมูล และการขาดการมองเห็นข้ามบริการต่าง ๆ
• Amazon S3 bucket เป็นช่องทางเข้าที่พบได้บ่อย โดยผู้โจมตีเข้ารหัสหรือลบข้อมูลสำคัญ อันเป็นผลจาก policy ที่อ่อนแอหรือการไม่บังคับใช้การเข้ารหัส
• การป้องกัน ransomware บนคลาวด์ที่ได้ผลต้องอาศัยกลยุทธ์แบบหลายชั้น ทั้งการควบคุมการเข้าถึง การมอนิเตอร์แบบเรียลไทม์ และ workflow การตอบสนองที่รวดเร็ว
• FireMon ยกระดับ data security posture ด้วยการมอนิเตอร์การตั้งค่าที่ผิดพลาดอย่างต่อเนื่อง บังคับใช้ policy ในระดับขนาดใหญ่ และมอบการมองเห็นที่ช่วยให้ทีมตอบสนองต่อภัยคุกคาม ransomware บนคลาวด์ได้เร็วขึ้น

Amazon AWS Ransomware เป็นปัญหาจริงหรือไม่

ใช่ ปรากฏว่า AWS ransomware เป็นปัญหามากกว่าที่ผมคิดไว้ในตอนแรก มีลูกค้าจริงได้รับผลกระทบแล้ว ไม่ได้เป็นเพียงเรื่องทางทฤษฎี

การโจมตีด้วย Amazon Ransomware ทำงานอย่างไร

ผมจะอธิบายช่องทางการเจาะระบบเริ่มต้นในหัวข้อถัดไป แต่เทคนิคการโจมตีด้วย Amazon ransomware ที่เป็นไปได้มีอยู่ 4 รูปแบบ:

• ผู้โจมตีเข้าควบคุม instance (มักผ่านการ phishing ผู้ใช้หรือผู้ดูแลระบบ ไม่ใช่การเจาะโดยตรงเสมอไป) จากนั้นติดตั้งมัลแวร์เพื่อเข้ารหัสข้อมูลและแพร่กระจายไปยัง instance อื่นที่เข้าถึงได้ รูปแบบนี้แทบไม่ต่างจาก ransomware ในดาต้าเซ็นเตอร์ เพราะไม่ได้เกี่ยวข้องกับสิ่งที่เฉพาะเจาะจงกับคลาวด์เลย
• ผู้โจมตีคัดลอกข้อมูลออกจาก S3 bucket แล้วลบข้อมูลต้นฉบับทิ้ง นี่คือ Amazon ransomware แบบ cloud native ที่พบบ่อยที่สุด
• ผู้ไม่ประสงค์ดีเข้ารหัสข้อมูลใน S3 ด้วย KMS key ที่อยู่ภายใต้การควบคุมของตน รูปแบบนี้ยังเป็นทฤษฎีมากกว่าของจริง ด้วยหลายปัจจัย เพราะการลบ object หรือ bucket ทิ้งนั้นง่ายกว่าการย้อนกลับไปเข้ารหัสมาก
• ผู้โจมตีทำบางอย่างกับข้อมูลในบริการจัดเก็บข้อมูลอื่นเพื่อล็อกหรือลบข้อมูล ที่ผมพูดกว้าง ๆ เพราะยังไม่พบกรณีเช่นนี้ และบริการเหล่านั้นส่วนใหญ่มีข้อจำกัดภายในและความทนทานในตัวที่ทำให้การทำ ransomware สำเร็จได้ยาก

Ransomware พุ่งเป้าไปที่ AWS S3 bucket มากที่สุด โดยผู้โจมตีจะคัดลอกข้อมูลแล้วลบทิ้ง ส่วน instance หรือเซิร์ฟเวอร์ก็อาจตกเป็นเป้าของมัลแวร์ชนิดเดียวกับที่ใช้โจมตีดาต้าเซ็นเตอร์ได้เช่นกัน นอกจากนี้ยังมีการโจมตีเชิงทฤษฎีอีกไม่กี่รูปแบบที่แทบไม่พบจริงในโลกภายนอก

อย่างไรก็ตาม มีการโจมตี Amazon ransomware รูปแบบใหม่ที่กำลังแพร่หลายมากขึ้น นั่นคือกลุ่ม ransomware เริ่มเข้ารหัสข้อมูลในที่ตั้งเดิมโดยใช้ server-side encryption with customer-provided keys (SSE-C) ของ AWS เทคนิคนี้ทำให้ผู้โจมตีเข้ารหัสไฟล์ใน S3 bucket ของคุณได้โดยตรง โดยไม่ต้องย้ายข้อมูลออกและไม่กระตุ้นการแจ้งเตือนมาตรฐาน อีกทั้งไม่สามารถกู้คืนข้อมูลได้หากไม่มีคีย์เข้ารหัสเฉพาะของผู้โจมตี

ผู้โจมตีเข้าถึงระบบเพื่อโจมตี Amazon Web Services ด้วย Ransomware ได้อย่างไร

ข้อมูลประจำตัวที่รั่วไหล เกือบทุกครั้งคือ static access key แต่ก็อาจเป็นคีย์ที่ได้มาจาก instance ที่ถูกเจาะ (ผ่าน metadata service) ก็คือรูปแบบเดียวกับที่การโจมตีด้านความปลอดภัยบนคลาวด์เกือบทั้งหมดใช้งานกัน

ลำดับขั้นของการโจมตี S3 ด้วย Ransomware เป็นอย่างไร

ผมจะเน้นที่สถานการณ์ ransomware บน S3 bucket เพราะเป็นรูปแบบ cloud native ที่เราต้องการให้ความสำคัญ

• ผู้โจมตีได้ข้อมูลประจำตัวมา
• ผู้โจมตีใช้ข้อมูลประจำตัวนั้นสำรวจระบบ เพื่อดูว่าเรียกใช้ API ใดได้บ้างและระบุทรัพยากรที่เข้าถึงได้
• ผู้โจมตีพบว่าตนมีสิทธิ์เขียนบน S3 และมีสิทธิ์ list/read เพื่อระบุ bucket ทั้งนี้ ผู้โจมตีอาจไม่มีสิทธิ์ List แต่ได้ชื่อ bucket จากแหล่งอื่น เช่น DNS, GitHub หรือที่อื่น ๆ ซึ่งมีโอกาสเกิดขึ้นน้อยกว่ามาก
• ผู้โจมตีคัดลอกหรือย้ายข้อมูลไปยังตำแหน่งอื่น ซึ่งไม่จำเป็นต้องอยู่ใน AWS
• ผู้โจมตีลบ object หรือไฟล์ต้นทางทิ้ง
• ผู้โจมตีอัปโหลดข้อความเรียกค่าไถ่ (หรือส่งอีเมล)

ในแคมเปญช่วงหลัง ผู้โจมตียังเริ่มใช้ policy ของ S3 Object Lifecycle Management เพื่อกำหนดให้ไฟล์ที่ถูกเข้ารหัสถูกลบภายในเจ็ดวัน เพื่อเร่งให้เหยื่อจ่ายค่าไถ่เร็วขึ้น และมักทิ้งไฟล์ warning.txt ไว้ในไดเรกทอรีที่ได้รับผลกระทบ พร้อมที่อยู่กระเป๋า Bitcoin และรหัสประจำตัวเหยื่อเฉพาะราย

เนื่องจากทั้งหมดนี้เป็นกระบวนการอัตโนมัติ การโจมตีจึงอาจเริ่มขึ้นภายในหนึ่งนาทีหลังข้อมูลประจำตัวรั่วไหล

จะตรวจจับ Amazon S3 Ransomware ได้อย่างไร

ถ้าคุณข้ามขั้นตอนการป้องกัน S3 ransomware ไม่ได้ ก็มาดูกัน…

โดยทั่วไปผู้โจมตีจะทิ้งข้อความพร้อมข้อมูลติดต่อไว้ให้คุณส่ง Bitcoin ไปให้ ซึ่งก็สะดวกดี แต่ส่วนใหญ่แล้วคุณคงอยากตรวจพบปัญหาก่อนถึงจุดนั้น เรามาไล่ดูลำดับขั้นของการโจมตี Amazon S3 ด้วย ransomware กันว่าเราจะจับสัญญาณได้ตรงจุดไหนบ้าง

อย่างแรก คุณควรเปิดใช้งานการมอนิเตอร์เชิงลึกสำหรับ bucket ที่มีข้อมูลสำคัญ เนื่องจากบทความนี้ยาวเกินกว่าที่ตั้งใจไว้แล้ว ผมจะข้ามรายละเอียดทั้งหมดเกี่ยวกับวิธีระบุและจัดการ bucket เหล่านั้น และเน้นไปที่แหล่งข้อมูลสำคัญไม่กี่แหล่งที่ควรพิจารณาแทน ด้วยเหตุผลด้านค่าใช้จ่าย อย่าคาดหวังว่าจะเปิดใช้สิ่งเหล่านี้กับทุกอย่าง:

• CloudTrail แน่นอนอยู่แล้ว
• CloudTrail Data Events สำหรับ bucket ที่คุณให้ความสำคัญ ส่วนนี้มีค่าใช้จ่ายเพิ่ม
• GuardDuty
• ทางเลือกเสริม: Security Hub นี่คือวิธีที่ดีที่สุดในการรวมข้อมูลจาก GuardDuty และบริการด้านความปลอดภัยอื่น ๆ ของ AWS จากทุกบัญชีเข้าด้วยกัน
• อาจพิจารณา: S3 Server Access Logs หากคุณมี CloudTrail Data Events อยู่แล้ว คุณก็ได้ข้อมูลส่วนใหญ่ที่ต้องการ แต่ S3 logs สร้างได้ฟรี (จ่ายเฉพาะค่าพื้นที่จัดเก็บ) และเก็บเหตุการณ์บางอย่างที่ CloudTrail อาจพลาดไป (เช่น การยืนยันตัวตนที่ล้มเหลว) อย่างไรก็ตาม ข้อมูลเหล่านี้ใช้เวลาหลายชั่วโมงกว่าจะปรากฏ จึงไม่มีประโยชน์ขณะรับมือเหตุการณ์แบบสด ๆ อ่านเพิ่มเติมได้ในคู่มือผู้ใช้ฉบับนี้

เมื่อพูดถึงการมอนิเตอร์กันไปแล้ว มาดูเจ็ดขั้นตอนของกระบวนการตรวจจับกัน:

1. การตรวจจับข้อมูลประจำตัวที่รั่วไหลและกิจกรรมสำรวจระบบ

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

การตรวจจับการสำรวจข้อมูลประจำตัวในบัญชีของคุณจะใช้ได้ในขั้นนี้ ตัวเลือกบางส่วนได้แก่:

• GuardDuty findings เช่น การขโมยข้อมูลประจำตัวออกไป อย่างไรก็ตาม มีความล่าช้าราว 20 นาที และยังมีเทคนิคหลบเลี่ยงการตรวจจับ
• การเรียก API GetCallerIdentity ไม่ได้เป็นสัญญาณร้ายเสมอไป แต่ก็ไม่ใช่การเรียกที่ควรพบบ่อยในบัญชี production
• GetAccountAuthorizationDetails ควรแจ้งเตือนทุกครั้ง
• การเรียก API ที่ล้มเหลวหลายครั้งจาก IAM entity เดียว

2. การเฝ้าระวังการ enumerate S3

ถึงจุดนี้ เราเริ่มโฟกัสที่การตรวจจับ AWS ransomware ซึ่งบ่งชี้ว่าผู้โจมตีกำลังเล็งไปที่ S3 คุณคงสังเกตว่าการตรวจจับตั้งแต่ระยะแรกในเฟสเหล่านี้ทำได้ยากเพราะมี noise มาก แต่พึงระลึกว่าวิธีเหล่านี้จะใช้ได้ผลกว่าในสถานการณ์อย่างบัญชี production ที่บริหารจัดการผ่าน CI/CD โดยมีคนเข้าถึงอย่างจำกัด เอาเข้าจริง เรื่องนี้อาจเป็นแรงจูงใจให้คุณหันมาใช้รูปแบบ cloud-native มากขึ้น

ใช้GuardDuty S3 findings สำหรับเหตุการณ์ประเภท Discovery ซึ่งต้องเปิดใช้งานเพิ่มเติมจากการเปิด GuardDuty เฉย ๆ ขึ้นอยู่กับการตั้งค่าบัญชีและองค์กรของคุณ ให้กรองเฉพาะ Management และ Data Events ประเภท Read และ List ที่ล้มเหลวบนบริการ S3 คุณอาจจับได้ว่าผู้โจมตีกำลังสำรวจอยู่ ซึ่งทำได้ใน SIEM ของคุณ หรือจะสร้าง CloudWatch Metrics Filters สำหรับสิ่งเหล่านี้ก็ง่ายเช่นกัน

3. การมอนิเตอร์การอ่านและคัดลอก object

ในขั้นนี้ คุณกำลังการตรวจสอบอย่างต่อเนื่องเพื่อดูว่าผู้โจมตีกำลังอ่านอ็อบเจ็กต์และทำสำเนาอยู่หรือไม่ หากผู้โจมตีอ่าน (คัดลอก) แล้วลบอ็อบเจ็กต์ทีละรายการ ขั้นตอนนี้อาจคาบเกี่ยวกับเฟสถัดไป

4. การตรวจจับการลบข้อมูลจำนวนมากและการวางข้อความเรียกค่าไถ่

นี่คือขั้น "ซวยแล้ว" ผู้โจมตีไม่ได้เพียงสำรวจรอบ ๆ อีกต่อไป แต่กำลังลงมือโจมตีและลบข้อมูลที่คัดลอกไปแล้ว GuardDuty findings ประเภท exfiltration/impact ของ S3 จะเริ่มทำงาน อย่าลืมว่าต้องใช้เวลาอย่างน้อย 20 นาทีกว่าจะถูกทริกเกอร์ และขึ้นอยู่กับจำนวนอ็อบเจ็กต์ สัญญาณนี้อาจมาช้าเกินไป ส่วน CloudTrail Insights หากคุณใช้งานอยู่ จะแจ้งเตือนเมื่อพบ Write events จำนวนมากที่ใช้ในการย้ายข้อมูล

คุณสามารถสร้างการตรวจจับของคุณเองสำหรับการเรียกคำสั่งลบจำนวนมากได้ ทั้งนี้ขึ้นอยู่กับสภาพแวดล้อมและรูปแบบกิจกรรมปกติขององค์กร เกณฑ์ดังกล่าวอาจตั้งไว้ต่ำและทริกเกอร์ได้เร็วกว่า GuardDuty โดย SIEM และ CloudWatch Metrics Filters เป็นตัวเลือกที่ดี

5. การระบุการใช้ SSE-C ในทางที่ผิด (Silent Encryption)

เฝ้าระวังการใช้ SSE-C headers ที่เกิดขึ้นอย่างกะทันหันใน API calls เช่น PutObject ซึ่งเป็นสัญญาณว่าข้อมูลอาจถูกเข้ารหัสด้วยคีย์ของผู้โจมตี เนื่องจาก AWS บันทึกเพียงค่า HMAC hash ของการดำเนินการ การกู้คืนด้วยกระบวนการ forensic มาตรฐานจึงเป็นไปไม่ได้หากไม่มีการเฝ้าระวังเชิงรุก

6. การใช้ canary buckets และการตรวจจับ KMS

องค์กรที่มีความพร้อมสูงสามารถวาง canary buckets/objects ไว้ในบัญชี แล้วตั้งการแจ้งเตือนเมื่อมีการดำเนินการใด ๆ กับ buckets เหล่านั้น แม้จะเป็นรูปแบบการโจมตีที่พบไม่บ่อยนัก แต่คุณก็สามารถแจ้งเตือนทีมงานเมื่อมีการใช้ KMS key จากภายนอกบัญชีของคุณได้

7. การยกระดับเหตุการณ์และการตอบสนองต่อ incident

หากคุณตรวจพบการโจมตีในขั้นนี้ แสดงว่าระบบของคุณถูกเจาะแล้ว ถึงเวลาต้องตอบสนอง แจ้งหน่วยงานบังคับใช้กฎหมายและติดต่อทีม AWS customer incident response

การป้องกัน ransomware บน AWS: ทำอย่างไรให้องค์กรปลอดภัย

การโจมตีด้วย ransomware บน AWS ให้สำเร็จนั้น ผู้โจมตีต้องมีเงื่อนไขสามข้อ ได้แก่

• การเข้าถึง credentials
• สิทธิ์ในการอ่านและเขียนข้อมูลใน S3
• ความสามารถในการลบอ็อบเจ็กต์โดยที่กู้คืนไม่ได้

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

• อย่าอนุญาตให้มี IAM users ที่มาพร้อม static access keys เลย หากทำไม่ได้ ก็ควรใช้เครื่องมือของคุณระบุผู้ใช้ทุกรายที่มีสิทธิ์ลบข้อมูลใน S3 ให้ได้อย่างแน่นอน
• กำหนดให้ผู้ใช้ SSO/federated ต้องใช้ MFA เสมอ ตลอดไป
• ให้ผู้ดูแลระบบยกระดับไปใช้ IAM roleอื่นเมื่อจำเป็นต้องดำเนินการลบข้อมูล คุณสามารถแยกสิทธิ์การอ่านและการลบออกเป็นคนละ role ได้อย่างสมบูรณ์ด้วยซ้ำ
• หาก instance จำเป็นต้องเข้าถึง S3 ให้กำหนดขอบเขตสิทธิ์ให้แคบที่สุดเท่าที่ทำได้ ทั้งจำกัดเฉพาะ API calls ที่จำเป็นขั้นต่ำและทรัพยากรที่จำเป็นขั้นต่ำ
• ปิดการใช้งาน SSE-C เว้นแต่จำเป็นจริง ๆ วิธีนี้ช่วยป้องกันการโจมตีแบบ silent encryption ที่อาจล็อกคุณออกจากข้อมูลของตนเองโดยไม่มีทางกู้คืน
• ใช้ VPC endpoint ในการเข้าถึง bucket และเสริมด้วย resource policy ที่อนุญาตให้ลบข้อมูลได้จาก VPC ต้นทางเท่านั้น เพื่อให้ผู้โจมตีไม่สามารถใช้ credentials นอก VPC นั้นได้
• เปิดใช้งาน versioning, AWS Backup และ/หรือ bucket replication ทั้งหมดนี้ช่วยให้มั่นใจว่าคุณจะไม่สูญเสียการเข้าถึงข้อมูล เว้นเสียแต่ว่าคุณจะตั้ง IAM policies ผิดพลาดอย่างร้ายแรงจนเปิดช่องให้ผู้โจมตีทำได้ตามใจ บางรายการต้องเปิดใช้งานตั้งแต่ตอนสร้าง bucket ดังนั้นคุณอาจต้องดำเนินการย้ายข้อมูลเพื่อให้ทำได้

คุณคงสังเกตว่าผมข้ามเรื่อง Block Public Access ไป ฟีเจอร์นี้ดีมาก แต่หลายองค์กรทำได้ยากในระดับสเกลใหญ่ เพราะยังจำเป็นต้องมี public buckets อยู่บ้าง และฟีเจอร์นี้ก็ไม่ช่วยอะไรกับการโจมตีที่ใช้ credentials ที่รั่วไหล

ทั้งหมดนี้ต้องใช้ความพยายามและมีต้นทุนเพิ่ม ผมจึงแนะนำอย่างยิ่งให้เริ่มจากการโฟกัสที่ buckets ซึ่งมีความสำคัญจริง ๆ ก่อน ยังมีกลยุทธ์ขั้นสูงกว่านี้อีก โดยเฉพาะหากคุณดูแลสภาพแวดล้อมขนาดใหญ่ ซึ่งเขียนไม่หมดในบทความเดียว หากสนใจพูดคุยเรื่องนี้ ติดต่อผมได้เลย

ได้เรียนรู้อะไรใหม่เกี่ยวกับ S3 ransomware จากเซสชัน Re:Inforce บ้าง

ผมไม่เคยรู้มาก่อนว่า S3 ransomware แพร่หลายขนาดนี้ และไม่รู้ว่าเทคนิคที่ผู้โจมตีนิยมใช้คือการคัดลอกแล้วลบ ผมเคยคิดว่าเป็นการใช้การเข้ารหัสด้วย KMS ซึ่งพอฟังแล้วก็เข้าใจได้อย่างชัดเจนว่าทำไมวิธีนั้นจึงเป็นเพียงทฤษฎีและพบได้ยาก ผมคุ้นเคยกับตัวตรวจจับและมาตรการป้องกันเหล่านี้อยู่แล้ว แต่ผู้บรรยายจาก AWS ทำได้ยอดเยี่ยมในการร้อยเรียงทุกอย่างเข้าด้วยกันอย่างชัดเจนและนำไปใช้ได้จริง เซสชันนี้เกินความคาดหมายของผมอย่างแน่นอน

FireMon ช่วยองค์กรของคุณป้องกัน S3 ransomware ได้อย่างไร

เรามีผลิตภัณฑ์ IAM ตัวใหม่ที่อยู่ในช่วง Beta สำหรับสิทธิ์แบบ Just in Time ซึ่งจะเปิดตัวในเร็ว ๆ นี้ นอกจากนี้เรายังมี posture checks และ threat detectors ใน DisruptOps เพื่อระบุ buckets ที่มีความเสี่ยงและแจ้งเตือนกิจกรรมที่เป็นอันตราย เช่น การโจมตีด้วย ransomware ติดต่อผมได้หากต้องการพูดคุยเรื่องเหล่านี้ หรือแม้แต่ขอคำแนะนำทั่วไปเกี่ยวกับตัวเลือกต่าง ๆ ของ AWS ที่ผมกล่าวถึงในบทความนี้

จองการสาธิตวันนี้ และดูว่า FireMon ช่วยปกป้ององค์กรของคุณจาก ransomware บน AWS ได้อย่างไร