Omer Gil และทีม พบช่องโหว่ซึ่งเป็นส่วนหนึ่งของ DevOps ตาม Blog และได้แจ้งกับทาง Information Security Media Group ว่าต้องมีการตรวจสอบกลไกในการตรวจสอบบน GitHub และเนื่องจาก GitHub Actions เป็นส่วนที่มีการติดตั้งเป็นค่า default เบื้องต้นทำให้มีผลต่อองค์กรที่มีการใช้งานทุกที่

GitHub เป็นแพลตฟอร์มในการพัฒนาซอฟต์แวร์ที่ใช้ควบคุมการดำเนินการแก้ไข การตรวจสอบการดำเนินการต่างๆใน Codeโปรแกรมต่างๆที่ทางผู้พัฒนาโปรแกรมได้ทำการสร้างขึ้น โดย GitHub Action คือการส่งต่อข้อมูลที่ทางผู้พัฒนาได้มีการแก้ไข สร้าง workflows เพื่อทำการส่งต่อไปยัง production

เมื่อ workflows ทำงานจะทำการสร้าง GITHUB_TOKEN มาใช้เพื่อทำการตรวจสอบสิทธิ์ โดยสิทธิ์ต่างๆจะถูกตั้งค่าตามแต่ละองค์กร เช่น สิทธิ์ในการ อ่าน เขียน เข้าถึงขอบเขตของข้อมูลบางส่วน เนื้อหา แพ็คเกจที่สามารถร้องขอได้ โดยผู้ใช้งานที่มีสิทธิ์ในการเขียน สามารถปรับเปลี่ยนการอนุญาตในการเข้าถึงไฟล์หรืออนุญาตการ merge หากผู้ไม่หวังดีสามารถเข้าถึง Account ที่มีสิทธิ์ในการแก้ไขได้ จะสามารถส่ง Code ที่เป็นอันตรายไปยังระบบงานต่างๆที่สามารถเข้าถึงได้ทั้งหมด

โดย GITHUB_TOKEN จะทำงานควบคู่กับ PR (การตรวจสอบทบทวนสิ่งที่มีการขอ merge request) User สามารถทบทวนสิ่งที่ผู้ใช้งานบางคนทำการเปลี่ยนแปลงแก้ไข ก่อนที่จะส่งไปยังระบบงาน production เมื่อ PR ถูกสร้างขึ้นมาจะไม่สามารถ merge ข้อมูลรวมกันได้เนื่องจากจะต้องมีการอนุมัติเสียก่อน แต่ในการโจมตีนี้ workflows จะทำงานทันทีเมื่อมีการอนุญาตจาก PR โดย github-actions bot

โดยทางนักวิจัยได้รายงานเหตุการณ์ ดังกล่าวกับทาง GitHub และบอกถึงผู้ใช้งาน GitHub ให้ดำเนินการปิด GitHub Action หากไม่ได้ใช้งาน และเพิ่มการตรวจสอบสิทธิ์ในการส่งต่อ Code ให้มากขึ้นโดยการตรวจสอบมากกว่า 2 ครั้งขึ้นไปจนกว่า GitHub จะมีการแก้ไขช่องโหว่ดังกล่าว

ที่มา: bankinfosecurity.

Felix Wilhelm จาก Google Project Zero เปิดเผยช่องโหว่ใหม่รหัส CVE-2020-15228 ใน Github Actions ที่ได้มีการแจ้งเตือนไปตั้งแต่ปลายเดือนกรกฎาคม โดยช่องโหว่ดังกล่าวเกิดจากการคำสั่งในกลุ่ม workflow commands ที่ทำให้ Actions runner สามารถรันคำสั่ง shell ใน runner machine ได้ ซึ่งทำให้ช่องโหว่นี้มีความเสี่ยงที่จะถูกโจมตีเพื่อทำ command injection

ช่องโหว่จริงๆ อยู่ที่วิธีการที่ Action runner ประมวลผล workflow commands โดยปกตินั้นหากต้องการเรียกใช้ workflow command เราจะทำการเรียกใช้โดยใช้คำสั่ง echo ของ Linux จากนั้นให้ใส่ workflow commands ที่ครอบด้วย marker ลงไป โดย marker แตกต่างกันตามเวอร์ชันของ Action runner เช่นหากเป็นรุ่นแรกนั้น marker คือตัวอักษร ## และสำหรับรุ่นที่ 2 จะมี marker คือ :: ตามตัวอย่างเช่น echo '::set-output name=SELECTED_COLOR::green'

Action runner จะมองหา workflow commands จาก STDOUT ของคำสั่ง echo หรือคำสั่งใดๆ ก็ตามและนำข้อมูลทั้งหมดไปรัน Felix ระบุว่ากระบวนการตรงนี้มีโอกาสที่สูงมากที่จะถูกทำ command injection หากภายใน echo นั้นมี untrusted code อยู่ หรือมีการรับข้อมูลจากผู้ใช้มารัน ผู้ไม่ประสงค์ดีสามารถทำการ inject ข้อมูลในส่วนนี้ จากนั้นใช้คำสั่งอย่าง set-env หรือ add-path เพื่อแก้ไข environment varible ของ runner machine ตอน workflow กำลังทำงานอยู่ได้

การจะโจมตีช่องโหว่ได้นั้นขึ้นอยู่กับว่ามีการรับ untrusted input เข้าไปประมวลผลใน workflow ในขั้นตอนใด ตัวอย่างซึ่ง Felix ยกมานั้นคือโครงการหนึ่งของ vscode ซึ่งนำ GitHub Actions มาใช้ในการกระจาย Issues ไปยังโครงการอื่นโดยมีการรับข้อมูลจาก Issues มา ผู้โจมตีสามารถทำการ inject คำสั่งผ่านการสร้าง Issues เพื่อโจมตีช่องโหว่นี้ได้

GitHub ใช้เวลาเกือบ 3 เดือนในการแก้ไขปัญหานี้แต่กลับไม่สามาถรปิดการใช้งานหรือแก้ไขช่องโหว่โดยตรงได้ GitHub จึงได้มีการออกคำแนะนำในการใช้งานเพื่อลดความเสี่ยงแทนที่ https://github.