Showing posts with label owasp. Show all posts
Showing posts with label owasp. Show all posts

Thursday, June 8, 2023


Important Note: All of the findings listed here were previously reported to the manufacturer of the software.

As part of the responsible disclosure policy, we waited for a response of the manufacturer (confirming the vulnerability, issuing a patch, or accepting that they won't solve the finding) before sharing this post.


Introduction

During a Penetration Test performed to a Security Company I was able to identify certain findings that could affect the popular Thruk Monitoring Web Interface. So, after analyzing the GitHub repository and performing some tests on the target environment, I was able to identify and exploit the vulnerabilities, then I reported these issues to the manufacturer.


Summary

The file panorama.pm is vulnerable to a Path Traversal Vulnerability which allows a remote authenticated attacker to upload arbitrary files to any folder which has write permissions on the affected system. This vulnerability affects all versions of Thruk even the one that was recently published (<=3.06) in May 24, 2023.


Details

The parameter "location" is not filtered, validated or sanitized and it accepts any kind of characters. For a path traversal attack, the only characters required were the dot (.) and the slash (/).

This was verified by analyzing in detail the GitHub repository and the source files.

In this step, the location is received from the parameters sent by the client through the web request and there is no sanitization at all.

Then, the variable folder is constructed doing a basic concatenation without any sanitization.

Next, the folder variable is concatenated with the filename and its result is stored in the newlocation variable, again no sanitization at all.

Finally, here the uploaded file is moved to the desired folder.


Through this flow, it is easy to see that due to the lack of sanitization we can manipulate the location parameter and exploit a Path Traversal vulnerability to upload a file to any folder we want.


Proof of Concept (PoC)

  1. Go to the form where we can upload an image that will be used as background for a Dashboard.
  2. Select any file with the allowed extensions and intercept the request with Burp Suite.
  3. Modify the location parameter which is the backgrounds/ string and replace it with something like backgrounds/../../../../tmp/
  4. You will receive a message that the file was uploaded successfully.
  5. Check your /tmp/ folder and verify the presence of the file.
As part of the PoC, I decided to include the following screenshots.

Normal Case

In this first screenshot I included the normal request where a file will be uploaded to a folder where the current user does not have any write permissions, and I received an error message.


Path Traversal Exploitation

In this second screenshot I included the manipulated request where the path traversal vulnerability is being exploited to upload the file to /tmp/ folder, as you can see I received a success message.


CVSS

The NIST NVD assigned a CVSS 3.1 Score of 8.8 (High) to this vulnerability.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

The CNA GitHub, Inc. assigned a CVSS 3.1 Score of 6.5 (Medium) to this vulnerability.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Check NIST NVD for further details.

Impact

A Path Traversal vulnerability allows an attacker to upload arbitrary files to the server. The attacker can overwrite existing files on the system and cause a defacement (replacing legitimate images on the web server) or simply can upload random files to fill the disk completely and affect the availability and correct status of the platform.

It is well known that a Path Traversal Vulnerability in certain cases can allow an attacker to upload a webshell and gain Remote Code Execution (RCE) on the affected host, which could lead to a Complete System Takeover.

This vulnerability affects all versions of Thruk even the one that was published 15 days ago (3.06) in May 24, 2023; so the impact is bigger as this issue affects all instances of Thruk around the world.

This was reported through a Security Advisory via GitHub. You can find the security advisory report and other useful references in the following links:

  1. https://github.com/sni/Thruk/security/advisories/GHSA-vhqc-649h-994h
  2. https://github.com/galoget/Thruk-CVE-2023-34096
  3. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34096
  4. https://www.exploit-db.com/exploits/51509
  5. https://packetstormsecurity.com/files/172822/Thruk-Monitoring-Web-Interface-3.06-Path-Traversal.html
  6. https://nvd.nist.gov/vuln/detail/CVE-2023-34096
  7. https://cve.report/CVE-2023-34096
  8. https://vulmon.com/vulnerabilitydetails?qid=CVE-2023-34096&scoretype=cvssv3
  9. https://vuldb.com/?id.231110
  10. https://twitter.com/CVEnew/status/1666897976894054415
  11. https://www.thruk.org/changelog.html#_v3-062

Vulnerability Summary

  • Assigned CVE: CVE-2023-34096
  • CVE Author: Galoget Latorre (@galoget)
  • Severity (NIST): 8.8 High
  • Severity (GitHub): 6.5 Medium
  • Type: Path Traversal
  • Product: Thruk Monitoring Web Interface
  • Affected Versions: All versions <= 3.06
  • Patched Version: 3.06-2

Timeline

  • 2023-05-25: This vulnerability was identified by Galoget Latorre.
  • 2023-06-02: Initial contact with maintainer via GitHub Security Advisory including vulnerability details and Proof of Concept (PoC).
  • 2023-06-05: CVE-2023-34096 is assigned. 
  • 2023-06-06: Maintainer releases a patch with version 3.06-2, see Thruk's Changelog.
  • 2023-06-08: GitHub Security Advisory is released by maintainer.
  • 2023-06-08: Security advisory (this blog post) is released by Galoget Latorre.
  • 2023-06-08: Exploit PoC is released by Galoget Latorre.
  • 2023-06-09: Exploit PoC is shared by Exploit Database (Exploit-DB).
  • 2023-06-09: Exploit PoC is shared by Packet Storm Security.

Credits

This security vulnerability was identified by Galoget Latorre, Security Consultant (Pentester) at Hackem Cybersecurity Research Group and Dreamlab Technologies.

Monday, January 8, 2018



Recently on Security StackExchange, I saw a lot of people asking how to use properly THC Hydra for Password Cracking, so in this post I'm going to explain how to install the command line utility, and also how to install the graphical user interface (GUI) for it. Then you can find step by step instructions on how to use this tool properly to attack an http-form-post that simulates a Login form for a corporate website. Hope you enjoy this post as much as I did when I was writing it.

Monday, December 4, 2017


A few days ago, we received an invitation to the BlitzCTF001, a very short and fast cybersecurity CTF. The challenges contained in this CTF covers: Crypto (Encoding), SQLi, Broken Access Control, Session Manipulation and Steganography.

In our opinion, the challenges are interesting and entertaining, especially to learn about web application security, so we decided to share the solutions (just in case that you got stuck in some level), hope you like and enjoy them as we did.

Wednesday, April 3, 2013


In this post I want to share one of the most popular attacks that are used in web applications, so let's start:

"Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page." - OWASP XSS -

For this practice, I am going to create a scenario that is vulnerable to this attack, first you need to set up a web server that supports PHP, the easiest way is downloading XAMPP (Avaliable for all Platforms).

To test if your web server is up, in a new tab you need to go to: http://localhost/

If all is OK, you will see an image that requests you to select a language, after you choose your language, the main page is shown and it looks like this:

Figure 1: XAMPP Started on GNU/Linux

If you used a web server before, you probably know that you need to move all your website to an specific directory, in this case "htdocs" directory in order to test your files in your browser.

In this exercise, for people that is starting in web development, I am going to create a file "color.php" with a Hello World message, so the code inside this file would be:

<?php
    echo 'Hello World';
?>

In order to test this file you need to go to the URL: http://localhost/color.php
And the output of this file should be something similar to Figure 2.
Figure 2: Hello World in PHP using XAMPP on GNU/Linux

Now that all is working, I am going to explain what I am going to do with this color.php file:
Scenario: Suppose you are a web developer, and you create websites for people, in your personal site, you have a short demo where people can choose a background color in the page that is shown to them, this is only to see if the color it is OK for your client. All the code for this file (color.php) it is not included in this post, but you can imagine how it works, hehehe.

Hint 1 (how the requests are sent?): <form method="post" action="">
Hint 2 (what is the background color code?): <body><center>

After you have finished your color.php file, you can test if it works correctly, for my example please refer to Figure 3, depending of how you coded it, it could be very similar to my file:
Figure 3: Color.php File working on XAMPP

How this web app works?
Really simple, you need to choose your color, then press the button and the background color will change depending of your selection, for example if I choose the yellow color and after that I press the button, my web app will show me the background with that color, see Figure 4.
Figure 4: My Web App with the background color changed

So now, how can we exploit this vulnerability (XSS) on the Demo website?, really simple, you need to capture the requests that are sent to the server and modify them.

For that purpose, you can use a Proxy tool, like OWASP ZAP 2.0, or an Add-on for your favorite browser as you prefer.

After I sent my request (without any modification), what are the changes on the web app?
The background color code: <body bgcolor="yellow"><center>

With this information an attacker can image how this web application works and then how to modify the request to get an XSS, showing an alert message.

In the Figure 5, you can see a tool that is used to modify the information that is generated by a request, the injection of code is made in the color box, where I wrote javacript code to show an alert message that says "\Hackem Research Group\".
Figure 5: Tool where you can edit the request

After you finished the edition of the request, you can send it to the server, and the response is a pretty XSS, as shown in Figure 6.
Figure 6: Alert message shown in the page, means that this web app is really vulnerable...

This is not only limited to an alert message, you can submit forms, or any kind of element, for example, you can inject code to show a login form, if a banking site is vulnerable to this attack, an malicious programmer can steal login credentials from the original website when people fill the fake form that were injected by XSS.