Hack The Box Lab: Unveiling Bike

Starting Point — Tier 1— Bike Lab

As we continue our exploration of cybersecurity challenges, we find ourselves in the “Bike” lab on Hack The Box (HTB). This lab presents interesting tasks that will test and enhance your penetration testing skills. For those who are new to this field, this journey will provide a solid foundation. Our goal is to gradually build up on the difficulty level and provide you with the necessary details, without being too elaborate.

Lab Overview

• Target IP: target_IP (Remember to replace target_IP with the respective IP of the target machine.)

In this lab, we will delve into the following questions and tasks:

1. Task 1: What TCP ports does Nmap identify as open? Answer with a list of ports separated by commas with no spaces, from low to high.
2. Task 2: What software is running the service listening on the http/web port identified in the first question?
3. Task 3: What is the name of the Web Framework according to Wappalyzer?
4. Task 4: What is the name of the vulnerability we test for by submitting {{7*7}}?
5. Task 5: What is the name of the templating engine being used within Node.js?
6. Task 6: What is the name of the BurpSuite tab used to encode text?
7. Task 7: In order to send special characters in our payload in an HTTP request, we’ll encode the payload. What type of encoding do we use?
8. Task 8: When we use a payload from HackTricks to try to run system commands, we get an error back. What is “not defined” in the response error?
9. Task 9: What variable is the name of the top-level scope in Node.js?
10. Task 10: By exploiting this vulnerability, we get command execution as the user the webserver runs as. What is the name of that user?
11. Task 11: Submit root flag

The answers to these questions (except for tasks where hints are provided, including the root flag) will be highlighted in bold and italic for your convenience.

Task 1: Exploring Open Ports

Our journey begins with a simple Nmap scan. To find the open TCP ports, we run the command nmap -sV -p- target_IP, scanning all 65535 ports while enabling version detection. The result Nmap output is the following:

Open TCP ports

Open TCP ports: 22,80

Task 2: Unveiling Web Services

As we continue our exploration, our focus shifts to the software behind the web port (port 80) we uncovered earlier. Based on the scan results, the answer is straightforward:

Web Service Software: Node.js

Node.js is an open-source, cross-platform, back-end JavaScript runtime environment. It serves as a great tool for building scalable network applications.

Task 3: Web Framework Revelation

To undercover the web framework in use, we turn to the Wappalyzer browser plugin, a handy tool for revealing the technologies behind websites. Wappalyzer can be used to detect content management systems, eCommerce platforms, web servers, JavaScript frameworks, analytics tools and much more.

Our journey involves visiting the target website using our browser at http://target_IP.

Website content of http://target_IP

Wappalyzer output for http://target_IP

After inspecting the site with Wappalyzer, we uncover the detail:

Web Framework Detected: Express.

Express is a minimal and flexible Node.js web application framework. This framework equips developers with a robust set of features for web and mobile applications.

Task 4: Uncovering Vulnerabilities

Upon visiting the webpage at http://target_IP, it becomes evident the site is currently under construction. To keep users informated about the page’s progress, a subscription form is available, where users can leave their email. Let’s investigate this form using different inputs in the Email field:

1. When we submit the email address test@test.com, the page refrehses, and a message appears below the subscription form, stating, "We will contact you at: test@test.com". This behavior suggests that the input provided in the email field is reflected back to the user after a page reload. This could potentially indicate a Cross Site Scripting (XSS) vulnerability.
2. Our attempt to inject the payload <script>alert(1)</script> to test for XSS vulnerability was unsuccessful. This suggests that the underlying website may not be vulnerable to XSS attacks.
3. Interestingly, when submitting the input {{7*7}}, an error occured displaying “Error: Parse error on line: ….”. As described in Hacktricks, this input serves as a common payload used to differentiate a Server Side Template Injection (SSTI) vulnerability from an XSS vulnerability. In cases where an SSTI vulnerability exists, the web server will detect this expression as valid code and attempt to execute it. In our scenario, this translates to the mathematical equation 7*7. However, due to an invalid data type, instead of evaluating the expression and producing the expected result of 49, an error is triggered. Nevertheless, the behavior indicates a potential SSTI vulnerability.

Using the input {{7*7}} in the Email field.

Error when submitting {{7*7}} in the Email field.

Task 5: Identifying the Template Engine

The error we encountered in Task 4 reveals two valuable pieces of information.

1. The web server seems to run from the /root/Backend directory.
2. The template engine in use is Handlebars.

These two points offer additional insights that go beyond what Wappalyzer provided, giving a deeper understanding of the website’s architecture and technology stack.

