duplicate SYN packets

[r00tkillah]

As directed, filing. This is using dns mode: On server: ruby ./dnscat2.rb --secret=<redacted> <redacted> The server keeps saying in window 1:

If you think this might be a bug, please report this trace:
#<DnscatException: Duplicate SYN received!>
/home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:153:in `_handle_syn'
/home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:387:in `_handle_incoming'
/home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:405:in `block in feed'
/home/r00tkillah/src/contrib/dnscat2/server/controller/encryptor.rb:244:in `decrypt_and_encrypt'
/home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:395:in `feed'
/home/r00tkillah/src/contrib/dnscat2/server/controller/controller.rb:91:in `feed'
/home/r00tkillah/src/contrib/dnscat2/server/tunnel_drivers/tunnel_drivers.rb:25:in `block in start'
/home/r00tkillah/src/contrib/dnscat2/server/tunnel_drivers/driver_dns.rb:316:in `call'
/home/r00tkillah/src/contrib/dnscat2/server/tunnel_drivers/driver_dns.rb:316:in `block in initialize'
/home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:872:in `call'
/home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:872:in `block (2 levels) in on_request'
/home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:843:in `loop'
/home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:843:in `block in on_request'

On client:

$ sudo ./dnscat --secret=<redacted> <redacted>
Creating DNS driver:
 domain = <redacted>
 host   = 0.0.0.0
 port   = 53
 type   = TXT,CNAME,MX
 server = <redacted>

** Peer verified with pre-shared secret!

[[ ERROR ]] :: The server hasn't returned a valid response in the last 20 attempts.. closing session.
[[ FATAL ]] :: There are no active sessions left! Goodbye!
[[ WARNING ]] :: Terminating

Using this version:

$ git log --oneline HEAD^..HEAD
3efee23 Error handling: Fixed the error handling for bad commands (which was apparently non-existant).

[iagox86]

Hmm, that shouldn't happen! Unfortunately, all the error you sent me shows is that the server is receiving the request, but it's impossible to say if the client got the response (presumably not).

If this happens consistently, can you please get a report with debugging on?

https://github.com/iagox86/dnscat2/blob/master/doc/how_to_bug_report.md

Thanks!

On Sun, Jul 17, 2016 at 2:55 PM, Hacker, J.R. notifications@github.com wrote:

As directed, filing. This is using dns mode: On server: ruby ./dnscat2.rb --secret=

The server keeps saying in window 1:

If you think this might be a bug, please report this trace:

<DnscatException: Duplicate SYN received!>

/home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:153:in _handle_syn' /home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:387:in_handle_incoming' /home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:405:in block in feed' /home/r00tkillah/src/contrib/dnscat2/server/controller/encryptor.rb:244:indecrypt_and_encrypt' /home/r00tkillah/src/contrib/dnscat2/server/controller/session.rb:395:in feed' /home/r00tkillah/src/contrib/dnscat2/server/controller/controller.rb:91:infeed' /home/r00tkillah/src/contrib/dnscat2/server/tunnel_drivers/tunnel_drivers.rb:25:in block in start' /home/r00tkillah/src/contrib/dnscat2/server/tunnel_drivers/driver_dns.rb:316:incall' /home/r00tkillah/src/contrib/dnscat2/server/tunnel_drivers/driver_dns.rb:316:in block in initialize' /home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:872:incall' /home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:872:in block (2 levels) in on_request' /home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:843:inloop' /home/r00tkillah/src/contrib/dnscat2/server/libs/dnser.rb:843:in `block in on_request'

On client:

$ sudo ./dnscat --secret= Creating DNS driver: domain = host = 0.0.0.0 port = 53 type = TXT,CNAME,MX server =

\ Peer verified with pre-shared secret!

[[ ERROR ]] :: The server hasn't returned a valid response in the last 20 attempts.. closing session. [[ FATAL ]] :: There are no active sessions left! Goodbye! [[ WARNING ]] :: Terminating

Using this version:

$ git log --oneline HEAD^..HEAD 3efee23 Error handling: Fixed the error handling for bad commands (which was apparently non-existant).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/iagox86/dnscat2/issues/97, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgITAjRcINu_HVrz-m7SpoXF_QfcYsQks5qWqTmgaJpZM4JOUpc .

[r00tkillah]

I think this is related to dnsmasq as the upstream dns. I switched to bind9 and the problem went away.

[ngo]

I am also experiencing this issue on some (but not all) resolvers. I've tracked it down to the behavior of some recursive resolvers where they send one query numerous times. One public DNS which does this is verysign public DNS (64.6.64.6).

After the initial handshake, when the client sends a SYN (e.g. 111600bd7a5bc2aaac8a170000e6ec30b7d7b0371b70cd6e7d21fae1db38.64273266.my.domain) verysign's resolvers sends two queries instead: 111600bD7A5bC2aaac8a170000E6Ec30b7d7b0371B70Cd6E7D21FaE1dB38.64273266.my.doMaIN and 111600Bd7a5BC2aAAC8A170000e6EC30b7D7B0371B70cd6E7d21faE1Db38.64273266.MY.DOmAin.

No idea why it does this, but this breaks dnscat2 completely - after receiving the first SYN in a session the server will not answer further SYN's and after 20 retriest the client will shut down.

On other resolvers this behavior is not 100% reproducible and happens from time to time. When the client is restarted by cron, I've seen cases where it successfully connects after like 15 restarts and in other cases with the same upstream DNS it connects on the first try.

Anyway, I think we have to handle this duplicate SYN situation in some other way, having in mind that some resolvers behave this way.

[ngo]

In the code there is a comment as follows:

# Ignore errant SYNs - they are, at worst, retransmissions that we don't care about

Well, this is unfortunately not so, because in my cases the client gets the answer for the second query, not the first.

@iagox86 , what is the proper strategy to deal with this situation? I've just commented out lines 152-154 of controller/session.rb and it seems to solve my problem, but I'm not sure if it breaks anything.