Prevenzione delle password dell'utente memorizzate come testo normale nella cronologia di bash

3

Dire che voglio trovare la password di un account sudoer per utente Linux. Supponiamo che usi una password complessa. Supponiamo che io abbia accesso fisico alla macchina. Posso ottenere il suo passwd e il suo file shadow e brute-force per giorni, o semplicemente ottenere una copia del suo file di storia di bash e usarlo come un elenco di parole.

Non sono un hacker, ma questo metodo ha funzionato molte volte quando volevo dirottare l'account di qualcuno. Nella mia apertura, molte persone digitano accidentalmente la password sulla riga di comando, specialmente se non toccano il tipo.

Lolz, non tocchi nemmeno il tipo. Né gli utenti dei sistemi che gestisco. Come posso assicurarmi che la mia password super-strong non sia archiviata come testo normale nel mio .bash_history ?

So che posso continuare a cancellare la cronologia di bash, ma ci sono altri mezzi?

    
posta daltonfury42 02.10.2015 - 15:14
fonte

3 risposte

3

Non puoi, e non dovresti provare per i seguenti motivi:

  1. Capacità tecnica imperfetta (semantica)
  2. Capacità tecnica imperfetta (registrazione centralizzata)
  3. Vettori alternativi (tabella dei processi)
  4. Best practice (insegnare correttezza)

Abilità tecnica imperfetta (semantica)

Supponiamo che tu voglia effettivamente avere un file di cronologia, esiste per un motivo; ti aiuta a ricordare i comandi che hai digitato, a ripetere i comandi per riferimento, ecc. ecc. In questo caso, vuoi rimuovere le password erroneamente inserite. Come si fa a farlo?

Potresti avere un elenco di password in chiaro che cerchi nei file di cronologia di bash .... ma hai un elenco di password in chiaro sul tuo sistema.

Potresti cercare comandi come "sudo" e "su" e provare a rimuovere le cose dopo di loro ... ma la cosa che succederà è che qualcuno digiterà "sudp" per errore, quindi digiterà la password prompt, e il filtro non lo noterà a causa del molto errore di battitura che ha portato all'esposizione della password.

In breve, il computer non è abbastanza intelligente da filtrare le voci di password inappropriate; questo è un problema di significato semantico.

Capacità tecnica imperfetta (registrazione centralizzata)

In bash 4.1, hanno introdotto la possibilità di copia i log della cronologia di tutti su syslog . Questa era una versione legittimata della funzionalità che le persone avevano hackerato, applicato a patch e script in bash (e altre shell) per anni . Se qualcun altro amministra la tua macchina - ad esempio, il gruppo IT al lavoro - allora potresti non avere il controllo sul fatto che le tue linee di comando vengano registrate, in silenzio, senza che tu lo sappia mai.

Non è solo bash. Il demone auditd su Linux può essere configurato per registrare comandi e argomenti:

# grep oops /var/log/audit/auditd.log
type=EXECVE msg=audit(1443795447.953:2387443): argc=6 a0="sudo" a1="oops" a2="i" a3="typed" a4="my" a5="password"
#

Questa è un'impostazione a livello di sistema, operativa tramite il kernel, completamente estranea a qualsiasi shell che utilizzi e indipendentemente dalle impostazioni della cronologia che potresti aver scelto per te.

Vettori alternativi (tabella dei processi)

Tutto ciò che scrivi sulla riga di comando può comparire nella tabella dei processi, motivo per cui gli strumenti che usano le password richiedono che vengano inseriti in modo interattivo. Se si incasinano (come nell'esempio sudo sopra) e li si inserisce come argomenti, sono lì per qualcuno a prendere l'elenco dei processi - e non è così difficile per qualcuno scrivere una mietitrice che estrae le righe di comando dal tabella dei processi.

Best practice (insegnare correttezza)

Ognuna di queste obiezioni ha avvertenze ... "Se non voglio continuare a utilizzare un file di cronologia", "Se il mio amministratore di sistema è hands-off", "Se nessuno sta guardando attentamente la tabella dei processi" .. .. Ma la mia definizione di "buone pratiche" è "roba che fai perché non puoi fare affidamento su altre cose andando come vorresti che fossero". Quindi le best practice sono semplicemente supporre che qualsiasi password digitata in modo errato dove non dovrebbe essere stata compromessa, per cambiarla immediatamente e per andare avanti con la tua vita.

Qualsiasi "soluzione" che potresti implementare è parziale e soggetta a guasti al di fuori della sfera di rilevamento dell'utente. Preferirei non dare alla gente la falsa impressione di essere più al sicuro di quello che sono.

Mi rendo conto che addestrare le persone a farlo è difficile. Diamine, addestrare le persone a fare qualsiasi cosa è difficile, e la sicurezza è doubleplushard. Ma è la risposta giusta.

    
risposta data 02.10.2015 - 16:24
fonte
2

Beh, il metodo che hai descritto (cracking degli hash nel file shadow) non può essere prevenuto in quanto Linux non è stato progettato per impedire agli aggressori con accesso fisico alla macchina.

Se vuoi eliminare la cronologia di bash (al logout), inserisci quanto segue nei file ~ / .bashrc e ~ / bash_logout :

cat /dev/null > ~/.bash_history && history -c && exit
    
risposta data 02.10.2015 - 15:28
fonte
0

Modifica il file .bashrc :

nano ~/.bashrc

Cambia i valori di questi due parametri in:

HISTSIZE=0
HISTFILESIZE=0

HISTSIZE is the number of lines or commands that are stored in memory in a history list while your bash session is ongoing.

HISTFILESIZE is the number of lines or commands that (a) are allowed in the history file at startup time of a session, and (b) are stored in the history file at the end of your bash session for use in future sessions.

    
risposta data 02.10.2015 - 15:39
fonte

Leggi altre domande sui tag