Denial of Service Attacks


The intent of a denial of service (DoS) attack is to force an application to stop responding either partially or completely. A DoS attack does not intend to destroy application data per se, but rather is aimed at making your application unavailable for use by others. DoS attacks are generally launched against networks and network-based applications. Visual Basic .NET, ASP.NET Web applications, and Web service applications that run on the Internet are most vulnerable to DoS attacks (when compared to other types of applications such as Windows Forms applications). DoS attacks come in many forms, as shown in Table 6-1. Your Visual Basic .NET code is most directly susceptible to the application crash, memory starvation, CPU starvation, and resource starvation forms of attack.

Table 6-1: Forms of DoS Attacks

Form of Attack

Examples

Application crash

Passing unexpected data to an application with the intent of crashing it.

Memory starvation

Passing large amounts of data to an application to use up the memory on the computer where the application is running.

CPU starvation

Passing in data to an application that causes the application to enter an infinite loop or causes the application to perform a CPU-intensive task for an inordinate period of time.

Resource starvation

Attempting to exhaust a limited resource such as disk space. One way this is done is by passing large amounts of data that an application then saves to disk and forcing a low-disk-space or out-of-disk-space condition.

Network bandwidth starvation

Enlisting the help of many machines to make simultaneous, repetitive requests of an application or system with the intent to overwhelm the application server with network requests.

System crash

Passing unexpected data to an application or directly to a system (or system application) via an exposed system entry point, such as a network port, with the intent of crashing the system.

Note

See Chapter 11 of Writing Secure Code, by Michael Howard and David LeBlanc (Microsoft Press, ISBN 0-7356-1588-8), for a general discussion of system-level DoS attacks.

Defensive Techniques for DoS Attacks

DoS attacks are the most difficult type of attack to defend against. It’s often difficult to identify where your application is vulnerable because it’s not easy to reproduce the conditions needed for a DoS attack to occur. For example, if you have a limited number of computers, it’s not easy to reproduce a DoS attack involving thousands or millions of computers accessing your ASP.NET Web application simultaneously in order to see how the application handles the situation.

In many cases, such as the case of several million computers accessing your Web application simultaneously, you cannot avoid the attack, but rather you strive to mitigate the negative effects. For example, if your Web application is able to detect that more requests are being made than it can reasonably handle, the application might be able to respond with a different HTML page— smaller in size than the page it would normally show—notifying users that the Web site is experiencing heavy volume and telling them to try back later. This is more favorable than having the application (or the Web site exposed by the application) appear to be locked up to the user because the Web page does not display in a reasonable amount of time. Although if your application does not respond well to unusually high customer demand unrelated to an attack, you should work toward making your application more scalable to handle the peak load.

Table 6-2 lists ways you can address each type of DoS attack.

Table 6-2: DoS Defensive Techniques

Form of Attack

Defensive Technique

Application crash

Write solid code that does not lead to crashes. How’s that for a broad statement? Specifically, you need to validate all input, as presented in Chapter 7; use Try … Catch handlers as appropriate to catch and handle any exceptions, as presented in Chapter 8; test your code and attack it, as presented in Chapter 9; and perform a security audit of your application code and the application design, as presented in Chapter 14 and Chapter 15.

Memory starvation

Limit the size of input and disallow repetitive input, as shown later in this chapter. Consider writing data stored in memory to a file or database to conserve memory. Judiciously release objects, such as arrays, that consume memory—for example, set the referencing object variable to Nothing when the data is no longer needed.

CPU starvation

Identify and fix any cases in your code where a loop or recursive call to a function could lead to an infinite loop based on unexpected input.

Resource starvation

Judiciously free file handles, database connections, and references to objects that your application no longer needs. Review your code to ensure that unchecked input doesn’t cause your application to allocate an unnecessary resource or a resource of unreasonable size.

Defending Against Memory and Resource DoS Attacks

As a simple example of Visual Basic .NET code that is susceptible to the memory-starvation form of a DoS attack, suppose you have a class library application with a Public class named Products containing a Public method named AddProduct, as follows:

Public Class Products
’Add Imports System.Collections.Specialized to the top of the
’code module
Private m_ProductNames As New StringCollection()
Public Sub AddProduct(ByVal ProductName As String)
m_ProductNames.Add(ProductName)
End Sub
End Class

Suppose an attacker created a client application that calls your AddProduct function repeatedly, passing extraordinarily large strings such as:

‘Force memory starvation attack
Dim ObscenelyLargeString As String
Dim products As New Products()

‘Loop to infinity
Do While True
‘Allocate a string of 1 million characters
ObscenelyLargeString = New String("X", 1000000)
products.AddProduct(ObscenelyLargeString)
Loop

Warning

The preceding code sample is for illustration purposes. DO NOT ATTEMPT TO RUN THE PRECEDING EXAMPLE ON YOUR COMPUTER. If you create and run this application yourself, your machine will become unresponsive and you might need to power reset your computer to recover. For an example that won’t lock up your computer, open and run AttackerClient.sln, which is located in the CH06_AvoidingAttacks\DoSAttack\AttackerClient sample applications directory. This application allows you to allocate a large block of memory and see the memory consumed. You can repeatedly allocate blocks of memory at your own discretion until you see a slow down in your system performance without locking up your system. The memory is released back to the system as soon as the application is terminated.

Because the AddProduct method provides no input validation, not even a check to see whether the ProductName is unique, the attacker will eventually force the server application to consume all available memory on the server. Even before all memory is consumed, however, the server will become quite sluggish and unable to respond to any new requests.

As another example, what if the AddProduct class library function appended the string to a file as shown here:

Public Sub AddProduct(ByVal ProductName As String)
Dim hFile As Integer = FreeFile()
’TODO: Add Imports Microsoft.VisualBasic.Compatibility to the
’top of the code module.
FileOpen(hFile, VB6.GetPath & "\ProductNames.Txt", _
OpenMode.Append)
PrintLine(hFile, ProductName)
FileClose(hFile)
End Sub

The attacker’s code would lead to a resource or disk-space starvation attack in which the end result is the same as the memory-starvation attack—the server would become unresponsive.

Your best defense against memory and disk-space starvation attacks is to limit the size of input allowed. In the previous example, the ProductName input parameter should be checked for size. In addition, the AddProduct subroutine should prevent duplicate names from being entered. For example, the ProductName parameter should be limited to a reasonable size, such as 20 characters. To prevent against duplicate strings, before adding the string to the collection, you should use the Contains method to confirm the collection does not already contain the string you are about to add.

The following code demonstrates how input validation—checking the input string for reasonable size—and disallowing duplicate names can help prevent a DoS attack, or at least make the attacker work harder and smarter to launch such an attack.

‘Add Imports System.Collections.Specialized to the top of the code module
Private m_ProductNames As New StringCollection()
Public Sub AddProduct(ByVal ProductName As String)
Const MAXLENGTH_PRODUCTNAME = 20
If ProductName.Length <= MAXLENGTH_PRODUCTNAME AndAlso _
Not m_ProductNames.Contains(ProductName) Then
m_ProductNames.Add(ProductName)
Else
Throw New ArgumentException("Invalid product name")
End If
End Sub

Note

To prevent an attacker from calling a Public method on a server class, you should also use a defense-in-depth strategy, such as using role-based security techniques to verify that the calling user has been authenticated and granted the necessary role-based permissions needed to call the function (as discussed in Chapter 2).




Security for Microsoft Visual Basic  .NET
Security for Microsoft Visual Basic .NET
ISBN: 735619190
EAN: N/A
Year: 2003
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net