Ignorando il comando / script specificato in / etc / passwd

Con lo script di esempio che hai pubblicato, l'utente con restrizioni può ad esempio imparare molto sul sistema, come i nomi di altri utenti e programmi installati. Per es.

What is your name?
> /home/* 
Hi /home/foo /home/bar /home/sadeq

Lo script attuale che hai potrebbe essere sfruttabile in modi simili, forse fino al punto in cui l'utente può ottenere un vero accesso alla shell.

Probabilmente potresti migliorare la situazione avviando il menu di login in un ambiente sandbox: non sarà necessariamente al 100% a prova di proiettile, ma almeno il sandboxing tapperà un sacco di buchi di sicurezza che l'autore dello script potrebbe aver lasciato.

Supponiamo che ci sia una backdoor (probabilmente non intenzionale)

Il valore predefinito /etc/passwd sulle workstation Sun dei primi anni '90 includeva una voce simile a questa:

games::0:0:games:/nopath:/bin/false

In altre parole, un account chiamato "giochi" senza password. Apparentemente il genio che ha avuto questa idea non ha avuto immaginazione e gli ha assegnato un uid e un gid zero (cioè radice e ruota). In generale, andava bene, poiché la home directory non aveva senso e la shell era impostata su un programma che veniva sempre chiuso con un errore. Inoltre, le impostazioni predefinite per qualsiasi accesso tramite rete - telnet, rlogin, rcp, ftp - sono state impostate per impedire l'accesso da qualsiasi uid zero. C'era una voce passwd separata per root, con una password, una directory home e una shell impostate correttamente.

Questo significa che se hai provato ad accedere come giochi, si verifica quanto segue:

• Effettuare l'accesso mentre i giochi nella console avrebbero inizialmente avuto successo, ma poi generare la shell /bin/false , che usciva immediatamente.
• L'uso di telnet o rlogin negherebbe completamente il login. Anche se fosse riuscito, la shell /bin/false si chiuderà immediatamente.
• FTP e scp non usano shell, ma sono state configurate per negare l'accesso a uid zero, quindi non è possibile accedere in questo modo.
• Un accesso GUI avvia i servizi GUI predefiniti, inclusi un gestore finestre, un client orologio e un terminale. Quest'ultimo uscirà immediatamente perché il suo guscio figlio uscirà immediatamente. Quindi otterresti uno schermo vuoto ad eccezione di un orologio. (Altro su questo sotto ...)
• Se davvero avevi per accedere come root, dovresti farlo dalla console, o prima da rlogin / telnet come un altro utente su quella macchina e poi su root . In entrambi i casi utilizza la voce root passwd piuttosto che la voce passwd dei giochi, e quindi funziona come dovrebbe funzionare root.

Quindi l'account di giochi sembrava fallire sempre, a meno che tu non abbia fatto un login GUI. In quel caso, l'unica cosa che appariva era l'orologio. Tuttavia, è possibile fare clic con il pulsante destro del mouse sullo sfondo per ottenere un menu principale, con un elenco di programmi fornito dalla fabbrica che gli utenti normalmente personalizzerebbero da soli. (La personalizzazione del menu non ha funzionato per l'account di gioco, non ricordo esattamente perché). Potresti provare a visualizzare più finestre di terminale, il che fallirebbe. C'era un gioco di puzzle (che potrebbe essere stato l'impulso per l'account in primo luogo). Un'altra scelta era uscire. E poi c'era lo strumento di debug grafico, dbxtool .

dbxtool era un frontend grafico per il debugger simbolico dbx , simile al gdb di oggi. Essendo zero, è possibile collegare e controllare qualsiasi processo sul sistema, sebbene ciò non sia stato utile in quanto i programmi forniti da Sun sono stati compilati senza simboli. Potresti avviare una shell, ma questa userebbe la tua variabile di ambiente SHELL , che era /bin/false . Tuttavia, potresti anche cambiare le variabili ambientali! Ciò significava che si poteva ottenere una shell di root come segue:

1. Accedi tramite la GUI come giochi, senza password.
2. Fai clic con il pulsante destro del mouse per visualizzare il menu principale.
3. Inizia un dbxtool .
4. setenv SHELL /bin/sh
5. (Facoltativo) setenv HOME /
6. Avvia una shell con !
7. Poiché il terminale non è impostato, fai stty sane

Voila, root shell senza password!

Quindi, non dare per scontato che un utente non possa scappare da una shell non valida.

Non puoi ignorare l'esecuzione dello script. Questa è la tua shell di login e verrà avviata ogni volta che accedi. E come shell di login , ti disconnetterò ogni volta che finisce. Ma puoi usare stranezze, errori e incongruenze sulla shell di login per uscire.

Una cosa che potresti fare è uscire in una shell usando qualsiasi opzione nel menu. Se il menu ti consente di avviare vim , less , more o qualche altro comando, puoi teoricamente liberarti. Se l'sysadmin è esperto, questi comandi useranno le loro versioni limitate e non funzioneranno.

Ricordo una sfida di wargame in cui c'era un caso simile: la shell indicava qualcosa che semplicemente stampava un output usando il comando more , quindi interrompeva la sessione. Tuttavia, dal momento che più presenta un editor di testo incorporato (in questo caso specifico era vi), è stato sufficiente ridimensionare la finestra del terminale da cui si stava effettuando la connessione in modo che venga attivato altro, quindi utilizzarlo per sfuggire alla shell.

Quindi, la risposta dipende da cosa fa il tuo script. Controlla le pagine man per ciascuno dei comandi in esecuzione per evitare una vulnerabilità.

TLDR: Lo script che hai citato è sicuro!

Ma comprendendo che in produzione si può usare una versione diversa, si dovrebbe essere consapevoli dei seguenti concetti:

1. Se la 'lettura' è vulnerabile all'iniezione di comando. Se è vulnerabile, quindi 'nome' valore come 'Bob; cat / etc / passwd ' potrebbe restituire il contenuto del file passwd e ' Bob & & / bin / bash -i ' potrebbe dare una sessione bash interattiva.

Domande del genere erano già state poste, per esempio qui:

link

La risposta dice "No, non vulnerabile", a causa di:

"(..) modern shells parse the statement prior to any variable substitution, and are thus unaffected by this attack."

Quindi nel tuo esempio l'input dell'utente da "leggere" non può essere ignorato dalla shell standard.

2. Dove viene analizzato l'input?

Il tuo script è sicuro, perché "echo" non fornisce alcuna tecnica di escape (almeno non nota). Ma sii consapevole dell'uso di binari "pericolosi" come menzionato in f.e. qui:

link

Se l'input dell'utente è analizzato da: man | less | more, awk, find, nmap, python | php | perl, bash | sh stesso, quindi è possibile l'escape, garantendo shell completamente interattiva ( Ho appena provato con less, python e find).

Se inserisci l'input solo per echo, come nell'esempio, sei OK.

3. Se il tuo input è usato all'interno del comando shell con asterischi (*), come: tar * o ls *

Non riesco a immaginare quando potrebbe essere utile nel tuo scenario, ma è sempre meglio menzionarlo. Se questo è un caso, per favore acquisisci familiarità con la seguente scrittura:

link

Un comportamento del genere potrebbe anche portare a sfuggire allo script.