Tuesday, August 30, 2005

How to Handle Exceptions Securely

Do not reveal internal system or application details, such as stack traces, SQL statement fragments, and table or database names. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary.

When you log or report exceptions, if user input is included in exception messages, validate it or sanitize it.

ASP.NET specifics:

By default, in ASP.NET the mode attribute of the <customErrors> element is set to remoteOnly, which returns complete exception information (including the stack trace) only to callers on the same computer as the server. Remote callers receive filtered exception information. In a production environment, you should set the mode attribute to On, so that all callers receive filtered exception information.

Also set pageOutput="false" on the <trace> element to disable trace output.

Define a global error handler in Global.asax to catch any exceptions that are not handled in code.

Adopted from http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGPractices0001.asp.

Network Service and Event Log

By default, ASP.NET applications that run under the default Network Service identity can write to the Windows event log by using an existing event source, but they cannot create new event sources. To create an event source, your app needs permissions to create a new registry entry beneath the following key: HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\.

You have two options:

  • Grant your ASP.NET process account (or impersonated identity if your application uses impersonation) permissions on the registry key mentioned above.
  • Create the event source at application install time when administrator privileges are available.

Adopted from http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGPractices0001.asp.

Application Development Security Guidance for .NET 2.0

The page Application Development Security Guidance for .NET 2.0 contains many how to links related to security in .NET Framework 2.0.

Monday, August 22, 2005

Instrument and Monitor Your ASP.NET Apps Using WMI

I just finish read Michael Jurek's article Call Mom: Instrument and Monitor Your ASP.NET Apps Using WMI and MOM 2005. Highly recommended.

Microsoft® Dynamic Systems Initiative

The Microsoft® Dynamic Systems Initiative (DSI) provides a roadmap for simplifying enterprise software development, deployment, and management. Current Microsoft products and technologies that support the DSI model for system management include Automated Deployment Services, Microsoft Operations Manager (MOM) 2005, Systems Management Server (SMS) 2003, Virtual Server 2005, and Windows Server™ Update Services. Future technologies expected to extend the DSI model include Visual Studio® 2005 Team System and the System Definition Model (SDM) planned for a future version of Windows Server. (For more information about DSI, see Dynamic Systems Initiative.)

Adopted fromMichael Jurek's article Call Mom: Instrument and Monitor Your ASP.NET Apps Using WMI and MOM 2005.

Sunday, August 21, 2005

Sockets in .NET

I just finish read Daryn Kiely's article Winsock: Get Closer to the Wire with High-Performance Sockets in .NET. It's very good. The part of debugging a sockets application is cool.

Saturday, August 20, 2005

Improving Reflection Performance

Here are some ways to reduce some of the cost of reflection and of the MemberInfo cache.
  • Avoid using Type.InvokeMember to call late-bound methods
  • Avoid case-insensitive member lookups
  • Use BindingFlags.ExactMatch whenever possible
  • Call the non-plural GetXX method if you know the name of the instance you care about (.NET Framework 2.0 only)
  • Cache only the handle to a member (.NET Framework 2.0 only)

Adopted from Joel Pobar's excellent article Reflection: Dodge Common Performance Pitfalls to Craft Speedy Applications.

What Reflection APIs Are Slow and What Are Not?

Fast and Light Functions:
  • typeof
  • Object.GetType
  • typeof == Object.GetType
  • Type equivalence APIs (including typehandle operator overloads)
  • get_Module
  • get_MemberType
  • Some of the IsXX predicate APIs
  • New token/handle resolution APIs in the .NET Framework 2.0

