"S" ใน MCP หมายถึงความปลอดภัย

 (elenacross7.medium.com)
2 คะแนน โดย GN⁺ 2025-04-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • MCP เป็นโปรโตคอลมาตรฐานที่เชื่อม LLM เข้ากับเครื่องมือ แต่โดยพื้นฐานแล้วยังไม่ได้ฝังความปลอดภัยมาให้
  • มีช่องโหว่ด้านความปลอดภัยหลายแบบ เช่น การแทรกคำสั่ง, การวางยาพิษเครื่องมือ, การบิดแก้คำจำกัดความ
  • MCP ไม่มีฟังก์ชันยืนยันตัวตน, การเข้ารหัส, หรือการตรวจสอบความถูกต้องสมบูรณ์ จึงเป็นโครงสร้างที่ยากจะไว้วางใจ
  • ในตอนนี้ การใช้เครื่องมืออย่าง ScanMCP เพื่อให้มองเห็นภาพรวมและควบคุมได้ น่าจะเป็นแนวทางรับมือที่ดีที่สุด

MCP คืออะไร และทำไมจึงสำคัญ

  • MCP ย่อมาจาก Model Context Protocol เป็นมาตรฐานใหม่ของวิธีที่ LLM อย่าง Claude, GPT และ Cursor ใช้เชื่อมรวมกับเครื่องมือและข้อมูล
  • มันมอบวิธีการเชื่อมต่อแบบมาตรฐานจนถูกเรียกว่าเป็น "USB-C สำหรับ AI agent"
  • ผ่าน MCP, AI agent สามารถทำสิ่งต่อไปนี้ได้
    • เชื่อมต่อกับเครื่องมือผ่าน API ที่เป็นมาตรฐาน
    • รักษาสถานะของเซสชัน
    • รันคำสั่ง (ซึ่งอาจถูกรันได้อย่างอิสระมากเกินไป)
    • แชร์คอนเท็กซ์ข้ามเวิร์กโฟลว์
  • แต่โดยพื้นฐานแล้ว ยังไม่ได้ฝังความปลอดภัยมาให้
  • จึงมีความเสี่ยงที่จะเปิด side channel ให้เข้าถึงระบบได้โดยที่ผู้ใช้ไม่รู้ตัว

ช่องโหว่ด้านความปลอดภัยหลัก ๆ ที่เกิดขึ้นใน MCP

  • ช่องโหว่จากการแทรกคำสั่ง (งานวิจัยของ Equixly)

    • ณ ปี 2025 ก็ยังเกิด การรันโค้ดระยะไกล (RCE) ผ่านการแทรกคำสั่ง อยู่
    • จากการตรวจสอบของ Equixly พบว่ากว่า 43% ของการติดตั้งใช้งาน MCP server ทั้งหมดใช้การเรียก shell ที่ไม่ปลอดภัย
    • ผู้โจมตีสามารถใส่คำสั่ง shell ลงในค่าที่ป้อนให้เครื่องมือ แล้วใช้ agent ที่เชื่อถือได้เป็นตัวรันโค้ดจากระยะไกล

  • การวางยาพิษเครื่องมือ (Tool Poisoning, Invariant Labs)

    • เป็นวิธีที่ผู้โจมตี ซ่อนคำสั่งอันตรายไว้ในคำอธิบายของเครื่องมือ
    • ผู้ใช้มองไม่เห็น แต่ AI จะรับรู้และทำตามคำสั่งนั้นตรงตามนั้น
    • เครื่องมือที่ดูเหมือนแค่คำนวณทางคณิตศาสตร์ธรรมดา อาจจริง ๆ แล้วอ่าน SSH key หรือไฟล์ตั้งค่าที่อ่อนไหวจากระบบผู้ใช้ได้

  • การนิยามเครื่องมือใหม่แบบเงียบ ๆ (Rug Pull)

    • เครื่องมือสามารถเปลี่ยนคำนิยามของตัวเองได้หลังการติดตั้ง
    • เครื่องมือที่ดูปกติใน Day 1 อาจกลายเป็นเครื่องมือขโมย API key ของผู้โจมตีใน Day 7
    • นี่คือรูปแบบใหม่ของ ปัญหาความปลอดภัยในห่วงโซ่อุปทาน ที่เกิดขึ้นภายใน LLM

  • การทำให้เครื่องมือจากเซิร์ฟเวอร์อื่นถูกกลบเงา

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

