מחקרי Wake Forest חושפים דליפה נרחבת של פרטי גישה במערכות AI

שני מחקרים מאוניברסיטת Wake Forest מצביעים על חולשה משותפת בשתי מערכות AI שצומחות במהירות: פרטי גישה — מפתחות API, טוקנים ונתיבי גישה לשירותים — נמצאים לא פעם במקום שבו סוכני AI, אפליקציות או תוקפים יכולים לקרוא ולנצל אותם.

במחקר אחד נבדקו 17,022 מיומנויות צד שלישי לסוכני AI, ונמצאו 520 מיומנויות בעייתיות שכללו 1,708 בעיות אבטחה. מחקר נוסף בחן 444 אפליקציות iOS המשלבות מודלי שפה (LLM), ומצא כי 282 מהן חשפו במהלך הבדיקה פרטי גישה או מנגנונים שאפשרו להגיע לשירותי ה-AI של המפתחים. 124

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

מה מצא המחקר על מיומנויות לסוכני AI?

החוקרים בחרו מדגם של 17,022 מיומנויות מתוך 170,226 פריטים ב-SkillsMP, שוק פתוח למיומנויות של סוכנים. הם שילבו איתור סטטי של סודות בקוד, בדיקות דינמיות בסביבת Sandbox עם פרטי גישה מדומים, והשוואה בין מטרת המיומנות כפי שהיא מתוארת לבין ההתנהגות שלה בזמן הרצה. 34

הממצאים המרכזיים:

• 520 מיומנויות בעייתיות, ובהן 1,708 בעיות אבטחה, שסווגו ל-10 דפוסים של דליפת פרטי גישה. 416
• 466 מתוך 520 המיומנויות החשופות כללו פרטי גישה שניתן היה לנצל ללא הרשאות מיוחדות — שיעור של 89.6% שניתנים לניצול מיידי, לפי הדיווח. 14
• 76.3% ממקרי הדליפה דרשו בדיקה משולבת של הוראות בשפה טבעית ושל קוד התוכנית.
• 3.1% מהמקרים נבעו מהזרקת פרומפטים בשפה טבעית, ללא קוד בר-ביצוע. 4

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

לפעמים הלוגים הופכים סוד למידע שהמודל יכול לקרוא

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

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

גם פיתוח זדוני וגם רשלני תורמים לבעיה

המחקר מבחין בין שתי סיבות עיקריות לדליפת פרטי גישה:

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

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

לאחר שהחוקרים הודיעו ל-SkillsMP על הממצאים, Wake Forest מסרה שכל המיומנויות הזדוניות שזוהו הוסרו, ושמרבית המיומנויות הפגיעות תוקנו. עם זאת, המחקר מזהיר שתיקון המאגר המקורי אינו בהכרח מספיק: עותקים מפוצלים (forks) עלולים לשמר את פרטי הגישה שנחשפו גם לאחר תיקון המקור. 14

באפליקציות iOS נמצא נתיב אחר להשתלטות על חשבונות LLM

המחקר המקביל בחן 444 אפליקציות iOS עם יכולות LLM. ב-282 מהן — כ-64% — נחשפו בתעבורת הרשת פרטי גישה או מנגנוני גישה לעורף האפליקציה שניתן היה לנצל. 25

דפוסי החשיפה שדווחו כללו:

• טוקנים מסוג JWT שניתנים לשימוש חוזר: 48%
• שרתי Proxy בעורף ללא אימות: 33%
• העברת מפתחות API בטקסט גלוי: 19% 3

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

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

גם קצב התיקון היה איטי. שלושה חודשים לאחר הדיווח האחראי על החולשות, רק 28% מהאפליקציות שנפגעו תיקנו את הבעיה; 72% נותרו ניתנות לניצול בבדיקת המעקב. 311

למה זה חשוב בעידן הפיתוח בעזרת AI?

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

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

הסיכון גובר בתקופה שבה מפתחים משתמשים ב-"Vibe Coding" — יצירה והרכבה מהירה של תוכנה בעזרת AI. מהירות אינה תחליף למודל איומים: עדיין צריך לתכנן בקפידה אימות, ניהול סודות, הרשאות, לוגים ובדיקת תלויות. במחקר על מיומנויות הסוכנים דווח גם כי ב-72% מהמקרים של פרטי גישה שהוטמעו בקוד נמצאו סימנים לפיתוח בסיוע AI, מה שמרמז שדפוסים לא מאובטחים עלולים להתפשט דרך קוד שנוצר אוטומטית או הורכב במהירות. 4

אבטחה כבר בשלב התכנון

הממצאים מצביעים על כמה צעדי בסיס לצוותים שבונים מוצרי AI או מפיצים מיומנויות לסוכנים:

1. להרחיק מפתחות ספק ארוכי-טווח ממכשירי המשתמש ומהקשר המודל. קריאות רגישות למודלים צריכות לעבור דרך שרת מאומת.
2. להשתמש בפרטי גישה קצרי-חיים ומוגבלים בהיקפם. יש ליישם עקרון הרשאות מינימליות ולוודא את תוקף הטוקנים, במקום להניח שעצם החזקתם מספיקה.
3. להשחיר סודות מלוגים ומפלט סטנדרטי. כל מידע שנכנס להקשר של סוכן צריך להיחשב למידע שעלול להיות בר-שחזור בידי המודל או המשתמש.
4. לסרוק קוד, הגדרות, פרומפטים ותלויות לאיתור סודות. ממצאי המחקר מבהירים מדוע יש לבדוק יחד הוראות בשפה טבעית וקוד בר-ביצוע.
5. לבדוק תעבורת רשת והרשאות בעורף. יש לוודא שבקשה שניירטה אינה ניתנת לשימוש חוזר ושאי אפשר לנתב אותה דרך Proxy ללא אימות.
6. להחליף פרטי גישה שנחשפו ולבדוק forks ועותקים. הסרת סוד מהמאגר המקורי אינה מבטיחה שכל הגרסאות שהופצו נקיות.
7. להוסיף בדיקה ברמת הפלטפורמה לפני ההפצה. סינון בשוקי מיומנויות, הנחיות למפתחים, דיווח אחראי ובדיקות אוטומטיות יכולים להשלים את המודעות של המפתחים. 34

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