Overview During a penetration test of a desktop application's backend interface, a critical flaw was identified that allows unauthenticated users to execute SQL queries by sending specially crafted requests.

Although the backend was intended to restrict unauthenticated queries to simple SELECT statements on a specific configuration table, the actual implementation failed to properly validate the structure and scope of those queries. As a result, it is possible to use SQL injection techniques, specifically the UNION operator to extract sensitive data from unrelated tables in the database.

This vulnerability directly enables session hijacking. By retrieving values such as session_id and station_id from the user_log table, an attacker is able to assume the identity of any active user, including administrative accounts. The attack does not require prior knowledge of credentials or active interaction with legitimate users, making it highly effective and dangerous!

Additionally, the application’s client-side interface was built with Java Applets, which are downloaded as JAR files over unsecured channels, making it trivial to intercept the network traffic and extract the binary artifacts. Although the applets were supposed to enforce sandbox restrictions and verify digital signatures to prevent tampering, the delivery mechanism lacked integrity checks, allowing attackers to retrieve and decompile the JARs at will. By reverse-engineering the decompiled code, every critical class structure, method implementation, and custom communication protocol was exposed. These insights were then incorporated into a sophisticated exploit chain, enabling automated privilege escalation and full system compromise! Request Flow and Exploitation Strategy The application communicates with its backend by exchanging encrypted Java objects over HTTP. The core objects in this process are DCSRequest and DCSResponse, which encapsulate both metadata and action-specific content. These objects are serialized and encrypted with a symmetric AES key. Once the backend receives such a request, it decrypts and deserializes the object and then performs the requested action.

To initiate the exploit, I send a minimal request with required metadata fields but without a valid session ID. This request triggers the backend to issue a new session context and return it within the response. The exact code used to send the first request looks like this: After receiving the response, the attacker could extract a new station_id and session_id. These values are then used to build a follow-up request that targets the SQL execution function. The application is designed to allow unauthenticated users to run limited SELECT queries against the system_profile table, but this check is casual and can be bypassed.

The injected SQL query is appended using the UNION clause to extract rows from user_log, where live session and station data are stored: I calculate the checksum as expected by the backend:
When the request is sent, the backend executes the combined query and returns session tokens, which may look like: The attacker can now impersonate any of these sessions by crafting subsequent requests using the stolen session_id and station_id values. Consequences of the Flaw Once the attacker has valid session identifiers, they can issue any request that a legitimate user would be able to. The backend does not validate whether a session is linked to a properly authenticated origin, and since the communication is based solely on the serialized object content, there is no additional layer of protection.

This means that with only two requests: one to create a base session, and another to inject the query an attacker gains the ability to:

• View all live sessions
• Assume the identity of administrators
• Extract arbitrary rows from other tables (including hashes and personal data)

Because this process does not rely on social engineering or interaction with legitimate users, it is difficult to detect with standard logging or monitoring. Moreover, the AES key used for encryption is assumed to be static or hardcoded, allowing consistent access for anyone who knows it. Recommended Remediation The observed flaw originates from incorrect assumptions about query safety and the absence of strict backend enforcement. First, the backend must reject any unauthenticated action that is not explicitly safe. All queries should be validated against a fixed, pre-approved set, and the query engine should be removed entirely from the unauthenticated code path.

Second, session validation must be enhanced. The backend must confirm that session identifiers are bound to real authenticated users and issued through a secure login flow. Without this step, any value returned by the backend becomes an open door.

Third, any user-controlled string passed to the SQL engine must be strictly sanitized or, ideally, eliminated in favor of a fixed set of database procedures or an ORM that prevents arbitrary SQL execution.