Blog Post

The Human Connection Blog
4 MIN READ

Human Connection Challenge Lab 6: Thick Client Applications Walkthrough Guide (Community Version)

StefanApostol's avatar
3 days ago

Time’s Up! Congratulations to everyone who completed Lab 6: Thick Client Applications from the Human Connection Challenge: Season 1.

In this walkthrough, I'll share some strategies for efficiently completing the lab based on my perspective as the author. Remember, there are often multiple ways to approach a challenge, so if you used a different method and succeeded, that's perfectly fine!

This challenge has now ended, but the lab remains available for practice. While prizes are no longer up for grabs, you can still complete the lab and use this walkthrough guide for support if needed.

Throughout this walkthrough, placeholders will be used for target IPs in brackets, such as <Kali IP>, <API IP>, or <Thick Client IP>. Simply replace this with the actual IP of your Kali instance or the specific target.

Let's get started!

Begin this challenge by setting up your Thick Client application with the API’s IP address. Go to the Remote Data Browser folder , right-click configuration.conf, then click Open with Notepad, and replace the original <IP:5000> with <API IP> or <API IP:80>.

Task 1

Task 1 requires you to input a token that you’re meant to receive after you first log in to the Remote Data Browser application with the username and password provided in the Credentials panel.

However, after logging in, the application doesn’t present any token.

Under normal circumstances, when testing Thick Client applications, you’d have tools like ProcMon running while using the application to check for interactions with the file and operating system.

In this lab, however, you can simply go back to the Remote Data Browser application’s folder. You’ll see that a token file has been created. Open it to find the token.

Task 2

The second task asks for an admin token. However, you can’t access any admin panel through the application’s interface, meaning the role is set on login.

First, open Burp Suite Community on your Thick Client machine. Then, set your System Proxy as follows:

  • Go to Proxy settings > Manual proxy setup
  • Toggle Use a proxy server to "on"
  • Set the IP address as 127.0.0.1
  • Set the port as 8080

After everything is set up, turn on the Intercept feature of Burp Suite and log back into the application.

On the login request, right click anywhere in the request panel and click Do intercept > Response to this request.

This will result in a successful authentication response. It contains a JWT token that can be used in subsequent requests, the username that was used, and the current user’s role.

From the response, you can assume that the API doesn’t tie the role to the session and instead sends it as a parameter to the application. The application then evaluates the role and presents the user with the appropriate panels. Now you can change the role in the response from user to admin.

This will reveal a token in the Remote Data Browser application.

Task 3

The final task asks for “the secret token in management”. Again, the application doesn’t offer this option.

Clicking any of the vehicles, however, results in a Burp Suite request. The application sends this request to the server when selecting the truck option, along with the JWT received during the login phase.

Since the vehicle parameter is the only one, you should focus on it for your final challenge.

Adding an extra quote (‘) to the vehicle parameter returns the error “SQL query failed”.

You can now safely assume this is vulnerable to SQL injection. Copy the original request into a file, retrieve.sqlmap, in your Kali box, and run sqlmap as follows:

sqlmap -l retrieve.sqlmap --dump

After hitting ENTER a few times (accepting SQLmap’s default options), you’ll be presented with your final token.

Tools

For this challenge, you’ll use a range of tools including:

  • Burp Suite
  • SQLMap
  • Kali

Tips

When testing for Thick Client application vulnerabilities, remember that vulnerabilities may reside in any part of the application. Subtle elements that appear unimportant could prove exploitable if they don’t handle inputs securely. So make sure you check all user input forms and any buttons that direct you to different parts of the application. Although not required for this lab, you should always monitor operating and file system interactions and attempt to decompile the app to uncover all possible attack vectors.

To learn more about some of the tools used in this lab, take a look at the following collections:

  • Windows Basics
  • Burp Suite Basics
  • SQL Injection

Conclusion

The steps I’ve laid out here aren’t the only way to find the answers to the questions. As long as you find the answers, you did it – well done!

If you used an alternative method, or think there’s a better route to find some of the answers, let us and the rest of the community know in the comments below!

I hope you enjoyed the challenge and are looking forward to the next one, after which I’ll share another walkthrough guide!

Updated 3 days ago
Version 3.0

4 Comments

  • not sure if it would be „sqlmap -r“ instead of „-l“. As -r would be for the request itself and -l to generate the request out of logfiles. I need to check if this works too, id so: I learned something new :)

  • "Although not required for this lab, you should always monitor operating and file system interactions and attempt to decompile the app to uncover all possible attack vectors." - Well, yes: Why didn't we have access to tools for static and dynamic analysis?

    That way it would be possible to get the first two tokens, without connecting to the target. 

    • StefanApostol's avatar
      StefanApostol
      Icon for Immerser rankImmerser

      I wanted this challenge to be more about the communication than static/dynamic analysis.

  • Ahh SQLMAP, i just used the repeater and manual SQL Injection. This could of saved me time. How simple the walkthrough made it sound. Great work was real fun.