Errore Meterpreter SSL dopo il sonno

Question

Errore Meterpreter SSL dopo il sonno

#1 da (1 voti)

3

Mentre uso intensamente metasploit sui pentests, comincio a usare il comando meterpreter sleep . Capisco che questo non è un metodo di persistenza, ma a volte è molto conveniente.

Purtroppo, quando le sessioni si sveglia non riescono a stabilire una connessione con questo errore:

OpenSSL::SSL::SSLError SSL_accept returned=1 errno=0 state=unknown state: tlsv1 alert protocol version

Se mando sei o sette sessioni a dormire, ne ricevo solo uno o due dopo il risveglio. Nessuno ama le sessioni morte.

Creo sessioni con exploit/windows/smb/psexec e il carico utile è windows/x64/meterpreter/reverse_tcp . So che i payload TCP usano la crittografia SSL, invece di htHTTPp, ma non riesco a capire perché fallisce.

La versione di MSF è Framework: 4.12.23-dev-e403df5 Console : 4.12.23-dev-e403df5 .
Inoltre, non aggiorno msf mentre le sessioni stanno dormendo. Inoltre, non viene rilevata alcuna differenza se più sessioni si svegliano a un LPORT o a più di un altro.

Qualcuno può aiutarti a risolvere questo problema, perché è molto fastidioso.

openssl metasploit meterpreter

posta lsass 01.10.2016 - 16:18

fonte

1 risposta

Leggi altre domande sui tag openssl metasploit meterpreter

Come gestire correttamente i certificati di sicurezza in asp.net (ws-federation) Perché questo attacco di iniezione XPATH fallisce e cosa sta succedendo sullo sfondo di un attacco?

score 1 · Answer 1

OpenSSL::SSL::SSLError SSL_accept returned=1 errno=0 state=unknown state: tlsv1 alert protocol version

Questa è una risposta OpenSSL comune quando il flusso TCP sotto l'handshake è interrotto. Dici che stai pentendo nel momento in cui questo accade, questo ha connotazioni di sicurezza della rete ma non quelle che probabilmente indovinerai all'inizio. Questa risposta è un'ipotesi basata sul vedere più volte l'errore.

Quando la tua sessione è addormentata, non invia pacchetti keepalive (cioè non invia ACK extra). Una tale sessione TCP "morta" verrà interrotta da un firewall statico, indipendentemente dal fatto che il firewall consideri la connessione valida (o innocua) o meno. Dal momento che stai pentendo, immagino che stai lavorando all'interno di una rete in cui sono presenti diversi firewall.

Perché un firewall stateful dovrebbe fare questo?

Oggi, i firewall senza stato sono praticamente una cronologia *, quindi tutti i firewall sono stateful, mantengono lo stato (e la cronologia) per ogni connessione che attraversa il firewall. Eseguono questo non solo per NAT ma per qualsiasi traffico che passa attraverso il firewall. Un firewall di questo tipo è vulnerabile a un attacco DoS lasciando troppe connessioni sospese e riempiendo la sua memoria. Per evitare che un firewall di stato abbia un timeout in base al quale viene interrotta la connessione sospesa (senza traffico durante il timeout).

Quando svegli la sessione SSL, invia un ACK. Ma il firewall ha abbandonato da tempo questa connessione dalla sua memoria e non ha alcuna conoscenza dell'esistenza della sessione TCP, quindi risponde con RST. L'RST provoca un errore di state=unknown dal livello SSL.

Il sistema sull'altro lato del firewall potrebbe essere a conoscenza della tua connessione e risponderebbe se ACK l'avesse raggiunto. Ma il firewall non lo lascerà passare.

Che cosa puoi fare a riguardo?

Non molto. È possibile eseguire un proxy stateful sulla propria macchina che continuerà a inviare TCP keepalive su un lato (all'esterno), ma non richiederebbe keepalive sull'altro lato (all'interno, loopback).

Tuttavia, se, ad esempio, metti in pausa l'intera macchina, il proxy di stato non invierà ACK aggiuntivi, ma lo sconfiggerà (e renderà il debugging della connessione ancora più difficile che lo sia già solo con i firewall). / p>

_{* Un firewall stateless è vulnerabile agli attacchi banali (bypass), come la frammentazione IP del pacchetto SYN iniziale.}