เหตุการณ์ด้านความปลอดภัยช่วงวันขอบคุณพระเจ้าปี 2023

 (blog.cloudflare.com)
1 คะแนน โดย GN⁺ 2024-02-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เหตุการณ์ด้านความปลอดภัยช่วงวันขอบคุณพระเจ้าปี 2023

  • เมื่อวันที่ 23 พฤศจิกายน 2023 ซึ่งเป็นวันขอบคุณพระเจ้า Cloudflare ตรวจพบผู้ไม่หวังดีบนเซิร์ฟเวอร์ Atlassian ที่โฮสต์เอง
  • ทีมความปลอดภัยเริ่มการสืบสวนทันทีและบล็อกการเข้าถึงของผู้ไม่หวังดี
  • วันที่ 26 พฤศจิกายน ได้เชิญทีมนิติวิทยาศาสตร์ดิจิทัลของ CrowdStrike เข้ามาทำการวิเคราะห์อย่างอิสระ
  • CrowdStrike ดำเนินการสืบสวนเสร็จสิ้น และ Cloudflare ได้แบ่งปันรายละเอียดของเหตุการณ์ด้านความปลอดภัยผ่านบล็อกโพสต์นี้
  • ย้ำว่าข้อมูลลูกค้าหรือระบบของ Cloudflare ไม่ได้รับผลกระทบจากเหตุการณ์นี้
  • การควบคุมการเข้าถึง กฎไฟร์วอลล์ และการบังคับใช้ฮาร์ดแวร์คีย์ด้านความปลอดภัยร่วมกับเครื่องมือ Zero Trust ทำให้ความสามารถในการเคลื่อนที่ด้านข้างของผู้ไม่หวังดีถูกจำกัด

งานกู้คืนและเสริมความแข็งแกร่งแบบ “Code Red”

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

ไทม์ไลน์ของการโจมตี

  • การโจมตีเริ่มต้นจากการละเมิดความปลอดภัยของ Okta ในเดือนตุลาคม และตั้งแต่กลางเดือนพฤศจิกายน ผู้ไม่หวังดีได้ใช้ข้อมูลรับรองที่ได้มาจากการละเมิด Okta เพื่อมุ่งเป้าไปที่ระบบของ Cloudflare
  • วันที่ 18 ตุลาคม การละเมิด Okta ทำให้ผู้ไม่หวังดีเข้าถึงข้อมูลรับรองได้
  • ตั้งแต่วันที่ 14 พฤศจิกายน ผู้ไม่หวังดีเริ่มสำรวจระบบและพยายามเข้าถึง
  • วันที่ 15 พฤศจิกายน สามารถเข้าถึง Atlassian Jira และ Confluence ได้สำเร็จ
  • วันที่ 16 พฤศจิกายน ได้สร้างบัญชีผู้ใช้ Atlassian
  • ระหว่างวันที่ 17 ถึง 20 พฤศจิกายน ไม่มีการเข้าถึงระบบ Cloudflare
  • วันที่ 22 พฤศจิกายน ได้ติดตั้ง Sliver Adversary Emulation Framework เพื่อรักษาการเข้าถึงอย่างต่อเนื่อง
  • วันที่ 23 พฤศจิกายน ทีมความปลอดภัยตรวจพบการมีอยู่ของผู้ไม่หวังดีและเริ่มปิดกั้นการเข้าถึง

บทสรุป

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

GN⁺ ความเห็น:

  1. เหตุการณ์นี้เน้นย้ำถึงความสำคัญของสถาปัตยกรรม Zero Trust ของ Cloudflare ซึ่งทำงานโดยจำกัดการแพร่กระจายของภัยคุกคามต่อทั้งองค์กรผ่านการแยกระหว่างระบบ
  2. การตอบสนองอย่างรวดเร็วของ Cloudflare และความพยายามเสริมความปลอดภัยผ่านโครงการ "Code Red" ให้ข้อมูลเชิงลึกเกี่ยวกับวิธีที่องค์กรรับมือกับภัยคุกคามด้านความมั่นคงปลอดภัยไซเบอร์
  3. บทความนี้เป็นกรณีศึกษาที่มีประโยชน์ซึ่งช่วยให้เข้าใจว่าองค์กรควรตอบสนองอย่างไรและควรดำเนินมาตรการใดเมื่อเกิดเหตุการณ์ด้านความมั่นคงปลอดภัยไซเบอร์

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

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

 
GN⁺ 2024-02-02
ความคิดเห็นจาก Hacker News

  • เหตุผลที่การกระทำแบบเดียวกับโพสต์บล็อกของ Cloudflare สร้างความน่าเชื่อถือ

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

  • ปัญหาของการรั่วไหลของข้อมูล

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

  • ปัญหาด้านความปลอดภัยของระบบ Okta

    • กังวลที่ระบบ Okta ได้รับผลกระทบเป็นครั้งที่สอง

  • โทเค็นบริการและบัญชีที่ไม่ได้ทำ rotation

    • ไม่ได้ทำ rotation เพราะมีความเชื่อผิด ๆ ว่าไม่ได้ใช้งานแล้ว
    • มีคำถามว่าทำไมจึงไม่เพิกถอนทิ้งทั้งหมดไปเลย

  • การเข้าถึงที่จำกัดของผู้โจมตีและมาตรการตอบสนอง

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

  • การวิเคราะห์เป้าหมายของผู้โจมตี

    • จากการวิเคราะห์หน้า wiki ฐานข้อมูลบั๊ก และที่เก็บซอร์สโค้ด ดูเหมือนว่าผู้โจมตีต้องการค้นหาข้อมูลเกี่ยวกับสถาปัตยกรรมเครือข่ายทั่วโลก ความปลอดภัย และการบริหารจัดการของ Cloudflare

  • ความประหลาดใจที่ Cloudflare ใช้ BitBucket

    • แสดงความประหลาดใจต่อข้อเท็จจริงที่ว่า Cloudflare ใช้ BitBucket

  • การจัดการข้อมูลรับรองที่ไม่ได้ใช้งาน

    • สำหรับข้อมูลรับรองที่เชื่อว่าไม่ได้ใช้งาน การลบทิ้งน่าจะเหมาะสมกว่าการทำ rotation

  • ข้อเสนอเรื่องการทำ rotation ข้อมูลรับรองหลังเหตุการณ์ Okta และการใช้ honeypot

    • เสนอว่าหลังจากทำ rotation ข้อมูลรับรองที่รั่วไหลแล้ว ควรใช้ honeypot เพื่อสังเกตพฤติกรรมของผู้โจมตี

  • ข้อสงสัยเกี่ยวกับ Zero Trust (ZT)

    • ชี้ว่าการเข้าถึงแอปพลิเคชันได้ด้วย bearer token เพียงตัวเดียวนั้นไม่สอดคล้องกับนิยามของ Zero Trust

ความรู้พื้นฐาน: Cloudflare เป็นบริษัทที่ให้บริการด้านความปลอดภัยอินเทอร์เน็ตและบริการ distributed domain name server ส่วน Okta เป็นบริษัทที่ให้บริการด้าน identity and access management และ Zero Trust คือโมเดลหนึ่งของความปลอดภัยเครือข่ายที่ใช้แนวทางไม่เชื่อถือผู้ใช้หรืออุปกรณ์ใด ๆ โดยปริยายและต้องตรวจสอบยืนยันเสมอ