- เหตุการณ์ Storm-0558 เป็นที่รู้จักในฐานะการเจาะ Exchange Online และ Outlook.com แต่มีการวิเคราะห์ว่า คีย์ลงนาม MSA ที่ถูกเจาะยังอาจถูกนำไปใช้ปลอมแปลงโทเค็น OpenID v2.0 ของแอปพลิเคชัน Azure AD ได้ด้วย
- ขอบเขตผลกระทบที่อาจเกิดขึ้นขยายไปถึงแอป Microsoft ที่ใช้การยืนยันตัวตนด้วยบัญชี Microsoft ส่วนบุคคล, แอปลูกค้าที่รองรับ “Login with Microsoft” และ แอปแบบมัลติเทแนนต์ ภายใต้เงื่อนไขบางอย่าง
- คีย์สาธารณะที่เป็นปัญหาอยู่ในรายการคีย์ Microsoft OpenID อย่างน้อยตั้งแต่ปี 2016 และถูกเปลี่ยนระหว่างวันที่ 27 มิถุนายน~5 กรกฎาคม 2023 โดยตรงกับ acquired signing key และ thumbprint ที่ Microsoft เปิดเผย
- Microsoft เพิกถอนคีย์แล้วจึงป้องกันโทเค็นปลอมใหม่ได้ แต่แอปที่ยังเชื่อถือเซสชันที่สร้างก่อนการเพิกถอนคีย์ หรือยังเชื่อถือแคชคีย์สาธารณะเก่า จำเป็นต้องตรวจสอบเพิ่มเติม
- โทเค็นปลอมสามารถสร้างแบบออฟไลน์ได้ จึงไม่ทิ้งร่องรอยการออกโทเค็นในพอร์ทัล Azure และหากไม่มีโทเค็นดิบหรือบันทึก
kidการ ยืนยันการถูกเจาะทำได้ยากมาก
ขอบเขตผลกระทบที่เกินกว่า Exchange Online
- Microsoft และ CISA เปิดเผยเหตุการณ์ความปลอดภัยที่ส่งผลกระทบต่อลูกค้าหลายรายของ Exchange Online และ Outlook.com
- ตามข้อมูลของ Microsoft ผู้ก่อภัยคุกคามที่ถูกระบุว่าเกี่ยวข้องกับจีนชื่อ Storm-0558 ได้คีย์เข้ารหัสส่วนตัวซึ่งเป็นคีย์ MSA ไป และปลอมแปลง access token สำหรับ Outlook Web Access และ Outlook.com
- มีรายงานว่าผู้ก่อภัยคุกคามยังใช้ประโยชน์จากปัญหาความปลอดภัยสองรายการในกระบวนการตรวจสอบโทเค็นของ Microsoft ร่วมด้วย
- จากการวิเคราะห์ของ Wiz Research คีย์ที่ถูกเจาะไม่ได้จำกัดอยู่เพียง Outlook.com และ Exchange Online แต่ยังสามารถใช้ปลอมแปลง access token สำหรับแอปพลิเคชัน Azure Active Directory หลายรายการได้ด้วย
- แอปพลิเคชันที่รองรับการยืนยันตัวตนด้วยบัญชีส่วนบุคคล
- แอปพลิเคชันที่ Microsoft จัดการ เช่น SharePoint, Teams, OneDrive
- แอปพลิเคชันของลูกค้าที่รองรับ “Login with Microsoft”
- แอปพลิเคชันแบบมัลติเทแนนต์ภายใต้เงื่อนไขบางอย่าง
ยืนยันคีย์ที่ถูกเจาะได้อย่างไร
- เมื่อวันที่ 11 กรกฎาคม 2023 Microsoft เปิดเผยว่าผู้ไม่หวังดีได้ MSA consumer signing key ไป ทำให้สามารถปลอมแปลง access token สำหรับบัญชี Exchange Online และ Outlook.com ได้
- Wiz ตรวจสอบ เอกสารทางการของ Microsoft สำหรับการตรวจสอบโทเค็น OpenID เพื่อระบุคีย์ที่สามารถลงนามโทเค็น OpenID สำหรับบัญชี Microsoft และแอปพลิเคชัน Azure Active Directory ได้
- ในขณะนั้น แอปพลิเคชัน Azure บัญชีส่วนบุคคล v2.0 พึ่งพา คีย์สาธารณะ 8 รายการ และแอปพลิเคชัน Azure แบบมัลติเทแนนต์ v2.0 ที่เปิดใช้บัญชี Microsoft พึ่งพา คีย์สาธารณะ 7 รายการ
- จากการตรวจสอบด้วย Internet Archive Wayback Machine พบว่าคีย์สาธารณะหนึ่งรายการที่อยู่ในรายการอย่างน้อยตั้งแต่ปี 2016 ถูกเปลี่ยนระหว่างวันที่ 27 มิถุนายน~5 กรกฎาคม 2023
- ช่วงเวลานี้ตรงกับเวลาการเปลี่ยนคีย์ที่ได้มา ซึ่ง Microsoft ระบุในบล็อก
- ใบรับรองคีย์สาธารณะเดิมออกเมื่อวันที่ 5 เมษายน 2016 และหมดอายุวันที่ 4 เมษายน 2021
- thumbprint ตรงกับค่าที่ Microsoft เปิดเผยในบล็อกล่าสุดว่าเป็น “Thumbprint of acquired signing key”
- คีย์ที่ Storm-0558 ได้ไปเป็นคีย์ส่วนตัวสำหรับ MSA tenant ของ Microsoft แต่จากการวิเคราะห์พบว่าสามารถลงนาม โทเค็น OpenID v2.0 สำหรับแอปพลิเคชัน Azure Active Directory หลายรายการได้ด้วย
เหตุใดการเจาะคีย์ลงนาม OpenID จึงอันตราย
- Azure identity platform เผยแพร่ รายการคีย์สาธารณะที่เชื่อถือได้ แตกต่างกันตามประเภทแอปพลิเคชัน และใช้รายการเหล่านี้เพื่อตรวจสอบความถูกต้องสมบูรณ์ของโทเค็นที่ Azure Active Directory ออกให้
- แอปพลิเคชัน AAD จะตรวจสอบลายเซ็นโทเค็นด้วยรายการคีย์สาธารณะที่ถูกต้อง แล้วตัดสินใจว่าจะเชื่อถือโทเค็นหรือไม่
- หากคีย์หนึ่งในรายการถูกเจาะ แอปพลิเคชันที่ตรวจสอบด้วยรายการนั้นอาจยอมรับ access token ปลอมเป็นโทเค็นที่ถูกต้องได้ภายใต้เงื่อนไขบางอย่าง
- ตามสิ่งที่ Wiz อนุมานจากบล็อกของ Microsoft ดูเหมือนว่า Storm-0558 ได้เข้าถึงคีย์หนึ่งในหลายคีย์ที่ใช้ลงนามและตรวจสอบ access token ของ AAD
- คีย์ที่ถูกเจาะได้รับความเชื่อถือสำหรับการลงนาม access token OpenID v2.0 ของบัญชีส่วนบุคคลและ mixed-audience กล่าวคือแอปพลิเคชัน AAD ที่เป็นเป้าหมายแบบมัลติเทแนนต์หรือบัญชีส่วนบุคคล
- ส่งผลให้ในเชิงทฤษฎี Storm-0558 สามารถปลอมแปลงโทเค็นที่ยืนยันตัวตนเป็นผู้ใช้ใดก็ได้ในแอปพลิเคชันที่ได้รับผลกระทบซึ่งเชื่อถือ Microsoft OpenID v2.0 mixed audience และใบรับรองบัญชีส่วนบุคคล
- คีย์ลงนามของ identity provider ถือได้ว่าเป็นความลับที่ทรงพลังกว่าคีย์ TLS
- แม้คีย์ TLS รั่วไหล ผู้โจมตียังต้องปลอมเป็นเซิร์ฟเวอร์นั้นเพื่อขยายผลกระทบ
- คีย์ identity provider สามารถใช้ปลอมแปลงโทเค็นที่เข้าถึงกล่องอีเมล บริการไฟล์ บัญชีคลาวด์ ฯลฯ ได้ในขั้นตอนเดียว
- ความเสี่ยงเดียวกันนี้ใช้ได้กับการรั่วไหลของคีย์ลงนามของ identity provider รายใหญ่ เช่น Google, Facebook, Okta ไม่ใช่แค่ Microsoft
ประเภทแอปพลิเคชันที่ได้รับผลกระทบ
- เป้าหมายที่ได้รับผลกระทบจำกัดอยู่ที่แอปพลิเคชัน Azure Active Directory ที่ใช้ OpenID v2.0 ของ Microsoft
- แอปพลิเคชัน v1.0 ไม่ได้รับผลกระทบ เพราะไม่ได้ใช้คีย์ที่ถูกเจาะในการตรวจสอบโทเค็น
-
แอปพลิเคชันที่รองรับเฉพาะบัญชี Microsoft ส่วนบุคคล
- แอปพลิเคชัน Azure Active Directory ที่ใช้โปรโตคอล Microsoft v2.0 และรองรับ “Personal Microsoft accounts only” ได้รับผลกระทบ
- รวมถึงแอปพลิเคชันที่ Microsoft จัดการ เช่น Outlook, SharePoint, OneDrive, Teams และแอปพลิเคชันลูกค้าที่รองรับการยืนยันตัวตนด้วย Microsoft Account
-
แอปพลิเคชันที่รองรับทั้งมัลติเทแนนต์และบัญชี Microsoft ส่วนบุคคล
- แอปพลิเคชัน Azure Active Directory ที่รองรับ “mixed audience” และใช้โปรโตคอล Microsoft v2.0 ก็ได้รับผลกระทบเช่นกัน
- ผู้ก่อภัยคุกคามสามารถปลอมแปลง access token ที่ถูกต้องเพื่อสวมรอยเป็นผู้ใช้แอปพลิเคชันที่ล็อกอินด้วยบัญชี Microsoft ส่วนบุคคลได้
- Microsoft นำส่วนขยายของโปรโตคอล OpenID มาใช้เพื่อจำกัดความสามารถของคีย์ MSA ในการสวมรอยบัญชีองค์กร
- นักพัฒนาต้องตรวจสอบ issuer claim โดยเปรียบเทียบกับฟิลด์ issuer ในรายการคีย์สาธารณะ OpenID
- การตรวจสอบนี้เป็นกลไกเพื่อป้องกันไม่ให้คีย์ MSA ลงนาม access token ที่มี issuer ซึ่งไม่ใช่ MSA tenant
- ส่วนขยายนี้เป็นของ Microsoft โดยเฉพาะ และความรับผิดชอบในการนำไปใช้เป็นของเจ้าของแอปพลิเคชัน
- Wiz มองว่าแอปพลิเคชันจำนวนมากอาจไม่มีขั้นตอนตรวจสอบนี้ และผลคืออาจยังมีความเป็นไปได้ในการสวมรอยบัญชีองค์กร
- ตามบล็อกของ Microsoft OWA ก็ได้รับผลกระทบจากปัญหาคล้ายกัน
- เมื่อวันที่ 12 กรกฎาคม Microsoft เพิ่มฟังก์ชันตรวจสอบนี้ลงใน Azure SDK อย่างเป็นทางการ
-
แอปพลิเคชันที่รองรับเฉพาะมัลติเทแนนต์
- แอปพลิเคชันแบบมัลติเทแนนต์ได้รับผลกระทบ หากถูกตั้งค่าให้พึ่งพา endpoint คีย์ v2.0 แบบ common แทน “Organizations”
- การตั้งค่าเช่นนี้ควรถูกมองว่าเป็นการตั้งค่าผิดพลาด
- เอกสารทางการ ของ Microsoft ไม่ได้ระบุชัดเจนว่าควรใช้ endpoint “common” เมื่อใด จึงเป็นไปได้ว่าแอปพลิเคชันมัลติเทแนนต์บางส่วนอาจได้รับผลกระทบด้วย
-
แอปพลิเคชันซิงเกิลเทแนนต์
- แอปพลิเคชันซิงเกิลเทแนนต์ ที่รองรับ “เฉพาะบัญชีในไดเรกทอรีองค์กรนี้” ไม่ได้รับผลกระทบ
เงื่อนไขที่ทำให้การปลอมแปลงโทเค็นสำเร็จ
- ในการตรวจสอบโทเค็น OpenID นักพัฒนาแอปพลิเคชันต้องตรวจสอบว่าโทเค็นถูกลงนามด้วยคีย์ส่วนตัวที่มีสิทธิ์สำหรับขอบเขตที่ตั้งใจไว้หรือไม่ และฟิลด์
audตรงกับขอบเขตของแอปพลิเคชันเป้าหมายหรือไม่ - แอปพลิเคชันจะตรวจสอบโทเค็นโดยดึงใบรับรองที่อนุญาตสำหรับการตรวจสอบลายเซ็นจาก metadata endpoint ที่เรียกว่า
jwks_uri - ผู้ก่อภัยคุกคามสามารถสร้างโทเค็น JWT ใส่ข้อมูลอย่างที่อยู่อีเมลของเหยื่อ แล้วลงนามด้วยคีย์ที่ถูกเจาะซึ่งลงทะเบียนอยู่ใน endpoint ใบรับรองสาธารณะของ Azure Active Directory เพื่อปลอมแปลง access token ที่ถูกต้อง
kidของคีย์ที่ถูกเจาะซึ่งถูกกล่าวถึงเป็นตัวอย่างคือ1LTMzakihiRla_8z2BEJVXeWMqo- ตามแนวทางของ Microsoft เพื่อให้โทเค็นถูกต้อง
issclaim ต้องเป็น issuer ของ MSA tenant ที่ระบุในฟิลด์ issuer ของ endpointjwks_uriและtidclaim ก็ต้องเป็น MSA tenant ID คือ9188040d-6c67-4c5b-b112-36a304b66dad - ในแอปพลิเคชัน AAD แบบ mixed-audience หากเป็นการสวมรอยบัญชีส่วนบุคคล โทเค็นที่ MSA tenant ลงนามสำหรับบัญชี Azure AD อาจถูกมองว่าถูกต้องได้
- รายละเอียดการตรวจสอบ ID Token ดูได้ใน แนวทางอย่างเป็นทางการ ของ Microsoft
ความเสี่ยงที่ยังเหลือหลังการเพิกถอนคีย์
- เนื่องจาก Microsoft เพิกถอนคีย์ที่ถูกเจาะแล้ว แอปพลิเคชัน Azure Active Directory จึงจะไม่ยอมรับโทเค็นที่ปลอมด้วยคีย์ดังกล่าวเป็นโทเค็นที่ถูกต้องอีกต่อไป
- โทเค็นที่ตั้งเวลาออกอายุไว้ยาวก็จะถูกปฏิเสธโดยแอปพลิเคชัน
- อย่างไรก็ตาม หากมีการสร้างเซสชันในแอปพลิเคชันของลูกค้าก่อนการเพิกถอนคีย์ ผู้ก่อภัยคุกคามอาจใช้สิทธิ์ของแอปพลิเคชันเพื่อสร้าง persistence ไว้แล้ว
- การออก access key เฉพาะแอปพลิเคชัน
- การตั้งค่า backdoor เฉพาะแอปพลิเคชัน
- กรณีที่ Storm-0558 ปลอม access token สำหรับ OWA ก่อนมาตรการของ Microsoft และออก access token ของ Exchange Online ที่ถูกต้อง
- แอปพลิเคชันที่เก็บสำเนาคีย์สาธารณะ AAD ก่อนการเพิกถอนใบรับรองของ Microsoft ก็อาจมีความเสี่ยงเช่นกัน
- หากใช้ที่เก็บใบรับรองภายในเครื่องหรือคีย์ที่แคชไว้ และยังเชื่อถือคีย์ที่ถูกเจาะอยู่ ก็จะเสี่ยงต่อการปลอมแปลงโทเค็น
- Microsoft แนะนำให้รีเฟรชที่เก็บภายในเครื่องและแคชใบรับรองอย่างน้อยวันละครั้ง
สิ่งที่ผู้ใช้ Azure ควรตรวจสอบ
- หากต้องการตรวจสอบว่ามีการใช้คีย์ที่ถูกเจาะในสภาพแวดล้อมหรือไม่ ต้องระบุแอปพลิเคชันที่อาจได้รับผลกระทบ ค้นหาร่องรอยการใช้โทเค็นปลอม และใช้ Indicators of Compromise ที่ Microsoft เปิดเผยเพื่อตรวจสอบกิจกรรม IP ที่เกี่ยวข้อง
- หากมีแอปพลิเคชันที่แคชใบรับรองสาธารณะ Microsoft OpenID ควรรีเฟรชแคช
- Microsoft เพิ่มการตรวจสอบเพิ่มเติมเพื่อป้องกันการยืนยันตัวตนเป็นบัญชีองค์กรด้วยคีย์ MSA ลงใน Azure SDK อย่างเป็นทางการแล้ว ผู้ใช้แพ็กเกจดังกล่าวควรอัปเดตเป็น เวอร์ชันล่าสุด
เหตุใดจึงตรวจจับได้ยาก
- ผู้ก่อภัยคุกคามสามารถปลอมแปลง access token แบบออฟไลน์ได้ ดังนั้นในพอร์ทัล Azure จึงไม่เหลือ ร่องรอยการออกโทเค็น
- หากลูกค้าคลาวด์ต้องการตรวจสอบว่ามีการใช้คีย์หรือไม่ ต้องทบทวนล็อกเฉพาะแอปพลิเคชันของแอปพลิเคชัน AAD ที่อาจได้รับผลกระทบ
- เป้าหมายที่ Wiz ระบุว่าได้รับผลกระทบคือแอปพลิเคชันที่ใช้ endpoint ต่อไปนี้ในการตรวจสอบ access token Microsoft v2.0
- แอปพลิเคชัน AAD ที่อาจได้รับผลกระทบสามารถระบุได้ด้วย Azure CLI โดยค้นหาแอปที่มี
signinaudienceเป็นAzureADMultipleOrgs,AzureADandPersonalMicrosoftAccount,PersonalMicrosoftAccount - แอป AAD ที่รีไดเรกต์ไปยัง Azure WebApps ก็สามารถค้นหาได้ด้วยคำสั่ง CLI แยกต่างหาก
- หากถอดรหัส access token ที่ใช้ในแอปพลิเคชัน แล้วตรวจว่าฟิลด์
kidใน JOSE Header มีสตริง1LTMzakihiRla_8z2BEJVXeWMqoหรือไม่ จะพบโทเค็นที่ลงนามด้วยคีย์ที่ถูกเจาะได้ - ตามข้อมูลของ Microsoft คีย์ที่ถูกเจาะอยู่ในสถานะไม่ใช้งาน ดังนั้น access token ทุกตัวที่ลงนามด้วยคีย์นี้ควรถูกมองว่าน่าสงสัย
- การทำ logging แยกตามแอปพลิเคชันยังขาดแนวปฏิบัติที่เป็นมาตรฐาน
- เจ้าของแอปพลิเคชันจำนวนมากไม่มีล็อกละเอียดที่มี access token ดิบหรือคีย์ลงนาม
- ด้วยเหตุนี้ การระบุเหตุการณ์และการสืบสวนอาจทำได้ยากมาก
- ในแอปพลิเคชัน AAD เฉพาะมัลติเทแนนต์ที่ไม่รองรับบัญชี Microsoft ส่วนบุคคล สามารถตรวจจับโทเค็นปลอมได้จาก
issและtidclaim- ความพยายามเชื่อมต่อด้วย access token ที่ลงนามโดย MSA tenant ID
9188040d-6c67-4c5b-b112-36a304b66dadอาจบ่งชี้ถึงการใช้คีย์ที่ถูกเจาะ
- ความพยายามเชื่อมต่อด้วย access token ที่ลงนามโดย MSA tenant ID
- หากเปิดใช้ HTTP Logs ใน WebApp สามารถใช้ Log Analytics ตรวจสอบได้ว่าที่อยู่ IP ที่เกี่ยวข้องกับผู้ก่อภัยคุกคามซึ่งระบุในบล็อกของ Microsoft เข้าถึงแอปพลิเคชันหรือไม่
คำถามที่ยังเหลือและข้อสรุปเชิงปฏิบัติ
- ผลกระทบโดยรวมใหญ่กว่าที่ทราบในตอนแรกอย่างมาก และอาจส่งผลระยะยาวต่อความเชื่อมั่นในคลาวด์ โดยเฉพาะ identity layer ซึ่งเป็นองค์ประกอบพื้นฐานของคลาวด์
- แอปพลิเคชันที่อาจเคยมีช่องโหว่มีจำนวนหลายล้านรายการ รวมทั้งแอปของ Microsoft และแอปลูกค้า และจำนวนมากไม่มีล็อกเพียงพอที่จะตัดสินได้ว่าถูกเจาะหรือไม่
- เจ้าของแอปพลิเคชันควรอัปเดต Azure SDK เป็นเวอร์ชันล่าสุด และตรวจสอบก่อนว่าแคชของแอปพลิเคชันได้รับการรีเฟรชแล้วหรือไม่
- แอปพลิเคชันที่ยังไม่ได้อัปเดตแคชอาจยังคงมีช่องโหว่ต่อผู้ก่อภัยคุกคามที่ใช้คีย์ที่ถูกเจาะ
- เรื่องนี้ยังอยู่ระหว่างการสอบสวน และจากข้อมูลที่เปิดเผยในขณะนี้ ยังตอบได้ยากว่าผู้ก่อภัยคุกคามได้คีย์มาอย่างไร เหตุการณ์เกิดขึ้นเมื่อใดอย่างแน่ชัด และมีคีย์อื่นถูกเจาะด้วยหรือไม่
1 ความคิดเห็น
ความเห็นจาก Hacker News
คีย์ลงนามของผู้ให้บริการตัวตน แทบจะเป็นความลับที่ทรงพลังที่สุดในยุคปัจจุบัน ตัวอย่างเช่น มันทรงพลังยิ่งกว่าคีย์ TLS มาก
ในหลายแง่มุมมันอยู่ในระดับเดียวกับคีย์ของหน่วยงานออกใบรับรอง (CA) และองค์กรที่ใช้บริการ Microsoft กับ Azure ควรประเมินผลกระทบที่อาจเกิดขึ้น
ดูเหมือนผู้คนจะลืมสุภาษิตเก่าว่า “อย่าใส่ไข่ทั้งหมดไว้ในตะกร้าใบเดียว” ไปแล้ว
ทำไมถึงเป็นโครงสร้างที่เซิร์ฟเวอร์หลักสิบ หลักร้อย หรืออาจหลักพัน แชร์คีย์เพียงไม่กี่ดอกกันอยู่
คีย์รากที่ใช้ HSM, คีย์กลางประจำดาต้าเซ็นเตอร์, คีย์ลงนามชั่วคราวประจำเซิร์ฟเวอร์, รายการเพิกถอนใบรับรอง อยู่ที่ไหน
ชวนให้สงสัยว่าในลักษณะการโจมตีแบบนี้ยังจะปกป้อง bearer token ให้ปลอดภัยได้จริงหรือไม่ หรือควรย้อนกลับไปใช้วิธีให้บริการต้นทางแสดงค่า nonce เพื่อดึง payload กลับมาอย่างปลอดภัย
เลยกลายเป็นว่ามีฟีเจอร์ที่ใช้งานได้ก็ต่อเมื่อเอาไข่มากองรวมกันไว้ที่เดียว
ผมเตรียมป๊อปคอร์นไว้รอวันที่ทุกอย่างพังหมดแล้ว และที่แน่ ๆ คือบริษัท จะไม่โทษตัวเอง
หมายถึงให้ไปใช้ผู้ให้บริการรายอื่นที่อาจจะไม่ทำคีย์หายงั้นหรือ
ตอนนี้เหมือนจะเหลือ บิ๊กเทคอยู่แค่ 4 เจ้า เท่านั้น
มีข้อสรุปว่า “ด้วยคีย์ MSA ที่ถูกเจาะ ผู้โจมตีน่าจะสามารถปลอม access token สำหรับแอปพลิเคชัน Azure Active Directory ได้หลายประเภท”
ซึ่งรวมถึง SharePoint, Teams, OneDrive, แอปพลิเคชันลูกค้าที่รองรับ “ลงชื่อเข้าใช้ด้วย Microsoft” และแอปพลิเคชันแบบหลายเทนเนนต์ภายใต้เงื่อนไขบางอย่าง รวมถึงแอปทุกตัวที่รองรับการยืนยันตัวตนด้วยบัญชีส่วนบุคคล
หวังว่าการที่ Microsoft เพิ่งเปลี่ยนชื่อ Azure AD เป็น Entra ID จะเป็นเรื่องบังเอิญ: https://devblogs.microsoft.com/identity/aad-rebrand/
เวลานึกถึงผลิตภัณฑ์ความปลอดภัย ผมไม่อยากนึกถึงผู้ขายที่ไม่ได้กันผู้ไม่หวังดีให้อยู่นอกระบบ แต่กลับ “พาคนเข้ามา” ข้างใน เพราะ entra มาจาก entrar ที่แปลว่าเข้าไป/เข้ามา /s
ในภาษาสเปนมันยังเป็นรูปคำสั่งด้วย ให้ความรู้สึกเหมือนกำลังสั่งใครสักคนว่า “เข้ามา!”
“ใบรับรองของคีย์สาธารณะที่เปิดเผยไว้ก่อนหน้านี้ออกให้เมื่อ 5 เมษายน 2016 และหมดอายุเมื่อ 4 เมษายน 2021 โดยลายนิ้วมือของมันตรงกับลายนิ้วมือของคีย์ที่ Microsoft โพสต์ไว้ในบล็อกล่าสุดว่าเป็น ‘ลายนิ้วมือของคีย์สำหรับการลงนามที่ถูกได้มา’”
ถ้าอ่านถูกต้อง นี่หมายความว่า คีย์หมดอายุไปแล้วแต่ก็ยังถูกใช้งานต่อ อย่างนั้นหรือ?
เลยสงสัยว่ามีใครรู้ไหมว่า Microsoft ใช้คีย์เหล่านี้ที่ไหน และใช้วิธีแบบใด
แบบหนึ่งคือวิธีตรวจสอบ TLS ซึ่งเมื่อ
CnถูกลงนามโดยCn-1แล้วต่อเนื่องไปจนถึงC0จะตรวจสอบสายโซ่ใบรับรองโดยคร่าว ๆ แบบนี้1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 return NOT_EXPIRED
คือจะตรวจสอบวันหมดอายุของใบรับรองแต่ละใบเทียบกับเวลาปัจจุบัน
อีกแบบหนึ่งคือวิธีที่ใช้กับการลงนามโค้ด ซึ่งโดยคร่าว ๆ เป็นแบบนี้
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
Cnจะถูกตรวจเทียบกับเวลาปัจจุบัน ส่วนที่เหลือจะตรวจเทียบกับเวลาที่ใบรับรองถัดลงมาถูกลงนามเข้าใจได้ว่าทำไมการลงนามโค้ดถึงทำงานแบบนั้น เพราะโดยแก่นแล้วมันคือการรับรองเอกสารแบบดิจิทัล จึงไม่ควรเป็นว่าถ้าผู้รับรองหมดคุณสมบัติหรือใบอนุญาตหมดอายุในภายหลัง เอกสารที่เคยรับรองไว้แล้วจะกลายเป็นไม่ได้รับรองไปด้วย
และตอนที่บอกว่า “เนื่องจากมีปัญหาในการตรวจสอบ คีย์นี้จึงอาจได้รับความเชื่อถือสำหรับการลงนามโทเค็น Azure AD” ก็น่าจะต้องพูดว่า “เนื่องจากมีปัญหาในการตรวจสอบหลายจุด คีย์นี้จึงอาจได้รับความเชื่อถือสำหรับการลงนามโทเค็น Azure AD”
แล้วตอนที่บอกว่า “ผู้กระทำการมีความเข้าใจดีเกี่ยวกับสภาพแวดล้อมเป้าหมาย นโยบายการบันทึกล็อก ข้อกำหนดด้านการยืนยันตัวตน รวมถึงนโยบายและขั้นตอนต่าง ๆ” ก็สู้พูดแบบนี้น่าจะดีกว่า
“ผู้กระทำการอาจแค่หวังจะฉกฉวยแล้วหนีอย่างหน้าด้าน ๆ และไม่สนใจเรื่องจุกจิกอย่างนโยบายเลยแม้แต่วินาทีเดียว หรือไม่ก็ผู้กระทำการอาจไม่มีความชำนาญ จนไม่รู้ด้วยซ้ำว่ากระทรวงการต่างประเทศสหรัฐฯ จ่ายเงินให้เรามากกว่านี้มากเพื่อสิทธิพิเศษในการบันทึกเหตุการณ์การเข้าถึงกล่องจดหมายอย่างละเอียด Boeing เหมือนจะให้คำใบ้เรื่องนี้ผ่าน MCAS แล้ว แถมผู้กระทำการยังดูเหมือนมองข้ามไปว่า Chrome 92 ได้รับการอัปเดตครั้งสุดท้ายในปี 2021 และเป็นการเลือก user agent ที่แย่มากสำหรับการโจมตีระบบ ICT ของหน่วยงานรัฐบาลสหรัฐฯ ที่ควรใช้เบราว์เซอร์รุ่นล่าสุด อีกทั้งดูเหมือนแทบไม่รู้อะไรเลยเกี่ยวกับวิธีเข้าถึงกล่องจดหมายของกระทรวงการต่างประเทศสหรัฐฯ และน่าจะใช้ดาต้าเซ็นเตอร์สาธารณะแบบสุ่มทั่วทวีปยุโรปในการเดาแบบแย่ ๆ”
[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
[2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
[3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...
มีความเป็นไปได้ต่ำมากที่คีย์นี้จะอยู่ใน HSM
ทุกครั้งที่เห็นข่าวว่าคีย์ที่ดูเหมือนควรอยู่ใน HSM ถูกขโมยไป ก็ยังรู้สึกประหลาดใจอยู่เสมอ
ไม่นานมานี้มีโอกาสสร้างเครื่องมือที่น่าจะเหมาะที่สุดเพื่อเชื่อมช่องว่างระหว่าง toolchain สมัยใหม่กับ hardware security enclave: https://keymux.com
ต่อให้คำนึงถึงขนาดของ Azure AD ก็อาจเป็นไปได้ว่า Microsoft ไม่จำเป็นต้องใช้ HSM จำนวนมากนักสำหรับงานลงนาม
แต่ HSM ก็ไม่ได้จัดการได้ง่ายเป็นพิเศษ ซึ่งอาจเป็นหนึ่งในเหตุผลที่ทำให้มันไม่ได้ถูกใช้อย่างแพร่หลายเท่าที่ควร
[1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
อย่างแรก Microsoft อาจนำคีย์สำหรับลงนาม JWT ขึ้นไปไว้ในหน่วยความจำเพื่อใช้งาน และผู้โจมตีอาจได้คีย์ไปจากการแทรกโค้ดหรือการเข้าถึงภาพหน่วยความจำของโปรเซสนั้น
อย่างที่สอง Microsoft อาจใช้ HSM จริง แต่จำเป็นต้องกระจายคีย์ในเชิงภูมิศาสตร์ และผู้โจมตีอาจเข้าถึงคีย์ได้ระหว่างกระบวนการนั้น
แบบแรกดูมีความเป็นไปได้มากกว่า แต่แบบที่สองก็ยังตัดทิ้งไม่ได้
ควรทำให้การที่ FAANG ทำ สงครามไซเบอร์/จารกรรม ใส่กันเองเป็นเรื่องถูกกฎหมายหรือเปล่า?
อย่างน้อยก็น่าจะทำให้พวกเขาต้องไปให้ถึงระดับแนวปฏิบัติด้านความปลอดภัยขั้นต่ำ แทนที่จะอาศัยความคลุมเครือ
ตราบใดที่ไม่ก่อให้เกิดความเสียหายจริงหรือดาวน์โหลดข้อมูลลูกค้าจริง และเปิดเผยสิ่งที่พบ ก็ถือว่าถูกกฎหมายอยู่แล้ว
Satya คงต้องพูดคำว่า AI ให้บ่อยกว่านี้มากในการประกาศผลประกอบการครั้งหน้า ถ้าจะกลบความเละเทะครั้งนี้
ยากจะจินตนาการถึงการเจาะระบบที่แย่ไปกว่าการที่อำนาจต่างชาติเข้าไปถึงบัญชีอีเมลของตัวแทนเราที่ต้องรับมือกับอำนาจนั้น
หวังว่ารัฐบาลสหรัฐฯ จะทบทวนนโยบายการย้ายงานคอมพิวติ้งไปยังผู้ให้บริการคลาวด์รายใหญ่กันอย่างจริงจัง
“สุดท้ายนี้ เราขอขอบคุณทีม Microsoft ที่ทำงานร่วมกับเราอย่างใกล้ชิด และช่วยตรวจสอบให้แน่ใจว่าเนื้อหานี้มีความถูกต้องในเชิงเทคนิค”
ตกลงกันได้อย่างไรว่าจะเผยแพร่ข่าวนี้ในวันศุกร์?
ฉันลองค้นหา “microsoft” บน Google News แล้วเลิกดูไปหลังจาก 5 หน้าแรก เพราะมีการกล่าวถึงเรื่องนี้แค่ 2 รายการเท่านั้น
ที่เหลือส่วนใหญ่เป็น “ข่าว” ประเภทบทความประชาสัมพันธ์ การโปรโมตสินค้า หรือเสียงรบกวนเกี่ยวกับราคาหุ้น
“ผลกระทบทั้งหมดของเหตุการณ์ครั้งนี้ใหญ่กว่าที่เราเข้าใจในตอนแรกมาก มันจะส่งผลระยะยาวต่อความเชื่อมั่นในคลาวด์ และต่อองค์ประกอบหลักที่ค้ำจุนมัน โดยเฉพาะอย่างยิ่งชั้นอัตลักษณ์ซึ่งเป็นเนื้อผ้าพื้นฐานของทุกสิ่งที่เราทำบนคลาวด์ เราต้องเรียนรู้และปรับปรุงจากเรื่องนี้”
อย่างแรกเลย บางทีเราอาจเริ่มจากการไม่เอาทุกอย่างขึ้นคลาวด์ก่อนไหม
ปัญหาไม่ได้อยู่ที่ตัวคลาวด์เองเท่าไร แต่อยู่ที่ระบบเศรษฐกิจทุนนิยมที่บิดเบี้ยว ซึ่งสุดท้ายก็นำไปสู่การผูกขาดหรือคาร์เทลของบริษัทยักษ์ใหญ่ไม่กี่ราย
สำหรับบริษัทเล็กจำนวนมากในหางยาวของตลาด การใช้ผลิตภัณฑ์และบริการของบริษัทยักษ์ไม่ใช่ทางเลือกที่สมเหตุสมผลนัก แต่เมื่อเราให้อำนาจแก่ผู้ชนะในตลาดมากขึ้นเรื่อย ๆ สุดท้ายก็จะได้บริษัทที่ใหญ่เกินกว่าจะปล่อยให้ล้ม
บริษัทใหญ่แบบนี้ แค่พลาดครั้งเดียวหรือสะดุดครั้งเดียวก็มีพื้นผิวการโจมตีมหาศาลอยู่แล้ว เรื่องแบบนี้ไม่ใช่คำถามว่าจะเกิดไหม แต่เป็นคำถามว่าเมื่อไรจะเกิด
ถ้าสังคมจะอยู่รอดได้ในระยะยาว คำตอบคือบริการแบบสหพันธรัฐ แม้ต้องแลกกับความสะดวกสบายบางส่วนก็ตาม
ผู้นำธุรกิจไม่ใช่พวกเนิร์ดสายเทคนิคที่ฝันถึงบริการแบบสหพันธรัฐที่ใหญ่กว่าและดีกว่า
โดยปกติแล้ว IT เป็นค่าใช้จ่ายก้อนใหญ่ ทั้งในงบกำไรขาดทุน และในแง่เวลา ความเหนื่อย และความเจ็บปวดจากการต้องเรียนรู้ ตัดสินใจ และต่อสู้กับปัญหาคอมพิวเตอร์
เปรียบเทียบได้ว่า ถ้าคุณเลือกขึ้น Microsoft Airlines ทั้งที่อากาศก็ดูไม่น่าไว้ใจนัก ต่อให้เที่ยวบินถูกยกเลิกจนมาช้า คุณก็ยังมีคนร่วมชะตาและได้รับความเห็นอกเห็นใจมากมาย
แต่ถ้าคุณเลือกเดินสายเดี่ยวด้วยการขึ้นรถไฟ ภาระในการทำความเข้าใจตารางเวลา สถานี และทุกอย่างจะตกอยู่กับคุณคนเดียว เพราะ “เครื่องบินเป็นวิธีที่ทุกคนรู้จัก”
และถ้า Microsoft Air ไปถึงอย่างปลอดภัย แต่รถไฟของคุณดันมีปัญหา คุณก็จะโดดเด่นอยู่คนเดียวเหมือนกองอะไรสักอย่างที่มีไอน้ำลอยอยู่บนพื้นครัว
เป็นบทสรุปที่ยอดเยี่ยมและน่ากลัวมาก
แม้หัวข้อจะซับซ้อน แต่ก็อธิบายไว้ได้เข้าใจง่าย