An often overlooked section of security is the managed code desktop app. Applications running on servers or the desktop written in C/C++ are often attacked and even where I started my security. But let’s look at a C# desktop app that communicates with a server. Farther, let us take a very methodical approach to testing this application. The Damn Vulnerable Thick Client is the app we will start with. Download the zip of the file and store somewhere for now.

Setup

First we must install SQL Server. Install which ever dependencies you need. I would suggest you also download SSMS as well. Next install Filezilla Server. Once all of these are installed, we will begin the setup. Let’s go with all standard defaults. And use p@ssw0rd for the password.

For an even better experience, instead of installing on our local VM, a free 30 day trial version of Windows Server can be installed. With this, you can try to do forensics on the hacked box.

Next open SSMS and connect to the local database. We must run the commands to create the database and tables. Create database DVTA in SSMS. Then run the commands on the github page to create the tables or copy the following into a new query.

use DVTA
CREATE TABLE "users" (
     "id" INT IDENTITY(0,1) NOT NULL,
     "username" VARCHAR(100) NOT NULL,
     "password" VARCHAR(100) NOT NULL,
     "email" VARCHAR(100) NULL DEFAULT NULL,
     "isadmin" INT NULL DEFAULT '0',
     PRIMARY KEY ("id")
 )
 go
 INSERT INTO dbo.users (username, password, email, isadmin)
 VALUES
 ('admin','admin123','admin@damnvulnerablethickclientapp.com',1),
 ('rebecca','rebecca','rebecca@test.com',0),
 ('raymond','raymond','raymond@test.com',0);
 go
 CREATE TABLE "expenses" (
     "id" INT IDENTITY(0,1) NOT NULL,
     "email" VARCHAR(100) NOT NULL,
     "item" VARCHAR(100) NOT NULL,
     "price" VARCHAR(100) NOT NULL,
     "date" VARCHAR(100) NOT NULL,
     "time" VARCHAR(100) NULL DEFAULT NULL,
     PRIMARY KEY ("id")
 )

Unzip DVTA and open the solution file. you will notice that mutliple files are missing. Don’t even attempt to build. We will return to this is the future and get the project running. In the extracted folder, we will go to DVTA\Bin\Debug\ and run everything from there.

Setup II

Within Commando, the application Obsidian exists and is great for taking notes. It’s like cheery Tree or any of the other programs out there. This comes prepackaged, and should be opened, and reviewed before continuing.

Next we will install Process Hacker 2, this is just like the sysinternal tools installed on your box but takes things a bit farther. Process Hacker 2 may be found here.

Next we need to install metasploit for some other attacks we will perform. This is a massive tools and one that can take many hours to learn. After the install, and the end of this article, a number of links will be provided for additional training.

Setup Summary

