כך עלינו על הפרצה בפרוטוקול ה-AI של Anthropic שסללה דרך לחטיפת חשבונות

מאת: יובל אלבר, חוקרת אבטחה בחברת הסייבר Cycode

כשארגון Linux Foundation ו-Anthropic הכריזו על MCP, הפרוטוקול הפתוח שנועד לחבר בין עוזרי AI לכלים ולמקורות מידע חיצוניים, היה ברור שמדובר באחד התקנים החשובים ביותר לעולם סוכני ה-AI. אבל כחוקרת אבטחה בחברת הסייבר Cycode, כשאני רואה פרוטוקול חדש שתופס תאוצה, השאלה הראשונה שעולה לי בראש היא: איך בדיוק מנגנון ההתחברות שלו מוודא שהוא מדבר עם השרת הנכון ולא עם מתחזה?

הסקרנות הזו הובילה אותי למסע בלשי בתוך הקוד של ה-Python SDK. בסופו גיליתי סדק כמעט בלתי נראה: כשל אבטחה בדרגת חומרה High שאיפשר לשרת זדוני לחטוף זהויות של משתמשים, לגנוב את מפתחות הגישה השמורים שלהם ולהשיג שליטה מלאה על החשבון – והכול דרך מסך התחברות אמיתי לחלוטין, שאינו מעורר שום חשד.

החיפוש אחר נקודת התורפה

הכול מתחיל בשאלה פשוטה שהאפליקציה צריכה לשאול כשהיא מתחברת לשרת חדש: "איפה דף ההתחברות שלך, ולאן לשלוח את הפרטים כדי לקבל אסימון גישה?". בדרך כלל, הפרוטוקול כולל מנגנון גילוי בטוח: האפליקציה פונה לכתובת שמספק השרת, בודקת מיהו ספק הזהויות, כמו Google, Okta או Azure AD, ומשווה בין מה שהספק מעיד על עצמו לבין הכתובת שזיהתה. אם יש אי-התאמה, המערכת מזהה שמדובר בהתחזות ועוצרת הכול.

אבל מה קורה כשהשרת החיצוני טוען שהוא פשוט לא תומך במנגנון החדיש הזה? במצב כזה, האפליקציה עוברת למסלול גיבוי (Fallback) פשוט יותר, שבו היא מבקשת את הגדרות ההתחברות ישירות משרת ה-MCP עצמו. כשצוללים לתוך הלוגיקה של מסלול הגיבוי הזה, שם בדיוק הכול מתחבר.

הברז שפתח את כל המנגנון

כשניתחתי את מנגנון אימות הזהות, גיליתי תנאי המבוסס על בדיקה פשוטה: הקוד הורה למערכת לבדוק את זהות ספק ההתחברות רק אם התקבלה כתובת מהבדיקה הראשונית. במסלול הגיבוי, מכיוון שהבדיקה הראשונית לא החזירה כתובת, משתנה הכתובת נשאר ריק. המערכת לא הכשילה את בדיקת האבטחה – היא פשוט דילגה עליה לחלוטין ולא הריצה אותה.

המשמעות הייתה מדהימה: שרת זדוני לא צריך להילחם במנגנוני האבטחה או לפרוץ אותם. כל מה שהוא צריך לעשות הוא להחזיר שגיאת "עמוד לא נמצא" (404) כשהאפליקציה שואלת אותו על מנגנון הגילוי הראשוני. האפליקציה עוברת למסלול הגיבוי, מנטרלת בעצמה את בדיקת האבטחה ומאמינה לכל כתובת שהשרת הזדוני יספק לה מכאן ואילך.

כדי להחמיר את המצב, השרת הזדוני יכול פשוט לשקר בבדיקה השנייה, בדיקת כפיתת האישורים, ולטעון שהוא ספק הזהויות האמיתי של המשתמש. מכיוון שהבדיקה הראשונה לא רצה, המערכת מאמינה לשקר הזה ומאפשרת לפרטים הרגישים לצאת לדרך.

המלכודת הפסיכולוגית

כדי להוכיח שההתקפה אינה תיאורטית בלבד, בניתי תרחיש בדיקה מלא. מה שגיליתי היה מטריד במיוחד: ההתקפה הזו אינה דורשת אתר פישינג מזויף או הנדסה חברתית מורכבת. כשתוקף מנצל את הפרצה, הוא מנתב את המשתמש לדף ההתחברות האמיתי והלגיטימי של Google או Okta.

המשתמש רואה כתובת נכונה ותעודת אבטחה תקפה, ומאשר את ההתחברות בראש שקט. אבל ברגע שההתחברות מאושרת, קוד האימות, יחד עם ה-Client Secret השמור ומפתח ההגנה PKCE, שאמור למנוע בדיוק גניבות מסוג זה, נארזים ונשלחים – לא לספק הזהויות, אלא ישירות לידיו של התוקף.

מבחינת המשתמש, השרת פשוט נראה קצת איטי או תקוע. הוא סוגר את הלשונית וממשיך הלאה, ללא שום אינדיקציה לכך שהתוקף מחזיק כעת במפתח הגישה לחשבון שלו.

מהבנה לפתרון בשטח

כדי להוכיח מעל לכל ספק שזו הנקודה הקריטית, הרצתי סדרת ניסויים מבוקרים והראיתי שברגע שבדיקת הזהות מורצת גם במסלול הגיבוי, ההתקפה נבלמת לחלוטין עוד לפני שנשלח פריט מידע רגיש אחד.

דיווחנו על הממצאים באופן מסודר לצוות האבטחה של Linux Foundation, שפעל במהירות ושחרר גרסאות מתוקנות של ה-SDK, הכוללות אימות חובה של מנפיק הזהות בכל מסלולי ההתחברות.

החשיבות של החשיפה הזו חורגת מתקלה נקודתית בקוד. היא מראה עד כמה התקפות על סביבות AI יכולות להיות שקטות. מכיוון שהתוקף מקבל מפתחות גישה קבועים דרך תהליך שנראה תקין לחלוטין למערכות הניטור, הוא עשוי להשיג דריסת רגל מתמשכת במערכות הארגון מבלי להדליק אף נורית אדומה.

הלקח הגדול הוא שמנגנוני אבטחה מתקדמים שווים כקליפת השום אם קיים מסלול עוקף שמנטרל את התנאי להרצתם. ככל שסוכני AI מקבלים יותר אוטונומיה להתחבר לכלים חיצוניים, המורכבות הזו היא בדיוק המקום שבו חוקרי אבטחה חייבים להמשיך ולחפור.