בדיקת capgate מול DVMCP
בדקתי את הכלי שלי, capgate, מול עשרה שרתי MCP פגומים בפרויקט Damn Vulnerable MCP (DVMCP).
DVMCP הוא כלי לימודי. כל שרת מדגים מתקפה ספציפית כמו prompt injection, גניבת token, או command injection.
המטרה הייתה פשוטה. כתבתי manifest אמין לכל כלי. ואז שאלתי: האם הגבול ש-capgate יוצר באמת עוצר את המתקפה?
התוצאות מראות בדיוק מה מהדר יכולות (capability compiler) יכול ואינו יכול לעשות.
מה הוא עוצר (במרכז המטרה) באתגר 3, לכלי יש הרשאות מוגזמות. הוא טוען שהוא קורא תיקייה אחת, אך בפועל הוא יכול לקרוא את כל הדיסק. המתקפה מנסה לגנוב פרטי גישה (credentials) של המערכת מתיקייה פרטית. capgate עוצר זאת. הוא מהדר את ה-manifest לתוך Docker container שמקשר (mounts) רק את התיקייה המורשית. הקבצים הפרטיים אינם קיימים בתוך ה-sandbox. המתקפה נכשלת.
מה הוא מכיל (שטח ביניים) באתגר 7, כלי מדליף API key. capgate לא יכול למנוע מהכלי לקרוא את המפתח, אך הוא עוצר את ההוצאה שלו החוצה (exfiltration). הוא יוצר egress proxy שמאפשר חיבורים רק למארח (host) ספציפי אחד. התוקף לא יכול לשלוח את המפתח הגנוב לשרת שלו.
באתגר 8, כלי מאפשר פקודות shell שרירותיות. capgate לא יכול לבטא "אפשר כל shell" בגרמטיקה שלו. במקום זאת, הוא "מכלא" (boxes) את הכלי. גם אם תוקף מריץ פקודה, לתהליך אין גישה לרשת, אין הרשאות נוספות, ויש לו מערכת קבצים לקריאה בלבד (read-only). הנזק מוגבל.
מה הוא מפספס (הגבולות) באתגר 1, המתקפה היא prompt injection. התוקף מרמה את המודל כדי שיתעלם מהוראות. capgate לא עושה דבר כאן. sandbox compiler מגביל את מה שהכלי יכול לגעת בו, אך הוא אינו יכול לשלוט במה ש-LLM אומר.
אם אתם חושבים ש-sandbox עוצר prompt injection, אתם טועים. הוא רק הופך את ה-prompt injection לפחות מועיל על ידי הגבלת הנזק.
סיכום • מניעה נקייה אחת. • ארבע הכלאות (containments) משמעותיות. • שלושה פספוסים כנים.
capgate אינו פתרון קסם (silver bullet). הוא שכבת הגנה אחת. הוא הופך את "השרת הזה יכול להגיע לכל דבר" ל"השרת הזה יכול להגיע לנתיב ספציפי אחד".
Optional learning community: https://t.me/GyaanSetuAi