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

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

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

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

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

חלק 1. רופא פוצ'קין

2018 יש לקוח - חברת IT הייטק, שבעצמה משרתת לקוחות רבים. מעוניין לקבל תשובה לשאלה: האם ניתן, ללא כל ידע וגישה ראשוניים, בעבודה דרך האינטרנט, לקבל זכויות מנהל תחום Active Directory? אני לא מתעניין בשום הנדסה חברתית (אה, אבל לשווא), הם לא מתכוונים להפריע לעבודה בכוונה, אבל הם עלולים בטעות - לטעון מחדש שרת שעובד בצורה מוזרה, למשל. מטרה נוספת היא לזהות כמה שיותר וקטורי תקיפה אחרים כנגד ההיקף החיצוני. החברה מבצעת באופן קבוע בדיקות כאלה, וכעת הגיע המועד האחרון לבדיקה חדשה. התנאים כמעט אופייניים, מספקים, מובנים. בואו נתחיל.

יש שם של הלקוח - שיהיה "חברה", עם האתר הראשי www.company.ru. כמובן, הלקוח נקרא אחרת, אבל במאמר זה הכל יהיה לא אישי.
אני עורך סיור רשת - גלה אילו כתובות ודומיינים רשומים אצל הלקוח, משרטט דיאגרמת רשת, איך מחלקים שירותים לכתובות אלו. אני מקבל את התוצאה: יותר מ-4000 כתובות IP חיות. אני מסתכל על התחומים ברשתות הללו: למרבה המזל, הרוב המכריע הם רשתות המיועדות ללקוחות הלקוח, ופורמלית איננו מעוניינים בהן. הלקוח חושב אותו דבר.

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

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

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

אגב, על מה שמצאו סורקים שהושקו בעבר באופן כללי. תן לי להזכיר לך: עבור אנשים מסוימים, "pentest" שווה ערך ל"סריקה אוטומטית". אבל הסורקים בפרויקט הזה לא אמרו כלום. ובכן, המקסימום הוצג על ידי פרצות בינוניות (3 מתוך 5 מבחינת חומרה): בשירות כלשהו תעודת TLS גרועה או אלגוריתמי הצפנה מיושנים, וברוב האתרים Clickjacking. אבל זה לא יביא אותך למטרה שלך. אולי סורקים יהיו שימושיים יותר כאן, אבל הרשו לי להזכיר לכם: הלקוח עצמו מסוגל לרכוש תוכנות כאלה ולבדוק את עצמו איתן, ואם לשפוט לפי התוצאות העגומות, הוא כבר בדק.

נחזור לאתרים ה"חריגים". הראשון הוא משהו כמו Wiki מקומי בכתובת לא סטנדרטית, אבל במאמר זה תן לזה להיות wiki.company[.]ru. היא גם ביקשה מיד כניסה וסיסמה, אבל דרך NTLM בדפדפן. עבור המשתמש, זה נראה כמו חלון סגפני המבקש להזין שם משתמש וסיסמה. וזה מנהג רע.

הערה קטנה. NTLM באתרים היקפיים גרוע ממספר סיבות. הסיבה הראשונה היא ששם הדומיין של Active Directory נחשף. בדוגמה שלנו, התברר שהוא גם company.ru, בדיוק כמו שם ה-DNS "החיצוני". אם אתה יודע זאת, אתה יכול להכין בזהירות משהו זדוני כך שהוא יתבצע רק על מכונת הדומיין של הארגון, ולא בארגז חול כלשהו. שנית, האימות עובר ישירות דרך בקר התחום באמצעות NTLM (הפתעה, נכון?), עם כל המאפיינים של מדיניות הרשת ה"פנימית", כולל חסימת חשבונות לחרוג ממספר ניסיונות הזנת הסיסמה. אם תוקף יגלה את ההתחברות, הוא ינסה סיסמאות עבורם. אם אתה מוגדר לחסום חשבונות מלהזין סיסמאות שגויות, זה יעבוד והחשבון ייחסם. שלישית, אי אפשר להוסיף גורם שני לאימות כזה. אם מישהו מהקוראים עדיין יודע איך, אנא ספר לי, זה באמת מעניין. רביעית, פגיעות להתקפות מעבר-האש. ADFS הומצא, בין היתר, כדי להגן מפני כל זה.

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

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

באתר השני הייתה הכתובת "ברור איזה סוג של שם משפחה.company.ru." מצאתי את זה דרך גוגל, משהו כזה בעמוד 10. העיצוב היה מתחילת אמצע שנות ה-XNUMX, ואדם מכובד הסתכל עליו מהעמוד הראשי, משהו כמו זה:

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

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

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

