חזרה לכל המאמרים
    AgentCorruption: איך סוכן AWS אחד הגיע לשכנים שלו
    AI SecurityAWSAgentCoreIAMPrompt Injection

    AgentCorruption: איך סוכן AWS אחד הגיע לשכנים שלו

    Y

    Yoni Fraimorice

    שיתוף:

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

    זה הלב של AgentCorruption, מחקר ש-Zenity Labs פרסמה ב-8 באוקטובר על Amazon Bedrock AgentCore.

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

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

    אלה התוצאות שעליהן Zenity דיווחה. לא שחזרתי את התקיפה באופן עצמאי. AWS חולקת על ההגדרה כחולשה: היא אמרה ל-The Next Web שההתנהגות מתועדת, שהגישה תלויה בהרשאות שהמפתח העניק ושלקוחות צריכים ליישם הרשאות מינימליות.

    השרשרת התחילה בכלי שימושי

    סוכן הבדיקה הציבורי של Zenity השתמש במסגרת Strands של AWS וקיבל כלי שיכול לבצע בקשות HTTP. Zenity אומרת ששחזרה את התוצאה גם עם כלי shell.

    AgentCore מריץ סשנים בתוך microVMs מבודדים של Firecracker. בתוך המכונות האלה, MicroVM Metadata Service, או MMDS, מספק פרטי גישה זמניים של תפקיד ההרצה. AWS מתארת את MMDS כדומה ל-EC2 Instance Metadata Service, שמוכר בשם IMDS.

    תיעוד ניהול פרטי הגישה של AWS מגדיר כיום את הגבול באופן ברור: כל קוד או גורם שפועל בתוך ה-VM יכול לפנות לנקודת המטא-דאטה ולקבל את פרטי הגישה האלה.

    זה חשוב במיוחד לסוכנים. משתמש ציבורי אינו צריך גישת רשת ישירה ל-VM אם לסוכן יש כלי web או command גמיש ואפשר לשכנע אותו להשתמש בו.

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

    בשלב הזה, הזרקת הפרומפט כבר לא הייתה הבעיה המרכזית. השאלה הפכה ל: מה תפקיד ה-IAM הזה יכול לעשות?

    הרשאות רחבות יצרו נתיב לתנועה רוחבית

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

    ניתוח התפקיד של Zenity אומר שתפקיד ההרצה שהיה ברירת המחדל באותה תקופה השתמש בתבניות wildcard על משאבים בחשבון ובאזור.

    הצוות מדווח שהשתמש בגילוי קבוצות לוגים ב-CloudWatch כדי למצוא מזהים של סוכנים וזיכרונות. הרשאות ECR אפשרו למשוך תמונות container של סוכנים אחרים. הרשאות AgentCore אפשרו להפעיל runtimes אחרים ולקרוא אירועי שיחה. הרשאות כתיבה לזיכרון אפשרו להוסיף אירועים שיכולים להשפיע על סשנים עתידיים. לפי הדיווח, הרשאה ל-Secrets Manager כיסתה פרטי גישה של כמה ספקים חיצוניים.

    העיצוב המסוכן לא היה רק ״סוכן יכול לקרוא את התפקיד של עצמו״. הוא היה:

    טקסט
    פרומפט לא מהימן
  → כלי רשת או shell גמיש
  → פרטי הגישה של תפקיד ההרצה
  → גישת wildcard לסוכנים שכנים ולשירותים משותפים

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

    AWS אומרת שזו התנהגות מתועדת

    AWS אמרה ל-The Next Web שהמחקר של Zenity ״מציג באופן לא מדויק התנהגות צפויה ומתועדת כחולשה״. AWS הדגישה שגישה לחשבון AWS אחר דורשת הרשאות מפורשות גם בתפקיד ההרצה וגם במשאב היעד.

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

    התיעוד הנוכחי של AWS גם מזהיר מפתחים שקוד בתוך ה-microVM יכול לקבל את פרטי הגישה של תפקיד ההרצה. מדריך האבטחה שלה אומר שמדיניות IAM שנוצרת ב-CLI מיועדת לפיתוח ובדיקות, לא לפרודקשן, וממליץ על מדיניות מותאמת עם ARNs מדויקים.

    הפלטפורמה השתנתה במהלך תהליך הדיווח. Zenity אומרת שסוכנים חדשים השתמשו ב-IMDSv2 בלבד החל מ-14 בפברואר 2026. היא גם אומרת שעד 29 בספטמבר AWS הסירה כמה הרשאות רחבות מתפקיד ברירת המחדל, כולל הרשאות ששימשו להפעלת סוכנים אחרים, לקריאת שיחות ולגישה ל-Secrets Manager.

    מדריך האבטחה הנוכחי של AgentCore אומר ש-runtimes חייבים להפעיל MMDSv2 ומתעד את requireMMDSV2: true.

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

    הרשאות מינימליות: זהות ענן נפרדת לכל סוכן

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

    לכל תפקיד:

    • אפשרו רק את פעולות AWS שהסוכן חייב לבצע.
    • הגבילו את Resource ל-runtime, למודל, ל-bucket, לסוד, ל-repository, לזיכרון ולקבוצת הלוגים המדויקים.
    • הסירו פעולות בין סוכנים, כמו הפעלת runtime או גישה לזיכרון, אלא אם הן דרישת מוצר מוגדרת.
    • אל תשתמשו בפרודקשן במדיניות שנוצרה עבור quick starts או הדגמות CLI.
    • ודאו שכוחו של התפקיד שווה או נמוך מכוח המשתמשים שרשאים להפעיל את הסוכן.
    • הוסיפו aws:SourceAccount ו-aws:SourceArn צר ל-trust policy.
    • השתמשו ב-IAM Access Analyzer ובדקו גם נתיבים שאמורים להיחסם.

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

    להקשיח את המטא-דאטה ואת הכלים שמסביבו

    ראשית, הכינו רשימה של כל runtime ובדקו ש-MMDSv2 נדרש. ב-AgentCore, עדכנו runtimes ישנים עם metadataConfiguration.requireMMDSV2 שמוגדר ל-true, ואז פרסו מחדש כשצריך.

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

    הוסיפו גבול שני בתוך הכלי:

    • חסמו כתובות link-local, loopback, private ויעדים אסורים אחרים לפני יצירת החיבור.
    • בדקו שוב את כתובת ה-IP אחרי פתרון DNS ובכל הפניה.
    • השתמשו ברשימת יעדים מאושרים לסוכנים ציבוריים במקום בגישת web כללית.
    • הפעילו כלי shell והרצת קוד ב-runtimes נפרדים ולא ציבוריים עם תפקידים צרים יותר.
    • התריעו על פניות לנתיבי מטא-דאטה ועל קריאות לא צפויות ל-STS, ל-ECR, ל-AgentCore Memory או ל-Secrets Manager.

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

    ארגז החול הוא רק גבול אחד

    AgentCorruption הוא לקח ענן עם נקודת כניסה של AI.

    הזרקת פרומפט נתנה לסוכן הבדיקה של Zenity הוראה גרועה. המטא-דאטה סיפק את הזהות. הרשאות IAM קבעו כמה רחוק הזהות יכולה לנוע.

    התיקון האמין והקטן ביותר אינו system prompt חכם יותר. הוא תפקיד שהופך למשעמם כשגונבים אותו.

    מקורות

    צילום ראשי: Server Rack with Spaghetti-Like Mass of Network Cables, צילום של Kim Scarborough מ-25 בינואר 2006. רישיון CC BY-SA 2.0. הוקטן מ-2560 x 1920 ל-1920 x 1440 פיקסלים ונדחס כ-JPEG; ללא עריכות נוספות. זהו צילום להמחשה של תשתית מחוברת, והוא אינו מציג את AWS, את AgentCore, את Zenity או את סביבת המחקר שדווחה. אין בו הבעת תמיכה.

    שיתוף: