מבוא ל-Responder - החולשה הישנה ב-Windows שעדיין תופסת ארגונים שלמים¶
אם תשאלו בודקי חדירות מנוסים מה הדבר הראשון שהם מריצים כשהם נכנסים לרשת פנימית של ארגון, חלק גדול מהם יגידו Responder. לא בגלל שזה הכלי הכי מתוחכם שקיים, אלא בגלל ההפך - הוא מנצל חולשה ישנה כל כך ובסיסית כל כך בדרך שבה Windows מחפש שמות ברשת, שהיא עדיין קיימת כמעט בכל ארגון שלא טיפל בה במפורש.
הבעיה הבסיסית שקיימת כבר עשרות שנים¶
כשמחשב Windows מנסה להגיע לשם רשת מסוים - נניח שהוקלד בטעות שם שרת שלא קיים - השלב הראשון הרגיל הוא לשאול שרת DNS. אבל אם ה-DNS לא מצליח לענות, Windows לא פשוט מוותר. הוא חוזר לפרוטוקולים ישנים בהרבה - LLMNR ו-NBT-NS - ששולחים שאילתת שידור (broadcast) לכל המכונות ברשת המקומית, בבקשה "מי כאן נקרא בשם הזה?".
הבעיה היא שהפרוטוקולים הישנים האלה נבנו בעידן שבו לא חשבו כמעט בכלל על אבטחה. כל מכונה ברשת יכולה לענות לשאילתה הזאת ולהגיד "אני!", גם אם היא לא באמת המכונה שחיפשו. Responder עושה בדיוק את זה - הוא מאזין לשאילתות שידור כאלה ברשת, ועונה לכולן בחיוב, ומתחזה לכל שירות שמישהו מחפש.
איך זה מוביל לגניבת hashes¶
ברגע שמכונת הקורבן מאמינה ש-Responder הוא השירות שהיא חיפשה, היא מנסה להתחבר אליו כרגיל - וכחלק מתהליך ההתחברות הסטנדרטי של Windows, היא שולחת גרסה מוצפנת של פרטי ההתחברות של המשתמש הנוכחי, בפרוטוקול בשם NTLM. Responder תופס את זה, ומקבל מה שנקרא "NTLM hash" - לא הסיסמה עצמה בטקסט גלוי, אבל משהו שבמקרים רבים אפשר לנסות לפצח לא מקוון, או במקרים מסוימים אפילו להעביר הלאה כפי שהוא (relay) כדי לקבל גישה ישירות בלי לפצח בכלל.
הדבר שהופך את זה לכל כך אפקטיבי הוא שהתהליך כולו קורה לגמרי בפאסיביות. תוקף שיושב ברשת עם Responder פועל לא צריך לתקוף אף אחד באופן אקטיבי - הוא פשוט מחכה, וברגע שמישהו ברשת מקליד בטעות שם שרת שגוי, או שמשאב רשת זמנית לא זמין, ה-hash שלו מגיע ישר אליו.
למה זו אחת הבעיות הנפוצות ביותר בבדיקות חדירה פנימיות¶
הסיבה ש-Responder כל כך יעיל בהערכות אבטחה מקצועיות היא שהתרחישים שמפעילים את הפרוטוקולים הפגיעים האלה קורים כל הזמן בעבודה יומיומית רגילה - שגיאת הקלדה בשם שרת, שירות רשת שרגע לא זמין, כונן רשת שהתנתק. ברוב הארגונים שמעולם לא בדקו את הנקודה הזאת במפורש, הרצה של Responder למשך כמה שעות בלבד תופסת בדרך כלל מספר לא מבוטל של hashes, פשוט כי הפרוטוקולים הפגיעים עדיין פעילים כברירת מחדל.
זו בדיוק הסיבה שממצא כזה מופיע כל כך הרבה בדוחות בדיקות חדירה פנימיות - זו לא חולשה אקזוטית שדורשת מיומנות נדירה לנצל, זו חולשת תצורה בסיסית שנשארת פתוחה כי אף אחד לא חשב לסגור אותה.
איך ארגונים מתגוננים¶
ההגנה כאן, למרבה המזל, ברורה ומוכרת:
- השבתת LLMNR ו-NBT-NS. ברוב הארגונים המודרניים, שבהם DNS פנימי מוגדר כמו שצריך, אין בכלל צורך בפרוטוקולים האלה, ואפשר להשבית אותם לגמרי דרך מדיניות קבוצתית (Group Policy).
- SMB Signing. מחייב חתימה קריפטוגרפית על תקשורת SMB, מה שמונע חלק גדול מהתקפות ה-relay שמנצלות hashes שנתפסו.
- פילוח רשת. הגבלת התקשורת בין קטעי רשת שונים מצמצמת את הטווח שבו תוקף בודד יכול להאזין לשאילתות שידור של כל הארגון בבת אחת.
- ניטור שאילתות שידור חריגות. צוותי אבטחה יכולים לזהות פעילות Responder פעילה על ידי ניטור עלייה חריגה בתעבורת LLMNR ו-NBT-NS ברשת.
למה כדאי להכיר את הכלי הזה¶
Responder הוא דוגמה מצוינת לכך שלא כל תקיפה משמעותית דורשת חולשה חדשה ומתוחכמת - לפעמים החולשה הכי אפקטיבית היא הכי ישנה, פשוט כי אף אחד לא טרח לסגור אותה. בודק חדירות טוב יודע לזהות בדיוק את סוגי הפערים הבסיסיים האלה, ולא רק לרדוף אחרי חולשות מרשימות. אם אתם רוצים ללמוד לזהות ולנצל, בסביבה מורשית בלבד, את סוגי הבעיות הבסיסיות האלה שחוזרות על עצמן שוב ושוב בעולם האמיתי, בקורס בדיקות חדירה אנחנו עוברים גם על תקיפות רשת פנימיות מהסוג הזה, כולל ההיגיון המלא שמאחורי הפרוטוקולים הפגיעים והדרך הנכונה לתעד ולדווח על הממצא.
לסיכום¶
Responder מזכיר לכולנו שאבטחת רשת טובה לא נגמרת בחומת אש חזקה או בסיסמאות מסובכות - היא דורשת גם לחזור אחורה ולבדוק פרוטוקולים ישנים שנשארו פעילים מברירת מחדל ואף אחד לא בדק אותם שוב. זו בדיוק הסיבה שהכלי הפשוט הזה עדיין רלוונטי, וימשיך להיות רלוונטי, כל עוד ארגונים לא סוגרים את הפער הבסיסי הזה.