Io sono root. Analizziamo l'elevazione dei privilegi in OS Linux

Nel primo trimestre del 2020, ho dedicato tempo alla preparazione per l'esame OSCP. La ricerca di informazioni su Google e il gran numero di tentativi 'ciechi' mi hanno rubato tutto il tempo libero. Non è stato affatto semplice comprendere i meccanismi di elevazione dei privilegi. Il corso PWK presta particolare attenzione a questo tema, ma il materiale didattico è sempre insufficiente. Ci sono molti manuali su Internet con comandi utili, ma non sono un sostenitore del seguire ciecamente le raccomandazioni senza comprendere a cosa porteranno.

Voglio condividere con voi ciò che sono riuscito a scoprire durante la preparazione e il superamento dell'esame (inclusi i miei raid periodici su Hack The Box). Ho provato un forte senso di gratitudine per ogni frammento di informazione che mi ha aiutato a percorrere il cammino di Try Harder in modo più consapevole, e ora è tempo per me di rendere omaggio alla comunità.

Desidero darvi un manuale sull'elevazione dei privilegi in OS Linux, che include un'analisi dei vettori più comuni e di alcuni trucchi correlati che vi saranno certamente utili. Spesso i meccanismi stessi di elevazione dei privilegi sono abbastanza semplici, le difficoltà sorgono nella strutturazione e analisi delle informazioni. Pertanto, ho deciso di iniziare con una 'visita guidata' e successivamente esaminare ogni vettore in articoli separati. Spero di farvi risparmiare tempo nello studio dell'argomento.

Quindi, perché l'elevazione dei privilegi è possibile nel 2020, se i metodi sono noti da molto tempo? In realtà, con un utilizzo corretto del sistema da parte dell'utente, non è affatto possibile elevare i privilegi. Il principale problema globale che genera tali opportunità è una configurazione insicura. La presenza nel sistema di versioni obsolete di software, contenenti vulnerabilità, è anche un caso particolare di configurazione insicura.

Elevazione dei privilegi tramite configurazione insicura

In primo luogo, vediamo di chiarire cosa si intende per configurazione insicura. Cominciamo con il fatto che i professionisti IT spesso utilizzano manuali e risorse come Stack Overflow, molti dei quali contengono comandi e configurazioni insicure. Un esempio eclatante è notizia il fatto che il codice più copiato da Stack Overflow contenesse un errore. Un amministratore esperto lo noterebbe, ma questo è nel mondo ideale. Anche i professionisti competenti, in situazioni di carico di lavoro elevato possono commettere errori. Immaginate che l'amministratore stia preparando e approvando la documentazione per una nuova gara, mentre si immerge in una nuova tecnologia che deve essere implementata nel prossimo trimestre, e nel frattempo risolve occasionalmente i problemi degli utenti. E qui gli viene dato un compito per sollevare rapidamente un paio di macchine virtuali e distribuire su di esse i servizi. Cosa pensate, qual è la probabilità che l'amministratore non noti semplicemente un errore? Poi gli specialisti cambiano, ma i rattoppi rimangono, mentre le aziende cercano sempre di ridurre i costi, compresi quelli per gli specialisti IT.

Pseudoshell e jailbreak

Una shell di sistema, ottenuta durante la fase di exploitazione, è spesso limitata, specialmente se l'hai ottenuta attraverso un attacco al server web. Ad esempio, le limitazioni della shell possono impedire l'utilizzo del comando sudo con il seguente messaggio di errore:

sudo: no tty present and no askpass program specified

Dopo aver ottenuto la shell, ti consiglio di creare un terminale completo, ad esempio utilizzando Python.

python -c 'import pty;pty.spawn("/bin/bash")'

Potresti chiedere: «Perché dovrei avere mille comandi, se posso usarne uno, ad esempio per trasferire file?» Il punto è che i sistemi possono essere configurati in modo diverso; su un altro host potrebbe non essere installato Python, ma ci potrebbe essere Perl. L'abilità sta nel saper eseguire operazioni familiari senza strumenti familiari. Puoi trovare un elenco completo delle possibilità qui.

Una shell a basso privilegio può essere ottenuta utilizzando comandi 1 e comandi 2 (sorprendente, anche GIMP).

Visualizzazione della cronologia dei comandi

