כאשר GPT מותאמים אישית הופכים לדלתות אחוריות בענן: פריצת ה-SSRF של ChatGPT ועתיד אבטחת ה-AI

אם אתה נשאר בתחום האבטחה מספיק זמן, בסופו של דבר אתה מפתח הרגל רע: אתה מפסיק לראות "תכונות" ומתחיל לראות נתיבי תקיפה פוטנציאליים. הסיפור האחרון על "פריצה ל-ChatGPT באמצעות GPT מותאמים אישית שמנצלים פגיעות SSRF כדי לחשוף סודות" הוא דוגמה קלאסית לכך. מה שנראה כמו תכונת פעולות נוחה עבור GPT מותאמים אישית התברר כמעבר ישיר לסביבת הענן של OpenAI. לא היה מדובר בקסם פרומפט אקזוטי, ולא ב"קסם AI" שהשתבש — אלא בבאג ישן מאוד, זיוף בקשות בצד השרת, שהתגלה מחדש בתוך פלטפורמה חדשה מאוד.

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

שחזור הניצול: מ"הוספת פעולה" לאסימון ענן

כדי להבין מה קרה, צריך להבין איך עובדים GPTs מותאמים אישית. הממשק של OpenAI מאפשר להגדיר פעולות (Actions), שהן למעשה ממשקי API חיצוניים שה-GPT שלך יכול לקרוא על בסיס סכימת OpenAPI. עבור המשתמשים, זה מרגיש כמו מתן "כוחות-על" ל-GPT שלכם: הוא יכול לאחזר נתונים, להפעיל זרימות עבודה, להתחבר למערכות פנימיות. מאחורי הקלעים, זה אומר שיש לקוח HTTP אחורי, הפועל בתוך התשתית של OpenAI, שיקרא בשמחה את כתובות ה-URL שתתארו ויזין את התגובות בחזרה למודל.

חוקר מ-Open Security הבחין בדיוק בזה. בזמן ששיחק עם GPTs מותאמים אישית, הוא ראה את הדפוס המוכר: כתובות URL הנשלטות על ידי המשתמש, כפתור "Test" ששולח בקשות בזמן אמת, ושרת שמריץ בבירור בסביבת ענן. כל מי שביצע בדיקות חדירות לענן יזהה את האינסטינקט הבא: לבדוק אם ניתן להטעות את השרת הזה כדי שיקרא כתובות פנימיות בשמך. זו מהות ה-SSRF.

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

המכשול הראשון שעמד בפני החוקר היה ש-Custom GPT Actions איפשר רק כתובות URL מסוג HTTPS, בעוד ששירות המטא-נתונים הוא HTTP בלבד. במבט ראשון, מגבלה זו נראית כמו אמצעי הגנה, אך בפועל היא רק עוד חלק בפאזל. הפתרון היה פשוט: לרשום דומיין HTTPS חיצוני בשליטת החוקר, ולהגדיר אותו להגיב עם הפניה 302 המפנה ל- http://169.254.169.254 URL של מטא-נתונים, ובדקתי אם ה-backend של Actions ביצע את ההפניה. הוא אכן ביצע אותה. לפתע, קריאת HTTPS תמימה למראה בתצורת ה-GPT המותאמת אישית הובילה לקריאת HTTP לנקודת הקצה הפנימית של מטא-נתוני הענן.

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

זה הספיק כדי להשלים את השרשרת. על ידי הגדרת "מפתח API" מזויף ששמו בכותרת היה פשוט מטא-נתונים ושערך היה נכון, החוקר שכנע את ה-backend לכלול את הכותרת המדויקת ש-Azure IMDS מצפה לה. שלבו זאת עם טריק ההפניה, וכעת יש לכם ערוץ SSRF מה-backend של Custom GPT Actions לשירות המטא-נתונים, עם מטא-נתונים: נכון כותרת.

