During their penetration tests (pentests), our security analysts at usd HeroLab repeatedly uncover vulnerabilities that pose significant risks to corporate security. They increasingly encounter the same vulnerabilities. Our blog series "Top 3 Vulnerabilities" presents them and provides tips on how to avoid them - for #moresecurity across all IT assets.
Today we look at the three most common security-critical vulnerabilities that our analysts have identified in pentests of fat clients in recent years.
Why fat client pentests?
Fat clients, also known as thick clients, are desktop applications which, unlike web applications, are installed on the user's local device. In addition to this locally installed component (front-end client), there are usually also back-end components such as application or database servers. Vulnerabilities in these applications grant attackers access to server-side business logic of the user's entire application landscape, including all data which is stored there.
Fat Client Pentests help to proactively identify and fix vulnerabilities in the application before they can be exploited to gain access to the entire server. Technically speaking, the focus of these penetration tests is therefore directed at the network communication of client and server components as well as the reverse engineering of application components and communication protocols.
Two-tier architecture
Some of the clients we tested rely on a two-tier architecture. This means that the front end of the application on the user's device directly accesses the database in the back end. Access credentials to this database are often stored in configuration files of the front-end application or in the code itself. If the application has a role and privilege concept, these credentials must map all privilege levels - from simple, low-privileged accounts to administrators. As a result, the application has administrative access to the database through these credentials.
Attackers can obtain these access credentials in various ways and thus access the database directly. For example, the credentials can be extracted from configuration files or the code. Alternatively, they can often be recorded in plain text by a network recording when the client authenticates to the database. If an attacker obtains these access credentials in any of the ways described, the existing access concept of the overall application can be circumvented and the database can be accessed.
Security tip:
We recommend the implementation of a three-tier architecture. In this case, an application server is introduced as a third tier between the front-end application and the database. This application server has exclusive access to the database access credentials and has the task of receiving client requests, checking them for authenticity and proper authentication, and then executing the operation.
Incorrect access controls
Many fat clients, especially in the context of the .NET framework or Java, rely on remote procedure call (RPC) mechanisms. Techniques from the Java world include Java RMI or Enterprise Java Bean (EJB). With these mechanisms, command calls are sent from the client to the server component in a format specific to the programming language and framework and are executed here.
In a large number of projects, we have discovered that some of these calls take place without explicit authentication. The developer of the software assumes that a valid session in the front-end client is required to access the remote objects and their methods. However, if an attacker uses a specially-developed client that simulates communication with the backend (very similar to the communication of the front-end client), this allows the endpoints to be accessed directly on the server side. This bypasses the entire role and privilege concept of the application and triggers any operations without knowledge of access data.
Security tip:
To remedy or at best prevent this, we recommend implementing an authentication mechanism at all server-side endpoints, for example in the form of session tokens that are sent to the server with every function call. The server can use these tokens to check the account making the call and its authorizations and, as a result, only process legitimate requests.
Insufficient authentication
The majority of companies use Microsoft Windows as the operating system for their employees' end devices. With Active Directory, Microsoft offers a standardized solution for managing user accounts/groups and authorizations. Furthermore, a variety of authentication methods such as NTLM or Kerberos are supported. In order to seamlessly integrate a fat client application into this environment, authentication using a user's Active Directory account is added to many clients. This account is also used for logging on to the operating system itself.
However, we often see a faulty implementation that leaves the authentication to the operating system and only reads the user name from the current session. The idea behind this is that only valid accounts can log on to the system and the user name obtained from the Windows session can be trusted. However, if an attacker starts the software via their own virtual machine (VM), they are able to name the local Windows account the same as the account they plan to take over. Due to the faulty implementation, this user name is read and trusted without checking its authenticity. In some cases it might also be possible to change the login name using an intercepting proxy on route to the server.
Security tip:
Fat clients should perform authentication independently and not rely implicitly on other components such as the operating system. If authentication is required without explicitly entering a password, Kerberos authentication on the Active Directory can be used, for example.
It is important to note that many other vulnerabilities may exist in addition to those mentioned. As every fat client application has different functions, new threats can also arise. A pentest can provide clarity and help you to effectively protect the data of the application and the server.
Would you like to have your fat client application tested? Contact us, we will be happy to help.
