Secure Software Development with Delphi 8 for the Microsoft.NET Framework Steve Teixeira CTO,...
-
Upload
andrea-glenn -
Category
Documents
-
view
234 -
download
0
Transcript of Secure Software Development with Delphi 8 for the Microsoft.NET Framework Steve Teixeira CTO,...
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?