לאחר שהערוץ הזה הוקם, השאר היה כמעט אוטומטי. החוקר ביקש משירות המטא-נתונים אסימון OAuth2 המיועד ל-Azure Management API, תוך שימוש בנתיב IMDS הידוע. התשובה כללה אסימון גישה המקושר לזהות הענן ששימשה את תשתית ChatGPT. אסימון זה יכול, לכל הפחות, לשאול נקודות קצה ניהוליות ולהגיע למשאבים רגישים, בהתאם לרמת ההרשאות של הזהות. בשלב זה, החוקר הפסיק, דיווח על הממצאים באמצעות תוכנית הבאונטי של OpenAI, ו-OpenAI סיווגה את הפגם כבעל חומרה גבוהה ופעלה לתיקונו.

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

שרטוט קוד זעיר של בדיקה בסגנון SSRF

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

import requests from urllib.parse import urljoin def trace_request(base_url: str, path: str = "/"): url = urljoin(base_url, path) print(f"[+] Requesting {url}") try: resp = requests.get(url, timeout=3, allow_redirects=True)
    except Exception as e: print(f"[!] שגיאה: {e}") return print(f"[+] כתובת URL סופית: {resp.url}") print(f"[+] סטטוס: {resp.status_code}") print("[+] שרשרת הפניות:")
    for h in resp.history: print(f" {h.status_code} -> {h.headers.get('Location')}") # היוריסטיקה גסה מאוד: התראה אם נחתנו על IP פנימי if resp.raw._connection and hasattr(resp.raw._connection, "sock"):
        peer = resp.raw._connection.sock.getpeername()[0] print(f"[+] IP של עמית: {peer}") if peer.startswith("10.") or peer.startswith("192.168.") or peer.startswith("169.254."):
            print("[!] אזהרה: ה-backend ביצע הפניה לכתובת פנימית") if __name__ == "__main__": # דוגמה: החלף בנקודת קצה מבוקרת במעבדה שלך trace_request("")

סקריפט כזה אינו "מנצל את ChatGPT", אלא לוכד את אותה צורת חקירה: מתחיל מכתובת URL חיצונית שנחשבת לבטוחה, עוקב אחר הפניות, ומתלונן בקול רם אם לקוח ה-HTTP שלך מוצא את עצמו פתאום מתקשר עם טווחי IP פנימיים או מקומיים. הפיכת תבנית זו לאוטומציה — והפעלתה על הרכיבים המניעים את פעולות ה-AI שלך — היא הרבה יותר שימושית מאשר רק לקרוא על האירוע.

זה לא "באג ב-AI"; זו התעללות בענן מהסוג הישן בשלב חדש.

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

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

מנקודת מבט זו, אירוע זה הוא פשוט OWASP SSRF בתחפושת אחרת. התנאים מוכרים: כתובות URL המושפעות על ידי המשתמש, שרת שיכול להגיע לנקודות קצה פנימיות או מיוחדות, בקרות יציאה חסרות או לא שלמות, ושירות מטא-נתונים בענן הנגיש מדי מעומסי עבודה רגילים. ההבדל הוא שנקודת הכניסה כבר אינה טופס אינטרנט קלאסי או שדה JSON, אלא בלוק תצורה שתוכנן כדי להפוך את ה-GPT המותאמים אישית לחזקים יותר.

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

AI כמרכז אינטגרציה: הרחבת משטחי התקיפה והזזת גבולות האמון

הסיפור המעניין יותר שמאחורי באג זה הוא אדריכלי. פלטפורמות AI הופכות במהירות למרכזים אינטגרטיביים. GPT מותאם אישית לצוות מכירות עשוי לתקשר עם CRM, מערכת חיוב ומאגר מסמכים. GPT המתמקד באבטחה עשוי לתקשר עם סורקים, מערכות הנפקת כרטיסים ו-CI/CD. בכל מקרה, ה-LLM אינו הנכס; הנכסים הם הנתונים והפעולות שמאחורי מחברים אלה.

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

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

