ผลการสืบสวนทางเทคนิคสำคัญเกี่ยวกับการได้มาซึ่งคีย์ของ Storm-0558
(msrc.microsoft.com)- ผลการสืบสวนทางเทคนิคของเหตุการณ์ที่ผู้ไม่หวังดีจากจีน Storm-0558 ปลอมโทเคนด้วย MSA consumer signing key ที่ขโมยมาเพื่อเข้าถึง OWA และ Outlook.com
- ในเดือนเมษายน 2021 มี crash dump ของระบบลงนามฝั่ง consumer ที่ล่ม ถูกสร้างขึ้น และเนื่องจาก race condition ทำให้มีคีย์รวมอยู่ด้วย โดยระบบตรวจไม่พบ
- crash dump ที่มีคีย์ถูกย้ายจากเครือข่ายโปรดักชันที่แยกกักไปยัง สภาพแวดล้อมสำหรับดีบัก บนเครือข่ายองค์กรที่เชื่อมต่ออินเทอร์เน็ต และไม่ถูกตรวจพบจากการสแกนข้อมูลรับรอง
- สาเหตุที่คีย์ฝั่ง consumer สามารถใช้เข้าถึง เมลองค์กร ได้ มาจากนักพัฒนาระบบเมลเข้าใจผิดว่าไลบรารีตรวจสอบสโคปให้แล้ว จึงไม่ได้เพิ่มการตรวจสอบ issuer/scope
- ข้อบกพร่องทั้งหมดได้รับการแก้ไขแล้ว และมีการเสริมการป้องกันหลายชั้นภายหลังเหตุการณ์ เช่น การทำคีย์สโคปวาลิเดชันแบบอัตโนมัติ
ที่มาของการได้คีย์
- Microsoft ดำเนินสภาพแวดล้อมโปรดักชันที่แยกกักและมีข้อจำกัด พร้อมการตรวจสอบประวัติ บัญชีเฉพาะ เครื่องเวิร์กสเตชันสำหรับการเข้าถึงอย่างปลอดภัย และ การยืนยันตัวตนหลายปัจจัย ที่ใช้ฮาร์ดแวร์โทเคน
- สภาพแวดล้อมนี้ปิดกั้นการใช้งานเครื่องมือทำงานร่วมกัน เช่น อีเมล การประชุม และการค้นคว้าบนเว็บ เพื่อป้องกันเส้นทางการยึดบัญชีอย่างมัลแวร์หรือฟิชชิง
- จำกัดการเข้าถึงระบบและข้อมูลด้วยนโยบาย Just in Time / Just Enough Access
- สภาพแวดล้อมองค์กร (corporate environment) แม้จะต้องใช้การรับรองความปลอดภัยและอุปกรณ์ความปลอดภัย แต่อนุญาตให้ใช้อีเมล การประชุม และเครื่องมือทำงานร่วมกันได้ จึงเสี่ยงต่อ spear phishing และมัลแวร์ขโมยโทเคน
- ตามหลัก Zero-Trust และ "assume breach" ข้อมูลคีย์ ไม่ควรออกนอกสภาพแวดล้อมโปรดักชัน
- ในเดือนเมษายน 2021 ระบบลงนามฝั่ง consumer ล่ม ทำให้เกิด crash dump (สแนปช็อตของโปรเซสที่ล่ม)
- crash dump ควรไม่รวม signing key เพราะมีการมาสก์ข้อมูลอ่อนไหวไว้ แต่มีคีย์รวมอยู่เนื่องจาก race condition (แก้ไขแล้ว)
- ระบบตรวจไม่พบว่ามีคีย์อยู่ใน crash dump (แก้ไขแล้ว)
- crash dump ที่ในเวลานั้นเชื่อว่าไม่มีคีย์ ถูกย้ายจากเครือข่ายโปรดักชันที่แยกกักไปยัง สภาพแวดล้อมสำหรับดีบัก
- เป็นไปตามขั้นตอนการดีบักมาตรฐาน และการสแกนข้อมูลรับรองไม่สามารถตรวจพบการมีอยู่ของคีย์ได้ (แก้ไขแล้ว)
- หลังคีย์รั่วไหล ผู้ไม่หวังดี Storm-0558 ได้เจาะ บัญชีองค์กร ของวิศวกร Microsoft
- บัญชีนั้นมีสิทธิ์เข้าถึงสภาพแวดล้อมสำหรับดีบักที่มี crash dump ซึ่งรวมคีย์ไว้
- ตามนโยบายการเก็บรักษา log ไม่มี log หลักฐานการรั่วไหลแบบเฉพาะเจาะจง แต่เส้นทางนี้เป็นความเป็นไปได้สูงสุดของการได้คีย์
สาเหตุที่คีย์ฝั่ง consumer ใช้เข้าถึงเมลองค์กรได้
- เพื่อตอบสนองความต้องการของลูกค้าที่ต้องการรองรับทั้งแอปพลิเคชันฝั่ง consumer และ enterprise จึงมีการนำ common key metadata publishing endpoint มาใช้ในเดือนกันยายน 2018
- พร้อมอัปเดตเอกสารให้ชัดเจนเรื่องข้อกำหนดการตรวจสอบคีย์สโคปแยกตามบัญชี enterprise และ consumer ในการให้บริการแบบรวม
- มี API สำหรับตรวจสอบลายเซ็นทางคริปโตกราฟี แต่ไม่ได้อัปเดตให้ไลบรารีทำ การตรวจสอบสโคป โดยอัตโนมัติ (แก้ไขแล้ว)
- ระบบเมลอัปเดตในปี 2022 ให้ใช้ common metadata endpoint
- นักพัฒนาระบบเมลเข้าใจผิดว่าไลบรารีทำการตรวจสอบครบถ้วนแล้ว จึงไม่ได้เพิ่ม การตรวจสอบ issuer/scope ที่จำเป็น
- ส่งผลให้ระบบเมลยอมรับคำขอเมลองค์กรที่ใช้ security token ซึ่งลงนามด้วยคีย์ฝั่ง consumer (แก้ไขแล้วด้วยไลบรารีเวอร์ชันอัปเดต)
การทบทวนหลังเหตุการณ์และมาตรการปรับปรุง
- ระบุและแก้ไข race condition ที่ทำให้ signing key ถูกรวมอยู่ใน crash dump
- เสริมการป้องกัน การตรวจจับ และการตอบสนอง กรณีที่ข้อมูลคีย์ถูกรวมใน crash dump อย่างไม่ถูกต้อง
- ปรับปรุง การสแกนข้อมูลรับรอง ให้ตรวจจับการมีอยู่ของ signing key ในสภาพแวดล้อมสำหรับดีบักได้ดีขึ้น
- เผยแพร่ไลบรารีที่ปรับปรุงแล้วเพื่อทำการตรวจสอบคีย์สโคปอัตโนมัติใน authentication library และทำเอกสารที่เกี่ยวข้องให้ชัดเจนขึ้น
อัปเดตเพิ่มเติมวันที่ 12 มีนาคม 2024
- ยังคงยึด สมมติฐานหลัก ว่าเกิดข้อผิดพลาดเชิงปฏิบัติการทำให้ข้อมูลคีย์ออกจากสภาพแวดล้อมการลงนาม security token และถูกเข้าถึงในสภาพแวดล้อมสำหรับดีบักผ่านบัญชีวิศวกรที่ถูกเจาะ โดยไม่มีการเปลี่ยนแปลงต่อผลกระทบต่อลูกค้า, Microsoft หรือกิจกรรมของผู้ไม่หวังดี
- แม้เคยระบุว่า crash dump ปี 2021 อาจเป็นสาเหตุที่ผู้ไม่หวังดีเข้าถึงได้ แต่ ไม่พบ crash dump ที่มีข้อมูลคีย์ที่ได้รับผลกระทบ
- race condition ที่กล่าวถึงนั้นไม่ได้มีผลต่อการมีหรือไม่มีคีย์อยู่ใน crash dump แต่มีผลต่อว่า crash dump จะสามารถ ถูกนำออก จากสภาพแวดล้อมการลงนามที่ปลอดภัยได้หรือไม่
- ข้อความที่ว่า การนำ crash dump ออกเป็นไปตามขั้นตอนการดีบักมาตรฐาน หมายถึงในอดีตไม่ได้ถูกห้ามไว้ และปัจจุบันขั้นตอนการดีบักมาตรฐานของ Microsoft ห้ามนำข้อมูลดังกล่าวออกจากสภาพแวดล้อมโปรดักชัน
- การสืบสวนที่ยังดำเนินอยู่เผยให้เห็น ข้อจำกัดของเทคโนโลยีการสแกนข้อมูลรับรอง และจะดำเนินการแก้ไขเมื่อค้นพบเพิ่มเติม
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ดูเหมือนว่ายังมีจิ๊กซอว์ที่ขาดหายไป: เข้าใจได้ไม่ยากว่าบั๊กด้าน concurrency หรือบั๊กด้าน memory safety อาจทำให้คีย์ส่วนตัวหลุดเข้าไปอยู่ในผลลัพธ์การดีบักโดยบังเอิญ แต่ผู้โจมตีต้องรู้ถึง ข้อเท็จจริงที่ว่าเกิดแครช รู้โครงสร้างของ crash dump และต้องรออยู่ภายในเครือข่ายภายในของ Microsoft ไม่ใช่หรือ
การป้องกันบนสมมติฐานว่าถูกเจาะแล้ว เป็นกลยุทธ์ความปลอดภัยเครือข่ายที่ดี แต่ไม่ควรยอมรับสมมติฐานว่าถูกเจาะจริง ๆ ไปเฉย ๆ
ข้อมูลแบบนี้มักไม่ได้ถูกเก็บอย่างปลอดภัยเท่ากับมูลค่าจริงของมัน จากประสบการณ์ที่เคยทำงานใน FAANG เด็กใหม่แทบทุกคนที่ไม่มีประสบการณ์ด้านการเงินหรือกฎระเบียบองค์กรคิดว่าสามารถแนบข้อมูลแครชลงใน bug tracker ได้ ดังนั้นสิ่งอย่าง crash dump ควรถูกย้ายไปไว้ในตู้เซฟที่ใช้งานง่ายพอจนคนไม่อยากหาทางเลี่ยง และต้องเปลี่ยนนิสัยให้ทำแบบนั้น
ถ้ามีบัญชีวิศวกรที่ถูกเจาะ อย่างน้อยก็ควรถือว่ามีสิทธิ์เข้าถึง bug tracker และอาจได้หรือสร้าง debug symbols ของไบนารีได้ด้วย ที่เหลือก็แค่รอให้วิศวกรคนหนึ่งเผลออัปโหลด crash dump เป็นไฟล์แนบของบั๊ก แล้วรีบเอาไปก่อนที่จะมีใครสังเกตเห็นและลบออก
อีกอย่าง เครื่องมือสแกนข้อมูลรับรองของ Microsoft หา key ไม่เจอ และบอกว่าปัญหานั้นแก้แล้ว แสดงว่าคีย์น่าจะอยู่ในรูปแบบที่สแกนตรวจจับได้
โดยรวมแล้วดูเหมือนว่าวิศวกรย้าย dump ที่มีคีย์อยู่เข้าไปไว้ในบัญชีของตนเอง แล้วปล่อยทิ้งไว้พักหนึ่ง ต่อมาผู้โจมตีเจาะบัญชีนั้นและกวาดไฟล์ที่ใช้ได้ทั้งหมดไป จากนั้นสแกนหาคีย์ด้วยเครื่องมือที่ดีกว่าของ Microsoft แล้วก็แจ็กพอต
กล่าวคือผู้โจมตีอยู่ในเครือข่ายแล้วและไปพบ dump โดยบังเอิญระหว่างการสแกนที่ไม่ถูกตรวจพบ หรือไม่ก็เล็งบัญชีนี้โดยเฉพาะตั้งแต่แรก
ถึงอย่างนั้น จากมุมของผู้โจมตี เหตุการณ์ที่ต่อกันเป็นทอด ๆ ก็ยังดูโชคดีเกินไปที่ทุกอย่างลงล็อกพอดี
มีวิชา system engineering ที่พูดถึงกระบวนการที่ปัญหาเล็ก ๆ หลายอย่างเรียงต่อกันตามลำดับเฉพาะ จนสุดท้ายกลายเป็น ความล้มเหลวระดับหายนะ กรณีนี้นับได้ว่าเป็นความล้มเหลวระดับนั้น
ก่อนอื่นต้องมี race condition และ race condition นั้นต้องนำไปสู่ผลลัพธ์ที่คาดไม่ถึง หากโค้ดผ่านการทดสอบและถูกใช้งานบ่อย โอกาสเกิดตรงนี้อาจต่ำกว่า 10% แล้ว จากนั้นวิศวกรต้องตัดสินใจพอดีว่าต้องใช้ crash dump นี้ ซอฟต์แวร์สแกนข้อมูลรับรองต้องหา credential เฉพาะนี้ไม่เจอ บัญชีหนึ่งต้องถูกเจาะจนได้สิทธิ์เข้าถึงเครือข่าย ผู้ใช้นั้นต้องเข้าถึง dump ดังกล่าวได้ และแฮกเกอร์ต้องหาเจอและนำออกไป
ถึงอย่างนั้นคีย์ก็เก่าแล้ว และควรจะปลอดภัยเพราะใช้ได้เฉพาะกับการเข้าถึงบัญชีอีเมลผู้บริโภค แต่กลับยังมีบั๊กที่ยอมรับคีย์เก่า และบั๊กที่ไม่ปฏิเสธคีย์เซ็นนี้สำหรับโทเค็นบัญชีอีเมลองค์กรอีกด้วย
เป็นบทเรียน system engineering ที่ดี ต่อให้พยายามแค่ไหน สุดท้ายเมื่อสิ่งเล็ก ๆ สะสมมากพอ ก็เกิดอุบัติเหตุใหญ่ได้ ดังนั้นควรออกแบบให้ รัศมีผลกระทบ ถูกจำกัด แม้จะเกิดระเบิดขึ้นก็ตาม
การวิเคราะห์ภายหลังถูกนำเสนอเหมือนเป็นเหตุการณ์โชคร้ายที่เกิดซ้อนกันแบบสุ่ม ราวกับว่าผู้โจมตีบังเอิญเล็ง Microsoft บังเอิญมี race condition บังเอิญเกิดแครช และบังเอิญเจอ crash dump ที่ไหนสักแห่ง
แต่ควรพิจารณาด้วยว่าบั๊ก race condition ตั้งแต่แรกอาจถูกฝังไว้อย่างจงใจ แครชอาจถูกกระตุ้นโดยตั้งใจ ผู้โจมตีอาจรอให้ dump ปรากฏในตำแหน่งเฉพาะ และอาจมีผู้สมรู้ร่วมคิดก็ได้
ระบบนิเวศของ Microsoft ดูเหมือนรถเลโก้ที่เด็ก ๆ ในละแวกบ้านเอาชิ้นส่วนจากบ้านของแต่ละคนมาประกอบแบบลวก ๆ
พอเรียกว่า race condition คนก็บอกว่า “โอกาสเกิดต่ำกว่า 10%” แต่จริง ๆ แล้วมันอาจเกิดกับแครชใหญ่ทุกครั้ง เพียงแต่แครชไม่ได้เกิดบ่อยก็ได้
ทำไมถึงไม่ masking ก่อนเขียนลงดิสก์ มีแต่พระเจ้าที่รู้
โครงสร้างที่โลกธุรกิจตะวันตกมากกว่าครึ่งพึ่งพา Outlook.com นั้นใกล้เคียงกับสภาพที่ผิดปกติมาก แต่แรงจูงใจทางการเงินในปัจจุบันไม่ได้มุ่งไปทางการเพิ่มความยืดหยุ่นหรือการแยกสิ่งที่รวมศูนย์สูงอย่าง Outlook.com ออกเป็นส่วน ๆ ดังนั้นเรื่องแบบนี้ก็น่าจะเกิดขึ้นต่อไป
มีประเด็นที่ยังไม่ได้อธิบายให้ชัดเจน: ถ้าถูกตรวจพบเมื่อวันที่ 11 กรกฎาคม 2023 และสงสัยว่าเกิดขึ้นตั้งแต่เดือนเมษายน 2021 ก็หมายความว่าผู้โจมตีถือข้อมูลรับรองนี้อยู่นาน กว่า 2 ปี และใช้เวลา 2 เดือนตั้งแต่ตรวจพบจนถึงเปิดเผย
ยังขาดข้อมูลว่ามีโทเค็นปลอมกี่รายการ และเข้าถึงไปมากแค่ไหน หากไม่เปิดเผย ก็ย่อมทำให้คาดเดาไปในทางร้าย
ไม่มีไทม์ไลน์ตั้งแต่ตรวจพบจนถึงการแก้ไข มีเพียงคำว่า “ปัญหานี้ได้รับการแก้ไขแล้ว” เท่านั้น ก็ได้แต่หวังว่าจะแก้ได้อย่างรวดเร็ว
แม้จะแก้ปัญหาโดยตรง 4 จุดแล้ว แต่เห็นได้ชัดว่าดูเหมือนมีปัญหาเชิงระบบ และก็ไม่เห็นว่าจะทำอะไรกับเรื่องนั้น
https://en.m.wikipedia.org/wiki/Adverse_inference
การเจาะระบบแบบนี้ต้องอาศัยความเข้าใจโครงสร้างพื้นฐานภายในของ Microsoft อย่างลึกมาก มองว่าเป็นงานที่ทำเป็นระบบโดยทีมแฮ็กเกอร์น่าจะปลอดภัยกว่า
ไม่ใช่งานที่ทำได้ถูก ๆ แต่ผลตอบแทนมหาศาล การรวมศูนย์แบบสุดขั้ว ทำให้แฮ็กเกอร์ทุ่มความพยายามไปที่เป้าหมายมูลค่าสูงจำนวนน้อย เพราะถ้าสำเร็จก็ได้ผลตอบแทนมหาศาล
แทบมั่นใจได้ว่ามีทีมแฮ็กเกอร์ที่ได้รับการสนับสนุนจากรัฐซึ่งกำลังศึกษาและวิเคราะห์โครงสร้างพื้นฐานภายในของที่อย่าง Google, Microsoft, Amazon อย่างลึกอยู่แล้ว การเจาะระบบครั้งนี้แสดงให้เห็นว่าพวกเขาเข้าใจมันดีแค่ไหนแล้ว
คิดว่าถึงเวลาต้องกระจายศูนย์ภายในขอบเขตความปลอดภัยที่กว้างขึ้นแล้ว
ถ้าตัดถ้อยคำระมัดระวังออกไป ก็คือมีใครบางคนดาวน์โหลด มินิดัมป์ จากสภาพแวดล้อมการผลิตลงมายังเวิร์กสเตชันของนักพัฒนา และมันก็คงหมักอยู่ที่ไหนสักแห่งใน OneDrive ภายในบริษัทของนักพัฒนาคนนั้น จนบัญชีถูกเจาะ มีคนเอาดัมป์ไป ค้นพบคีย์ แล้วก็ได้แจ็กพอต
คำอธิบายว่า “มีบั๊กคลุมเครือไม่กี่จุดที่ถูกใช้ประโยชน์อย่างซับซ้อน” ดูจะไม่ตรงนัก มันดูใกล้เคียงกับ ละครลูกโซ่ของความผิดพลาด ที่ไม่มีระบบความปลอดภัยใดทำหน้าที่ของตัวเองได้เลยมากกว่า
ไม่เข้าใจว่าทำไมไม่ใช้ HSM จุดประสงค์หลักของฮาร์ดแวร์แบบนั้นคือ การป้องกันการรั่วไหลของวัสดุคีย์ ไม่ใช่หรือ
[1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
นี่หมายความว่าคีย์ไม่ได้ถูกเก็บไว้ในฮาร์ดแวร์ที่ไม่สามารถกู้คืนได้ แต่โปรเซสเซิร์ฟเวอร์ทั่วไปซึ่งเป็นโค้ดที่คอมไพล์แล้วและรันอยู่ในสภาพแวดล้อมที่มีสิทธิ์สูงสามารถเข้าถึงได้
ไม่มีการกล่าวด้วยว่าระบบที่เข้าถึงคีย์นี้ได้อยู่ในสภาพแวดล้อมแยกต่างหาก ไม่ใช่สภาพแวดล้อมปฏิบัติการทั่วไป ดังนั้นจึงสันนิษฐานได้ว่าเครื่องปฏิบัติการใด ๆ ก็เข้าถึงคีย์ได้ และใครก็ตามที่เข้าถึงสภาพแวดล้อมนั้นได้ก็อาจ ทำให้วัสดุคีย์รั่วไหล ได้
เมื่อดูส่วนการตรวจสอบความถูกต้องใน https://learn.microsoft.com/en-us/azure/active-directory/dev... ถ้าผมไม่ได้พลาดอะไรไป ดูเหมือนว่ายังขาดความสำคัญของการตรวจสอบวันที่ของผู้ออกหรือสถานะการเพิกถอนอยู่
ใน pseudocode ก็ไม่มี ดังนั้นจึงมีความเป็นไปได้สูงว่าจะยังมีการใช้งานที่เชื่อถือคีย์ใด ๆ ก็ตามที่ Microsoft เคยเผยแพร่ไว้ เว้นแต่กรณีพิเศษอย่างการลบแคช
ถ้าแม้แต่ Microsoft ยังใช้ แพลตฟอร์มตัวตน ของตัวเองกับผลิตภัณฑ์เรือธงอย่าง Outlook ไม่ถูกต้อง แล้วคนอื่นจะมีโอกาสแค่ไหน
พวกเขาเพียงตรวจสอบว่า Microsoft CA เซ็นไว้หรือไม่เท่านั้น นี่เป็นปัญหาที่ควรเห็นได้ชัดอย่างไม่น่าเชื่อในการรีวิวโค้ด
หนึ่งในเหตุผลที่โดนหนักจริง ๆ ดูเหมือนจะเป็นเพราะ ไม่ได้หมุนเวียนคีย์ ฟังดูเหมือนมีช่วงเวลาค่อนข้างนานระหว่างตอนที่คีย์ถูกย้ายไปยังที่ที่ไม่ควรอยู่ กับตอนที่ถูกขโมยจริง
ถ้าหมุนเวียนคีย์บ่อย ๆ การปลอมโทเค็นด้วยคีย์นั้นก็คงเป็นไปไม่ได้
รู้สึกแบบนี้ทุกครั้งที่เห็นบทความลักษณะนี้ออกมา แต่โครงสร้างที่ปล่อยให้บริษัทเอกชนเป็นฝ่ายรับมือกับ การโจมตีระดับรัฐ เพียงเพราะการโจมตีไม่ได้เป็นทางกายภาพแต่เป็นดิจิทัลนั้น ดูแปลกมากจริง ๆ
ถ้าเครื่องบินรบจีนยิงเครื่องบิน FedEx ตกเหนือน่านฟ้ามหาสมุทรแปซิฟิก เรื่องนั้นคงถูกมองว่าเป็นการโจมตีอธิปไตยของสหรัฐฯ และรัฐบาลก็คงตอบโต้ตามสมควร คงไม่มีใครคาดหวังให้ FedEx ต้องมีฝูงบินขับไล่ของตัวเองเพื่อปกป้องเครื่องบินขนส่งของตน และก็คงไม่มีใครพูดว่า “เป็นความผิดของ FedEx เองที่ไม่ได้ป้องกันภัยทางอากาศให้ดี”
แต่พอเข้ามาอยู่ในโลกดิจิทัล กลับกลายเป็นบรรยากาศที่ยอมรับกันว่า Microsoft ต้องป้องกันตัวเองจากจีนและรัสเซีย
รัฐบาลต่าง ๆ จับกุมสายลับต่างชาติค่อนข้างสม่ำเสมอ แต่การจับกุมแบบนั้นไม่ได้ลุกลามไปเป็นสงครามเต็มรูปแบบ
ประการที่สอง สหรัฐฯ เองก็ทำเรื่องแบบนี้อยู่ตลอด และทำกับประเทศพันธมิตรด้วย จึงยากที่จะอ้างความชอบธรรมสำหรับมาตรการที่รุนแรงกว่านี้
ขอบเขตและปริมาณของการโจมตีไซเบอร์นั้นใหญ่มาก แต่เข้าใจว่าสหรัฐฯ เองก็ทำการโจมตีภายนอกประเทศในระดับที่สอดคล้องกันอยู่มากเช่นกัน