עשירית מיציאות Tor הפנו חיבורי SSH לשרתי התוקפים, ומי שהקליד סיסמה מסר אותה: 333 relay-ים שנפרצו
בשישי בבוקר, 2 באוקטובר, חוקר שמפרסם תחת השם kaba ניסה להתחבר ב-SSH לאחד השרתים שלו דרך רשת Tor וקיבל את האזהרה שכל אדמין מכיר: זהות השרת המרוחק השתנתה, וייתכן שמישהו מאזין באמצע. הוא לא התקין מחדש את השרת ההוא. בפוסט שפרסם ב-20 באוקטובר הוא מספר מה עשה בעקבות האזהרה, ומה מצא כשסרק באותו יום את כל כ-3,000 נקודות היציאה של Tor: ב-333 מהן חיבורי SSH הופנו לאותם 12 שרתי יירוט. בערך עשירית מיציאות הרשת כולה.
הצוות שמתחזק את בריאות הרשת ב-Tor Project הגיע לאותה מסקנה מכיוון אחר, ובתוך שלושה ימים הוציא את כולן מהמשחק. "לא ראינו מתקפה כזאת לפני כן", הם אמרו לו, לפי הפוסט. מאז פורסמו שני מסמכים שהופכים את האירוע לאחד המתועדים שיצאו מרשת Tor: ניתוח של נתוני הספרייה הציבורית של הרשת, ותחקיר פנימי שכתב אחד המפעילים שנפרצו. אז נראה מה בדיוק שונה בהגדרות של אותן יציאות, למה נגנבו שם סיסמאות ולא מפתחות, ואיך התוקפים נכנסו לשרתים כבר באוגוסט.
ההגדרה שקובעת מה בכלל עובר ביציאה
כל חיבור שיוצא מ-Tor אל האינטרנט הרגיל עובר דרך relay אחרון בשרשרת, והוא היחיד שרואה את התעבורה כמו שהיא. לכל relay כזה יש קובץ הגדרות (torrc) שבו המפעיל קובע לאילו פורטים הוא מוכן להעביר תעבורה, והרשימה מתפרסמת לכל הרשת. ל-client של Tor זה לא פרט שולי: הוא בוחר יציאה רק מתוך אלה שהצהירו שהן מעבירות את הפורט שהוא צריך. מי ששולט בקובץ הזה שולט בשאלה איזו תעבורה תזרום דרכו.
וזה בדיוק מה ששונה שם. לפי ניתוח נתוני הספרייה שפרסם ב-9 באוקטובר מפעיל שחותם Tor at 1AEO, בין 1 ל-4 באוקטובר עברו 377 relay-ים של 59 מפעילים שונים לאחת משתי מדיניות יציאה שאף relay ברשת לא השתמש בהן מאז תחילת 2025. ב-342 מהם השינוי פתח את פורט 22, פורט ה-SSH, שהיה חסום קודם, וב-334 סגר דווקא את פורטי הדואר המוצפנים 993 ו-995 והשאיר פתוחים את המקבילים הגלויים שלהם. עוד 24 relay-ים לא היו יציאות בכלל לפני כן, והשינוי הפך אותם ליציאות. בשיא, ב-4 באוקטובר ב-01:00, החזיקו 351 יציאות שימושיות עם המדיניות הזאת 7.46% ממשקל היציאות של הרשת.
הניתוח עצמו זהיר בניסוח: הוא מזהה relay-ים לפי התאמה מדויקת של רשימת הפורטים שפרסמו, ומדגיש שזאת התאמת מדיניות ולא הוכחה לפריצה. לשאלה למה נסגרו דווקא פורטי הדואר המוצפנים אין תשובה בנתונים, הוא כותב. kaba רואה בצירוף הפורטים שתי מטרות נפרדות: איסוף תעבורת דואר גלויה, ובמקביל יירוט של חיבורי SSH.
למה נגנבה הסיסמה, והמפתח לא
עם פורט 22 פתוח, חיבור SSH שיצא דרך אחת מאותן יציאות לא הגיע לשרת שהמשתמש ביקש אלא לאחד מ-12 שרתי היירוט. השרת שבאמצע הציג מפתח משלו. מי שהתחבר לאותו יעד בעבר ראה את אזהרת ה-OpenSSH שהמפתח השתנה, ומי שהתחבר בפעם הראשונה ראה בקשה רגילה לאשר מפתח חדש. מי שאישר והקליד סיסמה מסר אותה לתוקף. הסשן המשיך לעבוד, כי שרת היירוט פתח בעצמו חיבור לשרת האמיתי והעביר הלאה, וכך גם ראה כל פקודה שהוקלדה. לפי kaba, במקביל נפתח חיבור שני לאותו שרת, וזה ששימש לנסות להדביק אותו.
ההבדל בין סיסמה למפתח הוא כל העניין כאן, והוא לא עניין של חוזק הסיסמה. כשמתחברים עם מפתח, ה-client לא שולח שום דבר שאפשר להעביר הלאה: הוא חותם על בלוק נתונים שכולל מזהה ייחודי לסשן הנוכחי, ולכן חתימה שנוצרה מול שרת היירוט חסרת ערך מול השרת האמיתי. סיסמה, לעומת זאת, נוסעת בתוך המנהרה המוצפנת ומגיעה בטקסט גלוי לצד שמסיים את המנהרה, וכאן הצד הזה היה התוקף. אותה הצפנה שמגנה על הסיסמה מפני כל מי שבדרך היא זו שמסרה אותה ליעד הלא נכון.
איך 333 יציאות נמצאו בסריקה אחת
השיטה של kaba פשוטה בצורה שמסבירה למה היא עבדה. בעזרת exitmap, כלי שגם צוות בריאות הרשת משתמש בו, נעץ כל פעם יציאה אחת ופתח דרכה חיבור SSH משרת אחד שלו לשני. בצד אחד בדק אם המפתח שהתקבל הוא הנכון, ובצד השני אם החיבור הגיע מהיציאה שננעצה או משרת יירוט. אחר כך הריץ את זה מול כל היציאות ברשת. כתריסר מהן הגישו מפתח מזויף, ויותר מ-300 לא נגעו במפתח כלל אלא רק ניתבו דרך אותם שרתי יירוט, וזה הספיק כדי לסמן אותן.
אחר כך העמיד מלכודת דבש, שרת SSH מדומה שמקבל כל התחברות ומתעד אותה, ונתן לתוקף להתחבר אליה. משם נראה שהצד השני עבד עם paramiko, ספריית SSH ל-Python, ושניסה להתקין את הנוזקה דרך פקודת Perl מקודדת. ביום שישי בערב העביר את הכול לצוות בריאות הרשת. ב-4 באוקטובר הצוות יצר קשר עם המפעילים, ומ-18:00 UTC התחילו רשויות הספרייה של Tor להצביע לאותם relay-ים את הדגל BadExit, שאומר ל-client-ים לא להשתמש ב-relay הזה בתור יציאה בשום מצב. מ-17:00 ב-5 באוקטובר אף relay עם אותה מדיניות לא נמצא יותר ברשימה שה-client-ים קוראים, ובגרף הדגלים של Tor Metrics נותרה שקיעה שלא התאוששה.
איך התוקפים נכנסו, חודשיים לפני כן
הקבוצה הגדולה שנפגעה, 277 מתוך 377 ה-relay-ים, היא משפחת Quetzalcoatl, והמפעיל שלה פרסם ב-7 באוקטובר תחקיר מפורט של מה שקרה אצלו, חתום Zimmer. שני שרתים שלו נפרצו עד root והותקנה בהם נוזקה בשם Ebury, גרסה 1.8.3. ב-28 באוגוסט ב-03:19 התוקף התחבר לשרת הניהול עם הסיסמה של חשבון המפעיל, בניסיון הראשון, בלי שנרשם אי פעם ניסיון כושל מאותה כתובת. חמש דקות אחר כך הייתה לו גישת root. "שורש הבעיה היה אצלנו", כתב Zimmer: סיסמה אחת ששימשה להתחברות ב-SSH, ל-sudo ולהצפנת הגיבוי, שמורה בטקסט גלוי על שני השרתים, ולצידה אימות סיסמה ב-SSH שנשאר פתוח בשרת הניהול שחשוף לאינטרנט.
Ebury היא נוזקה שיושבת בתוך OpenSSH עצמו ואוספת פרטי אימות של כל מי שעובר דרכו, והמנגנון שלה מסביר למה שרתי SSH הם מטרה כל כך טובה. SSH מצפין את הסיסמה בדרך, אבל ה-sshd בצד השני חייב לפענח אותה כדי לבדוק אותה, ו-Ebury רצה בתוך אותו תהליך. כלומר היא קוראת כל סיסמה כפי שהוקלדה, כולל ניסיונות שנכשלו, ולפי התחקיר קלטה גם את הסיסמאות של מי שבא לחקור את השרתים. ההסתרה פשוטה ויעילה: הנוזקה היא קובץ ספרייה אחד עם הרשאת setuid, libkeyutils.so.1.10.2, שה-symlink של הספרייה המקורית הופנה אליו. הקובץ המקורי של החבילה נשאר שלם, ולכן בדיקות התקינות לא תופסות כלום, ו-sshd, sudo ו-PAM עוברים את בדיקת ה-checksum שלהם.
את השינוי בהגדרות עשו התוקפים בשני סבבים, והראשון נכשל. ב-1 באוקטובר ב-15:35 הם הוסיפו בלוק מדיניות לקובץ torrc הראשי והפעילו את Tor מחדש, ושום דבר במדיניות שהתפרסמה לא השתנה: ה-relay-ים האלה רצים כמופעים נפרדים בדביאן וקוראים קובץ אחר לגמרי. למחרת ב-09:34 הם חזרו וכתבו מחדש את קובצי המופעים, וה-relay-ים פרסמו את התוצאה תוך שניות. המדיניות הפתוחה הייתה בתוקף כ-52 שעות על שני relay-ים שהעבירו בערך 3.4 טביבייט ביום. אתחול שגרתי של הקרנל ב-4 באוקטובר חיסל את התהליכים הנסתרים, ו-Ebury חזרה מיד אחריו. וגם מפתחות המשפחה שהיו אמורים להיות מנותקים מהרשת לא היו מנותקים: עותקים שלהם שכבו בגיבוי שעל שרת הניהול, מוצפנים באותה סיסמה שהתוקף כבר החזיק. (ואגב, חלק מסבבי הבדיקה שהוא הריץ קבעו שלא הייתה פריצה בכלל; מה שהכריע היה הארכיון הציבורי של תיאורי ה-relay-ים.)
מה עוד לא ידוע
השאלה הגדולה שנשארה פתוחה היא איך נכנסו התוקפים לשרתי 58 המפעילים האחרים. הרמז החזק ביותר בנתונים הוא ספק האירוח: מתוך ה-relay-ים שלהם שהיו ברשימה ב-1 באוקטובר, 71 מתוך 101 שאוחסנו אצל FranTech Solutions, הרשת שמאחורי המותג BuyVM, עברו למדיניות של התוקף, מול 13 מתוך 9,054 שאוחסנו במקומות אחרים. ונתון נוסף שמצביע על תיאום: 40 relay-ים של 21 מפעילים עברו למדיניות החדשה בתוך חמש דקות ו-24 שניות, 38 מהם בטעינה מחדש של ההגדרות, ולדעת כותב הניתוח זה מעיד שלגורם אחד הייתה גישה לכולם מראש.
Marc-Etienne M. Léveillé, שכתב את הדוח של ESET על Ebury ב-2024 ושותף למאמר המקורי מ-2014, ענה ברשימת הדיוור ב-8 באוקטובר. הניחוש שלו למקור הסיסמה הוא התחברות משרת שכבר היה נגוע ב-Ebury, ואפשרות שנייה היא ספק אירוח שנפרץ: ESET נתקלה בעבר בספקים ששרתי הניהול שלהם היו נגועים, ושהשרתים הווירטואליים של הלקוחות שלהם נדבקו בעקבות זה. גרסה 1.8.3, הוא מוסיף, מסתובבת לפחות מיוני 2026, ולכן חדשה יותר מהסימנים הפומביים של ESET. "בהתחשב בכמה שרתים נדבקו ב-Ebury בין 2009 ל-2023 (400 אלף!), כנראה שיש עוד relay-ים נגועים של Tor בחוץ", כתב.
מי עומד מאחורי הקמפיין לא ידוע. kaba מעריך שהשימוש ב-Ebury יחד עם האיסוף הרחב של תעבורה גלויה מצביעים על קבוצה פלילית שמונעת מכסף, ומסייג מיד שגם זאת ספקולציה. וגם מה שרץ על השרתים לא התפענח: Zimmer מתאר שלושה תהליכים נסתרים בשמות guard, failover ו-snf, שהקבצים שלהם נעלמו עם האתחול. לדעת Léveillé, snf הוא אולי קיצור של sniff.
מה זה אומר בפועל
מי שהתחבר ב-SSH עם סיסמה דרך Tor בין 1 ל-5 באוקטובר ואישר מפתח שרת שלא הכיר או שהשתנה, צריך להתייחס לאותה סיסמה כגנובה, להחליף אותה ולבדוק את השרת עצמו. לכל השאר נשארת המסקנה המשעממת שגם kaba וגם Zimmer מגיעים אליה: אימות במפתחות בלבד, אימות סיסמה כבוי בכל מה שחשוף לאינטרנט, וסיסמה שאינה גם סיסמת ה-sudo וגם מפתח הגיבוי. ההודעה של Tor Project מבקשת ממפעילי relay-ים על לינוקס לעשות עוד דבר אחד: להשוות את מדיניות היציאה שה-relay שלהם מפרסם לרשת מול מה שהם באמת הגדירו. קובץ על שרת שנפרץ אפשר לשנות בלי להשאיר שורה אחת בלוג.
תגובות