Common Entry Points

Following is a list of some of the most common entry points that attackers probe for security vulnerabilities in applications, but it is by no means all inclusive. These common entry points are discussed in more detail throughout the rest of this chapter.

• Files

• Sockets

• Hypertext Transfer Protocol (HTTP) requests

• Named pipes

• Pluggable protocol handlers

• Malicious server responses

• Programmatic interfaces

• Structured query language (SQL; databases in general)

• Registry

• User interfaces

• E-mail

• Command-line arguments

• Environment variables

An application might also accept inputs from hardware devices such as a COM port, microphone, or infrared port. Although these types of input are too numerous to discuss in this book, to find and protect these entry points remember the following important points:

• You must identify entry points into your application and what they do.

• You must understand why each entry point is important to an attacker.

• You must determine the level of access needed for each entry point.

• You must test your entry points by thinking maliciously about them.

Files

Files are obvious entry points into your application. They contain data specified by a user, or they contain data supplied by the application. This data can be intentionally corrupted by a malicious user in an attempt to cause unexpected behaviors in the application. However, what might not be obvious is that the file content is not the only thing you have to be concerned about. An application can use other data associated with the file.

File data that might be used as an entry point  

Take a look at the parts of an example input file called ILoveHacking.jpg. Each of the following parts can be used as an entry point:

• Filename with extension (ILoveHacking.jpg)

• Filename without extension (ILoveHacking)

• Filename extension (.jpg)

• Path (c:\My Pictures\ILoveHacking.jpg)

• File s system attributes (Read-Only)

• File s metadata (Title: I Love Hacking)

• File s content

