กลับไปหน้าข่าวสาร

พบช่องโหว่ GitLab เป็นช่องทางในการโจมตี GitLab CE/EE ผ่านไลบรารี Oj

แชร์:

นักวิจัยจาก Depthfirst เปิดเผยชุดการโจมตีที่เชื่อมโยงช่องโหว่ด้าน Memory Safety จำนวน 2 รายการในไลบรารี Oj ซึ่งเป็นตัวประมวลผล JSON ประสิทธิภาพสูงที่พัฒนาด้วยภาษา C และถูกใช้งานในแอปพลิเคชัน Ruby จำนวนมาก รวมถึง GitLab ช่องโหว่ทั้งสองซ่อนอยู่ในไลบรารีนี้มานานเกือบ 5 ปี ก่อนถูกค้นพบและนำมาเชื่อมโยงกันจนสามารถรันโค้ดจากระยะไกล (Remote Code Execution) บน GitLab CE/EE ที่ติดตั้งด้วยค่ามาตรฐานได้ โดยไม่จำเป็นต้องมีสิทธิ์ผู้ดูแลระบบหรือการโต้ตอบจากเหยื่อแต่อย่างใด


วิธีการค้นพบช่องโหว่


ในฐานะส่วนหนึ่งของ Open Defense Initiative นักวิจัย Yuhang Wu จาก Depthfirst ใช้ระบบวิเคราะห์อัตโนมัติ (AI System) ตรวจสอบไลบรารี Oj และพบช่องโหว่ที่มีความสำคัญสูงจำนวน 18 รายการ ในจำนวนนี้ 7 รายการเป็นปัญหาด้าน Memory Safety โดย 2 รายการในนั้นถูกนำมาผสานกันจนกลายเป็น Exploit Chain ที่ใช้งานได้จริง


ห่วงโซ่การโจมตี


การโจมตีเริ่มต้นจากฟีเจอร์ Jupyter Notebook Diff ของ GitLab โดยมีขั้นตอนดังนี้:


  1. เมื่อผู้ใช้งาน Commit ไฟล์ .ipynb (Jupyter Notebook) เข้า Repository
  2. GitLab ใช้ Gem ภายในชื่อ ipynbdiff เพื่อประมวลผล JSON ของไฟล์ Notebook ผ่านคำสั่ง Oj::Parser.usual.parse เพื่อสร้าง Diff ที่มนุษย์อ่านได้
  3. ช่องโหว่ Memory Safety ทั้ง 2 รายการใน Oj ถูกกระตุ้นระหว่างขั้นตอนนี้ ทำให้ผู้โจมตีสามารถควบคุมการทำงานของ Process และรันคำสั่งได้ในที่สุด


จุดที่น่ากังวลเป็นพิเศษคือ สมาชิกโปรเจกต์ทั่วไป ที่มีสิทธิ์ Push และดู Diff ตามปกติ สามารถกระตุ้นการโจมตีนี้ได้ทันที โดยไม่ต้องมีสิทธิ์ผู้ดูแลระบบ ไม่ต้องเข้าถึง CI/CD และไม่ต้องอาศัยการโต้ตอบใดๆ จากผู้ใช้งานคนอื่น


ระบบและเวอร์ชันที่ได้รับผลกระทบ


ช่องโหว่นี้กระทบ GitLab CE/EE ในช่วงเวอร์ชันดังนี้:


  • เวอร์ชัน 15.2.0 ถึง 18.10.7 ได้รับการแก้ไขในเวอร์ชัน 18.10.8
  • เวอร์ชัน 18.11.0 ถึง 18.11.4 ได้รับการแก้ไขในเวอร์ชัน 18.11.5
  • เวอร์ชัน 19.0.0 ถึง 19.0.1 ได้รับการแก้ไขในเวอร์ชัน 19.0.2


ผลกระทบที่อาจเกิดขึ้น


  1. เปิดเผย Source Code ของ Repository ทั้งหมดที่โฮสต์อยู่บน GitLab Instance ที่ถูกโจมตี
  2. ขโมย Rails Secrets และ Service Credentials ที่จัดเก็บอยู่ในระบบ GitLab
  3. เข้าถึงระบบภายในอื่นๆ (Internal Services) ที่เชื่อมต่อกับ GitLab Instance ต่อได้ เปิดทางสู่การทำ Lateral Movement
  4. ความเสี่ยงต่อการโจมตีแบบ Supply Chain หาก Source Code หรือ Pipeline ถูกแก้ไขโดยผู้โจมตีที่เข้าควบคุมระบบได้
  5. ความเสี่ยงสูงเป็นพิเศษสำหรับองค์กรที่เปิดให้สมาชิกภายนอกหรือ Contributor จำนวนมากเข้าถึง Repository เนื่องจากผู้โจมตีไม่จำเป็นต้องมีสิทธิ์สูงในการเริ่มการโจมตี