אבל שרת האינטרנט שמתחתיו היה מעניין יותר. אם לשפוט לפי הכותרת של שרת HTTP, היה לו IIS 6.0, מה שאומר שהוא השתמש ב-Windows 2003 כמערכת ההפעלה. הסורק זיהה בעבר שאתר האורולוג המסוים הזה, בניגוד למארחים וירטואליים אחרים באותו שרת אינטרנט, הגיב לפקודה PROPFIND, כלומר הוא מריץ את WebDAV. אגב, הסורק החזיר את המידע הזה עם הסימן Info (בשפת דוחות הסורק זו הסכנה הכי נמוכה) - על דברים כאלה פשוט מדלגים. בשילוב זה נתן אפקט מעניין, שנחשף רק לאחר חפירה נוספת בגוגל: פגיעות נדירה של גלישת חוצץ הקשורה לסט Shadow Brokers, כלומר CVE-2017-7269, שכבר היה לה ניצול מוכן. במילים אחרות, יהיו בעיות אם יש לך Windows 2003 ו-WebDAV פועל על IIS. למרות שהפעלת Windows 2003 בייצור ב-2018 היא בעיה בפני עצמה.

הניצול הסתיים ב- Metasploit ונבדק מיד עם עומס ששלח בקשת DNS לשירות מבוקר - Burp Collaborator משמש באופן מסורתי לתפיסת בקשות DNS. להפתעתי, זה עבד בפעם הראשונה: התקבל נוקאאוט של DNS. לאחר מכן, היה ניסיון ליצור חיבור אחורי דרך יציאה 80 (כלומר, חיבור רשת מהשרת לתוקף, עם גישה ל-cmd.exe במארח הקורבן), אבל אז קרה פיאסקו. הקשר לא יצא, ולאחר הניסיון השלישי להשתמש באתר, יחד עם כל התמונות המעניינות, נעלמו לנצח.

בדרך כלל זה מלווה במכתב בסגנון "לקוח, תתעורר, הורדנו הכל". אבל אמרו לנו שלאתר אין שום קשר לתהליכים עסקיים ועובד שם בלי סיבה בכלל, כמו כל השרת, ושאנחנו יכולים להשתמש במשאב הזה כרצוננו.
כיממה לאחר מכן האתר התחיל לפתע לעבוד מעצמו. לאחר שבניתי ספסל מ-WebDAV על IIS 6.0, גיליתי שהגדרת ברירת המחדל היא להפעיל מחדש את תהליכי העובד של IIS כל 30 שעות. כלומר, כאשר הבקרה יצאה מקוד ה- shell, תהליך העובד של IIS הסתיים, ואז הוא הפעיל את עצמו מחדש כמה פעמים ואז הלך למנוחה של 30 שעות.

מכיוון שהחיבור האחורי ל-tcp נכשל בפעם הראשונה, ייחסתי בעיה זו ליציאה סגורה. כלומר, הוא הניח נוכחות של חומת אש כלשהי שלא אפשרה לחיבורים יוצאים לעבור החוצה. התחלתי להריץ קודי shell שחיפשו דרך יציאות tcp ו-udp רבות, לא הייתה השפעה. עומסי חיבור הפוכים דרך http(s) מ- Metasploit לא עבדו - meterpreter/reverse_http(s). לפתע נוצר חיבור לאותה יציאה 80, אך מיד נפל. ייחסתי את זה לפעולה של ה-IPS הדמיוני עדיין, שלא אהב את תעבורת המטרות. לאור העובדה שחיבור tcp טהור לפורט 80 לא עבר, אבל חיבור http, הגעתי למסקנה ש-http proxy הוגדר איכשהו במערכת.

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

במציאות, זה נראה כך: 3-4 ניסיונות התקפות תוך 5 דקות, ואז המתנה של 30 שעות. וכך הלאה במשך שלושה שבועות ברציפות. אפילו הגדרתי תזכורת כדי לא לבזבז זמן. בנוסף, היה הבדל בהתנהגות של סביבות הבדיקה והייצור: עבור פגיעות זו היו שני ניצולים דומים, האחד מ- Metasploit, והשני מהאינטרנט, שהומר מגרסת Shadow Brokers. אז רק Metasploit נבדק בקרב, ורק השני נוסה על הספסל, מה שהפך את איתור הבאגים לקשה עוד יותר והרס את המוח.

