ה-AI של Google פרץ לשלוש חברות אמיתיות. כל מה שהוא היה צריך זה סיסמה חלשה.
ב־19 בספטמבר Google אישרה אירוע חריג שהתרחש ארבעה חודשים קודם לכן ולא פורסם עד עכשיו: מודל Gemini שלה הצליח לפרוץ באופן אוטונומי למערכות של שלוש חברות אמיתיות.
לא מדובר במתקפת סייבר יזומה.
זה קרה במסגרת תרגיל Capture the Flag מבוקר של חברת אבטחת ה־AI הישראלית Irregular. המודל קיבל משימה פשוטה לכאורה: לאתר מידע במערכות של חברה פיקטיבית בתוך סביבת בדיקות.
אלא ששני דברים השתבשו.
למודל לא הייתה אמורה להיות גישה לאינטרנט — אבל בפועל הייתה לו.
ובמקביל, שם החברה הפיקטיבית שנבחר לתרגיל היה גם שמה של חברה אמיתית.
מכאן הכול התקדם מהר.
Gemini חיפש מידע ברשת, איתר מערכות שהוא חשב שהן חלק מסביבת התרגיל — והצליח להיכנס אליהן.
בשלושת המקרים הוא עצר ברגע שהבין שמדובר במערכות אמיתיות.
אבל מה שמעניין כאן הוא לא עצם העובדה ש־AI הצליח לפרוץ למערכת.
מה שמעניין הוא איך הוא עשה את זה.
לא Zero-Day. לא חולשה מתוחכמת. סיסמה.
באחד המקרים Gemini פשוט ניסה שוב ושוב לנחש את הסיסמה — עד שהצליח.
בשני המקרים האחרים הוא מצא Credentials שנשמרו בטעות ב־Repository ציבורי, והשתמש בהם.
וזה הכול.
לא exploit חדש. לא חולשת Zero-Day. לא מתקפת Supply Chain.
רק שתי שיטות ישנות מאוד:
לנחש סיסמה, או למצוא אחת שמישהו השאיר חשופה.
וזו בדיוק הסיבה שהאירוע הזה חשוב.
שלוש החברות לא היו יעד מיוחד. הן לא עשו משהו יוצא דופן. המערכות שלהן פשוט היו נגישות מהאינטרנט, וה־Credentials שלהן היו חלשים או חשופים.
זה תיאור שמתאים גם היום לאינספור שרתי Production.
מה באמת השתנה
Password Guessing קיים כבר עשרות שנים.
החידוש הוא לא בטכניקה.
החידוש הוא מי שמבצע אותה.
תוקף אנושי צריך לבחור מטרות, לאסוף מידע, לנסות, לטעות, לשנות כיוון ולהמשיך.
Agent אוטונומי יכול לעשות את כל זה לבד.
הוא מחפש מידע ציבורי, מצליב מקורות, מזהה שירותים, מנסה Credentials, קורא תגובות, מתאים את הצעד הבא וממשיך.
בלי להתעייף.
בלי להשתעמם.
ובמהירות של מכונה.
במקרה הזה, אף אחד אפילו לא ביקש ממנו לתקוף.
הוא קיבל משימה לגיטימית, עם גבולות לא מספיק טובים — ושלוש חברות אמיתיות נפרצו כתוצאה צדדית.
וזו אולי הנקודה החשובה ביותר:
אם Agent יכול לעשות דבר כזה בטעות, אפשר להבין עד כמה נמוך הרף לשימוש מכוון.
למה WAF או CDN לא בהכרח יעזרו כאן
ברגע ששומעים "AI תקף שרת", האינסטינקט הוא לחשוב על WAF, CDN או Cloud Firewall.
אבל במקרה הזה, הם בכלל לא היו במסלול.
ה־Agent לא "עבר דרך ה־Edge".
הוא מצא מערכות חשופות באינטרנט והתחבר אליהן ישירות.
וכאן נמצא ההבדל החשוב.
שכבת Edge יכולה להגן רק על תעבורה שעוברת דרכה.
אם ל־Origin Server שלכם יש כתובת IP ציבורית, ואם שירות כלשהו פתוח ישירות לאינטרנט — אפשר להגיע אליו גם בלי לעבור דרך ה־CDN או ה־WAF.
במילים אחרות:
המקום היחיד שרואה בוודאות כל חיבור שמגיע לשרת שלכם הוא השרת עצמו.
כל שכבה חיצונית אחרת מגינה רק על התעבורה שבאמת עוברת דרכה.
מה היה עוצר את Gemini?
כאן חשוב להיות מדויקים.
במקרה של ניחוש הסיסמה — כן.
Password Guessing עובד רק אם לתוקף נותנים מספיק ניסיונות.
nuDefend מזהה כשלי Authentication חוזרים וחוסם אוטומטית את כתובת המקור לאחר מספר קטן של ניסיונות.
והחסימה מתבצעת ב־Kernel Firewall — לפני שהניסיון הבא בכלל מגיע לשירות.
Agent שצריך מאות ניסיונות פשוט לא מקבל אותם.
אצלנו, לדוגמה, בשני שרתי Production רגילים, בתוך חלון של 24 שעות בלבד, נרשמו:
144 ניסיונות SSH כושלים מ־25 כתובות שונות בשרת אחד.
344 ניסיונות בשרת השני.
73 מהניסיונות כוונו ישירות לחשבון root.
כולם נחסמו אוטומטית.
ואלה לא שרתים שנמצאים תחת מתקפה ממוקדת.
זו פשוט רעש הרקע הקבוע של האינטרנט.
אותו סוג התנהגות ש־Gemini הציג בתרגיל — רק בקנה מידה עולמי, כל הזמן.
במקרה של Credentials שנחשפו ב־Repository — לא.
אם מישהו שמר סיסמה, API Key או Token בתוך Repository ציבורי, זו בעיית תהליך.
שום Agent שרץ על השרת לא יכול לתקן בדיעבד Credential שכבר דלף.
ומי שמבטיח אחרת פשוט מוכר אשליה.
צריך לסרוק Repositories, לבצע Secret Scanning, לסובב Credentials שנחשפו ולוודא שהם לא נכנסים לקוד מלכתחילה.
ובמקרה של גישת האינטרנט של Gemini — גם לא.
זו הייתה בעיית Sandbox והרשאות בצד של Google.
המודל קיבל יכולת תקשורת שלא הייתה אמורה להיות לו.
שום תוכנת הגנה שרצה אצל החברה שנפרצה לא יכולה לתקן טעות הרשאות בתוך סביבת AI של צד אחר.
כלומר:
nuDefend לא היה מונע את שלושת המקרים.
הוא היה עוצר אחד מהם.
אבל דווקא את הסוג שחוזר שוב ושוב, יום אחרי יום, כמעט על כל שרת ציבורי באינטרנט.
בדיוק בגלל זה ההגנה צריכה להיות על השרת
nuDefend מותקן ישירות על השרת ופועל במקום שבו החיבור באמת מגיע.
הוא חוסם כתובות IP ידועות כזדוניות ישירות ב־Kernel Firewall — הן בתעבורה נכנסת והן בתעבורה יוצאת — עוד לפני שהתעבורה מגיעה לאפליקציה.
הוא מזהה וחוסם ניסיונות חוזרים לניחוש Credentials.
רשימת האיומים החתומה שלו מתעדכנת כל 30 דקות, כך שכתובת IP שהפכה לזדונית היום יכולה להיחסם אצלכם עוד היום, בלי צורך בפעולה ידנית.
בנוסף, nuDefend מציג אילו שירותים מאזינים כרגע על השרת ועד כמה כל אחד מהם באמת חשוף.
וזה חשוב, כי זה בדיוק מה ש־Agent אוטונומי עושה בתחילת תקיפה:
הוא קודם כול מנסה להבין מה פתוח.
ההבדל הוא שאתם יכולים לראות את זה לפניו.
הדוחות נוצרים מקומית ונשארים על השרת שלכם.
אבל הסיפור הזה מצביע על בעיה גדולה יותר
הכשל המעניין ביותר באירוע של Google בכלל לא נמצא אצל שלוש החברות שנפרצו.
הוא נמצא אצל ה־AI.
היה שם Workload אוטונומי עם גישה החוצה — וגישה הזו לא הייתה אמורה להיות קיימת.
וזה מחזיר את השאלה אלינו.
אם אתם מריצים היום:
שרת Inference מקומי,
AI Agent,
מערכת Automation,
Vector Database,
או Agent שמחובר למערכות פנימיות,
האם אתם באמת יודעים לאן התהליך הזה יכול להתחבר?
לרוב התשובה היא לא.
אנחנו יודעים אילו Ports פתוחים פנימה.
אנחנו יודעים אילו תהליכים רצים.
אבל הרבה פחות קל לענות על השאלה:
עם מי כל Process באמת מתקשר החוצה?
וזה בדיוק הכיוון של השכבה הבאה שאנחנו בונים ב־nuDefend.
לא רק לראות תעבורה יוצאת.
אלא ללמוד לאורך זמן עם אילו יעדים כל Workload מתקשר באופן נורמלי — ואז לאפשר רק את מה שצריך.
במילים אחרות:
Learn first. Allow only what belongs.
לא בגלל ש־AI הוא "מסוכן" יותר מכל תוכנה אחרת.
אלא משום ש־Agent אוטונומי מקבל החלטות בעצמו.
וברגע שתהליך מקבל החלטות בעצמו, אי אפשר להסתמך רק על כך שהוא יתנהג כפי שהתכוונו.
צריך לתת לו גבולות.
ובינתיים? הדברים המשעממים עדיין עובדים.
אל תשאירו שירותים פתוחים לאינטרנט אם אין בכך צורך.
אל תשתמשו בסיסמאות שקל לנחש.
אל תשמרו Credentials בקוד.
ואל תאפשרו לאף גורם לנסות שוב ושוב עד שהוא מצליח.
AI אולי משנה את עולם הסייבר.
אבל הרבה מאוד פריצות עדיין מתחילות מאותה טעות ישנה:
השארנו את הדלת פתוחה יותר מדי זמן.
מקורות: CNN Business · The Hacker News · ABC News