Desktop Application
Penetration Testing (1)

Hello everyone, in this blog I wanted to write to you about an interesting Desktop Application Penetration testing engagement I went through in a big financial entity, which could be informative and inspiring.

The application was well implemented with huge functionalities and privileges to manage a huge system, which seemed challenging at first.

After some static analysis and dynamic walkthrough, some variables in the application source code are being assigned a value dynamically during runtime, so I needed to intercept the traffic, which was a very complicated journey after understanding the generic way of traffic encrypting that was well-implemented, another choice was to debug the application to check for these values while being assigned, but before consuming time in anti-debugging techniques, I decided to make a dump file for the memory and check what juicy info I would find there regarding these variables,

and as expected - it’s common -, after extracting strings from it using microsoft utility,


I found my login credentials in plain text,



that shed light on another thought in my head, finding my username and password in plain text could be an indication to find something else that should have been used during the login and authentication mechanism,

Exactly….,

I meant the Encryption Key of course.

I wasn’t sure, so I decided to re-read the dump file line by line in the authentication part around my login credentials. This analysis took some time, but it was worth it since I noticed that there’s a string value being called before the strings referring to authentication.

I suspected it could be the key, so I then returned to the static analysis, after reversing the application which was written in C# and searching this value in the source code, I found it hard coded inside one of the DLL files used for encryption.

I recognized that I now have the key to the kingdom since I am somehow now sure that this encryption methodology and this DLL file with this key are used for the encryption during the authentication process.

I took the encryption class written in this DLL file, with all its dependencies externally to my Kali Linux, and made a Decryptor.cs file to implement my C# Decryptor for this algorithm, where I added some lines to handle my inputs "the encrypted values" and let the magic turn against the magician.

---

Then I used the mono-complete which is an open-source implementation of the .NET framework. to convert the .cs file using mcs Decryptor.cs to executable file.exe and then able to execute it in Linux using mono Decryptor.exe

Using this executable now I managed to decrypt any encrypted data found in memory, local storage, and hard-coded values, by which I reached a lot of juicy info.

After expanding the use of this script I decided to go further for a privilege escalation vector,

so I returned back to the static analysis searching for the connection methodology with the Database server to check if I could make use of my Decrytor, until I reached the Class responsible for Database Connection, which shows a part of a SQL query that Authenticates using a hardcoded id, but for the password, it's value is assigned dynamically during runtime to a variable named AdminPassword, so luckily I now have the ID for the Admin to the Database, but for the AdminPassword variable, I didn’t find any relatives to this password variable, so for an instance I could have skipped this to another vector...

but I remembered the Memory Dump file I used earlier, now I can re-search for this ID in memory and check for any near values being cached around, which could be the password such as my ID and PW as shown earlier,

I found the ID !


but found more than one encrypted values around, and luckily found the same encryption key being called again, which confirmed my thoughts, that the database connection password is also being encrypted with the same key, I started extracting all these encrypted values and Decrypt them using my Decryptor until I found a value that could match a password format.

I asked myself before heading straight to connect to the DataBase, why don't I check for these credentials in the Desktop Application itself, since it's a way common mistake that the employees sometimes use the same credentials for multiple accounts.

I monitored the floor around me until the employees finished their work in their accounts in order not to interrupt their running tasks and functions.

After I waited until they had finished, I tried to log in using the values I collected but had a prompt telling,
I thought the employee didn't fall in that trap, especially since this prompt is a default prompt done even if you used a wrong password - which leads to another vulnerability performing users enumeration, but this is not the scope of my blog for now - .

I then heard an employee telling someone inside the IT group that she was currently managing something in the database, so I recognized that this was the user I found, the user is actually logged in!

that gave me another hope to retry later.

I waited until she logged out of her account, and retried to login, and this time I logged in successfully in the Desktop application with the Administrator Privilege!!,

and now I also have the Credentials for a full access to the database server - which can easily lead us to RCE to the backend server, but this could be for another blog -.

---

For now, I wanted to shed light on:

1- How important memory dump file analysis is.

2- Always Check for Encryption methodologies used in the Application.

3- The Idea of re-using the same algorithm without exhausting yourself in reversing the methodology, you will re-use the same methodology but just by referring to the decryption part of it.

4- Also be aware during making any privilege escalation vectors and keep aligned with penetration testing standards to just show a POC of the whole process without exposing more info than needed for your check.

5- Finally, Having a challenging encrypted traffic with a challengeing communication protocol and challenging anti-debugging techniques don't mean you won't reach the highest impact. ;)

---

That was all and thank you for reaching here :D