Some people think that as long as they open files only from trusted sources they will be safe. For instance, some people believe that e-mail attachments are safe as long as you don t open any that are executables. According to that logic, e-mail messages that have photo attachments should be fine to open , right? However, if the image file was manipulated by an attacker, the image file might be able to crash the application that opens it, thus potentially compromising the computer system. In 2004, a security vulnerability that would lead to such an attack was reported against the Microsoft Windows operating system in the LoadImage API ( http://www.securityfocus.com/bid/12095 ). Microsoft had to address this vulnerability in security updates.

Importance to an Attacker

From an attacker s perspective, any time users are able to supply data to the application, there is a good opportunity to exploit a security vulnerability. In particular, files are of interest to an attacker if any of the following conditions are true:

• The file contains sensitive data.

• The attacker is able to specify input for filenames.

• The attacker is able to provide data for the file s content.

• The attacker is easily able to force the application to use the attacker s malicious file.

We discuss in later chapters several types of security vulnerabilities that target files specifically , such as Chapter 7, Information Disclosure, Chapter 12, Canonicalization Issues, and Chapter 14, Denial of Service Attacks.

Registered File Types

Have you ever opened a file that launches an application and loads that file? These are known as registered file types . Because they can open the application that loads the file, there is a potential security problem. What if the file is maliciously corrupted? You might wonder who would ever open a file from an untrusted source. Maybe no one, but some files can be opened automatically from the Windows shell simply by browsing to that file. For example, an attacker can send you a link to a file on a Web site. When you click the link, the file is downloaded and then loaded automatically by the appropriate application if the Confirm Open After Download flag is not set. You might think the solution is to ensure that all files have the Confirm Open After Download flag enabled in the operating system. Even if that flag is set, an attacker might still be able to use a poorly written application, such as an ActiveX control, to cause the malicious file to load. Also, only a little bit of social engineering is needed to get a user to click Yes to load the file. For instance, if the file is named Resume.doc and is sent to a company s recruiter, do you think the recruiter would hesitate to open it? Probably not! Chapter 6, Spoofing, discusses social engineering in more depth and how that technique is useful for an attacker to use to trick a victim into performing a malicious action.

More Info  

For more information about the File Download dialog box and the Confirm Open After Download flag, see the Microsoft Knowledge Base article 905703, The File Download Dialog Box Appears If You Download a File ( http://support.microsoft.com/kb/905703/ ).

Unregistered File Types

Unregistered file types are files that do not open until the user specifies which application to use to open the file. These files do not have an application registered for them, so exploiting the previously discussed vulnerability is more difficult. However, this is not an excuse to ignore these file types.

How to Find This Entry Point

To determine whether files are an entry point into your application, you must also consider the following information:

• Files being accessed by the application

• File permissions

• Filename extension information

Files Being Accessed by the Application     Several tools created by SysInternals ( http://www.sysinternals.com ) are extremely useful for finding security vulnerabilities. In particular, FileMon monitors the file system in real time and indicates which processes are accessing files and folders. You can use this tool to determine which files your application uses, such as temporary files, log files, and so forth. Figure 3-1 shows FileMon in action.

Figure 3-1: Using SysInternal s FileMon to monitor which files and folders are accessed by an application

File Permissions     To view file permissions, right-click the file in Windows Explorer and select Properties. If your system uses the NTFS file system, the Security tab shows you the permissions set on that file or folder. Figure 3-2 shows an example of the Security tab for a file.

Figure 3-2: Security properties for a file

If you are using FileMon, right-click the target file, and click Path Properties to open the Properties dialog box. View the file permissions in the Security tab.

Note  

If you do not see the Security tab, you might be using simple file sharing mode, which hides the Security tab. To change this, click Start, click Control Panel, and then open Folder Options. In the View tab, under Advanced Settings, clear the Use Simple File Sharing check box.

Chapter 13 provides more information on how to discover problems with weak permissions, but essentially you want to look for files that provide too much access to files and folders, which gives an advantage to an attacker.

Filename Extension Information     You can use FileExtInfo.exe, which you can find on this book s companion Web site, to scan your entire system to determine which filename extensions have applications associated with them. You can also use this tool to determine whether the Confirm Open After Download flag is set. Figure 3-3 shows an example of the output generated by using the tool.

Figure 3-3: Output from running FileExtInfo.exe

Sockets

Sockets are used for bidirectional communication between applications using various network protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP) and User Datagram Protocol (UDP). A socket address consists of an IP address and a port number. The port number is a value between 0 and 65535 and identifies which door an application uses to transmit data to and from a particular IP address.

Importance to an Attacker

An application that uses open sockets to communicate is a lot like having an open door to your house with all sorts of people coming and going through. This scenario can be extremely dangerous if the entry point, the open socket, is not well protected. Sockets are easy to connect to, and the data going over the network is not always safe.

When an application uses data sent over a network, an attacker can try the following techniques to attack the application:

• Monitor the data.

• Send malformed data from the client.

• Send malformed data from the server.

• Intercept the data in the middle of the request that is sent to the server or sent back to the client.

The last technique is really a combination of the second and third techniques, called a man-in-the-middle attack. The attacker is able to manipulate the data as it is passing through the network so that access to the client or server is not needed. By using the same man-in-the-middle technique an attacker uses, you can determine which data is sent over the network and becomes an entry point into your application.

Note  

Peer-to-peer applications are also susceptible to networking attacks, even though there is not a designated client or server. Instead, each peer acts as its own client and server.

How to Find This Entry Point

If your application uses sockets, the threat modeling process should have identified these entry points. However, you must verify this information is correct to make sure an entry point that an attacker might find is not missed. To determine the entry points for sockets, do the following:

• Enumerate the open sockets.

• Monitor the network traffic.

Enumerating the Open Sockets     Although you can manually look through the code to determine whether your application uses sockets, it is usually too time-consuming because the many different languages have different socket libraries, not to mention that people write custom wrappers on top of them. Luckily, the command-line utility Netstat.exe that ships with the Windows operating system can help you determine the open connections.

By running Netstat.exe, you can see all of the connections currently open on the machine. In Microsoft Windows XP Service Pack 2, the ˆ’ b argument, which shows all the processes responsible for creating the socket, was added to Netstat.exe. Figure 3-4 shows the output ofthis tool.

Figure 3-4: Output from running Netstat.exe to show the current network connections on a machine

The downside of using Netstat.exe is that it indicates only the connections that are currently open, so you might miss some if they are not open at the time you run the check. To solve this problem, you can use tools to monitor the network traffic while using your application.

Monitoring the Network Traffic     If your application sends or receives data off the network, you need to determine what the data contains. For instance, an attacker might look for sensitive data, such as user credentials, or attempt to alter the data to cause your application to behave incorrectly. A network sniffer, such as Ethereal ( http://www.ethereal.com ), can monitor the network traffic and analyze different protocols. Figure 3-5 shows the Ethereal sniffer being used to monitor HTTP traffic sent to a server.

Figure 3-5: Monitoring HTTP traffic

HTTP Requests

One of the most widely used network protocols is HTTP. Documented in RFC 2616 for version 1.1, HTTP operates over TCP, generally using port 80, and enables data to be transferred between a client and server. If you use a Web browser, such as Microsoft Internet Explorer or Mozilla FireFox, you are actually using a client of HTTP. HTTP is a popular protocol for applications to use because of its simplicity and because it works through almost every firewall. The following is an example of a generic HTTP request:

 GET /someurl.aspx HTTP/1.1 Host: www.contoso.com 

More Info  

For more information about RFC 2616, see http://www.w3.org/Protocols/rfc2616/rfc2616.html .

The client sends this request to the server. If the server processes the request, the request is an entry point into the system. Unless you are testing a server application that is handling the HTTP request as a whole, such as a Web server, it might not be very interesting for you to spend time testing here. Generally, to determine whether an HTTP request is a vulnerable entry point, you can break down the request into smaller subparts, as shown in Figure 3-6, to decide what needs to be tested . Essentially, you need to trace the data through the system to figure out the entry points for your application.

Figure 3-6: Breaking an HTTP request into subparts to identify testing needs

In the example in Figure 3-6, the request is for an ASPX page, which is normally handled by Microsoft Internet Information Services (IIS) and sent to the Microsoft ASP.NET handler for processing. However, your application might handle the request in a specific manner, so you need to ask the following questions:

• Is there an Internet Server API (ISAPI) filter or something that can process the request prior to getting to the ASPX page handler?

• Does the application read cookie data?

• Does it use any of the other headers such as User-Agent or Referer?

• Does it parse the Uniform Resource Identifier (URI) or query string?

• Does it use the body of the request?

• What happens with the data? Is it stored in the database? Is it written out into ViewState, UserData, cookies, or other HTML elements on the page?

• Is any part of the data returned anywhere in the response?

These questions can help you identify the entry points to your system that might use HTTP. Entire books have been written about HTTP, and a plethora of security vulnerabilities are related to this technology. Chapter 10, HTML Scripting Attacks, and Chapter 11, XML Issues, discuss more of these vulnerabilities.

Importance to an Attacker

For applications and attackers alike, one of the most attractive features of HTTP is that it is almost always allowed to pass through firewalls. An attacker can easily send an HTTP request to an application that accepts such requests. Recall how open sockets are like doors that visitors can come in through. HTTP works the same way. This is useful when attacking your application to find flaws because you can manipulate requests freely in the hope of breaking in. However, malicious users also find it useful.

In addition, if the data sent using HTTP is not protected, an attacker can manipulate the data and might also be able to obtain sensitive data. For instance, when a user fills out an order form on a Web site, if the site does not use Secure Sockets Layer (SSL) or another security mechanism, any personal information will be sent in clear text over the network. Anyone in the middle that is monitoring the data can easily intercept it and use it for malicious purposes.

Note  

Alternatives to SSL can be used to secure data as it is sent by HTTP, such as Web Service Security (WS-Security) or various encryption implementations .

How to Find This Entry Point

The easiest way to determine whether your application uses HTTP for communication is to monitor the traffic over the HTTP port, typically port 80. You can use Ethereal to accomplish this, but there is a better tool for the job.

Web Proxy Editor, a tool you can find on this book s companion Web site, acts as a proxy by sitting between the application and the HTTP server. It is able to monitor the HTTP traffic that is sent to and from the application. Web Proxy Editor can monitor the traffic and intercept it to enable the data to be manipulated in real time. By seeing what data is being sent, you can bypass any client-side validation to try to break your application. Figure 3-7 shows Web Proxy Editor trapping an HTTP request sent to the server.

Figure 3-7: Using Web Proxy Editor to trap HTTP traffic

Named Pipes

Two types of pipes allow a section of memory to be shared for communication between processes:

• Anonymous pipes

• Named pipes

As its name implies, the anonymous pipe is unnamed. An anonymous pipe is always local and is a one-way pipe that allows one end to write data and the other end to read it. A named pipe, on the other hand, can allow one-way or duplex communication between a pipe server and one or many clients . One of the most common ways for a process to communicate with another process either locally or remotely is to use named pipes.

An application can either create a named pipe and act as the server for others to connect to it, or the application can connect to a named pipe as a client. Once a named pipe is created, a connection can easily be established to the server using file input/output (I/O) APIs to read or write data to the file handle.

Often, certain programmatic interfaces use named pipes as their communication transport and the programmer might not realize what is going on behind the scenes. After a named pipe is created, it can be accessed using the convention \\.\pipe\ pipename . The double backslash dot backslash prefix (\\.\) indicates that the connection is to the local machine, but can be replaced with a remote server name. For instance, \\contoso\pipe\MyEvilPipe is a named pipe called MyEvilPipe that is located on the machine called contoso. If a named pipe is created on a machine, an attacker will be able to access the pipe from a remote machine.

Importance to an Attacker

To an attacker, named pipes offer security vulnerabilities that they can exploit to own a user s machine. Because named pipes allow a client to connect to them over the network, the attacker has an entry point into the system that can be exploited without requiring any physical access to the client machine. If an application creates a named pipe, attackers can use the named pipe in the following ways:

• Exploit weak permissions on the named pipe

• Hijack the creation of a named pipe

• Impersonate the client

With access to the pipe server, malicious users can hijack the creation of a named pipe and then elevate their privileges to run their code as another user or, even worse , as the System account. Even if an application does not explicitly use named pipes, it could still allow connections to named pipes using common file operations. If this threat is not taken into consideration, attackers might be able to get an application to connect to their malicious named pipe and then can impersonate the client s account. By impersonating an account, attackers are able to elevate their privileges to the victim s account, which can result in serious security vulnerabilities as the example in the following sidebar describes.

Example vulnerability in SQL Server 2000  

A named pipe flaw in Microsoft SQL Server 2000 led to local privilege elevation, which allowed the attack to impersonate the user account running SQL Server. Andreas Junestam of @Stake found that the SQL Server xp_fileexist stored procedure allowed a user to specify a named pipe. In his example, he ran a program that created a named pipe, listened for a client to connect, and then impersonated the client, which was the SQL Server service. The malicious application that created the named pipe could then execute a program as the impersonated user, which was System.

More Info  

In April 2002, Blake Watts released a great paper on the security of named pipes. You can find his paper at http://www.blakewatts.com/namedpipepaper.html .

How to Find This Entry Point

To determine whether your application creates a named pipe, you can search the source for the CreateNamedPipe function . If you do not have access to the source, you can also use a tool from SysInternals called Pipelist.exe that enumerates all of the named pipes created on your machine. Figure 3-8 is an example of the output of Pipelist.

Figure 3-8: Output from Pipelist.exe showing all of the pipes created on a particular machine

Checking the Permissions

To create a named pipe server, developers use the CreateNamedPipe function. The method s declaration looks like this:

 HANDLE CreateNamedPipe(   LPCTSTR lpName,   DWORD dwOpenMode,   DWORD dwPipeMode,   DWORD nMaxInstances,   DWORD nOutBufferSize,   DWORD nInBufferSize,   DWORD nDefaultTimeOut,   LPSECURITY_ATTRIBUTES lpSecurityAttributes ); 

Named pipes support most of the same access rights as files. If CreateNamedPipe is called passing null for the lpSecurityAttributes attribute, the default security descriptor is used. If this happens, the named pipe allows the creator, Local System, and administrators full access to the pipe, and members of the Everyone groups and the anonymous account are granted Read access.

Can you see a problem with this? What happens if the named pipe s security attributes are null, and the server writes data to any client that connects to it? Incorrect security attributes might lead to several types of vulnerabilities. For example, what happens if the server writes data to the client without making sure the user has the correct permissions? Or maybe you could send malicious data to the server that will cause it to break.

More Info  

For more information about permissions, refer to Chapter 13.

Hijacking a Named Pipe

Now that you understand how named pipes can be created, can you think of any security situation where a named pipe with the same name already exists on the system? If a service creates a named pipe that has a predictable name, an attacker might be able to devise a malicious application that creates a named pipe using the predictable name before the real named pipe uses that name. If that happens, when an application tries to create the named pipe, it can get hijacked by the malicious named pipe that uses the same name. Now the malicious user can have all kinds of fun, such as impersonating the client. To avoid this problem, the developer should create the named pipe using the FILE_FLAG_FIRST_PIPE_INSTANCE flag for the dwOpenMode attribute.

Note  

The FILE_FLAG_FIRST_PIPE_INSTANCE flag is available only in Microsoft Windows 2000 Server Service Pack 1 and later.

You can use FileMon from SysInternals to see the named pipes that are created and to see whether they were created using the FILE_FLAG_FIRST_PIPE_INSTANCE flag. To do this, set a filter on the volume to monitor only for named pipes. If you see a request for IRP_MJ_ CREATE_NAMED_PIPE, you can see when a named pipe is created. If the Other column contains Create, the named pipe was created using the FILE_FLAG_FIRST_PIPE_INSTANCE flag. Otherwise , you will see the value OpenIf.

Note  

If the FILE_FLAG_FIRST_PIPE_INSTANCE flag has not been used, hijacking can also be mitigated by using a random name when creating the pipe.

Impersonating the Client

Once a named pipe is created and a client has connected to it, the server can impersonate the user. This might seem pretty typical for server applications because they want to perform a function on behalf of the user. However, impersonation can cause security vulnerabilities for the client, which we discuss in the next section. Here we are attempting to spot potential problems with the impersonate code that might lead to security vulnerabilities on the server. The impersonate API for named pipes is the following:

 BOOL ImpersonateNamedPipeClient(   HANDLE hNamedPipe ); 

As in most cases, you should always check return codes, but what happens if the developer missed doing this check? If the server is running as a highly privileged user, such as the LocalSystem account, it continues to run as that user after the ImpersonateNamedPipeClient() call fails. Thus, operations might succeed for a user who really doesn t have the correct permissions.

Client Security

After you have verified whether your application safely creates named pipes, do you think you are still secure from named pipe vulnerabilities? Think back to the SQL Server vulnerability described earlier. The xp_fileexist stored procedure was not creating a named pipe, it simply connected to a named pipe. You might think your application does not use named pipes, but if it uses the file API to open or create a file, you might be able to specify a named pipe. In the SQL Server security vulnerability, the problem was the service became a client of the malicious named pipe server because it allowed the attacker to specify the filename when calling the CreateFile function. This vulnerability allows an attacker to specify a malicious named pipe server when specifying the filename for xp_fileexist .

If your application is running with elevated privileges and accepts filenames, you should check to see whether it allows you to specify a named pipe as well. You can use the tool CreatePipe, which can be found on the companion Web site, to determine whether your application connects to a named pipe. The tool creates a named pipe called CreatePipe and indicates when a client successfully connects to the named pipe.

Pluggable Protocol Handlers

You are probably familiar with Uniform Resource Locators (URLs) that start with http: or https : . These are called protocol handlers , and they tell the system which application is invoked to handle the data when the hyperlink is clicked. They are useful because they allow a Web site to launch an application and easily perform some function for the user. For instance, if you click the mailto: [e-mail]?subject=EntryPoints link, your default e-mail application would launch, start a new e-mail message addressed to [e-mail] using the Subject line EntryPoints. Several applications register protocol handlers to increase application functionality by allowing hyperlinks to interact with the program.

Importance to an Attacker

Although protocol handlers might enrich users experience using the Internet, they can also wreak havoc if the calling application contains any security vulnerabilities. For instance, mIRC (an Internet Relay Chat program) installs the irc protocol handler that allows arbitrary Web pages to launch the application, connect to a specified server, and then join a channel. Because protocol handlers allow data to be passed into the registered application, they also become entry points that must be tested for vulnerabilities. If you have mIRC installed, all you need to do is click a link that looks like irc://server/channelName . With this protocol handler, the interesting entry points are the values for operations and the values for the parameters.

One example of a security vulnerability that was found in the irc protocol handler dealt with a maliciously crafted link that looked like irc://[~990 characters ]. This caused a buffer overflow in mIRC that allowed arbitrary code to execute. Luckily, the bug finder reported the vulnerability to the developer of mIRC and enabled him to release a patch; otherwise, the results could have been a lot worse.

Normally, it can be difficult to insert user-supplied data into a client application because the attacker must get the victim to run an application, open a particular file, and so forth. However, if an application installs a protocol handler, the attacker s job becomes much easier. To exploit such a security vulnerability, the attacker simply must get the victim to click a link or browse to a malicious Web site that redirects to the specially crafted URL. Sound scary? It is, and you might be surprised at how many applications use protocol handlers.

Important  

In some cases, user interaction is not needed to exploit a vulnerability in a protocol handler. Sometimes an application will automatically load data from various sources without prompting the user. For instance, an e-mail program might load images automatically using HTTP links.

How to Find This Entry Point

Normally (we hope), during the design review or by examining the threat model or data flow diagram of your application you will determine whether your application installs a protocol handler and how the handler was intended to be used. However, a tool called Viewplgs.exe, available on this book s companion Web site, enumerates all of the protocol handlers on the machine and the applications that handle them. Figure 3-9 shows the output from Viewplgs.exe. As you can see, several protocol handlers are installed on this particular machine.

Figure 3-9: Using Viewplgs.exe to discover the installed protocol handlers and the applications that handle them

Malicious Server Responses

Earlier in this chapter, we discussed HTTP requests and entry points that a server application might have. If you have a client application that accepts responses from a server, what happens if the server is malicious? Generally, users have a false sense of security that the server they are connecting to will behave properly, but that might not always be the case.

Just as the client can control the data that is sent to the server, the server can control the data sent back to the client. If the data is malformed and the client does not handle it gracefully, there might be a vulnerability waiting to be exploited. Chapter 16, SQL Injection, discusses in more depth testing clients by using malicious servers.

Importance to an Attacker

If attackers can get a user to connect to a malicious server, they might also be able to get the connecting application to behave differently as a result of unexpected data in the server s response. You might wonder why anyone would connect to a malicious server in the first place. Consider that when you browse the Internet, you connect to several servers, any one of which might be malicious. Let s look at another example.

Half-Life is a game by Valve Software that had a buffer overflow in the client connection routine. By connecting to a fake game server, the buffer overflow would execute an attacker s arbitrary code. Because playing network games can be a lot of fun, security is probably the last thing users think about before connecting to a server to join a game.

How to Find This Entry Point

You can use the same tools to monitor server responses as you use to monitor open sockets and HTTP requests from the client. Web Proxy Editor can trap all HTTP responses and allows you to manipulate the data to see how your client will behave. Ethereal can be used to monitor traffic on all ports, although it won t allow you to manipulate the data.

Programmatic Interfaces

Programmatic interfaces allow communication between applications. Several types of technologies can allow programmatic access to your application. For example, the following list contains some of the common programmatic interfaces:

• Remote procedure calls (RPCs)

• Component Object Model (COM)

• Distributed COM (DCOM)

• ActiveX controls

• Managed code entry points

• .NET Remoting

Some programmatic interfaces use sockets to transport communication; generally, the data is packed in a specific structure that, if tampered with, invalidates the request. For instance, if you try to manipulate an RPC packet, the RPC layer might reject the request before it reaches the application.

Chapter 15, Managed Code Issues, covers attacks for managed code in more detail, and you can refer to Chapter 18, ActiveX Repurposing Attacks, for more information about COM, DCOM, and ActiveX controls.

Importance to an Attacker

Most programmatic interfaces were intended to be used by the application or in a certain environment, such as a Web site using an ActiveX control. Programmatic interfaces usually provide a lot of functionality that an attacker can exploit.

How to Find This Entry Point

You can use several tools to help determine the programmatic interfaces used on a computer. For more detailed information about each of the following tools, refer to Appendix A.

• RpcDump     Use this tool to display all of the RPC endpoints that are located on a computer. You can find RpcDump at http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/rpcdump-o.asp .

• OleView     Use this tool to view all of the COM objects and their interfaces registered on a computer. You can find OleView at http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/oleview-o.asp .

• Dcomcnfg.exe     Use this tool to determine a DCOM application. Then navigate to Components Services/Computers/My Computer/DCOM Config to display all of the DCOM objects on the computer.

• AXDetail     Use this tool, available on this book s companion Web site, to get the ActiveX controls interface, safety levels, and safe mode support. After you locate a COM object of interest, you need to determine whether it is marked safe for scripting or initialization with untrusted data. If it is, the installed ActiveX object can be instantiated and programmatically manipulated further using commands on a Web page. Thus, an attacker can take advantage of any ActiveX security flaws by getting users to browse to a particular Web site.

• Gacutil.exe     Use the Global Assembly Cache Utility (Gacutil.exe) to list the managed assemblies that are registered on a computer. This tool is provided in the Microsoft .NET Framework and is located in %windir%\Microsoft.NET\Framework\<VERSION>. By running this tool using the /l argument, you can enumerate all of the assemblies installed in the system global assembly cache (GAC). Other tools for managed code are presented in Chapter 15.

SQL

If your application interacts with a database, more than likely it uses structured query language. These types of applications can be complex systems, such as employee management software, or as simple as a Web site guest book. SQL is used to query the database to retrieve or store data. The language uses human-like expressions to define statements that are executed against the SQL Server. SQL and its vulnerabilities are covered in Chapter 16.

Importance to an Attacker

Data in a database is a lot like files on your hard drive: you want to keep the data secure from people that shouldn t have access to it. If attackers compromise the SQL Server, they can access the data and potentially use powerful SQL queries to do much more harm. For instance, SQL defines several stored procedures that can be called to execute arbitrary commands on the computer system. If your application uses SQL, an attacker might be able to compromise your system by using the attacks discussed in Chapter 16.

Registry

The registry is essentially a hierarchical database in the Windows operating system that enables the operating system and installed applications to store settings that can be retrieved later. It is important to remember that your application can read from and write to the registry, which can make the registry a valid attack point.

More Info  

For a detailed description of the registry, refer to Knowledge Base article 256986, Description of the Microsoft Windows Registry ( http://support.microsoft.com/kb/256986/ ).

Importance to an Attacker

The registry key is an entry point into your application, and so, if compromised, the next time the application is run, the attacker s data could be used. A registry key can be placed under one of the following five predefined keys:

• HKEY_CURRENT_USER (HKCU)

• HKEY_USERS (HKU)

• HKEY_LOCAL_MACHINE (HKLM)

• HKEY_CLASSES_ROOT (HKCR)

• HKEY_CURRENT_CONFIG

Assuming a registry key has the correct permissions, only a legitimate user can read or modify a value in the key. First, we have to define what a legitimate user is. The current user should always have full permission for registry keys in the HKCU, but not for keys in HKU and HKLM. The keys in HKLM should be for the machine s settings, and keys in HKU contain the default values for all users on the machine. Applications generally use the registry to store data that will be used at run time to determine an application s settings. If the permissions on these keys are set incorrectly, numerous exploitable opportunities are available to an attacker, such as information disclosure, privilege escalation attacks, denial of service, buffer overruns, and more. It all depends on the application consuming the registry data. For example, say an application uses HKLM to store the values for the Most Recently Used files list. If this is writable by any user on the machine, a malicious user can set the value of this key.

Even the Read permission might be granting too much access depending on the data and who has access to it. By default, the HKLM grants Read permission to the Users group . How can this be a problem? If your application stores credentials, database connection strings, or other sensitive data in the registry, you can imagine how an attacker might use the Read permission to access the sensitive data in HKLM. Although it is not a best practice to store this data in the registry in the first place, if it is stored there, it should at least be encrypted. Amazingly, some applications store this data in clear text in HKLM and allow any user to read it. Also, if the Remote Registry service is running on the computer, an attacker doesn t need local access to the machine to potentially exploit a vulnerability in the registry.

Note  

Attackers can manipulate the registry in other ways without having local access to the machine. For instance, if they can trick a user into opening a .reg file or certain scripts, they canalso manipulate the registry. As for the Remote Registry service, you can restrict access to the registry from a remote computer by following the instructions described in Knowledge Base article 153183, How to Restrict Access to the Registry from a Remote Computer ( http://support.microsoft.com/kb/153183 ).

How to Find This Entry Point

To find the registry entry points for your application, you need to determine the following:

• Which registry keys are being accessed

• Permissions of the registry keys

Determining the Registry Keys Being Accessed     Determining which registry keys your application uses can be a tedious task, especially if you do not have access to the source code. RegMon, another tool by SysInternals, can be used to monitor registry access. By filtering for just your application s process, you can see the keys that are opened, read, or written. After generating a list of the registry keys your application uses, you can then determine whether the appropriate permissions are set. Figure 3-10 shows example output of RegMon.

Figure 3-10: RegMon monitoring registry access

Determining Permissions of Registry Keys     To determine the permissions set on a registry key, you can run Registry Editor (Regedit.exe). If you change registry values by using Registry Editor, you can cause serious problems, so use it carefully . To check permissions on a registry key, right-click the key, and then select Permissions to open the dialog box.

In Registry Editor, you might not be able to navigate to a child key because of permissions on the parent; however, this does not necessarily mean that the child is inaccessible. If you write code and specify the child registry key s path, you will be able to access it, despite the permissions on the parent. This user right is known as the Bypass Traverse Checking right, which is granted to all users by default.

User Interfaces

If you use the Windows operating system, you are already familiar with user interfaces. A user interface allows the user to input data; generally, an attacker needs to use social engineering to trick a user into entering malicious input. It is difficult programmatically to safeguard against social engineering attacks, but you can educate users to be aware of user interface vulnerabilities and to avoid being persuaded, effectively, to click a button called Hack Me.

Importance to an Attacker

As computer kiosks appear in more and more places ”from Internet terminals in airports to self-service photo centers in department stores ”user interfaces are becoming a prime target for attackers. The widespread use of cell phones and other portable devices is also a contributing factor because the number of people that are using the devices make it appealing to an attacker. Although it is still possible for attackers to exploit user interfaces, these entry points should be considered lower priority when you are testing an application.

Exploiting user interface vulnerabilities  

Many college libraries make computers available to patrons to assist with research and resource location. Several years ago, Microsoft Windows 95 was used on many such terminals, and third-party software could be used to prevent library patrons from accessing the system in a malicious manner ”or so it seemed. A bug in the Windows operating system allowed an attacker ”or a bored library patron ”to close the Start button. This vulnerability is now fixed, but you can imagine how frustrating, or amusing for an attacker, it was when students couldn t use the library s shared computers because the Start button had disappeared.

How to Find This Entry Point

A utility called Winspector ( http://www.windows-spy.com ) enables you to enumerate all of the processes, windows, and window messages on a machine. It is a lot like Spy++, which is a tool available with Microsoft Visual C++. Winspector includes some extra features that can help you identify which windows a process creates. By using Task Manager or Process Explorer, a tool from SysInternals, to determine which user started a process and Winspector to determine whether any windows were created by a highly privileged user, an attacker might be able to wreak some havoc, such as a shatter attack. We discuss shatter attacks in Chapter 19.

E-mail

Today, it seems like almost everyone has an e-mail address. E-mail has changed the way we communicate in our day-to-day lives. Instead of sending snail mail, which could take several days to reach its destination, transmitting a fax, or even making a simple telephone call, e-mail has quickly become the standard means of communication for many people and companies.

For e-mail to work, a client and a server must be involved. When a user sends an e-mail message, generally the message is sent to a Simple Mail Transfer Protocol (SMTP) server, and then is redirected to the destination server for delivery. At that point, a client can connect to its e-mail server, typically using another common e-mail protocol called Post Office Protocol (POP), and can retrieve any messages sent to it. This is the process in its simplest form and describes the components typically involved in e-mail.

Importance to an Attacker

Because so many people use e-mail, an attacker that finds an e-mail bug has a huge pool of potential victims to target. Also, e-mail can help hide the attacker s identity, making the malicious activity virtually anonymous.

Anyone can send e-mail to any e-mail address, as you are probably aware if your inbox receives several unsolicited messages each day. E-mail is also used as a transport vehicle for sending viruses. In earlier days, transferring malicious code generally entailed copying it onto a floppy disk and tricking a user into running it or tricking the user into downloading the malicious program. These days, e-mail gives an attacker an easy entry point into a user s system. If an e-mail application is poorly written, a maliciously crafted e-mail message could compromise the system.

More Info  

For example, Noam Rathaus of Beyond Security Ltd. found a buffer overflow in Microsoft Outlook Express in parsing the Secure/Multipurpose Internet Mail Extensions (S/MIME) data of a signed e-mail message. For more information about this attack, see Microsoft Security Bulletin MS02-058, Unchecked Buffer in Outlook Express S/MIME Parsing Could Enable System Compromise ( http://www.microsoft.com/technet/security/bulletin/MS02-058.mspx ).

A simple e-mail message defined in RFC 2821 consists of defining who the message is from, who the message is to, and the data in the message. Following is an example of an e-mail message:

 MAIL FROM: <[e-mail]> RCPT TO: <[e-mail]> DATA Date: 6 November 05 12:00:00 From: [e-mail] To: [e-mail] Cc: [e-mail] Subject: Example e-mail message Hi Victim1 & Victim2. If you are reading this, I have any entry point into your system.  I hope your system is well tested and secure. 

The MAIL FROM line indicates who, supposedly, is sending the mail. Even if an attacker changes this line to an invalid value, in most cases, depending on the mail server, the server simply trusts the value. This is demonstrated by spam, unsolicited e-mail, for which any e-mail address, whether valid or not, can be used in the MAIL FROM line. RCPT TO specifies the recipient, either the mail server that will process the request or the user that will receive the message, and so an attacker might not change this value. The body of the message is contained in the DATA section. In the preceding example, this section specifies Date, From, To, Cc, and Subject. Imagine all of the fun an attacker can have manipulating these headers. And these aren t the only values that can be provided in an e-mail message.

Although RFCs 2821 and 822 define several headers that can be supplied in an e-mail message, arbitrary headers can also be supplied. A client and server can use several other headers to extend functionality of e-mail. For instance, Microsoft Office Outlook uses custom headers when processing e-mail from a Microsoft Windows SharePoint Services server that enable the client to display special icons for those messages. Attackers can use this functionality to their own advantage. If some application processes data, there is a chance that a security flaw exists. In this case, if Outlook trusts that a SharePoint server always sends an e-mail message with valid headers, Outlook is making certain assumptions. But an attacker can easily manipulate the headers and so it might be possible for the attacker to cause a security bug by sending invalid headers the application does not expect.

How to Find This Entry Point

Without knowing the client code, there isn t an easy way to determine whether an application relies on e-mail, especially if it parses the data contained in the message. Deeper examination of the application using threat models, data flow diagrams, and tracing the source code canhelp.

Another clue that can indicate whether an application uses e-mail is if it uses technology such as Collaboration Data Objects (CDO), Messaging Application Program Interfaces (MAPI), orCommon Messaging Calls (CMC).

You can monitor the network to see traffic sent to defined mail ports, such as port 25 for SMTP; however, the application might use e-mail messages without being an SMTP server itself. For instance, e-mail servers generally store incoming e-mail addresses in a specific folder. The application might use the files stored in this directory to process the incoming e-mail. If this is so, you can use FileMon as described previously to reveal this case.

Command-Line Arguments

Many programs use command-line arguments to provide data to perform certain functions in the application. Generally, command-line arguments are not of too much interest to attackers because the attackers would have to somehow trick a user into typing in the malicious command-like argument. Although that isn t impossible , a user willing to type in code could probably be coerced into doing something much more dangerous.

Importance to an Attacker

If attackers are able to inject command-line arguments, they might be able to alter the behavior of the application to suit their malicious intent. For example, if an application uses a command-line argument to specify the file to be opened, it might seem harmless. However, what if the application also includes another command-line argument to delete the file? If attackers can cause a command-line argument to be injected when the victim starts the application, they might be able to get the application to delete the file.

An attacker might also be able to specify command-line arguments using other means such as protocol handlers or ActiveX controls. Recall that data in a protocol handler is supplied as a URL that a user might access. If so, it would be easy for an attacker to exploit a vulnerability in a command-line argument if a protocol handler calls that executable using the data specified in the URL.

How to Find This Entry Point

Sometimes an application will reveal information about its own usage when you specify certain command-line arguments, such as /?, -?, /h, or -h. However, an application can accept several arguments that are never documented or displayed in the usage information. Although it would be great to know all of the arguments an application accepts, you might have to resort to other measures.

You can use Process Explorer from SysInternals to determine what the command-line arguments are when an application is launched. After the target application is started, run Process Explorer, double-click the process, and click the Image tab. An attacker might use the Image tab to reveal undocumented command-line switches that can change the behavior of the application. Figure 3-11 shows the command-line arguments specified when a document is edited in Microsoft Office Word 2003 from a Windows SharePoint Services document library. As you can see, Winword.exe was launched using /n, /dde, and the URL of the document.

Figure 3-11: Using Process Explorer to view the command-line arguments used to launch an application

Environment Variables

Environment variables are used by applications and the system to store information about the currently logged on user and about the system environment. Some applications use the data stored in environment variables to determine specific information, such as paths. Some system variables can be set only by an administrator. These variables are usually defined by the system and are made available to all the computer users. If a user and system variable have thesame name, the user variable takes precedence.

Importance to an Attacker

If a program relies on an environment variable to make decisions, such as when constructing a path to a file, the data in the environment variable might not be safe. Although attackers cannot manipulate system environment variables unless they have compromised an administrator s account, they can change other environment variables.

For example, some applications expand the %temp% environment variable and use that location to store their temporary application data. In this case, the developer assumed that the value of %temp% would always refer to the user s temporary directory, but this might not always be true. As such, the data isn t safe, and attackers could use this to their advantage.

How to Find This Entry Point

To find both user and system environment variables, simply right-click My Computer, select Properties, click the Advanced tab, and then click the Environment Variables button. Figure 3-12 shows an example of this dialog box.

Figure 3-12: Displaying the Environment Variables dialog box

An application can also use its own environment variables, which are used only at the application s run time, so you won t be able to view them using the preceding method. Instead, use Process Explorer to determine these values. Start the application, double-click the process you wish to investigate, and then select the Environment tab. Figure 3-13 shows the environment variables used by Word 2003. As you can see, a couple of variables are defined that weren t shown in Figure 3-12.

Figure 3-13: Using Process Explorer to view the environment variables for a process