ทำไม MCP จึงยังไม่ปลอดภัย

  • MCP ให้ความสำคัญกับสิ่งต่อไปนี้
    • ✅ การเชื่อมต่อรวมระบบที่ง่าย
    • ✅ อินเทอร์เฟซที่เป็นหนึ่งเดียว
  • แต่ยังขาดสิ่งต่อไปนี้
    • ❌ ไม่มีมาตรฐานการยืนยันตัวตน
    • ❌ ไม่มีการเข้ารหัสคอนเท็กซ์
    • ❌ ไม่สามารถตรวจสอบความถูกต้องสมบูรณ์ของเครื่องมือได้
  • ผู้ใช้ไม่สามารถรู้ได้ว่า agent ใช้คำอธิบายใดจริง ๆ ในการเลือกใช้เครื่องมือ

แนวทางรับมือด้านความปลอดภัยที่นักพัฒนาและผู้ดูแลแพลตฟอร์มทำได้

  • นักพัฒนา

    • ต้องตรวจสอบค่าป้อนเข้า
    • ตรึงเวอร์ชัน (pinning) ของ MCP server และเครื่องมือ
    • ลบข้อมูลอ่อนไหวออกจากคำอธิบายของเครื่องมือ

  • ผู้ดูแลแพลตฟอร์ม

    • แสดง metadata ของเครื่องมือทั้งหมดให้ผู้ใช้เห็น
    • ใช้ integrity hash เมื่อมีการอัปเดตเซิร์ฟเวอร์
    • บังคับใช้ความปลอดภัยของเซสชัน

  • ผู้ใช้

    • ห้ามเชื่อมต่อกับ MCP server ที่ไม่น่าเชื่อถือ
    • เฝ้าดู session log เหมือนกับที่เฝ้าระวังระบบ production
    • ติดตามการอัปเดตเครื่องมือที่น่าสงสัย

ข้อเสนอแนวคิดของ ScanMCP.com

  • ScanMCP ถูกเสนอให้เป็นสแกนเนอร์และแดชบอร์ดที่ทำสิ่งต่อไปนี้
    • ตรวจสอบเครื่องมือ MCP ที่เชื่อมต่ออยู่
    • ตรวจจับความเสี่ยงอย่าง RCE, การวางยาพิษเครื่องมือ, การรั่วไหลของเซสชัน
    • เปรียบเทียบและแสดงภาพข้อมูลที่ผู้ใช้เห็น vs. ข้อมูลที่ agent รับรู้
  • อาจมีประโยชน์ต่อผู้ใช้กลุ่มต่อไปนี้
    • ทีมความปลอดภัยของแพลตฟอร์ม agent
    • สตาร์ตอัปด้านโครงสร้างพื้นฐาน AI
    • นักพัฒนาอิสระที่ต้องการสร้างเครื่องมือบนฐานความเชื่อถือ

ความคิดส่งท้าย

