È possibile prelevare una sessione SSH dalla memoria?

Question

È possibile prelevare una sessione SSH dalla memoria?

#1 da (4 voti)

3

Sono consapevole che le chiavi SSH possono essere prelevate dalla memoria del client. Tuttavia, nel caso di SSH che richiede un secondo fattore come Duo / Yubikey, rubare la chiave non sarebbe sufficiente. Un utente malintenzionato con accesso completo (RAT, con privilegi elevati) potrebbe rubare una sessione ssh aperta esistente dalla memoria?

E se no, perché no?

(se necessario per questo esempio, diciamo che il client sta eseguendo l'ultima versione di MacOS e che il server sta eseguendo l'ultima versione di Ubuntu, ecc.)

ssh

posta seanieb 11.01.2017 - 22:08

fonte

1 risposta

Leggi altre domande sui tag ssh

Sta prendendo i dati di social network legittimi per una carta di credito? E '"normale" trovare le procedure nel mezzo di un file .mov con un disassemblatore?

score 4 · Accepted Answer

L'utente malintenzionato riceve dalla memoria le chiavi di sessione e altre informazioni di stato, ma quelle chiavi sono valide solo per quella singola connessione TCP. Per una nuova connessione TCP, il server genererà nuovi nonce e tutte le funzionalità anti-replay di SSH kick in.

Quindi l'attaccante deve dirottare la connessione TCP, che il server identifica tramite l'indirizzo IP del client, la porta TCP del client e le informazioni sul numero di sequenza. Gli attacchi possono essere classificati in base alla distanza tra il client originale e la connessione TCP presa:

Nel processo ssh stesso. Se l'utente malintenzionato ha diritti di superutente in cui ssh è in esecuzione, può sostituire il ssh binario con la propria copia compromessa che l'utente innocente esegue, o modificarne il comportamento tramite l'iniezione di codice (ad esempio, le iniezioni non modificano il binario su disco, quindi le firme digitali non rilevano la manomissione).
In un secondo processo sulla stessa macchina. È facile continuare la connessione TCP da qui perché i pacchetti inviati dal server vengono già instradati qui.

a. Tutte le informazioni relative alla connessione TCP sono mantenute dal livello dei socket del sistema operativo e mentre i dettagli dello spostamento di un socket TCP tra processi sono specifici del sistema operativo, i socket non hanno affinità di processo in alcun sistema operativo POSIX, poiché possono essere utilizzati da più processi in una volta se ereditati durante spawn o fork.

b. Evitando il livello socket utilizzato dalle applicazioni e acquisendo / modificando / iniettando pacchetti nello stack o nel driver di rete, ad esempio usando iptables o libpcap.
In un'altra macchina posizionata per attacchi MITM. L'unica cosa che è assolutamente necessaria oltre a ottenere una copia delle chiavi di sessione e lo stato stesso è continuare a utilizzare lo stesso indirizzo IP in modo che il server pensi che la stessa connessione TCP sia in corso. Questa è la stessa cosa necessaria per man-in-the-middle, o seduti davvero sul percorso, o almeno compromettendo un router sul percorso per inviare pacchetti trasmessi dal server SSH all'autore dell'attacco.