o A problem that caused OS detection to fail for most hosts in a
certain was fixed. It happened when sending raw Ethernet frames
(by default on Windows or on other platforms with --send-eth) to
hosts on a switched LAN. The destination MAC address was wrong for
most targets. The symptom was that only one out of each scan group
of 20 or 30 hosts would have a meaningful OS fingerprint. Thanks go
to Michael Head for running tests and especially Trent Snyder for
testing and finding the cause of the problem. [David]
This fixes the following bug: When scanning with an Ethernet handle (as
opposed to raw sockets), only the first host in an OS scan group would
get a result. All others would be blank fingerprints with R=N for every
probe. This was first noticed on Windows because Ethernet is the default
sending method, but it affects other platforms with --send-eth.
OS scan initialized an Ethernet handle once for each group, and recorded
the first-hop MAC address of the first target at that time. That
first-hop address was used for all targets. This failed on a switched
LAN, when the first-hop address for every host is different (it's the
MAC address of each target).
All the various high-level probe sending functions now do their work
through three low-level sending functions: one each for TCP, UDP, and
ICMP. Those low-level functions take care of setting the MAC addresses
before each send.
I checked and the other places where Ethernet sends are used do not have
this problem. ultra_scan, idle scan, and traceroute all set the
addresses before every send.
measurements. These commonly responsive ports are moved to the front of the
list when randomizing ports to help us quickly get some timing feedback and
find a timing ping probe.
The previous list was
{ 21, 22, 23, 25, 53, 80, 113, 256, 389, 443, 554, 636, 1723, 3389 }
The new list is
{ 80, 23, 443, 21, 22, 25, 3389, 110, 445, 139, 143, 53, 135, 113 }
The ports that were removed are
256 fw1-secureremote
389 ldap
554 rtsp
636 ldapssl
1723 pptp
The ports that were added are
110 pop3
135 msrpc
139 netbios-ssn
143 imap
445 microsoft-ds
Like ultra_scan, OS scan has global and host-based congestion control
mechanisms like those in TCP. Part of global congestion control is
keeping track of how many probes are outstanding in the network; OS scan
keeps the number in a member variable called num_probes_active.
num_probes_active is meant to be the sum of the sizes of each host's
list of outstanding probes. It was correctly being decremented whenever
a probe was removed from an active list, but it was never incremented.
num_probes_active was always zero or negative, and therefore never
exceeded the global congestion window. This almost completely disabled
global congestion control.
With this fix OS scan will send a maximum of ten probes immediately at
the beginning of the scan. Previously it was limited only by the number
of hosts being scanned (20 or 30).
GroupScanStats::probeSent. This will allow updating timing variables for a
per-host rate limiter.
This fixes a bug, which was that decoy probes were not recorded by the scan
rate meter. Decoy scans would show a lower scan rate than the actual: with four
decoys the rate printed would be 1/5 of actual. This only affects printed
output, not the actual scan rate.
replied to or times out. Previously the scaling factor was increased as soon a
s a probe was sent. So if you sent 10 probes right away at the beginning of the
scan, the first reply that came back would be scaled by 10 (= 10/1, and the
next by 9/2, etc.). Now if every probe is replied to then the scaling factor
will be exactly 1 throughout the scan.
o Zenmap now runs ndiff to do its "Compare Results" function. This
completely replaces the old diff view. ndiff is now required to do
comparisons in Zenmap. [David]