בסופו של דבר, קוד shell שהוריד קובץ exe משרת נתון דרך http והשיק אותו במערכת היעד הוכיח את עצמו כיעיל. קוד המעטפת היה קטן מספיק כדי להתאים, אבל לפחות זה עבד. מכיוון שהשרת לא אהב כלל תעבורת TCP ו-http(s) נבדקו לנוכחות של meterpreter, החלטתי שהדרך המהירה ביותר היא להוריד קובץ exe המכיל DNS-meterpreter דרך shellcode זה.

כאן שוב נוצרה בעיה: בעת הורדת קובץ exe וכפי שהראו ניסיונות, לא משנה איזה, ההורדה נקטעה. שוב, מכשיר אבטחה כלשהו בין השרת שלי לאורולוג לא אהב תעבורת http עם אקס בפנים. נראה שהפתרון ה"מהיר" היה לשנות את קוד המעטפת כך שיעיב על תעבורת http תוך כדי תנועה, כך שנתונים בינאריים מופשטים יועברו במקום exe. לבסוף, המתקפה הצליחה, השליטה התקבלה דרך ערוץ ה-DNS הדק:

מיד התברר שיש לי את זכויות זרימת העבודה הבסיסיות ביותר של IIS, שמאפשרות לי לא לעשות כלום. כך זה נראה בקונסולת Metasploit:

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

בהנחה ששרת Windows 2003 זה לא תוקן עבור הפגיעות המפורסמת MS17-010, אני מעביר את התעבורה לפורט 445/TCP דרך מנהרת ה-DNS של מטרפרטר ב-localhost (כן, זה גם אפשרי) ומנסה להפעיל את ה-exe שהורד קודם לכן דרך הפגיעות. ההתקפה עובדת, אני מקבל חיבור שני, אבל עם זכויות SYSTEM.

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

לאחר מכן, נחשפים פרטים מעניינים חדשים:

1. עם זכויות SYSTEM, אתה יכול ליצור חיבור אחורי בקלות באמצעות TCP. ברור, השבתת TCP ישירה היא בהחלט בעיה עבור משתמש IIS מוגבל. ספוילר: תעבורת המשתמשים של IIS הייתה עטופה איכשהו ב-ISA Proxy המקומי בשני הכיוונים. איך זה בדיוק עובד, לא שחזרתי.
2. אני ב"DMZ" מסוים (וזה לא תחום Active Directory, אלא WORKGROUP) - זה נשמע הגיוני. אבל במקום כתובת ה-IP הפרטית ("אפורה") הצפויה, יש לי כתובת IP "לבנה" לחלוטין, זהה בדיוק לזו שתקפתי קודם. המשמעות היא שהחברה כל כך ותיקה בעולם כתובת ה-IPv4 שהיא יכולה להרשות לעצמה לשמור על אזור DMZ עבור 128 כתובות "לבנות" ללא NAT לפי התוכנית, כפי שמתואר במדריכים של סיסקו משנת 2005.

מכיוון שהשרת ישן, מובטח למימיקץ לעבוד ישירות מהזיכרון:

אני מקבל את סיסמת המנהל המקומי, מעביר תעבורת RDP דרך TCP ומתחבר לשולחן עבודה נעים. מכיוון שיכולתי לעשות מה שרציתי עם השרת, הסרתי את האנטי וירוס וגיליתי שהשרת נגיש מהאינטרנט רק דרך יציאות TCP 80 ו-443, ו-443 לא היה תפוס. אני מגדיר שרת OpenVPN ב-443, מוסיף פונקציות NAT לתעבורת ה-VPN שלי ומקבל גישה ישירה לרשת DMZ בצורה בלתי מוגבלת דרך ה-OpenVPN שלי. ראוי לציין ש-ISA, עם כמה פונקציות IPS שאינן מושבתות, חסמה את התעבורה שלי עם סריקת פורטים, שעבורה היה צריך להחליף אותה ב-RRAS פשוט ותואם יותר. אז החומשים לפעמים עדיין צריכים לנהל כל מיני דברים.

קורא קשוב ישאל: "מה לגבי האתר השני - ויקי עם אימות NTLM, עליו נכתב כל כך הרבה?" עוד על כך בהמשך.

חלק 2. עדיין לא מצפין? אז אנחנו מגיעים אליכם כבר כאן

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

