tom@home.htb:~$

Blog o HTB

30 December 2020

Postman

Úvod a kontext

Postman je ukázkový řetězec založený na konfiguraci, ne na exotickém exploitu. Otevřený Redis bez autentizace dovolí zapsat vlastní SSH klíč do domovského adresáře účtu redis. Z lokálního přístupu pak vypadne záložní privátní klíč id_rsa.bak, jehož passphrase je znovu použitá jinde v systému.

Didakticky je na tom důležité právě řetězení malých provozních chyb. Web na 80/tcp je spíš kulisa. Skutečný útok stojí na Redisu, špatně uloženém klíči a starém Webminu.

Počáteční průzkum

Otevřené služby

nmap -p 1-65535 -T4 -A -sC -v $IP
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp    open  http    Apache httpd 2.4.29
6379/tcp  open  redis   Redis key-value store 4.0.9
10000/tcp open  http    MiniServ 1.910 (Webmin httpd)

Z hlediska priorit bylo jasné, že nejdůležitější je 6379/tcp. Web na portu 80 neposkytoval nic zásadního, zatímco Redis běžel veřejně a bez autentizace.

Analýza zjištění

Redis bez autentizace

Postman stojí na klasické Redis misconfiguration technice. Pokud je Redis přístupný bez hesla a proces běží pod systémovým účtem, lze změnit dir a dbfilename tak, aby se dump databáze zapsal jako:

Je to zároveň učebnicový příklad článku Špatně vystavené datové, storage a cloud-like služby, protože pomocná datová vrstva tady fakticky rozhodla celý první foothold.

/var/lib/redis/.ssh/authorized_keys

Po vložení vlastního veřejného klíče a SAVE tak vznikl SSH přístup jako redis.

To není zranitelnost v Redisu samotném, ale chyba nasazení. Redis neměl být veřejně dostupný a už vůbec ne bez autentizace.

id_rsa.bak a reuse passphrase

Po přihlášení jako redis už dávala smysl čistě lokální enumerace. Právě ta odhalila v /opt zajímavý soubor:

/opt/id_rsa.bak

Šlo o šifrovaný privátní klíč. Po převodu pomocí ssh2john a cracknutí hesla v john vyšla passphrase:

Samotné cracknutí je typická práce pro John the Ripper a teprve jeho výsledek dává smysl dál testovat jako reuse.

computer2008

Přímé SSH jako Matt nefungovalo, ale stejné heslo šlo použít lokálně:

su Matt

Tím vznikl běžný uživatelský kontext a přístup k user.txt.

Starý Webmin na 10000/tcp

Ve stejné době už bylo z enumerace jasné, že na hostu běží Webmin 1.910:

10000/tcp open  http    MiniServ 1.910 (Webmin httpd)

To je důležité ze dvou důvodů:

Právě tohle propojení klíče, lokálního účtu a admin rozhraní shrnuji i v článku Password reuse a rozpad hranic mezi aplikací, SSH, WinRM a admin nástroji.

Získání přístupu

redis -> Matt

Stabilní uživatelský řetězec na Postmanu proto vypadal takto:

  1. zápis SSH klíče přes Redis a přihlášení jako redis,
  2. nalezení /opt/id_rsa.bak,
  3. cracknutí passphrase computer2008,
  4. lokální přepnutí na Matt přes su.

Ověření user části:

cat /home/Matt/user.txt
__CENSORED__

Eskalace oprávnění

Webmin package update RCE

Jakmile byly známé platné přihlašovací údaje Matt/computer2008, nebyl důvod dál hledat lokální SUID cestu. Webmin 1.910 měl známý authenticated RCE v rozhraní pro správu balíčků a běžel jako root.

Prakticky tedy stačilo použít PoC nebo Metasploit modul proti https://postman:10000, autentizovat se účtem Matt a nechat server vykonat útočníkův příkaz jako root.

Tím vznikl rovnou root shell a 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 - redis - ssh - webmin - exploit - privesc