השמיים רוב התקפות הסייבר להסתמך על אישורים גנובים - שהושגו על ידי הטעיית עובדים ומשתמשי קצה לשתף אותם, או על ידי קצירת אישורי דומיין שנשמרו במטמון בתחנות עבודה ובמערכות אחרות ברשת. האישורים הגנובים הללו נותנים לתוקפים את היכולת לנוע לרוחב בתוך הסביבה כשהם מסתובבים ממכונה למכונה - הן במקום והן בענן - עד שהם מגיעים לנכסים קריטיים לעסקים.
ב הפרת אובר עוד בספטמבר, תוקפים מצא את האישורים בסקריפט PowerShell ספציפי. אבל יש הרבה דרכים פחות נוצצות, אך מזיקות באותה מידה שתוקפים יכולים למצוא אישורים שיאפשרו להם גישה לסביבה. אלה כוללים אישורים מקומיים נפוצים, משתמשים מקומיים עם סיסמאות דומות ואישורים המאוחסנים בתוך קבצים בשיתופי רשת.
במחקר שלנו, התמודדנו עם השאלה איזה סוג של מידע ניתן לחלץ ממכונה שנפרצה - מבלי לנצל נקודות תורפה כלשהן - כדי לנוע לרוחב או לחלץ מידע רגיש. כל הכלים שהשתמשנו כאן זמינים אצלנו GitHub מאגר.
ארגונים מסתמכים על מספר כלים לאימות לשרתים ומסדי נתונים באמצעות פרוטוקולי SSH, FTP, Telnet או RDP - ורבים מהכלים הללו שומרים אישורים על מנת לזרז את האימות. אנו מסתכלים על שלושה כלים כאלה - WinSCP, Robomongo ו-MobaXterm - כדי להראות כיצד תוקף יכול לחלץ אישורים שאינם טקסט ברור.
WinSCP: אישורים מעורפלים
כאשר בקר תחום אינו זמין, משתמש יכול לגשת למשאבי מערכת באמצעות אישורי מטמון שנשמרו באופן מקומי לאחר כניסה מוצלחת לתחום. מכיוון שהמשתמש היה מורשה בעבר, המשתמש יכול להיכנס למחשב באמצעות חשבון הדומיין באמצעות אישורי מטמון, גם אם בקר הדומיין שאימת את המשתמש בעבר אינו זמין.
WinSCP מציעה אפשרות לשמור את פרטי האישור המשמשים לחיבור למכונות מרוחקות באמצעות SSH. בעוד שהאישורים מעורפלים כאשר נשמרים ברישום של Windows (ComputerHKEY_CURRENT_USERSOFTWAREMartin PrikrylWinSCP 2Sessions), הם אינם מוצפנים כלל. כל מי שמכיר את האלגוריתם המשמש לערפול יכול לקבל גישה לאישורים.
מכיוון שקוד המקור של WinSCP זמין ב-GitHub, הצלחנו למצוא את אלגוריתם הערפול. השתמשנו בכלי שהטמיע את אותו אלגוריתם כדי לטשטש את האישורים, והשגנו גישה לאישורים בטקסט ברור.
הטמעת אלגוריתם ערפול לאבטחת אישורים מאוחסנים אינו שיטות עבודה מומלצות, מכיוון שניתן להפוך אותו בקלות ולהוביל לגניבת אישורים.
רובומונגו: לא מפתח סודי
Robomongo (כיום Robo 3T) הוא לקוח MongoDB המשמש לחיבור לשרתי מסד נתונים של Mongo. כאשר אתה שומר את האישורים שלך, הם מוצפנים ונשמרים ב-a robo3t.json קובץ JSON. המפתח הסודי המשמש להצפנת האישורים נשמר גם הוא באופן מקומי, בטקסט ברור, ב-a robo3t.key קובץ.
זה אומר שתוקף שמקבל גישה למחשב יכול להשתמש במפתח השמור בטקסט ברור כדי לפענח את האישורים.
הסתכלנו על קוד המקור של Robomongo ב- GitHub כדי להבין כיצד המפתח משמש להצפנת הסיסמה ולמדנו שהוא משתמש ב- SimpleCrypt lib מ- Qt. בעוד ש-Robomongo משתמש בהצפנה כדי לאחסן אישורים בצורה מאובטחת, העובדה שהמפתח הסודי נשמר בטקסט ברור אינה השיטה הטובה ביותר. תוקפים עלולים לקרוא אותו, מכיוון שכל משתמש עם גישה לתחנת העבודה יכול לפענח את האישורים. גם אם המידע מקודד בצורה שבני אדם לא יכולים לקרוא, טכניקות מסוימות יכולות לקבוע באיזה קידוד נעשה שימוש, ואז לפענח את המידע.
MobaXterm: פענוח הסיסמה
MobaXterm הוא כלי רב עוצמה לחיבור למכונות מרוחקות באמצעות פרוטוקולים שונים כגון SSH, Telnet, RDP, FTP וכו'. משתמש שרוצה לשמור אישורים בתוך MobaXterm יתבקש ליצור סיסמת אב כדי להגן על הנתונים הרגישים שלו. כברירת מחדל, MobaXterm מבקש את סיסמת האב רק במחשב חדש.
זה אומר שהסיסמה הראשית נשמרת איפשהו, ו-MobaXterm יאחזר אותה כדי לגשת לאישורים המוצפנים. השתמשנו ב-Procmon מ- Sysinternals Suite כדי למפות את כל מפתחות הרישום והקבצים אליהם ניגש MobaXterm, ומצאנו את סיסמת האב שנשמרה ברישום של Windows (ComputerHKEY_CURRENT_USERSOFTWAREMobatekMobaXtermM). אישורים וסיסמאות נשמרים במפתחות הרישום C ו-P, בהתאמה.
בתחילה, לא הצלחנו לפענח את סיסמת האב, שהוצפנה באמצעות DPAPI. בסופו של דבר הבנו ש-20 ה-DPAPI הראשונים, שהם תמיד זהים בעת שימוש ב-DPAPI, הוסרו. כשהוספנו את 20 הבתים הראשונים, הצלחנו לפענח את צופן ה-DPAPI כדי לקבל את ה-hash SHA512 של סיסמת האב. Hash זה משמש להצפנה ולפענוח של אישורים.
כאן, מפתח ההצפנה המשמש לאחסון מאובטח של האישורים נשמר באמצעות DPAPI. זה אומר שרק המשתמש ששמר את האישורים יכול לגשת אליהם. עם זאת, משתמש עם גישת מנהל, או תוקף שמקבל גישה להפעלה של הקורבן, יכול גם לפענח את האישורים המאוחסנים במחשב.
דע את הסיכונים
מפתחים, DevOps ו-IT משתמשים בכלים שונים כדי להתחבר למכונות מרוחקות ולנהל את פרטי הגישה הללו. על הספקים לאחסן מידע רגיש זה בצורה המאובטחת ביותר. עם זאת, ההצפנה היא תמיד בצד הלקוח, ותוקף יכול לשכפל את התנהגות הכלי כדי לפענח את האישורים.
כמו תמיד, אין פתרון קסם שיכול לפתור כל בעיה שדיברנו עליה כאן. עם זאת, ארגונים עשויים להתחיל בבחינת השירותים שבהם הם משתמשים כעת. הם יכולים לבנות מטריצת סיכונים מדויקת ולהיות מוכנים טוב יותר לפרצות נתונים על ידי הבנה חזקה יותר של סוגי הנתונים והאישורים הרגישים שהם מאחסנים.
