Ethical Hacker and Scanning Tools

Can an ethical hacker simulate these scanning techniques to ensure the security of the network? We had stressed earlier that an ethical hacker does not have the liberty of time as a hacker in the wild. Therefore solely relying on the scanning tools that we are going to discuss or others in the wild are not advocated for the following reasons.

The first and foremost armor is knowledge itself. The results of a scanner can be misleading if the ethical hacker does not have a good knowledge of common vulnerabilities, commonly affected hosts , and patterns indicating misuse. Relying solely on the scanning tool to all threats is not practical as the author of the vulnerability check may have written it incorrectly. It is also likely that it was created in a controlled or known environment such as a test lab and might not work as well in the open .

Apart from this, performing an exhaustive scan against all the systems in a large enterprise is usually not feasible due to network constraints, stability of the backbone and scanned systems, and the dynamic nature of network deployments (wireless, DHCP, etc.). Therefore mere scanning does not a security check complete. A sound argument to back this statement is the fact that the scanner does not have an internal view of the host being audited and can miss critical misconfigurations that result in an insecure setup, but appear "secure" from the outside with automation.

Tool: ipEye, IPSecScan

 

Tools  

ipEye is a command-line driven port scanner written by Arne Vidstrom. It is a lightweight powerful tool bearing similarities with the command shell tools seen with UNIX. However, this port scanner is restricted to the Windows platform - 2000 and XP. Another drawback of this tool is that the hacker needs to know the specific IP before he can initiate a scan.

The basic usage for ipEye is:

ipEye <target IP> <scantype> -p <from port> <to port> [optional parameters]

The scantype parameter can take values of: -syn = SYN scan, -fin = FIN scan, -null = Null scan, - xmas = Xmas scan

However, the FIN, Null and Xmas scans don't work against Windows systems. Of these scan types, only the SYN SCAN is valid when scanning a Windows system. ipEye will scan the requested ports, given a valid IP address, and return a list of the FIN, Null and Xmas scans don't work against Windows systems.

• "Closed" indicates that there is a computer on the other end, but there is no service that listens at the port.

• "Reject" indicates the presence of a firewall or packet filtering device (sending a reset back) protecting the port.

• "Drop" indicates the presence of a firewall or packet filtering device that drops packets directed to port, or it indicates that the particular system is not alive on the target network.

• "Open" indicates that there is a service listening at the port.

Note in the above scan we see ports 135 and 139 as open.

Let us see the same scan done with IPSecScan. IPSecScan is a tool that can scan either a single IP address or a range of IP addresses looking for systems that are IPSec enabled.

In the scan above we have specified a range of IP addresses from 192.168.2.1 to 192.168.2.118. Note that the scan returns "Disabled" for some IPs - such as IP 192.168.2.1. This indicates that the system either doesn't support IPSec, has IPSec disabled, or that it is configured not to reveal that it has IPSec enabled.

A result of "Indeterminable" indicates that the scanner isn't sure if IPSec is enabled or disabled, it is also the label put on IP addresses which are not in use at all.

A result of "Enabled" indicates that the system has IPSec enabled.

Before we leave this discussion, let us take a look at what IPSec means.

IPsec is the short for IP Security. It is a set of protocols developed by the IETF to support secure exchange of packets at the IP layer.

IPsec = AH + ESP + IPcomp + IKE

• Authentication Header (AH): provides authenticity guarantee for packets, by attaching strong crypto checksum to packets. If a packet is received with AH and the checksum operation is successful, it indicates that the packet was originated by the expected peer (the packet was not generated by impersonator) and that the packet was not modified in transit. Unlike other protocols, AH covers the whole packet, from the IP header to the end of the packet.

• Encapsulating Security Payload (ESP) provides confidentiality guarantee for packets, by encrypting packets with encryption algorithms. If a packet is received with ESP and successfully decrypted it indicates that the packet was not wiretapped in the middle, if the sender and the receiver share a secret key, and no other party knows the key.

• ESP provides encryption service to the packets. However, encryption tends to give negative impact to compression on the wire (such as ppp compression). IP Compression (IPcomp) provides a way to compress packet before encryption by ESP.

• As discussed above, AH and ESP need shared secret key between peers. For communication between distant locations, there is a need to provide ways to negotiate keys in secrecy . Internet Key Exchange (IKE) makes this possible.

IPsec has been deployed widely to implement Virtual Private Networks (VPNs). IPsec supports two encryption modes: Transport and Tunnel.

Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec-compliant device decrypts each packet.

For IPsec to work, the sending and receiving devices must share a public key. This is accomplished through a protocol known as Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley), which allows the receiver to obtain a public key and authenticate the sender using digital certificates.

Note  

security of IPsec protocols depend on the secrecy of secret keys. If secret keys are compromised, IPsec protocols can no longer be secure.

Reference for readers: Old IPsec suite - RFC1825, New IPsec suite - RFC2401.

Tool: NetScan Tools Pro 2003

 

Tools  

NetScanTools consists of many independent network functions joined together in a single tabbed window. Most functions are designed to run in separate threads so several tabs can be used simultaneously . This program operates best on the newer Windows platforms.

NetScanTools communicates primarily using the TCP/IP protocol at the Winsock level. NetScanTools does not rely on remote agents to gather information. Instead, it uses active probing and in some circumstances passive listening for gathering information.

Active probing means that NetScanTools originates packets of information called datagrams and listens for responses to those packets. The responses are normally formatted into specific responses which are on a level above that of the transport level, such as a TCP or UDP. An example would be a name server response containing the IP address of a host.

NetScanTools Pro has a scanner tab - Port Prober, which will be discussed here. Port Probe (a port scanner) is an essential tool in determining the services or daemons running on a target machine. This prober is multithreaded, configurable and it allows running four different types of probing patterns. The user can build lists of target IP Addresses and lists of ports to probe, specifying timeouts and the protocol to connect with. Additionally, any data that is received from the target port upon connection is saved for viewing. The results are presented in a treeview and are colorcoded with different types of images for easy location of information at a glance.

The types of port connections supported are:

• TCP Full Connect. This mode makes a full connection to the target's TCP ports and can save any data or banners returned from the target. This mode is the most accurate for determining TCP services, but it is also easily recognized by Intrusion Detection Systems (IDS).

