0

A recent pentest revealed that the TCP timestamp option was enabled. I have tried to reproduce the pentesters' result using 

hping3 --tcp-timestamp -S -p 80 xx.xx.xx.xx

but the tool never returns. It sits on the line:

HPING xx.xx.xx.xx (eth0 xx.xx.xx.xx): S set, 40 headers + 0 data bytes

If I enter Ctrl C I get:

--- xx.xx.xx.xx hping statistic --- 
3746 packets transmitted, 0 packets received, 100% packet loss 
round-trip min/avg/max = 0.0/0.0/0.0 ms

If I add the -c option with a value of, say, 4 it does return but without timestamp information.

I checked with our hosting provider who confirmed that the timestamp was enabled (and then disabled it).

Any ideas what might be wrong with my setup that could be causing this? I'm using Kali 2016.1 on a hyper-v hosted virtual server, tunneling out of our DMZ to a Digital Ocean hosted Debian server using sshuttle.

Paul
  • 2,755
  • 6
  • 24
  • 35
Leo
  • 133
  • 8
  • Can you confirm what you mean when you say that the tool never returns? Perhaps you can add the actual hping3 output onto the question. It's worth noting that you can tell whether a remote server is using TCP timestamps by simply observing a connection with tcpdump to see if the `TS val` and `ecr` values are set in the TCP Options. – Mark Riddell Aug 10 '16 at 12:25
  • I mean just that - it has been sitting for 65 minutes and the only output is: HPING xx.xx.xx.xx (eth0 xx.xx.xx.xx): S set, 40 headers + 0 data bytes. If I enter ctrl C I get --- xx.xx.xx.xx hping statistic --- 3746 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms – Leo Aug 10 '16 at 12:27
  • Ok, so the SYN packets being sent from hping3 are not getting a response. Is the target webserver online and listening on port 80? Can you telnet to it on that port? – Mark Riddell Aug 10 '16 at 12:31
  • Webserver is online. Pentester and Hosting tech both managed to get an immediate timestamp with the above options. If I telnet I get connection closed by foreign host. The conditions on the website firewall when I test are exactly as they are for the Pentester and the Hosting tech. Could it be something to do with my ssh connection to my remote server? – Leo Aug 10 '16 at 12:38
  • Connection closed by foreign host sounds like you were able to telnet successfully (i,e, you got a message similar to Connected to x.x.x.x. Escape character is '^]'.). – Mark Riddell Aug 10 '16 at 12:42
  • Can you try a basic hping3 without the timestamp flag and see if you get a response from that. – Mark Riddell Aug 10 '16 at 12:42
  • Yeah - I've been trying that with the same (no) result. Just for a sanity check I ran it with google as the target and got the same result. Must be a local config issue, but I have no idea what. – Leo Aug 10 '16 at 12:46
  • 1
    Strange. The only thing I could suggest would be to take a tcpdump when you telnet to a working server and another when you use hping. Perhaps there is a particularly aggressive firewall in place which is dropping SYN's which contain (or omit) particular TCP/IP options. – Mark Riddell Aug 10 '16 at 12:51

1 Answers1

0

It appears that while sshuttle supports tcp, it doesn't work at the packet level (a good explanation is here in the Discussion section). My guess is that hping can't handle the remote mirroring of the TCP session and hangs or times out, depending on the options that are set.

When I killed the tunnel, hping worked fine, albeit from within the DMZ which means I'm subject to the rules of the firewall and possibly being reflected inward when looking at servers in our network.

Leo
  • 133
  • 8