MCP เป็นโปรโตคอลที่ทรงพลัง แต่กำลังถูกนำไปใช้เร็วเกินไปทั้งที่ความพร้อมด้านความปลอดภัยระดับ API ยังไม่สุกงอม
จนกว่าจะมีแนวทาง Secure-by-default เครื่องมืออย่าง ScanMCP.com คือวิธีที่ดีที่สุดในการสร้างการมองเห็นและการควบคุม

  • สรุป: "S" ใน MCP ไม่ได้หมายถึง Security แต่ มันควรจะเป็นเช่นนั้น

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

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

 
GN⁺ 2025-04-07
ความคิดเห็นบน Hacker News

  • บทความนี้เน้นย้ำและอ้างอิงสถานการณ์การโจมตีที่อธิบายไว้ในบันทึกด้านความปลอดภัยที่ Invariant Labs เผยแพร่เมื่อไม่กี่วันก่อน (tool poisoning, shadowing, MCP rug pull) ฉันเป็นผู้เขียนโพสต์บล็อกดังกล่าว

    • ต่างจากที่หลายคนสงสัย ปัญหาด้านความปลอดภัยของการเรียกใช้เครื่องมือ LLM แบบสไตล์ MCP ไม่ได้อยู่ที่การแยกการทำงานของ MCP server implementation ที่แตกต่างกัน
    • MCP server implementation ที่รันในเครื่องควรได้รับการตรวจสอบโดย package manager ที่ใช้ติดตั้ง (ส่วน remote MCP server นั้นตรวจสอบได้ยากกว่าจริง)
    • ปัญหาอยู่ที่มันเป็นรูปแบบพิเศษของ indirect prompt injection ที่เกิดขึ้นเมื่อใช้ MCP ในระบบเอเจนต์
    • เนื่องจากเอเจนต์รวมสเปกของ MCP server ที่ติดตั้งทั้งหมดไว้ใน context เดียวกัน MCP server ที่ไม่น่าเชื่อถือจึงสามารถชักนำพฤติกรรมของ MCP server อื่นได้ง่าย (เช่น server ที่เข้าถึงฐานข้อมูลที่อ่อนไหวได้) เราเรียกสิ่งนี้ว่า tool shadowing
    • นอกจากนี้ ด้วยธรรมชาติที่เป็นไดนามิกของ MCP ทำให้ MCP server สามารถเปลี่ยนชุดเครื่องมือที่ให้บริการเฉพาะกับผู้ใช้บางรายได้ ซึ่งหมายความว่า MCP server สามารถกลายเป็นอันตรายได้ทุกเมื่อ
    • ปัจจุบัน MCP client อย่าง Claude และ Cursor ไม่แจ้งการเปลี่ยนแปลงเหล่านี้ ทำให้ทั้งเอเจนต์และผู้ใช้มีช่องโหว่
    • หากใครสนใจมากขึ้น ลองอ่านโพสต์บล็อกที่อธิบายละเอียดกว่านี้ใน [1] เราศึกษาและทำงานด้าน agent security กันมานานที่ Invariant
    • เรายังเผยแพร่ code snippet ที่ทุกคนสามารถลองได้ รวมถึงการโจมตีแบบ tool poisoning ต่อ WhatsApp MCP server ยอดนิยมด้วย [2]

  • การโจมตีเหล่านี้ส่วนใหญ่เป็นอีกตัวอย่างหนึ่งของการอยู่ผิดด้านของ airlock พวกมันไม่ได้ข้ามขอบเขตสิทธิ์ และเป็นเพียงการทำสิ่งที่ทำได้อยู่แล้วด้วยวิธีที่แปลกออกไป

    • MCP server รันโค้ดในระดับผู้ใช้ และไม่จำเป็นต้องหลอก AI ให้ไปอ่าน SSH key เพราะมันอ่าน key ได้อยู่แล้ว
    • ที่เหลือก็เป็นข้อบ่นแบบเดียวกับที่ใช้กับเครื่องมือ/ระบบนิเวศสำหรับนักพัฒนาอื่น ๆ ได้อยู่ดี (NPM หรือ VS Code Extensions)

  • โจทย์คือการออกแบบสิ่งที่ดีกว่านี้ โดย:

      1. มีมาตรฐานด้านความปลอดภัยที่เหมาะสมพอจนคนจะไม่เขียนบทความว่า "S หมายถึง Security"
      1. ทำให้โปรแกรมยังสามารถให้ชุดความสามารถแบบเดียวกับที่ MCP ที่มีประโยชน์ที่สุดในปัจจุบันมอบให้ได้ โดยไม่เปลี่ยนความสามารถอัตโนมัติให้กลายเป็นสิ่งที่ต้องยืนยันด้วยมือ และโดยทั่วไปไม่ทำลายจุดประสงค์ทั้งหมดของแนวคิดนี้
      1. ไม่ล็อกทุกอย่างไว้ใน marketplace แบบปิดที่มี gatekeeper จากบริษัท
    • อยากเห็นข้อเสนอ เพราะจนถึงตอนนี้สิ่งที่เห็นมีแต่คำพูดกว้าง ๆ ไม่เฉพาะเจาะจงว่า "MCP ไม่ปลอดภัย!!!111" เท่านั้น โดยเฉพาะเมื่อผู้คนลืมไปว่าความปลอดภัยกับความมีประโยชน์เป็นแรงที่สวนทางกัน เรื่องนี้ยิ่งไม่ง่าย

  • บทความดี แต่สงสัยว่าทั้งหมดนี้ถูกสร้างโดย AI หรือเปล่า

    • รูปโปรไฟล์ดูเหมือนสร้างด้วย StableDiffusion, บัญชีเพิ่งสร้างวันนี้, และไม่มีบทความก่อนหน้า
    • อีกทั้งก็หาอ้างอิงอื่นเกี่ยวกับ Elena Cross ไม่เจอ

  • O หมายถึง Observability สัปดาห์นี้ฉันจมลึกกับการสำรวจและเขียน MCP server อยู่

    • implementation ส่วนใหญ่ รวมถึงของเล่นที่ฉันทำเอง ไม่มีทั้ง audit และ metrics เลย Claude เก็บ log output ของ MCP server ไว้ แต่มีไว้เพื่อ debugging ไม่ใช่สำหรับ DevOps/SecOps
    • ในเชิงวัฒนธรรม ปัญหาที่ OP อธิบายเป็นปัญหาใหญ่สำหรับคนสาย non-technical (muggles) ในซับเรดดิตที่เกี่ยวข้อง ผู้คนกำลังสนุกกับการรันโปรแกรม MCP CLI บนเครื่องตัวเอง
    • คอมเมนต์เรื่องความปลอดภัยของ OP อาจชัดเจนสำหรับนักพัฒนา แต่ผู้ใช้กลุ่มนี้ไม่มีมุมมองเลยว่ามันเสี่ยงแค่ไหน
    • ผู้คนกำลังเรียนรู้ Docker และ Claude ก็ใส่วิธีใช้งานไว้ในตัวอย่าง แต่คนส่วนใหญ่ก็แค่ดาวน์โหลด blob แล้วรัน ผู้คนกำลังเขียนโค้ดและรัน MCP server แบบส่ง ๆ กันอยู่
    • เมื่อ MCP แพร่หลายมากขึ้น framework และเครื่องมือต่าง ๆ ก็จะเติบโตขึ้นเพื่อรองรับความปลอดภัย, observability และอื่น ๆ มันเหมือนการสร้างเว็บในช่วงกลางทศวรรษ 90
    • ไม่เกี่ยวกับ OP แต่ระหว่างที่สร้างสิ่งนี้อยู่ การพิมพ์บางอย่างใน Claude Desktop แล้วไป trigger breakpoint ใน VSCode มันน่าตื่นเต้นมาก

  • ใช่ ฉันก็คิดเหมือนกัน แม้ว่าตอนเผยแพร่บันทึกนั้นฉันจะไม่ได้ลงลึกมากนัก

  • ต่อให้ซอฟต์แวร์ที่ใช้อยู่ไม่ได้เป็นอันตรายและถูก implement อย่างปลอดภัย แล้วจะตรวจสอบได้อย่างไรว่ามันถูกใช้งานในแบบที่เราต้องการ?

    • สมมติว่ามี MCP server ที่แก้ไข local file system ได้ และอีกตัวที่แก้ไข object ใน cloud storage ได้ ผู้ใช้จะรับประกันได้อย่างไรว่า LLM agent จะเลือกได้ถูกต้อง?
    • เราอยากให้มีตัวเลือกมากมายโดยไม่ต้องคอยเฝ้าดูทุกการกระทำ แต่การทำแบบนั้นก็น่าจะทำให้เกิดปัญหาเพิ่มขึ้น

  • มากกว่า 43% ของ MCP server implementation ที่ Equixly ทดสอบมีการเรียก shell ที่ไม่ปลอดภัย

    • ทำไมถึงตกหลุมพรางนี้ซ้ำแล้วซ้ำอีกได้ทุกครั้ง

  • สงสัยว่า MCP คืออะไร ฉันพยายามอ่านเอกสารหลายครั้งแล้ว แต่ก็ยังไม่เข้าใจว่ามันแก้ปัญหาอะไร โดยเฉพาะอะไรที่พิเศษเกี่ยวกับ AI agent จนใช้กับ deterministic agent ที่มีมาหลายสิบปีไม่ได้

  • ฉันเคยคิดว่าจุดประสงค์ทั้งหมดของ MCP คือให้ Anthropic แอบฟัง prompt กับ output แล้วเพิ่มข้อมูลฝึกให้ได้มากที่สุด นี่เป็นครั้งแรกที่ฉันรู้ว่ามันเป็น middleware สำหรับโมเดล AI ทั้งหมด