Thick Client Application Security - Attacks

By Paladion

March 15, 2006

Traditional two-tier thick client applications are vulnerable to several attacks. This two part series will discuss the attacks and defenses for them. In this first part, we focus on the different attack techniques and tools.

Traditional two-tier thick client applications are vulnerable to several attacks. This two part series will discuss the attacks and defenses for them. In this first part, we focus on the different attack techniques and tools.

Two-tier thick client applications usually perform most of the processing on the client; they use the backend database primarily to store and retrieve data. Thus most authentication and authorization are also done at the client. This common practice has paved the way for several attacks.

Thick client applications use a database driver to communicate with the database server. The following diagram shows the components involved.

Thick Client Arch 1

We shall discuss the different traffic interception techniques used to carryout attacks on such applications.

Intercepting at the Network Level

One of the most popular interception techniques used by attackers is the TCP/UDP proxying . Here, the attacker uses a tool such as Interactive TCP Relay to intercept the traffic between the database driver and the database server. The configuration file of the database driver (e.g. ‘ tnsnames.ora ' in ORACLE) specifies the database server IP and port. That can be modified to reroute the traffic via a proxy like ITR. When configured as a proxy, ITR can be used to intercept and modify the database queries. The diagram below shows where ITR fits between the client and the server.

Thick Client Arch 2

Now that we have seen how the traffic can be intercepted, let's look at attacks on the application with this method.

Attacks on Authentication

Many two tier applications build authentication logic into the client. The client queries the database for the password of a user and compares that with the input given by the user. This carries the risk of transmitting passwords to the client from the database during authentication. Here's an example of how the attack would work: the attacker attempts to login to the application with the admin login id, the application sends a query to the database to retrieve the admin's password. The attacker intercepts the response from the database with ITR and steals the admin's password.

This is especially simple if the password is stored in plain text. Incase the database stores a hash of the password, the attacker cannot steal the password, but can still try to fool the application into thinking the login succeeded. Here is how: the attacker replaces the original hash in the response with a hash that he has computed of a fake password. As the application compares the two hashes, the attacker will get authenticated successfully.

Attacks on Authorization

Similarly, carrying out privilege escalation attacks is possible if authorization checks are performed at the client. Consider the case where the client queries the database to learn the privileges of the currently logged in user. The attacker can intercept the query and change the user id to that of a higher privileged user.

In the screenshot of ITR below, the application queries the database for the user roles and rights after authentication has taken place.

Thick Client Arch 3

This query specifies the user ID in the ‘ where ' clause. Now the attacker can intercept and replace the original user ID with a higher privileged user such as ADMIN – that will escalate his privileges to that of the ADMIN user.

In addition to these, several other attacks such as SQL Injection and crashing the application and database can be carried out on thick client applications using ITR. We present detailed analysis of these attacks in the paper Thick Client Application Security .

As attacks on thick client applications evolved, developers started using the encryption functionality provided by databases to thwart interception. A new attack technique we describe in the next section overcame these defenses, though.

Intercepting Socket Calls

Tools such as Windows Packet Editor (WpePro) allow intercepting application traffic at the socket level. This means that the traffic is being intercepted before it reaches the network level. The following diagram shows how WpePro works.

Thick Client Arch 4

WpePro can be used to monitor the socket calls made by the application and modify the traffic before it is sent to the database driver. Similar to ITR, WpePro can also be used to carry out both the attacks we discussed earlier – attacks on authentication and authorization.

The user interface of the current version of WpePro supports only hexadecimal format. While we directly replaced the text (password hash or user ID) in ITR, filters have to be configured in WpePro to perform the attacks. The snapshot below shows how to create a filter to search and modify a particular text in WpePro .

Thick Client Arch 5

In July 2005, we described how this tool can be used to carry out replay attacks. It is tedious to perform attacks like SQL Injection, shutting down the database and crashing the application with such tools. But they can be used to obtain unauthorized access. In the next article of this series, we shall look at ways to prevent these attacks.

Tags: Technical