• UDP ICMP Port Unreachable Connect. This mode sends a short UDP packet to the target's UDP ports and looks for an ICMP Port Unreachable message in return. The absence of that message indicates either the port is used, or the target does not return the ICMP message which can lead to false positives. It can save any data or banners returned from the target. This mode is also easily recognized by IDS.

• TCP Full/UDP ICMP Combined. This mode combines the previous two modes into one operation.

• TCP SYN Half Open. (Windows XP/2000 only) This mode sends out a SYN packet to the target port and listens for the appropriate response. Open ports respond with a SYNACK and closed ports respond with ACKRST or RST. This mode is less likely to be noted by IDS, but since the connection is never fully completed, it cannot gather data or banner information. However, the attacker has full control over TTL, Source Port, MTU, Sequence number, and Window parameters in the SYN packet.

• TCP Other. (Windows XP/2000 only) This mode sends out a TCP packet with any combination of the SYN, FIN, ACK, RST, PSH, URG flags set to the target port and listens for the response. Again, the attacker can have full control over TTL, Source Port, MTU, Sequence number, and Window parameters in the custom TCP packet. The Analyze feature helps with analyzing the response based on the flag settings chosen . Each operating system responds differently to these special combinations. The tool includes presets for XMAS, NULL, FIN and ACK flag settings.

The four types of probe patterns are:

• Sequential Probe. This method scans a linear set of ports as defined by the start/end port numbers over a linear set of IP addresses as defined by the IP address range settings.

• Probe Port List. This mode probes only the ports listed in the Port List. This mode probes either a single host or a range of IP addresses based on the selection made in the Probe Single Host/Probe IP Range radio button group . It probes each host sequentially, that is the first, then the second etc., using the list of port numbers shown in the Port List.

• Sequential Port Probe Using the Target List. This mode probes every port using the Starting through ending port range on every computer in the target list.

• Probe a List of Ports on a List of Targets. This mode is the most stealthy mode and uses the least amount of CPU time and bandwidth because scanning is restricted to only the target ports on the target machines.

The tool also includes Ping before probe. This option allows the attacker to skip (automatically or by user response to a message) hosts that do not respond to pings . He can control the number of threads used to probe the host and the delay between launching each thread. He can also vary the amount of time to wait for a response to a probe of the port and the amount of time to wait after a connection for a banner to be sent.

In our lab scenario, we did a net scan to locate active hosts on the network, using the NetScanner tab, by specifying IP range.

On detecting live hosts, we probed a select target host to see the services running on the machine. We select host with IP 64.3x.3x.xxx and check for services running using a sequential probe. We find a HTTP service running on TCP port 80. We try to pry for some more information using the TCP Term tab. We get a bad request message, however, we also get to know that the server is running Microsoft IIS 4.0 version.

Similarly, we use the TCP Term tab to get information about the:

• POP3 server as +OK X1 NT-POP3 Server target.com (IMail 5.08 227094-2),

• SMTP server as 220 X1 NT-ESMTP Server target.com (IMail 5.05 110875 -1)

• IMAP server as * OK IMAP4 Server (IMail 5.09)

This is a wealth of information for an attacker. Similarly using Nslookup, we could trace the root server for this particular site and even find the TCP port with a domain.

Tool: Super Scan

 

The information retrieved was fairly good, but NetScan did register some more open ports with unknown service. Let us take a look at another scanner - SuperScan.

Tools  

SuperScan is a powerful connect-based TCP port scanner, pinger and hostname resolver. Released by Foundstone, its multithreaded and asynchronous techniques make this program extremely fast and versatile. SuperScan can do ping sweeps and scan any IP range. The attacker can also compile a list of target IP as a text file and use SuperScan to extract this list for scanning. The visual interface allows the attacker to view responses from connected hosts. The built in editor allows manipulation of port list and port descriptions. The advantage is that certain ports can be skipped as the ping results can be analyzed before hand to make the scan faster. The tool can be used to connect to any discovered open port using user-specified "helper" applications and then assign a custom helper application to any port. The attacker can also choose to save the scan list to a text file for future reference. The scan can be done slowly as well by controlling the transmission speed.

On the windows platform, Superscan does a very good job of swiftly looking for open ports. However, it does not give additional information such as if the port is closed, open, or filtered. Nmap is the better scanner for more detailed information, or when the attacker wants to use more advanced scanning techniques - for now SuperScan detects common ports.

Readers should note that the term "attacker" is used here, as these are the tools you might see being used over the Internet for unauthorized access. From a penetration tester's viewpoint, these very tools can be used to test the network as well as assist in doing reconnaissance about the attacker. In our example here, we find additional information on TCP ports that were not listed by NetScan Tools - we find a port with pcAnywhere data connection. This is good news to an attacker as he has to just get one point of access into the target system. Let us look at the data we have obtained here.

 * + 64.3x.3x.xxx    xxxxxx.com       ___    25   Simple Mail Transfer              ___  220 X1 NT-ESMTP Server xxxxxx.com (IMail 5.05 111734-1)..       ___    80   World Wide Web HTTP              ___   HTTP/1.1  200  OK..Server:  Microsoft-IIS/4.0..Cache-Control: no-cache..Expires: Mon, 21 Apr 2003 05:02:42 GMT..Content-Location:       ___    110  Post Office Protocol - Version 3              ___  +OK X1 NT-POP3 Server xxxxxx.com (IMail 5.08 228329-2)..       ___    135  DCE endpoint resolution __   139 NETBIOS Session Service       ___    143  Internet Message Access Protocol              ___  * OK IMAP4 Server (IMail 5.09)..       ___  1032   BBN IAD       ___  5631   pcANYWHEREdata       ___  5800   Virtual Network Computing server       ___  5900   Virtual Network Computing  server  ___  RFB 003.003.  

Notice how the scanner returns additional information about the services running on the ports. Here, we see some banner grabbing done for the HTTP server, SMTP server, IMAP server and the POP3 server.

Tool: NMap (Network Mapper)

 

Tools  

NMap or Network Mapper, written by Fyodor, is considered the best port scanning tool available currently. Traditionally available on the UNIX platform, it is now portable on almost all platforms including the windows platform. Nmap is an open source utility for network exploration or security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts. Nmap uses raw IP packets in innovative ways to determine what hosts are available on the network, what services (ports) they are offering, what operating system (and OS version) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. Nmap runs on most types of computers, and both console and graphical versions are available. Nmap is free software, available with full source code under the terms of the GNU GPL.

