บั๊กรีเซ็ตรหัสผ่านของ GitLab ทำให้เซิร์ฟเวอร์มากกว่า 5.3 พันเครื่องตกอยู่ในความเสี่ยง

 (scmagazine.com)
1 คะแนน โดย GN⁺ 2024-01-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เซิร์ฟเวอร์ที่ยังไม่แพตช์ช่องโหว่ GitLab CVE-2023-7028

  • ช่องโหว่ร้ายแรง CVE-2023-7028 ของ GitLab ยังไม่ได้รับการแพตช์บนเซิร์ฟเวอร์มากกว่า 5,300 เครื่อง ณ วันอังคาร ทำให้มีความเป็นไปได้ที่บัญชีของนักพัฒนาซอฟต์แวร์จะถูกยึดจากระยะไกล
  • บั๊กนี้ได้รับคะแนน CVSS สูงสุด 10 คะแนน และ GitLab ได้เปิดเผยพร้อมออกแพตช์ครั้งแรกเมื่อวันที่ 11 มกราคม
  • จากช่องโหว่ในระบบล็อกอินของ GitLab ผู้โจมตีสามารถส่งลิงก์รีเซ็ตรหัสผ่านไปยังอีเมลที่ยังไม่ได้รับการยืนยันตัวตนได้ โดยไม่ต้องมีปฏิสัมพันธ์ใด ๆ จากเหยื่อ

ข้อมูลแพตช์และผลการทดสอบช่องโหว่

  • มีการออกอัปเดตความปลอดภัยสำหรับ GitLab เวอร์ชัน 16.5.6, 16.6.4, 16.7.2 และมีการ backport ไปยังเวอร์ชัน 16.1.6, 16.2.9, 16.3.7, 16.4.5 ด้วย
  • นักวิจัยรายหนึ่งได้ทดสอบบั๊กนี้บน GitLab Community Edition เวอร์ชัน 16.6.1 และแชร์ผลไว้บน AttackerKB ว่า "มีประสิทธิภาพมากและใช้ประโยชน์ได้ง่าย"

การตรวจพบอินสแตนซ์ที่เปราะบางและแนวโน้มการลดลง

  • หลังจากสามารถติดตั้งแพตช์ได้เกือบ 2 สัปดาห์ Shadowserver Foundation ตรวจพบ GitLab อินสแตนซ์ที่ยังเปราะบางทั่วโลกจำนวน 5,379 รายการ
  • สหรัฐอเมริกาและเยอรมนีมีอินสแตนซ์ที่เปราะบางมากที่สุด โดยมี 964 และ 730 รายการตามลำดับ
  • เครื่องมือแดชบอร์ดของ Shadowserver แสดงให้เห็นว่าอินสแตนซ์ที่เปราะบางลดลงเหลือ 4,652 รายการเมื่อวันที่ 24 มกราคม
  • โฆษกของ Shadowserver กล่าวยืนยันกับ SC Media ว่า แม้การลดลงของอินสแตนซ์ที่เปราะบางจะเป็นพัฒนาการเชิงบวก แต่ยังต้องใช้เวลาอีกมากเพื่อพิจารณาว่านี่เป็นแนวโน้มหรือเป็นเพียงความผันผวนชั่วคราว

