Application Security - each one, teach one

Writing to Registry? Some best-practices...

richardl — Tue, 30 Jan 2007 22:04:00 GMT

Use the following best practices when dealing with the Windows registry.

Use of registry reduces application portability. Therefore, use only if required.
Don’t use the registry as a configuration trash–bin.
Don’t store secrets in registry.
Encrypt application data stored in the registry.
Discourage users from directly editing the registry.
Perform input validation on data read and written to registry.
Don’t write data to HKLM. Reading back the data will require the user to be logged on as administrator as by default only Read-access is provided to HKLM all users.
Don't open registry keys for FULL_CONTROL or ALL_ACCESS.

Vista update:
a) Always open registry keys with read-only access when possible. Use read-write access only when needed and revert the permissions back to read-only once the operation is complete.
b) Beware of WRP (Windows Resource Protection) that might be protecting a hive you might want to store your app data into and may result in access denied error message and ultimately broken app functionality.
c) How to find out if WRP is active for a registry key, Two ways of doing this.

a. Programmatic: Call the SfcIsKeyProtected function in your code .
b. Administratively: Use Regedit by right-clicking the key in question  Permissions. Keys that are WRP will show Trusted Installer with Full Control. SYSTEM, Administrators, and Users will only have Read permissions.

d) Hopefully, the registry changes are being doing through a thick-client and not IE. If it is IE, btw, remember that in Vista runs IE in protected mode and so wont be able to store to HKCU.

Code signing mini-FAQ

richardl — Thu, 25 Jan 2007 19:59:00 GMT

What really is code signing?
At a high level, code signing allows you to generate a digital signature for the application binary and then provides a mechanism to carry the signature right to the end user. When the end user invokes the application, the digital signature is verified by the user and the user is able to make an informed decision whether the executable must be executed on his/her machine. Code signing uses digital signatures to provide identity and integrity for the code of software applications. It is important to understand that code signing merely asserts the identity of the software publisher and confirms that the software has not changed since it was signed. Code signing does not make a judgement of the quality of the software or its performance.

How does code signing work?
Let us now try and see how code signing works – Let us first understand the different entities involved in the code signing and verification process. The Software publisher obtains a code-signing certificate from the CA and uses the private key corresponding to the certificate to sign the code. The digital signature obtained is either embedded in the code or sent separately from the code (more on this later.) The software consumer who is typically the end user verifies the digital signature on the code before using the software. If the digital signature is verified successfully and the user trusts the signer of the software, he or she may go ahead and use the software. On the other hand, if the digital signature is not verifiable or the user does not trust the signer then he or she may choose to stop the application in its tracks. The bottom line is that code signing offers application designers a robust method of attaching their identity with the code that they write thereby providing greater user accountability and assurance.

What are some of the code signing technologies?
Microsoft offers two technology options for code signing – these are Authenticode and Strong Names.

Authenticode
Authenticode identifies the software publisher and confirms that the software has not changed since the signature was generated on it. It uses digital certificates as opposed to strong names which uses public keys. Therefore, authenticode allows software users to verify the identity of the software publisher up to a trusted root certificate or up to any certificate that the user trusts. Authenticode does not alter the executable portion of the application. Instead it supports embedded signatures wherein the digital signature is embedded in the non-execution portion of the executable. Examples where embedded signatures are used are in File Download box, the UAC prompt in Vista and the Windows loader. Authenticode also supports detached signatures in which signed catalog files are used to store the hashes of all files that require to be signed. The principal advantage of using detached signatures is when the file format does not support embedded signatures. Another advantage is performance as you have to sign (and verify) a group of files only once if you use detached signatures since the catalog files can reference several files at the same time. Authenticode is more prolific in terms of the number of the file formats that it supports viz. PE (.dll, exe, sys, ocx), Cabinet files and Windows installer files (.msi and .msp)

Strong Names
Strong name signing is used exclusively with .NET assemblies. Although digital signatures are used to generate strong names, it is important to understand that strong naming does not use digital certificate, instead it uses and supports public keys only. This means that it is not really possible to establish a chain of trust for the public key; and therefore there is no way to bind the identity of the software publisher to the private key being used to sign the assembly. Since strong names do not support digital certificates, they do not support expiration or revocation of key material either. This means that extra precautions must be taken by the software publisher to keep the private key private and to securely distribute the publisher’s public key to those assemblies that reference the signed assembly. In order to tide over these limitations, it is recommended that strong names be used along with authenticode, where possible.

What are the best practices for code signing?
Having now discussed the various options available for code signing let us now take a look at the best practices for code signing.

The first one is that you should use code-signing where you can. Code signing puts your product (and your organization) in the league of those organizations who are ready to run the extra mile in reassuring their customers about the reliability of their software. Code signing also tends to create a strong brand recall in the mind of your users when they are using their software. Its like having the About box of your software automatically pop up everytime the user runs your software!

We move on to the second one. Microsoft recommends that commercial software publishers use a different code-signing infrastructure to test sign pre-lease builds of their software. As part of this infrastructure, test publisher certificates must chain to completely different certificates than the root certificate this is used to sign the publicly released version of the software. Also it is much more efficient to use test signing rather than use signing for daily use during development. This helps in the configuration management space too as the using test certificates for signing ensure that pre-release code is not accidentally released to the public.

