Hack the Box Business CTF 2022 Challenge 1 - PhishTale
Find out how we performed in Capture the Flag during Hack the Box 2022, as our pen testers showed off their skills in the web app PhishTale Challenge.
Introduction
Recently, Bulletproof’s pen testers participated in the Hack the Box Business CTF 2022 competition. This was a global InfoSec contest that pitted cyber security teams against one another in a series of hacking challenges, based on real-world vulnerabilities.
There were 8 categories which included challenges of varying skill levels for teams to apply their hacking expertise to ‘capture the flag’. To complete each challenge, teams had to find a way to exploit a weakness, or a series of vulnerabilities, in order to capture the flag.
In this blog, we focus on PhishTale – a challenge based on finding and exploiting vulnerabilities in a web application. We explain what the challenge entailed and how our team successfully solved this task. So, without further ado, let's begin!
Share this Article
Challenge 1: PhishTale
Prior to each challenge, players receive a description of the task. This may include a subtle suggestion to guide teams, such as the use of the HTTP/2 protocol to exploit a vulnerability.
The difficulty level for this challenge was set as Moderate. However, only 24 out of 656 companies managed to successfully capture the flag, including our team.
Here’s what we had to do:
Recently we identified a host matching a threat actor's TLS certificate facing the public internet. It contains an open-source phishing kit builder, so we have the source of the application at hand. We need you to get access to their server so that we can uncover their campaigns.
Note: The host uses an HTTP/2 protocol with a self-signed certificate, so you must visit the host with the https:// protocol and accept the self-signed certificate to access.
The description of the challenge mentioned that the host uses the HTTP/2 protocol. This was an indication that one of the vulnerabilities we had to exploit would require the utilisation of the HTTP/2 protocol. Teams were also given the files to accompany the PhishTale challenge, which made it easier to analyse and debug.
Step 1: Setting up the environment
To begin with, certain files had been provided to each team in order to run the challenge locally on their machines, to investigate the task further.
By running the provided shell script, we were able to build the docker image and run the application.
After running the application, we were greeted with the login page.
Step 2: Enumeration
Access to the application was gained by providing the almighty admin:admin credentials. The credentials were hardcoded in the application's files (/challenge/.env).
If they were not, they could've been brute forced using various tools. However, in this case we found the credentials by following a trial-and-error approach.
Once we gained access to the application, we noticed that it was a phishing framework that could be used to create phishing campaigns.
The application also had export functionality. However, this could only be used via localhost.
However, it could also be verified by looking at the /config/default.vcl file, which is a configuration file for Varnish. Varnish Cache is essentially a reverse proxy for caching HTTP.
By analysing the provided Dockerfile, we noticed that the Varnish version used by the application was outdated and affected by a request smuggling vulnerability (CVE-2021-36740). Based on publicly available information, when HTTP/2 is enabled, an attacker could bypass Varnish Configuration Language (VCL) access controls by sending a large Content-Length header as part of an HTTP POST request. This made sense as the challenge description contains a note regarding the utilisation of HTTP/2.
The payload, shown in the screenshot below, was then used to verify the existence of the request smuggling vulnerability.
By monitoring the web server logs, we observed that our request was smuggled.
Step 3: Exploitation phase
During the exploitation phase, we needed to craft a payload in order to bypass the Access Control Lists (ACL) that were enforced by Varnish. Then, we needed to use the application’s export functionality to generate and export a phishing campaign.
Please note that the value of the PHPSESSID session cookie should be valid for the request to be processed by the application.
The final payload is shown below:
By analysing the web server logs, we could see that our request was smuggled, and the application responded with a 302 redirect.
The next step was to find the location of the generated phishing template. This was achieved by analysing the files provided, as shown below:
After identifying the location of the phishing template as /static/exports/phishtale.zip, we proceeded with downloading the file.
After investigating the downloaded files, we observed that the values we passed as part of the query string parameters during the request smuggling attack were included in the generated template.
By looking at the TemplateGenerator.php file, we could see that the parameter values are passed to Twig – an open-source template language for PHP. >
The following payload was submitted to verify whether the application is vulnerable to Server-Side Template Injection (SSTI).
An SSTI occurs when an attacker uses native template syntax, to inject a malicious payload into a template. SSTI vulnerabilities can expose web applications to a variety of cyber attacks, including Remote Code Execution (RCE). >
The generated template was re-downloaded, and we noticed that the template expression was evaluated by the application.
We then attempted to gain Remote Code Execution, which is how an attacker could remotely execute malicious code on a computer, by using the following payload:
However, by observing the web server logs, we noticed that this was unsuccessful since Twig was running in a sandbox and ‘filter’ was not permitted.
However, upon closer inspection, we observed from the composer.json file that the Twig version used by the application was slightly outdated (for example, 3.3.7), and affected by the vulnerability CVE-2022-23614.
The following payload was then used to execute arbitrary commands on the system hosting the application:
Finally! We got RCE!
Step 4: Capture the Flag
The following screenshots show the final payload we used to successfully capture the flag:
In summary
That concludes the PhishTale challenge from the 2022 Hack the Box Business CTF competition, that was all about discovering and exploiting weaknesses in a web application.
We thoroughly enjoyed solving this challenge as it presented us with a real-world scenario that we would often encounter when exploiting vulnerabilities in web applications. Kudos to the author of the PhishTale challenge!
Stay tuned for more technical overviews of the challenges we faced during the Hack the Box Business CTF 2022 competition.
Simplify your security!
Learn how our innovative cyber services can make solving your security challenges both simple and cost-effective. Schedule a free consultation with a Bulletproof security expert today.
Learn moreRelated resources
Trusted cyber security & compliance services from a certified provider
Get a quote today
If you are interested in our services, get a free, no obligation quote today by filling out the form below.