🥇Io sono root. Approfondiamo l'elevazione dei privilegi in Linux

Nel primo trimestre del 2020 ho dedicato tempo alla preparazione per l'esame OSCP. La ricerca di informazioni su Google e i numerosi tentativi 'alla cieca' mi hanno portato via tutto il tempo libero. È stato particolarmente difficile capire i meccanismi di elevazione dei privilegi. Il corso PWK dedica molta attenzione a questo tema, ma ci sono sempre pochi materiali metodologici. Ci sono molti manuali online con comandi utili, ma non sono favorevole a seguire ciecamente raccomandazioni senza capire dove porterà.

Voglio condividere con voi ciò che ho appreso durante la preparazione e il superamento dell'esame (inclusi i periodici attacchi a Hack The Box). Ho provato un forte senso di gratitudine per ogni piccola informazione che mi ha aiutato a percorrere il cammino di Try Harder in modo più consapevole; ora è il mio momento di rendere omaggio alla community.

Voglio fornirti una guida su come ottenere privilegi elevati in OS Linux, che includa un'analisi dei vettori più comuni e delle relative tecniche utili. Spesso, i meccanismi per ottenere privilegi elevati sono relativamente semplici, mentre le difficoltà sorgono nella strutturazione e analisi delle informazioni. Perciò, ho deciso di iniziare con un'"escursione panoramica" e poi trattare ciascun vettore in articoli separati. Spero di farti risparmiare tempo nello studio dell'argomento.

Quindi, perché l'ottenimento di privilegi elevati è ancora possibile nel 2020, se i metodi sono noti da molto tempo? In realtà, se un utente gestisce correttamente il sistema, non dovrebbe essere in grado di ottenere privilegi elevati. Il principale problema globale che crea tali opportunità è dovuto a configurazioni insicure. La presenza di versioni obsolete di software nel sistema, che contengono vulnerabilità, è anche un caso specifico di configurazione insicura.

Ottenimento di privilegi elevati tramite configurazione insicura

Innanzitutto, comprendiamo la configurazione insicura. Iniziamo con il fatto che Gli specialisti IT utilizzano spesso manuali e risorse come stackoverflow, molti dei quali contengono comandi e configurazioni non sicure. Un esempio lampante è una notizia che il codice più copiato da stackoverflow conteneva un errore. Un amministratore esperto può notare l'errore, ma questo è nel mondo ideale. Anche i professionisti competenti possono commettere errori sotto carico di lavoro elevato. Immaginate che un amministratore stia preparando e concordando la documentazione per un nuovo appalto, mentre contemporaneamente si immerge in una nuova tecnologia che deve essere implementata nel prossimo trimestre, risolvendo nel frattempo compiti di supporto agli utenti. E in questo momento gli viene assegnato il compito di creare rapidamente un paio di macchine virtuali e distribuire su di esse i servizi. Qual è secondo voi la probabilità che l'amministratore non noti l'errore? Poi gli specialisti cambiano, ma le soluzioni temporanee rimangono, mentre le aziende cercano sempre di ridurre i costi, compresi quelli per gli specialisti IT.

Pseudo-shelly e jailbreak

La shell di sistema ottenuta in fase di exploit può spesso essere limitata, soprattutto se l'hai acquisita tramite un attacco all'utente del server web. Ad esempio, le restrizioni della shell possono impedire l'uso del comando sudo, generando l'errore:

sudo: nessun tty presente e nessun programma askpass specificato

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

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

Puoi chiedere: «Perché dovrei conoscere mille comandi, se posso usare uno solo, ad esempio per trasferire file?» La realtà è che i sistemi possono essere configurati in modo diverso, e su un determinato host potrebbe non essere installato Python, ma potrebbe esserci Perl. La maestria sta nella capacità di eseguire operazioni familiari in un sistema senza strumenti familiari. Un elenco completo delle possibilità è disponibile qui.

Una shell a basso privilegi può essere ottenuta usando comandi 1 e comandi 2 (è sorprendente, ma anche GIMP).

Visualizzazione della cronologia dei comandi

Linux raccoglie la cronologia di tutti i comandi eseguiti nel file ~/.bash_history. Se il server è attivamente utilizzato e la sua cronologia non viene pulita, c'è un'alta probabilità di trovare le credenziali in questo file. Pulire la cronologia è semplicemente scomodo. Se l'amministratore è costretto a selezionare comandi di dieci righe tramite , ovviamente gli sarà più comodo richiamare quel comando dalla cronologia piuttosto che reimmetterlo. Inoltre, molti non conoscono questo "hack". Se nel sistema sono presenti shell alternative come Zsh o Fish, esse gestiscono la propria cronologia. Per visualizzare la cronologia dei comandi in qualsiasi shell, è sufficiente digitare il comando history.

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

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

Ricerca delle password nel file system e attacchi a sistemi contigui

