Note: It should be noted that this is the legit way to get caught. I have only tested this against .Net 3.5 sp1, and only assemblies that are in full trust can be skipped. Patching Strong Naming in mscorlib will get you further than this, without direct fear of being noticed.
Read this:
http://msdn.microsoft.com/en-us/library/cc713694.aspx
12/17/2009
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
There are two ways to disable Strong Naming (a pirate way, and a ninja way). The pirate method is by using the built in Strong Naming Tool (sn.exe). The Ninja way is to patch what you need in the mscorlib assembly via Framework injection. Today we will learn to wear an eye patch.
It is possible to, completely or just partially, disable strong name verification for assemblies.
Sn.exe Argument dump for -Vr switch:
-Vr
Register
separated list of usernames for which this will take effect and an
optional test public key in
indicate that all assemblies with the given public key token. Public key
tokens should be specified as a string of hex digits.
While putting your injected GAC assembly files in place and deleting the ngen derivatives, or in your injected method, just hop out and call
sn -Vr *
This will result in a verification skipping entry for all assemblies and all users.
You can, also target a specific assembly by public key token. To disable System.Windows.Forms.dll strong naming verification, you would run (as of .Net 3.5):
sn -Vr *,b77a5c561934e089
So there you have it. Now I am going to test if this works for getting something ngen'd that shouldn't be.
Posts
Ha! I'm pretty sure this proves that Strong Naming was not intended for security.
ReplyDeleteUsing this method leaves a record behind, along with priveledge use records in the Security event log (if its enabled). The copy command does not do this....
ReplyDelete... This is the way you are supposed to use this to disable it, and you can check for it before running your application.
However, patching mscorlib.dll bypasses this tool. Even as admin, this is not supposed to be possible.
But also, remember the point - these are just skillsets to get rootkit development and detection going. This has been known for sometime (CanSecWest this year), but good rootkits have yet to surface in this layer, and awareness in the .Net development community is scarce.
They all believe the opposite is true w/Strong Naming (that it can't be bypassed without SN.exe, which most of them don't know even allows skipping)
.. You have tend the fields, the sugar cane crop doesn't change itself to Rice when it rains.
This is a fantastic explanation of how to handle Strong Naming with such clarity! The way you’ve broken down both the pirate and ninja methods makes the process accessible and understandable, regardless of the approach you choose. Your step-by-step guide for using the sn.exe tool and managing verification skipping is incredibly helpful. Thanks for sharing this detailed insight—it’s sure to be a great resource for anyone looking to delve into assembly management!
ReplyDeleteEngineering Assignment Help