การใช้ GitHub MCP ในทางที่ผิด: เข้าถึง repository ส่วนตัวผ่าน MCP

• MCP agent ที่เชื่อมกับบัญชี GitHub อาจเปิดช่องทางให้ข้อมูลจาก repository ส่วนตัวรั่วไหลได้ เพียงแค่อ่าน Issue สาธารณะ
• การโจมตีเริ่มจาก indirect prompt injection ที่ฝังไว้ใน Issue ของ repository สาธารณะ ซึ่งเปลี่ยนลำดับการใช้เครื่องมือของ agent
• ในเดโม Issue ประสงค์ร้ายใน ukend0464/pacman ทำให้ข้อมูล repository ส่วนตัวถูกส่งออกไปยัง PR สาธารณะผ่านการเชื่อมต่อ Claude 4 Opus กับ GitHub MCP
• แก่นของปัญหาไม่ได้อยู่ที่บั๊กในโค้ดของ GitHub MCP server แต่อยู่ที่โครงสร้างซึ่งเครื่องมือที่เชื่อถือได้ถูกใช้ร่วมกับ เนื้อหาภายนอกที่เชื่อถือไม่ได้
• ระบบ agent จำเป็นต้องมีสิทธิ์ขั้นต่ำแยกตาม repository, การจำกัดการเข้าถึงระดับ session และ runtime security monitoring เช่น MCP-scan

---

การโจมตี GitHub MCP ที่เริ่มจาก Issue ประสงค์ร้าย

• Invariant พบช่องโหว่ใน GitHub MCP integration ที่ใช้งานกันอย่างแพร่หลาย ซึ่งผู้โจมตีสามารถยึด agent ของผู้ใช้และทำให้ข้อมูล repository ส่วนตัวรั่วไหลได้
  • GitHub MCP server ดังกล่าวเป็นโปรเจกต์ที่มี 14k stars บน GitHub
  • ช่องโหว่นี้เป็นหนึ่งในกรณีแรก ๆ ของ Toxic Agent Flows ที่เครื่องมือวิเคราะห์ความปลอดภัยของ Invariant ตรวจพบ
• Toxic Agent Flow คือโฟลว์ที่ indirect prompt injection ทำให้ agent ใช้เครื่องมือตามลำดับที่ไม่ได้ตั้งใจ
  • อาจนำไปสู่การรั่วไหลของข้อมูลหรือการรันโค้ดอันตราย
• ในสถานการณ์ที่ coding agent และ IDE ถูกนำไปใช้อย่างรวดเร็ว การโจมตีลักษณะคล้ายกันอาจกระทบผู้ใช้เครื่องมือพัฒนาซอฟต์แวร์หลัก ๆ ได้

องค์ประกอบของการโจมตี

• ผู้ใช้ใช้ MCP client เช่น Claude Desktop และเชื่อม GitHub MCP server เข้ากับบัญชี GitHub ของตนอยู่
• สถานการณ์โจมตีสมมติ repository สองประเภท
  • <user>/public-repo: repository สาธารณะ ที่ใครก็สร้าง Issue และรายงานบั๊กได้
  • <user>/private-repo: repository ส่วนตัว ที่มีโค้ด proprietary หรือข้อมูลภายในบริษัท
• ผู้โจมตีสามารถสร้าง Issue ประสงค์ร้ายใน repository สาธารณะได้ตามกฎสิทธิ์ปกติของ GitHub
• เมื่อผู้ใช้ส่งคำขอปกติให้ agent เช่น Have a look at the open issues in <user>/public-repo agent จะดึง Issue ของ repository สาธารณะมาและถูก prompt injection
• จากนั้น agent อาจดึงข้อมูล repository ส่วนตัวเข้ามาใน context และทำให้ข้อมูลรั่วไหลผ่าน PR ที่สร้างอัตโนมัติใน repository สาธารณะ

โฟลว์การรั่วไหลที่ยืนยันในเดโม

