stanford-esrg / lzr Goto Github PK

Hello there, I'm running lzr with zmap, it gives me correct output for one time and then it returns 0 results for all other scans!

note: my main interface is ens160, there is only one IP address on this interface, I've used this to make the lzr
make all source-ip=x.x.x.x/32

my target network has at least 21 results on port 80, zmap can verify that but I don't know what happens that it's giving me this results !

one time that it gave me results ( just 5 item, it should give me about 21 items ) !

{"saddr":"x.x.x.13","daddr":"185.x.x.x","sport":80,"dport":56425,"seqnum":3014031342,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393362549+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.13/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.12","daddr":"185.x.x.x","sport":80,"dport":46649,"seqnum":1393460254,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393380333+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.12/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.11","daddr":"185.x.x.x","sport":80,"dport":47539,"seqnum":2199870258,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393385312+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.11/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.10","daddr":"185.x.x.x","sport":80,"dport":51667,"seqnum":2846776825,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.393396227+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.10/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}
{"saddr":"x.x.x.14","daddr":"185.x.x.x","sport":80,"dport":57849,"seqnum":1098684816,"acknum":110,"window":29200,"ttl":60,"Counter":0,"ACK":true,"ACKed":true,"SYN":false,"RST":false,"FIN":false,"PUSH":true,"HandshakeNum":1,"fingerprint":"http","Timestamp":"2023-11-13T12:37:18.39340616+03:30","expectedRToLZR":"data","data":"HTTP/1.1 301 Moved Permanently\r\nServer: openresty\r\nDate: Mon, 13 Nov 2023 09:07:18 GMT\r\nContent-Type: text/html\r\nContent-Length: 166\r\nConnection: keep-alive\r\nLocation: https://x.x.x.14/\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e301 Moved Permanently\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody\u003e\r\n\u003ccenter\u003e\u003ch1\u003e301 Moved Permanently\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003eopenresty\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n"}

output for wrong results:
root@ubuntu20:/tmp/lzr# port=80 ; target=86.x.x.x/24 ; zmap -c 5 --retries=3 $target -i ens160 --target-port=$port --output-filter="success = 1 && repeat = 0" -f "saddr,daddr,sport,dport,seqnum,acknum,window" -O json | lzr --handshakes wait,http,tls -sendSYNs -sendInterface ens160
Nov 13 13:05:50.540 [WARN] blocklist: ZMap is currently using the default blocklist located at /etc/zmap/blocklist.conf. By default, this blocklist excludes locally scoped networks (e.g. 10.0.0.0/8, 127.0.0.1/8, and 192.168.0.0/16). If you are trying to scan local networks, you can change the default blocklist by editing the default ZMap configuration at /etc/zmap/blocklist.conf. If you have modified the default blocklist, you can ignore this message.
Nov 13 13:05:50.542 [INFO] dedup: Response deduplication method is full
++Writing results to file: default_20231113130550.json
++Handshakes: wait,http,tls
++Sending SYNs
++Using Sending Interface: ens160
++Worker threads: 1
++Timeout Interval (s): 5
++Retransmit Interval (s): 1
++Number of Retransmitions: 1
Nov 13 13:05:50.617 [INFO] recv: duplicate responses will be passed to the output module
Nov 13 13:05:50.620 [INFO] recv: unsuccessful responses will be passed to the output module
0:00 0%; send: 0 0 p/s (0 p/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%
0:00 0%; send: 0 0 p/s (0 p/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%
0:01 21%; send: 256 done (2.49 Kp/s avg); recv: 21 21 p/s (19 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:02 40%; send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (10 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:03 60%; send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (6 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:04 80%; send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (5 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
0:05 99% (1s left); send: 256 done (2.49 Kp/s avg); recv: 21 0 p/s (4 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 8.20%
Nov 13 13:05:56.633 [INFO] zmap: completed
Killed

Add to README how to implement new handshakes (handshake folder + handshake.go)

add functionality such that lzr can read from zmap --dryRun (and not assume that whenever lzr is in charge of starting a connection (e.g., sendSYNs), that the input is coming in as a list). Will require to chance the lzr.readZMap() logic in bin/bin.go

As of go1.17 the go get command mentioned doesn't work and has been deprecated, instead go suggests to use go install, which fails.
When I'm trying to build from source I encounter this issue:

$ make all source-ip=256.256.256.256/32
sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 256.256.256.256/32 -j DROP
iptables v1.8.7 (legacy): host/network `256.256.256.256' not found
Try `iptables -h' or 'iptables --help' for more information.
make: *** [Makefile:10: all] Error 2

OS: fedora 36

I've been attempting to get LZR to play nicely with ZMap and I'm finding I keep running into an issue where I apparently am getting no data response from anything I'm attempting to scan.

I've tried both in an externally-facing environment and on my internal network as well, but no matter what I do I can't seem to get a received response length above 0.

I've tested on both the latest version of Ubuntu 23 as well as Ubuntu 22 LTS and I'm getting the same results.

Example chain of commands:

LOCAL_SRC_IP=192.168.1.100 # (eth0 ipv4 address - LZR compiled with this same value for internal scans. Separately, I compiled LZR with my external/ISP-provided IP for external scans when running from a VPS.)

GATEWAY=<my eth0 gateway mac>

sudo zmap 192.168.1.0/24 --target-port=80 -O json -f "saddr,daddr,sport,dport,seqnum,acknum,window,ttl" \
--source-ip=$LOCAL_SRC_IP --output-filter="success=1 && repeat=0" | \
sudo ~/lzr/lzr -d --handshakes "http,tls" -sendInterface eth0 -gatewayMac $GATEWAY -feedZGrab

ZMap appears to successfully identify all the hosts that are running HTTP services on :80 in the above example, but LZR consistently returns TotalResponses: 0.

Example output:

Oct 19 XX [INFO] dedup: Response deduplication method is window with size 1000000
++Writing results to file: default_20231019XX.json
++Handshakes: http,tls
++Using Sending Interface: eth0
++Using Gateway Mac: redacted
++Feeding ZGrab with fingerprints
++Worker threads: 1
++Timeout Interval (s): 5
++Retransmit Interval (s): 1
++Number of Retransmitions: 1
Oct 19 XX [INFO] recv: duplicate responses will be passed to the output module
Oct 19 XX [INFO] recv: unsuccessful responses will be passed to the output module
 0:00 1%; send: 134 1 p/s (2.04 Kp/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%

<...snip...>

192.168.1.222 ====
recv seq num: 2905414489
stored seqnum:  2905414489
recv ack num: 1494555975
stored acknum:  1494555975
received response length:  0
stored response length:  111
192.168.1.222 ====
 0:08 100% (1s left); send: 256 done (6.83 Kp/s avg); recv: 145 0 p/s (18 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 56.64%
Oct 19 XX [INFO] zmap: completed
Finished Reading Input
Runtime: 9.047087634s
{"TotalResponses":0,"ZeroWindow":0,"ACKed":0,"Data":0,"No_SYNACK":0,"Rst":0,"Fin":0,"Resp_ack":0,"HyperACKtive":0}

Any ideas on how to get LZR properly reading the scan data and identifying the proper protocols would be greatly appreciated - thanks in advance!

Hello,

Just for clarification; I just want to know if I have to choose one random IP address for the $source-ip variable when executing the make command.

Also, I am having the below problem when doing the scan. What could it be?

panic: ens8: No such device exists (SIOCGIFHWADDR: No such device)

Can you please offer some guidance on the above concerns?
Thank you in advance.

Hello,

I've run into the following issues when using LZR with ZMap.

• When reading SYN-ACKs from ZMap, the SYN and ACK flags are not explicitly set. This causes LZR to respond to SYN-ACKs with a zero window size (which shouldn't happen according to the algorithm diagram), since the windowZero function checks for those flags.
• ZMap outputs SeqNum and AckNum as signed 32-bit integers, but LZR uses 64-bit integers on a 64-bit machine (int is architecture-dependent in Go). This causes verification to fail for the first handshake whenever the MSB in SeqNum or AckNum is one.

Here is a possible fix, though the fix for the latter is a bit hacky!

--- a/packet.go
+++ b/packet.go
@@ -132,7 +132,17 @@ func convertFromZMapToPacket( input string ) *packet_metadata      {
        synack := &packet_metadata{}
        //expecting ip,sequence number, acknumber,windowsize, sport, dport
        err := json.Unmarshal( []byte(input),synack )
+       synack.SYN = true
+       synack.ACK = true
        synack.Processing = true
+       if strconv.IntSize == 64 {
+               if synack.Seqnum < 0 {
+                       synack.Seqnum = 4294967296 + synack.Seqnum
+               }
+               if synack.Acknum < 0 {
+                       synack.Acknum = 4294967296 + synack.Acknum
+               }
+       }
        if err != nil {
                log.Fatal(err)
                return nil

I'm trying to get lzr to fingerprint anything, and I'm failing. I'm running the following command, using the latest release of lzr, from a debian 12 host:

$ echo "192.168.1.1:22" | sudo ./lzr \
   --handshakes ssh \
   -sendSYNs \
   -sourceIP      192.168.1.71 \
   -sendInterface wlp0s20f3 \
   -gatewayMac    30:89:4a:11:71:eb \
   -f -

The json it outputs, contains "fingerprint: unknown":

{
  "saddr": "192.168.1.1",
  "daddr": "192.168.1.71",
  "sport": 22,
  "dport": 42472,
  "seqnum": 2052859966,
  "acknum": 0,
  "window": 65535,
  "ttl": 0,
  "Counter": 1,
  "ACK": false,
  "ACKed": false,
  "SYN": true,
  "RST": false,
  "FIN": false,
  "PUSH": false,
  "HandshakeNum": 0,
  "fingerprint": "unknown",
  "Timestamp": "2024-04-11T15:25:37.616496178+01:00",
  "expectedRToLZR": "sa"
}

The host I am scanning from has this network interface

wlp0s20f3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.71  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::3289:4aff:fe11:71eb  prefixlen 64  scopeid 0x20<link>
        ether 30:89:4a:11:71:eb  txqueuelen 1000  (Ethernet)
        RX packets 147663603  bytes 169865914024 (158.1 GiB)
        RX errors 0  dropped 73712  overruns 0  frame 0
        TX packets 44722281  bytes 59451909408 (55.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The IP and port I am trying to scan is open (below run from the scanning host):

$ telnet 192.168.1.1 22
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u4

Can you suggest what I am doing wrong?

It seems like there is a mac address hardcoded in construct_responses.go :

func getHostMacAddr() (addr net.HardwareAddr) {
	return net.HardwareAddr{0xa8, 0x1e, 0x84, 0xce, 0x64, 0x5f}
}

This makes it difficult for the packets to actually arrive to their destination unless the scanning machine's gateway's mac address matches this address.

Hello
Please add ability to detect http/s, socks* proxy services
thanks.

The following command: zmap 0.0.0.0/0 -p 80,443 --shards=32 --shard=3 --seed=123 -B 10m --probe-ttl=510 -O json -f saddr,daddr,sport,dport,seqnum,acknum,window,ttl --sender-threads=16 --source-ip=xxx --output-filter "success=1 && repeat=0" | ztee -u zmap_status.txt -l zmap_errors.txt --raw ztee.output | lzr --handshakes http,tls -t 5 -w 3 -sendInterface eth0 -gatewayMac xxx -f -

Results in the following crash after a few minutes. This is an issue that has occurred on numerous servers. Could this be patched to handle this issue gracefully, or are there any workarounds I could use to make this tool usable?

panic: send: No buffer space available

goroutine 58 [running]:
github.com/stanford-esrg/lzr.SendSyn(0xc29dd87c00, 0xc00011c1e0, 0xc000063ea8?)
        /tmp/lzr/handle_syn.go:31 +0x156
github.com/stanford-esrg/lzr.handleExpired(0xc00015e0e0, 0xc29dd87c00, 0xc00011c1e0, 0xc000128358?, 0xf?)
        /tmp/lzr/handle_expired.go:77 +0x19e
github.com/stanford-esrg/lzr.HandleTimeout(0xc00015e0e0, 0xc29dd87c00, 0x0?, 0xc29dd87c00?, 0x0?, 0x0?)
        /tmp/lzr/handle_timeout.go:52 +0x185
github.com/stanford-esrg/lzr/bin.LZRMain.func4(0x0?)
        /tmp/lzr/bin/bin.go:162 +0xc7
created by github.com/stanford-esrg/lzr/bin.LZRMain in goroutine 1
        /tmp/lzr/bin/bin.go:149 +0x734

I've also tried increasing the tcp_mem, wmem max, and xfrm4_gc_thresh:

echo "$(($RAM * 1024 * 1024 / 4096)) $(($RAM * 1024 * 1024 * 2 / 4096)) $(($RAM * 1024 * 1024 * 3 / 4096))" > /proc/sys/net/ipv4/tcp_mem
sysctl net.ipv4.xfrm4_gc_thresh=65536
echo 83886080 > /proc/sys/net/core/wmem_max
echo 83886080 > /proc/sys/net/core/wmem_default
echo 83886080 > /proc/sys/net/core/rmem_max
echo 83886080 > /proc/sys/net/core/rmem_default

However, this doesn't work. I've only had this issue with this tool. Other ones like Zmap, zrgab2, and masscan never crash and throw this error.

Aviator hack aap

After reading your paper, I'd like to ask you two questions. First, I don't quite understand the detailed strategy of the algorithm in Figure 12. Second, can LZR only recognize about 30 protocols listed by you?

I'm running lzr following instructions in README.md, when I ran

 sudo zmap --target-port=9002 --output-filter="success = 1 && repeat = 0" \
-f "saddr,daddr,sport,dport,seqnum,acknum,window" -O json --source-ip=172.26.48.1 -n 20 | \
sudo ./lzr --handshakes http,tls

I encountered the followed error

++Writing results to file: default_20220827165939.json
++Handshakes: http,tls
++Worker threads: 1
++Timeout Interval (s): 5
++Retransmit Interval (s): 1
++Number of Retransmitions: 1
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x8297b5, 0x16)
        /usr/lib/go-1.13/src/runtime/panic.go:774 +0x72
runtime.sysMap(0xc004000000, 0x538000000, 0x10a1638)
        /usr/lib/go-1.13/src/runtime/mem_linux.go:169 +0xc5
runtime.(*mheap).sysAlloc(0xb59f20, 0x53724e000, 0x459140, 0x7ff928219008)
        /usr/lib/go-1.13/src/runtime/malloc.go:701 +0x1cd
runtime.(*mheap).grow(0xb59f20, 0x29b927, 0xffffffff)
        /usr/lib/go-1.13/src/runtime/mheap.go:1255 +0xa3
runtime.(*mheap).allocSpanLocked(0xb59f20, 0x29b927, 0x10a1648, 0x421035)
        /usr/lib/go-1.13/src/runtime/mheap.go:1170 +0x266
runtime.(*mheap).alloc_m(0xb59f20, 0x29b927, 0x7ff924790100, 0x7ff92479a9f0)
        /usr/lib/go-1.13/src/runtime/mheap.go:1022 +0xc2
runtime.(*mheap).alloc.func1()
        /usr/lib/go-1.13/src/runtime/mheap.go:1093 +0x4c
runtime.(*mheap).alloc(0xb59f20, 0x29b927, 0x7ff924010100, 0x1)
        /usr/lib/go-1.13/src/runtime/mheap.go:1092 +0x8a
runtime.largeAlloc(0x53724e000, 0x1, 0xc00015bb18)
        /usr/lib/go-1.13/src/runtime/malloc.go:1138 +0x97
runtime.mallocgc.func1()
        /usr/lib/go-1.13/src/runtime/malloc.go:1033 +0x46
runtime.systemstack(0x45c6e4)
        /usr/lib/go-1.13/src/runtime/asm_amd64.s:370 +0x66
runtime.mstart()
        /usr/lib/go-1.13/src/runtime/proc.go:1146

goroutine 1 [running]:
runtime.systemstack_switch()
        /usr/lib/go-1.13/src/runtime/asm_amd64.s:330 fp=0xc00015bd20 sp=0xc00015bd18 pc=0x45c7e0
runtime.mallocgc(0x53724e000, 0x80c660, 0x1, 0xc0001e76c4)
        /usr/lib/go-1.13/src/runtime/malloc.go:1032 +0x895 fp=0xc00015bdc0 sp=0xc00015bd20 pc=0x40fb75
runtime.makechan(0x7753a0, 0x5f5e100, 0xc0000b8060)
        /usr/lib/go-1.13/src/runtime/chan.go:106 +0x153 fp=0xc00015be08 sp=0xc00015bdc0 pc=0x4083b3
github.com/stanford-esrg/lzr.ConstructWritingQueue(...)
        /home/wangtz/lzr/construct_main_routines.go:49
github.com/stanford-esrg/lzr/bin.LZRMain()
        /home/wangtz/lzr/bin/bin.go:43 +0x174 fp=0xc00015bf50 sp=0xc00015be08 pc=0x5d5aa4
main.main()
        /home/wangtz/lzr/cmd/lzr/main.go:11 +0x20 fp=0xc00015bf60 sp=0xc00015bf50 pc=0x738450
runtime.main()
        /usr/lib/go-1.13/src/runtime/proc.go:203 +0x21e fp=0xc00015bfe0 sp=0xc00015bf60 pc=0x4332ae
runtime.goexit()
        /usr/lib/go-1.13/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc00015bfe8 sp=0xc00015bfe0 pc=0x45e8b1

it seems that my machine's memory has run out, how should deal with this problem?