ตัวบ่งชี้การถูกโจมตีของ GitLab CVE-2023-7028

  • ลูกค้า GitLab ที่มีอินสแตนซ์แบบ self-managed ของ GitLab Community Edition และ GitLab Enterprise Edition ควรตรวจสอบล็อกเพื่อยืนยันว่ามีการใช้ประโยชน์จาก CVE-2023-7028 หรือไม่
  • ควรตรวจสอบ HTTP request ไปยังพาธ /users/password ใน gitlab-rails/production_json.log และดูว่า params.value.email ถูกจัดเป็น JSON array ที่มีอีเมลหลายรายการหรือไม่
  • ควรตรวจสอบรายการใน gitlabs-rails/audit_json.log ที่ meta.caller.id เป็น PasswordsController#create และ target_Details ถูกจัดเป็น JSON array ที่มีอีเมลหลายรายการ
  • ยังไม่พบการตรวจจับการใช้ประโยชน์จากบั๊กนี้บน GitLab.com หรืออินสแตนซ์เฉพาะของ GitLab
  • GitLab ยังแนะนำให้เปิดใช้งานการยืนยันตัวตนแบบ 2 ขั้นตอน (2FA) ซึ่งจะช่วยป้องกันการยึดบัญชีผ่าน CVE-2023-7028 ได้ แต่ผู้ใช้อินสแตนซ์ที่ยังไม่แพตช์ก็ยังคงเสี่ยงที่จะถูกล็อกออกจากบัญชี หากผู้โจมตีใช้ช่องโหว่นี้รีเซ็ตรหัสผ่าน

ความเห็นของ GN⁺

  • บทความนี้ให้ข้อมูลสำคัญเกี่ยวกับช่องโหว่ความปลอดภัยร้ายแรงของ GitLab โดย CVE-2023-7028 อาจเป็นภัยคุกคามโดยตรงต่อความปลอดภัยของบัญชีนักพัฒนาซอฟต์แวร์ และจำเป็นต้องมีการดำเนินการที่เหมาะสม
  • แม้จะมีการออกแพตช์แล้ว แต่เซิร์ฟเวอร์จำนวนมากทั่วโลกยังคงอยู่ในสถานะเปราะบาง ซึ่งตอกย้ำความสำคัญของการตระหนักรู้ด้านความปลอดภัยและการอัปเดตอย่างทันท่วงที
  • บทความนี้ยังเน้นย้ำความสำคัญของการยืนยันตัวตนแบบ 2 ขั้นตอน (2FA) และช่วยกระตุ้นให้ผู้ใช้ใช้มาตรการรักษาความปลอดภัยเพิ่มเติม เพื่อยกระดับการตระหนักรู้ด้านความปลอดภัย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-29
