ช่องโหว่ GitLab 18.11.3 ให้ผู้ใช้ที่ตรวจสอบตัวตนรันคำสั่งในฐานะ git

GitLab รุ่น 18.11.3 ที่รันบนเซิร์ฟเวอร์แบบ Self‑Managed ถูกค้นพบช่องโหว่ให้ผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์แล้วสามารถทำการเรียกใช้งานคำสั่งระบบปฏิบัติการในฐานะผู้ใช้ git ได้โดยไม่ต้องมีสิทธิ์ระดับแอดมินหรือเข้าถึงตัวรันเนอร์ CI – เป็นประเด็นสำคัญสำหรับองค์กรหลายแห่งที่พึ่งพา GitLab เป็นศูนย์กลางจัดการซอร์สโค้ด

Overview

นักวิจัยด้านความปลอดภัย Yuhang Wu จากทีม depthfirst ได้เผยแพร่ **Proof‑of‑Concept (PoC) ที่แสดงให้เห็นกระบวนการโจมตีแบบ Remote Code Execution (RCE) บน GitLab รุ่นดังกล่าว PoC นี้สามารถทำงานได้บนเซิร์ฟเวอร์ที่ยังไม่ได้รับการอัปเดตแพทช์

GitLab เวอร์ชัน 18.11.3 ยังคงเป็นหนึ่งในรุ่นที่ได้รับความนิยมจากองค์กรขนาดกลางและใหญ่ เนื่องจากรองรับการติดตั้งแบบ On‑Premise ซึ่งทำให้ผู้ดูแลระบบต้องรับผิดชอบในการอัปเดตและจัดการช่องโหว่ทั้งหมดด้วยตนเอง

ตามรายงานของ The Hacker News การโจมตีไม่จำเป็นต้องอาศัยสิทธิ์ระดับแอดมินหรือการตั้งค่า CI Runner พิเศษ ทำให้ความเสี่ยงต่อระบบภายในเพิ่มสูงขึ้นอย่างชัดเจน

Technical Details

กระบวนการโจมตีเริ่มต้นด้วยผู้ใช้ที่มีบัญชีใน GitLab ทำการอัปโหลด Jupyter notebook สองไฟล์ที่ถูกปรับแต่งเป็นพิเศษ ไฟล์เหล่านี้ถูกคอมมิทเข้าสู่รีโพสิทอรีแล้วเรียกดูความแตกต่าง (diff) ของสองโน๊ตบุ๊ก

เมื่อระบบทำการสร้าง diff ไฟล์ จะมีขั้นตอนภายในที่ประมวลผลข้อมูลจาก notebook ซึ่งเป็นช่องทางให้โค้ดประสงค์ร้ายสามารถฝังคำสั่งระบบได้โดยตรง การเรียกใช้ git เป็นผู้ดำเนินการจึงทำให้คำสั่งดังกล่าวถูกประมวลผลในสิทธิ์ของผู้ใช้ git

PoC ไม่ต้องพึ่งพาการโต้ตอบจากเหยื่อเพิ่มเติม เช่น การคลิกลิงก์หรือเปิดไฟล์แนบ เนื่องจากขั้นตอนทั้งหมดเกิดขึ้นอัตโนมัติเมื่อผู้โจมตีทำการส่งคอมมิทและเรียกดู diff

ขั้นตอนหลักของ PoC
ผู้ใช้ที่เข้าสู่ระบบอัปโหลด Jupyter notebook สองไฟล์ที่มีโค้ดประสงค์ร้าย
คอมมิทไฟล์เหล่านี้ลงในรีโพซิทอรี
เรียกดู diff ของสองโน๊ตบุ๊กผ่าน API หรือ UI ของ GitLab
ระบบประมวลผล diff แล้วดำเนินการคำสั่งระบบในฐานะผู้ใช้ git

Exploit Chain

การเชื่อมต่อระหว่างขั้นตอนต่าง ๆ ทำให้ PoC สามารถทำงานได้โดยไม่ต้องอาศัยสิทธิ์แอดมินหรือเข้าถึงเครื่องมือ CI Runner ใด ๆ การใช้ Jupyter notebook เป็นจุดเริ่มต้นนั้นเป็นวิธีที่ค่อนข้างใหม่ เนื่องจากหลายองค์กรอนุญาตให้ผู้พัฒนานำไฟล์โน๊ตบุ๊กเข้าสู่โครงการเพื่อการทำงานร่วมกัน

