Diggin Em Walls (part3) - Advanced/Other Techniques for ByPassing Firewalls # Firewalls    May 10 2002 - 01:54 EST    Posted By Ka0ticSH      (0) Preface: In the previous documents related to this series, Diggin Em Walls Part 1 and Diggin Em Walls Part 2, I noted various techniques and methods used to detect firewalls, probe networks behind firewalls, and even bypass firewalls through port redirection. In this document we will discuss other means and techniques of detecting hosts behind firewalls, bypassing firewalls, protocol tunneling and some insecurities with certain types of packetfiltering techniques. For this document, knowledge in TCP/IP, networking, Access Control Lists, and most firewall concepts, and it would help if you read my other two parts =D. Enjoy. 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 describd the use of traceroute and ICMP packets to detect hidden hosts. There are more indepth 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 givin, 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 recieves 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 recieve 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 no-response, 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 subnet mask on a target network. The response, ICMP Type 18, Address Mask Reply, would include the subnet 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) Recieving 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 recieving 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) Recieving 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 suprised 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 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: (For ALL 3 articles) 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 --Ka0ticSH asm.coder@verizon.net      (0)

To the best of our knowledge, the text on this page either may be freely reproduced and distributed or was written specifically for fromadia.com. The site layout, page layout, and all original artwork on this site are Copyright © 2002 Fromadia.com. If you wish to reproduce any of it or if you are author of a work that you feel shouldn't be printed here, please email us at copyright@fromadia.com.

Enter a keyword...

sponsored links web hosting Reseller Hosting