Saturday, September 28, 2024

MetaCTF ⚑ Write-Ups

 MetaCTF ⚑

Challenge categories: Web Exploitation

Challenge Name: Library

Challenge Link: https://compete.metactf.com/291/problems

Tools: Manually.

Challenge Description:

In this challenge, we are performing a penetration test on a small book library app built in the Go language that appears to exhibit some abnormal behaviour. The app is designed to process book requests, but certain endpoints return unexpected responses. The objective is to identify the root cause—whether it’s a coding bug, improper input validation, or potentially a security vulnerability in the request handling. This exercise will challenge your ability to analyze code logic and identify security flaws that could compromise the app's functionality or expose it to attacks.

The challenge description contained the source code download link with a live web application to perform the penetration testing.

Application Dashboard:

Open the provided link in the browser to access the library dashboard, where we can find a welcome message and a list of available books. You can also view the details of each book.

Source Code Review:

Download the application's source code using the given link in the challenge description.

The application source code file contained two “.html“ files and one “main.go” file, which contained all the backed code of the application.

The home.html file contains an HTML template snippet that is likely used in a Go (Golang) web application. It dynamically generates a list of books, with each book title rendered as a hyperlink. The syntax {{range .}} indicates the use of Go's templating engine, which is commonly used for web applications built using Go.

<home.html>

In the above image, the <ul> element creates an unordered list that will be dynamically populated with <li> (list items). The {{range.}} syntax is part of Go’s templating system and is used for iterating over a collection. The dot (.) represents the current context passed into the template, which in this case likely refers to a list of book objects. This indicates that the template expects to receive a slice or array of books, with each book being iterated over within the {{range.}} block.

In the range loop, a list item (<li>) is created for each book in the collection.

The <a href="/books?book={{.Param}}">{{.Title}}</a> tag adds a clickable link for each book. The link is used {{.Param}} as a query parameter, which is likely a unique ID or identifier for the book. Inside the link, {{.Title}} displays the book's title as clickable text.

The {{end}} marks the end of the {{range .}} loop, indicating where the iteration stops.

<book.html>

This HTML template is designed to display the content of a single book in a web application. It uses Go templating syntax to dynamically render the book's content inside the <p> tag.

In the above image, the <p> tag is used to display a paragraph of text. {{.}} is Go's template syntax, where the dot (.) refers to the current data passed to the template. In this case, it represents a string of book content. When the page loads, {{.}} will be replaced with the actual content of the book.

The Go file (main.go) is a simple web server application that provides book-related content via Go's HTTP package and templating engine. It defines a ReadBook structure with a method that reads a file's content and returns it as a string while handling any file reading errors.

The application stores a hardcoded map of books (books), with each key-value pair representing a book identifier and description. The application also includes two HTTP handlers: homeHandler, which generates a homepage listing available books using the home.html template, and bookHandler, which retrieves and displays individual book content based on the query parameter book using the book.html template.

<main.go>

Vulnerable Code: The provided Go code is vulnerable to Server-Side Template Injection (SSTI) in the bookHandler function. below the vulnerable part of the code.

This part of the code takes the book query parameter from the URL (userBook) and directly passes it to the template.New("book").Parse() function, without any sanitization or validation.

This can result in template injection if an attacker supplies malicious input through the book parameter. Since Go templates allow for the execution of code within {{ ... }} attacker could potentially inject arbitrary template code that gets executed on the server.

To get the flag from the server, we have to use the constructed below payload.

Payload: /books?book={{.ReadBook%20"flag.txt"}}

In this payload the {{.ReadBook "flag.txt"}} is a Go template syntax where .ReadBook refers to the ReadBook method defined in the application. The injected payload attempts to call the ReadBook method to read a file called "flag.tx".

Exploitation Part:

Step 1. Open the link given in the challenge description.

Step 2. Click on any list data and the URL contains the book parameter which is vulnerable to SSTI. 

Step 3: Inject the crafted payload on the book parameter for the flag.


Mitigation Part

To mitigate the SSTI risk:

Remove Dynamic Parsing: Never send user input directly to the template parser.

Validate Input: Use only predefined values (such as book IDs) in the template and reject any untrusted or unexpected entries.

Fixed Code for bookHandler function