Costly Functions:

  • GetXX APIs (MethodInfo, PropertyInfo, FieldInfo, and so on
  • GetCustomAttributes
  • Type.InvokeMember
  • Invoke APIs (MethodInfo.Invoke, FieldInfo.GetValue, and so on)
  • get_Name (Name property)Activator.CreateInstance

Generally, lightweight functions are fast for one of two reasons: either the reflection infrastructure has the information it needs already stored in super-fast runtime data structures, or the just-in-time (JIT) compiler detects these method calls and code patterns and generates special optimizations to speed things up a bit.

Adopted from Reflection: Dodge Common Performance Pitfalls to Craft Speedy Applications by Joel Pobar.

Emergency Response Process

At a very minimum the process needs to cover the following:
  • Disconnect the system.
  • Who to contact and how?
  • Who will analyze what?
  • How do we restore service?
  • What to do afterward?

Adopted from Protect Your Windows Network : From Perimeter to Data by Jesper M. Johansson, Steve Riley.

How to Make Users Aware of Securities Policies

Policies must be meaningful, actionable, and relevant. During the development of policies, you probably should do some user acceptance testing to ensure that the policies are meaningful to users. It is also worthwhile pointing out that policies must be simple enough to understand and remember for users. The policies have to be accessible to users.

The general user population probably should not have to read more than about five policies, and each of those policies should probably have no more than five to seven important points to them.

Adopted from Protect Your Windows Network : From Perimeter to Data by Jesper M. Johansson, Steve Riley.

Thursday, August 18, 2005

Concurrency: What Every Dev Must Know About Multithreaded Apps

I just finish read Vance Morrison's article Concurrency: What Every Dev Must Know About Multithreaded Apps. It's excellent. Here are my notes.

Using the lock statement only if:
  • No cleanup is needed in its body
  • Everything its body did was read-only

Rules and good practices for using Locks Properly:

  • For a lock to provide mutual exclusion for a region of memory, no writes to that memory can occur without entering the same lock. The programmer should document it!
  • Check whether any of the regions protected by different locks overlap.
  • It is best to have few locks that protect large regions of memory and only split them when lock contention is shown to be a bottleneck on performance.
  • Believing that everything changes unless locks are used to prevent it.
  • The general rule should be that all program memory should fall into one of three buckets: thread exclusive, read-only, or lock protected, with one exception as follows.
  • Finally, in certain specialized cases where the program invariant is relatively weak, it is possible to perform updates that can be done without locks. Typically, specialized compare-and-exchange instructions are used. These techniques are best thought of as special, lightweight implementations of locks.
  • Most reusable code (like container classes) should not have locks built into it because it can only protect itself, and it is likely that whatever code uses it will need a stronger lock anyway. The exception to this rule is when it is important that the code works even with high-level program errors. The global memory heap and security-sensitive code are examples of exceptional cases.
  • In cases where threads read shared structures frequently, but write to them infrequently, reader-writer locks such as System.Threading.ReaderWriterLock can be used to keep the number of locks in the system low.

Deadlocks:

Deadlocks are generally prevented in one of two ways. The first (and best) way to prevent deadlock, is to have few enough locks in the system that it is never necessary to take more than one lock at a time. If this is impossible, deadlock can also be prevented by having a convention on the order in which locks are taken. To prevent this, each lock in the system is assigned a "level", and the program is designed so that threads always take locks only in strictly descending order by level.

The cost of locks:

Another reason to avoid having many locks in a system is the cost of entering and leaving a lock. The lightest locks use a special compare/exchange instruction to check whether the lock is taken, and if it isn't, they enter the lock in a single atomic action. Unfortunately, this special instruction is relatively expensive (typically ten to hundreds of times longer than an ordinary instruction). There are two main reasons for this expense, and they both have to do with issues arising on a true multiprocessor system.

The first reason is that the compare/exchange instruction must ensure that no other processor is also trying to do the same thing. Fundamentally, this requires one processor to coordinate with all other processors in the system. This is a slow operation and accounts for the lower bound of the cost of a lock (dozens of cycles). The other reason for the expense is the effect inter-process communication has on the memory system. After a lock has been taken, the program is very likely to access memory that may have been recently modified by another thread. If this thread ran on another processor, it is necessary to ensure that all pending writes on all other processors have been flushed so that the current thread sees the updates. The cost of doing this largely depends on how the memory system works and how many writes need to be flushed. This cost can be pretty high in the worst case (possibly hundreds of cycles or more).

Wednesday, August 17, 2005

Credentials and Delegation

Keith Brown just published an excellent article Security Briefs: Credentials and Delegation. I highly recommend to read it.

Saturday, August 13, 2005

Some Policies You Might Need

Here are some policies you might need:

  • Acceptable use policy
  • Password policy
  • Remote access policy
  • Antivirus policy
  • Info protection policy
  • Wireless network access policy
  • E-mail access and retention policy
  • Server security policy
  • Privacy policy

Other important policies:

  • Perimeter protection policy
  • Direct tap policy
  • System sensibility classification policy
  • Physical security policy

Adopted from Protect Your Windows Network : From Perimeter to Data by Jesper M. Johansson, Steve Riley.

How To Provide CIA For A Network Connection?

In order to provide the properties of confidentiality, integrity, and authentication for a network connection, we first must perform an authenticated key exchange using a protocol such as Kerberos or CA. Then, for each message we must calculate a MAC over the plaintext, appending it to the message. Finally we must encrypt the message. The receiver should decrypt the message and verify the attached MAC. The MAC and encryption keys should be derived from the session key that was exchanged during authentication.

Adopted from The .NET Developer's Guide to Windows Security by Keith Brown.

What Does A Network Authentication Protocol Do?

A network authentication protocol is really about two things. First, it allows two network peers to develop trust in each other's identity. Second, it allows the two peers to exchange a session key that can be used to provide the properties of CIA for their ensuing conversation.

Adopted from The .NET Developer's Guide to Windows Security by Keith Brown.

Saturday, August 06, 2005

Tampering with Log Files

Here are some common attacks to log files:
  • Take advantage of weak ACLs on log files and directories
  • Modify or delete log files
  • Exploit software weakness in logging mechanisms
  • Exploit configuration weakness in configuration mechanisms

Contermeasures:

  • Secure log file locations
  • Store logs on another host
  • Use encryption to protect log files
  • Use cryptographic hashes to detect tampering
  • Back up log files
  • Keep logging mechanism patched
  • Keep logging mechanism properly configured

Adopted from the book Assessing Network Security by Ben Smith, David LeBlanc, Kevin Lam.

NTFS Alternate File Streams

On NTFS, a file can be composed of multiple strams. One stream is used for actual file data and is created by default, whereas the alternate streams can be used for anything else, such as storing a description of the file or storing search words.

You can insert data into an alternate stream as follows.

C:\> echo "Evil Data" > mydoc.txt:AttackerStream:$DATA

Adopted from the book Assessing Network Security by Ben Smith, David LeBlanc, Kevin Lam.

Hiding Files on Windows Systems

You can use Attrib.exe to hide a file as follows:

C:\>Attrib +h myApp.exe

You can display all the hidden files using the following command:

C:\>attrib.exe /s findstr.exe H".*":

Adopted from the book Assessing Network Security by Ben Smith, David LeBlanc, Kevin Lam.

Friday, August 05, 2005

Some Common Ways an Attacker Can Attack IDSs and IPSs

Here are some common ways an attacker can attack IDSs and IPSs:
  • Using an elevation of priviledge attack
  • Using a denial of service attack
  • Using a non-public attack

Adopted from the book Assessing Network Security by Ben Smith, David LeBlanc, Kevin Lam.

IDSs and IPSs

Both intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) work by inspecting network traffic for attack patterns. When a pattern is identified, the system takes some administrator-defined action. The similarities between the two end there and the differences begin when you consider how each is positioned on the network.

An IDS sits on network segments passively network traffic. An IPS sits inline on the network and where necessary it drops or rewrites packets sent to a host protected by the IPS.

Adopted from the book Assessing Network Security by Ben Smith, David LeBlanc, Kevin Lam.

Tuesday, August 02, 2005

How Attackers Avoid Detection Post-Intrusion

The following are common ways attackers conceal themselves on systems they're already compromised:
  • Using rootkits
  • Hiding data
  • Tampering with log files

Here are some common ways to hide data:

  • Use the hidden file attribute
  • Hide data in NTFS alternate file streams
  • Replace or rename files
  • Use steganography

Adopted from the book Assessing Network Security by Ben Smith, David LeBlanc, Kevin Lam.

Some Common Ways Attacks Avoid Detection

Here are some common ways attackers avoid detection while they are attacking your organization systems:

  • Log flooding
  • Using logging mechanism
  • Attacking detection mechanism
  • Using fragmentation attacks
  • Using canonicalization attacks
  • Using decoys

Here are some common ways attackers can use fragmentation against your system:

  • Session splicing attacks
  • Packets fragmentation attacks
  • Fragmentation time-out attacks

Adopted from the book Assessing Network Security by Ben Smith, David LeBlanc, Kevin Lam.