ตู้นิรภัยไม่ถูกเจาะ — แต่นั่นไม่ใช่ทางเข้าอยู่แล้ว

LastPass ถูกเจาะอีกครั้งในเดือนนี้ ส่วนที่ทุกคนรอรับมือไม่เกิดขึ้น ไม่มีตู้นิรภัยถูกแคร็ก ไม่มี master password หลุด ข้อมูลลับที่เข้ารหัสไว้ไม่ถูกแตะต้อง LastPass ยืนยันว่า "ผลิตภัณฑ์ บริการ และโครงสร้างพื้นฐานไม่ได้รับผลกระทบ" และว่าตู้นิรภัยของลูกค้า "ยังคงปลอดภัย" [1]

ผู้โจมตีไม่ได้เข้าใกล้ตู้นิรภัยเลย พวกเขาเดินเข้ามาทางผู้ขาย (vendor) รายหนึ่ง

ขอยกห่วงโซ่เหตุการณ์ให้ดู เพราะกลไกคือประเด็นทั้งหมด วันที่ 11 มิถุนายน กลุ่มที่เรียกตัวเองว่า Icarus เข้าถึง Klue แพลตฟอร์ม market-intelligence ที่ @LastPass ใช้ภายในองค์กร ทางเข้าของพวกเขา ตามที่ @HuntressLabs ซึ่งรับผิดชอบเหตุการณ์นี้ระบุ คือ "ข้อมูลรับรอง API ที่หลับใหลมานาน ซึ่งเดิมสร้างขึ้นสำหรับ prototype ของ integration บุคคลที่สามที่ถูกทิ้งร้าง" [2] คีย์ที่สร้างไว้สำหรับโปรเจกต์ที่ไม่มีอยู่แล้ว เพื่อจุดประสงค์ที่ไม่มีใครจำได้ แต่ยังใช้งานได้ จากภายใน Klue พวกเขาผลักโค้ดร้ายที่ดึง OAuth token ที่ Klue เก็บไว้ให้ลูกค้า: สิทธิ์ที่เปิดค้างไว้ ซึ่งให้ Klue อ่าน @salesforce, Slack, HubSpot และอื่น ๆ แทนบริษัทเหล่านั้น หนึ่งในโทเคนเหล่านั้นเป็นของ LastPass ด้วยโทเคนนั้น ผู้โจมตีอ่าน Salesforce CRM ของ LastPass ชื่อ อีเมล เบอร์โทรศัพท์ ที่อยู่ เนื้อหาเคสซัพพอร์ต จากนั้นก็เป็นจดหมายขู่เรียกค่าไถ่ จ่าย หรือข้อมูลจะถูกนำไปโพสต์บน leak site

LastPass ไม่ได้เป็นรายเดียวที่ได้รับผลกระทบ Huntress, Recorded Future, Tanium, Jamf, BeyondTrust — ส่วนใหญ่เป็นบริษัทความปลอดภัย ประเภทที่ทำเรื่องนี้เป็นอาชีพ

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

นั่นคือจุดที่เปลี่ยนไป threat model ขยับจาก "พวกเขาจะเจาะตู้นิรภัยได้ไหม" ไปเป็น "มีกุญแจที่ถูกลืมวางค้ำประตูไว้กี่ดอก ในประตูที่คุณเลิกเฝ้าดู" ข้อมูลรับรองที่ตายแล้วจาก prototype ที่ถูกทิ้งร้าง เพียงพอที่จะเข้าถึงข้อมูลลูกค้าของบริษัทหลายราย คณิตศาสตร์ไม่เคยเป็นจุดอ่อน ความกระจัดกระจายต่างหากที่เป็น

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

มีข้อจำกัดข้อหนึ่งที่ควรพูดให้ชัด Clavitor กำกับดูแลข้อมูลรับรองที่ตนถืออยู่ ไม่ใช่ standing OAuth grant ที่คุณมอบให้แพลตฟอร์มของผู้ขาย โทเคนนั้นอยู่ในระบบของพวกเขา ภายใต้การควบคุมของพวกเขา และไม่มีตู้นิรภัยไหนจะเอื้อมเข้าไปหมดอายุมันแทนคุณได้ สิ่งที่เปลี่ยนคือทุกอย่างในขอบเขตของ Clavitor มันปฏิเสธที่จะเป็นที่ที่ความลับซึ่งไม่มีวันหมดอายุจะมานั่งอยู่เงียบ ๆ วินัยที่การขาดหายไปเปิดช่องให้ Klue (อายุสั้น ขอบเขตแคบ ระบุแหล่งที่มาได้จริง) เป็นค่าเริ่มต้นที่นี่ ไม่ใช่การตั้งค่าที่ใครสักคนควรจะต้องจำได้

คำถามที่เหลืออยู่เป็นคำถามที่อึดอัด มีโทเคนที่ยังใช้งานได้กี่ตัว กำลังนั่งอยู่ในผู้ขายที่คุณรับเข้ามาเมื่อปีที่แล้ว และไม่ได้นึกถึงอีกเลย?

เราเขียนสรุปคุณสมบัติไม่กี่ข้อที่ credential ควรมี ก่อนที่คุณจะไว้ใจมันกับอะไรก็ตาม ไว้แล้วครับ [3]

Clavitor (@clavitorai) คือ credential vault ที่สร้างขึ้นสำหรับ AI agents และเพื่อรับมือกับ AI agents clavitor.ai

แหล่งอ้างอิง

[1] BleepingComputer, "LastPass confirms data breach in Klue supply chain attack" — @BleepinComputer

[2] Huntress incident findings, reported via Help Net Security, "Klue breach lead to Salesforce data theft, Huntress affected" — @HuntressLabs, @helpnetsecurity

[3] The Ten Rules of Credential Management (native X Article) — @clavitorai