สิ่งที่องค์กรควรทำ


  1. อัปเดต GitLab CE/EE เป็นเวอร์ชัน 18.10.8, 18.11.5 หรือ 19.0.2 ขึ้นไปโดยเร็วที่สุด ตามสายเวอร์ชันที่ใช้งานอยู่
  2. ตรวจสอบ Log การ Commit ไฟล์ .ipynb ที่ผิดปกติย้อนหลัง โดยเฉพาะจากบัญชีผู้ใช้งานที่ไม่คุ้นเคยหรือมีพฤติกรรมผิดปกติ
  3. จำกัดสิทธิ์การเข้าถึง Repository ให้เหมาะสมตามความจำเป็น โดยเฉพาะสำหรับ Repository ที่มีข้อมูลสำคัญ
  4. หมุนเวียน Rails Secrets และ Service Credentials หากสงสัยว่า GitLab Instance อาจถูกโจมตีสำเร็จไปแล้วก่อนการแพตช์


แนวทางลดความเสี่ยงระยะยาว


1. ทำ Dependency Scanning สำหรับไลบรารีภายในที่ใช้ประมวลผลไฟล์จากผู้ใช้งาน

โดยเฉพาะไลบรารีที่ประมวลผลข้อมูลในรูปแบบที่ซับซ้อน เช่น JSON Parser ที่พัฒนาด้วยภาษาระดับต่ำอย่าง C


2. จำกัดฟีเจอร์ที่ประมวลผลไฟล์แบบอัตโนมัติจากผู้ใช้งานทั่วไป

พิจารณาว่าฟีเจอร์อย่าง Notebook Diff จำเป็นต้องเปิดใช้งานสำหรับผู้ใช้งานทุกระดับหรือไม่


3. ติดตาม Security Advisory จาก GitLab อย่างสม่ำเสมอ

และวางแผนอัปเดตเวอร์ชันตามรอบที่เหมาะสม โดยเฉพาะเมื่อมีการประกาศช่องโหว่ระดับ Critical


4. ทำ Runtime Protection สำหรับ Self-hosted GitLab Instance

เพื่อตรวจจับพฤติกรรมการรันคำสั่งผิดปกติจาก Process ของ GitLab แบบ Real-time


วิเคราะห์ในมุมมองจาก TXEC


ช่องโหว่นี้สะท้อนความเสี่ยงที่สำคัญของ Software Supply Chain ในระดับที่ลึกกว่าปกติ คือความเสี่ยงจากไลบรารีพื้นฐานที่ซ่อนอยู่ในหลายชั้นของแอปพลิเคชัน ช่องโหว่ Memory Safety ทั้งสองรายการซ่อนอยู่ในไลบรารี Oj มาเกือบ 5 ปีโดยไม่มีใครตรวจพบ จนกระทั่งมีการใช้ระบบวิเคราะห์อัตโนมัติเข้ามาช่วยค้นหา สะท้อนว่าองค์กรไม่สามารถพึ่งพาความไว้วางใจในไลบรารีที่ใช้งานมานานเพียงอย่างเดียวได้อีกต่อไป


สำหรับองค์กรไทยที่ใช้ GitLab เป็นแพลตฟอร์มหลักในการพัฒนาซอฟต์แวร์ โดยเฉพาะ Self-hosted Instance ที่เปิดให้ทีมพัฒนาหลายทีมหรือ Contributor ภายนอกเข้าถึง TXEC แนะนำให้เร่งอัปเดตเป็นเวอร์ชันที่แก้ไขแล้วโดยเร็วที่สุด เนื่องจากช่องโหว่นี้ใช้สิทธิ์เพียงระดับสมาชิกโปรเจกต์ทั่วไปในการโจมตี ทำให้ความเสี่ยงกระจายไปถึงผู้ใช้งานเกือบทุกระดับในองค์กร


รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า


[ แหล่งอ้างอิง: Depthfirst, CyberSecurityNews, The Cyber Express, CyberPress, GBHackers ]