มอบสิทธิ์ผู้ดูแลระบบให้บัญชีทดสอบของ Microsoft ที่ถูกแฮ็ก

[GN⁺]

ความเห็นจาก Hacker News

• ทำให้นึกถึงกรณีแฮ็ก Roblox สมัยโบราณ ที่มีเว็บไซต์ staging ที่ไม่ใช่ระบบโปรดักชันซึ่งผู้ใช้สมัครได้ และมีแบนเนอร์ว่า "ทุกอย่างที่นี่ไม่ถาวร" เมื่อมีการเพิ่มบัญชีแอดมินใหม่ในบัญชีโปรดักชัน ก็มีคนไปลงทะเบียนในเว็บไซต์ staging ด้วยชื่อผู้ใช้เดียวกัน แล้วใช้คุกกี้และโทเคนยึดบัญชีโปรดักชัน ทำให้เว็บไซต์ตกอยู่ในความเสี่ยง เรื่องแบบนี้ไม่น่าเชื่อว่าจะเกิดขึ้นไม่บ่อยนัก: เช่น ตอนสร้างโทเคนเข้ารหัสโดยอิงจากชื่อผู้ใช้หรือ user ID แล้วไม่มี secret แยกระหว่างโปรดักชัน/สเตจจิง หรือกรณีที่เว็บไซต์ staging สื่อสารกับบริการภายนอกที่สับสนสิทธิ์ของโปรดักชัน
• เส้นแบ่งระหว่างระบบพัฒนา/โปรดักชันในบริษัทใหญ่พรุนกว่าที่คนคิดมาก ลองนึกถึงวันทำงานปกติ: ล็อกอินพีซี เช็กอีเมล แล้วใช้ข้อมูลยืนยันตัวตนชุดเดียวกันล็อกอิน Azure portal (ทั้งหมดรองรับโดย tenant เดียวกัน) บัญชียังเชื่อมกับ GitHub และบัญชีคลาวด์ด้วย
• เพื่อให้ทำงานใน Teams หรือ OneDrive ได้ มีกลุ่มและทีมที่มีสิทธิ์เข้าใจยากถูกสร้างกระจัดกระจายไปทั่ว และยังคงอยู่ใน company directory ในฐานะ security group ที่แทบแยกไม่ออก
• บางครั้งก็ได้รับอีเมลอัตโนมัติถามว่ายังใช้งานสิ่งที่ต้องใช้อยู่อีกไหม แต่ข้อความคลุมเครือ และในบริษัทใหญ่มาก ๆ ก็ไม่มีใครให้ถาม (help desk ใช้เวลาสองวันกว่าจะตอบ และก็ไม่สามารถติดต่อ John Savill ทาง Twitter ได้) สุดท้ายก็แค่กดยืนยันแล้วไปต่อ
• ท้ายที่สุด โครงสร้างก็เริ่มปริแตก และผู้โจมตีก็โชคดีเจอจุดอ่อนจนข้าม tenant ไปเอาสิ่งที่ต้องการได้
• อย่างที่ CISO ผู้มีวิสัยทัศน์คนหนึ่งเคยพูดไว้ แฮ็กเกอร์ไม่ได้บุกเข้าไป แต่พวกเขาแค่ล็อกอิน
• ในอุตสาหกรรมไซเบอร์ซีเคียวริตี้ เรื่องนี้เป็นที่รู้จักกันทั่วไปว่า "whoopsie"
• Kevin Beaumont นักวิจัยและผู้เชี่ยวชาญด้านความปลอดภัย ชี้บน Mastodon ว่าบัญชีที่สามารถกำหนดบทบาท 'full_access_as_app' ให้กับแอป OAuth ได้ ควรต้องมีสิทธิ์แอดมิน เขาบอกว่า "ใครบางคน" ทำการตั้งค่าผิดพลาดครั้งใหญ่พอสมควรในสภาพแวดล้อมโปรดักชัน
• แม้จะไม่รู้รายละเอียดของระบบ แต่ดูเหมือนว่านั่นไม่ควรเป็นประเด็น และน่าแปลกใจที่ผู้เชี่ยวชาญบอกว่านี่คือประเด็น ไม่ควรมีทางให้เกิดความผิดพลาดแบบนั้นได้เลย ผู้ออกแบบและผู้ดูแลระบบควรทำให้มันเป็นไปไม่ได้ และพวกเขาควรต้องรับผิดชอบ
• ทั้งที่มีใบรับรองด้านความปลอดภัยหรูหรา แต่กลับดูเหมือนว่าแนวปฏิบัติที่ดีที่สุดซึ่งคิดมาอย่างดีในหนังสือราคา $36 บน Amazon ถูกเพิกเฉยอย่างสิ้นเชิง
• สิ่งที่ขาดหายไปจากโพสต์นี้คือ: ผู้เขียนนิยาม "โปรดักชัน" อย่างไร และเพราะอะไรบัญชี "ที่ไม่ใช่โปรดักชัน" จึงมีสิทธิ์ดูแลโดเมนโปรดักชันได้
• แพตเทิร์นนี้ไม่ใช่ข้อยกเว้นแต่เป็นกฎทั่วทั้ง ecosystem ของ MS แต่การที่ Microsoft เองทำแบบนี้ยิ่งน่าอึดอัดเป็นพิเศษ
• มีบริษัทหนึ่งเก็บรหัสผ่านของเซิร์ฟเวอร์และฐานข้อมูลโปรดักชันทั้งหมดไว้ในไฟล์ข้อความใน code repository เพราะหัวหน้าสถาปนิกไม่อยากจำรหัสผ่านเอง พอชี้ให้ CTO เห็นว่านี่โง่แค่ไหน ก็ได้รับคำตอบว่า "เราเชื่อใจพนักงานของเรา" และ "เราผ่านการตรวจสอบความปลอดภัยมาแล้ว"
• เวลาไปที่ทำงานใหม่ ฉันไม่ชอบเลยเวลามีคนมอบสิทธิ์จำนวนมากให้เพียงเพราะ "มันง่ายกว่า" ไม่ควรทำแบบนั้น นอกจากจะเพิ่มความเสี่ยงให้บริษัทแล้ว ยังทำให้เราต้องแบกรับความรับผิดชอบที่ไม่ต้องการด้วย เราอาจเผลอทำของสำคัญพัง หรือถ้าถูกแฮ็กก็อาจถูกสงสัยว่าเป็นฝีมือเรา เพราะเรามีสิทธิ์ทำได้
• ทำไมเรื่องนี้ถึงถูกนับว่าเป็น "ความผิดพลาด"? มันอาจเป็นการกระทำของสายลับที่ทำงานเป็นแอดมินอยู่ใน Microsoft ก็ได้