การโจมตี GitHub MCP: เข้าถึงรีโพซิทอรีส่วนตัวผ่าน MCP

 (invariantlabs.ai)
3 คะแนน โดย GN⁺ 2025-05-28 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • พบช่องโหว่ร้ายแรงในการผสานรวม GitHub MCP ซึ่งทำให้ผู้โจมตีสามารถใช้ GitHub Issue ที่เป็นอันตรายเพื่อควบคุมเอเจนต์ของผู้ใช้และขโมยข้อมูลจากรีโพซิทอรีส่วนตัวได้
  • ช่องโหว่นี้เป็นรูปแบบใหม่ที่เรียกว่า Toxic Agent Flow ซึ่งทำให้เอเจนต์เปิดเผยข้อมูลไปยังรีโพซิทอรีสาธารณะโดยไม่ตั้งใจจากการถูกชักจูงด้วยพรอมป์ต์อันตราย
  • ช่องโหว่นี้ไม่ได้เกิดจากข้อบกพร่องของตัวเครื่องมือเอง แต่เกิดจากข้อจำกัดเชิงสถาปัตยกรรม และพฤติกรรมการใช้งานจริง เช่น นโยบายยืนยันการใช้งานแบบง่าย ๆ ยิ่งเพิ่มความเสี่ยง
  • เพื่อป้องกันอย่างมีประสิทธิภาพ จำเป็นต้องนำมาตรการปกป้องเอเจนต์อย่างเป็นระบบมาใช้ เช่น การควบคุมสิทธิ์แบบละเอียด และ การติดตามความปลอดภัยอย่างต่อเนื่อง
  • การพึ่งเพียงการจัดแนวโมเดล (Alignment) อย่างเดียวไม่เพียงพอ จึงต้องให้ความสำคัญกับมาตรการความปลอดภัยระดับระบบที่ครอบคลุมทั้ง MCP และสภาพแวดล้อมของเอเจนต์

ภาพรวม

Invariant ค้นพบช่องโหว่ร้ายแรงมากใน GitHub MCP integration (14,000 stars) ที่มีการใช้งานอย่างแพร่หลาย ช่องโหว่นี้ทำให้ผู้โจมตีสามารถสร้าง GitHub Issue ที่เป็นอันตรายเพื่อควบคุมเอเจนต์ของผู้ใช้ และทำให้ข้อมูลจากรีโพซิทอรีส่วนตัวรั่วไหลออกไปภายนอกได้

ปัญหานี้เป็นกรณีแรกที่ถูกค้นพบโดยสแกนเนอร์ตรวจจับ Toxic Agent Flow แบบอัตโนมัติของ Invariant ในสถานการณ์ลักษณะนี้ เอเจนต์จะถูกชักจูงให้ทำพฤติกรรมที่ไม่ได้ตั้งใจ จนนำไปสู่ความเสียหาย เช่น ข้อมูลรั่วไหลหรือการรันโค้ดอันตราย

ในช่วงหลัง อุตสาหกรรมกำลังนำ coding agent และ IDE มาใช้อย่างกว้างขวาง จึงเป็นช่วงเวลาสำคัญที่จะต้องยกระดับการตระหนักรู้ต่อการโจมตีลักษณะนี้

สถานการณ์การโจมตี

  • การเตรียมการโจมตี

    • สมมติว่าผู้ใช้เชื่อมต่อ MCP client อย่าง Claude Desktop เข้ากับ GitHub MCP server แล้ว
    • <user>/public-repo: รีโพซิทอรีสาธารณะที่ใครก็สร้าง Issue ได้
    • <user>/private-repo: รีโพซิทอรีส่วนตัว ใช้เก็บข้อมูลภายในองค์กร เป็นต้น
    • ผู้โจมตีสร้าง Issue ที่เป็นอันตราย (มี prompt injection) ในรีโพซิทอรีสาธารณะ
    • เมื่อผู้ใช้ส่งคำขอธรรมดา เช่น “ช่วยดูรายการ issue ของ public-repo ให้หน่อย” เอเจนต์จะดึง Issue จากรีโพซิทอรีสาธารณะและสัมผัสกับอินเจกชันดังกล่าว

  • ลำดับการโจมตี

    • ทันทีที่เอเจนต์อ่าน Issue อันตราย มันจะดึงข้อมูลจากรีโพซิทอรีส่วนตัวมาเป็นคอนเท็กซ์ แล้วสร้างเป็น PR ในรีโพซิทอรีสาธารณะจนใครก็เข้าถึงได้
    • กระบวนการนี้ถูกนิยามว่าเป็น Toxic Agent Flow และตัววิเคราะห์ความปลอดภัยของ Invariant สามารถตรวจจับได้อัตโนมัติในสภาพแวดล้อมจริง