כמה פריבילגיות יש לזהויות המשמשות את עומסי העבודה הללו? במקרה של ChatGPT, החוקרים הצליחו לבקש אסימון עבור ממשק ה-API של Azure Management. גם אם אסימון זה הוגבל על ידי הקצאת תפקידים, הוא עדיין מייצג סוד בעל ערך רב. בארגונים רבים, הפיתוי להעניק הרשאות נרחבות ל"תשתית הפלטפורמה" הוא חזק, מכיוון שהדבר מפשט את הפריסה. עבור כל דבר שניתן להניע בעקיפין באמצעות קלט של המשתמש – במיוחד באמצעות בינה מלאכותית – פיתוי זה הוא מסוכן.

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

מאירוע בודד למתודולוגיית בדיקה חוזרת

עבור מפתחים ומפתחים, הערך האמיתי של סיפור זה אינו באג ספציפי, אלא תפיסת הבדיקה שהוא ממחיש. החוקר התייחס למעשה ל-Custom GPT Actions כאל סוג חדש ומוזר של לקוח HTTP, ואז עבר על רשימת בדיקה מוכרת: האם אני יכול לשלוט ב-URL, האם אני יכול להגיע למארחים פנימיים, האם אני יכול לעשות שימוש לרעה בהפניות, האם אני יכול להזריק כותרות, האם אני יכול לפגוע במטא-נתונים, האם אני יכול להפוך את זה לאסימון ענן?

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

כדי להמחיש זאת מעט יותר, ניתן לחשוב על "סקירת SSRF של פעולות AI" כעל רצף פשוט וניתן לשחזור, כמו זה:

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

זה המקום שבו כלי אבטחה מיוחדים המותאמים ל-AI מתחילים להיות חשובים. סורק אינטרנט גנרי עשוי שלא לדעת כיצד לנווט בממשק משתמש שמסתיר קריאות רשת מאחורי פעולות (Actions) או כיצד להסיק מסקנות לגבי סכמות OpenAPI המשמשות בתוך הגדרת GPT. לעומת זאת, פלטפורמת בדיקות חדירות מונעת AI כגון Penligent יכולה לטפל בסכמות ובתצורות אלה כקלטות מדרגה ראשונה. ניתן לדמיין זרימת עבודה שבה מייצאים את תצורת ה-Actions עבור קבוצת GPTs מותאמים אישית או כלי AI אחרים, מזין אותם לתוך צינור בדיקות סוכני, ומאפשר לו לחפש באופן שיטתי תנאים של SSRF, הפניות לא בטוחות, גישה בלתי מוגבלת לרשת וחשיפת מטא-נתונים.

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

סוג כזה של זרימת עבודה משיג שתי מטרות. הוא מכניס את פלטפורמות ה-AI לאותו מעגל אבטחה מבוסס ראיות שממנו נהנות כבר יישומים אינטרנטיים ו-API, והוא מנצל את אותן יכולות LLM שתוקפים ישתמשו בהן בהכרח, אך לשירות המגנים. הבאג שפגע ב-ChatGPT כבר אינו הפתעה חד-פעמית; הוא הופך למקרה מבחן בסוויטת רגרסיה שניתן להריץ בכל פעם שמכניסים אינטגרציה חדשה או משנים את תשתית ה-Actions.

שיעורים מעשיים לצוותים הבונים על גבי פלטפורמות AI

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

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

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

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

מעבר לכותרת

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

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

אם נעשה זאת, המורשת של אירוע זה לא תהיה רק "ל-ChatGPT היה פעם SSRF". היא תהפוך למקרה בוחן של איך לחשוב על אבטחת AI: להתייחס למודלים כאל מרכיב אחד במערכת גדולה יותר, להתייחס לאינטגרציות כאל משטחי תקיפה רציניים, ולהשתמש באוטומציה ובחוכמה אנושית – בין אם באמצעות פלטפורמות כמו Penligent או צינורות פנימיים משלכם – כדי להפוך דאגות מעורפלות להבטחות קונקרטיות, ניתנות לבדיקה ומגובות בראיות. זהו סוג הסיפור ששווה לספר ב-Medium, ואפילו יותר שווה לחיות בתוך ארגון ההנדסה שלכם.