Weasel
I think the data science team has been a bit fast and loose with their project resources. - by huskyhacks
Recon
There are six ports open, the server offers SSH, SMB, RDP and a web server. The box itself might be a windows machine.
The first hints might be on the Webserver, directly visiting its IP we will be redirected to a login page which requires a token or a password. The title states Jupyter.
Next, using Gobuster to find any interesting directories:
The API directory might have something interesting. It reveals us the version number of Jupyter.
Jupyter 6.0.3 which is interesting for further investigations.
We catch the request with Burpsuite while trying to log in. With the information gathered we attempt to craft a command in Hydra to try several passwords.
On a failed attempt to log in, the page prompts us with "Invalid credentials".
But using the found information with hydra doesn’t lead to success.
http://10.10.108.11:8888/login?next=%2Fview
To get further, we look into the SMB shares that are available.
The datasci-team stands out and is enumerable without any credentials.
And there is a token:
Initial Access
With the found token we log in to the page.
With the discovered version number an exploit is easily found. We are able to get RCE through XXS:
By editing a ipynb file with the following payload:
To do that we just duplicate the given:
And enter the payload in the created copy.
File → Save
And then open your copy by accessing the page http://10.10.108.11:8888/notebooks/weasel-Copy1.ipynb
Testing it, we have a python command line.
Next, try to deploy a Windows reverse shell, because of the results of the Nmap scan, we might face a windows machine.
It looks like this:
Next, run a listener on the attacker machine:
But it’s a Linux machine, maybe it's a Windows subsystem for linux, this might come in handy for the more direct alternative attack path.
In the folder /home/dev-datasci is an SSH private key named dev-datasci-lowpriv_id_ed25519.
Copy the key to file on attack machine and change its permissions via chmod 600
But it did not work with the user revealed by the reverse shell, instead it might be the key of another user. A user on the windows box?
Using the username dev-datasci-lowpriv from filename of the found key, we are able to log in via SSH as dev-datasci-lowpriv and are now on a windows machine.
User flag
Looking a bit around the first flag is found on the desktop of dev-datasci-lowpriv.
Hosting the File PrivescCheck via a Python Webserver on the attacker machine its possible to retrieve it via wget. With PrivsescCheck.ps1 it’s easy to determine some possible vulnerabilities to escape privileges.
To run the script use the following command:
First of all we find credentials for our user, which might come in handy later
Creds dev-datasci-lowpriv:wUqnKWqzha*W!PWrPRWi!M8faUn
The last part of the script reveals us, that AlwaysInstalledElevated is enabled
For interest in crafting the revere shell, check for the architecture:
Using the following article to target the vulnerability AlwaysInstalledElevated
With msfvenom it’s possible to craft a reverse shell inside a msi file.
Again using the python webserver on the attack box to get the msi
run a listener to catch the reverse shell on given port
With msiexec and the flag /qn = No Gui, /i =Regular it’s possible to install the msi in command line.
But it doesn’t succeed. Its not able to establish a connection.
With a hint, using the command runas to run msiexec solves the problem.
ChatGPT has the following explanation why it works this way:
When you run msiexec directly in your SSH session, it uses the current user's privileges and permissions to execute the command. If the user account "dev-datasci-lowpriv" does not have sufficient privileges or lacks necessary permissions, it could result in the failure of the msiexec command.
However, when you use runas /user:dev-datasci-lowpriv to execute msiexec, it runs the command under a different process with the specified user's credentials. This effectively elevates the privileges of the command, potentially bypassing any restrictions or permission issues associated with the current user account.
Root flag
now we are able to access the root flag with the new reverse shell.
Alternative attack path
For the alternative attack path we have to chose a more stable reverse shell, which is able to spawn a shell. We know from our previous reverse shell, that python3 is available, so we use Python3#2 from revshells.com spawning a /bin/bash.
After successfully getting a reverse shell, it’s time to upgrade it.
Due to the upgrade echo does not work correctly, but printf does it just as well.
In the inital enumeration via sudo -l, it is possible to run /home/dev-datasci/.local/bin/jupyter as sudo without a password. This file does not exist, so its up to our own to create this file, and enter what ever we want to be executed with sudo. In this case /bin/bash
Running this with sudo gives us now a bash with root permissions.
Now moving into the root directory and creating a folder, to mount the wsl host, maybe its possible to directly retrieve the flags from there.
to resolve the issue add C: /root/windows drvfs defaults 0 0 to the /etc/fstab
and run mount -a
Now we are able to traverse through the Windows filesystem.
User flag
Root flag
Last updated
Was this helpful?