Validating .NET Framework Assemblies

Question

I just went through our german VB.NET forums and there was something interesting that gives me some kind of headache.

It is actually possible to edit the .NET Framework assemblies using ReflexIL or some other IL editor. The only thing you have to bypass is the Strong Name signature of the assembly. After changing the assembly IL, you have to run sn.exe -Vr [assemblyname] to kinda skip the strong name validation. After that you have to clear the cached native images. Just go through the C:\Windows\assembly directory and delete every image related to your assembly. Then reboot. When you are logged in, run ngen install [assemblyname]. Now the new native images are generated.

This works. I verified this procedure in my virtual environment (Windows XP x86). Now the thing that worries me the most is that you can easily bypass the .NET VerifyHash or VerifyData methods of the RSACryptoServiceProvider. This actually works, too. A friend of mine and me tested could verify this issue (see screenshots). That was fairly easy.

For example, if I'd create a licensing system built on the .NET Framework cryptography classes, it could be bypassed system-wide for every .NET application on the system using the framework. Also, everybody can log and change the input of functios that I call just by hooking into the methods.

Now my question is: Since this can be a huge problem, how can I do something about that? Of course a malicious user could just edit my application, but that would not be as bad as doing this system-wide. I was thinking about some framework checksum validation, but since there are alot of different updates for the .NET Framework, this seems to be impossible.

Any solutions or suggestions? Does Microsoft take care of this problem in some way?

Answer 1

If an attacker has admin access to your computer (which is required for the attack you described), then you've pretty much lost. Anything you could do could be circumvented by the attacker.

Because of that, I think it is completely pointless trying to defend against this type of attack. If you have to deal with untrusted, potentially compromised computers, then you simply can't trust them to do anything sensitive and you have to do it on your own server, or something like that.