TryHackMe - envizon
As the creator of the room we want to publish a clean, complete and intended write-up for the community to share a bit knowlege about white-box testing.
The machine is deployed in our network testing environment so the ip address is different than in the THM environment.
Initial discovery
First things first. We need a basic port scan in order to identify possible vulnerable services.
The SSH service is not very promising so we will focus on the other two ports. Nmap identified port 4444 as an Jetty HTTP service.
After visiting the webservice we identified a running selenium instance which is used for taking screenshots from other web services. This may be interesting for client side attacks but is not in focus yet.
Note: The selenium container was disabled in some environments like tryhackme because of the high ram usage so the port 4444 will be not open.
The other open port “3000” looks like an ssl wrapped tcp application. After some investigations we simply try to use a browser on order to connect to the service.
As pointed in the description we are facing an instance of the open source software “envizon” which asks for a password. We can assume that the database is not empty and may contain sensitive data.
A basic directory bruteforce shows some interesting locations.
As we are in a white box approach with the ability to inspect the current underlying source code we can confirm our findings.
After spending some time reading the code and the hints given by the description we noticed that the “show” function in the “NotesController” can be reached without authentication.
Notes are not directly routable by their corresponding id because the gem “acts_as_hashids” is used for this specific model. We can verify this by inspecting the “notes.rb” model.
Luckily the developers implemented an additional check in the notes controller for the note with the id “1”. So the very first note can be reached by simply using the id.
The path “/notes/1” could be also reached without a source code review by simply using gobuster with a default wordlist like seclist’s “common”.
Insecure direct object references (IDOR) & insecure / predictable hash calculation
In order to calculate the hashid for the note with the id “380” we exploit the fact that hashids are calculated with a default secret if it’s not given by the application. As mentioned in the readme-file of the gem (https://github.com/dtaniwaki/acts_as_hashids#secret) the class name of the model is used as the secret.
Now we have to put all information together using the irb-shell. Before we are able to calculate the hashid we have to install ruby and the gem that is used by “acts_as_hashids”. This can be achieved by the following command:
gem install hashids
After successfully calculating the hashid for our note we can view the content by simply browsing directly to the location
As expected we find the password for the current envizon instance and are able to login.
Unrestricted file upload, Full path disclosure (optional), Command injection
The application offers a wide attack surface as many functions are made for pentesting purposes. A very promising target is the custom scan functionality as we can inject parameters in the final nmap command by default.
After spending some time reading the source code on this specific functionality, basic command injection using special termination characters has been mitigated. However nmap offers wide functionality that can be abused.
https://gtfobins.github.io/gtfobins/nmap/
This link describes the invocation of system commands using a lua-script and the “ — script” parameter. In order to get our custom lua script to the target machine we can abuse the upload xml file functionality.
The uploaded file is placed in the “nmap/uploads/” folder. Furthermore the content is not checked by the backend code.
The prepared file contains lua-code that can be interpreted by nmap.
By clicking on the “tasks” button in the footer we receive the full path of the uploaded file by clicking again on the “Versuche” link as the import worker fails processing the malformed file.
This information can by also recieved by inspecting the corresponding Dockerfile.
All information is collected in order to execute the final exploit. The xml filename is generated from the scan name used in the upload process earlier.
Sensitive file in backup archive
The “.dockerenv” file indicates that we are in a docker environment. In order to escalate to the host system further investigations are necessary.
Enumerating the file system one file indicates the usage of the borgmatic backup software.
The borgmatic configuration file contains the repository password in cleartext. Furthermore the backup-repo is located on the local filesystem. We can use borgmatic to inspect older backups as the root-folder is backuped periodically.
After extracting the archives we found an unsecured private ssh key.
The private ssh key is able to login into the host system using the root user.
Now the box is finally rooted and the challenge is completed. Hope you enjoyed and always try harder!