We will explore the windows version here for the graphical interface it provides. Let us first take a look at the scan types.

We have discussed the various scans at length in the earlier discussion on the TCP three -way handshake. However, we will revisit them briefly in this context again. We will supplement each scan type with a scan output directed towards a Linux machine.

Note  

For the SYN scan (sS option), a SYN packet is sent to the target. If a SYNACK is received, a RST is immediately sent to tear down the connection. The primary advantage to this scanning technique is that it might go unnoticed as this scan might not be logged. However, one needs root privileges to build these custom SYN packets. This is the default scan type for privileged users.

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (202.93.176.17) appears to be up ... good. Initiating SYN Stealth Scan against (202.93.176.17) Adding open port 80/tcp Adding open port 199/tcp Adding open port 22/tcp The SYN Stealth Scan took 10 seconds to scan 1601 ports. For  OSScan assuming  that port  22 is  open and port  1  is  closed  and neither are firewalled Interesting ports on (202.93.176.17): (The 1597 ports scanned but not shown below are in state: closed) Port       State       Service 22/tcp     open        ssh 80/tcp     open        http 199/tcp    open        smux 1720/tcp   filtered    H.323/Q.931 Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20 OS Fingerprint: TSeq(Class=RI%gcd=1%SI=38A91D%IPID=Z%TS=100HZ) T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T4(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) Uptime 21.348 days (since Tue Jun 24 14:10:11 2003) TCP Sequence Prediction: Class=random positive increments                          Difficulty=3713309 (Good luck!) TCP ISN  Seq.  Numbers:  145B1189  14679617  1409BDA8  14BA2947  14382805 1471C774 IPID Sequence Generation: All zeros Nmap run completed -- 1 IP address (1 host up) scanned in 19 seconds 

Note  

For the connect scan (sT option), a normal TCP connection is initiated. If the port is listening, connect () will succeed, otherwise the port isn't reachable . Though this scan does not need any special privileges for the user, it is easily as the target system's logs will register connections accepted by open services just to have it immediately shutdown.

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (202.93.176.17) appears to be up ... good. Initiating Connect () Scan against (202.93.176.17) Adding open port 22/tcp Adding open port 199/tcp Adding open port 80/tcp The Connect () Scan took 370 seconds to scan 1601 ports. For OSScan assuming that port 22 is open and port 1 is closed and neither are firewalled Interesting ports on (202.93.176.17): (The 1597 ports scanned but not shown below are in state: closed) Port       State       Service 22/tcp     open        ssh 80/tcp     open        http 199/tcp    open        smux 1720/tcp   filtered    H.323/Q.931 Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20 OS Fingerprint: TSeq(Class=RI%gcd=1%SI=2B8183%IPID=Z%TS=100HZ) Tl(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T4(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) Uptime 21.355 days (since Tue Jun 24 14:10:12 2003) TCP Sequence Prediction: Class=random positive increments                          Difficulty=2851203 (Good luck!) TCP  ISN  Seq.  Numbers: 358615B7  35DA3B9F  36107817  361BCFD1  36329A58 35AF32F4 IPID Sequence Generation: All zeros Nmap run completed -- 1 IP address (1 host up) scanned in 386 seconds ---------------- 

Sometimes it is not possible to use the SYN scan as the target may have filtered SYN packets through the firewall or other packet filtering devices. Here nmap can be used with the FIN (sF) / Xmas (sX) / Null (sN) options set. Closed ports reply with an RST, while open ports ignore the probe packet in accordance to RFC 793.

Tools  

The FIN scan uses a bare FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags.

FIN Scan Output

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (202.93.176.17) appears to be up ... good. Initiating FIN Scan against (202.93.176.17) The FIN Scan took 9 seconds to scan 1601 ports. Adding open port 199/tcp Adding open port 22/tcp Adding open port 1720/tcp Adding open port 80/tcp For OSScan assuming that port 22 is open and port 1 is closed and neither are firewalled Interesting ports on (202.93.176.17): (The 1597 ports scanned but not shown below are in state: closed) Port       State       Service 22/tcp     open        ssh 80/tcp     open        http 199/tcp    open        smux 1720/tcp   open        H.323/Q.931 Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20 OS Fingerprint: TSeq(Class=RI%gcd=1%SI=20E535%IPID=Z%TS=100HZ) Tl(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T4(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) Uptime 21.358 days (since Tue Jun 24 14:10:11 2003) TCP Sequence Prediction: Class=random positive increments Difficulty=2155829 (Good luck!) TCP  ISN Seq.  Numbers:  4A737CE3  4AC56FAC  4A4023DE  4A67DB18  4A980AEC 4A4DF87B IPID Sequence Generation: All zeros Nmap run completed -- 1 IP address (1 host up) scanned in 14 seconds 

What happens if the user wants to know which hosts are alive on the network and does not want to scan any of them? Nmap can do this by sending ICMP echo request packets to every IP address on the networks specified. Hosts that respond are up. If the network blocks ICMP requests , the host can still be detected as nmap send a TCP packet to port 80 by default. If the response is an RST, that machine is up. By default (for root users), nmap uses both the ICMP and ACK techniques in parallel. Pinging is done by default anyway, and only hosts that respond are scanned. Let us look at a ping sweep output that has been truncated here.

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (192.168.20.0) appears to be down. Host HOME-TTM9XYUI7J (192.168.20.10) appears to be up. _________________.. Host HOME-YAJJ51U3VD (192.168.20.51) appears to be up. Host RUNWAY (192.168.20.69) appears to be up. Host FUTURE (192.168.20.83) appears to be up. Host WORKGROUP (192.168.20.113) appears to be up. _________________.. Host WEBDESIGN (192.168.20.150) appears to be up. _________________.. Host Q4F104 (192.168.20.253) appears to be up. Host (192.168.20.254) appears to be up. Host (192.168.20.255) seems to be a subnet broadcast address (returned 1 extra ping). Nmap run completed -- 256 IP addresses (26 hosts up) scanned in 41 seconds 

UDP Scan

Nmap scans UDP ports by sending a zero byte UDP packet to each port on the target machine. If an ICMP port unreachable message is received, then the port is closed. Unfortunately UDP scanning is sometimes painfully slow (as we realized with our target host) since most hosts implement a suggestion in RFC 1812 (section 4.3.2.8) of limiting the ICMP error message rate. Linux machines limit destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. Solaris has much more strict limits (about 2 messages per sec ). Nmap detects this rate limiting and slows down accordingly , rather than flood the network with useless packets that will be ignored by the target machine. However, Windows machines can be scanned quickly as they do not abide by the RFC. A sample output is shown here.

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host RUNWAY (192.168.20.69) appears to be up ... good. Initiating UDP Scan against RUNWAY (192.168.20.69) The UDP Scan took 9 seconds to scan 1468 ports. Warning:  OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Interesting ports on RUNWAY (192.168.20.69): (The 1453 ports scanned but not shown below are in state: closed) Port       State       Service 7/udp      open        echo 9/udp      open        discard 13/udp     open        daytime 17/udp     open        qotd 19/udp     open        chargen 135/udp    open        loc-srv 137/udp    open        netbios-ns 138/udp    open        netbios-dgm 161/udp    open        snmp 445/udp    open        microsoft-ds 500/udp    open        isakmp 520/udp    open        route 1028/udp   open        ms-lsa 1031/udp   open        iad2 4500/udp   open        sae-urn Too many  fingerprints match this host for me to give an accurate OS guess TCP/IP fingerprint: SInfo(V=3.00%P=i686-pc-windows-windows%D=7/15%Time=3F14430B%0=-1%C=-1) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) Nmap run completed -- 1 IP address (1 host up) scanned in 35 seconds 

Idle Scan (sI option)

This advanced scan method allows for a truly blind TCP port scan of the target. Instead, a unique side-channel attack exploits predictable "IP fragmentation ID" sequence generation on the zombie host to glean information about the open ports on the target. The attacker listens on the zombie for change in the IPID to determine if the target host is open or filtered. The target hosts responds differently to the Zombie depending on port state. If the probed port is open, the target sends a SYNACK to the Zombie. The Zombie does not expect this SYNACK, so it sends a RST back. By sending the RST, the Zombie causes its IPID sequence number to increment. The real attacker detects this. If the port is closed, the target sends a RST to the Zombie. Zombies ignore this unsolicited RST packet and do not increment their IPID sequence number.

Note  

This scan is more stealth than the SYN scans and also allows mapping out IP-based trust relationships between machines. The port listing shows open ports from the perspective of the zombie host. This can detect trusted zombies. Let us look at a sample output here.

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (202.93.176.17) appears to be up ... good. Idlescan using zombie 192.168.20.69 (192.168.20.69:80); Class: Incremental Initiating Idlescan against (202.93.176.17) The Idlescan took 11 seconds to scan 1601 ports. Warning:  OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port All 1601 scanned ports on (202.93.176.17) are: closed Remote OS guesses: Linux Kernel 2.4.0 - 2.5.20, Linux 2.4.19-pre4 on Alpha, Linux Kernel 2.4.0 - 2.5.20 w/o tcp_timestamps, Gentoo 1.2 linux (Kernel 2.4.19-gentoo-rc5), Linux 2.5.25 or Gentoo 1.2 Linux 2.4.19 rcl- rc7), Linux 2.4.7 (X86) OS Fingerprint: T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) WARNING: Idlescan has erroneously detected phantom ports -- is the proxy 192.168.20.69 (192.168.20.69) really idle? Nmap run completed -- 1 IP address (1 host up) scanned in 17 seconds 