Linux raccoglie la cronologia di tutti i comandi eseguiti nel file ~/.bash_history. Se il server è utilizzato attivamente e la sua cronologia non viene svuotata, c'è una buona probabilità di trovare le credenziali in questo file. Cancellare la cronologia è semplicemente scomodo. Se l'amministratore è costretto a digitare comandi lunghi tramite , ovviamente, sarà più comodo richiamare quel comando dalla cronologia piuttosto che reinserirlo. Inoltre, molti non sono a conoscenza di questo «trucco». Se nel sistema sono presenti shell alternative come Zsh o Fish, esse mantengono la propria cronologia. Per visualizzare la cronologia dei comandi in qualsiasi shell, basta inserire il comando history.

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

Esiste un hosting condiviso in cui il server è utilizzato per ospitare più siti. Di solito, in tale configurazione, per ciascuna risorsa viene creato un proprio utente con una directory home separata e un host virtuale. Ecco, se configurato in modo errato, nella directory principale della risorsa web si può trovare il file .bash_history.

Ricerca di password nel filesystem e attacchi a sistemi correlati

I file di configurazione di vari servizi possono essere accessibili in lettura dal tuo utente corrente. In essi puoi trovare credenziali in chiaro — password per l'accesso al database o a servizi correlati. La stessa password può essere utilizzata sia per accedere al database che per l'autenticazione dell'utente root (credential staffing).
Può capitare che le credenziali trovate appartengano a servizi su altri host. Lo sviluppo di un attacco all'infrastruttura tramite un host compromesso non è inferiore all'exploitation di altri host. I sistemi collegati possono anche essere trovati cercando indirizzi IP nel filesystem.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Trova la stringa password (senza cs) in quelle directory
grep -a -R -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /var/log/ 2>/dev/null | sort -u | uniq #IPs all'interno dei log

Nel caso in cui sull'host compromesso ci sia un'applicazione web accessibile da Internet, è meglio escludere i suoi log dalla ricerca di indirizzi IP. Gli indirizzi degli utenti della risorsa da Internet sono probabilmente poco utili, mentre gli indirizzi della rete interna (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) e i luoghi che visitano, secondo i log, possono essere di interesse.

Sudo

Il comando sudo consente all'utente di eseguire un comando nel contesto di root utilizzando la propria password o addirittura senza usarla. Molte operazioni in Linux richiedono privilegi di root, tuttavia lavorare come root è considerata una pratica molto sbagliata. È meglio applicare autorizzazioni selettive per l'esecuzione di comandi nel contesto di root. Tuttavia, molti strumenti Linux, compresi i classici come vi, possono essere utilizzati per aumentare i privilegi in modi del tutto legittimi. Per trovare il modo migliore consiglio di dare un'occhiata. qui.

La prima cosa da fare, una volta ottenuto l'accesso al sistema, è eseguire il comando sudo -l. Questo mostrerà le autorizzazioni per l'uso del comando sudo. Se l'utente ottenuto non ha password (ad esempio, apache o www-data), la possibilità di elevare i privilegi tramite sudo è improbabile. Quando si utilizza sudo, il sistema richiederà una password. Con il comando passwd non è possibile impostare una password, poiché richiederà la password attuale dell'utente. Ma se sudo è comunque disponibile, si dovrebbero cercare fondamentalmente:

• qualsiasi interprete, chiunque può generare una shell (PHP, Python, Perl);
• qualsiasi editor di testo (vim, vi, nano);
• qualsiasi visualizzatore (less, more);
• qualsiasi possibilità di lavorare con il file system (cp, mv);
• strumenti che hanno accesso a bash, in modalità interattiva o come comando eseguibile (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Ci sono numerosi manuali online che consigliano di raccogliere tutti i comandi suid/sgid, tuttavia raramente gli articoli forniscono indicazioni specifiche su cosa fare con questi programmi. Variazioni per l'elevazione dei privilegi, che non considerano l'uso di exploit, possono essere trovate qui. Inoltre, diversi file eseguibili presentano vulnerabilità specifiche per la versione del sistema operativo, ad esempio.

In un mondo ideale, bisognerebbe passare tutti i pacchetti installati almeno attraverso searchsploit. Nella pratica, questo dovrebbe essere fatto con i programmi più popolari come sudo. In ogni caso, c'è sempre la possibilità di utilizzare e mantenere lo sviluppo di strumenti automatizzati che evidenziano file eseguibili interessanti, in termini di elevazione dei privilegi, con i bit suid/sgid impostati. Elencherò tali strumenti nella sezione pertinente dell'articolo.

Script scrivibili, eseguiti da Cron o Init, nel contesto Root

I compiti cron possono essere eseguiti nel contesto di diversi utenti, inclusi root. Se in cron è impostato un compito con un collegamento a un file eseguibile, e questo è accessibile per la scrittura, può essere facilmente sostituito da uno malevolo e può eseguire un'elevazione dei privilegi. Per default, i file con i compiti cron sono accessibili in lettura a qualsiasi utente.

ls -la /etc/cron.d  # mostra i compiti cron 

La situazione è simile con init. La differenza è che i compiti in cron vengono eseguiti periodicamente, mentre in init all'avvio del sistema. Per sfruttare questo, sarà necessaria una riavvio del sistema, durante il quale alcuni servizi potrebbero non avviarsi (se non sono stati configurati per l'avvio automatico).

ls -la /etc/init.d/  # mostra i script di init 

È possibile cercare anche file accessibili in scrittura per qualsiasi utente.

find / -perm -2 -type f 2>/dev/null # trova file scrivibili da chiunque

Il metodo è abbastanza noto, gli amministratori di sistema esperti usano con cautela il comando chmod. Tuttavia, la maggior parte dei manuali online descrive l'impostazione dei diritti massimi. L'approccio degli amministratori di sistema inesperti "basta che funzioni" crea opportunità per l'escalation dei privilegi in generale. Se possibile, è meglio cercare nella cronologia dei comandi esempi di utilizzo non sicuro di chmod.

chmod +w /path 
chmod 777 /path

Accesso alla shell di altri utenti

Controlliamo l'elenco degli utenti in /etc/passwd. Facciamo attenzione a quelli con una shell. Possiamo provare a forzare l'accesso a questi utenti; non è escluso che attraverso un utente acquisito si possa finalmente ottenere un'escalation di privilegi.

Per aumentare la sicurezza, consiglio di seguire sempre il principio dei privilegi minimi. È anche utile dedicare tempo a controllare configurazioni non sicure che potrebbero essere rimaste dopo la risoluzione dei problemi; questo è un "debito tecnico" per l'amministratore di sistema.

Codice personalizzato

Vale la pena dare un'occhiata ai file eseguibili nella directory home dell'utente e del server web (/var/www/, se non è specificato altro). Questi file potrebbero rappresentare una soluzione insicura e contenere notevoli errori. Ovviamente, se hai un framework nella directory del server web, non ha senso cercare un zero-day all'interno durante un pentest, ma è consigliabile trovare e studiare le modifiche personalizzate, i plugin e i componenti.

Per aumentare la sicurezza, è meglio evitare di utilizzare credenziali in script personalizzati, così come funzionalità potenzialmente pericolose, come la lettura di /etc/shadow o manomissioni di id_rsa.

Escalation dei privilegi tramite sfruttamento delle vulnerabilità

Prima di tentare di aumentare i privilegi tramite sfruttamento, è importante approfondire il trasferimento di file sull'host target. Oltre ai soliti strumenti come ssh, ftp, http (wget, curl), c'è un intero «zoo» di possibilità.

Per aumentare la sicurezza del sistema, aggiornalo regolarmente con versioni stabili versioni e cerca di utilizzare distribuzioni progettate per l'Enterprise. Altrimenti, anche se raramente, ci sono situazioni in cui un apt upgrade rende il sistema non funzionante.

Utilizzo dei servizi eseguiti nel contesto dell'utente root

Alcuni servizi Linux funzionano con il privilegiato utente root. Possono essere trovati utilizzando il comando ps aux | grep root. In questo caso, il servizio potrebbe non essere annunciato in rete e disponibile solo localmente. Se ha exploit pubblici, possono essere applicati senza problemi: il crash del servizio in caso di fallimento è molto meno critico rispetto a quello del sistema operativo.

ps -aux | grep root # Linux