ความเห็นจาก Hacker News

  • "อยากพูดถึงความเสี่ยงของฟีเจอร์ 'เชื่อมโยงที่อยู่อีเมลกับบัญชี' ในเว็บแอปแบบอิงบัญชีผู้ใช้ ฟีเจอร์นี้เป็นหนึ่งในสิ่งที่ผู้ทดสอบเจาะระบบจะลองบิดหรือโจมตีทันที และมีการพบช่องโหว่มาตั้งแต่ช่วงต้นยุค 2000 ปัญหาแบบนี้เกิดขึ้นซ้ำใน GitLab เช่นกัน แม้ GitLab จะมีทีมความปลอดภัยที่ยอดเยี่ยม แต่ดูเหมือนว่าบั๊กลักษณะนี้จะหลีกเลี่ยงได้ยาก หากผู้อ่าน Hacker News ทั่วไปสนใจเรื่องนี้ ก็อยากให้ลองตรวจสอบฟังก์ชันรีเซ็ตรหัสผ่านของตัวเอง โดยเฉพาะตรรกะการเชื่อมโยงอีเมล"

  • "ขอแชร์ลิงก์คอมมิตที่พบช่องโหว่นี้ในโค้ดเบสของ Rails: ลิงก์คอมมิต GitLab"

  • "ฉันได้รับผลกระทบจากบั๊กนี้ ผู้โจมตีต้องรู้อีเมลของผู้ใช้จึงจะโจมตีได้ แต่มีที่อยู่อีเมลที่ซ่อนอยู่ซึ่งเชื่อมกับ GitLab user ID (ตัวเลขที่เพิ่มขึ้นจาก 1) โดย ID 1 หรือ 2 มีโอกาสสูงว่าจะเป็นผู้ดูแลระบบ จึงเป็นเป้าหมายที่ดี รูปแบบอีเมลจะเป็น '1-user@mail.noreply.<gitlabhost>' ดูเหมือนเป็นการโจมตีแบบอัตโนมัติ และ 2FA ช่วยเราไว้"

  • "การรีเซ็ตรหัสผ่านผ่านอีเมลเป็นฝันร้ายด้านความปลอดภัย แม้จะติดตั้งอย่างถูกต้องแล้วก็ตาม ในบริการส่วนใหญ่ คุณไม่สามารถปิดฟีเจอร์นี้ได้ และทางเลือกก็มักมีแค่ Enterprise SSO บางบริการให้ตั้งหมายเลขโทรศัพท์สำหรับโทเค็น SMS ได้ แต่ฉันยังไม่เคยเห็นตัวเลือกที่บังคับใช้ทั้งอีเมลและโทเค็น SMS พร้อมกัน"

  • "ฉันเคยพบบั๊กที่สามารถ brute force บัญชีได้โดยใส่อาร์เรย์ของรหัสผ่านลงในฟอร์มล็อกอิน มันเป็นเว็บอินเทอร์เฟซแบบหยาบ ๆ สำหรับสแปมแอปพลายแอนซ์ และฉันก็ไม่แน่ใจว่านั่นเป็นพฤติกรรมที่ตั้งใจไว้หรือเป็นเพราะมือใหม่ PHP เขียนโค้ด ตอนนั้นมีผู้ใช้คนหนึ่งที่ใช้รหัสผ่านซึ่งมีอักขระพิเศษ และเป็นคนพบมัน"

  • "เรื่องนี้เตือนอีกครั้งว่า บริการภายในอย่าง GitLab ควรถูกรันไว้หลัง VPN ที่อนุญาตให้เฉพาะผู้ใช้ที่เชื่อถือได้เข้าถึงเท่านั้น"

  • "การทำอัปเดต GitLab แบบอัตโนมัตินั้นง่ายมาก ใช้ GitLab บน Docker+Compose แล้วอัปเดตรายวันผ่าน Watchtower หรือเครื่องมือคล้ายกันก็ได้ ฉันดูแลเซิร์ฟเวอร์ GitLab ด้วยวิธีนี้มานานกว่า 7 ปีแล้วโดยไม่มีปัญหาเลย มองไปรอบ ๆ จะเห็นว่า GitLab จำนวนมากยังเป็นเวอร์ชันเก่า ผู้ดูแลระบบกำลังทำอะไรกันอยู่?"

  • "ฉันมีหลักการว่าจะไม่เปิดเผยเซิร์ฟเวอร์ภายในทุกประเภทออกสู่อินเทอร์เน็ตสาธารณะโดยตรง แต่จะให้เข้าถึงได้ผ่าน VPN เท่านั้น เพื่อสร้างแนวป้องกันชั้นที่สอง"

  • "ย้ำเตือนอีกครั้งว่าควรใช้ SSO เสมอ และอย่าลืมเปิดใช้ 2FA"

  • "เลิกคิดกันได้แล้วว่า Ruby/Rails เป็นตัวเลือกที่เหมาะสมสำหรับซอฟต์แวร์ที่ต้องปลอดภัยจริงจัง ฉันเข้าใจว่า GitLab ต้องรับมือกับสภาพแวดล้อมนี้ แต่ต่อจากนี้เราควรยอมรับว่าสิ่งที่เรียบง่ายกว่าจะดีกว่าภาษาและเฟรมเวิร์กที่ให้ความสำคัญกับ control flow ที่ชาญฉลาดและซ่อนอยู่ ฉันทำงานกับโค้ดเบส Ruby ในระบบโปรดักชันอยู่ และมองเห็นได้ชัดว่าปัญหาคล้ายกันนี้อาจเกิดขึ้นได้ จากการที่ใครบางคนคิดว่าการซ้อน abstraction หลายชั้นทำให้โค้ดขยายได้ดีมาก"