In the above output we notice that the OS guesses are more than what we received with the other scans. Also, there is a warning message intimating us that the zombie in question might not be a "zombie" after all. Nmap initiates idle scan by sending several packets in parallel and listening on the zombie host for increment in IPID. It counts the number of packets sent by a zombie and assuming those packets are responses to packets originated by the target. Thus, extraneous packets sent by a non-idle zombie cause significant confusion. Nmap tries to counter this problem with probe retransmission and other techniques (parallelism and timing) to detect false results. While this does compensate for slightly active hosts or dropped packets, another technique in dealing with highly active zombies is to send a large number (dozens or hundreds) of probes to each port. This "brute force" technique can hide a small amount of "white noise" traffic, but at the cost of significant bandwidth, slower scans, and the possibility of SYN flooding the target.

ACK Scan (sA option)

Note  

This option is used to map out firewall rulesets. This scan can help determine whether a firewall is stateful or if a simple packet filter is blocking the SYN packets. This can be tried out especially when the other scans such as Xmas /FIN/Null scans point towards the presence of a filtering device. This scan type sends an ACK packet possessing random acknowledgement /sequence numbers) to the ports specified. If a RST comes back, the ports are classified as " unfiltered ". If nothing comes back (or if an ICMP unreachable is returned), the port is classified as "filtered".

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (202.93.176.17) appears to be up ... good. Initiating ACK Scan against (202.93.176.17) The ACK Scan took 8 seconds to scan 1601 ports. Warning:  OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port All 1601 scanned ports on (202.93.176.17) are: Unfiltered Remote OS guesses: Linux Kernel 2.4.0 - 2.5.20, Linux 2.4.19-pre4 on Alpha, Linux Kernel 2.4.0 - 2.5.20 w/o tcp_timestamps, Gentoo 1.2 linux (Kernel 2.4.19-gentoo-rc5), Linux 2.5.25 or Gentoo 1.2 Linux 2.4.19 rcl- rc7), Linux 2.4.7 (X86) OS Fingerprint: T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) Nmap run completed -- 1 IP address (1 host up) scanned in 32 seconds 

Note  

Window Scan (sW option)

This scan is very similar to the ACK scan, except that it can sometimes detect open ports as well as filtered/nonfiltered due to an anomaly in the TCP window size reporting by some operating systems.

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (202.93.176.17) appears to be up ... good. Initiating Window Scan against (202.93.176.17) The Window Scan took 5 seconds to scan 1601 ports. Warning:  OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port All 1601 scanned ports on (202.93.176.17) are: closed Remote OS guesses: Linux Kernel 2.4.0 - 2.5.20, Linux 2.4.19-pre4 on Alpha, Linux Kernel 2.4.0 - 2.5.20 w/o tcp_timestamps, Gentoo 1.2 linux (Kernel 2.4.19-gentoo-rc5), Linux 2.5.25 or Gentoo 1.2 Linux 2.4.19 rcl- rc7), Linux 2.4.7 (X86) OS Fingerprint: T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) Nmap run completed -- 1 IP address (1 host up) scanned in 31 seconds 

