Sono tranquillamente a caccia di vulnerabilità (non su ESXi perché sta sotto inchiesta), come tutte le sere prima di partire verifico che l'exploit sia crash-safe, preparo i quick-report da inviare ai target sulla CVE usata, lancio la scan e a un certo punto mi ritrovo davanti questo, cioè lo scenario più raccapricciante che un hacker etico possa mai assistere:
Cioè no, allora, io per amor di privacy ho censurato molte cose in questo screenshot. Adesso voi vi chiederete, perché la parte in base64 è censurata, e soprattutto perché è identica in più punti? I motivi sono molto semplici. Se voi decodificate l'intera stringa esce fuori l'indirizzo IP dell'amico che stava cercando di exploitare quest'host. Dato che però il payload era troppo grande.. Qualcosa è decisamente andato storto :/
Il processo con PID 20771 è un bash command che genera una reverse shell (la sintassi era identica a Metasploit, con porta 4444 nel listener, sia IP che Porta in plain text come sempre), ma dato che Metasploit è un tool creato a scopo educativo, molte funzioni avanzate mancano, e infatti il tizio quando è uscito gli è rimasta questa backdoor in "pending" sul terminal. Cioè ma fare process kill prima di uscire? Cioè immagina di essere un sistemista, inizi la tua giornata lavorativa, apri il terminal, guardi i task ed escono 10 PID di bombe informatiche codificate in base64. Poi la porta in ascolto, cioè di 65.000 scegliere una porta più ingannevole? U'culu, porta 4444 invece... Non stava usando Metasploit, no.
Non ha neppure provato a fare payload rotation, erano letteralmente circa 10 task con PID differenti (=10 tentativi ripetuti di fila), tutti con la stessa identica stringa in base64. Decodificando la stringa, stava cercando di scaricare un payload in /tmp con wget e creare un cron (per fare persistence). Adesso io non lo so se questo payload era Beacon, Meterpreter, Xmrig o qualcosa di più pericoloso, sta di fatto che ho lasciato, come al solito, il report sulla CVE all'amministratore, ho dato una pulita a quel terminal e poi sono uscito.
Ma a monte dell'etica, io mi chiedo, che senso ha lanciare 20 volte lo stesso comando se vedi che non funziona? Cioè se guardi questa bomba informatica in base64 lo capisci immediatamente che è qualcosa che anche ClamAV fermerebbe (cito ClamAV dato che siamo su Linux eh), la regola è semplice = più è complesso il codice, più sys call insicure -> Maggior rischio di detection. Ma poi il fatto stesso di codificare gli script in base64, un trucchetto che nel 2023 frega solamente gli AV con le definizioni scadute dal 2016...
Tutto quello che ha concluso questo sconosciuto sapete qual è? Che se ero uno stro*** adesso leakavo i suoi dati, ha lasciato tutto il terminal pieno di quella roba là e non ha nemmeno pulito. Sono abbastanza sicuro che dal processo con PID 20771 possa essere riuscito ad entrare, perché era un semplice bash command in plain. Forse non aveva neanche tante cattive intenzioni perché non ho trovato file criptati o altra roba... Ma l'accortezza manca, si tasta proprio sulla pelle l'impulsività giovanile nell'output di quel terminal. I bambini non devono giocare con Metasploit, devono uscire, farsi amici e avere una vita. L'hacking non è un gioco, perché 1 è complesso 2 se non sai quello che fai combini danni, anche involontariamente.
Ad esempio è sufficiente anche non sapere cosa fa un exploit a livello tecnico per fare danni, se hai in mano una CVE instabile che freeza l'app vulnerabile, genera resource loss o service disruption, non andrebbe mai lanciata neanche per fare un pentest "benevolo", ma solamente con l'autorizzazione e la supervisione di un'ente in un ambiente controllato.
Alcune CVE sono letteralmente delle bombe a orologeria, con più probabilità di fare danni piuttosto che forzare il target a eseguire un comando su terminal o ricevere una reverse shell. Ma a a chi lo sto spiegando? Il campione che ha generato quell'output non è qui, non può leggermi... Spero che almeno mi avete letto voi.
Cioè no, allora, io per amor di privacy ho censurato molte cose in questo screenshot. Adesso voi vi chiederete, perché la parte in base64 è censurata, e soprattutto perché è identica in più punti? I motivi sono molto semplici. Se voi decodificate l'intera stringa esce fuori l'indirizzo IP dell'amico che stava cercando di exploitare quest'host. Dato che però il payload era troppo grande.. Qualcosa è decisamente andato storto :/
Il processo con PID 20771 è un bash command che genera una reverse shell (la sintassi era identica a Metasploit, con porta 4444 nel listener, sia IP che Porta in plain text come sempre), ma dato che Metasploit è un tool creato a scopo educativo, molte funzioni avanzate mancano, e infatti il tizio quando è uscito gli è rimasta questa backdoor in "pending" sul terminal. Cioè ma fare process kill prima di uscire? Cioè immagina di essere un sistemista, inizi la tua giornata lavorativa, apri il terminal, guardi i task ed escono 10 PID di bombe informatiche codificate in base64. Poi la porta in ascolto, cioè di 65.000 scegliere una porta più ingannevole? U'culu, porta 4444 invece... Non stava usando Metasploit, no.
Non ha neppure provato a fare payload rotation, erano letteralmente circa 10 task con PID differenti (=10 tentativi ripetuti di fila), tutti con la stessa identica stringa in base64. Decodificando la stringa, stava cercando di scaricare un payload in /tmp con wget e creare un cron (per fare persistence). Adesso io non lo so se questo payload era Beacon, Meterpreter, Xmrig o qualcosa di più pericoloso, sta di fatto che ho lasciato, come al solito, il report sulla CVE all'amministratore, ho dato una pulita a quel terminal e poi sono uscito.
Ma a monte dell'etica, io mi chiedo, che senso ha lanciare 20 volte lo stesso comando se vedi che non funziona? Cioè se guardi questa bomba informatica in base64 lo capisci immediatamente che è qualcosa che anche ClamAV fermerebbe (cito ClamAV dato che siamo su Linux eh), la regola è semplice = più è complesso il codice, più sys call insicure -> Maggior rischio di detection. Ma poi il fatto stesso di codificare gli script in base64, un trucchetto che nel 2023 frega solamente gli AV con le definizioni scadute dal 2016...
Tutto quello che ha concluso questo sconosciuto sapete qual è? Che se ero uno stro*** adesso leakavo i suoi dati, ha lasciato tutto il terminal pieno di quella roba là e non ha nemmeno pulito. Sono abbastanza sicuro che dal processo con PID 20771 possa essere riuscito ad entrare, perché era un semplice bash command in plain. Forse non aveva neanche tante cattive intenzioni perché non ho trovato file criptati o altra roba... Ma l'accortezza manca, si tasta proprio sulla pelle l'impulsività giovanile nell'output di quel terminal. I bambini non devono giocare con Metasploit, devono uscire, farsi amici e avere una vita. L'hacking non è un gioco, perché 1 è complesso 2 se non sai quello che fai combini danni, anche involontariamente.
Ad esempio è sufficiente anche non sapere cosa fa un exploit a livello tecnico per fare danni, se hai in mano una CVE instabile che freeza l'app vulnerabile, genera resource loss o service disruption, non andrebbe mai lanciata neanche per fare un pentest "benevolo", ma solamente con l'autorizzazione e la supervisione di un'ente in un ambiente controllato.
Alcune CVE sono letteralmente delle bombe a orologeria, con più probabilità di fare danni piuttosto che forzare il target a eseguire un comando su terminal o ricevere una reverse shell. Ma a a chi lo sto spiegando? Il campione che ha generato quell'output non è qui, non può leggermi... Spero che almeno mi avete letto voi.
