Threats against .NET Services and Servers

Like any Web Services application, a .NET application can be written insecurely. The majority of attacks against a .NET site are probably invalid input attacks. These attacks manipulate data to something that the server does not expect.

Input Validation

Input validation attacks take advantage of weak parsing functions and programmers who place too much trust in the client application. One of the most efficient, yet insecure, methods of input validation is to use client-side JavaScript in the Web browser. The JavaScript routines might be smart enough to strip out invalid characters, but it is trivial to bypass such methods. Input validation attacks can lead to user impersonation, privilege escalation, and arbitrary file access.

SQL Injection

SQL injection is a specific subset of input validation that can enable malicious users to extract arbitrary data from a database. A good method of mitigating such attacks is to rely on stored procedures. For example, if your application relies on the SqlCommandMethod to execute SQL statements, you should use the CommandType.StoreProcedure as opposed to the CommandType.Text method. A stored procedure receives a parameter list and generates an error if the list varies from the predetermined number of parameters or parameter types. On the other hand, it is easier to insert malicious characters into a SQL query constructed from a string.

Consider this function, written in C# pseudocode:

 [ SqlCommandMethod(CommandType.Text, "SELECT * FROM Users

  WHERE Password = @Passwd AND ExpireDate > GetDate()") ]

public static DataSet GetAnnouncements(SqlConnection connection, int moduleId)

{

...functions

}

If the Web application does not perform proper input validation for the @Passwd variables, a malicious user could attempt a SQL injection attack. For example, @Passwd might be manipulated to contain SQL formatting such as “a OR 1=1’--.” The final SQL query would end up as “SELECT * FROM Users WHERE Password = a OR 1=1.” Thus, the SQL query is reduced to selecting all data (SELECT *) from the table containing user information. Depending on the error handling within the application, a few actions might occur. The application will return an error because it received more fields than it expected. This field information (such as passwords) could be returned in the error string. On the other hand, the application may simply take the first series returned. In that case, the user would log in with the credentials of the first user defined in the Users table.

Threats against .NET Servers

System administrators can easily lose sleep when their .NET applications run on Microsoft’s IIS Web server. A vulnerable Web server is often the point of entry into any Web-based application. A buffer overflow or an incorrect parsing algorithm could provide a malicious user access to encryption keys, user data, and application source code. IIS has had a history of such vulnerabilities. For example, Microsoft has issued the following security advisories for IIS:

·          IIS Directory Traversal and Superfluous Decode (MS00-086, MS01-026) These enabled malicious users to access arbitrary files and run arbitrary commands on the Web server. Placing the Web document root on a drive volume separate from the SYSTEMROOT greatly reduces the impact of this attack.

·          IIS ISAPI DLL buffer overflow (MS01-023, MS01-033) Buffer overflows in the .printer and .ida ISAPI filters granted malicious users command-line access to vulnerable servers. Removing unused filters from the IIS install would have protected servers.

·          IIS FrontPage Server Extensions (MS01-035) Another buffer overflow that granted command-line access. Again, removing unnecessary components from the IIS install would have protected many servers.

Attacking Protocols

Servers are always susceptible to denial of service (DoS) attacks. These attacks usually consist of excessive amounts of traffic being sent to the victim Web servers. For example, if the Passport authentication servers were taken down due to a flood attack or a backhoe slicing fiber lines, any partner site that requires Passport authentication would be out of commission as well. A successful DoS attack would be difficult to accomplish against networks specifically designed to handle high bandwidth.

Still, there are some measures you should take to protect your own servers:

·          Apply rate limiting to border routers Cisco IOS supports committed access rate (CAR) controls with the access-list and rate-limit configuration options. Using CAR can aid your network against DoS attacks, but requires careful configuration to make sure they work appropriately for your network’s average bandwidth, peak utilization, and traffic composition. Here is an example designed to protect against SYN floods. It permits traffic to TCP port 80, but limits SYN packets (new connection requests) while permitting all established connections to continue normally. You would change the numbers 64000 8000 8000 in order to set the average allowable bandwidth and maximum burst numbers:

access-list 101 permit tcp any any eq www

access-list 102 permit tcp any any eq www established

access-list 103 permit tcp any any syn

interface <interface> <interface #>

rate-limit input access-group 103 64000 8000 8000 

conform-action transmit exceed-action drop

·          Design redundancy into the network and remove or limit single points of failure Network equipment such as routers, load balancers, and firewalls should be deployed such that they have failover components. If a single load balancer serves a farm of 20 Web servers, a failure in the load balancer would prevent access to all of the Web servers.

·          Deploy a geographically diverse network This can be difficult to accomplish for applications that rely heavily on database transactions. However, networks that are distributed geographically are more resistant to power failures, bandwidth flooding attacks, or equipment failure. It is similar to redundancy.

·          Ensure servers are maintained at a current security patch level If application servers lack security patches, malicious users could more easily create a denial of service or compromise a system. After all, it’s easier to bring down a server with only a few dozen packets against a known vulnerability as opposed to flooding the server with millions.

How to Protect Your Servers from Threat?

The IIS ISAPI filters caused a great deal of headaches for administrators. The default installation for IIS is notoriously insecure and includes several items that can be removed in order to make it more secure while not hampering its performance. Here’s a quick checklist of recommended settings for IIS:

·          Remove all unused ISAPI filters. This is a simple measure that buys a lot of security.

·          Place the Web document root on a drive volume that does not contain the system root (WINNT directory). Preferably, this will be a volume that holds no other data but the Web application’s code.

·          Network access lists should only permit inbound Internet access to ports 80 and 443.

·          Network access lists should not allow Web servers to establish outbound Internet connections. This means that the Web server can still answer incoming connections, but the server cannot be used to access an FTP server, a TFTP server, or any other service on the Internet. This makes it more difficult for a malicious user or a worm to use the server as a platform for further attacks.

·          Database servers should only use integrated authentication. Regardless, the “sa” user password should not be blank!

Happy  Learning !!!