Security

Lock IT Down: Security assessment shows idlescan is not an idle threat

Get a detailed look at the threat of Idlescanning and the security issues involved.

As a standard part of a security assessment in support of financial audits, my company, CQUR IT, conducts penetration testing to gauge the client’s external security. One recent assessment yielded an interesting double-edged security architecture that provided an increased level of protection but left the client highly vulnerable to a denial of service (DoS) attack by a variety of methods, including an emerging threat known as idlescanning.

I’ll explain how we identified the vulnerability and made recommendations to maintain the client’s security while minimizing the potential for a DoS attack.

Autoblocking ports: The good
We first attempted to map the client’s network using Nmap. Shortly after we began the Nmap scan, we unexpectedly lost the ability to ping or probe any of the client’s external IP addresses, with the exception of the Internet router. Fortunately, we recognized a banner response from the firewall as being indicative of a WatchGuard Firebox firewall. From experience, we knew that this particular firewall has an interesting feature known as autoblocking. From the online vendor documentation, we determined that this version of the WatchGuard Firebox enabled an autoblock feature by default. (Newer versions of this product do not have autoblocking enabled by default. However, it’s possible for Firebox users to enable autoblocking if they choose.) Here are the specifics:
  • This feature is triggered on attempts to connect to specific ports.
  • The default ports that trigger this feature are 1, 111, 513–514, 2049, 6000–6005, 7100–7109, and 8000.
  • Once triggered, a DENY rule is added, which blocks the source IP for 20 minutes.

The autoblock feature blocked access to our IP address for 20 minutes because our Nmap configuration included several default autoblock ports. Hoping that the firewall administrator had left autoblock in the default configuration, we attempted to scan around the default trigger ports using the following command line:
nmap -P0 -p 2-110,112-512,515-2048,2050-5999,6006-7099,7111-7999,
8001-65535 -O -T Sneaky -sS 67.105.146.97-111


Unfortunately, we found our IP address blocked for another 20 minutes. Scanning only ports 2–110 and 112–512 proved successful, although it yielded limited information. The scanning of ports 515–2048 once again triggered the autoblock feature, indicating that the firewall admin had changed the default configuration and specified an additional port(s) in that range to be blocked.

We considered writing a Linux shell script to automate the process and identify which ports were triggering the autoblock feature but instead thought it would be advantageous to consider other elements of the client’s security architecture.

Convenience yields risk
Our concern for the DoS potential associated with the autoblock feature led us to focus our attention on the Internet router. The Nmap results below are both interesting and significant:
Interesting ports on wxxx.zxxxxxx.xxx-xx.dsl.xxx.net (XX.XXX.XXX.XX):
(The 1148 ports scanned but not shown below are in state: closed)
Port  State  Service
23/tcp  open  telnet    
80/tcp  open  http    

Remote operating system guess: DSL Router: Flowpoint 144/22XX v3.0.8
or SpeedStream 5851 v4.0.5.1

TCP Sequence Prediction: Class=truly random
IPID Sequence Generation: Incremental


Because the client preferred the ability to remotely manage its router, both management ports (Telnet/23 and HTTP/80) were accessible via the Internet. There is an inherent risk-for-convenience trade-off to this fairly common practice. Strong passwords are essential if this configuration is dictated by business requirements.

Given time and motivation, a malicious user could brute-force the password, making the client’s network highly vulnerable to further exploitation. We decided to attempt to use the open HTTP interface on the router to scan the network without triggering the autoblock feature by using an emerging scanning technique, an idlescan.

The basics of an idlescan
Devices that communicate via TCP/IP assign an IP identification number (IPID) to each packet. Most devices assign each IPID sequentially. Knowledge of this behavior may allow malicious external users to port scan a target by reflecting or bouncing the scan off a secondary device (usually a Web server) to keep their identity unknown. The following sequence will clarify idlescanning:
  • HackerX decides that he wants to attack XYZ.com but wants to hide his IP address because he is concerned that XYZ actively monitors firewall and intrusion-detection logs.
  • HackerX identifies a “zombie” Web server with low traffic levels to use to surreptitiously perform the scanning on his behalf.
  • HackerX initiates a conversation with the zombie Web server and records the IPID received from the zombie Web server.
  • HackerX initiates a conversation (on the port of interest) with the XYZ target server but spoofs the XYZ target server by replacing his IP address with the IP address of the zombie Web server.
  • The zombie Web server receives the spoof-induced response from the XYZ target server. If the port is open, the zombie Web server will acknowledge the XYZ target server (which increases the IPID number by 1). If the port is closed, the zombie Web server will not acknowledge the XYZ target server (the IPID number stays the same).
  • HackerX initiates another conversation with the zombie Web server and records the IPID received. If the IPID has increased by 2, the target port on the XYZ target server is open. If the IPID has increased by 1, the target port is closed. Hence, HackerX has successfully determined the target server’s port status without exposing his IP address.

While this process would be labor-intensive to conduct manually, Nmap has automated this capability. (A more detailed and technical discussion of idlescanning can be found at insecure.org.)

One + one = three
We expected that we could leverage the router management port as a reflection point to allow unblocked (and undetectable) scanning of the client network because the autoblock feature should be set to exclude the IP addresses of other client-owned network devices. We bounced the idlescan off the router with the mail server as the target, as shown here:
# nmap (V. 3.00) scan initiated Tue Dec 10 12:50:10 2002 as: nmap -sI
XX.XXX.XXX.XX -F -O -oN idlefromrouter.txt XX.XXX.XXX.XXX


Surprisingly, instead of conducting a successful scan, we were no longer able to access the client’s network. The autoblock feature had blocked access from the internal network to the router after the router attempted to connect to one of the autoblocked ports. Internet access to the network was completely shut down, denying normal business operations. The autoblock feature intended to protect the network had effectively denial-of-serviced itself.

Theory vs. real world
In theory, autoblocking of IP addresses is a wonderful idea and can be very effective in reducing the number of “script-kiddie” scans run against a network when enabled on a perimeter firewall. However, as our penetration testing illustrated, the potential for DoS attacks is great, and the risk associated with this feature may outweigh the benefit for many organizations’ security architectures.

Reconfiguring the autoblock feature to exclude the router would not eliminate the potential for a DoS attack. Using spoofed sources for port scans, a malicious user could potentially trigger a repetitive autoblock and initiate a DoS attack against vital systems such as the mail server or the Web server. If the client reconfigured the autoblock feature to exclude these IPs, a malicious user could spoof other key components of its infrastructure, including its ISP’s upstream routers, DNS servers, or external business partners’ systems.

Excluding all of these elements of an infrastructure would be impractical from an administrative perspective and ineffective from a security perspective.

Final thoughts
Balancing protection against the risk of the protection itself is often an overlooked element of strong network security. In this case, the benefit gained by implementing autoblocking (making scanning of the network difficult) was greatly outweighed by the risk (a relatively simple-to-execute DoS opportunity) created by the autoblock feature itself. Third-party validation of key security configuration and design elements (firewall configuration and rule bases, Internet architecture, remote access) is a logical means of detecting security flaws before malicious users do.
0 comments

Editor's Picks