אני טוען את הסורקים דרך DMZ דרך מנהרה של OpenVPN ומחכה. אני פותח את הדוח - שוב שום דבר רציני, כנראה מישהו עבר את אותה שיטה לפני. השלב הבא הוא לבחון כיצד מארחים ברשת DMZ מתקשרים. כדי לעשות זאת, הפעל תחילה את Wireshark הרגיל והאזן לבקשות שידור, בעיקר ARP. מנות ARP נאספו כל היום. מסתבר שבקטע זה נעשה שימוש במספר שערים. זה יהיה שימושי מאוחר יותר. על ידי שילוב נתונים על בקשות ותגובות ARP ונתוני סריקת יציאות, מצאתי את נקודות היציאה של תעבורת משתמשים מתוך הרשת המקומית בנוסף לאותם שירותים שהיו ידועים בעבר, כגון אינטרנט ודואר.

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

Cain&Abel הושק בשרת של האורולוג. בהתחשב בזרימות התעבורה שזוהו, נבחרו הזוגות המבטיחים ביותר להתקפת האיש באמצע, ולאחר מכן התקבלה תעבורת רשת מסוימת בהשקה קצרת טווח למשך 5-10 דקות, עם טיימר לאתחול מחדש של השרת במקרה של הקפאה. כמו בבדיחה, היו שתי חדשות:

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

כתוצאה מכך, רכשתי הרבה אישורים שהיו חסרי תועלת בהקשר של הפרויקט, אבל בהחלט מעניינים כהדגמה לסכנת הפיגוע. נתבי גבול של חברות גדולות עם telnet, העבירו את יציאות ה-debug http ל-CRM פנימי עם כל הנתונים, גישה ישירה ל-RDP מ-Windows XP ברשת המקומית ועוד סתמיות. זה יצא ככה שרשרת אספקה ​​פשרה לפי מטריצת MITER.

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

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

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

לאחר חפירה נוספת בשירותים, עלה בראש רעיון מעניין. יש כלי עזר כזה בשם Responder (קל למצוא דוגמאות לשימוש בשם זה), שבאמצעות "הרעלת" בקשות שידור, מעורר חיבורים באמצעות מגוון פרוטוקולים כגון SMB, HTTP, LDAP וכו'. בדרכים שונות, ואז מבקש מכל מי שמתחבר לאימות ומגדיר זאת כך שהאימות מתבצע באמצעות NTLM ובמצב שקוף לקורבן. לרוב, תוקף אוסף בדרך זו לחיצות ידיים של NetNTLMv2 ומתוכם, באמצעות מילון, משחזר במהירות סיסמאות משתמשי דומיין. כאן רציתי משהו דומה, אבל המשתמשים ישבו "מאחורי קיר", או ליתר דיוק, הם הופרדו על ידי חומת אש, וניגשו ל-WEB דרך אשכול ה-Proxy Blue Coat.

זכור, ציינתי ששם הדומיין של Active Directory עולה בקנה אחד עם הדומיין "חיצוני", כלומר, זה היה company.ru? אז, Windows, ליתר דיוק Internet Explorer (ו-Edge ו-Chrome), מאפשרים למשתמש לבצע אימות שקוף ב-HTTP דרך NTLM אם הם חושבים שהאתר ממוקם באיזה "אזור אינטראנט". אחד הסימנים של "אינטרנט" הוא גישה לכתובת IP "אפורה" או שם DNS קצר, כלומר ללא נקודות. מכיוון שהיה להם שרת עם שם IP ו-DNS "לבן" preobrazhensky.company.ru, ומכונות דומיין בדרך כלל מקבלים את סיומת הדומיין של Active Directory דרך DHCP להזנת שם פשוטה, הם רק היו צריכים לכתוב את כתובת האתר בשורת הכתובת preobrazhensky, כדי שימצאו את הדרך הנכונה לשרת של האורולוג שנפגע, בלי לשכוח שעכשיו קוראים לזה "אינטרנט". כלומר, במקביל נותן לי את לחיצת היד של המשתמש NTLM ללא ידיעתו. כל מה שנותר הוא לאלץ את דפדפני הלקוחות לחשוב על הצורך הדחוף ליצור קשר עם השרת הזה.

כלי השירות הנפלא Intercepter-NG בא להציל (תודה מיירט). זה אפשר לך לשנות תעבורה תוך כדי תנועה ועבד מצוין ב-Windows 2003. אפילו הייתה לו פונקציונליות נפרדת לשינוי קבצי JavaScript בלבד בזרימת התעבורה. תוכנן מעין Scripting Cross-Site מסיבי.

