Weather App: HTB Web Challenge (Retired)

I had a bad day yesterday (April 11, 2023), so I was back again on HTB to have some fun. In this blog I will be writing up the walkthrough of the Weather App challenge from HTB.

So, this challenge allows us to download the source code of the application in order to perform a static analysis. Nice Right?

Overview

There is a SSRF vulnerability in the application which allows us to bypass the host validation in order to perform a SQL Injection and retrieving the flag.

Source Code Analysis

Open up the database.js file from the source code. Observe that the user supplied username and password is directly concatenated in the SQL query. This can allow a SQL Injection in the application during registration.

Was so easy to point this out

I also found out that the registration is only possible through the local machine of the application and can’t be done remotely (code snippet from the index.js file).

How is the founder supposed to monetize this application?

The application also checks if the logged in user is Admin or not. If the user is Admin only then the flag will be shown.

Are you the Admin?

It was also found that the version of Node used was outdated and had CVE-2018–12116 associated to it. This version of Node JS is vulnerable to a Response Splitting attack.

A06:2021

Dynamic Analysis

Start the instance of the application from HTB.

The application has a pretty nice interface, shows up the weather at my location.

Wait! My location?

Let’s check out the undergoing requests through burp.

The application sends out the name of my City to a different domain and prints out the weather response that is received from there.

Guess the possible vulnerability that can arise here

There could be an SSRF here. I checked it through an instance of interact.sh and I got an HTTP hit on it.

No, I don’t live in Chicago

Had a hit on interact.sh

This is okay, but how to get the flag now?

I had no idea how to proceed now. Then, I remembered about the registration process that I mentioned above in the blog.

Quick Recap

The application allows the registration of a new user to be done through the local machine (on which the application is hosted). This registration functionality is rigged by a SQL Injection. We also have an SSRF on the application. The SSRF can be used to make a registration request on the application. The version of Node JS used by the application is affected by a response splitting attack. Also, the flag can only be fetched by the admin user and not by any other standard user.

So, I can send a registration request through SSRF and add a SQL query in the request to change the password of the admin user and can now log in to claim the flag. But, a POST method based registration request cannot be sent through SSRF. For this, I can use the response splitting attack to send a POST request.

FUN RIGHT?

I like Chandler more

So, we do the same as written above.

After a lot of trial and error in writing the payload (SSRF + Response Splitting + SQL Injection). I came up with the below payload:

127.0.0.1/\u0120HTTP/1.1\u010d\u010aHost:\u0120127.0.0.1\u010d\u010a\u010d\u010aPOST\u0120/register\u0120HTTP/1.1\u010d\u010aHost:\u0120127.0.0.1\u010d\u010aContent-Type:\u0120application/x-www-form-urlencoded\u010d\u010aContent-Length:\u012093\u010d\u010a\u010d\u010ausername=admin&password=123%27)\u0120ON\u0120CONFLICT(username)\u0120DO\u0120UPDATE\u0120SET\u0120password\u0120=\u0120%27admin%27;--\u010d\u010a\u010d\u010aGET\u0120/hello?

I was able to write this exploit payload thanks to this blog.

SSRF + Response Splitting + SQLi to Account Takeover

We can now login to the application with the credentials admin:admin

The flag was found just after logging in as the admin

The SQL Injection issue in the application originated because the user input was concatenated in the backend SQL code without any sanitization. This could have been easily avoided by the usage of parameterized queries.

The SSRF issue originated because of the user controlled URL passed in the request. This is a very bad practice and should be avoided at all costs. If still required to implement, then only a handful of whitelisted URLs should be processed by the backend code to send an HTTP query.

Atlast, the known vulnerability can easily be fixed just by updating the Node Implementation to the latest version.

Conclusion

The HTB Weather App challenge is an excellent hands-on experience in web application security. It underscores the importance of keeping software updated, secure coding practices, and regular security audits. This challenge serves as a practical approach to understanding and mitigating security vulnerabilities.

Lets get in touch: Add me on Linkedin.