การสาธิตการโจมตี

  • มีการจำลองการโจมตีโดยใช้รีโพซิทอรีสาธารณะตัวอย่าง (ukend0464/pacman) และรีโพซิทอรีส่วนตัวหลายแห่ง
  • ผู้โจมตีสร้าง Issue ที่เป็นอันตรายในรีโพซิทอรีสาธารณะ และเมื่อเอเจนต์ตรวจดูรายการ Issue ของรีโพซิทอรีนั้น prompt injection ก็จะทำงาน
  • เมื่อผู้ใช้ขอความช่วยเหลือจาก Claude 4 Opus, Claude จะดำเนินอินเจกชันผ่านการเชื่อมต่อ GitHub MCP
    • โดยปกติ Claude Desktop จะขอการยืนยันเมื่อใช้เครื่องมือ แต่ผู้ใช้จำนวนมากตั้งค่าเป็น "always allow" ทำให้ตอบรับโดยไม่ทันระวัง
  • เอเจนต์จะดึงข้อมูลจากรีโพซิทอรีส่วนตัวออกมาและเปิดเผยเป็น PR สาธารณะ
  • ในการทดลอง มีข้อมูลอ่อนไหวรั่วไหลถึงระดับชื่อโปรเจกต์ส่วนตัว แผนการย้ายที่ทำงาน และเงินเดือน

การตรวจจับ Toxic Agent Flows

  • ช่องโหว่นี้สามารถเกิดขึ้นได้แม้เครื่องมือ MCP เดิมจะไม่ได้ถูกเจาะ เพราะต้นเหตุคือข้อมูลที่ไม่น่าเชื่อถือจากแพลตฟอร์มภายนอก (GitHub)
  • ในระบบเอเจนต์ขนาดใหญ่ การวิเคราะห์และบรรเทาความเสี่ยงลักษณะนี้ด้วยมือมีความซับซ้อนมาก Invariant จึงพัฒนาวิธีตรวจจับอัตโนมัติเพื่อให้สามารถวิเคราะห์ภัยคุกคามเชิงรุกได้

ขอบเขตผลกระทบและแนวทางรับมือ

  • ช่องโหว่นี้ไม่ได้จำกัดอยู่แค่เอเจนต์/ไคลเอนต์บางตัว แต่กระทบต่อเอเจนต์ทุกตัวที่ใช้ MCP server
  • นี่ไม่ใช่ข้อบกพร่องของโค้ด GitHub MCP server เอง แต่เป็นปัญหาด้านการออกแบบ จึงแก้ไม่ได้ด้วยการแพตช์ฝั่งเซิร์ฟเวอร์ GitHub
  • มีข้อเสนอแนวทางรับมือหลัก 2 ประการ

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

  • ในสภาพแวดล้อมที่ผสาน MCP ควรใช้หลักสิทธิ์น้อยที่สุด โดยให้เอเจนต์เข้าถึงได้เฉพาะรีโพซิทอรีที่จำเป็นจริง ๆ เท่านั้น
  • การให้สิทธิ์แบบโทเค็นดั้งเดิมเพียงอย่างเดียวมีข้อจำกัดด้านการใช้งาน
  • สามารถเสริมการควบคุมการเข้าถึงตามบริบทของเวิร์กโฟลว์ด้วยเลเยอร์ความปลอดภัยแบบรันไทม์อย่าง Invariant Guardrails
    • ตัวอย่างนโยบาย: อนุญาตให้เข้าถึงได้เพียงหนึ่งรีโพซิทอรีต่อหนึ่งเซสชัน เพื่อป้องกันการรั่วไหลข้ามรีโพซิทอรี
    • ตัวอย่างการกำหนดนโยบาย: 
      raise Violation("You can access only one repo per session.") if:
    (call_before: ToolCall) -> (call_after: ToolCall)
    call_before.function.name in (...set of repo actions)
    call_after.function.name in (...set of repo actions)
    call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
    call_before.function.arguments["owner"] != call_after.function.arguments["owner"]
    • สามารถทดลองนโยบายได้ใน Guardrails Playground เป็นต้น

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

  • นอกเหนือจากมาตรการป้องกันแล้ว ยังจำเป็นต้องมีเครื่องมือติดตามที่ทรงพลังสำหรับสแกนการโต้ตอบระหว่างเอเจนต์กับระบบ MCP แบบเรียลไทม์
  • ตัวอย่างเช่น การนำ Invariant MCP-scan มาใช้เพื่อตรวจเฝ้าระวังและตรวจจับความผิดปกติ
  • โดยใช้ proxy mode รุ่นล่าสุด สามารถเบี่ยงทราฟฟิก MCP ผ่านพร็อกซีเพื่อวินิจฉัยแบบเรียลไทม์ได้ โดยไม่ต้องเปลี่ยนโครงสร้างพื้นฐานเดิม
  • การเฝ้าติดตามแบบครอบคลุมช่วยให้ตรวจพบช่องโหว่ บันทึกความพยายามเจาะระบบ และหยุดยั้งโฟลว์อันตรายได้ตั้งแต่เนิ่น ๆ

