Quali sono i rischi di SSHing per un host non affidabile?

18

Quando esegui SSH su un host che è stato compromesso (o completamente sostituito usando le chiavi del server rubato) da un utente malintenzionato con permessi di root, qual è la cosa peggiore che può capitare al client?

È noto che l'inoltro X presenta alcuni rischi e l'agente l'inoltro è ovviamente una cattiva idea in quello scenario, ma sono ci sono più problemi?

  • Quali informazioni possono essere acquisite sul client, oltre alle variabili di ambiente impostate da ssh (SSH_CONNECTION, tutto da ~ / .ssh / environment)?
  • Cosa si può ottenere con le sequenze di escape del terminale?
  • Quanto è difficile falsificare un logout (in risposta a CTRL + D, logout, ecc.) al client, provocando in tal modo un utente a eseguire comandi aggiuntivi con input potenzialmente sensibili sull'host remoto, come sudo con una password ? Il prompt del client può essere letto in remoto per rendere più convincente tale inganno?
  • Ci sono dei modi efficaci per prevenire questo inganno, come aliasing ssh a "ssh; echo somesecret"?
posta lxgr 28.06.2013 - 14:52
fonte

1 risposta

13

Intercettare i comandi di "logout" è facile sul server ostile. Intercettare il "Ctrl-D" richiede di assumere il controllo del terminale in modalità raw, ma non è un grosso problema.

La lettura dei contenuti del terminale potrebbe rivelarsi difficile. Terminali diversi implementano il proprio set di sequenze di controllo; xterm è noto per aver implementato molti di loro . Non vedo alcuna sequenza che permetta di leggere il contenuto del terminale; tuttavia, con le sequenze si può ancora fare un notevole disordine, come spostare la finestra, cambiare font e così via. Nei giorni precedenti, era possibile effettivamente creare xterm per creare file locali, anche se senza molto controllo sul nome del file (non ricordo i dettagli, ma probabilmente era con la funzione "file di registro" che potrebbe essere disabilitata durante la compilazione) tempo). Oltre a ballare, un xterm potrebbe anche essere fatto per cantare, con il "carattere di campana" - è più una cosa fastidiosa che un vettore di attacco, però.

Parlando di fastidio: a seconda del sistema client e della sua configurazione e dei driver grafici, un testo scorretto di scrolling del terminale ad alta velocità può quasi bloccare la console della vittima (nella mia esperienza, gnome-terminal e un gestore di finestre di composizione può trasformarsi in una brutta combinazione per questo).

Ancora in xterm, ci sono sequenze per manipolare gli appunti (cerca "manipola selezione" nella pagina di riferimento collegata sopra). Questo può essere sgradevole, sia per leggere che per scrivere. Vedi questa pagina per una discussione sui possibili problemi (un elenco di commenti di tracciamento dei problemi , da persone che discutono sulla possibilità di importare quel meccanismo in un emulatore di terminale chiamato mintty).

La conclusione generale è: non usare SSH in host non sicuri. Se lo fai, puoi farlo da rxvt-unicode , un fork rxvt dove l'autore ha fatto (tra le altre caratteristiche) alcuni tentativi di disabilitare sequenze di controllo "non sicure" per impostazione predefinita (possono essere ripristinate con il parametro della riga di comando "-insecure").

    
risposta data 28.06.2013 - 18:08
fonte

Leggi altre domande sui tag