PEnetration TEsting Proxy (PETEP)
Capturing network communication based on the TCP protocol and modifying it by creating a specialized Man-in-the-Middle proxy is one of many practices used for searching for security flaws in network applications. In this article, we will focus on the use of the cross-platform open-source application PETEP for testing fat clients using TCP protocols and show a simplified attack procedure on a sample vulnerable application.
We base our penetration testing of fat clients on complex methodologies and we use a wide portfolio of tools. A large part of the testing is devoted to trying to disrupt the logic of the tested application in many different ways – and the modification of the transmitted communication is one of them. For these purposes, we usually use tools such as EchoMirage, Burp, Zap, Wireshark (for analysis) and many others.
However, when testing applications using protocols building on TCP other than HTTP/WebSockets, we often hit on the shortcomings of current solutions, especially in case of a broader and more complex testing requiring effective communication analysis and the subsequent effective management. For this reason, a new tool called PETEP (PEnetration TEsting Proxy) was created.
PETEP is an open-source tool coded in Java. It allows creation of proxy and working with communication using functionalities such as rule-controlled labelling, modification, logging, and capturing data units transmitted with the TCP protocol. Moreover, to make the work with communication more convenient, the tool can be connected to existing tools for working with the HTTP protocol, such as Burp Suite and Zaproxy. The application is also fully extensible with new protocols and various data processing modules, through the development of one’s own Java archive packages.
As an illustrative demonstration, a simple application developed for the purposes of attack demonstrating will be used, namely the basic vulnerable chat. Of course, such attacks are much more complex and time consuming in reality, but they are often based on a very similar principle.
Creating and configuring the project
The test as such using the PETEP tool begins with the creation of a project. Here, we choose the required modules needed for our work. Then we configure the individual proxy modules and interceptor modules (for data processing). Interceptor modules can then be assembled and configured in both directions of communication according to specific needs.
Communication analysis
Extensive network applications often use their own protocols built on TCP, and for the testing to be thorough, it is necessary to understand the transmitted messages and to navigate across them. For this reason, any attempt at the disruption of communication is usually preceded by the analysis phase, where we deal with the functioning of the protocol used and we set rules for automatic labelling of data units. Using these rules, the tool consequently marks individual units with certain labels such as "login", "account_balance_check", "heartbeat", etc. depending on the content, length and other parameters.
The example application uses very simple plain-text protocol of the following format – in both directions:
![[]](/static/images/article-icon--blue.929eff9893d6.png){kind=icon}
[command] [data]
For example:
login user 1234 print Text to be written to chat…
It follows that if we want to label the individual data units, it is enough to detect the beginning of the data – e.g. in case data units start with “print”, we can mark them with the “print” label (see the video below).
Labelling individual data can later become handy, especially when working with applications with a large number of transmitted messages , which would otherwise be very hard to filter. By assigning labels to data units, it is then easy to carry out their subsequent filtration.
Situations where we need to pause, log or otherwise work only with certain data and the rest must be released without delay to avoid stopping of the established connection, can be seen as yet another practical use of automatic data labelling, which we encounter during real-life testing.
Manual modification of transmitted data
After the analytic phase, we target our effort on disrupting the operation of the tested system by using various modifications, replay attacks, and other techniques.
We will demonstrate a very simple and yet, often efficient, attack on a sample application. For these purposes, we will exploit the application’s vulnerability which lies in incorrect authorization check performed on the server side resulting in the authorization taking place only on the client side.
Specifically, the “secret” command will be used. It is available only to the admins of the vulnerable chat. If any user enters this command to the entry field, the application will show him an error message stating their insufficient rights. Several different approaches could be taken to overcome the client-side validation, for example:
- Application modification according to the reverse engineering methodology.
- Sending the “secret” command directly to the server.
- Changing the client-side rights with the modification of communication.
We will take a look at a variant in which we will change the rights on the client side, and we will convince our client application that we have logged in under admin rights, although we will continue to be registered as a normal user on the server side. This modification is done by replacing the "USER" role with the "ADMIN" role in the command sent by the server to the client after a successful login.
Similar vulnerabilities can be often encountered not only in fat clients, but also in wen SPAs (Single Page Application). Authentication must be performed on the server side at all times, but it often happens that authentication checks are omitted for some actions, and an attacker can thus easily cause major damage to the system.
Automated data modification
Manual data modification is suitable in case of manual vulnerability testing, however, for a continuous misuse of the given vulnerability, it is rather beneficial to automate the misuse of the vulnerability.
In the previous section, we have demonstrated how the client-side privilege check can be bypassed with manual data modification and the admin command "secret" can be thus used with a user account. This procedure can be very easily automated by creating a rule for labelling the command "principal" and creating a modification rule for replacing the "USER" role with the "ADMIN" role in this command.
After setting an automatic change of the user role, every time we log in afterwards, the administrator role will be immediately set for us, so we can continue testing with the application switched to the administrator mode.
Many times, automated modification is also suitable for performing more complex attacks requiring modification of a larger amount of data in different data units. This is especially the case for applications where a longer delay between messages causes automatic termination of the connection.
Connecting PETEP to external HTTP proxy
To make our work with the transmitted data (modification, repetition, fuzzing) comfortable and efficient, we are often working with the tools we are used to from web application penetration testing, namely Zaproxy and Burp Suite. When using them during fat client testing, we will take advantage of the External HTTP Proxy module functionality providing serialization of all data units passing through the set proxies and encapsulating them into HTTP requests. The resulting configuration of the communication can then be described with the following diagram.
This way, a web client and web server simulation is created inside the PETEP tool. This leads to the possibility of connecting it to ordinary testing HTTP proxies.
This mode allows us to use for example all functionalities of the Burp Suite app, especially the Repeater and Intruder modules. To understand its use better, let’s have a look at the example below, where the PETEP is interconnected with Burp Suite followed by the actions below:
- 1:36 – data unit resending with Repeater,
- 2:10 – changing the client-side privileges by sending a data unit with modified role and misusing the missing server-side authentication for launching the “secret” admin command,
- 3:30 – automated sending of data units with Intruder for SPAM,
- 4:50 – dictionary attack on the admin password with Intruder.
Application extensibility
One of the major features of the PETEP app is that it is a multiplatform and fully extensible technology. This means that we can develop new extensions providing additional functionalities, including those tailor-made to specific testing. It is because extensions to the application can be used to add support for other communication protocols, own interceptor modules, or labelling/modification rules as well. (See the developer manual.)
Conclusion
Fat client penetration testing is a complex discipline involving a wide range of activities, such as file analysis, reverse engineering, memory analysis, network communication analysis and modification, and many more. Many different tools and methodologies are used for these purposes to achieve a complete check of the current security status. In this article, we specifically discussed the use of PETEP tool for analysis and work with network communication of tested applications and we have seen what some types of attacks may look like in a simplified format.
If we were to make recommendations regarding securing the application from similar vulnerabilities, it needs to be said that any measures taken on the client side can be always overcome and it is only a matter of time before the attackers find a way to bypass them. Therefore, it is necessary to perform all security checks on the server side every time and thoroughly test the functionality of these checks before deploying the application into a production environment.