Il caso più favorevole è l'esecuzione di un servizio compromesso nel contesto dell'utente root. L'utilizzo del servizio SMB fornisce accesso privilegiato SYSTEM nei sistemi Windows (ad esempio, tramite ms17-010). Tuttavia, nei sistemi Linux questo è raro, quindi si può dedicare molto tempo all'ottenimento di privilegi elevati.

Sfruttamento delle vulnerabilità del kernel Linux

Questo è il percorso da seguire come ultima risorsa. Un sfruttamento non riuscito può portare al crash del sistema e, in caso di riavvio, alcuni servizi (inclusi quelli attraverso cui si è ottenuto l'iniziale shell) potrebbero non avviarsi. A volte l'amministratore dimentica semplicemente di applicare il comando systemctl enable. Inoltre, questo genererà molte lamentele riguardo al tuo lavoro, se lo sfruttamento non è stato concordato.
Se hai deciso di utilizzare i codici sorgente di exploitdb, assicurati di leggere i commenti all'inizio dello script. Tra l'altro, di solito viene indicato come compilare correttamente questo exploit. Se sei troppo pigro o hai scadenze da rispettare, puoi cercare repository con exploit già compilati. ad esempio. Tuttavia, va compreso che in tal caso otterrai un 'gatto in un sacco'. D'altra parte, se un programmatore conoscesse ogni byte del funzionamento del computer e del software utilizzato, non scriverebbe mai una riga di codice in tutta la sua vita.

cat /proc/version
uname -a
searchsploit "Linux Kernel" 

Metasploit

Per catturare e gestire una connessione, è sempre meglio utilizzare il modulo exploit/multi/handler. La cosa principale è impostare correttamente il payload, ad esempio, generic/shell/reverce_tcp o generic/shell/bind_tcp. La shell ottenuta in Metasploit può essere migliorata a Meterpreter utilizzando il modulo post/multi/manage/shell_to_meterpreter. Con Meterpreter, puoi automatizzare il processo di post-esecuzione. Ad esempio, il modulo post/multi/recon/local_exploit_suggester verifica la piattaforma, l'architettura e le entità necessarie per l'esploitazione e suggerisce moduli Metasploit per l'elevazione dei privilegi nel sistema target. Grazie a Meterpreter, l'elevazione dei privilegi a volte si riduce semplicemente all'esecuzione del modulo giusto, tuttavia l'hacking senza comprendere ciò che sta accadendo sotto il cofano non è considerato 'vero' (devi comunque scrivere un rapporto).

Strumenti

Gli strumenti di automazione per la raccolta locale delle informazioni ti faranno risparmiare molta fatica e tempo, ma da soli non sono in grado di identificare completamente il percorso per l'elevazione dei privilegi, soprattutto nel caso di sfruttamenti delle vulnerabilità del kernel. Gli strumenti di automazione eseguiranno per te tutti i comandi necessari per raccogliere informazioni sul sistema, ma è anche importante saper analizzare i dati ottenuti. Spero che il mio articolo ti sarà utile in questo. Certamente, ci sono molti più strumenti rispetto a quelli che elencherò di seguito, ma tutti fanno più o meno la stessa cosa: si tratta più di gusto.

Linpeas

Un tool abbastanza recente, il primo commit risale a gennaio 2019. Attualmente è il mio strumento preferito. La sostanza è che evidenzia i vettori di elevazione dei privilegi più interessanti. Concordi che è più comodo ricevere una valutazione esperta a questo livello piuttosto che analizzare dati grezzi monolitici?

LinEnum

Il mio secondo strumento preferito, raccoglie e sistema anche i dati ottenuti tramite enumerazione locale.

Linux-exploit-suggester (1,2)

Questo exploit analizzerà il sistema per verificare la presenza di condizioni adatte agli exploit. Fondamentalmente, eseguirà il lavoro identico al modulo Metasploit local_exploit_suggester, ma offrirà non moduli Metasploit, ma collegamenti ai codici sorgente di exploit-db.

Linuxprivchecker

Questo script raccoglierà e organizzerà per sezioni una grande quantità di informazioni che potrebbero essere utili per formare un vettore di elevazione dei privilegi.

In un'altra occasione esaminerò in dettaglio l'elevazione dei privilegi in Linux tramite suid/sgid.

Fonte: habr.com