פרוקסי Blue Coat, שדרכם משתמשים ניגשו ל-WEB הגלובלי, שמנו מעת לעת תוכן סטטי במטמון. על ידי יירוט תנועה, היה ברור שהם עובדים מסביב לשעון, וביקשו בלי סוף סטטי בשימוש תכוף כדי להאיץ את הצגת התוכן בשעות השיא. בנוסף, ל-BlueCoat היה User-Agent ספציפי, שהבדיל אותו בבירור ממשתמש אמיתי.

הוכן Javascript, אשר, באמצעות Intercepter-NG, הוטמע במשך שעה בלילה עבור כל תגובה עם קבצי JS עבור Blue Coat. התסריט עשה את הדברים הבאים:

• קבע את הדפדפן הנוכחי על ידי User-Agent. אם זה היה Internet Explorer, Edge או Chrome, זה המשיך לעבוד.
• חיכיתי עד שנוצר ה-DOM של הדף.
• הוכנס תמונה בלתי נראית ל-DOM עם תכונת src של הטופס preobrazhensky:8080/NNNNNNNN.png, כאשר NNN הם מספרים שרירותיים כך ש-BlueCoat לא שומר אותו במטמון.
• הגדר משתנה דגל גלובלי כדי לציין שההזרקה הושלמה ואין צורך להכניס תמונות יותר.

הדפדפן ניסה לטעון את התמונה הזו; ביציאה 8080 של השרת שנפרץ, מנהרת TCP חיכתה לה למחשב הנייד שלי, שם אותו Responder פעל, ודרשה מהדפדפן להיכנס דרך NTLM.

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

ביקורים סודיים המוניים בשרת האורולוג על ידי משתמשים

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

נאלצתי להתחמש בטכניקות מוטציות בסיסמאות, כרטיס מסך, מילון עבה יותר ולחכות. לאחר זמן רב נחשפו מספר חשבונות עם סיסמאות בצורת "Q11111111....1111111q", מה שמרמז שכל המשתמשים נאלצו פעם להמציא סיסמה ארוכה מאוד עם רישיות שונה של תווים, מה שאמור היה גם להיות מורכב. אבל אי אפשר לרמות משתמש ותיק, וכך הוא הקל על עצמו לזכור. בסך הכל נפגעו כ-5 חשבונות, ורק לאחד מהם הייתה זכויות יקרות ערך בשירותים.

חלק 3. Roskomnadzor מכה בחזרה

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

• לחברה רשת WiFi עם אימות באמצעות חשבונות דומיין עם גישה לרשת המקומית. עם סט הנתונים הנוכחי, זה כבר וקטור התקפה עובד, אבל אתה צריך ללכת למשרד עם הרגליים ולהיות ממוקם איפשהו בשטח משרד הלקוח.
• מצאתי הוראה לפיה היה שירות שאפשר... לרשום באופן עצמאי מכשיר אימות "גורם שני" אם המשתמש נמצא בתוך רשת מקומית וזוכר בבטחה את הכניסה והסיסמה שלו לדומיין. במקרה זה, "בפנים" ו"בחוץ" נקבעו לפי הנגישות של הנמל של שירות זה למשתמש. היציאה לא הייתה נגישה מהאינטרנט, אבל הייתה נגישה למדי דרך ה-DMZ.

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

כשה"גורם השני" נשבר, הצלחתי לגשת לדואר של Outlook Web Access ולגישה מרחוק ב- Citrix Netscaler Gateway. הייתה הפתעה בדואר ב-Outlook:

בזריקה הנדירה הזו תוכלו לראות כיצד Roskomnadzor עוזר לחודרים

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

מי שמכיר את Citrix Netscaler מדמיין שבדרך כלל זה מיושם בצורה כזו שניתן להעביר למשתמש רק ממשק תמונה, מנסה לא לתת לו את הכלים להשיק אפליקציות צד שלישי והעברת נתונים, מה שמגביל בכל דרך אפשרית פעולות באמצעות פגזי בקרה סטנדרטיים. "הקורבן שלי", עקב עיסוקו, קיבל רק 1C:

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

ביקשתי מחבריי מתכנתי 1C ליצור עיבוד שיקבל מחרוזת ויבצע אותה. בשפת 1C, התחלת תהליך נראית בערך כך (נלקח מהאינטרנט). האם אתה מסכים שהתחביר של שפת 1C מדהים אנשים דוברי רוסית בספונטניות שלו?

העיבוד בוצע בצורה מושלמת; התברר שזה מה שהפנטסטרים מכנים "קליפה" - Internet Explorer הושק דרכו.

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

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

