3

While heavily using metasploit on pentests, I start using sleep meterpreter command. I understand that this is not a persistence method, but sometimes it's very convenient.

Sadly, when sessions wake up they fail to establish connection with this error: 

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

If I send six or seven session to sleep, I get only one or two after waking up. No one loves dead sessions.

I create sessions with exploit/windows/smb/psexec and the payload is windows/x64/meterpreter/reverse_tcp. I know that TCP payloads use SSL encryption, instead of htHTTPp, but I can' t elaborate why it fails.

MSF version is Framework: 4.12.23-dev-e403df5 Console : 4.12.23-dev-e403df5.
Also, I don't update msf while sessions are sleeping. Also, there is no difference noticed if multiple sessions wakes up to one LPORT or multiple ones.

Can any one help to solve this problem, cause it's very annoying.

Improve this question
2
  • I'm not yet in a position to give you a meaningful answer to this. I've had the same issue in a number of cases with staged TCP payloads. Note that HTTP/S payloads do not have this problem for obvious reasons. I'm currently investigating why this fails with staged TCP and hope to have a response for you soon. In the mean time, the best workaround is to have a staged listener and a stageless listener side by side where the staged listener's configuration points to the stageless one. I'll write up a quick blog about it while we find out the real answer!
    – OJ.
    Commented Oct 5, 2016 at 0:40
  • 1
    Please take a look at this: buffered.io/posts/staged-vs-stageless-handlers
    – OJ.
    Commented Oct 5, 2016 at 3:10

1 Answer 1

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

That is a common OpenSSL response when the TCP stream below the handshake is broken. You say you are pentesting at the moment this happens, this has network security connotations but not the ones one would probably guess at first. This answer is an educated guess based on seeing that error several times.

When your session is asleep it does not send keepalive packets (i.e. does not send extra ACKs). Such a "dead" TCP session will be cut off by a stateful firewall, no matter if the firewall considers the connection valid (or harmless) or not. Since you are pentesting I would imagine you are working within a network where several firewalls are in place.

Why would a stateful firewall do this?

Today, stateless firewalls are pretty much history* therefore all firewalls are stateful, they keep the state (and history) for each connection that goes through the firewall. They perform this not only for NATs but for any traffic passing through the firewall. Such a stateful firewall is vulnerable to a DoS attack by leaving too many hanging connections and filling its memory. To prevent that a stateful firewall have a timeout upon which it drops the hanging (no traffic during the timeout) connection.

When you wake up your SSL session, it sends an ACK. But the firewall had long dropped that connection from its memory and is clueless about the existence of the TCP session, therefore it answers with RST. The RST provokes a state=unknown error from the SSL level.

The system at the other side of the firewall may well be aware of your connection, and would answer had the ACK reached it. But the firewall will not let that pass.

What can you do about it?

Not much. You could run a stateful proxy on your own machine which would keep sending TCP keepalive on one side (the outside), but would not require keepalives on the other side (the inside, loopback).

Yet if you, for example, put your entire machine to sleep, then the stateful proxy will not send extra ACKs anyway defeating it purpose (and it will make connection debugging even harder that it already is with just the firewalls).

* A stateless firewall is vulnerable to trivial attacks (bypasses), such as IP fragmentation of the initial SYN packet.

Improve this answer
3
  • Thanks for help. Its interesting. But how can one explain this moment: I send 6 or 7 sessions to sleep simultaneously. So, if I rightly understand you, my sessions should all fail, but some wakes up and some doesn't. The only difference between them are the machines, from which they are established.
    – lsass
    Commented Oct 3, 2016 at 9:09
  • @lsass - You can't explain a complex network without stats, and 7 sessions do not make for stats. You do not know where the firewalls are I assume. Even in a lab setup: two machines connect through a firewall controlled switch, you could hit firewall activity algorithms (e.g. drop more silent sessions during traffic peaks, less during slow times).
    – grochmal
    Commented Oct 3, 2016 at 23:57
  • @grochmal To be clear, when sessions are put to sleep, the connection is killed entirely. The point here is to be completely silent on the wire during this time. When the sleep timeout expires, a whole new connection is established. Hence, keepalive isn't really the issue here I believe. This answer is still very interesting and contains helpful details about how things work in general behind the scenes. Cheers!
    – OJ.
    Commented Oct 5, 2016 at 0:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .