You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+8-19Lines changed: 8 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,37 +28,26 @@ The tool does not send any exploits to the vulnerable hosts, and is designed to
28
28
In this example we run the tool against the `192.168.1.59/29` subnet (which contains a vulnerable server).
29
29
30
30
The tools does the following:
31
-
1. Open a TCP server on the default address (the local IP at port 5555)
32
-
2.Adds the flag `--ports=top100` to adjust the scan to include the top 100 ports
31
+
1. Open a server on the default address (the local IP at port 5555)
32
+
2.POssibly, add the flag `--ports=top100` to adjust the scan to include the top 100 ports
33
33
3. The tool then tries all ports on each of the IP addresses in the subnet. If a remote server responds at one of the ports, the request is sent to it.
34
34
4. If the server is vulnerable, a callback is made to our server (created on step 1) and the IP address of the remote is logged
35
-
5. After all IP addresses in the subnet are scanned, the TCP server waits 10s for any lingering connections and closes down
35
+
5. After all IP addresses in the subnet are scanned, the server waits for a default duration of 10s for any lingering connections and closes down
36
36
6. The tools displays the summary of the connections made:
37
37
1. Requests sent to responding remote servers (and the status code they responded with)
38
-
2. Any callback address made to our TCP server
38
+
2. Any callback address made to our server
39
39
40
40
## Important Note about Assumptions
41
41
42
42
* If a callback happened, this means that a vulnerable server exists, the exploit worked and it initiated a callback.
43
-
However, the logged IP address might not belong to the actual vulnerable server (it might be behind a NAT or a proxy)
43
+
However.
44
44
* A good rule of thumb, if the callback IP address is not in the subnet scanned, the vulnerable server is behind a NAT
45
45
(e.g. a docker container responds with its own IP address, not the host running the docker)
46
46
* The network traffic created by the tool might be classified as malicious by security products, or cause a lot of noise for monitoring services
47
-
* The TCP server created by the tool assumes that it is open to receive inbound traffic. That means that opening a FW inbound rule on the host running the scan is needed.
48
-
49
-
### What to do if the vulnerable server is behind a NAT?
50
-
51
-
Let's assume that we are scannon `192.168.1.0/24` and a vulnerable application is running inside a docker container on the `192.168.1.2` host.
52
-
53
-
The tool will scan that host, sending requests to `192.168.1.2` but the callback we get will be from '172.10.0.1' (which is the internal docker subnet)
54
-
55
-
what we can do is minimize the search. we can get the list of all successful requests made by the scanner from the log, and the enumerate
56
-
through them, one by one, to see which one is triggering the callback.
57
-
58
-
as this is a bit tedious, we plan on automating this if this becomes a real issue
59
-
47
+
* The server created by the tool assumes that it is open to receive inbound traffic. That means that opening a FW inbound rule on the host running the scan is needed.
60
48
61
49
## Basic usage
50
+
62
51
Download the tool for your specific platform (Windows, Linux or Mac), to run the tool, make sure port 5555 on the host is available (or change it via configuration),
63
52
and specify the subnet to scan (it is possible to configure a separate server:port combination using the `--server` flag):
64
53
@@ -90,7 +79,7 @@ if you wish to disable the callback server, use `--noserver`
90
79
*`--nocolor` provide output without color
91
80
*`--ports` either top10 (default) or top100 (list of the 100 most common web ports)
92
81
*`--noserver` only scan, do not use a local callback server
93
-
*`--ports=slow` is currently disabled due to a bug, to be fixed in the next release
82
+
*`--timeout=10` is setting the server shutdown timeout to 10 seconds
"Set path (inc. filename) to save the CSV file containing the scan results (e.g /tmp/log4jScanner_results.csv). By default will be saved in the running folder.")
121
+
scanCmd.Flags().Int("timeout", 10, "Duration of time to wait before closing the callback server, in secods")
0 commit comments