Paolo PeregoFollowSpecialista di sicurezza applicativa e certificato OSCE e OSCP, amo spaccare e ricostruire il codice in maniera sicura. Sono cintura nera di taekwon-do, marito e papà. Ranger Caotico Neutrale, scrivo su @codiceinsicuro.
Oggi, stavo cercando qualche istanza di database
NoSQL in giro tra le mie reti del Luna
Park per provare un nuovo strumento di database audit. Ah, per l’inciso,
trovare uno strumento di database audit che lavora come dico io, è molto,
molto difficile.
Dicevo, ero lì che cercavo tra i risultati di
Nexpose, la macchina che più si
poteva prestare ad essere immolata alla sperimentazione, quando nelle finestre
di riepilogo degli asset, vedo elencati una serie di database.
La macchina, chiamiamola per semplicità 10.10.0.3, aveva la porta MySQL
aperta e vedevo tutti i suoi database elencati. Visto che Nexpose lavora con
nmap e qualche colpo di rpm, almeno sulle distribuzioni rpm powered, mi sono
chiesto come diavolo avesse tirato fuori tutti quei risultati.
Dopo una ricerchina su Google, è venuto fuori che ci sono
11 script per nmap, tutti dedicati al simpatico database di
casa Oracle.
Oh bhé, tanto è da immolare, sfruttiamoli.
Seek…
Dunque, i nomi dei percorsi sono diversi tra Sistemi Operativi diversi e
versioni di nmap diverse. Come regola, prendete la directory dello share,
cercate i dati di nmap e qui chercate i dati degli script scritti in
lua. Bingo, avete trovato quello che stavate cercando.
Torniamo a noi. Sul mio
Mac, nmap è
installato usando Homebrew.
Tutti i package, quindi, sono installati in /usr/local/Cellar. Ogni package
avrà una sottodirectory per ciascuna versione installata, in modo da creare una
specie di sandbox tra le diverse versioni.
Ora, visto che è a solo scopo dimostrativo, metteremo sull’altare dei sacrifici
il mysql che ho installato sul mio Mac per qualche giochino con WordPress e
Redmine.
Per prima cosa, verifichiamo che la porta sia effettivamente aperta e, essendo nmap un portscanner, potrebbe essere proprio compito suo. Gli diciamo di fare anche il fingerprint del servizio in modo da recuperare, se riesce, il numero di versione.
Aperta. Ora, chiediamo qualcosa di più ed usiamo lo script
mysql-info.
Quanta abbondanza. Sembra ci sia un problema di output con il salt del
database.
Questo salt, altro non è se non una stringa pseudocasuale, accodata alle
password cifrate per prevenire attacchi basati sulle rainbow tables.
No, non usano bcrypt. Male. Andiamo avanti.
Ora, passiamo a cercare di forzare il lucchetto. Abbiamo MySQL aperto, abbiamo
nmap, usiamo lo script
mysql-brute che fa un
attacco di forza bruta su una serie di account well known.
Nel mio caso, sulla mia macchina locale, l’utente root non ha password. Questo
non succede mai nella realtà vero?!?
Ok, ora io potrei anche usare il client di mysql e navigare, ma visto che ho
iniziato con nmap, continuerò con il mio fido coltellino svizzero. Coltellino
che ora mi servirà per enumerare tutti i database presenti su quella mia
macchina.
Allo script occorre passare anche, come argomento, l’utente MySQL che si vuole
utilizzare. Noi abbiamo l’utente root, siamo particolarmente fortunati.
L’efficacia dello script ovviamente è dovuta ai privilegi dell’utente sul
sistema.
… and destroy
Nel 2012, uscì una brutta vulnerabilità riguardante MySQL e MariaDB. Il
CVE-2012-2122 parla di un bypass
dell’autenticazione sul DBMS a causa di un errore di casting di una variabile.
Di fatto, sfruttando questo bug, era possibile collegarsi a qualsiasi MySQL,
usando una password casuale a patto di conoscere un utente reale del db. Di
fatto, l’utente root esiste quasi sempre. Lo script
mysql-vuln-cve2012-2122
serve proprio a sfruttare questa vulnerabilità nei database MySQL.
Ahimé, la mia versione è moderna e non vulnerabile a questa problematica.
Questione di audit
Quanti di noi fanno girare di solito, audit sui database, sanno cos’è lo
standard CIS. Lo standard CIS consiste in una
serie di checklist che, dato un sistema, mi indicano se la sua configurazione è
più o meno sicura.
Lo script da lanciare è
mysql-audit, che però ha
bisogno necessariamente di un file di audit contenente i controlli CIS che si
vuole implementare.
Come dicevamo, il file di compliance CIS che viene fornito con nmap, non solo è
vecchio e si applica solo a nmap 4.1, 5.0 e 5.1, ma è anche sintatticamente
errato. Ho creato una pull request
giusto mentre preparavo questo post, altrimenti non funzionava nulla.
Lanciando lo script, ahimé abbiamo dei risultati che non sono veritieri,
proprio perché questa versione di checklist non è applicabile alla versione di
MySQL che sto usando io.
L’idea comunque di avere una checklist applicata così semplicemente dal mio
portscanner, apre nella mia testa innumerevoli scenari.
Di sicuro, i file di checklist devono controllare se sono applicabili alla
versione di MySQL a seconda del banner. Poi, un possibile miglioramento è
quello di creare più file di audit, in modo da coprire le versioni mancanti di
MySQL ed eventualmente estendere anche ad altri DBMS.
Off by one
Nmap è uno strumento straordinario e, da quando ha integrato il motore di
scripting basato su Lua, è diventato definitivamente uno strumento poliedrico.
Ormai chiamarlo port scanner è riduttivo, abbiamo visto come dal port scan, si
possa fare information gathering, fino all’exploiting e per finire anche report
di compliance.
Se questo post ti è piaciuto, sono abbastanza sicuro che troverai questi contenuti altrettanto interessanti. Buona lettura.
Episodio 32: Quando l'EDR fa crock
Introduzione
Ciao caro lettore. Ero come al solito in ritardo nella creazione di questo
numero della newsletter di cybersecurity più aperiodica dell’universo, quando
Internet si è rotta ancora.
Eh già… in questi mesi ho dato anima e corpo al canale YouTube ed ho trascurato un po’ il mio blog. Questa però è una delle cose che voglio prima raccontare qui, nella mia versione digitale di un Bullet Journal.