เหตุผลที่การจัดแนวโมเดล (Alignment) อย่างเดียวไม่เพียงพอ

  • แม้แต่โมเดลภาษาขนาดใหญ่รุ่นใหม่ล่าสุด (เช่น Claude 4 Opus) ก็ยังเปราะบางต่อการโจมตีแบบ prompt injection ธรรมดาได้ง่าย
  • การฝึก Alignment พื้นฐานเพียงอย่างเดียวไม่สามารถป้องกันการโจมตีที่มีความหลากหลายและขึ้นกับบริบทในสภาพแวดล้อมการใช้งานจริงได้ทั้งหมด
  • ดังนั้น จึงจำเป็นต้องสร้างระบบตรวจจับบริบทและมาตรการความปลอดภัยในระดับระบบ แยกต่างหากจากตัวโมเดลอย่างแน่นอน

บทสรุป

  • Invariant ได้สาธิตช่องโหว่ร้ายแรงใน GitHub MCP server ที่เปิดทางให้ยึดการทำงานของเอเจนต์ผ่าน GitHub Issue อันตราย และทำให้รีโพซิทอรีส่วนตัวรั่วไหล
  • ช่องโหว่นี้เป็นกรณีตัวแทนที่ถูกค้นพบจากระบบตรวจจับอัตโนมัติของ Invariant และการโจมตีลักษณะคล้ายกันยังคงเกิดขึ้นต่อเนื่องในสภาพแวดล้อมหลากหลาย รวมถึง MCP
  • การใช้สแกนเนอร์ความปลอดภัยเฉพาะทางอย่าง MCP-scan และ Guardrails เป็นหัวใจสำคัญต่อการนำ MCP/ระบบเอเจนต์ไปใช้อย่างปลอดภัยและดูแลการทำงานได้อย่างมั่นคง

อ้างอิงและติดต่อ

  • หากต้องการคำปรึกษาหรือการนำมาตรการความปลอดภัยเพิ่มเติมไปใช้ สามารถติดต่อได้ที่ earlyaccess@invariantlabs.ai

