Introduction to the Lab Environment

In this module, all labs will follow the same general structure, containing multiple virtual hosts that we can use to develop, fine-tune, and deliver our exploit. In this section, we will discuss the different tools at our disposal and how we can use them to exploit the different CSRF and XSS vulnerabilities we will encounter in the upcoming sections.

Generally, the labs consist of the following components:

• An exploit development server at https://exploitserver.htb

• The vulnerable web application we are assessing at the given virtual host. For instance, https://vulnerablesite.htb

• Additionally, we will host a HTTPS web server on our own system that enables us to exfiltrate data

Exploit Development Server

We can use the exploit development server at exploitserver.htb to develop a CSRF or XSS payload and deliver the exploit to our victim.

The exploit development server enables us to develop a custom exploit to target specific vulnerabilities we find in the target web applications. Suppose, for an XSS proof-of-concept on a target web app, we want to trigger an alert box:

https://exploitserver.htb
Exploit server interface with options to develop, view, and deliver exploits. Text area contains <script>alert(1)</script>. Save button below.

We can view our developed exploit by accessing the endpoint /exploit. Doing so triggers the alert pop-up:

https://exploitserver.htb/exploit
Popup alert from exploitserver.htb displaying the number "1" with an "OK" button.

Lastly, we can deliver exploit to our victim by accessing the /deliver endpoint, which will cause the victim to trigger our developed payload by visiting https://exploitserver.htb/exploit. This is helpful in CSRF attacks, where the victim needs to access the payload voluntarily to trigger the exploit code. This module focuses on exploit development, not exploit delivery methods. Delivering the payload to the victim forces triggering the exploit; in the real world, numerous exploit delivery methods exist, including sending a link to the victim via e-mail or any messaging service.

We can also use the exploit server to develop an XSS payload. However, we do not need to deliver the exploit to the victim in such cases, as the payload will be delivered by the injected XSS payload on the vulnerable site.

HTTPS Exfiltration Server

In this module, all labs are running on HTTPS-enabled web servers. Modern web-browsers prevent security measures that prevent HTTPS websites from loading resources via unencrypted HTTP connections. To avoid running into issues, we will setup a web server in Python that accepts HTTPS requests. Firstly, we need to generate a new self-signed certificate for the server to be able to support encrypted communication. We can achieve this using the following command. We can provide arbitrary details for the certificate:

kabaneridev@htb[/htb]$ openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes

Next, we can create a simple Python HTTPS server in a file server.py:

from http import server
import ssl

httpd = server.HTTPServer(('0.0.0.0', 4443), server.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='./server.pem', server_side=True)
httpd.serve_forever()

Afterward, we can run our server by executing the file server.py. To test the server, let us make a quick test request using curl in a second terminal:

kabaneridev@htb[/htb]$ curl -vk https://127.0.0.1:4443/testrequest?Hello=World

If we switch back to the terminal running the web server, we can see that the request URL and all GET-parameters are printed, which is sufficient for data exfiltration for our purposes in the scope of this module:

kabaneridev@htb[/htb]$ python3 server.py

127.0.0.1 - - [30/Dec/2024 23:05:55] code 404, message File not found
127.0.0.1 - - [30/Dec/2024 23:05:55] "GET /testrequest?Hello=World HTTP/1.1" 404 -

While certificate validation is disabled for all labs in this module, we should avoid self-signed certificates in real-world engagements since modern web browsers may refuse to load resources over insecure connections due to improper HTTPS configurations. For more details on HTTPS, check out the HTTPS/TLS Attacks module.