• เดโมใช้ repository สาธารณะ ukend0464/pacman และ repository ส่วนตัวหลายรายการ
  • ukend0464/pacman: repository สาธารณะที่มีการสร้างเกม Pacman แบบง่าย ๆ และดูได้บน GitHub
  • repository ส่วนตัวมีโปรเจกต์ส่วนบุคคลและข้อมูลอ่อนไหวของผู้ใช้
• ผู้โจมตีวาง Issue ประสงค์ร้าย ไว้ใน repository สาธารณะ
  • Issue ดังกล่าวมี payload ที่จะทำงานทันทีเมื่อ agent ตรวจดูรายการ Issue ของ repository สาธารณะ
• ผู้ใช้ส่งคำขอไปยัง Claude 4 Opus เพื่อ trigger การโจมตี
  • โดยค่าเริ่มต้น Claude Desktop จะขอการยืนยันจากผู้ใช้สำหรับการเรียกใช้เครื่องมือแต่ละครั้ง
  • ผู้ใช้จำนวนมากเลือกนโยบายยืนยันแบบ “Always Allow” เมื่อใช้ agent และหยุดตรวจสอบการทำงานแต่ละรายการ
• agent ไล่ดูรายการ Issue แล้วพบ payload ของผู้โจมตี จากนั้นดึงข้อมูล repository ส่วนตัวเข้ามาใน context และทำให้รั่วไหลไปยัง pull request ของ repository pacman
• PR สาธารณะมีข้อมูลส่วนตัวของผู้ใช้ ukend0464
  • ข้อมูล repository ส่วนตัว เช่น Jupiter Star
  • แผนที่จะย้ายไปอเมริกาใต้
  • ข้อมูลเงินเดือน
• สามารถดู reasoning ทั้งหมดของ agent และลำดับการใช้เครื่องมือได้ใน trace ฉบับเต็มบน Invariant Explorer

Toxic Agent Flow ที่เกิดขึ้นได้แม้กับเครื่องมือที่เชื่อถือได้

• ช่องโหว่นี้ต่างจากการโจมตี tool poisoning แบบเดิมที่ต้องทำให้เครื่องมือ MCP เองถูก compromise
• เมื่อ agent ที่เชื่อมต่อกับแพลตฟอร์มภายนอกอย่าง GitHub ถูกเปิดรับ ข้อมูลที่เชื่อถือไม่ได้ ปัญหาก็อาจเกิดขึ้นได้ แม้เครื่องมือจะอยู่ในสถานะที่เชื่อถือได้โดยสมบูรณ์
• การทำความเข้าใจ วิเคราะห์ และบรรเทาโฟลว์เหล่านี้ในระบบ agent เป็นงานที่ทำด้วยมือในสเกลใหญ่ได้ยาก
• Invariant พัฒนาวิธีอัตโนมัติสำหรับตรวจจับ Toxic Agent Flow เพื่อให้องค์กรระบุและจำลองภัยคุกคามที่อาจเกิดขึ้นได้ก่อนถูกผู้ไม่หวังดีนำไปใช้

ขอบเขตผลกระทบและวิธีบรรเทา

• การทดลองโฟกัสที่ Claude Desktop แต่ช่องโหว่ไม่ได้จำกัดอยู่กับ agent หรือ MCP client รายใดรายหนึ่ง
• agent ทุกตัวที่ใช้ GitHub MCP server อาจได้รับผลกระทบได้ ไม่ขึ้นกับโมเดลพื้นฐานหรือ implementation
• ประเด็นสำคัญคือปัญหานี้ ไม่ใช่ข้อบกพร่องในโค้ดของ GitHub MCP server เอง
  • ไม่ใช่ช่องโหว่ที่ GitHub จะแก้ได้ฝ่ายเดียวด้วย patch ฝั่ง server เท่านั้น
  • เป็นปัญหาเชิงโครงสร้างที่ต้องจัดการในระดับระบบ agent