Note  

RPC Scan (sR option)

This scan works in combination with other scans such as SYN scan. It takes all the TCP/UDP ports found open during the other scan and then floods them with SunRPC program NULL commands in an attempt to determine whether they are RPC ports, and if so, what program and version number they serve up.

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (202.63.106.17) appears to be up ... good. Initiating SYN Stealth Scan against (202.63.106.17) Adding open port 22/tcp Adding open port 199/tcp Adding open port 80/tcp The SYN Stealth Scan took 11 seconds to scan 1601 ports. Initiating RPCGrind Scan against (202.93.176.17) The RPCGrind Scan took 0 seconds to scan 0 ports. For  OSScan assuming that  port 22  is  open and  port 1 is closed and neither are firewalled Interesting ports on (202.93.176.17): (The 1597 ports scanned but not shown below are in state: closed) Port       State       Service (RPC) 22/tcp     open        ssh 80/tcp     open        http 199/tcp    open        smux 1720/tcp filtered      H.323/Q.931 Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20 OS Fingerprint: TSeq(Class=RI%gcd=1%SI=238705%IPID=Z%TS=100HZ) Tl(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T4(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLE N=164%RIPTL=148%RIPCK=E%UCK=E%ULEN=134%DAT=E) Uptime 21.403 days (since Tue Jun 24 14:10:10 2003) TCP Sequence Prediction: Class=random positive increments Difficulty=2328325 (Good luck!) TCP  ISN  Seq.  Numbers: 3DF4D257  3DF224B1  3E5BCC18  3E94EC5E  3E7C4526 3E9841B7 IPID Sequence Generation: All zeros Nmap run completed -- 1 IP address (1 host up) scanned in 45 seconds 

The other scans - list scan (sL) simply generates and prints a list of IPs/Names without actually pinging or port scanning them. DNS name resolution will be performed unless opted otherwise.

For the FTP bounce scan, please refer the discussion of scan types done earlier in the module.

We will discuss how nmap does the remote OS detection in detail under our discussion on active stack fingerprinting. The outputs shown here (where generated for the same host) are given for comparison purpose. The reader can gauge how the nature of scan influences the output.

Note  

Let us look at some of the other options we have in nmap.

The user can spoof the scan in several ways. One way is to give a different source IP (S <ip> option). If you are on a broadcast Ethernet segment it is possible to specify a non-existent IP address and to sniff the network for the packets being sent as reply to the address.

Another way of keeping the identity obscure is to use the decoy option. Here, several scans are spoofed as originating from decoy machines. The real scan from the user's machine is interspersed in-between. This is a slow scan and obscurity gets better with more number of decoys. The idea here is to confuse the target host's administrator regarding the real scan. Note that the hosts used as decoys should be up or the scan might accidentally SYN flood the target.

The ident scan option can be used only if the target has the port 113/auth open. It only works with TCP connect scans (-sT). This will reveal the owner of the daemon which is listening on the port if the site is running identd. This scan requires the complete TCP three way handshake (-sT) and will be registered on the target.

The fragmentation option allows the user to fragment the packet into small IP fragments. This makes it harder for packet filters to detect the scan unless they queue up all IP fragments (which are rare). However, sometimes this can cause unexpected behavior in the target system .

 Starting nmap V. 3.00 (www.insecure.org/nmap) Host (196.12.44.67) appears to be up ... good. Initiating SYN Stealth Scan against (196.12.44.67) The SYN Stealth Scan took 360 seconds to scan 1601 ports. For OSScan assuming that port 53 is open and port 1 is closed and neither are firewalled Interesting ports on (196.12.44.67): (The 1595 ports scanned but not shown below are in state: closed) Port       State       Service 53/tcp     open        domain 80/tcp     open        http 135/tcp    open        loc-srv 139/tcp    open        netbios-ssn 1029/tcp   open        ms-lsa 1720/tcp   filtered    H.323/Q.931 Remote operating system guess: Windows NT4 or 95/98/98SE OS Fingerprint: TSeq(Class=TD%gcd=1%SI=4%IPID=RPI%TS=U) Tl(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M) T2(Resp=N) T3(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M) T4(Resp=Y%DF=N%W=0%ACK=0%Flags=R%Ops=) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=0%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RIPCK=E%UCK=E%U LEN=134%DAT=E) TCP Sequence Prediction: Class=trivial time dependency Difficulty=4 (Trivial joke) TCP ISN Seq. Numbers: 1461E 14625 14627 14633 14638 IPID Sequence Generation: Random positive increments Nmap run completed -- 1 IP address (1 host up) scanned in 397 seconds 

Active Stack Fingerprinting

• Fingerprinting is done to determine the remote OS

• Allows attacker to leave smaller footprint and have greater chance to succeed

• Based on the fact that various OS vendors implement the TCP stack differently

• Specially crafted packets sent to remote OS and response is noted. This is compared with a database to determine the OS

 

Let us take a look at how Nmap guessed the remote system. This technique is called OS fingerprinting.

Concept  

The term OS fingerprinting defines any method used to determine what operating system is running on a remote computer. OS fingerprinting is an essential part of network reconnaissance, because the attacker has a greater probability of succeeding in his attack if he can formulate his attack strategy based on operating systems specific vulnerabilities.

Note  

Remote OS fingerprinting is carried out by noting the way the remote system responds to specifically crafted TCP packets. These can range from examining the default TCP window size in a packet, to measuring the amount of data in ICMP packets, and even gauging TCP initial sequence numbers. Similar to port scanning, there are several methods to successfully fingerprint an OS. Querying the services running on a target machine is often the simplest means for OS fingerprinting.

Note  

Active stack fingerprinting is based on the principle that an operating system's IP stack has its own unique way of responding to specially crafted TCP packets. This arises due to the different interpretations that vendors abide with while implementing the TCP/IP stack on the particular OS. In active fingerprinting, a variety of malformed packets are sent to the remote host, and the responses compared to a database.

For instance, in Nmap, the OS fingerprint is done through eight tests. Each of these tests is described below.