AppLocker הופעל בשרת היישומים המריץ את Citrix, אך הוא עקף. אותו Meterpreter נטען והושק דרך DNS, מכיוון שגרסאות ה-http(s) לא רצו להתחבר, ולא ידעתי את כתובת ה-proxy הפנימית באותו זמן. אגב, מרגע זה ואילך, הפנטסט החיצוני הפך למעשה לחלוטין לפנימי.

חלק 4. זכויות המנהל למשתמשים הן גרועות, בסדר?

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

טכניקה טיפוסית לתפיסת זכויות מנהל תחום נראית פשוטה כמחזור של פעולות מונוטוניות:

• אנחנו הולכים למחשבי דומיין שבהם יש זכויות מנהל מקומיות, על סמך חשבונות דומיין שכבר נלכדו.
• אנו משיקים את Mimikatz ומקבלים סיסמאות שמור, כרטיסי Kerberos ו-NTLM hashe של חשבונות דומיין שנכנסו לאחרונה למערכת זו. לחלופין, אנו מסירים את תמונת הזיכרון של תהליך lsass.exe ונעשה את אותו הדבר בצד שלנו. זה עובד היטב עם Windows צעירים מ-2012R2/Windows 8.1 עם הגדרות ברירת מחדל.
• אנו קובעים היכן לחשבונות שנפרצו יש זכויות מנהל מקומיות. אנו חוזרים על הנקודה הראשונה. בשלב מסוים אנו מקבלים זכויות מנהל עבור כל הדומיין.

"סוף המחזור;", כפי שהיו כותבים כאן מתכנתי 1C.

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

• התקנתי שם לקוח OpenVPN, שעשה מנהרה דרך האינטרנט לשרת שלי. היה צריך לאלץ את הלקוח לעבור את אותו מעיל כחול עם אימות דומיין, אבל OpenVPN עשה את זה, כמו שאומרים, "מהקופסה".
• הותקן OpenSSH על VDI. ובכן, באמת, מה זה Windows 7 בלי SSH?

כך זה נראה בשידור חי. הרשו לי להזכיר לכם שכל זה צריך להיעשות דרך Citrix ו-1C:

טכניקה אחת לקידום גישה למחשבים שכנים היא בדיקת סיסמאות מנהל מקומיות להתאמה. כאן חיכה מיד המזל: ה-hash של NTLM של מנהל ברירת המחדל המקומי (שנקרא לפתע Administrator) ניגש באמצעות התקפת העברה-האש למארחי VDI שכנים, מהם היו כמה מאות. כמובן שההתקפה פגעה בהם מיד.

זה המקום שבו מנהלי VDI ירו לעצמם ברגל פעמיים:

• הפעם הראשונה הייתה כשמכונות VDI לא הובאו תחת LAPS, ובעצם שמרו על אותה סיסמת מנהל מקומית מהתמונה שנפרסה באופן מאסיבי ל-VDI.
• מנהל ברירת המחדל הוא החשבון המקומי היחיד שחשוף להתקפות מעבר-ה-hash. אפילו עם אותה סיסמה, ניתן יהיה למנוע פשרה המונית על ידי יצירת חשבון מנהל מקומי שני עם סיסמה אקראית מורכבת וחסימת ברירת המחדל.

למה יש שירות SSH ב-Windows הזה? פשוט מאוד: כעת שרת OpenSSH לא רק סיפק מעטפת פקודה אינטראקטיבית נוחה מבלי להפריע לעבודתו של המשתמש, אלא גם פרוקסי socks5 ב-VDI. דרך הגרביים האלה, התחברתי דרך SMB ואספתי חשבונות מאוחסנים מכל מאות מכשירי ה-VDI האלה, ואז חיפשתי את הנתיב למנהל הדומיין המשתמש בהם בגרפים של BloodHound. עם מאות מארחים לרשותי, מצאתי את הדרך הזו די מהר. הושגו זכויות מנהל דומיין.

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

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

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

• אל תשתמש בתוכנה מיושנת (זוכרים את Windows 2003 בהתחלה?)
• אל תשאיר מערכות מיותרות מופעלות (למה היה אתר של אורולוג?)
• בדוק את סיסמאות המשתמש לחיזוק עצמך (אחרת חיילים... פנטסטרים יעשו זאת)
• אין את אותן סיסמאות עבור חשבונות שונים (התפשרות VDI)
• ואחר

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

מקור: www.habr.com