Test di un ambiente chroot per le vulnerabilità di escalation dei privilegi

6

Sto cercando dei buchi nella mia attuale implementazione di una prigione chroot che ho implementato per un gruppo di utenti. C'è qualcosa che posso fare meglio qui?

Ho utilizzato i seguenti pacchetti: RHEL6 openSSH jailkit

L'utente esegue una shell standard, non la shell specifica del jailkit, ma ho configurato openSSH per avviare gli utenti chroot tramite la direttiva MatchGroup.

Solo l'accesso ssh a questo server è abilitato.

Ho utilizzato jailkit per costruire la stessa prigione e risolvere le dipendenze della libreria necessarie.

Costruisco la prigione usando copie di tutti i file richiesti invece dei collegamenti fisici.

Ogni utente ha il proprio jail e il mount point per le jail è montato su nosuid.

Gli utenti non richiedono nulla che necessiti di SUID, quindi mi prendo cura di rimuovere tutti questi bit SUID all'interno della prigione dell'utente, non che importi molto con il flag nosuid sulla montatura.

Tutti i file al di fuori della directory home dell'utente sono di proprietà di root.

Quello che segue è l'elenco completo di comandi, percorsi e dispositivi che ho messo a disposizione degli utenti nella prigione. Roba abbastanza standard:

/ dev / random / dev / urandom / dev / null / bin / vi / bin / env / usr / bin / which / bin / nomehost / usr / bin / id / usr / bin / file / usr / share / misc / magic /lib/libnsl.so.1 /lib64/libnsl.so.1 /lib/libnss*.so.2 /lib64/libnss*.so.2 /etc/nsswitch.conf /etc/ld.so. conf / bin / sh / bin / bash / bin / ksh / bin / ls / bin / cat / bin / chmod / bin / mkdir / bin / cp / bin / cpio / bin / data / bin / dd / bin / echo / bin / egrep / bin / false / bin / fgrep / bin / grep / bin / gunzip / bin / gzip / bin / ln / bin / ls / bin / mkdir / bin / mktemp / bin / più / bin / mv / bin / pwd / bin / rm / bin / rmdir / bin / sed / bin / sh / bin / sleep / bin / sync / bin / tar / bin / touch / bin / true / bin / uncompress / bin / zcat / etc / motd / etc / issue /etc/bash.bashrc / etc / bashrc / etc / profile /usr/lib/locale/en_US.utf8 / usr / bin / awk / usr / bin / bzip2 / usr / bin / bunzip2 / usr / bin / ldd / usr / bin / less / usr / bin / clear / usr / bin / cut / usr / bin / du / usr / bin / find / usr / bin / testa / usr / bin / less / usr / bin / md5sum / usr / bin / nice / usr / bin / sort / usr / bin / tac / usr / bin / tail / usr / bin / tr / usr / bin / sort / usr / bin / wc / usr / bin / watch / usr / bin / whoami / usr / bin / m c / usr / bin / mcedit / usr / bin / mcview / usr / share / mc / etc / terminfo / usr / share / terminfo / usr / bin / joe / usr / bin / nano / usr / bin / vi / usr / bin / vim / etc / vimrc / etc / joe / usr / share / vim

Per complicare le cose, ho esposto un automount all'interno della home directory dell'utente incarcerata che monta un filesystem remoto FUSE / sshfs come root con le seguenti opzioni: ro, noexec, nodev, nosuid, nonempty, noatime, follow_symlinks, allow_other , auto_cache, max_read = 65536
Ogni utente ottiene la propria voce di automount codificata in modo rigido sulla home page dell'utente prigione.

Ho compilato tutte le gesta che ho potuto trovare intese per uscire dal chroot e intenzionalmente metterle in prigione. Senza rimuovere la direttiva "nosuid" dal jail mount, possedere il file su root e impostare il bit SUID su uno di essi, non sono riuscito a uscire.

Qualcos'altro che mi manca?

    
posta Daren Schwenke 16.05.2012 - 21:44
fonte

1 risposta

4

bash può stabilire connessioni tcp, non dovresti dimenticare di controllare il firewall. Forse vorresti eliminare tutto il traffico dagli utenti con iptables -A OUTPUT -m owner --uid-owner youruser -j DROP ma questo non dovrebbe sostituire il tuo firewall.

Se l'utente è in grado di aprire una connessione, può eseguire la scansione della rete e sfruttare i servizi vulnerabili per rompere la prigione o compromettere i server.

    
risposta data 16.05.2012 - 23:03
fonte

Leggi altre domande sui tag