MCP: כשפרוטוקול AI הופך לדלת פרוצה
דמיינו שרברב שמתקין מערכת צנרת זהה בכל בתי הכלא בארץ. שנה לאחר מכן מגלים שבכל הצינורות יש פתח נסתר שמוביל ישירות לחצר החיצונית. הבעיה אינה בכלא ספציפי — היא בתכנון הצינור עצמו. כל מבנה שהשתמש בו מושפע. כך נראה פגם ארכיטקטוני (Architectural Flaw).
זה בדיוק מה שהתגלה ב-MCP — Model Context Protocol.
מה זה MCP?
Model Context Protocol הוא פרוטוקול שפיתחה Anthropic כדי לאפשר לסוכני AI לתקשר עם כלים חיצוניים. תחשבו על זה כ”שפה משותפת” שמאפשרת למודל AI לגשת לקבצים, לקרוא מסדי נתונים, להפעיל APIs ועוד — בצורה אחידה ומובנית.
הפרוטוקול מיושם ב-SDKs רשמיים של Anthropic בשפות Python, TypeScript, Java ו-Rust. פלטפורמות AI פופולריות כמו LiteLLM, LangChain ו-Flowise נבנו מעל MCP — כלומר, כל אחת מהן יורשת את ההתנהגות שלו. זה בדיוק מה שהופך פגם ארכיטקטוני לאסון: במקום באג אחד בתוצר אחד, קיבלנו חולשה שמשוכפלת לכל מערכת שנגעה בפרוטוקול.
הפגם: STDIO כדלת פרוצה
ב-MCP יש מנגנון תקשורת שנקרא STDIO — הדרך הפשוטה ביותר שתהליך אחד מעביר נתונים לתהליך אחר. כשמשתמשים ב-MCP כדי להפעיל כלי חיצוני, מעבירים לו StdioServerParameters — פרמטרים שמגדירים איזה תהליך יורץ ואיך.
הבעיה: אם קלט חיצוני לא-מסונן (למשל, נתון שהגיע ממשתמש) מוזרק ל-StdioServerParameters — התוקף יכול לשלוט על הפקודה שתרוץ בשרת. זהו Remote Code Execution (RCE): הרצת קוד שרירותית על המכונה הקורבן, מרחוק, ללא הרשאה.
חברת OX Security בדקה את זה בפועל על שש פלטפורמות ייצור — ובכל אחת מהן הצליחה להריץ קוד שרירותי על השרת. לא בסביבת מעבדה. בייצור.
למה פגם ארכיטקטוני מסוכן יותר מבאג?
באג הוא שגיאה בקוד של מוצר אחד. מתקנים אותו בעדכון, מפרסמים patch, עוברים הלאה.
פגם ארכיטקטוני קיים בשכבת הבסיס — בפרוטוקול עצמו. כל מי שבנה מעליו סופג אותו אוטומטית. זה בדיוק מה שקרה כאן:
- 150 מיליון הורדות של חבילות הקשורות ל-MCP ב-PyPI ו-npm
- 200,000 מופעים פגיעים שזוהו בחשיפה
- 10 CVEs שהונפקו — ל-LiteLLM, LangChain, Flowise, ועוד — כולם נובעים מאותה שורש
אי-אפשר לתקן את כולם בבת-אחת. כל צוות צריך לעדכן בנפרד, ובינתיים — כל מופע שלא עודכן עדיין חשוף.
מה מפתחים חייבים לעשות?
אם אתם בונים מערכת שמבוססת על MCP, אלה הצעדים הקריטיים:
- טפלו בכל קלט חיצוני כלא-מהימן: כל נתון שמגיע ממשתמש, מ-API חיצוני, או מכל מקור אחר שאינם שלטים בו — סננו אותו לפני שהוא נוגע ב-StdioServerParameters.
- הגבילו StdioServerParameters: אפשרו רק רשימה מאושרת מראש של פקודות ופרמטרים. אל תרשו לקלט חיצוני להגדיר את הפרמטרים האלו באופן חופשי.
- הריצו ב-Sandbox: בידדו כל שרת MCP בסביבה מבודדת — Container, VM, או סביבת Sandbox ייעודית. כך, גם אם תוקף יצליח להריץ קוד, הנזק יישאר מוגבל לאותה סביבה.
- מנעו חשיפה לאינטרנט: שירותי AI שמריצים MCP לא צריכים להיות חשופים לציבור הרחב. אם שירות כזה חייב להיות נגיש מרחוק — שמרו אותו מאחורי VPN, או הגבילו גישה לפי כתובות IP מאושרות.
הגדולה של הכשל
הסיפור הזה ממחיש עיקרון שחוזר על עצמו בעולם האבטחה: ככל שרכיב נמוך יותר בשכבות התוכנה, כך השפעת הפגיעות גדולה יותר. פרוטוקול שנמצא בשכבת הבסיס של מאות פלטפורמות הוא יעד בעל ערך עצום — ופגם שם מתרבה בקצב שאף צוות אבטחה לא יכול לעמוד בו לבדו.
MCP הוא פרוטוקול צעיר. הוא ימשיך להתפתח, ויותר פלטפורמות ייבנו מעליו. הכשל שהתגלה הוא הזדמנות: לתקן, לחשוב מחדש על ברירות המחדל, ולוודא שהצינורות הבאים שיותקנו — בנויים נכון מהיסוד.
תגובות