Just to summerize, since this hack takes some serious time for setup and some external software packages here is a summery:

  • Download the DVTA from gitup as a zip. Unzip and ignore everything excel the debug directory.
  • Next download SQL Server Express and SSMS.
  • Finally download Filezilla Server.
    • Finally complete their setup and use default p@ssw0rd (now forget this password 🙂
  • On the desktop, go to Tools -> Utilities -> SysInternals and notice the large number of programs at our disposal. These will help us live off the land.
  • Install Metasploit for Windows
  • Install Process Hacker 2.

Setup Verification

Verify everything is up and running and open the DVTA app. Here we can notice that we have a log in screen and a register. If we attempt to register, the program hangs and produces a SQL error.

At the bottom, the button is not active, where I placed the blue check box. This is probably not to accurate in the wild, but it does server as a good test to working with an issue we will come up again in the future.

Often times applications have buttons (controls) that are invisible and display based on permissions.

These types of Desktop apps can be written in many different languages. C#, Java, C++, VB, etc

Architecture

Two types of architecture is common, the two tier and the three tier. Our setup here is one as a two tier where everthing is hosed on one system. For bonus points, and a much better forensic analysis, a second server could be setup. I’ll leave this to the reader to implement.

Essentially the two tier architecture speaks directly to a database or FTP, while the three tier has a “middle wear”. This offers a whole of advantages at the same time is more resources.

A Formal Methodology

Up until now, we have just setup and attacked. That is excellent for getting out hands dirty, getting us excited, but it is not enough for a true code review/black box test/penetration test.

Open Obsidian, create a node for note taking and also a photo for all our screen shots. We will use greenshot fn+print to print and save.

We need a formal methodology to guide us. This not only ensures proper coverage but guides us less experienced hackers on how APTs (advanced persistent threat actors) maybe go about an attack. Behold the OWASP Windows Binary Executable Files Security Checks Project.

1. Information Gathering

First let’s determine what type of application architecture we are dealing with (.net, java, etc). We can choose from many programs in our desktop Tools folder. Ghidra, IDAPro, ILSpy, etc. Let’s try ILSpy and see what the program shows. It’s obviously

We can now see we are using .NET 4.8, compiled with Any CPU but running as 32 bit, and using C# 11 as the programming language and last built with VS 2022. We also see the WinForms reference, so we know it’s is now WPF or something else. Opening the DBAccess.dll, we can see the System.SQL reference. From experience we know this is NOT an object relational mapper (ORM) which helps prevent sql injection. There is an entity framework dll in the folder as well. Let’s use another tool called iLDasm.exe

& "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\ildasm.exe" .\DVTA.exe

As long as you have the SDKs installed, you should have this tool. Looking at the manifest by double clicking we can see EF is a red herring. Here is where being a software developer comes in handy for thinking about these artifacts. It’s highly doubtful we would move back to sqlcommand from EF. Most likely the dev is planning an upgrade, or started one and wasn’t sure how to proceed so rolled back and the .DLL was never removed. Sometimes Clean in visual studio doesn’t clean like you would except!

Let’s dig deeper into the application by attempting to use it as a normal user would. This may help us understand the business logic and the infrastructure.

Attempting to log in and we get a SQL crash. We can’t reach the database. Checking the config files in the folder we can see that an IP address is there. Changing the IP address and the program still does not run. Let’s open dnSPY and see if we can alter the code to make the Configure Server button enabled.

So once we open the app, we can find the string Configure Server. We will find a few places where this.configureServer.Enabled = false; can be found. The only one that matters. We can first right click. Now we can actually edit the assembly!

Here we can edit the IL Instructions or Edit the Method. Once we change false to true. At the bottom we hit compile.

After compiling we hit save module. We can even adjust the .pdb (symbol file) and the app now runs with the Config Server button enabled.

Now the “Configure Server” button is available and we can, well, configure the server! Since our client/server is the same box, you can put the loopback address 127.0.0.1 or COMMANDO or probably even localhost.

After hitting configure server, we can now see a popup that says the server is configured.

We should be good to register and start poking around.

We can gather this app let’s use add expenses and view expenses, even exporting them to csv. The basic login of the app is pretty simple. Make sure you are logging everything in Obsidian. At this state, spelling etc does not need to be perfect, just the facts and anything you want to convey to your client.

Extra Credit: Now that we know the versions of application libraries, you can begin to look for exploits freely available online.

Living off the land

Living off the land is really just as the name implies. We attempt to use only tools we find on a machine we are attacking. If we need to do something, we first attempt to do it within memory only, not touching disk. If this fails, we move to installing tools that are well know like from Microsoft. One of these tool sets is Sys Internals. But at the heart of these attacks, we have two tools available to use that can accomplish almost anything WMI and Powershell. We will discuss this in great depth in future articles.

Phase 3 & 4 Network and Server Side Attacks

Installation traffic doesn’t matter here. Especially since we are pretending that we didn’t do that setup or this whole exercises would be pointless. Our run time traffic however, can help us gain more information about the system. Here we essentially have Network, Client, and Server side all performed at once.

Here we use TCPView, just to check what could be going on with our application.

Here we see the actual connection to sql server. Note we can see our ftp server as well and had we triggered some ftp action, we could have gathered the program also uses ftp.

The Queen of these apps, however is Wireshark. We can see here packet by packet our communication with the sql server. Not only that, we can see that the app is sending data in plain text!

  • The connection string for the database.
  • Our admin password during authentication.
  • Standard packet asking for passwd.

This now leads to our first two possible vulnerabilities. Notice we now have the database connection string with username and password sa and p@ssw0rd. We can also see select statements that look quite suspicious. They look as through the value was plugged right in.

Let’s now try a sql injection attack in the log in. Let’s leave Wireshark (or tcpdump, etc) running so we can see if more than one row is returned.

No errors on log in and we are returned back with a user raymond.

Reviewing the network traffic, and we now have the entire user table.

Now we also have the admin password. We definitely need to log these poor passwords as findings.

Now we log into the admin interface and are presented with a new interface.

Run wireshark and let’s see what data we can capture. The file exists from a previous test. Though it seems it should have just incremented and updated.

Back to our regular interface, we see an add expenses option. Also an export to excel option. If we can enter something like =1+2 and it saves, will the export then show the expense as 3? If so, we have a CSV injection.

  • Inject formula
  • View Formula in Grid
  • Export to CSV/Excel.

Phase 2 Client Side Attacks

As software devs, sometimes we like to write Console.Writeline() and send debug info the output windows instead of watches or breakpoints. These are almost never turned off. Thus we have some insecure logging.

Open a command prompt and run the application. However pipe standard out to a text file. Ex .\DVTA.exe >> console.txt now cat console.txt. Full connection strings.

The second attack we will perform is a memory dump. This can be done in so many different ways.

We can run procdump.exe DVTA.exe

With this dump file we can often find many in memory details. The gallery below shows Windbg being opened and the dump file being imported. We then run the analyze command and can view all the registers etc. Finally we can pull out sections and run the strings.exe command to find juicy details. Of import note, sometimes the SOS.dll needs to be loaded to run fully. WinDBG is a tool that you should aim to master, even just for software dev.

  • Import
  • Interface
  • Registers and More
  • Command to Dump
  • Command to Dump
  • Raw Data
  • Raw Data

Dump files can also be made from the task manager, ProcMan, Process Hacker, among others. After exporting we can run strings.exe to also find details that are human readable.

In the program file, we find the xml manifest file. Note that mid way down we see AES, IV, and password.

  <appSettings>
    <add key="DBSERVER" value="127.0.0.1\SQLEXPRESS" />
    <add key="DBNAME" value="DVTA" />
    <add key="DBUSERNAME" value="sa" />
    <add key="DBPASSWORD" value="CTsvjZ0jQghXYWbSRcPxpQ==" />
    <add key="AESKEY" value="J8gLXc454o5tW2HEF7HahcXPufj9v8k8" />
    <add key="IV" value="fq20T0gMnXa6g0l4" />
    <add key="ClientSettingsProvider.ServiceUri" value="" />
    <add key="FTPSERVER" value="127.0.0.1" />
  </appSettings>

From here we can go to a site to decrypt this data, maybe <dev glan>.

If we paste in the password, AES key, EBC and 128 we get an error. Notice there is no room for the IV. If we change to CBC we can paste in the IV key. We still get an error. Now if we up the bits to 256, we can see the decrypted password.

Later we will take a look at the algorithm and see how well it is impleted. However at the end of the day, if we can get all the keys and data, it doesn’t matter how well it is implemented, we can retrieve the information.

AES is one of the most secure encruption algorithms around, and this type of attack is really unacceptable.

SysInternals is an amazing tool set, let’s see how we can use the tools for some additional exploits.

VMMap, Virtual Memory Map, RAMap (Random Access Memory) Map allow us to explore memory in a wholistic view.

Process Monitor is a tool allowing us to explorer process data and properties.

Process Hacker 2, is even more powerful letting us watch the register, DLL loading and so much more.

If we load DVTA into Process Hacker, we can see that we are storing unencrypted user data in registry.

Notice on the context menu we have an inject dll option. However if we can reopen process monitor and filter on the following. This will show all the DLLs it will attempt to open.

We can see it attempts to load a DWrite.dll in the directory. If we now open the metasploit directory we can run msfvenom.

Placing this DLL in the folder, when we run the DVTA app, it should load.

However we get a bad image. Sometimes this happens. We need to do some trial and error to get the dll to work.

I leave this to the reader.

Next we load the msfconsole and set a reverse shell and wait.

There is another option that actually works.

We receive our connect back and we have persistence and control.

Here are all the files that were ran to help in your replicating of these attacks. I have included them as a zip file here.

Note I did run nmap just found fun and something we would have for sure done. I included the output here.

A list of all the vulnerabilities found and should be written up in the system.

Weak cryptography — FOUND (code review)
Exposed decryption logic — FOUND
DLL Hijacking — FOUND
Client side protection bypasses using Reverse Engineering — FOUND
Insecure local data storage — FOUND
Insecure logging — FOUND
Lack of code obfuscation — FOUND
SQL Injection — FOUND
CSV Injection — FOUND
Sensitive data in memory — FOUND
Clear text data in transit — FOUND

In part 2, we will completly lock down this app and fix all vulnerabilities.