Secure Software Development with Delphi 8 for the Microsoft .NET Framework

1. Secure Software Developmentwith Delphi 8 for the Microsoft .NET Framework Steve Teixeira CTO, Falafel Software Inc.

2. Agenda • Security: the “what,” “why,” and “who” • Inherent .NET security protections • Obfuscation • Cryptography • Assembly strong naming • ASP.NET / Web services security • Code Access Security

3. Why we’re here • With the proliferation of threats and growing industry awareness of vulnerabilities and security breaches, it has become imperative for software developers to have a well-rounded knowledge of security concepts. • Responsibility for security can no longer be pushed to the systems management side; responsibility begins and ends with the developer.

4. Goals • This presentation is intended to open your eyes to the broad range of .NET security issues and their potential solutions. • Along the way, we will explore much of the breadth of .NET security, visit with new and emerging standards, and drill down into implementation details for several select topics. • By the end, you’ll understand what issues you can expect to face and strategies for surmounting them.

5. What is “security”? • Authentication • Authorization • Access control • Privacy • Integrity • Uniqueness • Availability • Non-repudiation • Infrastructure • Endpoint protection • Auditing • Physical

6. Why secure? • Competitive reasons • Provisioning • Proprietary data exchange • Commerce information • Legal requirements • Keeping the honest folks honest • Government / national security • Sneaky

7. Security and The Art of War(with apologies to Sun Tzu) • If you know neither your enemy nor yourself, rarely will you stand victorious after a battle. • If you know only yourself but not your enemy, you will lose a battle for every one you win. • If you know both your enemy and yourself you need to fear the result of a thousand battles.

8. Remember: It’s not paranoia if they really are out to get you  • The Evil Genius • Found: Villain in Bond movies • Motivation: Intellectual challenge • M.O.: Well-crafted attacks targeting OS and common application vulnerabilities • Outlook: A dying breed • The Rock Chucker • The Mole • The Gordon Gecko

9. Remember: It’s not paranoia if they really are out to get you  • The Evil Genius • The Rock Chucker • Found: Online, practicing b@d sp3ll1ng • Motivation: Better than PlayStation • M.O.: Scripted / modified generic attacks, especially DDoS • Outlook: A growing problem. Some attacks easily preventable, some not • The Mole • The Gordon Gecko

10. Remember: It’s not paranoia if they really are out to get you  • The Evil Genius • The Rock Chucker • The Mole • Found: In the next cubical • Motivation: Revenge / selfishness • M.O.: Attacks from within, customized to the target, understands target • Outlook: The most common hacker • The Gordon Gecko

11. Remember: It’s not paranoia if they really are out to get you  • The Evil Genius • The Rock Chucker • The Mole • The Gordon Gecko • Found: Day trading • Motivation: Profit • M.O.: Whatever does the job • Outlook: Smallest in number but does the most financial damage by a wide margin

12. So, what will they do? Here are some common attacks • Denial of Service • Crash • Arbitrary code execution / privilege elevation • Virus • Zombification / Spyware

13. Inherent Security • Memory manager prevents buffer overrun-type errors • Special treatment of unsafe and unmanged code • Pointers and direct memory manipulation are not allowed in normal code

14. Obfuscation • Provides some protection of your code’s intellectual property. • Obfuscation scrambles an assembly’s IL code, making it considerably more difficult to reverse-engineer the software. • Works by giving types, methods, etc. confusingly brief names and by overloading methods like crazy. May also encrypt strings and provide other protection measures. • Note: obfuscation does not make it impossible to figure out your code, just more difficult.

15. Strong Naming • Strong naming provides a means for unambiguous naming of assemblies as well as integrity verification • Note: a strong name does NOT imply trust • Two steps to strong naming: • Generate a keypair with sn.exe • Sign using [assembly: AssemblyKeyFile()] attribute • Optional: Delay-sign developer builds

16. Cryptography • Symmetric key (or “shared secret”) algorithms • Same key is used for encryption and decryption • Less resource intensive than asymmetric key algorithms • Since key has to be distributed, there is a chance it – and therefore the cryptographic protection – can be compromised. • Good for applications requiring speedy cryptography where client and server can meet privately in advance to exchange the key • Asymmetric key algorithms • Different keys used for encryption and decryption • The public key can be openly distributed, whereas the private key is only known to a single entity • Generally rather resource intensive, which can make scalability an issue • Good for applications requiring strong privacy and systems where client and server cannot meet in advance • Examples: SSL, code signatures • Where to find? There are a number of open source algorithms of both types, and RSA is a good resource for industrial strength algorithms

17. “Weak” encryption • You may consider using “weak” encryption in cases where absolute privacy isn’t paramount. • Examples: • xor bytes with some value to keep the honest people honest • ROT13 in a Usenet group • .NET obfuscation

18. Checksums / Digests • These algorithms produce a “fingerprint” hash of some given buffer of data, which can be compared against a fingerprint taken later to validate the integrity of some data or determine whether it has changed • Spotlight on the three most common algorithms in this area (both are freely available): • CRC-32 • most common checksum algorithm (used in Ethernet, window file system, ZIP files, etc.) • Forms a 32-bit fingerprint value based on some buffer of data that is very likely to change when the buffer changes in the slightest • Fast but does not always produce unique values for different data sets • MD5 • Message Digest 5 is in common use today • Forms a 128-bit fingerprint value based on a sample of data • Chances of collision are statistically extremely minute • Much slower than CRC32 • One way; great for storing “shadow passwords” or similar data • SHA-1 • Similar to MD5, but produces a hash 160-bits in size • Considered more secure

