During a recent audit, I created a simple scanner to facilitate fuzzing of parameters sent from a desktop app to the server. A custom tool allowed me not only to bypass client-side sanitization, but also to send more malformed requests in a structured way, instead of manually testing out one by one. The application I got to work on was a corporate financial software for managing loans, credits, payments, invoices etc. It was written in .NET Framework and it communicated with a remote server running a WCF service.

Step 1. Bypassing client-side data sanitization First, during the initial reconnaissance, I’ve traced code flows during execution of actions from the desktop app. Before a request to WCF service is fired, a sanitization is performed. I’ve found this within one of the client libraries, APPlib.dll: The code simply escapes quotes and backslashes. At first sight it may be doing it to prevent SQL injection, but is also serves a different role: requests to WCF server are textual data separated with whitespace, generally in this form: Inconsistency in single or double quotes would break the key=value structure, so the role of this function is to handle this.

The data is sent to the server as a vData object - a class that is used throughout the application for data exchange. The code responsible for constructing the object (adding new keys and values) is shown below. The escape function is always called when preparing user data (vData object) to be sent: Sanitized data is passed to putRaw function that assumes data is safe. The function has “private void” signature, meaning it cannot be accessed directly from a function outside of the class. However, it was sufficient to change the function definition to “public” using dnSpy software and export the new, modified DLL to the application directory. Modified signature is shown below: This allowed to create own custom code that would prepare vData datasets with unsanitized content inside, therefore being a basis for performing injection attacks – by calling putRaw directly, bypassing the escape function.

Step 2. Gathering information about functions and data The application was opened in a debugger, and a breakpoint was set inside the beginning of callApi function within vAPIBase class: The breakpoint was set to continue execution (do not break) when hit, and a log message was defined, containing values of variables “function” and “inData”. When browsing the application in the regular user interface, this allowed to dump every function name and data sent to it, therefore creating a database of functionalities qualifying for attacks. An example part of debugger output is shown below: A simple parsing script was written to automatically load function names and data structures from this log into a C# Dictionary object. Having this, it was possible to iterate over endpoints automatically, preserving the original data structures for each endpoint.

Step 3. Exploitation I created a list of mutators within the custom client, to facilitate simple fuzzing of all parameters within each called function: Each parameter within each function was subjected to a mutation. For example, for every parameter, a null byte was appended as the second character. Each mutation was isolated from others, meaning a single request always had only one parameter changed.

Within one of the identified functions, actionsTaskGetList, there were two parameters: “ContractName” and “ExecState”. Execution of a program revealed that one of the invocations, namely “append_single_quote_bs” mutator for “ExecState” parameter, which appends to the parameter a single quote preceded with a backslash, returned the following error message coming from an SQL server:

Original data of this parameter was “IN(1,2,3,4)”. This was an indication that an SQL query may be constructed insecurely. So, I’ve attempted to inject a UNION query inside the statement to confirm that entire modified SQL syntax is parsed correctly. After (another) automated discovery that the UNION query should contain 40 columns to match the original statement, the final injected value was: After execution, the server indeed returned the information about its version within the first column, confirming existence of the vulnerability: Thanks to the list of endpoints gathered before and combined with applied mutators, the scanner detected a total of 5 SQL injection instances within the application. All of these were available to exploit using a low privileged account, without admin credentials. Within the same audit, the same approach was used to detect broken authentication – cases, where low privileged user can access administrative functionalities, even though they are invisible in the UI. Takeaways Constructing SQL queries by concatenating user input is never a good idea. Even though injections may sometimes require a bit more work to prepare, it’s just a security by obscurity approach, and so will fail sooner or later.

Escaping user input client-side is fine for user interface logic, but it’s the server that should properly sanitize the input before execution step.

On top of this, successful exploitation wouldn’t be so straightforward if it wasn’t for verbose error in the application, indicating what exactly happens underneath.