הדבקה
מפה
לפני ימים מספר Mesicka.com היה האתר העברי הראשון שדווח לכם על פירצה בסדר גודל ענק במערכת ההפעלה חלונות. שעת תחילת כתיבת הפוסט הנוכחי היא 21:30, כ-40 דקות לאחר ש-HD Moore, חוקר הפירצה, פרסם את הפרטים הטכניים שבוודאי ידווחו באמצעי תקשורת רבים, אלא אם יושתקו באמצעים כלכליים על ידי החברות הנכונות. למרות הזמן הרב (יחסית) שעבר מאז שדווח על הפירצה לראשונה ולמרות גודלה הבלתי נתפש כמעט במערכת ההפעלה, עבדכם הנאמן עדיין לא הצליח לאתר אף מקור עברי אחר שדיווח עליה (למה?!). בפוסט זה אשתדל להביא את הפרטים, כפי שהביא אותם HD Moore – איש אבטחת המידע שאחראי על פרויקט הענק Metasploit, והעומד מאחורי חברת האבטחה Rapid7.
תחילת הדרך – מונחים בסיסיים
תחילת המחקר מקומו בכלל במאמר על פירצה בתוכנה iTunes, שפורסם לפני כשבוע באתר האבטחה SecurityFocus על ידי ACROS Security, ומתאר את אותה הפירצה כ-"Binary planting" ("נטיעה בינארית" או "שתילה בינארית"). התקפה זו (Binary Planting) עושה שימוש בתוכנות הנמצאות במחשב המותקף, ומריצות קבצים בינאריים מסוימים הנטענים עם עליית התוכנה או במהלך ריצתה. במקום הקובץ הבינארי שהתוכנות ייעדו להריץ, שותלים ההאקרים קובץ אחר שבו יש קוד זדוני. כך נוצר מצב שהתוכנה הלגיטימית, כשמופעלת, מריצה קוד זדוני על המחשב. דוגמה סתמית: התוכנית School.exe מריצה דרך קבע את התוכנית Marks.exe כאשר המשתמש מבקש להכניס ציונים. האקר שמכיר את דרך פעולתה של התוכנה, יכול להחליף את הקובץ Marks.exe בקובץ זדוני (נניח: Virus.exe ששינו את שמו לMarks.exe), וכך לגרום להרצת אותו קובץ זדוני.
כיצד מיושמת פירצה זו על iTunes? לא להבהל מהפרטים הטכניים – הכל מוסבר בהמשך. נתחיל בתיאור קבצים מסוימים הנקראים קובצי DLL (או בשמם המלא: קובצי Dynamic Link Library). אותם קבצים נקראים "ספריות", ומכילים פונקציות מוכנות לעבודה (כשם שספרייה אמיתית מכילה ספרים – DLL היא ספרייה המכילה פונקציות מוכנות עבור תוכנות). כל תוכנה יכולה להשתמש בDLLים, ואף יתכן מצב בו מספר תוכנות משתמשות באותו DLL. אם אני מתכנת תוכנה להכנת קפה, למשל, אוכל לגשת ל-DLL בשם מסויים ולבקש ממנו "עזרה" בשפיכת הסוכר. במקרה זה, Coffee.exe (התוכנה להרצת הקפה) תבקש לטעון את CoffeeHelper.DLL (קובץ הDLL שמאחסן את הפונקצייה), ואז תשתמש בפונקציית שפיכת הסוכר שנטענה. יתכן, אגב, שב-CoffeeHelper.DLL יש פונקציות נוספות (כמו ערבוב הקפה), שבחרתי שלא להשתמש בהן, אך הן יטענו בכל מקרה עם טעינת ה-DLL.
הנושא הוא קצת מורכב ולכן יהיה בעייתי לפרט אותו לעומק, אבל בואו נניח שאותו CoffeeHelper.DLL קיים רק ב-Windows 7 (ולא בגירסאות קודמות כמו Windows Vista ו-Windows XP). אני, מלורי, בחור זדוני שממש שונא קפה ואת מי שיצר את תוכנת הקפה (פיצול אישיות קל), אפתח כונן שיתופי עם בחורה בשם אליס שממש מתחשק לה לשתות קפה, ומשתמשת ב-Windows Vista. אשים שם את Coffee.exe וקובץ DLL בשם CoffeeHelper.DLL שמכיל קוד זדוני, ואהפוך את השני לקובץ מוסתר. אליס תנסה להכנס לCoffee.exe על מנת להכין את הקפה, ומאחר והתוכנה לא תמצא את CoffeeHelper.DLL בתיקייה windows/system32 (התיקייה שמכילה בד"כ את קבצי ה-DLL שמותקנים כברירת-מחדל עם הווינדוס), היא תעבור לחפש אותו בתיקייה הנוכחית של התוכנה – מה שיטען את הקוד הזדוני.
כעת, מכשהבנו כיצד עובד תהליך ה-Binary Planting בקובצי DLL, נוכל לגשת לקריאת המאמר שפורסם ב-SecurityFocus, בו כתובים פרטים מעורפלים אודות הפירצה בתוכנת ה-iTunes: יש לשים קובץ DLL זדוני בעל שם מסויים במקום נגיש עבור המשתמש, ולבקש מאותו משתמש לפתוח קובץ מדיה (דבר שכנראה יטען את אותו DLL). מפרסם המאמר ציין אפשרות של שיתוף בעזרת WebDAV, שתאפשר את קיום הפירצה גם בצורה לפיה לא תצטרך להיות למי שמנצל את הפירצה לגישה ישירה למחשב. לפי טענת הכותב, פירצה זו יכולה לגרום לצרות רציניות, ולכן הוא לא מפרסם פרטים. הפירצה נסגרה בגירסאותיה החדשות של iTunes, ושדרוג התוכנה מוצע במאמר כפתרון הבעיה.
לא רק iTunes – על DLL Hijacking
"הפירצה הזו יכולה להיות מנוצלת כאשר סוג קובץ פגיע מופעל מכל תיקייה שבשליטת התוקף" מסביר מור, "התיקייה יכולה להיות כונן USB, תוכן ארכיון שחולץ או קובץ שיתופי ברשת. ברוב המקרים, המשתמש יצטרך לדפדף לתיקייה ולהפעיל את קובץ היעד על מנת שהפירצה תעבוד".
הפירצה באה לידי ביטוי כאשר תוכנה לא מציינת באופן ישיר את המיקום במחשב ("נתיב") ממנו היא מעוניינת לטעון את ה-DLL. מערכת ההפעלה "חלונות" אמורה לחפש את המיקום של אותו קובץ DLL (לפי הנתונים שיוצרי התוכנה ציינו) ולטעון אותו מהמקום בו הוא ממוקם. כאשר לא מצוין הנתיב המלא לאותו DLL, מערכת ההפעלה תחפש אותו במספר מקומות המוגדרים מראש במערכת ההפעלה. מקומות אלו משתנים לפי הגדרות האבטחה של המערכת, אבל לרוב יהיו (לפי הסדר, תודה לויקיפדיה):
הנתיב ממנו נטענה התוכנה
תיקיית system32
תיקיית system
תיקיית windows
תיקיית העבודה הנוכחית (CWD = Current Working Directory)
תיקיות שמצוינות במשתני סביבה (PATH)
הבעיה היא שלא כל התוכנות מציינות נתיב מלא ל-DLL, וחלקן אף משתמשות בדרכים לא בטוחות לטעינת DLL-ים (לחבר'ה היותר מעורים – API-ים דוגמת SearchPath). התוכנות שמשתמשות באותן דרכים לא בטוחות (ויש כמה אפשרויות לתכנת דברים הקשורים לDLLים באופן לא בטוח), ינסו לטעון את אותם DLL-ים מתיקיית העבודה הנוכחית, שעלולה להיות בשליטת התוקף. יתכנו מקרים של שיתוף רשתות (ושוב לחבר'ה היותר מעורים – בעזרת פרוטוקולים כמו WebDAV או SMB) בהם התוקף יכול לשתף, אף מרחוק, DLL שהוא עצמו כתב, ומקרים שבהם הקובץ מועבר דרך גישה פיזית למחשב (דוגמת Disk-on-key או CD-ROM). בתרחישים אלו, התוכנה תטען את אותו DLL, שיכול להכיל הוראות זדוניות שירוצו תחת הרשאותיו של המשתמש המריץ. מכאן, שלהאקר שהצליח לנצל את הפירצה, יש כעת הרשאות בדיוק כמו לתוכנה שהריצה את הקובץ.
פתרונות לחסימת DLL Hijacking
זהירות! טכני! לא לקרוא אלא אם אתם גיקים בטירוף / מפתחים / בעלי שרתים / משועממים במיוחד (זה רק אני או שארבעתם זהים?):
לבעלי שרתים: יש לחסום התקשרויות דרך SMB ו-WebDAV, ולהשבית את ה-Web Client בכל שולחנות העבודה דרך ה-group policy.
למתכנתים: השתמשו בLoadLibrary, LoadLibraryEx, CreateProcess, ShellExecute. אל תשכחו לציין נתיב מלא! השתמשו ב-DLL Redirection על מנת לוודא שהקובץ DLL הנכון הוא זה שנטען. השתמשו ב-Safe DLL Search Mode, ואל תשכחו לוודא אתגירסת מערכת ההפעלה לפני השימוש בLoadLibrary. להצעות נוספות הסתכלו במקורות לקריאה נוספת.
סוף טכני!
דברי סיכום
עוד לפני שפורסמה עם פרטיה הטכניים, אמר מור על הפירצה שהיא גורמת לפירצת הLNK להראות כ"חסרת טעם", והפך את פירצה זו באופן חד משמעי לאחת ההתקפות שכנראה ירשמו בהיסטוריה, הן בגלל חומרתן, הן בגלל מספר התוכנות הפגיעות לבאג זה והן בגלל כמות ההאקרים שהולכים לנצל אותן. מספר התוכנות על פי מור עומד על 40 בלבד, בזמן שלדעת שאר החוקרים הוא עומד על יותר מ-200. אולי דווקא בגלל סיבות כאלו אני כל-כך מתקשה להאמין שהעניין עדיין לא פורסם בשום בלוג אבטחת-מידע עברי רציני ואפילו לא בכלי תקשורת עברי מרכזי אחד, וקורא לחבר'ה היצרנים בסצנה קצת להתעורר – הייתי שמח לראות מאמרים שלכם בנושא (ועם זאת אני שמח להיות בין המקומות הראשוניים בעולם ששופכים אור ומפרטים באופן רציני על הפירצה – הייתי שמח לראות גם אתכם).
בנוסף להסבריו הטכניים הארוכים על הנושא, הראה מור גם כלים שפיתח על מנת לבדוק האם תוכנית ספציפית ניתנת לניצול על-ידי הבאג (לא אכנס לפרטים, תוכלו למצוא אותם למטה).
לסיום, נגלה שמור מדווח על דבר מצחיק, אם כי לא נדיר: חוקרי אבטחה מאוניברסיטת קליפורניה, דייויס, כבר דיווחו למיקרוסופט לפני חצי שנה על הפירצה הזו ואף הוציאו עליו מאמר. למרות זאת, היא לא זכתה לתיקון על ידי חברת הענק עד עכשיו. זאת ועוד: מיקרוסופט עומדת על דעתה שעל הפירצה אחראיות יצרני התוכנות, ושהיא איננה מתכוונת לפתח טלאי מתאים שיסגור את חור האבטחה.
* תודה ל-Zerith על תשובה לשאלה כללית, ל-Interruptus על תשובה לשאלה טכנית ול-TheLeader שעבר על המאמר לפני פרסומו על מנת לוודא שאין שגיאות טכניות ואחרות.
מקורות לקריאה נוספת: פוסט טכני של HD Moore [כולל כלי ניתוח], פוסט כללי של HD Moore, פוסט של Microsoft בנושא, דרכים לתכנות בטוח עם DLL-ים ב-MSDN, המאמר של חוקרי האבטחה מאוניברסיטת קליפורניה.