There are six ports open, the server offers SSH, SMB, RDP and a web server. The box itself might be a windows machine.
root@ip-10-10-27-71:~#nmap-sT-sV-sC-O-p135,3389,445,8888,22,13910.10.108.11StartingNmap7.60 ( https://nmap.org ) at 2023-05-22 20:12 BSTNmapscanreportforip-10-10-108-11.eu-west-1.compute.internal (10.10.108.11)Hostisup (0.00028s latency).PORTSTATESERVICEVERSION22/tcpopensshOpenSSHfor_Windows_7.7 (protocol 2.0)|ssh-hostkey:|20482b:17:d8:8a:1e:8c:99:bc:5b:f5:3d:0a:5e:ff:5e:5e (RSA)|2563c:c0:fd:b5:c1:57:ab:75:ac:81:10:ae:e2:98:12:0d (ECDSA)|_256e9:f0:30:be:e6:cf:ef:fe:2d:14:21:a0:ac:45:7b:70 (EdDSA)135/tcpopenmsrpcMicrosoftWindowsRPC139/tcpopennetbios-ssnMicrosoftWindowsnetbios-ssn445/tcpopenmicrosoft-ds?3389/tcpopenms-wbt-serverMicrosoftTerminalServices|ssl-cert:Subject:commonName=DEV-DATASCI-JUP|Notvalidbefore:2023-03-12T11:46:50|_Notvalidafter:2023-09-11T11:46:50|_ssl-date:2023-05-22T19:12:47+00:00; 0sfromscannertime.8888/tcpopenhttpTornadohttpd6.0.3|http-robots.txt:1disallowedentry|_/|_http-server-header:TornadoServer/6.0.3|http-title:JupyterNotebook|_Requestedresourcewas/login?next=%2Ftree%3FMACAddress:02:48:C8:C7:60:2F (Unknown)Warning:OSScanresultsmaybeunreliablebecausewecouldnotfindatleast1openand1closedportAggressive OS guesses: Microsoft Windows Longhorn (92%), Microsoft Windows Server 2012 (92%), Microsoft Windows Vista SP1 (92%), Microsoft Windows Server 2012 R2 Update 1 (91%), Microsoft Windows Server 2016 build 10586 (91%), Microsoft Windows 7, Windows Server 2012, or Windows 8.1 Update 1 (91%), Microsoft Windows Server 2012 R2 (90%), Microsoft Windows 10 build 10586 (90%), Microsoft Windows Server 2008 SP2 (90%), Microsoft Windows 7 SP1 (90%)
NoexactOSmatchesforhost (test conditionsnon-ideal).NetworkDistance:1hopServiceInfo:OS:Windows; CPE:cpe:/o:microsoft:windowsHostscriptresults:|_nbstat:NetBIOSname:DEV-DATASCI-JUP,NetBIOSuser:<unknown>,NetBIOSMAC:02:48:c8:c7:60:2f (unknown)|smb2-security-mode:|2.02:|_Messagesigningenabledbutnotrequired|smb2-time:|date:2023-05-2220:12:47|_start_date:1600-12-3123:58:45OSandServicedetectionperformed.Pleasereportanyincorrectresultsathttps://nmap.org/submit/.
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.
To get further, we look into the SMB shares that are available.
The datasci-team stands out and is enumerable without any credentials.
root@ip-10-10-27-71:~/smbmap/smbmap#smbclient-L10.10.108.11WARNING:The"syslog"optionisdeprecatedEnterWORKGROUP\root's password: Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share datasci-team Disk IPC$ IPC Remote IPCReconnecting with SMB1 for workgroup listing.Connection to 10.10.108.11 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)Failed to connect with SMB1 -- no workgroup available
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.
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.
PS C:\Users\dev-datasci-lowpriv\Desktop> runas /user:dev-datasci-lowpriv "msiexec /i C:\Users\dev-datasci-lowpriv\Desktop\revshell.msi /qn /L*V C:\Users\dev-datasci-lowpriv\
Desktop\error"Enter the password for dev-datasci-lowpriv: Attempting to start msiexec /i C:\Users\dev-datasci-lowpriv\Desktop\revshell.msi /qn /L*V C:\Users\dev-datasci-lowpriv\Desktop\error as user "DEV-DATASCI-JUP\dev-datasci-low
priv"...PSC:\Users\dev-datasci-lowpriv\Desktop>
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.
root@DEV-DATASCI-JUP:~#cd/rootroot@DEV-DATASCI-JUP:~#mkdirwindowsroot@DEV-DATASCI-JUP:~#mount-tdrvfsC:\ /root/windowsmount:C:/root/windows:can't find in /etc/fstab.
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.