Chaining Multiple Website Vulnerabilities: My First Bug Hunt
Bug hunting is the process of actively searching for software bugs, vulnerabilities, or weaknesses in computer systems, applications, websites, or networks.
Introduction
In this article, I will share my journey of finding my first bug in a real website, shedding light on the steps I took and the vulnerabilities I uncovered. From stumbling upon an unexpected LFI from a “View PDF” functionality to unearthing critical information disclosure and Remote Command Execution vulnerabilities. I hope this article helps a lot of new bug hunters.
Unearthing a Local File Inclusion (LFI) Vulnerability
Local File Inclusion (LFI) is a type of vulnerability that occurs when an application allows user-supplied input to be included as a file on the server. It typically arises from improper input validation or insufficient access controls in a web application.
When an LFI vulnerability is present, an attacker can manipulate the input to include files from the local file system that are not intended to be accessible.
During my exploration of the website’s functionalities, I stumbled upon the view receipt feature in the website, which accessed a PDF. I intercepted all the requests that the website was sending and discovered that it was using absolute system path to access that PDF. To my surprise, this functionality neither verified the session cookie nor imposed any restrictions. Seizing the opportunity, I attempted to access the “hosts” file located at “C:/WINDOWS/System32/drivers/etc/hosts,” which confirmed the presence of an LFI vulnerability.
Expanding the scope of LFI
Initially considering the LFI vulnerability to be low-risk, I decided to dig deeper. Using a Python script and a wordlist (found at https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt) I targeted files containing the strings “inetsrv” and “inetpub” on the windows system to look for sensitive files. This helped me to discover a file called “C:/Windows/System32/inetsrv/config/applicationHost.config,” which contained absolute paths of the “wwwroot” where the entire source code of the web application is stored along with other sensitive files like “web.config”. Then, I accessed the “web.config” file which contained a connection string with an IP address, along with username and password details that were used to connect to the database of the web application.
This meant that I could retrieve and even modify data from any table in the database of the web application by logging in to the MS SQL Server as an administrator. (I didn’t though)
Leveraging a Deserialization Flaw in Viewstate Tokens to get Remote Command Execution
Now, I started collecting more information about Viewstate tokens and I came across an article (https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/) in which I found out that if you get access to the ‘validationKey’ of the viewstate token from the ‘web.config’ file, you could create your own correctly signed viewstate tokens which would contain your own custom powershell or XML code that would execute arbitary system commands on the webserver because of an Insecure Deserialization vulnerability and potentially give you complete control of the webserver.
Insecure Deserialization is a vulnerability that arises when an application deserializes data from an untrusted or unauthenticated source without proper validation or sanitization. Deserialization is the process of converting serialized data, often in formats like JSON or XML, back into objects in programming languages.
When an application lacks proper security controls during the deserialization process, it becomes susceptible to Insecure Deserialization vulnerabilities. Attackers can exploit this vulnerability by modifying or crafting maliciously crafted serialized data to execute unauthorized code, tamper with objects, or manipulate the application’s behavior.
So, I obtained the validationKey from the web.config file.
And then, I used the Ysoserial.net tool to create a correctly signed Viewstate token that I can use to execute system commands on the webserver.
So, I am using the command “dir G:\inetpub\wwwroot\ > c:\windows\temp\test.txt” which will output a directory listing of the specified folder and save the output into the ‘c:\windows\temp\test.txt’ file.
Then, I replaced the Viewstate token in the ‘ChangePassword’ request (the one that I used to try changing passwords of other users) with my own custom Viewstate token and sent the request.
Although this resulted in a validation error, I was able to confirm the RCE (Remote Command Execution) vulnerability by accessing the file that I had created in my command using the LFI vulnerability.
In the above image, you can see that the command was successfully executed on the webserver and we can see the directory listing in the web server response.
Conclusion
My journey of finding my first bug in a real website was an eye-opening experience. Through discovering an LFI vulnerability, expanding its scope to get sensitive information like database credentials, and leveraging deserialization attacks, I uncovered a critical Remote Command Execution vulnerability. This journey highlights the importance of rigorous security measures in web development and the constant need for vulnerability testing. May this account inspire aspiring bug hunters and cybersecurity enthusiasts to embark on their own quests for knowledge and website security.
Note: Please refer to the provided links for detailed information and guidance on the referenced vulnerabilities and attack techniques.
https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/