I file di configurazione di vari servizi possono essere accessibili in lettura dal tuo attuale utente. In essi possono trovarsi credenziali in chiaro — password per accedere a database o servizi correlati. La stessa password può essere usata sia per accedere al database che per l'autenticazione dell'utente root (credential staffing).
Capita che le credenziali trovate appartengano a servizi su altri host. L'evoluzione di un attacco all'infrastruttura attraverso un host compromesso non è inferiore allo sfruttamento di altri host. I sistemi correlati possono essere trovati anche 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 nei log

Nel caso in cui ci sia un'applicazione web sul host compromesso accessibile da Internet, è meglio escludere i suoi log dalla ricerca degli indirizzi IP. Gli indirizzi degli utenti del servizio su Internet saranno difficilmente 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 in cui accedono, basandosi sui log, possono essere di interesse.

Sudo

Il comando sudo consente all'utente di eseguire un comando nel contesto root utilizzando la propria password o addirittura senza di essa. Molte operazioni su Linux richiedono privilegi di root, ma lavorare come root è considerata una pratica assai inadeguata. È preferibile applicare autorizzazioni selettive per eseguire comandi nel contesto root. Tuttavia, molti strumenti Linux, tra cui i classici come vi, possono essere utilizzati per ottenere privilegi tramite metodi assolutamente legittimi. Per trovare il metodo più adatto, consiglio di consultare qui.

La prima cosa da fare, una volta ottenuto l'accesso al sistema, è eseguire il comando sudo -l. Questo mostrerà le autorizzazioni relative all'uso del comando sudo. Se l'utente è senza password (ad esempio, apache o www-data), è poco probabile riuscire a ottenere un'elevazione dei privilegi tramite sudo. Quando si utilizza sudo, il sistema chiederà la password. Non sarà possibile impostare una password tramite il comando passwd, poiché richiederà la password corrente dell'utente. Tuttavia, se sudo è disponibile, è essenziale cercare:

qualsiasi interprete, chiunque possa generare un shell (PHP, Python, Perl);
qualsiasi editor di testo (vim, vi, nano);
qualsiasi visualizzatore (less, more);
qualsiasi funzione di lavoro con il file system (cp, mv);
strumenti che hanno accesso a bash, interattivo o come comando eseguibile (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Ci sono molti manuali online che consigliano di raccogliere tutti i comandi suid/sgid, tuttavia raramente un articolo fornisce dettagli su cosa fare con questi programmi. Le opzioni di escalation dei privilegi, escludendo l'uso di exploit, possono essere trovate. qui. Inoltre, una serie di file eseguibili ha vulnerabilità specifiche per la versione del sistema operativo, ad esempio.

In un mondo ideale, bisognerebbe esaminare tutti i pacchetti installati almeno tramite searchsploit. Nella pratica, è opportuno fare ciò con i programmi più popolari come sudo. Esiste anche sempre la possibilità di utilizzare e mantenere lo sviluppo di strumenti automatizzati, che mettono in evidenza file eseguibili interessanti, dal punto di vista dell'escalation dei privilegi, con i bit suid/sgid impostati. Elencherò tali strumenti nella sezione corrispondente dell'articolo.

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

I compiti cron possono essere eseguiti nel contesto di diversi utenti, incluso root. Se è impostato un compito cron con un link a un file eseguibile, e questo è accessibile per la scrittura, può essere facilmente sostituito con un file dannoso e si può eseguire un'assegnazione di privilegi. Inoltre, per impostazione predefinita, i file con i compiti cron sono leggibili da qualsiasi utente.

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

La situazione è simile per init. La differenza è che i compiti in cron vengono eseguiti periodicamente, mentre in init — all'avvio del sistema. Per sfruttarli sarà necessaria un'adeguata riavvio del sistema, e alcuni servizi potrebbero non avviarsi (se non sono stati configurati per l'avvio automatico).

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

Si possono anche cercare file accessibili per la scrittura da parte di 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 attenzione il comando chmod. Tuttavia, sulla rete la maggior parte dei manuali descrive l'assegnazione di diritti massimi. L'approccio degli amministratori inesperti, "basta che funzioni", crea opportunità per l'elevazione dei privilegi. Se possibile, è meglio cercare nell'array dei comandi usi insicuri 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 shell. Possiamo tentare di forzare la password di questi utenti — non è escluso che attraverso l'utente compromesso si possa eventualmente ottenere l'elevazione dei privilegi.

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

Codice personalizzato

È importante esaminare attentamente i file eseguibili nella directory home dell'utente e del server web (/var/www/, se non è stata specificata un'altra). Questi file potrebbero rivelarsi soluzioni completamente insicure e contenere numerosi workaround. Certo, se hai qualche framework nella directory del server web, non ha senso cercare zero-day all'interno di esso durante un pentest, ma è consigliabile trovare e studiare le modifiche personalizzate, i plugin e i componenti.

Per aumentare la sicurezza, è meglio evitare l'uso di credenziali nei propri script e di funzionalità potenzialmente pericolose, come la lettura di /etc/shadow o la manipolazione di id_rsa.

Elevazione dei privilegi tramite sfruttamento di vulnerabilità

Prima di tentare di elevare i privilegi tramite sfruttamento, è importante comprendere il trasferimento di file verso l'host target. Oltre ai mezzi familiari come ssh, ftp, http (wget, curl), c'è un intero «zoo» di possibilità.

Per migliorare la sicurezza del sistema, aggiorna regolarmente a versioni stabili e aggiornate versioni, e cerca di utilizzare distribuzioni progettate per l'Enterprise. Altrimenti, raramente, si possono verificare situazioni in cui l'upgrade apt rende il sistema non funzionante.

Esecuzione di servizi avviati nel contesto dell'utente root

Alcuni servizi Linux funzionano con privilegi dell'utente root. Possono essere trovati utilizzando il comando ps aux | grep root. In questo caso, il servizio potrebbe non essere annunciato in rete e essere accessibile localmente. Se ha exploit pubblici, possono essere applicati senza problemi: la caduta del servizio in caso di fallimento è molto meno critica rispetto a quella del sistema operativo.

ps -aux | grep root # Linux

Il caso migliore è considerare il funzionamento di un servizio compromesso nel contesto dell'utente root. L'esecuzione del servizio SMB offre accesso privilegiato SYSTEM nei sistemi Windows (ad esempio, tramite ms17-010). Tuttavia, nei sistemi Linux questo è poco comune, quindi è possibile spendere molto tempo per aumentare i privilegi.

Sfruttamento delle vulnerabilità del kernel Linux

Questo è un percorso da seguire per ultime. Un'errata esecuzione può portare al crash del sistema e, in caso di riavvio, alcuni servizi (inclusi quelli attraverso cui si è ottenuto il shell iniziale) potrebbero non avviarsi. A volte, l'amministratore dimentica semplicemente di applicare il comando systemctl enable. In più, questo causerà molto malcontento per il vostro lavoro se l'esecuzione non è stata concordata.
Se avete deciso di utilizzare i codici sorgente da exploitdb, assicuratevi di leggere i commenti all'inizio dello script. Oltre ad altre cose, di solito viene spiegato come compilare correttamente questo exploit. Se non avete voglia di farlo o se i tempi di consegna erano «ieri», potete cercare repository con exploit già compilati. ad esempio. Tuttavia, bisogna capire che in questo caso si ottiene un gatto in un sacco. D'altra parte, se il programmatore comprendesse fino al byte come è fatto un computer e il software che utilizza, non scriverebbe nemmeno 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/reverse_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-sfruttamento. Ad esempio, il modulo post/multi/recon/local_exploit_suggester controlla la piattaforma, l'architettura e le entità necessarie per l'escalation e suggerisce moduli Metasploit per l'elevazione dei privilegi nel sistema target. Grazie a Meterpreter, l'elevazione dei privilegi talvolta si riduce all'esecuzione del modulo corretto; tuttavia, hackerare senza comprendere ciò che accade dietro le quinte non è considerato "autentico" (dovrai ancora scrivere un rapporto).

Strumenti

Gli strumenti di automazione per la raccolta di informazioni locali ti faranno risparmiare un grande quantitativo di fatica e tempo, ma di per sé non sono in grado di identificare completamente i percorsi per l'elevazione dei privilegi, soprattutto nel caso di sfruttamento delle vulnerabilità del kernel. Gli strumenti di automazione eseguiranno per te tutti i comandi necessari per raccogliere informazioni sul sistema, ma è importante anche sapere analizzare dati ottenuti. Spero che il mio articolo vi sarà utile. Certamente, ci sono molti più strumenti di quelli che menzionerò qui sotto, ma tutti fanno più o meno la stessa cosa: è soprattutto una questione di preferenze.

Linpeas

Uno strumento piuttosto recente, il primo commit risale a gennaio 2019. Attualmente è il mio strumento preferito. La sua essenza è che evidenzia i vettori più interessanti per l'elevazione dei privilegi. Conviene avere una valutazione esperta a tale livello piuttosto che districarsi tra dati grezzi e monolitici.

LinEnum

Il mio secondo strumento preferito, anch'esso raccoglie e sistematizza i dati ottenuti attraverso l'enumerazione locale.

Linux-exploit-suggester (1,2)

Questo exploit analizzerà il sistema per verificare se ci sono condizioni adatte per exploit. Fondamentalmente, svolgerà un compito identico al modulo Metasploit local_exploit_suggester, ma offrirà non moduli Metasploit, ma link a codice sorgente di exploit-db.

Linuxprivchecker

Questo script raccoglierà e sistematizzerà una grande quantità di informazioni, suddividendole in sezioni, che possono essere utili per formare un vettore di elevazione dei privilegi.

In un'altra occasione esaminerò in dettaglio elevamento dei privilegi nel sistema operativo Linux tramite suid/sgid.

Fonte: habr.com