This point particularly applies to code that will be released to the public. As mentioned earlier, the keys used to generate and verify the signature on code are confidential items and therefore unless if the provided keys are not strongly authenticated, they must not be used for automatic code signing.

Strong naming does not use digital certificates and therefore does not support revocation and expiration. It is therefore imperative that the keys used for strong naming be protected in a failsafe manner.

To take care of the strong name shortcoming mentioned in the previous point, it is always a good idea to couple strong name signatures with authenticode signatures.

What are some of the tools for code signing?
Having seen some of the best practices when using strong naming let us now see some tools that you can use for code signing.

MakeCat – This tool creates an unsigned catalog file that contains the hashes of a specialised set of files and their associated attributes. This allows an organization to sign a single file – the catalog – instead of signing numerous individual files. This tool relies on a catalog definition file (.cdf) that the user must create which contains the list of files to be cataloged and their attributes. The tool scans this file, verifies the attributes, adds the attributes to the catalog files and hashes and stores the hash values in the catalog file.

SignTool – This is a command line tool that signs, verifies and timestamps all formats supported by Authenticode. This tool is a well-endowed tool in that it can sign and verify signatures, check if certificates are revoked and also wheter a signing certificate is valid for a specific policy.

Strong Name Tool (sn.exe) – This tool is used to sign .NET assemblies. It also allows for key management, signature generate and signature verificateion and supports strong name test signing , delay signing and release signing.

That's it folks.

Cryptography Cognizance for Application Designers and Developers

richardl — Wed, 24 Jan 2007 21:03:00 GMT

Here's the abstract for a whitepaper I am beginning to write -

Cryptography is increasingly emerging as an essential and must-have ammo in the arsenal of application designers and developers. Reliance on cryptography is a critical part of an application’s security strategy and is an unstated yet expected requirement for satisfying the security needs of business applications. The ever increasing list of threats and their corresponding countermeasures confound the application developer and lead to incorrect cryptographic choices. The complexities associated with cryptography only compound this problem. This has led to developers seeing cryptography as a silver bullet that will solve their applications security problems and kill the ‘werewolf’ aka hacker. Also, with so many mitigation options available, it is often difficult to volition one mitigation technique over the other leading to a void in the understanding of the application designer.

This whitepaper fills up exactly that void by delving into cryptography concepts that developers should be cognizant about and incorporate in their application security strategy. Microsoft is a market leader in application security and we believe our vast experience in the application security arena qualifies us to share our insights with the application development community at large.

At a broad level, the whitepaper is divided into two logical parts –Warm-up and Deep-dive.

The Warm-up portion of the whitepaper will give the reader a gentle introduction to application security and the role of cryptography in the application security landscape. It will also encompass a short discussion on various cryptographic primitives available and clears the common misconceptions surrounding these primitives. This is followed by a discussion on various cryptography terminology and technology choices available.

The Deep-dive portion of the whitepaper provides a detailed overview of how cryptography offers various security services to applications in the areas of code security, authentication, authorization, non-repudiation, replay protection, timestamping, application provisioning and federation. Code samples will be demonstrated where applicable. Best practices when using cryptographic APIs will be discussed. Common mistakes made when using cryptography and ways of correcting them will also be covered.

All in all, my vision for this whitepaper is to leave the reader with a panoptic understanding of cryptography and a higher level of cryptography cognizance. The goal is for the reader to be more comfortable and foster increased productivity in the cryptography arena.

Understanding 'padding' in symmetric key cryptography

richardl — Tue, 23 Jan 2007 04:12:00 GMT

Symmetric key algorithms like 3DES, AES etc operate on blocks of input data. For this to happen, the length of the input data must be exactly equal to the block length or an integral multiple of the block length for that algorithm. For example, let us take AES 128-bit encryption. Lets say the block length is 128-bits or 16-bytes in this case. Imagine that the input data to be encrypted (called plaintext in cryptographic parlance) has size 20-bytes. No prizes for calculating that we are 4-bytes off the block length in this case. In order to make the input data length a multiple of the block length we need to pad it. In this case,

20 bytes will require (16 - (20-16)) = 12 bytes of padding.

Therefore, as mentioned earlier padding is used when the plaintext's length may not be an exact multiple of the algorithm's block size. Padding, therefore, allows stuffing the end of the message to fill the last block. If PKCS7 padding is used the last block is padded with integers, each of which is the number of bytes used to pad the message. As an example, if the plaintext requires say 5 bytes of padding, the padding would be "0x05, 0x05,0x05, 0x05,0x05". If no padding is used then we have to ensure that the length of the plaintext is an exact multiple of the block size of that algorithm. If zero-padding is used, the last block is padded with zeros.

Temporary file generation and usage best practices

richardl — Tue, 23 Jan 2007 04:07:00 GMT

This article previously appeared at CodeProject.com

