Hacking The Framework

1. Hacking The Framework Nimrod Luria Head Of Consulting Services, 2Bsecure. Security MVP .NET Security User Group Leader. Microsoft affiliate consultant. Nimrod@2Bsecure.co.il

2. Attack sophistication vs. Intruder Technical Knowledge binary encryption Tools “stealth” / advanced scanning techniques High denial of service packet spoofing distributed attack tools sniffers Intruder Knowledge www attacks automated probes/scans GUI back doors network mgmt. diagnostics disabling audits hijacking sessions burglaries Attack Sophistication exploiting known vulnerabilities password cracking Attackers password guessing Low 2001 1980 1985 1990 1995 Source: CERT/CC (used w/o permission & modified “Can you say ‘fair use?’ Sure, I knew you could.” IHO Fred Rogers)

3. Warm Up - Demo • Why you shouldn’t use Custom validator

4. Why should we be aware of security? • 1st Scenario : • In my current smart card company, most of the information stored within our SDK are highly confidential. We do not want our SDK to be manipulated by our competitors. • 2nd Scenario : • You took a year to write a software and in the process consumed a lot of resources and time for its development. Then you sell your software, you find that all your hard work in past 12 months were easily manipulated. Therefore, steps must be taken to ensure this does not happen. • 3rd Scenario : • One day, my manager came to me and asked me this question. • Questions: Are .NET assemblies that secure? • Answer: Nothing is secure, but all we can do is to try to make things harder for a hacker.

5. Reflector • Demo

6. Don’t trust the Registry • Back in 1990s, you may have noticed that some shareware programs implements this kind of verification technique. When you install the software, it will create a key in the Windows registry. Basically what it does, is stores the serial number inside the registry as either a plain text or encrypted version. Yes, I have seen people placing plain text in registry. So when your program runs, it will check the registry to verify the existence that particular key. If you have a wrong serial number or that particular key is not there, it will prompt you an error. Right now I will try to simulate this verification technique in C# step by step.

7. Demo • Manipulating The Registry • Listening with RegMon

8. Internal Representation of Methods by the CLR

9. Let’s Change the code • How to use ILdasm and ILasm to manipulate the code. • Type ildasm CrackingIL.exe /out=CrackingIL.il • Open CrackingIL.il with any text editor • Just remove all the codes from IL_0000 to IL_0075.(Clean FrmSecureApp_Load event) • type 'ilasm CrackingIL.il'. • You are done !

10. protect your .NET assemblies from being tampered • Strong Name key is a RSA 1024 bit encryption, and to break it is not that easy at all. You need to have huge computing power to get that private key. • Why Strong Name??

11. Strong Name, is it strong enough ? • It did not encrypt my codes nor did it hide my codes from decompilers such as .NET Reflector. It isn't even related to obfuscation. So then what is Strong Name for? Some marketing tool to convince the public that the assemblies it protects is secure?

12. What people doing in the industry ? • Your superior comes to you and asks you to implement a Strong Name key in your assemblies. And then when you reply, why Strong Name, they would say this is what other people are doing in the industry; we should follow them as well.

13. It’s seems to be strong

14. But It’s NOT !

15. How to break Strong Name .NET Assemblies • Questions: • Question : Is Strong Name key secure? • Answer : Yes, Strong Name key uses RSA 1024 bit encryption. • Question : Is Strong Name key breakable? • Answer : If you have enough computing power, time and knowledge on how to break RSA, the answer is yes. • Question : Can Strong Name key be removed from .NET assemblies? • Answer : Yes, it can be removed very easily if you know how.

16. Demo • Removing the signature. • Tempering the code.

17. Hijacking .NET • type members defined with a private access modifier are not actually private • Even though the method is private, calling clients can still set the state of the object whenever they want using reflection.

18. Demo • Calling private methods using reflection

19. The SolutionModifying Rotors Source Code [DebuggerStepThroughAttribute][Diagnostics.DebuggerHidden]public override void SetValue(Object obj,Object val,BindingFlags invokeAttr,Binder binder,CultureInfo culture) {       InternalSetValue(obj, val, invokeAttr, binder,             culture, true, binder == Type.DefaultBinder);}  to:  [DebuggerStepThroughAttribute][Diagnostics.DebuggerHidden]public override void SetValue(Object obj,Object val,BindingFlags invokeAttr,Binder binder,CultureInfo culture) {      // Add the check.         if (this.IsPrivate)      {            throw new Exception("Access denied!!!                   Cannot set the value of private fields.");      }      InternalSetValue(obj, val, invokeAttr, binder,             culture, true, binder == Type.DefaultBinder);} 

20. VS 2005 Exploit • Demo

21. Solutions • To make sure that only trusted assemblies are calling your assembly you can use StrongNameIdentityPermission Class • You should use sn.exe –o <infile> <outfile> to get the signature. • You can use imperative or declarative checks. <StrongNameIdentityPermissionAttribute(SecurityAction.LinkDemand, _PublicKey:="002400000480000094000...")> _Public Class myClass...

22. Evidence • Use the wizards

23. Encrypt Your code • Reactor • CryptKey • Preemptive .NET obfuscation

24. In Got We Trust ! • Don’t trust any code. • Use sandbox to test downloaded code or 3rd party assemblies. • Use CAS • Follow the least privilege principle. • Review your code. • Test your applications for security.

25. ?

26. Thank You ! Nimrod Luria Head Of Consulting Services, 2Bsecure. Security MVP .NET Security User Group Leader.