Secure Software Developmentwith Delphi 8 for the Microsoft .NET

Framework

Steve Teixeira

CTO, Falafel Software Inc.

Agenda

• Security: the “what,” “why,” and “who”

• Inherent .NET security protections

• Obfuscation

• Cryptography

• Assembly strong naming

• ASP.NET / Web services security

• Code Access Security

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.

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.

What is “security”?

• Authentication

• Authorization

• Access control

• Privacy

• Integrity

• Uniqueness

• Availability

• Non-repudiation

• Infrastructure

• Endpoint protection

• Auditing

• Physical

Why secure?

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

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.

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

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

• 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

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

Remember: It’s not paranoia if they really are out to get you

So, what will they do? Here are some common attacks

• Denial of Service

• Crash

• Arbitrary code execution / privilege elevation

• Virus

• Zombification / Spyware

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

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.

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:

1. Generate a keypair with sn.exe

2. Sign using [assembly: AssemblyKeyFile()] attribute

• Optional: Delay-sign developer builds

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

“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

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

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

Configuring for HTTPS

1. Create a certificate request

2. Send request to CA

3. Obtain and install a certificate

4. Use “HTTPS” in web, WSDL, and SOAP references

5. Test

6. Optional: Require secure communications

7. Optional: Client certificates for bi-directional authentication

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

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

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

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>

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>

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>

Privacy through encryption

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

Encrypted content within envelope body:

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

“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

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

Permissions Protect Resources• FileIO• FileDialog• IsolatedStorage • Environment• Registry• UI • Printing• Reflection • Security

• Socket• Web• DNS• OleDb• SQLClient• MessageQueue• EventLog• DirectoryServices• … extensible

Execution, Assertion, Skip Verification, Execution, Assertion, Skip Verification, Unmanaged code, Control evidence, Control Unmanaged code, Control evidence, Control policy, Control principal, Control threadspolicy, Control principal, Control threads

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

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…]}

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

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

Declarative Security Demand• An example declaration (Delphi):

[FileIOPermission(SecurityAction.Demand, Write = ‘c:\temp’)]

procedure foo()begin // class does something with c:\tempend;

• 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

That’s all, folks!

Questions?