Ancora un post sui bersagli di Cracca al Tesoro. Parliamo questa volta del bersaglio due, posizionato presso la reception della Fiera. L’access point con SSID “CATGE2012-2” era protetto da una WEP 64bit la cui chiave era “1111111111”.
Il primo server, con indirizzo 172.16.12.1/25, era un sistema linux con porte ssh e web aperte. La vulnerabilità inserita era exploitabile individuando l’utente “guest” con password “guest”.
Nella home dell’utente “guest” si trovava il file “indizio”.
Ma non era tutto qui…
Infatti, il file indizio, pur essendo listabile, non poteva venire aperto per via dei permessi non concessi all’utente guest.
Guardando bene, si notavano altri due file, “badcat” e “badcat.c”, presumibilmente un eseguibile ed il suo sorgente.
Purtroppo anche il sorgente aveva il setuid impostato. Esaminando l’eseguibile si scopriva che il programma serviva banalmente a leggere un file con altri permessi, grazie al setuid impostato. Tentando di leggere il file indizio, però la risposta era picche. Miglior fortuna si aveva tentando di aprire il file sorgente. A questo punto, si poteva capire che per leggere il file indizio era sufficiente, ad esempio, creare un link al file indizio e chiedere a badcat di aprirlo con “badcat link_file_indizio”.
L’indizio richiedeva come azione l’acquisto di un gadget, ma di questo (la storia della radio impermeabile) ne abbiamo già parlato in precedenza.
Due parole su setuid, prese a prestito dalla lista PLUTO-help, perché mi sembra davvero spiegato in modo esemplare!
PERCHE' IL SETUID E' PERICOLOSO (link al testo originale) Il bit setuid e` uno dei bit che codificano i permessi dei file che sono 12. I 9 bassi li conoscono credo tutti e sono quelli che regolano i permessi di lettura, scrittura ed esecuzione. Rimangono i 3 bit alti Set UID Set GID Sticky Linux usa sticky solo per le directory (vedi man chown). Gli altri due indicano al sistema che l'esecuzione del programma non deve avvenire con l'uid dell'utente collegato ma con l'uid del proprietario del file. L'uid e` l'identita` utilizzata, per il sistema c'e` anche quella reale, per cui un programma e` comunque in grado di conoscere l'id dell'utente che lo usa se serve). Scopo dell'ambaradan ? Ci sono risorse che non devono rimanere liberamente accessibili ma che l'utente deve poter utilizzare, ad esempio, con determinati programmi. X e` uno di questi. "WOW, quindi se io metto setuid un certo programma posso usarlo anche da utente peone..." ## ## ###### ## ## ## ###### ## #### ## ## ## ## #### ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #### ## ## ## #### ## ## ## ## ###### ## ## ## ###### ## Il bit setuid non va usato se non quando e` veramente l'unica risorsa, sopratutto se l'utente proprietario del file e` root. 1) Certe operazioni sono lasciate solo a root perche' sono critiche per il sistema ed il loro uso deve avvenire in modo "protetto da abusi". Se si mette setuid root un file, questa protezione salta. Cio` e` male (E. Spengler). Ci sono vari meccanismi (sudo, o file di configurazione come shutdown.allow descritto in man shutdown) per delegare ad alcuni utenti certe operazioni senza peraltro permettere a loro di diventare root a tutti gli effetti. 2) Mettere setuid root un file che generalmente non lo e` puo` aprire falle di sicurezza. Ad esempio, e` poco probabile che tale file sia stato sottoposto ad auditing per l'uso di tecniche di programmazione poco sicure (i.e. buffer overflow). C'e` gia` abbastanza da tenere d'occhio per quello che "istituzionalmente" gira con l'uid 0:0. Il programma potrebbe avere una shell escape: "Mi metto setuid less cosi` non ho problemi di permessi. Ho tutti i servizi di rete che girano come nobody, anche se li sfondano...". Peccato che la prima cosa che si fa quando si sfonda una macchina con utente diverso da root la prima cosa che si va a vedere sono i file setuid root: "WOW", esclama l'intruso, "less setuid!", fa less /etc/motd, preme !, scrive sh, preme return ed ha una shell di root. Non parliamo del fatto che se un utente riesce ad avere la scrivibilita` di un file setuid allora ha la porta aperta verso l'account 0:0: copia il file incriminato, tanto per avere un backup e cancellare le prove. cat /bin/sh > file_incriminato esegue file incriminato cat copia_backup > file_incriminato #via le prove Sembra uno scenario stupido ma e` gia` successo perche' il sistemista era troppo facilone. Oh, se fate questa prova sotto Linux: fate uno shell script che contenga il solo comando id diventate root e fate chmod 4755 file_di_prova tornate utenti richiamate il file vi ritornera` i vostri dati di utente normale e non quelli di root. Il perche' e` banale. Chi ha scritto la bash sa che gli shell script setuid root sono estremamente pericolosi, e quindi per default bash va a vedere chi siete veramente e ripristina la vostra identita`. E' anche vero che puo` essere _realmente_ necessario avere uno shell script setuid. bash vi chiede di "esserne consci" e richiede il parametro -p sulla command line, parametro che sta a dire "sono perfettamente conscio che potrebbe essere una cazzata, ma hai l'ordine di eseguirlo setuid". Si puo` fare, ma e` meglio non farlo. Si puo` percuotere i propri geniali con un martellone, ma e` meglio non farlo. E` M E G L I O N O N F A R L O ! ! ! E` M E G L I O N O N F A R L O ! ! ! E` M E G L I O N O N F A R L O ! ! ! E` M E G L I O N O N F A R L O ! ! ! E` M E G L I O N O N F A R L O ! ! ! E` M E G L I O N O N F A R L O ! ! ! E` M E G L I O N O N F A R L O ! ! !
Illuninante, vero?
🙂