• การควบคุมสิทธิ์แบบละเอียด

  • เมื่อใช้การเชื่อมต่อ MCP เช่น GitHub ควรจำกัดสิทธิ์การเข้าถึงของ agent เฉพาะ repository ที่จำเป็น
  • สิทธิ์แบบ token-based ดั้งเดิมช่วยป้องกันได้บางส่วน แต่อาจสร้างข้อจำกัดที่แข็งตัวจนจำกัดความสามารถของ agent
  • Invariant แนะนำ runtime security layer แบบไดนามิกที่ปรับให้เหมาะกับระบบ agent
  • Invariant Guardrails ให้การควบคุมการเข้าถึงที่รับรู้ context และปรับตาม workflow ของ agent
  • นโยบายตัวอย่างจำกัดให้หนึ่ง session เข้าถึงได้เพียงหนึ่ง repository เพื่อป้องกันข้อมูลรั่วไหลข้าม repository
  • หากมีการเรียกใช้เครื่องมือที่เกี่ยวกับ repository สำหรับ repo หรือ owner ที่ต่างกันต่อเนื่องกัน จะถือว่าเป็นการละเมิด
  • ดูนโยบายฉบับเต็มได้ที่ github_policy.txt
  • วิธีใช้งานอยู่ใน MCP-scan documentation
  • สามารถทดสอบนโยบายก่อน deploy ได้ที่ Guardrails Playground

• การมอนิเตอร์ความปลอดภัยอย่างต่อเนื่อง

  • นอกจากมาตรการป้องกันแล้ว ยังต้องมีการมอนิเตอร์เพื่อค้นหาและตอบสนองภัยคุกคามแบบเรียลไทม์
  • Invariant แนะนำให้ deploy security scanner เฉพาะทาง เช่น MCP-scan เพื่อ audit ปฏิสัมพันธ์ระหว่าง agent กับระบบ MCP อย่างต่อเนื่อง
  • proxy mode ของ MCP-scan ช่วยสแกนการเชื่อมต่อ MCP แบบเรียลไทม์ได้โดยไม่ต้องแก้ไข infrastructure ของ agent เดิม
  • เมื่อ route ทราฟฟิก MCP ผ่าน proxy จะได้ visibility และการสแกนการละเมิดด้านความปลอดภัยแบบเรียลไทม์
  • การมอนิเตอร์แบบครอบคลุมสร้าง audit trail ซึ่งช่วยตรวจสอบช่องโหว่ที่อาจเกิดขึ้น ความพยายามโจมตี และสถานะการป้องกันต่อการโจมตีรูปแบบใหม่

การ align โมเดลอย่างเดียวไม่เพียงพอ

• การทดลองใช้ Claude 4 Opus ซึ่งผ่านการ alignment และการฝึกด้านความปลอดภัยล่าสุด
• แม้จะมี safety training ที่แข็งแรง agent ก็ยังถูกควบคุมได้ด้วย prompt injection ที่ค่อนข้างเรียบง่าย
• ระบบป้องกัน prompt injection detection สำเร็จรูปจำนวนมากก็จับการโจมตีนี้ไม่ได้
• ความปลอดภัยของระบบ agent ขึ้นกับ context และสภาพแวดล้อม
  • การฝึก alignment ทั่วไปของโมเดลไม่สามารถคาดการณ์ทุกสถานการณ์การ deploy หรือข้อกำหนดความปลอดภัยเฉพาะของแต่ละองค์กรได้
  • มาตรการความปลอดภัยระดับระบบต้องเข้ามาเสริมกลไกป้องกันระดับโมเดล

โจทย์ที่ยังเหลือในความปลอดภัยของ agent

• agent ที่ใช้ GitHub MCP server อาจถูกควบคุมผ่าน GitHub Issue ประสงค์ร้าย จนทำให้ข้อมูล repository ส่วนตัวรั่วไหลไปยัง repository สาธารณะ
• แม้ช่องโหว่นี้จะเฉพาะกับ GitHub MCP แต่การโจมตีลักษณะคล้ายกันยังคงปรากฏในสภาพแวดล้อมอื่น ๆ
  • Legit Security เพิ่งรายงานช่องโหว่ remote prompt injection ใน GitLab Duo
• เพื่อการ deploy อย่างรับผิดชอบในสเกลใหญ่ การเชื่อมต่อ MCP และระบบ agent จำเป็นต้องมี security scanner เฉพาะทางและการควบคุมนโยบาย เช่น MCP-scan และ Guardrails

[crawler]

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