---------------------------- Scan 21 - Scan of the Month Roshen Chandran Paladion Networks Honeynet Rsearch Alliance ---------------------------- A stream of UDP packets that trigger our IDS isn't always interesting - except, when they don't. On Feb 16, the Alliance was excited by 9 UDP packets that streaked through our honeynets, without causing a tremor on our IDS. The Snort logs captured these for our analysis. As the logs are in tcpdump format, we like to use Ethereal - a GUI-based protocol decoder available on most platforms. A quick glance for UDP packets (ip.proto eq 17) reveals that the interesting UDP packets appeared towards the end of the day- packets 3360 to 3368. No. Time Source Destination Prot Info 3360 15:50:15.0974 213.68.213.135 172.16.1.101 UDP src: 5298 dest: 18030 3361 15:50:15.1732 213.68.213.133 172.16.1.102 UDP src: 19566 dest: 18202 3362 15:50:15.1776 213.68.213.135 172.16.1.103 UDP src: 9280 dest: 19757 3363 15:50:15.1783 213.68.213.144 172.16.1.104 UDP src: 17773 dest: 3327 3364 15:50:15.1793 213.68.213.130 172.16.1.105 UDP src: 19841 dest: 15316 3365 15:50:15.1800 213.68.213.135 172.16.1.106 UDP src: 14604 dest: 12208 3366 15:50:15.1808 213.68.213.140 172.16.1.107 UDP src: 1348 dest: 5274 3367 15:50:15.1815 213.68.213.133 172.16.1.108 UDP src: 16932 dest: 16219 3368 15:50:15.1823 213.68.213.134 172.16.1.109 UDP src: 18986 dest: 10903 A quick look gives us the first hints: - These packets have different destinations, sweeping the target network - Four different sources were responsible for these packets - The source and destination ports are different for each packet - The packets all arrived within 1 second We now realise why the IDS didn't alert a scan on these packets- not only are the destination ports different, even the source IPs are different. The attacker is actively evading IDSs by using different source IPs. Yet, what's the motive? It looks like the attacker's scanning for reachable hosts on the network- a UDP ping sweep. UDP packets to closed ports will evince an ICMP Port Unreachable error message, a feature used to map reachable hosts. We dig deeper for details: - The TTL value is random across the packets - The UDP payload contains the ASCII string DOM in all the packets Off to Google, "DOM UDP security" and we have a security alert from Qualys on the RST.b trojan. http://www.qualys.com/alert/remoteshellb.html "RST.b is a newly discoverd Trojan which affects various Linux platforms and installs backdoor functionality for executing arbitrary commands on infected systems...To activate the backdoor, an attacker needs to send a UDP packet containing the three-byte ASCII string "DOM" at a specific offset. " The pieces are falling in place - the attacker is stealthily scanning for machines infected with the RST.b trojan ---------------------------- The Answers to the Challenge ---------------------------- 1. What is the attacker attempting to achieve? Flying below the radar, the attacker is scanning for machines infected with the RST.b trojan. On the side, he might be building a list of reachable hosts on the network, as well. 2. How does UDP work to achieve this purpose? UDP is connectionless, and evokes a distinct error message (ICMP Port Unreachable), when it receives a packet to its closed ports. Thus UDP is ideal to stealthily identify machines reachable on a network; the technique is a variation of the UDP Ping sweep. The RST.b trojan also listens in promiscuous mode for UDP packets with the activation string "DOM" 3. Why is the attacker using random src and dst UDP ports and random IP addresses? IDSs detect scans by counting the number of packets from one source to either multiple destinations, or multiple ports of the same destination. Here, the attacker uses different source IPs and random destination ports to prevent IDSs from identifying this as a scan. The random source port seems innocuous. 4. Are all the packets originating from the same machine or different ones? The 9 packets had widely varying TTLs and yet arrived within the span of a second. It is unlikely that packets from different sources could arrive in such close synchronisation. We conclude that the attacker crafted and sent the packets from the same machine. 5. How can the attacker view the responses to his probes? Here're two ways the attacker could view the responses to his probes: - Sniff at a gateway to the 213.68.213.0/24 network - Sniff on the 213.68.213.0/24 network Bonus Question: 6. Can the attacker fingerprint the OS of the victim systems? Yes, the OS of systems not infected by RST.b trojan can be discovered by looking at the ICMP error messages that the attacker receives. [In this network, the ICMP error messages have been filtered and the attacker will not be able to fingerprint the OS with these packets] Fyodor discusses OS Fingerprinting with UDP at http://www.insecure.org/nmap/nmap-fingerprinting-article.txt Ofir Arkin discusses ICMP Error messages for fingerprinting at http://www.sys-security.com/archive/papers/ICMP_Scanning_v3.0.pdf To quote from Fyodor's article: -------------------------------------------------------------------------- ICMP Message Quoting -- The RFCs specify that ICMP error messages quote some small amount of an ICMP message that causes various errors. For a port unreachable message, almost all implementations send only the required IP header + 8 bytes back. However, Solaris sends back a bit more and Linux sends back even more than that. The beauty with this is it allows nmap to recognize Linux and Solaris hosts even if they don't have any ports listening. ICMP Error message echoing integrity -- I got this idea from something Theo De Raadt (lead OpenBSD developer) posted to comp.security.unix. As mentioned before, machines have to send back part of your original message along with a port unreachable error. Yet some machines tend to use your headers as 'scratch space' during initial processing and so they are a bit warped by the time you get them back. For example, AIX and BSDI send back an IP 'total length' field that is 20 bytes too high. Some BSDI, FreeBSD, OpenBSD, ULTRIX, and VAXen fuck up the IP ID that you sent them. While the checksum is going to change due to the changed TTL anyway, there are some machines (AIX, FreeBSD, etc.) which send back an inconsistent or 0 checksum. Same thing goes with the UDP checksum. All in all, nmap does nine different tests on the ICMP errors to sniff out subtle differences like these. Type of Service -- For the ICMP port unreachable messages I look at the type of service (TOS) value of the packet sent back. Almost all implementations use 0 for this ICMP error although Linux uses 0xC0. This does not indicate one of the standard TOS values, but instead is part of the unused (AFAIK) precedence field. I do not know why this is set, but if they change to 0 we will be able to keep identifying the old versions _and_ we will be able to identify between old and new. --------------------------------------------------------------------------