New IDLE scan sees through your firewall to scan hosts inside your network!

IDLE scans allow an attacker to scan a victim and frame an inactive host on the internet. The attacker doesn’t transmit packets directly to the victim, but instead uses the idle zombie to measure the victim’s response to a spoofed packet. NMAP currently does this with the -sI command line option. There is a very interesting paper out that discusses two new methods of performing idle scans. One of these methods can peer through a network firewall and scan devices on internal networks that are not directly reachable by the attacker. The paper is available for download here: http://people.csail.mit.edu/costan/readings/usenix_papers/Ensafi.pdf The paper introduces two new types of scans. The first, is based on RESET limiting and works similar to the current method of measuring differences in the IPID field performed by nmap. The second method uses changes in the “SYN cache” to scans hosts that are reachable by the ZOMBIE that are not directly accessible to the attacker. Here is a brief explanation of how these two new scans would work. NEW IDLE SCAN#1 – Reset Rate Limiting Scans Concept: FREEBSD limits the number of RESET packets it will send in a given period of time. For simplicity, lets say that FreeBSD will only send 1 RESET per second. If I send that host a packet that should elicit a RESET and I don’t get back the expected RESET back then I know it sent someone else a RESET in the same second causing the host to reach it’s RESET limit. So if we find an idle FREEBSD host on the net with rate limiting turned on we can scan a third party victim using this behavior. Overview of the scan technique: 1) Attacker spoofs the ZOMBIE IP in a SYN packet to the VICTIM 2) Attacker sends a SYN-ACK to the ZOMBIE 3) If the attacker get a RST back the port was CLOSED. If the attacker gets nothing back the port was OPEN. To understand how this works let’s look at an open and closed port scenario. In this case the ZOMBIE is any idle FREEBSD host on the internet with RESET rate limiting enabled. Considering the following Open Port Scenario: 1) Attacker sends spoofed SYN packet from ZOMBIE to VICTIM with a destination port that he wants to scan 2) Since the port is open the VICTIM sends a SYN-ACK to the ZOMBIE 3) The ZOMBIE wasn’t expecting the packet so it sends a RESET to the VICTIM and enables it’s RST rate limiting timer preventing any further RESET packets. 4) The attacker sends a SYN-ACK from their real IP to the ZOMBIE. Since the ZOMBIE never send a SYN to the attacker the ZOMBIE should send a RESET back but because of the rate limit it does not and we get nothing back. Here is the scenario for a closed port: With a closed port the VICTIM will not respond with a SYN-ACK. It will send a RESET which will NOT cause the ZOMBIE to send a RESET. 1) Send spoofed packet from ZOMBIE to VICTIM with a SYN flag 2) Since the port is CLOSED the VICTIM sends a RESET to the ZOMBIE 3) The ZOMBIE will silently drop the RESET from the victim so his RST rate limit is unaffected allowing the ZOMBIE to respond to us with a RESET. 4) The attacker sends a SYN-ACK from their REAL IP to the ZOMBIE and we get a RESET back. NEW IDLE SCAN #2 – SYN Cache scans This scan is based on the fact that some modern TCP stacks will send SYN cookies after their HALF OPEN Connection queue is full. This scan has two things that are very different from other IDLE scans. 1) We are not spoofing packets from the ZOMBIE and sending them to the VICTIM like traditional IDLE scan methods. Instead, we are spoofing packets from the VICTIM and sending them to the ZOMBIE. This leads to a VERY interesting second difference. 2) We NEVER transmit a packet to the VICTIM. Not even spoofed packets! So the attacker doesn’t have to be able to ROUTE to the victim as long as the ZOMBIE can. This means you could potentially use a firewall or other network device to scan devices on the DMZ or other internal networks that are not accessible to the attacker. Here is a high level overview of how it is supposed to work: Overview: 1) Spoof the VICTIM and send a SYN to a ZOMBIE using the source port you want to scan on the VICTIM* *Note traditional IDLE scans send the packets to the VICTIM from the ZOMBIE 2) Send a SYN to the ZOMBIE from your real address 3) If you get back a SYN cookie back from the ZOMBIE the port on the VICTIM was open. If it is a normal SYN-ACK back the port on the VICTIM was close. Consider the following Open Port scenario: 1) Attacker spoof the VICTIM’s IP sending a SYN packet to the ZOMBIE 2) The ZOMBIE sends a SYN-ACK to the VICTIM exhausting it’s HALF-OPEN connection queue causing it to use SYN cookies for all any additional connection requests (pretend it had a connection queue of 1 for simplicity) 3) The attacker sends a SYN to the ZOMBIE from his real IP address. 4) Since the connection queue is full the ZOMBIE sends a SYN cookie 5) The attacker determines it is a SYN cookie and not a regular SYN based upon the fact that SYN cookies have some statistical anomalies in their ISNb and they are never retransmitted. Closed Port 1) Attacker spoof the VICTIMs IP sending a SYN packet to the ZOMBIE 2) The ZOMBIE sends a SYN-ACK to the VICTIM exhausting its HALF-OPEN connection queue causing it to use SYN cookies for all any additional connection requests. 3) The VICTIM sends a RST to the to the ZOMBIE causing the ZOMBIE to remove the entry from his half open connection queue. Since the half open connection queue isn’t full the VICTIM will respond with normal SYN-ACK and not SYN cookies to future requests. 3) The attacker sends a SYN to the ZOMBIE from his own IP address. 4) Since the connection queue is not full the ZOMBIE sends a normal SYN-ACK 5) The attacker determines it is a SYN-ACK and knows the port is CLOSED Of course there is more to it than I try to explain here. But the paper is definitely worth a read so check it out! Join me for SANS 560 vLive!! Monday – September 12, 2011 – Wednesday – October 19, 2011 Register Today!