GitHub เพิ่มความเข้มงวดมาตรการความปลอดภัยของ npm ด้วยการบังคับใช้ 2FA และ Access Tokens

GitHub กำลังนำมาตรการป้องกันใหม่มาใช้เพื่อลดความเสี่ยงจากการโจมตีแบบ Supply-Chain attack บนแพลตฟอร์ม หลังจากที่มีเหตุการณ์โจมตีครั้งใหญ่หลายครั้งในช่วงที่ผ่านมา

การโจมตีก่อนหน้านี้ ซึ่งเริ่มต้นจากการโจมตี GitHub repositories แล้วแพร่กระจายไปยัง NPM ได้แก่ การโจมตี "s1ngularity" ในช่วงปลายเดือนสิงหาคม, แคมเปญ "GhostAction" ในต้นเดือนกันยายน และแคมเปญ worm-style ที่ถูกเรียกว่า "Shai-Hulud" เมื่อสัปดาห์ที่แล้ว

เหตุการณ์โจมตีเหล่านี้ส่งผลให้มีการบุกรุกบัญชี และ repository ส่วนตัวนับพัน, การขโมยข้อมูลที่มีความสำคัญ และก่อให้เกิดค่าใช้จ่ายในการแก้ไขปัญหาที่สูงมาก

แม้ว่า GitHub จะตอบสนองอย่างรวดเร็วเพื่อลดผลกระทบจากเหตุการณ์เหล่านี้ แต่ก็ยอมรับว่า การใช้มาตรการเชิงรุกที่เข้มแข็งกว่านี้จะมีประสิทธิภาพมากกว่า

เพื่อลดความเสี่ยง GitHub ได้ประกาศว่าจะทยอยดำเนินมาตรการดังต่อไปนี้ :

• บังคับใช้การยืนยันตัวตนแบบสองขั้นตอน (2FA) สำหรับ local publishing
• บังคับใช้ granular tokens ที่มีอายุการใช้งาน 7 วัน
• ขยาย และส่งเสริมการใช้งาน trusted publishing
• ยกเลิกใช้งานโทเค็นแบบ classic และ TOTP 2FA (ย้ายไปใช้ FIDO-based 2FA)
• ลดระยะเวลาหมดอายุของ publishing tokens
• Publishing access เริ่มต้นคือ disallow tokens
• ลบตัวเลือกการ bypass การใช้ 2FA สำหรับ local publishing

Trusted publishing ซึ่งถูกนำมาใช้ในหลาย ecosystem แล้ว GitHub แนะนำให้ผู้พัฒนานำมาใช้อย่างจริงจัง เนื่องจากช่วยลดความจำเป็นในการจัดการ API tokens ในระบบ build

สำหรับผู้ดูแล NPM ได้รับคำแนะนำให้เปลี่ยนมาใช้ trusted publishing โดยทันที รวมถึงบังคับใช้ 2FA สำหรับการ publishing และ writing และควรใช้ WebAuthn แทน time-based one-time passwords (TOTP) สำหรับ 2FA

แพลตฟอร์ม code hosting และ collaboration จะทยอยปล่อยการเปลี่ยนแปลงเหล่านี้ พร้อมจัดทำเอกสาร และคู่มือการย้ายระบบ เพื่อให้เกิดการรบกวนต่อ workflow เดิมน้อยที่สุด

ประกาศดังกล่าวยังเน้นย้ำด้วยว่า ความมั่นคงปลอดภัยของ ecosystem เป็นความรับผิดชอบร่วมกัน และนักพัฒนาควรลงมือปฏิบัติเองในการลดความเสี่ยงจาก supply-chain attack โดยการเลือกใช้ตัวเลือกความปลอดภัยที่ดีกว่าที่มีอยู่บนแพลตฟอร์ม

นอกจากนี้ Ruby Central ยังได้ประกาศการกำกับดูแลที่เข้มงวดขึ้นของ RubyGems package manager เพื่อเสริมสร้างการป้องกัน supply-chain attack เช่นกัน

ใน ecosystem นี้ก็เคยประสบปัญหาคล้ายกันเมื่อเร็ว ๆ นี้ เช่น แคมเปญที่มี Ruby gems ที่เป็นอันตรายกว่า 60 รายการ ถูกดาวน์โหลดไปกว่า 275,000 ครั้ง และอีกกรณีหนึ่งคือการโจมตีแบบ typosquatting โดยปลอมชื่อใกล้เคียงกับโปรเจกต์ Fastlane สำหรับ Telegram

จนกว่ารูปแบบการกำกับดูแลใหม่ และนโยบายที่เกี่ยวข้องจะแล้วเสร็จ จะมีเพียงเจ้าหน้าที่ของ Ruby Central เท่านั้นที่ถือสิทธิ์การเข้าถึงแบบผู้ดูแลระบบ

ประกาศดังกล่าวยังให้คำมั่นว่าจะมีการเปลี่ยนแปลงไปสู่ รูปแบบที่โปร่งใสมากขึ้น และเน้นชุมชนเป็นศูนย์กลาง โดยมีการจัดถาม-ตอบในวันนี้ เพื่อคลายความกังวลที่เกิดขึ้นจากการดำเนินการอย่างกะทันหัน ซึ่งสมาชิกในชุมชน Ruby หลายคนมองว่าเป็นการเข้าควบคุมอย่างไม่เหมาะสม

ที่มา : bleepingcomputer