Amb l’objectiu de mitigar possibles fallades en diferents entorns o sistemes de la xarxa, des dels últims anys, les empreses s’han vist obligades a fer proves periòdicament a les seves pròpies infraestructures per corregir anomalies i forats que posin en perill la integritat, la disponibilitat la confidencialitat dels seus actius. Aquest conjunt de proves és el que s’anomena pentesting “penetration testing”.
La filosofia del pentesting es basa en identificar les vulnerabilitats i punts febles d’un sistema abans que ho facin entitats de tercers amb intencions malicioses.
Però, com es fa un pentest? Aquesta pregunta no té una resposta aplicable per tots els casos, ja que a cada pentest es treballa en un ambient diferent (infraestructura, software…). Tot i això, sí que podem extreure una metodologia aplicable en la gran part de pentests.
Aquesta metodologia s’explica a continuació amb un exemple basat en un servidor propietat de HackTheBox, una organització que dissenya màquines molt realistes, amb l’objectiu de formar a persones en l’àmbit de la ciberseguretat. Cal remarcar que en cap moment s’ha volgut fer una guia de com completar aquesta màquina, s’han omès certes passes importants per centrar-se en el procés general del pentest.
Pre-Engagement Interactions
En aquesta primera fase d’un pentest el client indica quins són els objectius i l’àrea d’atac. Depenent de la informació rebuda per part del client, es tractarà d’un pentest de caixa negra (si no es coneix res del sistema al que s’atacarà), un pentest de caixa blanca (si es coneix tot sobre el sistema que s’atacarà) o un pentest de caixa grisa (si només es coneixen algunes dades sobre el sistema que s’ha d’atacar).
Information Gathering
Procés que es basa en obtenir la màxima informació possible per poder generar un perfil precís de l’objectiu.
A continuació, es mostren exemples d’una de les eines més fetes servir durant aquesta fase: Nmap, que és un escàner de ports amb moltes funcionalitats.
sudo nmap -p- <IP> ordre que llista els ports oberts mitjançant TCP en un sistema.
Es mostra que els ports 22 i 80 estan oberts mitjançant TCP. A més a més ens indica quin servei acostuma a anar a cada port.
Seguidament, un exemple per escanejar els ports oberts del sistema que utilitzen el protocol UDP.
sudo nmap -sU -oN nmap/udp.nmap <IP>
Podem observar que els ports 161 i 3389 estan oberts, com a dada interessant el port 161 fa anar SNMP.
En aquest cas, es prioritza la investigació del port 161, un port crític que no hauria de ser accessible des de l’exterior. Degut a una mala configuració, es poden obtenir unes credencials que ens permeten saber que el servidor fa anar una versió de Pandora en local al port 80, a la que s’hi pot accedir redirigint els ports.
A la part inferior de la pàgina es veu que la versió de Pandora és la v7.0NG.742_FIX_PERL2020, una versió amb vulnerabilitats conegudes.
Exploiting
Aquesta fase es basa en explotar les vulnerabilitats trobades prèviament i, en cas de trobar-ne més, veure fins a on es pot arribar.
Dins de les vulnerabilitats conegudes de la versió v7.0NG.742_FIX_PERL2020 de Pandora, hi ha una injecció de SQL, documentada a Mitre (CVE-2021-32099).
Una injecció SQL és una vulnerabilitat que es basa en injectar codi SQL en un camp determinat per aconseguir crides arbitràries a una base de dades. Això és degut a que no es comproven correctament les dades que introdueix un usuari en un camp determinat.
Així doncs, obtenim les credencials del formulari necessàries enviant una petició POST a la ubicació esmentada a la descripció del CVE amb un paràmetre session_id maliciós, que ens permet saltar-nos la autenticació del servidor:
session_id=666' UNION SELECT 1,2,data FROM tsessions_php WHERE data LIKE '%user%' -- xxx
Un cop a dins de la interfície explotarem una altre vulnerabilitat, també documentada a Mitre (CVE-2020-13851), un RCE (Remote Code Execution), que permet executar comandes de manera remota. S’utilitza aquesta vulnerabilitat per generar una Reverse Shell i obtenir accés al sistema com a usuari ras.
Una vegada s’ha aconseguit accedir al sistema, mitjançant un script d’enumeració anomenat linPEAS, es pot observar el següent:
A l’última línia es pot veure informació molt interessant, un fitxer que té permisos de SUID, i que també pot ser executat per l’usuari que hem aconseguit.
Un binari amb permisos SUID pot canviar els seus privilegis pels del propietari de l’arxiu. Per tant, si l’executem amb l’usuari que hem aconseguit anteriorment, el binari podrà obtenir permisos d’administrador, ja que root és el propietari de l’arxiu.
A l’examinar les crides de sistema que executa, es pot veure que es crida el binari tar sense el path absolut. Això vol dir que si es modifica la variable d’entorn $PATH i es crea un arxiu anomenat “tar”, es podrà executar aquest arxiu amb privilegis d’administrador.
Les comandes següents fan això mateix i executen el binari:
export PATH=.:$PATH echo '/bin/bash' > tar chmod +x tar /usr/bin/pandora_backup
Aquest és un exemple d’escalat de privilegis, obtenint permisos d’administrador i, en conseqüència, el control total del servidor.
Per últim, cal aclarar que un pentest no es basa únicament en obtenir accés a una màquina, sinó que consisteix en intentar trobar totes les vulnerabilitats o males configuracions que poden posar en perill la seguretat i integritat d’un servei.
Reporting
Aquesta fase final, es basa en agrupar tot el que s’ha trobat i documentat per poder-ho explicar tot de manera clara i fixa. El document final ha de tenir un recull de totes les vulnerabilitats trobades, les respectives mitigacions i la manera en que les primeres s’han trobat. D’aquesta manera, a l’hora que els desenvolupadors hagin d’arreglar les vulnerabilitats, seran capaços de replicar-les per assegurar-se de que s’han resolt correctament.