บัญชีถูกแฮ็กหลังเหตุขัดข้องของ AWS

 (news.ycombinator.com)
1 คะแนน โดย GN⁺ 2025-10-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

หลังจาก เหตุขัดข้องของบริการ AWS ที่เกิดขึ้นล่าสุด ผู้ใช้หนึ่งรายรายงานว่าได้ประสบเหตุการณ์บัญชี AWS ของตนถูก ผู้โจมตีภายนอก เข้าควบคุม

เส้นทางการรบกวนและปัญหาที่เกิดขึ้น

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

ความเสียหายและการตอบสนอง

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-22
ความคิดเห็นบน Hacker News

  • โดยปกติแล้วอาจคิดได้ว่าเรื่องนี้เป็นเรื่องบังเอิญ แต่ผมก็มีเคสที่บัญชีลูกค้าเคยถูกบุกรุกเช่นกัน ลูกค้าเป็นองค์กรเล็ก และมีบันทึกการเข้าคอนโซลและเปลี่ยนรหัสผ่านโผล่ขึ้นมาอย่างกะทันหันใน IAM 2 บัญชีเก่าที่ไม่เคยใช้มากว่า 5 ปี หลังการตรวจสอบ ในตอนนี้ข้อมูลที่ชัดเจนที่สุดมีเพียงการเปิดการเข้าถึง AWS SES ใน production และการยื่นตั๋วขอเพิ่มโควตาการส่งอีเมลรายวันเป็น 50,000 เท่านั้น บัญชีที่ค้างอยู่เกิน 5 ปีแล้วกลับมาทำงานตรงช่วงนี้ได้ช่างน่าแปลกใจ

    • ชัดเจนว่าเป็นกลิ่นฟิชชิง ตัวอย่างเช่นได้รับอีเมลปลอมโดยอ้างการหยุดชะงักของ AWS แล้วชวนให้เข้าสู่คอนโซล จากนั้นยืนยันตัวตนผ่าน wrapper ที่เป็นอันตรายก็อาจทะลุความปลอดภัยบัญชีได้
    • เหตุการณ์แทบจะเหมือนกันเกิดกับตัวผมเมื่อราว 1 ปีก่อน ล็อกอินด้วยบัญชีที่เก่าแก่มาก, เข้าถึง SES แล้วขอเพิ่มโควตาได้ การยกระดับการส่งอีเมล พวกเราระบบบัญชีที่ถูกบุกรุกออกทันทีและเช็ก Roles ทั้งหมด โดยลบ roles ที่มีอายุต่ำกว่า 1 เดือนหรือมีสิทธิ์ admin ออกทั้งหมด ในขณะเดียวกันพบว่าการบุกรุกเกิดขึ้นจริงจาก key ของเราเองด้วย ตัวผู้ใช้ตัวแรกถูกสร้างก่อนคำขอ SES จริงเกือบ 1 เดือน จึงอาจเป็นได้ว่าผู้โจมตีรอให้เกิดเหตุขัดข้องของ AWS แล้วใช้โอกาสนี้ และชั่วขณะปัญหา AWS อีกตัวอื่นๆ ก็ทำให้มองไม่เห็นชัด

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

    • แน่นอนว่าจะเกิดได้ ในฐานะคนทำ due diligence ผมก็เคยเจอกรณีจริง ผู้โจมตีบางรายจะจัดเตรียมทุกอย่างไว้ก่อนแล้วรอเหตุการณ์สำคัญอย่างการขายกิจการของบริษัทถึงวันนั้นจึงเคลื่อนไหว ผู้โจมตีที่พัฒนาขั้นสูงมักรอโอกาสแบบนี้และเตรียมพร้อมล่วงหน้า
    • ผมยืนยันว่าเป็นทีมเดียวกันเอง และจริงๆ แล้วเมื่อ 2 ปีก่อนเคยได้รับอีเมลเตือนเกี่ยวกับ key ที่เกี่ยวข้องกับการใช้งานผิดพลาดในวันนี้ มาจากคนสุ่ม แต่จนถึงเมื่อวานก็ไม่มีการ misuse ใดๆ
    • กลับกันช่วงนี้อาจไม่ใช่เวลาดีสำหรับการโจมตี เพราะทุกคนกำลังจับตา AWS และล็อกอินมาก จึงไวต่อความผิดปกติมากขึ้น ถ้าบริษัทเราใช้ AWS ยิ่งต้องเฝ้าดูทุกอย่างให้มากขึ้น

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

  • หากมีทรัพยากรแปลกๆ (เช่น EC2) ถูกสร้างในสภาพแวดล้อมคลาวด์ คุณสามารถเช็กได้จาก CloudTrail ว่าเกิดจากเหตุการณ์ใด โดยเฉพาะเหตุการณ์ runinstance

    • ผมไม่ค่อยได้ใช้ AWS ช่วงนี้ จึงเช็กคอนโซลเองไม่ได้ แต่หากเจอเรื่องคล้ายๆ กัน แนะนำขั้นตอนคร่าวๆ แบบนี้:
      1. ตรวจสอบบัญชี/ผู้กระทำที่สร้าง EC2 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
      2. ติดตามการกระทำต่อไปตาม userIdentity
      3. เช็กประวัติการล็อกอินผ่านคอนโซลโดยตรง (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
      4. ตรวจสอบประวัติคำขอการยืนยันผ่าน Security Token Service (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
      5. ดูว่ามีการใช้ AssumeRole ผ่าน STS session หรือไม่ (eventSource:sts.amazonaws.com, eventName:AssumeRole)
      6. ตรวจสอบความพยายามรักษาความต่อเนื่อง เช่น การสร้าง IAM Role/Account ใหม่ (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
      7. ดูว่า Role/Account เดิมมีการปรับให้สิทธิ์สูงขึ้นหรือไม่ (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
      8. ตรวจสอบการสร้าง/ลบ Access Key (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
      9. ตรวจสอบความเสี่ยง backdoor จากการแก้ไข IAMInstanceProfile ของ production EC2 (ดูตัวอย่างอ้างอิงจาก AWS Docs ตัวอย่าง) หากสงสัยการบุกรุกในระดับลึก ขอแนะนำให้ขอให้ผู้เชี่ยวชาญเข้าไปตรวจสอบสภาพแวดล้อมและทำ audit
    • ข้อมูลนี้ดีมาก จึงจะไปไล่ดู log ต่อ โดยสังเกตเพิ่มเติมมีดังนี้:
      1. ใต้ root account มีองค์กรราว 20 องค์กรถูกสร้างขึ้น และใช้อีเมลโดเมนเดียวกัน (co.jp)
      2. ผู้โจมตีได้ทำ fargate template หลายตัวไว้
      3. สร้างทรัพยากรใน 16~17 region ของ AWS
      4. มีการร้องขอทรัพยากรที่ไม่จำเป็น เช่น การขอเพิ่มโควตา SES, คำขอยกระดับ WS Fargate และคำขอบำรุงรักษา SageMaker notebook (มีอีเมลแจ้งเตือนจำนวนมาก)
      5. พบว่าบางอีเมลมีการเพิ่มชื่อใหม่ (random name@outlook.com)
      • เหตุการณ์ RunInstances นี่แหละคือเหตุการณ์นั้น

  • มีผู้ใช้ Reddit บางส่วนเล่าว่า ระหว่าง AWS outage พวกเขารีเฟรชแล้วบางครั้ง login เข้ามาเป็นผู้ใช้คนอื่น

    • ที่บริษัทที่ผมเคยทำงานมาก่อนไม่กี่แห่งก็เคยเจอแบบนี้เช่นกัน สาเหตุคือพนักงานคนหนึ่งทำ live debugging ในโปรดักชันที่ไม่ถูกต้อง ทำให้ลูกค้าถูกพาเข้าถึงข้อมูลลูกค้าคนอื่น เหมือนคนที่ผมเคยไม่เห็นด้วยตอนสัมภาษณ์นั่นแหละ แก้ไขยิ่งลำบากมาก
    • อาจเป็นไปได้ว่า DynamoDB ในช่วงเกิดเหตุขัดข้องเกิดการไม่สอดคล้องชั่วคราวจน credential ของ IAM เพี้ยนไปด้วยได้หรือไม่ ถ้าเป็นความจริงคงเป็นปัญหาหนักมาก อยากทราบว่ามีลิงก์อ้างอิงเคสแบบนี้บ้างไหม
    • ถ้ามีหลักฐานยืนยันอะไร ร่วมแชร์หน่อย มันน่าตกใจจริงๆ
    • ช่วงหลังนี้ทำให้ผมนึกถึงว่า ChatGPT ก็มีเรื่องคล้ายๆ แบบนี้ไหม รู้สึกแบบเดียวกัน
    • เหตุการณ์ด้านความปลอดภัยแบบนี้รุนแรงกว่าปัญหา outage ชั่วคราวของระบบมาก

  • ในสถานการณ์ปกติ เหตุการณ์แบบนี้มักเป็นเรื่องบังเอิญแต่โดยทั่วไปแล้วสาเหตุหลักคือการรั่วของ access key ส่วนการรั่วรหัสผ่านของบัญชีคอนโซลที่ไม่เปิด MFA ก็พบได้บ้างแม้จะน้อยกว่า

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

  • region us-east-1 ใหญ่เกินคาด จากข้อมูลล่าสุดที่เผยแพร่ว่าอยู่ที่ 159 data center และอาจมีหลายล้านบัญชีกระจุกตัวอยู่ตรงนี้ได้ เหตุการณ์นี้อาจเกี่ยวข้องกับ AWS outage ก็ได้ แต่ส่วนตัวคิดว่าโอกาสที่เป็นเรื่องบังเอิญยังสูงกว่า

    • 159 นี่เยอะมาก ถ้ามีแหล่งอ้างอิงช่วยแชร์ให้หน่อย

  • ฟังดูแปลกนะ แต่ถ้าส่ง API key มาได้ อาจเช็กให้ว่ามันอยู่ใน list รั่วไหม

    • ผมรู้ว่าเป็นเรื่องตลก แต่ก็อยากเตือนแบบจริงจังว่า คำแนะนำเรื่องการแชร์ API key หรือ credential ควรหลงเลี่ยง แม้จะพูดแบบขำขันก็ยังมีโอกาสมีคนตีความจริงได้จึงต้องระวัง