Introduction
Many applications require to create and maintain temporary files. Often these temporary files are created without the enduser knowing about the same. Security attacks realized due to insecure temporary file management is a critical category of security attacks on software applications. Application developers are required to follow certain security best practices when creating temporary files. In this article I shall discuss these best practices.

Vulnerabilities due to poor tmp file implementations
Attack#1
victim.c:
filename = mktemp(template);
fd = open(filename, …);

But an adversary can create a file with the same name between the two statements.
Then, victim.c will either end up opening the adversary’s file, or will fail to create the temporary file itself.

Attack#2 Symbolic Link Vulnerability
If the attacker knows where the application creates its temporary files and can guess the name of the next temporary file, the following attack can be realized:
- Attacker will put a symbolic link at the temporary file location.
- The attacker will link the symbolic link to a privileged file.
- Now, the application will unknowingly write to the privileged file instead of writing to the file in the temp directory.

Security Considerations when designing Temporary File modules
1. Avoid temporary files altogether
Temporary files often end up creating more problems than solving them. The effort (time/money) required to develop a temporary file management module often outweighs the features that get added to the application.

2. Reasearch the platform support for temporary files
Before starting out to code the temporary file generation module, assess the existing support for file generation on the target platform. For example, Windows has the GetTempPath() API call that provides the default temporary directory path.

3. Ensure file name uniqueness
The filename of the temporary file must be unique. This ensures that the application does not end up clobbering any existing data on the disk. If a file having the same name already exists on the disk, the logic of file name generation should generate (see next point) a new file name and use that instead.

4. Ensure file name randomness
When generating the file name of the temporary file ensure that the name is not guessable. Typically, the default APIs that are supplied by the operating system for generating temporary files create filenames containing monotonically increasing integers. Therefore it becomes possible to predict the filename of the next temporary file that the application will generate. Use cryptography to generate unique file names. For eg. the CryptGenRandom() (Win32) function or the Guid.NewGuid() (.NET) functions may be used to achieve this.

5. Ensure proper permissions for the temporary file
Ensure that the temporary file have the appropriate ACLs (access control lists) set on them. Avoid publically writable temporary directories if possible. If using a publically writable directory, make a directory within the publically writable directory for temporary files, with read and write permissions for the application only. Temporary files are often used to hold intermittent state information about the operation in progress and may contain confidential information.

6. Ensure secure cleanup of temporary files after usage
One of the most common attacks on applications that use temporary files is the recovery of previously deleted temporary files from the disk. This is trivially possible with the help of software available on the Internet. In order to mitigate against this operation, shred temporary files. Depending on the sensitivity of the information contained in the temporary file, ensure that the cleanup is commensurate with the security levels desired.

7. Prevent covert access
Sometimes the application's temporary files containing sensitive information may be indexed by the underlying Operating System service that may be active on the user system. For example, the indexing service on Windows, when active, silently builds an index of all files on disk. It is possible that sensitive information will end up getting indexed so that a malicious user may use the Search Files/Folders feature to obtain application intelligence.

8. Dont use dangerous functions for temporary file generation
Dont use mktemp(), tmpnam(), tempname(), tmpfile() for generating temporary files. Also don’t reuse the parameter in mkstemp(f) in any other function call, such as stat(), chmod(), etc because the same name may refer to a different file.

9. Avoid storing very sensitive information in temporary files
As a rule, avoid storing sensitive information in temporary files. This is a very common reason for most attacks on applications. An application may employ sophisticated security safeguards such as encryption for securing its data but between encryption may be unwittingly storing sensitive information to an unprotected temporary file. Avoid this at all costs.

10. Rely on absolute file paths and file handles
When building the file paths of the temporary file, use absolute paths. Do not use relative file paths. Also, if the directory path where the temporary files are being housed is being accepted from the user, ensure that it has been sanitised. To prevent time-of-check-to-time-of-use (TOCTOU) attacks, ensure that you use file handles (and not file paths) for future access to the temporary files. Many a vulnerability have been imputed to applications using relative file paths for temporary file access.

11. Securely create temporary files
If open() is being used to create a temporary file use the O_CREAT|O_EXCL flags. If the Windows CreateFile() is being used to create a temporary file use the CREATE_NEW attribute. Calling the APIs with these flags ensures that these APIs fail if a file is already present with the same name in the temporary directory.

12. Dont rely or allow user input for content types (From Guidance Explorer)
Dont allow a user to influence the content disposition or content type as there may be a possibility for header injection. For example, if you are expecting a report to be user uploaded in the form of a pdf file, do not allow the user to set the content type.

Conclusion
Temporary files are sometimes very useful for the application developer. However, improper implementation of temp file modules leads to the realization of several attacks on the application. The application developer must use the techniques contained in this article to mitigate against these security issues.

Welcome

richardl — Tue, 23 Jan 2007 03:55:00 GMT

Hi - I am Richard Lewis and am proud to have joined the ACE team at Microsoft. We are heavily into application security - that means we do security code reviews, application threat modeling and a host of allied services.

I joined this team on the 15th of January 2007 and, well, cant seem to get enough of what the work out here which is absolutely exciting. Keep writing in. You can contact me any time richard dot lewis at microsoft.com.

Bye and happy (and secure) coding!!