ผู้เขียน:
Marco Milanta
Luca Beurer-Kellner

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

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

 
crawler 2025-05-28

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

  • ฉันรู้สึกว่ายังไม่ค่อยเข้าใจการโจมตีนี้ทั้งหมดนัก ถ้าให้ access token กับ Claude ไม่ว่าจะสั่งให้ใช้เพื่ออะไร ก็หมายความว่าสามารถชักจูงให้ Claude ทำอะไรก็ได้ภายในขอบเขตสิทธิ์ของโทเค็นนั้น ถ้าให้ข้อมูลรับรองกับ LLM ก็ต้องถือว่า LLM ใช้สิทธิ์ทั้งหมดของข้อมูลรับรองนั้นได้ โดยเฉพาะถ้าตั้งให้อนุญาตการเรียกใช้เครื่องมือโดยอัตโนมัติยิ่งต้องระวัง แต่ GitHub มี access token ที่จำกัดสิทธิ์ได้ละเอียด ดังนั้นถ้าให้สิทธิ์เข้าถึงเฉพาะบาง repository ขอบเขตที่ LLM จะถูกนำไปใช้ในทางที่ผิดก็จะถูกจำกัด การโจมตีนี้เป็นไปได้ก็ต่อเมื่อ LLM มีสิทธิ์เข้าถึงทั้งบัญชี และการให้ข้อมูลรับรองที่เสี่ยงขนาดนั้นกับ Claude ตั้งแต่แรกนั่นแหละคือปัญหา

    • ประเด็นสำคัญของเรื่องนี้คือ เช่นเดียวกับการโจมตีแบบ prompt injection ส่วนใหญ่ LLM ถูกวางไว้ในสภาพแวดล้อมที่เข้าถึงอย่างน้อย 2 ใน 3 อย่างพร้อมกัน คือข้อมูลที่ผู้โจมตีควบคุมได้, ข้อมูลอ่อนไหว, และความสามารถในการรั่วไหลข้อมูล หลักการพื้นฐานของการออกแบบเอเจนต์คือควรอนุญาตได้ทีละไม่เกินสองอย่าง และต้องออกแบบตามกฎนี้จึงจะกันปัญหาความปลอดภัยได้ ตัวอย่างเช่น แค่เปิด issue ที่คนไม่น่าเชื่อถือสร้างไว้ บริบทของ LLM ก็ปนเปื้อนด้วยข้อมูลจากผู้โจมตีแล้ว จากนั้นถ้าจะให้เข้าถึงข้อมูลอ่อนไหว ก็ต้องปิดความสามารถอย่างการเชื่อมต่ออินเทอร์เน็ต ถ้ายึดโมเดลนี้ ก็ปลอดภัยได้แม้ไม่มี token แยกตาม repository น่าเสียดายที่ MCP ไม่มีเครื่องมือที่รับประกันเรื่องนี้

    • มีปัญหาที่สิทธิ์ของ token มักถูกตั้งกว้างเกินไป แต่ในขณะเดียวกันนักพัฒนาก็ไม่อยากเปิด token แยกหนึ่งอันต่อหนึ่ง repository จึงลงเอยด้วยการให้สิทธิ์กว้าง ๆ กับ token แล้วเชื่อใจ LLM แบบไม่มีเงื่อนไข การระวังแบบนี้ถือว่าฉลาด แต่ในโลกจริงผู้เล่นจำนวนมากใน ecosystem ไม่ได้ทำแบบนั้น เหตุผลที่รายงานนี้สำคัญก็เพราะมันช่วยให้เห็นว่า ถ้า LLM มีสิทธิ์และมีข้อมูลที่ไม่น่าเชื่อถือ มันก็สามารถถูก hijack ให้ทำอะไรก็ได้ วิธีแก้คือจำกัดขอบเขตการใช้ token แบบไดนามิก เรากำลังศึกษาวิธีนี้อยู่ในรายการนี้

    • นี่เป็นปัญหาที่อาจเกิดกับบริการอย่าง Railway ได้ Railway บางครั้งขอสิทธิ์เข้าถึง GitHub repository ทั้งหมด แม้จะใช้ deploy แค่โปรเจ็กต์เดียว ขณะที่ Netlify เคารพให้สิทธิ์เฉพาะ repository ที่ผู้ใช้ต้องการ GitHub ควรบล็อกไม่ให้แอปที่ไม่เคารพการจำกัดสิทธิ์แบบนี้ได้รับการอนุมัติตั้งแต่ต้น

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

    • ถ้าแชตบอตมีปฏิสัมพันธ์กับผู้ใช้ ก็ต้องตั้งสมมติฐานว่าแชตบอตจะทำได้ทุกอย่างภายในขอบเขตที่มันได้รับอนุญาต แชตบอตเป็นเพียงเลเยอร์อำนวยความสะดวกบน API ไม่ใช่กลไกความปลอดภัยในตัวอยู่แล้ว

  • ถ้าสนใจ MCP และความปลอดภัยของเอเจนต์ มีเอกสารหลายอย่างที่ทำไว้แล้ว ดู Claude execution trace ของสถานการณ์โจมตีแบบเต็ม(ลิงก์), security scanner สำหรับการเชื่อมต่อ MCP(ลิงก์), การโจมตีแบบ MCP tool poisoning(บล็อก), กรณี exploit ผ่าน WhatsApp MCP(บล็อก), เลเยอร์ความปลอดภัยสำหรับเอเจนต์ Guardrails(บล็อก) และ AgentDojo ที่ใช้ประเมินทั้งความปลอดภัยและ utility ของ AI agent ร่วมกัน(บล็อก)

  • สงสัยว่านี่ควรถูกเรียกว่า 'exploit' จริงหรือไม่ ถ้าให้ token ที่เข้าถึง private repository ได้กับเอเจนต์ มันก็เข้าถึงได้อยู่แล้ว MCP ก็เป็นแค่ API server ถ้าไม่อยากให้สิ่งใดถูกเปิดผ่าน API ก็ไม่ควรให้สิทธิ์มันตั้งแต่แรก

    • เหมือนหลายคน ฉันก็อ่านคอมเมนต์ก่อนอ่านบทความจริง จากเนื้อหาจริงของบทความคือมีการสร้าง issue ที่เป็นอันตรายบน GitHub และใน issue นั้นมี prompt ที่ใช้ LLM เพื่อชักจูงให้ข้อมูลรั่วไหล เมื่อเจ้าของ repository เรียกใช้งานเอเจนต์ เอเจนต์ก็จะทำตาม prompt อันตรายนั้น

    • นี่คือ exploit จริงที่อาศัยความผิดพลาดของมนุษย์ (หรือความมั่นใจเกินไป) ปัญหาคือผู้คนถูกกระแส hype กล่อมจนยอมส่ง token การเข้าถึง GitHub ทั้งบัญชีที่อ่อนไหวให้ LLM อย่างสบายใจ

    • เรื่องนี้สำคัญจึงอยากสะกิดนิดหนึ่งว่า ทุกคนควรเข้าใจความเสี่ยงของการให้ AI เรียกใช้เครื่องมืออย่างถูกต้อง ตอนนี้เอเจนต์ตัดสินใจใช้เครื่องมือตามสิ่งที่อยู่ในความสนใจหรือบริบท ซึ่งบริบทนั้นถูกผลลัพธ์จากเครื่องมือหรือ prompt ชักจูงได้ง่าย แต่ในคอมเมนต์กลับมีแต่การพูดซ้ำ ๆ ว่า “ก็เพราะให้ token ไปเอง” น่าเสียดายที่แม้อธิบายปัญหาอย่างถูกต้องแล้ว ก็ยังมีการเบี่ยงประเด็นต่อด้วยแนวคิดว่า "ผู้ใช้อนุญาตเองนี่" นี่คือข้อโต้แย้งผิดแบบคลาสสิกของปัญหา 'confused deputy' อีกทั้งยังโยนว่าเป็นความรับผิดชอบของผู้ใช้ แต่จริง ๆ แล้วตัว MCP เองที่ไม่มีการควบคุมหลังการเข้าถึงหรือไม่มี log ก็เป็นปัญหา สำหรับฉัน ต้องมีการทำ logging ได้จึงจะอุ่นใจ นอกจากนี้ยังมีการเมินงานวิจัยด้านความปลอดภัยแล้วด่าว่าเป็นเรื่อง “สามัญสำนึก” ทั้งที่การพูดเรื่องความปลอดภัยไม่เคยเป็นเรื่องเสียหาย จุดอ่อนจะไม่ร้ายแรงมากก็ไม่ได้แปลว่าไม่ควรพูดถึง ถึงขั้นเปรียบได้กับ 'SQL injection' เลยด้วยซ้ำ และการไม่เข้าใจมุมที่ว่าระบบถูกปนเปื้อนทางอ้อมได้ (ผ่านการสร้าง public issue เพื่อส่งโค้ดอันตราย) นั้นอันตราย สุดท้ายก็น่าเสียดายที่คนจำนวนหนึ่งไม่ได้เปิดรับมุมมองใหม่และเลือกตั้งรับอย่างเดียว

  • มองจากด้านความปลอดภัย ถ้า LLM เห็นข้อความจากแหล่งที่ไม่น่าเชื่อถือ ก็ต้องสมมติว่าแหล่งนั้นสามารถควบคุมให้ LLM สร้างผลลัพธ์ตามต้องการได้ ถ้าผลลัพธ์นั้นนำไปสู่การเรียกใช้เครื่องมือ ก็เท่ากับว่าแหล่งที่ไม่น่าเชื่อถือเองก็ใช้เครื่องมือนั้นได้ไปด้วย พอค้นข้อมูลที่เกี่ยวข้องก็รู้สึกว่า เอกสาร Guardrails ของ invariant labs ก็มีมุมการตลาดอยู่เหมือนกัน แต่ในเชิงความปลอดภัย โครงสร้างที่ซับซ้อนจนต้องมีผลิตภัณฑ์ guardrail แบบนี้ก็น่าหวั่นอยู่ดี และก็อดเสียดายไม่ได้ว่าถ้าบริษัท AI ออกแบบโดยยึดความปลอดภัยเป็นศูนย์กลางตั้งแต่แรก ก็คงไม่ต้องมีผลิตภัณฑ์แบบนี้

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

    • เลยสงสัยว่าอาจฝึก LLM ให้มองข้อความบางส่วนเป็นข้อมูลที่ไม่ผ่านการทำให้บริสุทธิ์ (impure) และละเว้นการตีความเชิงคำสั่งจากส่วนนั้นได้หรือไม่

    • จริง ๆ แล้วบริษัท AI ก็ออกแบบโดยคำนึงถึงความปลอดภัยอยู่เหมือนกัน แต่ 'exploit' ครั้งนี้เป็นสถานการณ์ที่เกิดได้ก็ต่อเมื่อปิดระบบความปลอดภัยไว้เท่านั้น (พร้อมคำเตือนตัวหนา) เช่น Claude Desktop ปกติจะขออนุญาตโดยตรงทุกครั้งที่มีการเรียกใช้เครื่องมือ แต่ผู้ใช้จำนวนมากตั้งค่าเป็น “อนุญาตเสมอ” จึงไม่คอยตรวจสอบการกระทำแต่ละอย่าง

    • รูปแบบช่องโหว่ซอฟต์แวร์แบบนี้เกิดซ้ำมาโดยตลอดในโลกดั้งเดิม และก็น่าทั้งขำทั้งเหนื่อยใจที่มันยังเกิดในเทคโนโลยีใหม่ด้วย รูปแบบ “รับ input จากผู้ใช้ แล้วในสภาพแวดล้อมที่ป้องกันไม่ดี ก็ตีความเป็นคำสั่งแล้วรัน” เป็นเรื่องเดิมที่เราเห็นมาแล้วใน SQL injection, XSS, PHP include และอื่น ๆ ตอนนี้มันก็วนมาถึง LLM

  • ฉันไม่คิดว่า MCP เองจะเป็นของใหม่ที่ปฏิวัติวงการหรือเปราะบางต่อการแฮ็กเป็นพิเศษนัก (แม้ว่าจะมีความเห็นแยกเกี่ยวกับ MCP ก็ตาม) มันให้ความรู้สึกเหมือนเอาเทคนิค prompt injection ไปห่อด้วยการตลาด ตอนออกแบบระบบเอเจนต์ ฉันใช้ปรัชญาว่า “สิ่งใดก็ตามที่เอเจนต์เข้าถึงได้ ก็หมายความว่าใครก็ตามที่เข้าถึงเอเจนต์ได้ก็เข้าถึงสิ่งนั้นได้เช่นกัน” ฉันไม่ปล่อยให้ LLM เป็นผู้บังคับใช้ access control และทำให้ชัดว่าเจ้าของคำขอเป็นผู้รับผิดชอบด้านความปลอดภัยของงานที่เอเจนต์ทำนั้นเอง ตลอดทั้งบทความ สิ่งที่เราควรสนใจจริง ๆ คือจะให้เอเจนต์เข้าถึง resource อะไรบ้าง ถ้าอนุญาตให้เข้าถึงข้อมูลอีเมล แล้วมีอีเมล prompt injection ที่ชักจูง LLM ให้ขโมย security token ส่งออกไป นั่นแหละคือความเสี่ยงที่ร้ายแรงจริง

    • การพ่วงคำว่า MCP เข้าไปให้ความรู้สึกเหมือนกระแส “เอาขึ้น blockchain แล้วนะ” เมื่อ 10 ปีก่อน การพูดว่า “เพราะ LLM เป็นตัวอนุมัติและเป็นผู้ลงมือทำ จึงต้องใช้หลัก least privilege อย่างเคร่งครัด” เป็นเรื่องที่ใครมีประสบการณ์ก็ควรรู้อยู่แล้ว แต่บางทีก็อาจเป็นอีกครั้งที่คนรุ่นใหม่ต้องมาเรียนพื้นฐานนี้กันใหม่

  • ดูตัวอย่างการโจมตีจริงและการตอบสนองของเอเจนต์ได้ที่นี่ จุดที่ชวนขำอยู่บ้างคือเอเจนต์ทำให้การโจมตีสำเร็จอย่างสมบูรณ์

  • ฉันเองก็ลองใช้ Google's Jules coding agent เมื่อสัปดาห์ก่อน และคำขอสิทธิ์ผ่าน GitHub OAuth ต้องการสิทธิ์เข้าถึง repository และสิทธิ์ทั้งหมดในบัญชีแบบเต็มรูปแบบ ดีไซน์แบบนี้ส่วนหนึ่งก็เพื่อความสะดวกของนักพัฒนา และอีกส่วนก็มาจากตัว GitHub OAuth authentication flow เอง จริง ๆ ควรมีวิธีให้สิทธิ์แบบจำกัดเฉพาะระดับ repository ได้ง่ายกว่านี้ และขอสิทธิ์เพิ่มภายหลังได้ แต่ความเป็นจริงตอนนี้คือแทบต้องสร้างบัญชี GitHub แยกเพื่อให้สิทธิ์เฉพาะบาง repository เท่านั้น(ตัวอย่างบัญชี) ซึ่งยุ่งยากมาก แม้เอกสารทางการของ GitHub จะแนะนำให้สร้าง machine user แยกไว้แบบนี้ก็ตาม แต่การกำหนดขอบเขต repository ตั้งแต่ต้นควรง่ายกว่านี้ ถ้าใครมีวิธีที่ดีกว่านี้อยากให้ช่วยบอกที

  • ฉันรู้สึกว่าข้ออ้างในบทความนี้เกินจริงไปมาก เรื่องที่บอกว่าข้อมูลรั่วไหลได้จาก issue ง่าย ๆ นั้น จริง ๆ แล้วจะเกิดขึ้นได้ก็ต่อเมื่อผู้ใช้ลงมือทำหลายอย่างที่เสี่ยงทางความปลอดภัยด้วยตนเองทั้งหมด กล่าวคือ ต้องตั้งค่า MCP server, ให้ข้อมูลรับรองที่เข้าถึงได้ทั้ง public/private repo, อนุญาตให้ LLM เข้าถึง server นั้นและอ่าน issue ใน repository, และยังต้องไปอ่าน issue อันตรายนั้นเอง รวมถึงตั้งค่าให้เปิดเผยผลลัพธ์ออกภายนอกด้วย มันเป็นผลลัพธ์ที่แย่ก็จริง แต่ในทางปฏิบัติยังไม่ใช่สิ่งที่จะเรียกว่า “ช่องโหว่ความปลอดภัยจากการโจมตีโดยผู้อื่น” ได้เต็มปาก เป็นผลจากผู้ใช้ทำให้ระบบอ่านข้อมูลที่ไม่น่าเชื่อถือและส่งผลออกไปยังที่ที่ไม่น่าเชื่อถือเอง ถึงอย่างนั้น GitHub MCP ก็มีส่วนต้องรับผิดชอบอยู่บ้าง เพราะมันไม่ได้กันการข้ามระหว่าง public/private repository

    • ที่สำคัญคือต้องไม่มองข้ามว่า แม้แต่คำสั่งง่าย ๆ อย่าง “ช่วยสรุป issue ให้หน่อย” ก็อาจทำให้คำสั่งอันตรายที่ฝังอยู่ใน issue ถูกปฏิบัติตามได้

    • มุมการตลาดของ MCP ก็สำคัญ ตัว protocol เองควรถูกแยกให้เข้าถึงได้เฉพาะสภาพแวดล้อมหรือผู้ใช้ที่เชื่อถือได้เท่านั้น ปัญหาคือไม่มีวิธีมาตรฐานในการกำหนด scope หรือ authentication ให้ MCP server ฉันรู้สึกว่าปัญหาหลักไม่ได้อยู่ที่ Github MCP แต่เป็นปัญหาเชิงโครงสร้างในวิธีใช้งานและวิธีนำไปใช้ของทั้งอุตสาหกรรมด้วย เวลาใช้ custom MCP server จริง ๆ เรามักส่งข้อมูลอื่นนอกเหนือจาก AI เพิ่มเข้าไปด้วย เช่น ID, JWT ฯลฯ เพื่อใช้บล็อกด้านความปลอดภัย

    • เพราะกระแส AI ช่วงนี้ ความจริงก็คือมีคนจำนวนมากเอาการตั้งค่าและ flow ที่อันตรายแบบนี้ไปใช้โดยไม่ทันคิด ถึงจะพูดได้ง่ายว่า “ของแบบนี้ไม่ควรใช้” แต่เพราะคนเรามักตัดสินใจพลาด guardrails จึงจำเป็นมาก

    • สำหรับข้อโต้แย้งที่ว่าไม่ควรผสม public/private repository เข้าด้วยกัน ในทางปฏิบัตินี่เป็นการเรียกใช้เครื่องมือที่แยกจากกันโดยสิ้นเชิง ในมุมของ MCP server ไม่มีทางตรวจจับปฏิสัมพันธ์นั้นได้

  • เพิ่งพบว่าตอนนี้การถกเถียงกำลังดำเนินอยู่ในเธรด HN นี้

    • ฝั่งนั้นก็มีคนพูดไว้แล้วว่าความเสี่ยงด้านความปลอดภัยชัดเจนมาก คือถ้าคุณให้ระบบเข้าถึงข้อมูลส่วนตัว และในขณะเดียวกันอนุญาตให้ผู้ใช้ภายนอกใส่ข้อความ input อะไรก็ได้ สุดท้ายก็เท่ากับเปิดทางให้ผู้ใช้ภายนอกเข้าถึงข้อมูลลับทางอ้อมด้วย เป็นปัญหาที่กันได้ง่ายหากยึดตามแนวปฏิบัติด้านความปลอดภัยมาตรฐาน

    • ตอนนี้คอมเมนต์ย้ายไปรวมกันอยู่ที่นี่

  • MCP เป็นเพียงหนึ่ง protocol เท่านั้น ยังมีกรณีคล้ายกันอย่าง A2A หรือวิธีเข้าถึงแบบดิบอีกมาก จะสั่งให้ LLM ไปอ่านเอกสาร GitHub API แล้วใช้ token เรียก API เองก็ยังได้ แม้ตอนนี้ LLM ทุกตัวจะยังทำได้ไม่ถึงระดับนั้น แต่เดี๋ยวก็คงทำได้ การทำให้กลไกลงทะเบียนเครื่องมือปลอดภัยอย่างสมบูรณ์นั้นแทบเป็นไปไม่ได้ในทางปฏิบัติ ความรับผิดชอบสุดท้ายต่อการรั่วไหลของข้อมูลจึงไปตกอยู่ที่ LLM อยู่ดี นักพัฒนาต้องการประสิทธิภาพจาก LLM มากขึ้น ทำให้ท้ายที่สุดเราต้องมีความปลอดภัยที่รับประกันได้ หรือไม่ก็อาจถึงขั้นต้องเพิ่ม security firewall ลงในทุกโน้ตบุ๊ก เรื่องที่ปวดหัวจริง ๆ คือ ในอนาคตอาจไปไกลถึงขั้นเป็นศึกระหว่าง LLM ที่ประพฤติไม่ดีกับ LLM ที่คอยจับ LLM ไม่ดีผ่าน security firewall ก็ได้