If you haven't yet, please read lesson one.
Alright, so we have our malicious method's code saved off in a text file malicious.txt. Now we need to generate a complete dump of the victim mscorlib.dll. In order to do this, copy the victim DLL from its GAC location under the \Windows\Assembly\GAC_32\mscorlib\ directory to a temp folder.
Now, if you haven't already, add your Microsoft.net SDK location to your PATH environment variable, or just browse to the Microsoft .Net SDK bin folder. If you are running ildasm.exe from the SDK folder directly, remember to modify the location of mscorlib.dll in the following command.
ILDASM /OUT=mscorlib.dll.il /NOBAR /LINENUM /SOURCE \temp\mscorlib.dll
This will generate a fairly large text file of IL that is mscorlib. Open it and search for the signature line of our victim method. Copy our malicious code over the original code, from the .method to the last '}' bracket. Now, if you got the line renumbering right during lesson one, it will compile back into mscorlib.dll and we can move that back into the GAC. When it loads, the path information is what is used to verify any SN requirements on assembly load.
Compile the modified mscorlib.dll.il by running this command (modify this command with the location you wish the output to go):
\Windows\Microsoft.NET\Framework\V2.0.50727\ilasm.exe ILASM /DLL /QUIET /OUTPUT=\temp\maliciousdll\mscorlib.dll mscorlib.dll.il
This will generate a suitable malicious replacement for the mscorlib.dll in the GAC.
So copy the mscorlib.dll to the GAC. If you are in a remote shell and the OS is Vista or Win7 and the shell is not running as SYSTEM or builtin\Administrators, you must use the runas.exe command and use a local admin credential set to get this to run.
copy \temp\maliciousdll\mscorlib.dll
c:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\
You must kill all processes using .Net (the FontCache Service in Vista needs to be stopped, if you get stuck). In Win7, you have to spray and pray on this. I am getting something [a tool] to bypass this together to make it painless.
Alright so now that you have the DLL in the GAC location for the version you are attacking, you must get rid of the ngen registration as well as the actual assemblies. To do this browse to the
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32> .
First, to remove the registration - run the command
ngen uninstall mscorlib
If you are attacking another assembly, just add ' ni' between the filename and extension when running the ngen command.
Search for all files named mscorlib.ni.dll by running
dir/w/s mscorlib*
Delete those files and their directories. If you are a whitehat and reading this, this is a point you can check - if ngen has no listing for your assembly and / or the directories are gone, it is a pretty good idea you have been infected.
Once you remove all references to the native images, your malicious code will now be ready to run. Execute the Console.Writeline(string) method in a test application and you will see it printed twice. No virus scanner or tool will alert a user that his mscorlib.dll is malicious in any way.
Keep hiding in the noise....
-blakdayz
Subscribe to:
Post Comments (Atom)
Posts
What about just unregistering it but not deleting the images? Also could you re-ngen it to make detection even harder?
ReplyDeleteThis requires root perms to perform, so if I have root perms then I curious what advantages framework corruption provides me over other forms of infection?
ReplyDeleteActually, Pjackson, that is the most common argument from the white-hat world. "If this requires root, then what really does it matter? You can do anything as root." That golden axe would, if true, invalidate *anything* involving rootkits. Let's admit that all of you are admins on your work PC's at most organizations - small and really large. Unless you have money like the Fed, no one is going to help Cindy in accounting install the new billing update if they can help it.
ReplyDeleteSo, if I were to rephrase the question with applicable Windows AD context...
"So if you have to be the standard user in the field in order to get this to run, how is that 'a hack'". But there is more if you don't subscribe to that elemental detail normally left out of conversation.
While 'Adding a new user named Guest as admin' is an administrator task, doing it when you thought you were just testing your new function that calls Console.Writeline() is a whole different story.
Actually, there are more than a few things to evaluate that makes this very different from standard *system configuration tasks* as admin.
1. When the manifest of your application's assembly references the mscorlib.dll assembly to implement the Namespace 'System' on compilation, it records a signed hash value representing the *only* version of mscorlib.dll it will allow code to be run from. - which was recorded with Microsoft's highly secured corporate key-pair. This was so important to code security, they implemented delayed-signing, so they could literally lock the CD in the safe with the pair, until the day of a release build.
When your code runs, and it needs mscorlib.dll to host an instance of the CLR, and it looks for that valid Microsoft .Net Framework assembly. When it finds a candidate assembly at the right location, it is supposed verify the signed hash value of that DLL with what it has in it's manifest. This is the point when a Strong Naming violation would normally launch if the DLL failed the verification.
This process apparently occurs with every framework assembly, but mscorlib.dll.
As a matter of point, Microsoft even has a tool that is supposed to be the focal point of Strong Name skipping (google how to turn off strong naming) SN.exe, since there is no other way to supposedly turn it off. =
Now, if the SN.exe tool was used to add a verification skipping record (-Vr *) record, this would be visible to an alert admin. But this doesn't even go there.
The point in both of these posts was to cover a necessary skillset in order to get people onboard framework rootkit development.
Another evaluation point is that the code you write does not change, so it passes security reviews, and virus/malware scanning on the hosts you attack.
So to recap:
1. Even as admin, strong naming is not supposed to be skipped unless I specify it as a verfication skipping record.
2. It is a doorway to disabling strong naming everything else (patching mscorlib can get you there).
3. There is no way to currently detect it without a human looking at the state of .Net on the machine (checking mscorlib, looking for deleted native images, etc..).
4.There is/will be no virus scanner for the JIT
5. Extremely easy to code, very powerful root kits.
cStorm. You must delete the files themselves as well as unregister. About ngen'ing them yourself.... I wonder if you disable SN using SN.exe or patching if you could then bypass that check when running ngen.... As far as mscorlib goes itself, I haven't tried disabling SN and then installing it
ReplyDelete