Piviul writes: > Gian Uberto Lauri scrisse in data 13/12/2013 11:54: > > Perché di default sudo fa il caching delle credenziali: con la > > configurazione di default, per alcuni minuti sudo non chiede > > nuovamente l'autenticazione (su -c non lo fa mai). > sai che ho letto la tua mail 2 o 3 volte ma non sono riuscito a capire > dove sia il problema di sudo? Ho capito che riguarda la cache ma poi... > > [...]
Provo ad indicartelo con una scala temporale con un esempio rozzo senza ipotizzare come una cosa viene fatta. 1 - l'attaccante riesce a far eseguire il cavallo di troia. 2 - il cavallo di troia piazza "l'imboscata" 3 - L'imboscata si pone in attesa, diciamo che riesce a prendere il controllo dello stdin e stdout della shell, ma non si mette a fare logging (per non creare tracce della sua presenza). Fa passare tutto l'input dell'utente e si preoccupa di non fare vedere all'utente quello che non deve vedere. 4 - periodicamente prova a lanciare - ad esempio - "sudo ls" e a vedere se ottiene una richiesta di prompt, nel qual caso manda un carattere di terminazione al sudo che ha lanciato e nasconde l'output all'utente; se invece si ha un risultato positivo grazie al fatto che l'utente ha usato sudo e le credenziali sono in cache, allora può "dare il via all'invasione" avendo la possibilità di agire con l'id 0:0 . Questo non è un attacco in grado di dare risultati immediati. Richiede molta pazienza ed un numero sufficientemente elevato di vittime (per ottenere in parallelo quello che è lungo ottenere in serie). Esattamente come stuxnet. Avendo a disposizione l'immensa base di untenti di sistemi Windows hanno lanciato l'attacco. Questo ha cominciato a diffondersi a destra ed a sinistra (usando exploit acquistati al mercato nero - a qanto pare) fintanto che un giorno, passando chissà quante macchine e chiavette USB, una copia di stuxnet -delle migliaia e migliaia attive - ha raggiunto una macchina bersaglio e ha fatto il suo dovere. > > fare un piccolo cavallo di troia > > che si metta in attesa del momento in cui vede che la cache delle > > credenziali sia attiva per poi iniettare codice malevolo sfruttando > > sudo e la configurazione 'utente ALL=(ALL)ALL'. > AFAIK la cache delle credenziali di sudo può > essere utilizzata soltanto dal terminale dalla quale viene usata... > direi che è molto difficile per il cavallo di troia diventare figlio del > terminale in cui hai inserito il comando sudo Le tue informazioni non sono errate e scrivere l'attaccante in modo corretto non è facile. Per questo ho parlato di una larga fascia di utenti: questi sono attacchi che richiedono risorse per essere sviluppati e devono quindi generare un "ritorno economico" che puoi ottenere solo se hai una grande quantità di bersagli. Peraltro un paio di ideuzze le ho. Tutto starebbe a saperle "confezionare" bene: quando ancora gli AT&T 3B2 erano una macchina abbastanza recente un mio amico riuscì ad ottenere una shell setuid col mio user semplicemente facendomi credere di aver trovato quello che cercavo. Spero di essere riuscito a spiegarmi meglio. -- /\ ___ Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_____ African word //--\| | \| | Integralista GNUslamico meaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso... Debian" Warning: gnome-config-daemon considered more dangerous than GOTO -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21163.2381.646174.36...@mail.eng.it