Task 6 & 7: Exploring Payloads with BurpSuite and Encoding for HTTP Requests

In Hacktricks, payloads are provided that can be used to potentially run commands on a Handlebars SSTI. To test these payloads, BurpSuite allows us to capture POST requests and edit them to include our own payloads. For instance, in Hacktricks, we find the following payload, we may want to use for SSTI:

Hacktricks payload

Pay close attention to the line:

This line instructs the server to execute the whoami command, revealing the currently logged-in user. In subsequent tasks, we may customize this line to meet our specific objectives. However, to transmit this payload correctly to the server, we must encode it.

Specifically, when sending data to a web server, the transmitted content must adhere to the standard 128-character ASCII set. Reserved characters outside this set require encoding. Here, we employ URL Encoding, where, for example, the reserved character & becomes %26. BurpSuite simplifies this process with a built-in URL encoder and decoder, accessible within the "Decoder" tab.

The screenshot below illustrates the URL-encoded version of the Hacktricks payload, demonstrating the encoding process performed by BurpSuite:

URL encoding with BurpSuite accessible via the Decoder tab

URL encoding ensures our payloads are properly formatted for HTTP requests, allowing us to interact with the server effectively.

Task 8: Overcoming Errors

We utilize BurpSuite’s Repeater, accessible via the Repeater tab, to modify the POST request generated when we submit the email subscription form. The process involves copying the URL-encoded payload from BurpSuite’s Decoder tab and pasting it into the email= field within the request tab of BurpSuite's Repeater, as depicted below:

Modified POST request with URL-encoded Hacktricks payload in the email= field

To initiate the request, we simply click the orange “Send” button at the top. The resulting response is displayed below:

Response of modified POST request in BurpSuite’s Repeater tab

Notably, we encounter an error message reading “ReferenceError: require is not defined…”. This error stems from the specific line of code:

This portion of the payload appears to be the source of the error. In JavaScript, and particularly in Node.js, require is a keyword used for loading code from other modules or files. In the provided code, it's attempting to load the "child_process" module into memory to execute system commands (in this case, whoami).

However, template engines like Handlebars often run in a sandboxed environment. This means that their code operates within restricted boundaries to prevent the execution of malicious code or the loading of modules that can run system commands. Consequently, using require to load such modules directly may not be possible. Task 9 will explore alternative methods to achieve our objectives.

Task 9: The Global Variable

Upon consulting the Node.js documentation, we discover that objects like require and __dirname may seem globally accessible but are, in fact, confined to the scope of Node.js modules. (Answer Task 9: Global) As a result, they are not accessible in certain situations, such as ours. Fortunately, we find an alternative solution in the documentation: “the process.mainModule property provides an alternative way of retrieving require.main” (refer to the specific documentation about process).

By modifying the code line from

to

and subsequently URL encoding the entire adjusted payload, we can submit the request in BurpSuite’s repeater without encountering errors since the process object is indeed available.

Taking our modifications further, we extend the code line to:

With these adjustments in place, we observe from the response, as shown below, that the output of whoami is now root.

HTTP response based on modified payload

Task 10: Elevated Privileges

As evident from the screenshot above, running the whoami command reveals that the currently logged-in user is root.

Task 11: Capturing the Root Flag

The final task is to submit the root flag. We achieve this by modifying our payload to locate and display the contents of the flag.txt file. The unexperienced users of the Linux command line, we advise to have a look at our article on the very basics of the Linux command line.

First, we list all files in /root directory, by adjusting the code line of the payload to:

The respective response is shown below:

Response of modified POST request to locate the flag.txt file

The flag.txt is located in /root directory. We output the content of flag.txt by the cat command, i.e., we adjust the payload code line to:

Conclusion

The “Bike” lab on Hack The Box’s Tier 1 offers an instructive journey through various aspects of web application security. We’ve explored Nmap for port scanning, identified web service software like Node.js, delved into web frameworks like Express, and even encountered vulnerabilities like Server-Side Template Injection (SSTI). Through practical exercises in BurpSuite, we learned about encoding techniques and how to overcome challenges posed by sandboxed environments.

This lab showcases the importance of thorough reconnaissance and creative problem-solving when it comes to web application security. Remember to replace target_IP with the specific IP address of your target machine. Keep exploring, learning, and honing your skills in the fascinating world of cybersecurity!

Thanks for reading! If you want to learn more about Ethical Hacking, please subscribe to this blog. We will constantly be posting articles to help you start your cyber security journey as an ethical hacker!