4.5.2
Review the remainder of the code in index_public.php. Try to identify another path to the vulnerable function and modify the final data exfiltration script accordingly.
4.6
Try to modify the script from the previous exercise so that you can retrieve the admin account password hash.
4.7
Is there a different way to bypass the authentication? If yes, create a proof of concept script to do so.
4.9.4
Develop a fully functional exploit that will combine the previous vulnerabilities to achieve remote code execution:
- Use the SQL injection to disclose the teacher’s password hash
- Log in with the disclosed hash (using the pass the hash vulnerability)
- Upload a ZIP that contains a PHP file and extract it into the web root
- Gain remote code execution!
5.5.2
Given everything you have learned about type juggling, recreate the compromise of the “teacher” account using the “Forgot Password” function WITHOUT updating the email address.
6.5.1
There is at least one additional attack vector which involves manipulation of Java class files and the use of JSP files. While not simple, it can be accomplished. See if you can find and exploit this additional vector.
6.8.2
Use the SQL injection we discovered in this module to create a large object and retrieve the assigned LOID without the use of blind injection. Adapt your final proof of concept accordingly in order to employ this technique avoiding the use of a pre set LOID value (1337).
7.5
The student user home directory contains a sub-directory named bassmaster_extramile. In this directory we slightly modified the Bassmaster original code to harden the exploitation of the vulnerability covered in this module.
Launch the NodeJS batch.js example server from the extra mile directory and exploit the eval code injection vulnerability overcoming the new restrictions in place.
8.4
Although we have not discussed Java deserialization vulnerabilities in this course, it is worth mentioning that one such vulnerability exists in the ManageEngine Applications Manager instance in your lab. We encourage you to get familiar with the Java ysoserial version and try to identify and exploit this vulnerability.
9.5.2
Discover another location where ERPNext uses the render function to execute user-provided code.
9.5.3
Creating string variables of the attributes we need to access is only one option to bypass the SSTI filter. If the developers replace the filter from “.” to “”, our payload would not work any longer. Using the Jinja documentation, find another method to exploit the filter that does not set the string variables for the attributes directly in the template. For this Extra Mile, the template should only contain the following expression: “string|attr(class)”.
9.6.2
Using the Python and Jinja documentation, make changes to the template that will allow the output to display in the response.
10.2.4
Update the token generator program to accept the start and stop values as command line parameters.
10.2.5
Automate the entire password reset attack chain, including the deletion of any password reset alerts that are generated.
10.3.5
Create a script to parse the results of the XXE attack and cleanly display the file contents.
11.6.2
Change the form of the fake login page to prevent the form from loading a new page. Currently, if a user submits their credentials in the fake login page, we will not capture it and the user will be redirected away from the XSS. We want to keep the user on this page for as long as possible. Don’t worry about grabbing the data and sending it over just yet. We’ll cover this in a following section.
11.6.4
Add the ability to store credentials and any accessible cookies that are obtained from an XSS victim. Some cookies might contain the HttpOnly attribute, making them inaccessible from JavaScript. However, we should capture all cookies that do not have the HttpOnly attribute. The credentials and cookies should be stored in separate tables and will require modifications to the database script as well.
11.6.5
Capture any pre-filled passwords the user has saved in their browser. Send the captured credentials to the API Server. Capture Login Events if the user we are targeting types in their credentials and clicks “Sign in”. Send the captured credentials to the API Server. This can also be done by creating a JavaScript keylogger. The longer the user is on this page, the more data we can obtain from them. Devise a technique to keep the user on the page longer.
11.7.6
Find a readable database configuration and read the password. The user we exploited in the XSS was not an administrator of the application. Use the database password to elevate privileges of the “viewer” user to the administrator and reset the password to allow you to login. The openITCOCKPIT application allows administrative users to create custom commands. Using this feature and an administrator’s account, find and “exploit” this feature.
12.3
Since the Authorization header is allowed in the CORS requests, we would be able to send authenticated requests through a user’s browser if we don’t have network access to the application. Return to the old version of Concord and create a CORS payload using the Authorization header and the credentials we’ve discovered. This payload should create a new Admin user, generate a new API key as a back door, and obtain a shell.
13.3.2
Expand the route_buster.py script to include PUT and PATCH methods. Investigate the /users/invite endpoint. What information are we missing to make a valid request?
13.4.2
Review the source code for /users/invite. Determine why it cannot be exploited.
13.4.5
Create a second script that enumerates based on host name. Try using the script to identify the live hosts.
13.6.1
Modify the JavaScript function to avoid data truncation by sending the data in multiple requests if the data is longer than 1024 characters.
13.6.2
Create a web server in your choice of programming language to handle the JavaScript callbacks and automatically URL-decode the data.
13.7.1
The current reverse shell isn’t fully interactive and can cause the gateway to hang. Upgrade to a fully interactive shell.
With the other plugins available in Kong API Gateway, find a way to log all traffic passing through the gateway. Inspect the traffic for any sensitive data. You should only need five to ten minutes worth of logging. The logging plugin can be disabled by sending a GET request to /plugins to get the plugin’s id, then sending a DELETE request to /plugins/{id}. Review the authentication documentation for Directus2 and use the logged data to gain access to a valid access token for Directus.
14.2.3
Find a value (other than toString) that will crash the application when it is set in the prototype.
So far, we have been able to obtain the token because this application allows the user to provide their own settings. This might not always be the case. We’ve introduced a directory traversal vulnerability into the application. Use this directory traversal to obtain the source for the encryption function and the encryption key. Generate a token, decrypt it, modify any parameter, and re-encrypt it. Use this modified token to connect to the RDP client.
14.4.2
Earlier, we used the escape variable to detect if the target is running EJS. We can also use this variable to obtain RCE with some additional payload modifications. Find how to obtain RCE by polluting the escape variable.
14.5.1
Switch to the Pug templating engine. Discover a mechanism to detect if the target is running Pug using prototype pollution. Using this mechanism, obtain XSS against the target.
14.5.2
Switch the Templating Engine to Pug and discover a path to RCE.