Cracking the Puzzle: Unveiling the Flaws of Insecure Design

Sometimes as a penetration tester, you instantly know there is an issue. However, simply explaining the security flaw isn’t sufficient, and you need to show why it’s an issue and how to exploit it!  

This is a narrative following a desktop application penetration test, doing just that. 

Firstly, it was noted that while the Desktop Application was well-designed in some aspects, the SQL Database was public-facing and lacked Application Programming Interface (API) based segmentation or something similar to segment all the sensitive data, which made the tester think there must be a significant exploit, and would just need direct access to the SQL Database.  

When the Desktop Application started, it enforced TDSENCRYPTION utilising Transport Layer Security (TLS), enforced for all communications through the application. This led to man in the middle Attacks (MitM) failing during the testing. We tried generating our own TLS Certificate, but it was not trusted. Replacing the certificate in the application would take significant resources with no guarantee to succeed, since hashes would change and could be checked on the backend.

Below are details of some steps taken trying to MitM the traffic to and from the application.

First, we used Wireshark to monitor the traffic and identify the servers used by the desktop application.

Two key IPv4 addresses were identified, which have the hostname <redacted>.database.windows.net. 

Shows the Wireshark traffic which was active when interacting with the Desktop Application

Shodan was used next, a search engine that scans devices and services connected to the internet, which disclosed the service as AzureSQL.  

Shows the service in Shodan

A direct Nmap scan with some common Microsoft SQL scripts revealed the version, on a positive, although not the most recent version, it did not have any publicly disclosed vulnerabilities.  

Shows a Nmap scan result

Direct brute force attacks on the database failed. However, since the service was Azure SQL, the default SA password would not be permitted by default. After only one failed credential using another guessed username, the server blocked the IP. A round-robin (rotating IPs) could be performed, but without knowing the username, the probability is extremely low and time-consuming. So, we moved on!

Next, a MitM attack was attempted. It was noted reviewing the previously obtained Wireshark network traffic that it was not using standard HTTP/HTTPS, which adds some complexity. Full details of the tool used can be found here NoPE. However, it was evident that the SSL/TLS certificate could not be replaced to facilitate MitM attacks, with all communication attempts failing.

Shows a connection to the host is closed after turning on our MitM encryption certificate

Further attempts were made. The next image shows a connection intercepted without presenting our TLS/SSL certificate, as expected, it is encrypted.

Shows a snippet of the encrypted traffic

The configuration protecting MitM attacks was evident again when we enabled our certificate, we got an immediate error.

Shows a connection error

All of the above enumeration and exploitation attempts concluded that the data in transit from the application was well-designed and secure. Therefore, in typical Penetration Testing style, we tried another route, going for direct access to the SQL Database.

Direct Access: The Insecure Design

Finally, delving into the core of the issue, we knew from the outset it had to be an insecure design! Although the Desktop Application was well configured, mitigating MitM, how did it make the initial connection to enforce the TLS Certificate? Usually, this is done on the backend via private APIs, for example. However, we could see in Wireshark that this wasn’t the case and the SQL Database was public-facing.

Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” In this specific scenario, following a few rabbit holes and failed attempts to enumerate how the connection was occurring, we got some results.

First, the application was reverse-engineered and decompiled to enable reading of the source code.

Shows a snippet of the reserve engineering attempts with some decompiled code

Once all the files were decompiled, common keywords like Password, SQL, and ConnectionString were searched. One of these searches led to a DLL that was updated on the day the application was installed.

Shows a string of code "SQLOLEDB Error Lookup", which is associated with a file sqloledb.dll

The sqloledb.dll file is a dynamic-link library (DLL) provided by Microsoft, used to enable OLE DB (Object Linking and Embedding, Database) connections specifically for Microsoft SQL Server databases.

Further enumeration and research led to the conclusion that this DLL, which runs in memory, was used to establish the connection to the Database, and did this when the application was executed. This facilitated the consultant to identify the Process ID (PID) and carry out a memory dump during the start-up of the application.

Shows the PID as 3828

Shows a process dump of the PID

Although the memory dump had 1,215,487 lines of data, a keyword search revealed the database connection string.

Shows the connection string with an obfuscated password

Jackpot, these details facilitated a direct connection to the database, and we could access everything, including a ton of sensitive information which could be exfiltrated and edited. For obvious reasons, it’s heavily redacted, but the next image shows a direct connection to the database.

Shows a direct connection to the SQL Database using the credentials obtained

This led to the conclusion that all data held by the application could be accessed, and would very likely impact Confidentiality, Integrity, and Availability (CIA) if ever exploited.

Our Recommendation

Aside from limiting access to download the application, and considerations around allowing listing a potential interim mitigation could be adding the SSL certificate (.cer) as a requirement to connect directly (same certificate mitigating MitM attacks). However, a persistent skilled attacker may still be able to extract and use it to connect directly.

Ultimately, we recommended that the Desktop Application connect via APIs instead of directly accessing the database. Using APIs enhances security, as it restricts direct data access and reduces potential vulnerabilities. Additionally, APIs can offer better control over data flow and allow for easier updates and maintenance without affecting the core database structure.

This assessment highlights how even well-configured components—like enforced TLS for transport—can be undermined by insecure architectural decisions, such as direct database access from a desktop application. It’s a clear reminder that security must be considered at every layer of the system, not just the obvious ones.

At CybaVerse, our penetration testing team doesn’t stop at surface-level scans. We go deeper, combining technical expertise with an attacker’s mindset to uncover hidden risks and help you fix them before someone else finds them first.

If you want to understand how secure your applications really are, get in touch with CybaVerse today to book a tailored penetration test with our experts.