• The first test is named T1 for test 1. In this test a TCP packet with the SYN, and ECN-Echo flags enabled is sent to an open TCP port.

• The second test is named T2 for test 2. It involves sending a TCP packet with no flags enabled to an open TCP port. This type of packet is known as a NULL packet.

• The third test is named T3 for test 3. It involves sending a TCP packet with the URG, PSH, SYN, and FIN flags enabled to an open TCP port.

• The fourth test is named T4 for test 4. It involves sending a TCP packet with the ACK flag enabled to an open TCP port.

• The fifth test is named T5 for test 5. It involves sending a TCP packet with the SYN flag enabled to a closed TCP port.

• The sixth test is named T6 for test 6. It involves sending a TCP packet with the ACK flag enabled to a closed TCP port.

• The seventh test is named T7 for test 7. It involves sending a TCP packet with the URG, PSH, and FIN flags enabled to a closed TCP port.

• The eighth test is named PU for port unreachable test. It involves sending a UDP packet to a closed UDP port. The objective is to extract an ICMP port unreachable message back from the target machine.

But this is not all. The last test that Nmap performs is named TSeq for TCP sequenceability test. The test tries to determine the sequence generation patterns of the TCP initial sequence numbers also known as TCP ISN sampling, the IP identification numbers also known as IPID sampling, and the TCP timestamp numbers. The test is performed by sending six TCP packets with the SYN flag enabled to an open TCP port.

The objective is to find patterns in the initial sequence numbers chosen by TCP implementations when responding to a connection request. These can be categorized in to many groups such as the traditional 64K (many old UNIX boxes), Random increments (newer versions of Solaris, IRIX, FreeBSD, Digital UNIX, Cray, and many others), True "random" (Linux 2.0.*, OpenVMS, newer AIX, etc). Windows boxes use a "time dependent" model where the ISN is incremented by a fixed amount each time period.

Most operating systems increment a system-wide IPID value for each packet they send. Others, such as OpenBSD, use a random IPID and some systems (like Linux) use an IPID of o in many cases where the "Don't Fragment" bit is not set. Windows does not put the IPID in network byte order, so it increments by256 for each packet. Another number that can be sequenced for OS detection purposes is the TCP timestamp option values. Some systems do not support the feature; others increment the value at frequencies of 2HZ, 100HZ, or 1000HZ, and still others return 0. ^[1]

Passive Fingerprinting

• Passive fingerprinting is also based on the differential implantation of the stack and the various ways an OS responds to it.

• However, instead of relying on scanning the target host, passive fingerprinting captures packets from the target host and study it for tell tale signs that can reveal the OS.

• Passive fingerprinting is less accurate than active fingerprinting.

 

Like active fingerprinting, passive fingerprinting is also based on the differential implantation of the stack and the various ways an OS responds to it. However, instead of relying on scanning the target host, passive fingerprinting captures packets from the target host and study it for tell tale signs that can reveal the OS.

Note  

The four areas that are typically noted to determine the operating system are:

• TTL - What the operating system sets the Time To Live on the outbound packet

• Window Size - What the operating system sets the Window Size at.

• DF - Does the operating system set the Don't Fragment bit?

• TOS - Does the operating system set the Type of Service, and if so, at what?