19. Best practice: Hash passwords • Avoid storing passwords in any reversible format • Hash password • Add salt to hash (e.g., value = hash(pwd + salt) • Use a different salt for each machine • Use nonce values when communicating passwords over a network • Send value and nonce, where value = hash(pwd + nonce) • Other data, such as a timestamp, can be added for additional security • Avoid encryption – if a key exists, it will be found • Beware dictionary attacks on passwords

20. Configuring for HTTPS • Create a certificate request • Send request to CA • Obtain and install a certificate • Use “HTTPS” in web, WSDL, and SOAP references • Test • Optional: Require secure communications • Optional: Client certificates for bi-directional authentication

21. ASP.NET Authentication • Built-in support for Windows, Forms, or Passport authentication • Can be used with web applications or web services • Managed mostly via web.config file • Helps you get out of the authentication business

22. SOAP over HTTPS • Advantages: • A convenient and very secure means of ensuring a private connection • No special coding required • Client certificates can add authentication capabilities • Disadvantages: • Certificates add to cost and maintenance • Dependent on HTTP/S protocol • Doesn’t address role-based security or endpoint protection • More difficult/expensive to scale server-side

23. Web Services Security Language • WS-Security is a standard, generic security architecture to be used with web services • Currently a bit cumbersome since support isn’t yet built into tools. • WS-Security provides: • Authentication via username/password or security token (e.g., username, X.509 certificate, or Kerberos ticket) • Message integrity • Message privacy • Document routing • Can be used in combination with: • XML-Signature • XML Encryption • Implemented in .NET Framework’s Web Service Enhancements (WSE)http://msdn.microsoft.com/webservices

24. Form of WS-Security header • <S:Envelope> <S:Header> ... <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"> ... </wsse:Security> ... </S:Header> ...</S:Envelope>

25. Text and Binary security tokens <wsse:Security xmlns:wsse=http://schemas.xmlsoap.org/ws/2002/04/secext> <wsse:UsernameToken> <wsse:Username>steve</wsse:Username> <wsse:Password>swordfish</wsse:Password> </wsse:UsernameToken> <wsse:BinarySecurityToken Id="myToken" ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0... </wsse:BinarySecurityToken> </wsse:Security>

26. Integrity through signatures <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference> <ds:Transforms> <ds:Transform Algorithm="http://...#RoutingTransform"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>EULddytSo1...</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> BL8jdfToEb1l/vXcMZNNjPOV... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature>

27. Privacy through encryption Encrypted content within envelope body: <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" Id="enc1"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#3des-cbc"/> <xenc:CipherData> <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0... </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData>

28. Message uniqueness • Even with fancy data encryption and signatures, bear in mind the threat of “playback” attacks • To avoid these type of attacks, it’s a good idea to “stamp” each method call with a timestamp or serial number to ensure uniqueness • WS Utility “Timestamp” tag a useful and standard way to do this

29. “Home Grown” solutions • Until recently, home grown authentication and privacy solutions were common due to slow-to-emerge standards • They typically involve “special treatment” of function parameters • While seemingly expedient, home grown solutions may do more harm in the long run in terms of hampered interoperability and maintainability

30. Permissions • A permission is a set (or subset) of capabilities • All permissions implement union, intersection, and subset operations • There is a partial order defined over all instances of a permission • Permission types are orthogonal • A demand for a permission of type A must be satisfied with a grant of a permission of type A • Requiring “set mathematics” has drawbacks • Ex: Implementing regular expression semantics is hard

31. FileIO FileDialog IsolatedStorage Environment Registry UI Printing Reflection Security Socket Web DNS OleDb SQLClient MessageQueue EventLog DirectoryServices … extensible Permissions Protect Resources Execution, Assertion, Skip Verification, Unmanaged code, Control evidence, Control policy, Control principal, Control threads

32. Permission Enforcement • Load time and run time security checks • Declarative security operations are made by annotating source code, appear in metadata • Also used for permission requests • Imperative security operations are performed via object creation and method invocation • Permission demand checks that all callers have the specified permission(s) granted • Stack walk guards against “Luring attacks” • Also have direct security checks (no stack walk behavior): fast but use at own risk • Overrides of stack walk: e.g. assertion

33. Imperative Security Actions • Actions occur at runtime as part of a method body, just like any other call • All permission objects have a Demand() method to invoke a security check for that permission. • Example: Frameworks File object constructor • Requires “read” access to the corresponding file public File(String fileName) { // Must fully qualify the path for the security check String fullPath = Directory.GetFullPathInternal(fileName); new FileIOPermission(FileIOPermissionAccess.Read, fullPath).Demand(); //[…rest of function…] }

34. Design Philosophy for Declarative Security • Make it easy for… • Developers to make security checks in their own programs at the method or class level • Code auditors, reviewers & automated tools to see where security-related actions are taking place • Assembly authors to state their requirements to the policy system, so policy can fail them early if it refuses to meet their requirements

35. Declarative Security Actions • Actions are declared as a custom attribute • Persisted as metadata at compile time • Checks occur at run-time or bind-time depending on the particular action • Demand() occurs at runtime • LinkDemand(), InheritanceDemand() occur at bind-time • Bind-time actions are automatically invoked by the JIT compiler when the caller is compiled or the subclass is loaded • For run-time declarations, the JIT compiler emits code performing the security check

36. Declarative Security Demand • An example declaration (Delphi): [FileIOPermission(SecurityAction.Demand, Write = ‘c:\temp’)] procedure foo() begin // class does something with c:\temp end; • In v1 of the CLR, security declarations cannot contain runtime variables • Permission state must be completely specified at compile-time • Some compiler support required to enable declarative security

37. That’s all, folks! Questions?