--------------------------
Scan of the Month: Scan 21
David Long
dlong@fish.co.uk
--------------------------

( Apologies for the awful formatting! I only saw the challenge at the last
  minute - I thought you'd stopped doing them! )
 
Analysis of Scan 21 - Odd UDP Packets
 

1. What is the attacker attempting to achieve?
 
Stealth scan, but not quite as stealthily as possible since he ran through
the destination addresses sequentially. However most IDS would not recognise
it anyway.
 

2. How does UDP work to achieve this purpose?
 
By being connectionless. Thus, in the unlikely event of a port being open,
there would be no reply. Also, being stateless, it is more likely to be
passed by simple packet filters than TCP.
 

3. Why is the attacker using random src and dst UDP ports and random IP
addresses?
 
By varying the source address and the source and destination ports, the
chances of being spotted by an IDS are much reduced. In fact, the ports are
not entirely random since the destination ports and many of the source ports
are unassigned according to IANA (http://www.iana.org/assignments/port-numbers), 
thus increasing the likelihood of an ICMP Port Unreachable reply. The scan 
could have been made even more stealthy by randomising the order in which 
the target addresses were scanned. Slowing the scan rate would have helped 
too, although lots of packets close together are less likely to be logged by 
devices that limit their syslog message generation rate, such as some routers.
 

4. Are all the packets originating from the same machine or different ones?
 
The odds very strongly favour the source being the same machine since the
target addresses are scanned in sequence. Additionally the packets are sent
VERY close together in time and it is unlikely that a group of machines
could be synchronised that closely. The 5 data bytes are identical in each
packet ("DOM", 0x02, 0x00), which might allow for a simple signature to aid
recognition by an IDS.
 

5. How can the attacker view the responses to his probes?
 
Since all the source addresses are in the same limited range and therefore
likely in the same subnet, the attacker merely has to be able to listen to
the LAN in promiscuous mode assuming that he is not on a switched network.
Alternative, though less likely, methods include access to data capture on
the subnet default router and spoofing the source addresses itself (via
flooded gratuitous ARPs if the addresses are already in use) to ensure that
the replies are forwarded to his machine.
 

6. Can the attacker fingerprint the OS of the victim systems?
 
In many cases, yes, by the characteristics of the ICMP Port Unreachable
replies. In the particular example, no definite conclusions can be drawn
since there are no replies (logged) and lack of any reply could be due to a 
number of reasons, such as:
 
        UDP port is open (unlikely, given the ports chosen)
 
        UDP packet was dropped by heavily loaded router en route
 
        UDP packet was dropped by router/firewall at remote site
 
        ICMP Port Unreachable was dropped by router/firewall at remote site
 
        ICMP Port Unreachable was dropped by heavily loaded router en route
 
        Target device was running Windows flavour that does not send ICMP
        Port Unreachables
 

ADDITIONAL INFO
 
Although it might well be unrelated, there is a similarly fast scan earlier
in the Snort log (lines 2639-2647). This time it uses ping and although from
an apparently unrelated IP address, it originates from the same country as
the UDP scan (Germany). A possible source of this ping is Cyberkit
(http://www.cyberkit.net), a shareware network utility for Windows - the
snort signature for an older version is 32 letter "a"s in a row and the
snort trace shows 32 letter "E"s. If so, he is running it on a recent
version of Windows (ME or later) since the IP ID is incrementing by 1. A
very recent Windows O/S (2000 or XP) would also fit with the likely initial
TTL of 128.