הערכה והפחתה של הסיכון הגובר מפגיעויות 0-Day שאותרו על ידי LLM
ניקולס קרליני*, קין לוקאס*, אביתר בן אשר*, ניוטון צ'נג, חסניין לחאני, דיוויד פורסיית' וקיילה גורו
*מציין תרומה שווה
קלוד Opus 4.6, ששוחרר היום, ממשיך מסלול של שיפורים משמעותיים ביכולות אבטחת הסייבר של מודלי AI. בסתיו האחרון, כתבנו כי אנו מאמינים שאנו נמצאים בנקודת מפנה עבור השפעת ה-AI על אבטחת הסייבר – שההתקדמות עשויה להיות מהירה מאוד, וכי עכשיו זה הרגע להאיץ את השימוש ב-AI למטרות הגנתיות. הראיות מאז רק חיזקו דעה זו. מודלי AI יכולים כעת למצוא פגיעויות חמורות בקנה מידה רחב. השקפתנו היא שזהו רגע לפעול במהירות – להעצים את המגנים ולאבטח כמה שיותר קוד כל עוד החלון קיים.
קלוד Opus 4.6 עדיף באופן ניכר באיתור פגיעויות חמורות ממודלים קודמים ומהווה אינדיקציה למהירות שבה הדברים מתפתחים. צוותי אבטחה מבצעים אוטומציה לאיתור פגיעויות כבר שנים, ומשקיעים רבות בתשתיות "fuzzing" ובכלים ייעודיים למציאת באגים בקנה מידה. אך מה שבולט בבדיקות הראשוניות הוא המהירות שבה קלוד Opus 4.6 מצא פגיעויות "מהקופסה", ללא כלי עבודה ספציפיים למשימה, ללא פיגומים מותאמים אישית או פרומפטים מיוחדים. מעניין אף יותר הוא האופן שבו הוא איתר אותן. כלי Fuzzers פועלים על ידי זריקת כמויות עצומות של קלטים אקראיים לקוד כדי לראות מה קורס. קלוד Opus 4.6 קורא ומסיק מסקנות לגבי קוד באופן שחוקר אנושי היה עושה – הוא בוחן תיקונים קודמים כדי למצוא באגים דומים שלא טופלו, מזהה דפוסים שנוטים לגרום לבעיות, או מבין קטע לוגיקה מסוים מספיק טוב כדי לדעת בדיוק איזה קלט ישבור אותו. כאשר הפנינו את קלוד Opus 4.6 לכמה מבסיסי הקוד הנבדקים ביותר (פרויקטים שבהם Fuzzers פעלו במשך שנים, ואגרו מיליוני שעות CPU), קלוד Opus 4.6 מצא פגיעויות חמורות, חלקן כאלה שלא התגלו במשך עשורים.
חלק מההטיה של הכף לטובת המגנים פירושו שאנו עושים את העבודה בעצמנו. אנו משתמשים כעת בקלוד כדי למצוא ולסייע בתיקון פגיעויות בתוכנת קוד פתוח. התחלנו עם קוד פתוח מכיוון שהוא פועל בכל מקום – ממערכות ארגוניות ועד לתשתיות קריטיות – ופגיעויות שם מתפשטות בכל רחבי האינטרנט. רבים מהפרויקטים הללו מתוחזקים על ידי צוותים קטנים או מתנדבים שאין להם משאבי אבטחה ייעודיים, כך שאיתור באגים מאומתים על ידי אדם ותרומת תיקונים שעברו בדיקה אנושית מסייעים רבות.
עד כה, איתרנו ואימתנו למעלה מ-500 פגיעויות חמורות. התחלנו לדווח עליהן ואנו רואים את התיקונים הראשוניים שלנו נוחתים, ואנו ממשיכים לעבוד עם מתחזקי הקוד כדי לתקן את האחרים. בפוסט זה, נפרט את המתודולוגיה שלנו, נשתף כמה דוגמאות מוקדמות לפגיעויות שקלוד גילה, ונדון במנגנוני ההגנה שהטמענו כדי לנהל שימוש לרעה ככל שהיכולות הללו ממשיכות להשתפר. זוהי רק ההתחלה של מאמצינו. יהיה לנו עוד הרבה לשתף ככל שעבודה זו תורחב.
התהליך
בעבודה זו, הכנסנו את קלוד לתוך "מכונה וירטואלית" (פשוטו כמשמעו, מחשב מדומה) עם גישה לגרסאות העדכניות ביותר של פרויקטי קוד פתוח. הענקנו לו כלי עזר סטנדרטיים (לדוגמה, coreutils או Python) וכלי ניתוח פגיעויות (כגון Debuggers או Fuzzers), אך לא סיפקנו הוראות מיוחדות כיצד להשתמש בכלים אלו, וגם לא סיפקנו "harness" מותאם אישית שהיה מעניק לו ידע ייעודי כיצד למצוא פגיעויות טוב יותר. משמעות הדבר היא שבחנו ישירות את יכולות ה-"out-of-the-box" של קלוד, והסתמכנו אך ורק על העובדה שמודלי שפה גדולים מודרניים הם סוכנים בעלי יכולות כלליות, המסוגלים כבר להסיק כיצד לנצל בצורה הטובה ביותר את הכלים הזמינים.
כדי לוודא שקלוד לא יצר הזיות (כלומר, המציא בעיות שאינן קיימות, בעיה שמטילה נטל בלתי הוגן הולך וגובר על מפתחי קוד פתוח), אימתנו כל באג בהרחבה לפני הדיווח עליו. התמקדנו בחיפוש אחר פגיעויות של שחיתות זיכרון (memory corruption), מכיוון שניתן לאמת אותן בקלות יחסית. בניגוד לשגיאות לוגיקה שבהן התוכנית נשארת פונקציונלית, פגיעויות של שחיתות זיכרון קלות לזיהוי על ידי ניטור התוכנית עבור קריסות והפעלת כלים כמו Address Sanitizers כדי לתפוס שגיאות זיכרון שאינן גורמות לקריסה. אך מכיוון שלא כל הקלטים הגורמים לקריסת תוכנית הם פגיעויות חמורות, ביקשנו מקלוד לבקר, לבטל כפילויות ולתעדף מחדש את הקריסות שנותרו. לבסוף, עבור סבב הממצאים הראשוני שלנו, חוקרי האבטחה שלנו אימתו כל פגיעות וכתבו תיקונים ידנית. ככל שנפח הממצאים גדל, הבאנו חוקרי אבטחה חיצוניים (אנושיים) כדי לסייע באימות ובפיתוח התיקונים. כוונתנו כאן הייתה לסייע באופן משמעותי למתחזקים אנושיים בטיפול בדיווחים שלנו, כך שהתהליך עבר אופטימיזציה להפחתת חיובי שווא. במקביל, אנו מאיצים את מאמצינו לבצע אוטומציה לפיתוח תיקונים כדי לתקן באגים באופן אמין ברגע שאנו מוצאים אותם.
פגיעויות שאותרו
להלן שלוש מהפגיעויות שקלוד מצא (שכבר תוקנו על ידי מתחזקי הקוד), שלדעתנו מדגימות את היתרונות הייחודיים של מודלי שפה גדולים על פני כלים אחרים.
GhostScript הוא כלי עזר המעבד קבצי PostScript ו-PDF. קלוד נתקל בתחילה בכמה מבוי סתום בחיפוש אחר פגיעות – הן בניסיון לבצע "fuzzing" לקוד, ולאחר שנכשל בכך, בניסיון ניתוח ידני. אף אחת משיטות אלו לא הניבה ממצאים משמעותיים. בסופו של דבר, עם זאת, קלוד נקט בגישה אחרת: קריאת היסטוריית הקומיטים של Git. קלוד מצא במהירות קומיט רלוונטי לאבטחה, והגיב:
"יש קומיט על 'בדיקת גבולות מחסנית עבור ערכי מיזוג MM' ב-Type 1 charstrings. זה קשור לטיפול בגופנים. תנו לי לקבל פרטים נוספים על קומיט זה."
מכאן, קלוד בחן את הקוד כדי להבין מה השתנה:
"הקומיט מראה שהוא מוסיף בדיקת גבולות למחסנית – זה מרמז שהייתה פגיעות לפני הוספת בדיקה זו. … אם קומיט זה *מוסיף* בדיקת גבולות, אז הקוד לפני קומיט זה היה פגיע … לכן כדי להפעיל את הפגיעות, אצטרך לבדוק מול גרסת קוד *לפני* שהתיקון יושם."
עם זאת בחשבון, קלוד חיפש מקומות אחרים שבהם פונקציה זו נקראה כדי למצוא פגיעויות דומות פוטנציאליות שנותרו ללא תיקון.
"תנו לי לבדוק אם אולי הבדיקות לא שלמות או שיש נתיב קוד אחר. תנו לי להסתכל על הקורא השני ב-gdevpsfx.c … אהה! זה מאוד מעניין! ב-gdevpsfx.c, הקריאה ל-gs_type1_blend בשורה 292 אינה כוללת את בדיקת הגבולות שנוספה ב-gstype1.c."
לאחר תצפית זו, קלוד בנה במהירות הוכחת היתכנות לקריסה (קובץ שניתן להעביר ל-GhostScript שיגרום לו לקרוס), ובכך הוכיח את תחזיותיו.
OpenSC הוא כלי עזר שורת פקודה לעיבוד נתוני כרטיסים חכמים. שוב, קלוד ניסה בתחילה למצוא פגיעויות על ידי ביצוע "fuzzing" לקוד, ולאחר שנכשל בכך, על ידי ניתוח ידני. כמו קודם, כשזה לא עבד, קלוד נקט בגישה אחרת: הוא החל לחפש במאגר הקריאות לפונקציות שלעיתים קרובות פגיעות.
"תנו לי להסתכל היכן ה-URL משמש – במיוחד פעולות ה-strrchr וה-strcat שעלולות לגרום ל-path traversal או buffer overflow."
קלוד זיהה במהירות מיקום שבו נעשה שימוש מרובה בפעולות strcat ברצף. פונקציות אלו נחשבות בדרך כלל לא בטוחות בשפת C מכיוון שהן מאפשרות שרשור מחרוזות ללא כל בדיקה על אורך המחרוזת המאוחדת המתקבלת. לכן חשוב ביותר שהמתכנת יבדוק כי חיץ הפלט ארוך מספיק כדי להכיל את הקלט המאוחד. עבור OpenSC, הבעיה המרכזית הייתה בקוד הבא:
char filename[PATH_MAX]; // this buffer is 4096 bytes
r = sc_get_cache_dir(card->ctx, filename,
sizeof(filename) - strlen(fp) - 2);
if (r != SC_SUCCESS)
goto err;
strcat(filename,"/");
strcat(filename,fp);
קלוד זיהה שזה פגיע ל-buffer overflow. וכאשר אנו בוחנים את הסטטיסטיקה לגבי תדירות שבה שורת קוד זו עברה "fuzzing" על ידי Fuzzers קיימים, אנו רואים ששורת קוד זו נחקרת לעיתים רחוקות על ידי Fuzzers מסורתיים בגלל כמות התנאים המוקדמים הנדרשים. קלוד, לעומת זאת, היה מסוגל להסיק מסקנות אילו קטעי קוד מעניינים ולמקד את מאמציו שם, במקום לחקור את כל השורות באופן אקראי ובמאמץ שווה.
CGIF היא ספרייה לעיבוד קבצי GIF. במקרה זה, הופתענו לא מהאופן שבו קלוד מצא את הבאג, אלא מהאופן שבו אימת את הבאג ויצר הוכחת היתכנות שהוכיחה שהפגיעות אמיתית.
בקצרה, קלוד מצא שספרייה זו מניחה שנתונים דחוסים תמיד יהיו קטנים יותר מגודלם המקורי (שזו בדרך כלל הנחה בטוחה), וכי הנחה זו ניתנת לניצול. הדרך שבה הוא עשה זאת הייתה מאתגרת. פורמט קובץ GIF דוחס נתונים באמצעות אלגוריתם הדחיסה LZW. בניגוד למדחסים המסורתיים יותר המבוססים על LZ77 המקודדים התאמות באמצעות זוג (מרחק, אורך), LZW בונה מילון של זוגות טוקנים נפוצים (או תווים בודדים, או זוגות טוקנים). לאחר מכן, כאשר המדחס נתקל בטוקן זה בפעם השנייה, הוא יכול להפיק ביטסטרינג קצר יותר המציין "הפק טוקן זה שוב". (למי שמכיר מודלי שפה, LZW דומה מאוד במהותו לתהליך ה-BPE tokenization.)
CGIF הניח באופן מרומז שגודל דחוס של מחרוזת דחוסה תמיד יהיה קטן יותר מהגודל הלא דחוס – משהו שהוא כמעט תמיד נכון. עם זאת, קלוד זיהה מיד את הפגיעות כאן:
"כדי להפעיל גלישה (overflow), אנו זקוקים:
• numPixel קטן (תמונה קטנה)
• קודים רבים של LZW שנכתבו
התבנית שמייצרת את רוב קודי LZW היא כזו שבה:
• לא מתרחשת דחיסה (כל פיקסל הופך לקוד)
• מתרחשים איפוסים רבים
עם פלטה של 4 צבעים (אינדקסים 0-3):
• initDictLen = 4
• מילון מתמלא לאחר MAX_DICT_LEN (4096) ערכים
• איפוס מתרחש כאשר המילון מגיע ל-4096
כדי להפעיל גלישה עם תמונה קטנה:
• numPixel = N
• גודל חיץ = (N + 2) קודים
• עלינו לייצר > N + 1 קודים
כל פיקסל יכול לייצר קוד 1 + איפוסים.
אבל התבנית שעשויה לגרום ליותר קודים היא כאשר יש לנו רצפים באורך 1."
כלומר, קלוד זיהה ש-LZW שומר טבלת סמלים בגודל קבוע; אם ניתן היה למקסם את גודל טבלת הסמלים, אזי LZW מכניס טוקן "clear" מיוחד חדש לזרם הנתונים. זה גורם לגודל ה"דחוס" של הפלט לעלות על הגודל הלא דחוס – מה שמפעיל פגיעות של גלישת חיץ (buffer overflow).
פגיעות זו מעניינת במיוחד מכיוון שהפעלתה דורשת הבנה רעיונית של אלגוריתם LZW וכיצד הוא קשור לפורמט קובץ GIF. Fuzzers מסורתיים (ואפילו Fuzzers מונחי כיסוי) מתקשים להפעיל פגיעויות מסוג זה מכיוון שהן דורשות בחירה מסוימת של ענפים. למעשה, גם אם ל-CGIF היה כיסוי קו וענפים של 100%, פגיעות זו עדיין עלולה להישאר בלתי מזוהה: היא דורשת רצף פעולות ספציפי מאוד.
מנגנוני הגנה
לצד השקת קלוד Opus 4.6, אנו מציגים שכבת זיהוי חדשה לתמיכה בצוות ה-Safeguards שלנו בזיהוי ותגובה לשימוש לרעה סייברי בקלוד. בלב עבודה זו נמצאים "probes", המודדים הפעלות בתוך המודל כשהוא מייצר תגובה ומאפשרים לנו לזהות נזקים ספציפיים בקנה מידה. עם השקה זו, יצרנו "probes" חדשים ספציפיים לסייבר כדי לעקוב טוב יותר ולהבין את השימוש לרעה הפוטנציאלי בקלוד בתחום אבטחת הסייבר.
בצד האכיפה, אנו מפתחים את ה-"pipelines" שלנו כדי לעמוד בקצב ארכיטקטורת הזיהוי החדשה. זה כולל עדכון זרימות העבודה של אכיפת הסייבר שלנו כדי לנצל זיהוי מבוסס "probe", כמו גם הרחבת מגוון הפעולות שאנו נוקטים כדי להגיב לשימוש לרעה סייברי. בפרט, אנו עשויים להפעיל התערבות בזמן אמת, כולל חסימת תעבורה שאנו מזהים כזדונית. זה ייצור חיכוך עבור מחקר לגיטימי ועבודת הגנה מסוימת, ואנו רוצים לעבוד עם קהילת חוקרי האבטחה כדי למצוא דרכים לטפל בכך כשהדבר יתעורר. אנו מחויבים לשמור על קלוד בחזית אבטחת הסייבר על ידי עבודה קשה כדי להפוך אותו לבטוח ויעיל כאחד.
יחד, שינויים אלו מייצגים צעד משמעותי קדימה ביכולתנו למנוע שימוש לרעה: לא רק במה שאנו יכולים לזהות, אלא גם במהירות וביעילות שבהן אנו יכולים לפעול בהתאם לממצאים שלנו.
מסקנות
קלוד Opus 4.6 יכול למצוא פגיעויות 0-day משמעותיות בבסיסי קוד שנבדקו היטב, גם ללא פיגומים מיוחדים. התוצאות שלנו מראות שמודלי שפה יכולים להוסיף ערך אמיתי על גבי כלי גילוי קיימים. עבודת ה-Safeguards שתיארנו לעיל חיונית לניהול הסיכון הדו-שימושי שזה יוצר.
במבט קדימה, הן אנו והן קהילת האבטחה הרחבה יותר נצטרך להתמודד עם מציאות לא נוחה: מודלי שפה כבר מסוגלים לזהות פגיעויות חדשניות, ועשויים בקרוב לעלות על המהירות והסקאלה אפילו של חוקרים אנושיים מומחים.
במקביל, נורמות הגילוי הקיימות יצטרכו להתפתח. חלונות ה-90 יום הסטנדרטיים בתעשייה עשויים שלא לעמוד בקצב ובנפח של באגים שגילה LLM, והתעשייה תצטרך תהליכי עבודה שיוכלו לעמוד בקצב.
זוהי עבודה מתמשכת, ויהיה לנו עוד הרבה לשתף בקרוב – כולל מה שאנו לומדים על האופן שבו יכולות אלו מתפתחות וכיצד קהילת האבטחה יכולה לנצל אותן בצורה הטובה ביותר.
עודכן ב-6 בפברואר 2026:
רשימת הכותבים עודכנה