กระบวนการนี้แสดงให้เห็นถึงความอ่อนไหวยของฟีเจอร์ diff rendering ที่มักถูกมองว่าเป็นส่วนที่ปลอดภัย เนื่องจากไม่ได้มีการตรวจสอบเนื้อหาอย่างละเอียดในระดับไฟล์โน๊ตบุ๊ก ทำให้โค้ดประสงค์ร้ายสามารถหลบผ่านการกรองได้

แม้ว่าผู้โจมตีจะต้องเป็นผู้ใช้ที่ได้รับอนุญาตแล้ว แต่หลายองค์กรอาจให้สิทธิ์การเข้าถึงระดับพื้นฐานแก่พนักงานจำนวนมาก ซึ่งเพิ่มความเสี่ยงต่อการถูกทำลายโดยภายใน (insider threat) หรือบัญชีที่ถูกขโมย

Impact

หากผู้โจมตีสามารถรันคำสั่งในฐานะผู้ใช้ git ได้ จะมีผลกระทบหลายประการ ได้แก่

การเข้าถึงไฟล์ระบบและข้อมูลโค้ดทั้งหมดในรีโพซิทอรี รวมถึงความลับขององค์กรที่เก็บไว้ใน GitLab
ความสามารถในการติดตั้ง backdoor หรือสคริปต์เพิ่มเติมบนเซิร์ฟเวอร์เพื่อทำการขโมยข้อมูลต่อเนื่องหรือทำการโจมตีต่อไปยังระบบอื่น ๆ ภายในเครือข่าย
การทำลายความเชื่อมั่นของกระบวนการ DevOps เนื่องจาก CI Pipeline หรือระบบอัตโนมัติอาจถูกควบคุมโดยผู้โจมตีได้

ตามที่นักวิจัยชี้แจง ช่องโหว่นี้เป็น “remote code execution” ที่ไม่ต้องพึ่งพาการมีสิทธิ์แอดมิน ทำให้ระดับความรุนแรงของมันอยู่ในระดับสูง และจำเป็นต้องได้รับการแก้ไขโดยเร็ว

Mitigation

GitLab ได้ออกแพทช์สำหรับเวอร์ชันที่ใหม่กว่าเพื่อปิดช่องโหว่นี้ ผู้ดูแลระบบควรดำเนินการต่อไปนี้โดยด่วน

อัปเดต GitLab ไปยังรุ่นล่าสุดหรืออย่างน้อย 18.11.4 (หากมี) ที่ได้รวมการแก้ไขช่องโหว่ RCE นี้แล้ว
จำกัดสิทธิ์การอัปโหลดไฟล์ Jupyter notebook หรือกำหนดให้ต้องผ่านกระบวนการตรวจสอบก่อนนำเข้ารีโพซิทอรี
ตรวจสอบและปิดการเข้าถึง API diff สำหรับผู้ใช้ที่ไม่ได้รับอนุญาตระดับสูง เพื่อลดโอกาสโจมตีจากช่องทางนี้

องค์กรควรเพิ่มการตรวจจับพฤติกรรมที่ผิดปกติในระบบ GitLab เช่น การคอมมิทไฟล์จำนวนมากโดยทันที หรือการเรียกดู diff อย่างต่อเนื่องจากบัญชีผู้ใช้เดียวกัน

Summary

นักวิจัย Yuhang Wu เผย PoC ทำให้ผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์บน GitLab 18.11.3 สามารถรันคำสั่งระบบในฐานะผู้ใช้ git ได้โดยไม่ต้องมีสิทธิ์แอดมินหรือ CI Runner การเปิดเผยนี้กระตุ้นให้ผู้ดูแลระบบเร่งอัปเดตแพทช์และปรับนโยบายการจัดการไฟล์ notebook เพื่อป้องกันความเสี่ยงต่อการละเมิดข้อมูลและระบบภายใน.