Passive fingerprinting need not be fully accurate nor does it have to be limited to these four signatures. However, by looking at several signatures and combining the information, the accuracy can be improved upon. The following is the analysis of a sniffed packet dissected by Lance Spitzner in his paper on passive fingerprinting (http://www.honeynet.org/papers/finger/)

 04/20-21:41:48.129662 129.142.224.3:659 -> 172.16.1.107:604 TCP TTL:45 TOS:oxo ID:56257 ***F**A* Seq: 0x9DD90553 Ack: 0xE3C65D7Win: 0x7D78 

Based on the 4 criteria, the following is identified:

• TTL: 45

• Window Size: 0x7D78 (or 32120 in decimal)

• DF: The Don't Fragment bit is set

• TOS: 0x0

This information is then compared to a database of signatures. Considering the TTL used by the remote host, it is seen from the sniffer trace that the TTL is set at 45. This indicates that it went through 19 hops to get to the target, so the original TTL must have been set at 64. Based on this TTL, it appears that the packet was sent from a Linux or FreeBSD box, (however, more system signatures need to be added to the database). This TTL is confirmed by doing a traceroute to the remote host.

If the trace needs to be done stealthily, the traceroute time-to-live (default 30 hops), can be set to be one or two hops less then the remote host (-m option). Setting traceroute in this manner reveals the path information (including the upstream provider) without actually touching the remote host.

The next step is to compare the Window size. The Window Size is another effective tool, specifically what Window Size is used and how often the size changes. In the above signature, it is set at 0x7D78, a default Window Size commonly used by Linux. Also, Linux, FreeBSD, and Solaris tend to maintain the same Window Size throughout a session. However, Cisco routers and Microsoft Windows/NT Window Sizes are constantly changing. The Window Size is more accurate if measured after the initial three -way handshake (due to TCP slow start).

Most systems use the DF bit set, so this is of limited value. However, this does make it easier to identify the few systems that do not use the DF flag (such as SCO or OpenBSD). TOS is also of limited value. This seems to be more session based then operating system. In other words, it's not so much the operating system that determines the TOS, but the protocol used. Therefore, based on the information above, specifically TTL and Window size, one can compare the results to the database of signatures and with a degree of confidence determine the OS (in this case, Linux kernel 2.2.x).

Note  

Just as with Active Fingerprinting, Passive Fingerprinting has some limitations. First, applications that build their own packets (such as nmap, hunt, nemesi s, etc) will not use the same signatures as the operating system. Second, it is relatively simple for a remote host to adjust the TTL, Window Size, DF, or TOS setting on packets.

Threat  

Passive fingerprinting can be used for several other purposes. It can be used by crackers as 'stealthy' fingerprinting. For example, to determine the Operating System of a 'potential victim', such as a web server, one only needs to request a webpage from the server, and then analyze the sniffer traces. This bypasses the need for using an active tool that can be detected by various IDS systems. Also, Passive Fingerprinting may be used to identify remote proxy firewalls. Since proxy firewalls rebuild connection for clients , it may be possible to ID the proxy firewalls based on the signatures we have discussed. Organizations can use Passive Fingerprinting to identify 'rogue' systems on their network. These would be systems that are not authorized on the network.

Cheops

 

Tools  

Cheops (KEE-ops) is a Network management tool for mapping and monitoring the network. It has host/network discovery functionality as well as OS detection of hosts.

Cheops is an Open Source Network User Interface. It is designed to be the network equivalent of a Swiss-army knife , unifying your network utilities. Cheops does for the network what a file manager does for the file system.

Cheops can optionally determine the OS of hosts on the network, selecting appropriate icons for them. Cheops can show the routes taken to access areas of the network. This feature is designed for larger networks, with routers, subnets, etc. This mapping not only makes hierarchy clearer, but can show unusual routing issues.

Cheops includes a generalized TCP port scanner to see what ports on the network are in use. It can be used to retrieve version information for certain services, to be sure any given host is up-to-date with the latest revision of its services.

Cheops includes a simple integrated SNMP browser, including write capability, using the UCD SNMP library. Cheops also supports a plug-in interface, which includes support for SNMP plug-ins, similar in concept to those of HP Openview.

Cheops can monitor critical servers, and immediately notify the concerned person through its event log, standard e-mail, and soon via paging, when things go wrong. The network administrator can know exactly which system is up or down, and just when problems occur. Right clicking on a host quickly shows a list of common services it supports, and rapid, easy access to them. The co-developer has given cheops a makeover and it is called Cheops-ng (new generation)

SocksChain

• SocksChain is a program that allows to work through a chain of SOCKS or HTTP proxies to conceal the actual IP-address.

• SocksChain can function as a usual SOCKS-server that transmits queries through a chain of proxies.

 

Tools  

SocksChain is a program that allows to work through a chain of SOCKS or HTTP proxies to conceal the actual IP-address. SocksChain can function as a usual SOCKS-server that transmits queries through a chain of proxies. SocksChain can be used with client programs that do not support the SOCKS protocol, but work with one TCP-connection, such as TELNET, HTTP, IRC... (FTP uses 2 connections).

SocksChain transmits the TCP-call of a client program in such a way that it successively goes through a chain of proxies. SocksChain itself is connected only with the first element of this chain. That one in its turn is connected with the second and so on.

So, to track where the query was initiated from with the help of server logs is very complex. To do that, one should analyze the logs of all intermediates one by one in the reverse order. If somewhere the logs are not kept, the thread will be lost. Theoretically it provides a high degree of anonymity. But it affects the speed of data transmission as it is inversely proportional to the chain length.

In all variety of proxies there are 2 basic types of universal services, i.e. allowing to transmit any TCP-connections (not only, say, HTTP and FTP). Only they make a chain possible and, therefore, are useful for SocksChain:

SOCK4 and SOCKS5 services. Their default port is 1080. SOCKS5 is the most universal service, as it allows not only establish TCP-connections but open a port for incoming TCP-connections (BIND operation) and transmit/receive UDP-datagrams as well.

HTTP-proxy with a possibility of SSL-tunneling. The default ports are 80, 8080, 3128. This service is less universal than SOCKS5, but by far more widespread.

Proxy Servers

• Proxy is a network computer that can serve as an intermediate for connection with other computers. They are usually used for the following purposes:

  • As firewall, a proxy protects the local network from outside access.

  • As IP-addresses multiplexer, a proxy allows to connect a number of computers to Internet when having only one IP-address

  • Proxy servers can be used (to some extent) to anonymize web surfing.

  • Specialized proxy servers can filter out unwanted content, such as ads or 'unsuitable' material.

  • Proxy servers can afford some protection against hacking attacks.

 

Tools  

Proxy is a network computer that can serve as an intermediate for connection with other computers. They are usually used for the following purposes:

• As firewall, a proxy protects the local network from outside access.

• As IP-addresses multiplexer, a proxy allows to connect a number of computers to Internet when having only one IP-address

• Proxy servers can be used (to some extent) to anonymize web surfing.

• Specialized proxy servers can filter out unwanted content, such as ads or 'unsuitable' material.

• Proxy servers can afford some protection against hacking attacks.

The program Wingate is often used as proxy. Quite a number of such proxies are open to easy access. Anonymous proxies hide the real IP address (and sometimes other information) from websites that the user visits . There are two sorts; ones can be used in the same way as the non-anonymous proxies above, and web-based anonymizers.

Using a non-anonymous proxy:

HTTP_X_FORWARDED_FOR = 62.64.175.55, 194.72.9.37. This shows the IP address (first number) and possibly the IP address of the proxy server used (second).

Using an anonymous proxy:

HTTP_X_FORWARDED_FOR = 66.51.107.3 This now only shows the IP address of the proxy.

Anonymizers

• Anonymizers are services that help make your own web surfing anonymous.

• The first anonymizer developed was Anonymizer.com, created in 1997 by Lance Cottrell.

• An anonymizer removes all the identifying information from a user's computers while the user surfs the Internet, thereby ensuring the privacy of the user.

 

Note  

Anonymizers are services that help make your own web surfing anonymous. The first anonymizer developed was Anonymizer.com, created in 1997 by Lance Cottrell. An anonymizer removes all the identifying information from a user's computers while the user surfs the Internet, thereby ensuring the privacy of the user.

Many anonymizer sites create an anonymized URL by appending the name of the site the user wishes to access to their own URL, e.g.:

http://anon.free.anonymizer.com/http://www.yahoo.com/

After the user anonymizes a web access with an anonymizer prefix, every subsequent link selected is also automatically accessed anonymously. Most anonymizers can anonymize at least the web (http:), file transfer protocol (ftp:), and gopher (gopher:) Internet services.

To visit a page anonymously, the user visits his preferred Anonymizer site, and then enters the name of the target site in the anonymization field. Alternatively, he can set his browser home page to point to an anonymizer, so that every subsequent web access made will be anonymized. Apart from this, he can choose to anonymously provide password and other information to sites that request it, without revealing any other information such as his IP address. Crackers may configure an anonymizer as a permanent proxy server by making the site name the setting for the HTTP, FTP, Gopher, and other proxy options in their applications configuration menu, thereby cloaking their malicious activities.

However, anonymizers have the following limitations:

• HTTPS. Secure protocols like " https :" cannot be properly anonymized, since the browser needs to access the site directly to properly maintain the secure encryption.

• Plugins. If an accessed site invokes a third-party plugin, then there is no guarantee that they will not establish independent direct connections from the user computer to a remote site.

• Logs. All anonymizer sites claim that they don't keep a log of requests. Some sites, such as the Anonymizer, keep a log of the addresses accessed, but don't keep a log of the connection between accessed addresses and users logged in.

• Java. Any Java application that is accessed through an anonymizer will not be able to bypass the Java security wall.

• Active X. Active-X applications have almost unlimited access to the user's computer system.

• JavaScript. The JavaScript scripting language is disabled with url-based anonymizers

Some anonymizer sites are:

• Anonymizer.com

• Anonymize.net

• @nonymouse.com

• Iprive.com

• MagusNet Public Proxy

• MuteMail.com PublicProxyServers.com

• Rewebber.de

• SilentSurf.com

• Surfola.com

• Ultimate-anonymity.com

Bypassing Firewall using Httptunnel

http://www.nocrew.org/software/httptunnel.html

• Httptunnel creates a bidirectional virtual data path tunneled in HTTP requests. The requests can be sent via an HTTP proxy if so desired.

 

Tools  

httptunnel creates a bidirectional virtual data connection tunneled in HTTP requests. The HTTP requests can be sent via an HTTP proxy if so desired. This can be useful for users behind restrictive firewalls. If WWW access is allowed through a HTTP proxy, it's possible to use httptunnel and telnet or PPP to connect to a computer outside the firewall.

A HTTP tunnel encapsulates packets in the HTTP protocol, which is usually allowed though firewalls, perhaps via a proxy. If the user wants to connect to a port on the destination computer, he will connect to that port on the httptunnel client (htc), which is typically run on the user's computer. The htc program makes two TCP connections to a httptunnel server (hts) which runs on a computer that can accept external HTTP connections and can connect to the desired port on the destination computer. The desired bi-directional TCP connection is split into the two TCP connections, each of which is used for a HTTP method. Data from the user is sent with the HTTP POST method, and the user receives the data from the destination with the HTTP GET method. Both the POST and the GET methods are initiated by htc.

HttpTunnel runs a protocol inside of the HTTP method. For example, data is sent encapsulated by a tunnel header consisting of 0x02, followed by the length of the data, followed by the data. Thus, the user TCP data is sent via multiple tunnel packets, in a HTTP method, which is carried by a TCP connection, transferred by IP packets.

Here is how htc sends data to the destination:

1. Open TCP connection to hts

2. Send HTTP POST with a large Content-Length

3. Send TUNNEL_DATA packets until POST Content-Length would be exceeded.

4. Send TUNNEL_PADDING packets to exactly satisfy Content-Length - 1

5. Send TUNNEL_DISCONNECT (1 byte)

6. Close TCP connection

7. Go to step 1

Here is how htc gets data from the destination.

1. Open TCP connection to hts

2. Send HTTP GET

3. Wait for response from hts

4. Read TUNNEL_DATA, then TUNNEL_PADDING, TUNNEL_DISCONNECT packets

5. Close TCP connection

6. Go to step 1

Tunnel creation and destruction

When a TCP connection is opened via the tunnel, the TUNNEL_OPEN packet is sent. When the TCP connection that is being tunneled (as opposed to the HTTP TCP connections) close, the TUNNEL_CLOSE packet is sent on the respective GET or POST HTTP TCP connection. The standard TUNNEL-CLOSE server and client can only handle one connection at a time.

Http Tunnel supports using HTTP proxies. The way these work is that TCP connections are made to the proxies, and the proxy makes the HTTP request to the HTTP server. The proxies get the HTTP server from the Host field in the HTTP header. If the proxy requires authorization, this is provided by the Base64-encoded username and password in the HTTP Proxy-Authorization field.

HTTPort

• HTTPort allows you to bypass an HTTP proxy, which is blocking you from the Internet. With HTTPort you may use the following software (just a sample list, not limited to !) from behind an HTTP proxy: e-mail, IRC, ICQ, news, FTP, AIM, any SOCKS capable software, etc. etc.

 

Tools  

HTTPort allows you to bypass an HTTP proxy, which is blocking you from the Internet. With HTTPort you may use the following software (just a sample list, not limited to !) from behind an HTTP proxy: e-mail, IRC, ICQ, news, FTP, AIM, any SOCKS capable software, etc. etc.

The basic idea is that you set up your Internet software in such a manner, that it considers your local PC to be a remote server it needs. This is where HTTPort enters. It intercepts connection from this software and runs the connection through the proxy - this is called a tunneling. Your software should use TCP/IP. HTTPort does not work with UDP/IP. There are two ways you can set up your software for use with HTTPort:

1. If your software uses a single (small range of) fixed server with a single (small range of) fixed port: For instance your software would like to connect to some.server.com:some_port. Create a new HTTPort mapping, with any local port, preferably above 1024, remote server of "some.server.com" and remote port of "some_port". Point your software to 127.0.0.1:mapped_local_port as if it was the original server it needs.

2. If your software can connect through SOCKS4 proxy: Point your software to 127.0.0.1:1080, which is a built-in HTTPort SOCKS4 server.

HTTPort makes it possible to open a client side of a TCP/IP connection and provide it to any software. CLIENT means that HTTPort may not be used for Trojans like NetBus or BackOrifice, because HTTPort can't make a "listening" server side of a TCP/IP connection, available for connection from outside, which could possibly be exploited by Trojans. This in turn means that HTTPort may be exploited by "client type" software only, not "server type". ANY SOFTWARE means, that ANY OTHER software may use the same technique that HTTPort does to perform exactly the same. Moreover, the client side of malicious software may use plain HTTP protocol to access remote malicious server.

Summary

• War dialing is the term given to accessing a network illegally over a compromised phone line. Popular tools include THC war dialer and phone sweep.

• Scanning is a method adopted by administrators and crackers alike to discover more about a network

• There are various scan types - SYN, FIN, Connect, ACK, RPC, Inverse Mapping, FTP Bounce, Idle Host etc. The use of a particular scan type depends on the objective at hand.

• Ways to subvert a standard connection include HTTPort, HTTP tunneling, using proxies, SOCKS chains and anonymizers.

 

^[1] (Reference for Nmap: www.insecure.org - documents, mailing lists etc)