การละเมิดที่เปลี่ยนสมมติฐานความปลอดภัยคลาวด์ขององค์กร
การละเมิด LastPass ปี 2022 ไม่ใช่เรื่องราวหลักเกี่ยวกับตัวจัดการรหัสผ่าน แต่เป็นเรื่องราวเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อองค์กรไว้วางใจผู้ให้บริการคลาวด์กับข้อมูลละเอียดอ่อนที่สุดของตน และความไว้วางใจนั้นถูกละเมิด ไม่ใช่จากความประมาทแต่จากความอ่อนแอในการ implement ที่มองไม่เห็นจากภายนอก
LastPass ทำการตลาดสถาปัตยกรรม zero-knowledge สถาปัตยกรรมนั้นไม่ใช่ zero-knowledge ในทางปฏิบัติ ผู้ใช้ 25 ล้านคน มี vault ที่เข้ารหัสแล้วของตนถูกดึงข้อมูลออกไป การละเมิดถูกเปิดเผยครั้งแรกในเดือนสิงหาคม 2022 และได้รับการอัปเดตหลายครั้งจนถึงปลายปี 2022 เมื่อขอบเขตขยายออก
สำหรับองค์กรในด้านการดูแลสุขภาพ การเงิน และบริการทางกฎหมาย ซึ่งเป็นภาคส่วนที่การเปิดเผยข้อมูลสร้างความรับผิดด้านกฎระเบียบ การละเมิด LastPass ไม่ใช่เหตุการณ์ที่แยกออกมาเพื่อดูจากระยะไกล แต่เป็นการแสดงตัวอย่างล่วงหน้าของปัญหาเชิงระบบ
รายละเอียด Implementation ที่สำคัญ
การวิเคราะห์หลังการละเมิดเผยให้เห็นความอ่อนแอของ implementation สองอย่างที่สำคัญ:
การขาดจำนวน iteration: LastPass ใช้ PBKDF2 สำหรับการสร้างกุญแจ สำหรับบัญชีใหม่กว่า พวกเขาใช้ 100,100 iterations ซึ่งต่ำกว่าคำแนะนำของอุตสาหกรรมที่ 600,000 สำหรับบัญชีเก่า (ก่อนปี 2018 ในบางกรณี) จำนวน iteration ต่ำถึง 1 iteration จำนวน iteration ที่ต่ำกว่าทำให้การโจมตี brute-force บน vault ที่เข้ารหัสสามารถทำได้ในเชิงคอมพิวเตอร์ ผู้โจมตีที่ได้ vault สามารถพยายามอย่างเป็นระบบในการถอดรหัส master password
การเปิดเผย metadata: ในขณะที่เนื้อหา vault ถูกเข้ารหัส metadata ไม่ได้ถูกเข้ารหัส URL ที่จัดเก็บใน password manager ชื่อผู้ใช้ และชื่อบริการมองเห็นได้ในข้อมูลที่ถูกดึงออกไป ผู้โจมตีสามารถระบุบริการที่ผู้ใช้มีบัญชีด้วย ทำให้สามารถทำ phishing และ credential stuffing ที่มีเป้าหมายได้แม้โดยไม่ถอดรหัส vault
สำหรับทีมจัดซื้อที่ประเมินผู้ให้บริการความปลอดภัยคลาวด์ กรณี LastPass แสดงให้เห็นว่าต้องตอบคำถามสองข้อแยกกัน: "สถาปัตยกรรมเป็น zero-knowledge?" และ "การ implement ถูกต้องหรือไม่?"
การละเมิด Okta: เดือนเดียวกัน กลไกต่างกัน
ในเดือนตุลาคม 2023 Okta เปิดเผยว่าผู้ก่อภัยคุกคามใช้ข้อมูลรับรองที่ถูกขโมยเพื่อเข้าถึงระบบสนับสนุนลูกค้าของ Okta การละเมิดเปิดเผย บันทึกสนับสนุนลูกค้ากว่า 600,000 รายการ รวมถึงไฟล์ที่ลูกค้าอัปโหลดระหว่างการโต้ตอบการสนับสนุน
Okta เป็นแพลตฟอร์มความปลอดภัย identity การละเมิดไม่ใช่ความล้มเหลวของสถาปัตยกรรมพื้นฐาน แต่เป็นความล้มเหลวของการควบคุมการเข้าถึงของ supply chain วิศวกรสนับสนุนมีข้อมูลรับรองที่ถูกโจมตี และผู้โจมตีใช้การเข้าถึงที่ถูกต้องตามกฎหมายในการเข้าถึงข้อมูลละเอียดอ่อน
การรวมกันของ LastPass และ Okta แสดงให้เห็นรูปแบบความล้มเหลวสองอย่างที่ผู้ให้บริการคลาวด์องค์กรเผชิญ:
- ความล้มเหลวเชิงสถาปัตยกรรม: คำกล่าวอ้าง zero-knowledge ที่ไม่ได้ implement อย่างแท้จริง
- ความล้มเหลวการควบคุมการเข้าถึง: ข้อมูลรับรองที่ถูกต้องนำไปสู่การเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต
สถาปัตยกรรม zero-knowledge แก้ไขรูปแบบความล้มเหลวแรก ไม่ได้ป้องกันผู้โจมตีที่มุ่งมั่นซึ่งได้รับข้อมูลรับรองที่ถูกต้องสำหรับระบบสนับสนุนของผู้ให้บริการ แต่ทำให้แน่ใจว่าแม้แต่ผู้โจมตีดังกล่าวก็ไม่สามารถเข้าถึง plaintext ของลูกค้าได้ เพราะระบบสนับสนุนของผู้ให้บริการไม่มีวันเข้าถึงข้อมูลที่ถอดรหัสได้
เหตุการณ์ความปลอดภัย SaaS เพิ่มขึ้น 300% ตั้งแต่ปี 2022 ถึง 2024
การวิจัย AppOmni และ Cloud Security Alliance ที่ติดตามเหตุการณ์การละเมิด SaaS ตั้งแต่ปี 2022 ถึง 2024 พบ การเพิ่มขึ้น 300% ของเหตุการณ์ความปลอดภัยที่ส่งผลกระทบต่อแพลตฟอร์ม SaaS ในช่วงเวลานี้
ตัวเลข 300% ไม่ได้แสดงถึงการเพิ่มขึ้น 300% ของความซับซ้อนของผู้โจมตี แต่แสดงถึงการเติบโตของการนำ SaaS มาใช้รวมกับการปรับตัวของผู้โจมตี: เมื่อข้อมูลองค์กรมากขึ้นย้ายไปยังแพลตฟอร์มคลาวด์ ผู้โจมตีเปลี่ยนทรัพยากรไปมุ่งเป้าแพลตฟอร์มเหล่านั้น ROI ของการโจมตีผู้ให้บริการ SaaS ซึ่งก็คือการได้รับเข้าถึงข้อมูลจากลูกค้าองค์กรหลายสิบหรือหลายร้อยราย สูงกว่าการมุ่งเป้าองค์กรแต่ละแห่งอย่างมาก
สำหรับองค์กรที่สร้างกระบวนการประเมินความปลอดภัยของผู้ให้บริการบนสมมติฐานที่ว่าผู้ให้บริการคลาวด์เป็นเป้าหมายที่ปลอดภัย ข้อมูลปี 2022–2024 ต้องการการปรับเทียบใหม่ สมมติฐานนั้นผิด ผู้ให้บริการ SaaS เป็นเป้าหมายลำดับต้น
รายการตรวจสอบการตรวจสอบหลัง LastPass
สำหรับองค์กรที่ประเมินความปลอดภัยของผู้ให้บริการคลาวด์ใหม่หลังเหตุการณ์ LastPass และ Okta รายการตรวจสอบในทางปฏิบัติ:
การ implement การเข้ารหัส:
- ขอ algorithm การสร้างกุญแจ จำนวน iteration และพารามิเตอร์หน่วยความจำ
- ยืนยันว่าจำนวน iteration เป็นไปตามคำแนะนำปัจจุบันของ OWASP (ขั้นต่ำ 600,000 PBKDF2-SHA256 หรือพารามิเตอร์ Argon2id ที่เทียบเท่า)
- ตรวจสอบว่าการสร้างกุญแจเกิดขึ้นฝั่ง client ไม่ใช่บนเซิร์ฟเวอร์ของผู้ให้บริการ
การปกป้อง metadata:
- ถามโดยตรงว่า metadata ใดถูกจัดเก็บใน plaintext ควบคู่กับเนื้อหาที่เข้ารหัส
- ขอ data model แสดงฟิลด์ใดที่ถูกเข้ารหัสและฟิลด์ใดที่เข้าถึงได้ในสถานการณ์การละเมิด
การควบคุมการเข้าถึงของระบบสนับสนุน:
- ขอเอกสารเกี่ยวกับการเข้าถึงข้อมูลลูกค้าของวิศวกรสนับสนุน
- ยืนยันว่าระบบสนับสนุนไม่สามารถเข้าถึง plaintext ของลูกค้าได้
ประวัติการแจ้งเตือนการละเมิด:
- ขอการเปิดเผยเหตุการณ์ความปลอดภัยก่อนหน้าทั้งหมด รวมถึงเหตุการณ์ที่ไม่ถึงเกณฑ์การเปิดเผยสาธารณะ
- ประเมินความโปร่งใสและความสมบูรณ์ของการเปิดเผยก่อนหน้า
การละเมิด LastPass เป็นส่วนหนึ่งจากความล้มเหลวของ implementation และส่วนหนึ่งจากความล้มเหลวของความโปร่งใสเกี่ยวกับ implementation องค์กรที่ถามคำถามรายละเอียดก่อนการเลือกผู้ให้บริการได้รับคำตอบที่ช่วยให้ประเมินความเสี่ยงอย่างรอบรู้ องค์กรที่ยอมรับคำกล่าวอ้างระดับสูง ซึ่งก็คือ "เราเข้ารหัสข้อมูลของคุณ" รับมรดกความเสี่ยงของการค้นพบรายละเอียด implementation หลังจากการละเมิด
แหล่งที่มา: