Saturday, December 12, 2009

Disabling Strong Naming - A Pirate Method

/////////////////////////////////////////////////////////
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 for verification skipping (with an optional, comma
separated list of usernames for which this will take effect and an
optional test public key in ).
can be specified as * to indicate all assemblies or *, to
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.




2 comments:

  1. Ha! I'm pretty sure this proves that Strong Naming was not intended for security.

    ReplyDelete
  2. Using 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....

    ... 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.

    ReplyDelete