func bookHandler(w http.ResponseWriter, r *http.Request) {
    userBook := r.URL.Query().Get("book")
    bookContent, validBook := books[userBook]

    if validBook {
        tmpl := template.Must(template.ParseFiles("templates/book.html"))
        tmpl.Execute(w, bookContent)
        return
    }

    http.Error(w, "No valid book specified", http.StatusBadRequest)
}

    • Removed Dynamic Template Parsing: The template.New("book").Parse(userBook) section has been removed to avoid processing untrusted input.
    • Only Predefined Books: The code now only renders templates for books that exist in the books map, preventing arbitrary template execution.

    Reference: Server-side template injection: https://portswigger.net/web-security/server-side-template-injection

    HackTricks: https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection#ssti-in-go

    Payatu : https://payatu.com/blog/ssti-in-golang/

    w3school : https://www.w3schools.com/go/

    _____________________________________________________________________
    Connect: LinkedIn: https://www.linkedin.com/in/sudeeplamsoge/

    Twitter : https://x.com/SudeepLamsoge

    Comments & Suggestions are always welcome. :)

    Share:

    Saturday, September 7, 2024

    In-depth analysis of CVE: PodcastGenerator 3.2.9—Blind SSRF via XML Injection.


    Application: Podcast Generator

    Vulnerable Version: v3.2.9

    Vulnerable version link: https://github.com/PodcastGenerator/PodcastGenerator/releases

    Vulnerability Description:

    Podcast Generator (PG) is an open-source content management system written in PHP, specifically designed for podcast publishing. It provides users with tools to easily manage all aspects of podcast publication, from uploading episodes to submitting them to the Podcast Index and iTunes store.

    In this write-up, we'll explore a Blind Server-Side Request Forgery (SSRF) via XML injection attack in depth, including a practical understanding of the source code and payload.

    Lab Setup:

    Download the vulnerable application from the provided link. We'll use a localhost XAMPP server for this demonstration.

    Download the XAMPP server: https://www.apachefriends.org/download.html

    1. Set up the Apache and MySQL servers using XAMPP.


    2. Unzip the downloaded Podcast Generator file to the server location:
      "C:\xampp\htdocs\<project name>".


    3. Open your web browser and navigate to the URL where you uploaded the Podcast Generator files (e.g., http://localhost:8080/PodcastGenerator).


    Source Code Analysis:

    After logging into the application, you'll notice a feature called "Upload New Episode".

    When adding a new episode, the application creates an XML file to store the data instead of using a database.

    Since the application uses an XML file for data storage, we can attempt an XML entity injection attack. Further analysis reveals that the application lacks input validation on its parameters.

    In the episodes_upload.php file, the $_POST['shortdesc'] function accesses data sent via an HTTP POST request from an HTML form, specifically the input named shortdesc (short description).

    The strlen() PHP function calculates the string length, checking if the short description exceeds 255 characters. However, the $_POST['shortdesc'] input is passed directly into the strlen() function without sanitization or validation, potentially exposing the application to cross-site scripting or injection attacks.

    Due to this lack of validation, we can perform an XML entity injection attack and escalate it to a blind SSRF attack. But first, let's understand what blind SSRF and XML entity injection attacks are.

    Blind SSRF:

    Blind SSRF vulnerabilities occur when an application makes a request to a back-end server, but the server's response isn't shown on the front-end.

    To detect a Blind SSRF attack, we can trigger an HTTP request to an external system under our control and monitor for network interactions, such as using Burp Suite Collaborator.

    XML Injection:

    XML entity injection, also known as XML External Entity (XXE) attack, involves an attacker interacting with the server using XML data.

    Some applications use XML format to exchange data between server and browser.

    Using an XML injection attack, an attacker can perform various actions, such as retrieving sensitive files or conducting an SSRF attack via XXE.

    Exploiting Blind SSRF:

    As the application creates an XML file to store data, we can exploit this vulnerability by injecting an XML payload.

    Payload:

    test]]></shortdescPG><imgPG path="">http://localhost:3132</imgPG><shortdescPG><![CDATA[test

    When adding normal data, the application stores the short description input value in the <![CDATA[]]> section.

    Note that the "testing" data is added to the CDATA section, and to balance the query, we must add the mentioned payload.

    The image below shows the difference between adding normal data and the payload, demonstrating how to balance the payload to exploit the blind SSRF attack.

    Payload Breakdown:

    test]]></shortdescPG><imgPG path=""><http://localhost:3132></imgPG><shortdescPG><![CDATA[test

    The <shortdescPG> tag uses CDATA, which likely just stores text and doesn't directly contribute to the SSRF.

    The key part of the payload is the URL http://localhost:3132 inside the <imgPG> tag. If the application processes this payload by taking the content between the <imgPG> tags and performs a server-side request (e.g., to fetch an image or resource), an attacker can exploit this by sending the server to a location under their control (such as localhost, internal services, or external servers).

    The URL http://localhost:2222 suggests the attacker is attempting to force the server to make a request to a local service on port 2222.

    Exploitation Part:

    Step 1. Log into the application using the URL:
    http://localhost:8080/PodcastGenerator/admin/

    Step 2. Navigate to "Upload New Episodes" under "Episodes".

    Step 3. Add the following payload to the short description parameter, with the listener on port 2222, then click save:

    payload:

    test]]></shortdescPG><imgPG path=""><http://localhost:2222></imgPG><shortdescPG><![CDATA[test

    Listen on the port using Netcat (NC) on port 2222

    Step 4. Open the submitted podcast data and observe the response from the server.

    WOOT!, We have successfully received the hit back from the server.

    Mitigation Part: 
    • Implement strict input validation and sanitization mechanisms to ensure that XML input from untrusted sources does not contain malicious content, including external entities.
    • Always utilize a strong database so that the input is validated from both the server and the client sides.
    • Ensure that all systems and applications are updated with the latest security patches offered by the vendor.
    Hope you understand the blind SSRF via XML injection in depth.

    Comments and suggestions are welcome.

    LinkedIn: https://www.linkedin.com/in/sudeeplamsoge/
    Twitter : https://x.com/SudeepLamsoge
     

    Share:

    Monday, September 2, 2024

    MetaCTF ⚑ Write-Ups

    MetaCTF ⚑ Write-Ups

    Challenge 3: Challenge categories: Web Exploitation

    Challenge Name: Login Query 

    Tools: Burp Suite.

    Challenge Description:

    In this challenge, we need to find the password for "jim404" without using a forgot password functionality. The challenge provides a source code link to help identify the loophole and bypass the login process.

    This challenge teaches us how to extract database information using SQL queries. As mentioned in the challenge description, it appears to be an SQL injection attack.

    Source Code Analysis:

    Download the source code using the link provided in the challenge description. Upon opening the source code files, you'll observe that they contain the login page (index.php) and (app.py), which houses the backend code for the login process. This CTF challenge is written in Python.

    The index.html file contained both the login page code and the JavaScript code. The JavaScript includes an asynchronous function called login() that manages the user login process on the webpage. This function communicates with a server to authenticate the user's credentials and updates the webpage based on the login's success or failure.

    Another file is app.py. This file contains the backend code used to manage the login process and validate the username and password with the database.

    Upon reviewing the code, it was observed that the application lacked proper validation for the username and password parameters. The SQL query is constructed by directly concatenating user input (username and password_hash) into the query string. This practice makes the application vulnerable to SQL injection attacks, allowing an attacker to manipulate the input and potentially execute arbitrary SQL commands.

    In the above image, the Python code is part of a Flask web application. It defines two routes ("/" and "/login") and handles requests to these routes. In the def Login() function, line 21 retrieves JSON data sent in the POST request body and stores it in the data variable. The next two lines extract the username and MD5 hash password.

    The SQL query is a particularly interesting part of this code. It selects the username, public_btc_address, private_btc_key, and balance from the users table. The query filters results based on matching username and password_hash values against the provided credentials.

    It’s observed that the application has not implemented any validation on username and password_hash parameters. Now, let's exploit this vulnerability using the information we've gathered.


    Challenge exploit:

    Open the given login page using the given URL in the challenge description.

    We use the Burp Suite tool to capture the requests.

    After intercepting the login request with the username "jim404" and a random password, we examine the response. The response reveals the entire SQL query along with a login failure error message.

    Breakdown the query:

    Query :

    SELECT username, public_btc_address, private_btc_key, balance FROM users WHERE username='admin' AND password_hash='0a1f508dd056bb8d1052ec6a6cb5b8b3';

    The query is designed to retrieve the username, public_btc_address, private_btc_key, and balance from the users table for the user whose username is 'admin' and whose password_hash matches the provided hash ('0a1f508dd056bb8d1052ec6a6cb5b8b3').

    To verify the username parameter's vulnerability to SQL injection, we employed the query ' or '1' = '1';--. This is a common technique used to exploit SQL injection vulnerabilities. Its most potent effect is when it successfully bypasses authentication controls.

    In this scenario, the input ' OR '1'='1' can bypass the authentication check because '1'='1' always evaluates to true. This could potentially lead to the retrieval of all records in the users table. Additionally, the double dash (-- ) signifies an SQL comment which causes the SQL query to ignore the remaining part of the query, including the password check.

    SELECT username, public_btc_address, private_btc_key, balance FROM users WHERE username='' OR '1'='1'; --' AND password_hash='d41d8cd98f00b204e9800998ecf8427e';

    The "username" parameter is closed and then a "or" statement is used. This means that if the "username" parameter is not true, then the condition "1=1" is always true. After that, a semicolon is used to end the query, followed by double hyphens to comment out the remaining part of the query.

    Once we successfully bypass the authentication process, only the admin data is shown, but we need the "jim404" user account to get the flag.

    To exploit the SQL injection for the jim404 user, we are using a UNION-based SQL injection attack.

    The UNION operator allows you to combine the results of two or more SELECT statements into a single result set.

    • Each SELECT statement within the UNION must have the same number of columns in the result set with the same data types in corresponding columns.
    • The columns in each SELECT statement must be in the same order.

    Craft the payload using the query:

    Payload:

    jim404' UNION ALL select null, null, null, password_hash from users ;--

    Final Query:

    SELECT username, public_btc_address, private_btc_key, balance FROM users WHERE username=''jim404' UNION ALL select null, null, null, password_hash from users ;--' AND password_hash='d41d8cd98f00b204e9800998ecf8427e';

    To find the password_hash for the user jim404, use the UNION ALL function to concatenate all the strings and get all the data

    • jim404': This is the part of the username parameter that closes the existing username string in the original SQL query. If the original query uses a single quote (') to wrap the username, the attacker's input will terminate the string.
    • UNION ALL: Combines the results of two SELECT statements. UNION ALL includes duplicate rows, whereas UNION would remove them.
    • SELECT null, null, null, password_hash FROM users: This is the injected SELECT statement. It selects three null values followed by the password_hash from the users table.
    • ;--: The semicolon (;) ends the original query, and -- is a comment that ignores the rest of the original query. Everything after - is treated as a comment by the SQL engine, effectively removing the password check in the original query.


    WOOT, successfully get the FLAG for the “jim404” account.

    Reference :

    Mitigation:

    • Use parameterized queries or prepared statements.
    • Properly sanitize all the user-submitted values used in the query before using them.
    • Disallow common characters used in SQL Injection payloads, such as the characters “<>/?*()&” and common SQL operations like SELECT and UPDATE.

    Share:

    Thursday, August 22, 2024

    MetaCTF ⚑ Write-Ups

    MetaCTF ⚑ Write-Ups

    Challenge 2

    Challenge categories: Web exploitation

    Challenge Name: Direct Login

    Challenge Information

    This challenge involves a PDF file containing hidden information. While PDFs are commonly used in organizations, many are unfamiliar with the potential for information disclosure through these files.

    The challenge description provides information about the PDF file and details about the challenge itself.

    Download the music producer's (D34DM0053) open letter by clicking the provided link.

    After downloading and reviewing the letter, it was observed that it doesn't contain any sensitive information about the producer's identity.

    The letter doesn't contain any flags or sensitive information, so the only thing left to examine is the Exif data in the file.

    EXIF (Exchangeable Image File Format) metadata is additional information embedded in files such as images, PDFs, etc. It's commonly found in photos taken by digital cameras, smartphones, and other imaging devices.

    EXIF data contains the following key information embedded in files:

    • camera Settings information
    • Image Information
    • Geolocation Data
    • Thumbnail
    • software information
    • device information

    To extract the metadata from the file, we'll use ExifTool.

    ExifTool is a free, open-source program that reads, writes, and manipulates metadata in images, audio files, videos, and PDFs.

    To install ExifTool, use the following command:

    Command: “sudo apt install libimage-exiftool-perl”

    After installing ExifTool, use the following command to view the PDF file's metadata:

    Command: “exiftool <filename.pdf>”

    Upon examination, you'll notice that the Author field contains the flag value.

    To address this type of vulnerability, consider the following points:

    • It is recommended to strip all metadata from the image once it is uploaded into the application.


    Share:

    MetaCTF ⚑ Write-Ups

    MetaCTF ⚑ Write-Ups

    Challenge 1

    Challenge categories: Web exploitation

    Challenge Name: Direct Login

    Challenge Information

    In this CTF challenge, you have to access the protected employee portal without knowing the password and steal the flag. In the description, they have provided a URL and some information about the challenge.

    Clicking on the provided link will take you to the ConnectWind internal employee portal, where you will find the employee login page.

    If you observed the name of this CTF challenge, direct login indicates that you have unauthenticated access to the employment portal

    After attempting to run the directory brute forcing attack on the URL, it was discovered that the application was unable to access the directory and displayed a Not Found error.



    After reviewing the source code of the employee login page, it was discovered that JS code is used to authenticate the login process. In the below image, you can notice line No.66 of the code, the "window.location.href" property of JS is used to redirect users to the directory "./employee_portel.php" after successful login.


    Now that we have the directory name, we can modify the URL to access it directly. By doing so, we successfully gained access to the employee portal and obtained the FLAG.


    Successfully get the FALG.

    To address this type of vulnerability, consider the following points:

    • The application should implement a robust authentication mechanism.
    • The application should validate URLs before redirecting users.
    • The application should not disclose internal directories publicly.

    Simply done… :)

    Share: