App security audits: Don't ignore thick clients
- 30 July, 2008 08:26
When it comes to running application security audits many organizations make the mistake of assuming that only Internet-facing, browser-based Web applications deserve scrutiny. After all, thick client applications tend to face inside and tend to be compiled binaries so they are less risk of malicious tampering.
That assumption is dangerous.
Thick client applications face far fewer attack attempts than applications facing the Internet, but they also tend to handle the most critical transactions, and employees often know how these programs work from both a business and a technical perspective, making them prime targets for insider attacks.
In fact, compiled executable clients are often inherently less secure than browser-based Web applications, and the tools for tampering with them are available and easier to use than you might expect.
One axiom of application security is "Never rely on client-side validation for security" because it is easy to manipulate the client and bypass security controls. Yet the very definition of a thick client is one that performs most, if not all, of the application's logic. In many cases the application's architecture is two-tier, meaning the client talks directly to a back-end database with no intermediary server to enforce security. As a result, virtually all of the application's logic, including security, is in the client and thus in the hands of the potential attacker.
Thick client applications are prone to many of the same types of vulnerabilities that thin client and Web applications are. Yet the fact that much of the security enforcement responsibility is placed with the client translates into more critical vulnerabilities, including:
Password harvesting: When a user logs in to the application, it is not uncommon for the thick client to query the database for the password of the supplied user name, and then do a client-side check for a match against the password supplied by the user. As a result, the user can supply the username of other account holders and then obtain the password for that user from the database's response.
Privilege escalation: After a user authenticates, the thick client needs to know what functional features that user is privileged to access. This is often accomplished by querying the database and enabling or disabling various menu items depending on the permission bits returned by the database. If the user can manipulate these response bits before they get to the client, he can usually enable extra permissions -- perhaps even full administrative permissions to the application.
Hard-coded application credentials: In an attempt to prevent the users from directly accessing the database, developers sometimes "hide" the application's database credentials inside the compiled thick client. If the user can extract these credentials, he can often directly access the database with the application's full privileges. The security controls built into the client can be entirely bypassed in this way.
Tools and techniques
One of the most popular ways to compromise a thick client outside of decompiling the binary is to study the traffic to and from the application. Most thick clients use some form of connection back to a database or Web service to get data. The quickest way to see what the application is doing is to sniff the traffic on the wire using a program such as WireShark.
This will reveal the type of connection that is being used and probably the database name and credentials. Using this information, the hacker can try logging directly into the database without using the client, which may reveal more functionality and access than what the client shows. However, sometimes the database password is not revealed because a challenge-response mechanism is used to protect the credentials.
If database credentials aren't observed, hackers typically try to insert themselves in the conversation to see if they can modify any of the data while in transit. The quickest way to get at protected data and functionality is to use the functions built into the client, instead of trying to reverse engineer the client's database queries.
That can be done by escalating user privileges in the application. Thick clients typically support functions for a variety of user levels. However, some of these functions are not enabled for lower-privileged roles. To determine what rights the user has, the application will query the database and then parse the response to determine what functions to allow. If they can insert themselves in the conversation and alter the database's response, they will likely end up with the full set of features enabled on the client.
Modifying the data can be done many ways, but one method that works well is to use a stream editor such as netsed. Netsed looks to match a regular expression in the data stream and replace that value with one the hacker supplies. They will be looking for obvious data points that can be identified in the stream. Items such as user names, account balances, phone numbers, Social Security numbers and others are common targets. They will then configure netsed to look for these items and replace them with other values, and then check the results to see if they were successful. Knowing what success looks like makes the rest of the assessment easier.
To combat this type of attack, many application developers turn to encrypted channels between the application and an intermediary application server for database access. Encryption makes it virtually impossible for the hacker to determine which bits to change.
SSL- and TLS-encrypted connections are the easiest ways to provide this service, but they can be bypassed with a program such as stunnel. In client mode, stunnel will listen for plain-text traffic and then forward it as SSL-encrypted traffic to a new destination. In server mode, stunnel will listen for SSL traffic and then decrypt it before forwarding the plain text.
Using two instances of stunnel -- one in each mode -- allows hackers to insert a 'window' of unencrypted plain-text traffic between the client and server, where they can sniff traffic with WireShark or alter it with netsed.
These, of course, are only brief examples of what to look for. Thick clients are used less frequently in the ever-increasing Web application world, and many companies are paying less attention to legacy applications. This adds up to opportunity for attackers. Protecting these applications by evaluating their weaknesses allows your company to better understand its true risk profile.
Royster (email@example.com) is a senior consultant and Reed (Jason.firstname.lastname@example.org) is a principal consultant at SystemExperts Corp.