================================================================================ Reverse Tunneling Techniques: theoretical requirements for the GW implementation v1.0 - March 2004 Jakub Sławiński Gray-World Team http://www.gray-world.net ================================================================================ ================================================================================ Copyright (c) 2004, Jakub Sławiński . Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. You should have received a copy of the license with this document and it should be present in the fdl.txt file. If you did not receive this file or if you don't think this fdl.txt license is correct, have a look at the official http://www.fsf.org/licenses/fdl.txt licence file. ================================================================================ ======= SUMMARY ======= CHANGELOG AND NOTES INTRODUCTION TERMS 1. LIMITATIONS AND REQUIREMENTS 1.1 Bandwidth 1.2 Latency 1.3 Stealthiness 2. DESIGN 2.1 Logical channels 2.2 Possible methods 2.2.1 SMTP/IMAP/POP3 2.2.2 HTTP/HTTPS 2.2.3 Raw sockets 2.2.4 Direct tcp connections 2.3 The best method 2.3.1 User's choice 2.3.2 Learning mode 2.4 Demultiplexing 2.4.1 In Control Channel 2.4.2 In Data Channel 2.5 Multiplexing 3. CONTROL CHANNEL 4. DATA CHANNEL CONCLUSION THANKS USEFUL LINKS ================================================================================ =================== CHANGELOG AND NOTES =================== o v1.0 - March 2004 : Initial publication. You will find the current working version of this paper at http://team.gray-world.net/public. ================================================================================ ============ INTRODUCTION ============ The idea behind the reverse tunneling technique (RTT) is quite simple, but the implementation could be a bit complicated. RTT usually involves a box placed within the internal network that serves as a client for local services and a server for the outside world. Security issues emerge due to the soft core model followed in most organizations (i.e. less restrictive firewall rules and security policies for the internal network). Even in corporative networks with extensive perimeter security, unauthorized tunnels for illicit data transfers can be established via backdoors as long as some kind of internet access is permitted. Of course, RTT is also used legitimately for providing access to internally located services via such programs as CCTT, AF, OpenSSH et.al. (see USEFUL LINKS). It is also used for remote administration and by system auditors (pen-test). We will now discuss various methods of implementing reverse tunneling techniques and focus on the ways of applying them to a variety of situations. ================================================================================ ===== TERMS ===== First we define a few terms and concepts: RTT Client - connects to the RTT Server. The client waits for the server's requests and opens the connection to the Application Server, if needed. It's transferring the data between the RTT Server and the Application Server. RTT Server - waits for clients/users to connect. When a user connects to it, the RTT Server sends a request to the RTT Client. Next, the client establishes channels to the Application Server and to the RTT Server. The RTT Server then transfers data between the RTT Client and the Application Client (user). Application Server (AS) - waits for user connections and processes the requests. Application Client (AC) - connects to the Application Server and sends the requests. Control Channel (CC) - a tunnel dedicated to transferring administrative messages between the RTT Client and Server. Data Channel (DC) - a tunnel dedicated to transferring user/application data between the RTT Client and Server. ================================================================================ =============================== 1. LIMITATIONS AND REQUIREMENTS =============================== Ideally an RTT tool would create Data Channels without any delay, transfer data with maximum allowed speed and stay invisible. But in practice we can rarely achieve all the objectives and have to arrive at a functional balance. We will now take a look at the three main characteristics of the RTT: 1.1 Bandwidth ------------- "bandwidth - a data transmission rate; the maximum amount of information (bits/second) that can be transmitted along a channel" - WordNet (r) 2.0. High bandwidth is important when dealing with large amounts of data but you do not always need maximum transfer rates. For example, using shells usually does not generate big amounts of data. An RTT tool should be able to take advantage of all the bandwidth available. 1.2 Latency ----------- "latency - the time it takes a {packet} to cross a network connection, from sender to receiver." - Free On-line Dictionary of Computing. Latency is a very important parameter of a communication channel. New packets cannot be transmitted before the previous ones are acknowledged in the tcp protocol. So, high latency implies more time taken to transfer the data. Moreover, delays are especially detrimental when transmitting a large number of (small) packets. E.g. telnet/ssh sessions. This parameter becomes even more important in the context of RTT tools. Each user's packets have to go through several hosts, gaining delays in each of them. Therefore, when we want to do something using reverse shell, we have to provide a reasonable response time from every node in our chain. 1.3 Stealthiness ---------------- "stealthiness - the state, quality, or character of being stealthy; stealth." - Webster's Revised Unabridged Dictionary (1913). Stealthiness becomes important in the situation where the RTT tool has to do its job without being detected. E.g. when running without the knowledge and/or permission of the administrator. We cannot hide our tunnels completely but there are some effective methods. For example, we could craft fake HTTP messages to establish reliable tunnels through a local proxy. Moreover, we could use steganography. Stealthy channels can't use high bandwidth and low latency, the need to strike a balance between the three objectives becomes obvious. ================================================================================ ========= 2. DESIGN ========= One of the main purposes of this article is to dwell on possible implementations of the reverse tunneling technique. The design considerations are entirely dependent on the user requirements and the tools created should be able to adapt to the changes in the environment. We can achieve this by offering multiple methods, modes of operation and an ability for the user to select any of them. 2.1 Logical channels -------------------- local network |FireWall| Internet || /-------CC-------\ AS <------> RTT Client || RTT Server <------> AC \-------DC-------/ || We can differentiate between the modes of operation in RTT tools. These types of programs spend the majority of their time waiting for the users' requests. When the appropriate packet comes, the server notifies the client and a new connection is established. So we can talk about a Control Channel, which is used in the server-client communication line for administrative purposes. And the RTT tool uses a Data Channel to transfer all the information, which was requested by the user. Control and Data Channels should be implemented in different ways, because they are used for different tasks. The Control Channel should be stealth and provide reliable data communication channel establishment time. At that the Data Channel should also be able to transfer information within the highest possible bandwidth. Moreover, the user could also intentionally forget about stealthiness of his Data Channel, when he knows that his Control Channel is stealthy enough to stay covert all the time. Furthermore, even the Data Channel could be left uncovered, when the time of its existence is shorter than the administrator's reaction. 2.2 Possible methods -------------------- I will not present the implementation of each method, but only discuss their usefulness, advantages and disadvantages. If you want to know more about some of the techniques, please visit http://gray-world.net and check other papers, tools and links. 2.2.1 SMTP/IMAP/POP3 local network |FireWall| Internet || || AS SMTP/POP3 <==== Legalized Tunnel ====> SMTP/POP3 AC \ / || \ / RTT Client || RTT Server || Using mail messages to transfer additional data has several advantages. Programs don't have to initiate outgoing connections, everything is going through the legalized channels. The majority of administrators allow their users to send and receive mails, so this method would be almost always available. Moreover, we could put everything we want into the message body. We could compress the data, encode it and use steganography techniques in order to cover our actions. Also additional spam messages could be generated to cheat the tracking programs/people. On the other hand, mail tunnels have one great disadvantage: delivery time. Sometimes we can wait really long until our message is brought to the destination. Furthermore, a lot of mail will probably puzzle the administrator and uncover our tunnel. 2.2.2 HTTP/HTTPS local network |FireWall| Internet || (PROXY) || (PROXY) AS ------ Fake HTTP/HTTPS messages ------ AC \ / || \ / RTT Client || RTT Server || This is one of the most popular protocols to exploit. It's almost always legalized by network access control systems, at least through the local proxy. It gives a lot of possibilities of encoding, compressing and covering data into fake headers/bodies of the HTTP messages. Also the keep-alive method could be useful in creating long-term connections to transfer bigger amounts of data. We could also use third-party sites to cover communication. When we use this method in real environment, we could generate traffic, which could be easily detected by the administrator's tools. For example, creating reverse shell needs lot of small packets, which can be tunneled using lots of connections or one long-term connection. Both the ways could puzzle the people responsible for security. 2.2.3 Raw sockets local network |FireWall| Internet || || AS -Craft. packets-->||<--Craft. packets- AC \ / || \ / RTT Client || RTT Server || This category includes all the tunnels created by ICMP, TCP/IP flags, TCP ACK. We could build custom packets, which will be able to cheat firewalls rules and penetrate the local network. Also we could modify the legal packets so, that they will contain additional data. However, we need root privileges in order to play with these low-level protocols. This could be a great disadvantage in some cases. Furthermore, creating a covert, reverse channel using one of these exotic techniques in most cases needs a lot of effort and the result is not guaranteed. For example, almost all firewalls have the spoofing protection turned on as a default, so modifying the sender field of echo requests will be useless. 2.2.4 Direct tcp connections local network |FireWall| Internet || AS <------> RTT Client <--------------> RTT Server <------> AC || This method is a basis for all user-level protocols. If we can make a tcp connection, we can do with it almost everything. We could use protocols like irc and msn in order to covert our actions. We could also easily compress and encode our data, generate additional fake/legal packets. On the other hand - administrators are mostly concentrated on this type of connections. The majority of firewalls deny/reject connections to multiple ports, often blocking all incoming packets. 2.3 The best method ------------------- As far as I know, the best method to create a tunnel with a RTT tool does not exist. The technique used depends on various circumstances, the user's choice and NACS limitations. We have two ways of choosing a method for RTT. 2.3.1 User's choice The first one is to give all options to the user. He knows his network limitations and his requirements for the reverse tunnel. He could choose from the methods provided by the RTT tool. The choice could be made directly, by selecting the proper possibility from the list. Moreover, the user should be able to specify the characteristics of the tunnel (bandwidth, latency, stealthiness), and the program would use the method that fit these requirements. 2.3.2 Learning mode Sometimes even the user is not sure, which method will work best in his network. There could be a possibility, that we place a pen-testing RTT tool on the host without the knowledge of the owner. In such cases, the RTT tool should be able to observe the local communication environment and learn from it the traffic that is legalized and secure. This technique could be very powerful and then the traffic generated by the RTT tool is hardly detectable. 2.4 Demultiplexing ---------------- local network |FireWall| Internet || -------------CC_type1------------- / || \ AS /-------------CC_type2-------------\ AC \ / || \ / RTT Client <---------------DC---------------> RTT Server \ || / \-------------CC_type3-------------/ || Each of the possible methods of creating covert channels has its own advantages and disadvantages. We could choose the technique we want to use, or the program will do it for us. Even the best and most suitable method has one serious disadvantage: it's repeatable, so detection of this is only a matter of time. However, we could use several methods simultaneously. This would give us the possibility to improve the stealthiness of our channels. On the other hand, there would appear problems with data synchronization. 2.4.1 Control Channel Channels demultiplexing would be especially useful in Control Channels. In order to stay covered, our tunnel should change the communication method from time to time. Also some random and legalized (from the NACS point of view) packets could be generated to mislead the administrator's tools. However, demultiplexing gives us even more possibilities to avoid detection. For example, when we have two active and useable Control Channels, and one of them is going to be detected/closed by the administrator, the RTT Server and the Client could still communicate with each other through the second tunnel. This also gives us time in case of possible uncovering - time to cover up the traits or establish a new, secure Control Channel. 2.4.2 Data Channel When we use demultiplexing in the Data Channel, the situation becomes more complicated. Sending large amounts of data through two different tunnels could cause synchronization problems. For example, when we use HTTP and SMTP methods in our two tunnels, high latency of mail exchange will definitely affect the second channel. There could be a situation in a channel based on HTTP when large amounts of data are pending, because the SMTP channel is waiting for mail delivery. However, we could use several tunnels to manage the particular Data Channel. This new channels will send control messages, but only regarding one tunnel. This method could be useful, when the existing Control Channels have bad performance, and we need some additional tunnel to transfer the required management messages for proper operation of the Data Channel. 2.5 Multiplexing ---------------- local network |FireWall| Internet || AS No.1 || AC 1 \ || / RTT Client <-------Multiplexed Channel--------> RTT Server / || | \ AS No.2 || | AC 2 || \ || AC 3 || Sometimes multiple connections could puzzle the administrators. In this situation, we could consider multiplexing of the several Data/Control Channels. By doing that, we could lower the latency of the tunnels and probably decrease the amount of logs produced by the NACS tools. However, this new multiplexed channel should be more permanent in order to transfer the data from several channels. Moreover, one long-term connection with high bandwidth usage could also puzzle the administrators. So the decision of using the multiplexing method should be dependent on the user's needs and NACS policy. ================================================================================ ================== 3. CONTROL CHANNEL ================== We have different requirements for session control and data messages transmission. The Control Channel should allow us at least to notify the internally located box of the incoming connections and requests for the Data Channel creation. So it can even be an unilateral tunnel, sending packets from outside to inside only. However, there could also be more sophisticated configurations. The client box could ping the server, send information about local services and the internal state of the program. The Control Channel should be stealthy. This means that permanent sessions and generation of lots of heavy packets should be avoided. It's often asynchronous, in most cases allowing only the transfer from the outside to the inside. Because it's not common to send large amounts of data through the Control Channel, we could forget about keeping high bandwidth characteristics of this tunnel. We have to concentrate on stealthiness and latency. When we talk about being stealthy, we can't allow for long-term connections. We should send what we have quickly (or during a very long period) and using the smallest amount of packets possible. We have to choose from the available methods: - using mail exchange is very stealthy, but with high latency. This method is ideal when we don't need quick answer - http/https protocol does not have the latency problem and is also very stealthy. However, tcp connections are required to send requests to the client. When we can afford these connections - than we should choose this method. - low-level protocols are in most cases very stealthy. However, they require root privileges on client and server box. Moreover, the majority of our efforts could be squandered by firewalls and NACS. This method is often useless in real environment. - direct tcp connections do not have any disadvantages regarding latency and stealthiness. However, in most jailed corporative networks the only protocols allowed are smtp and http (often via local servers). So we do not need this technique in most cases. On the other hand - if we do not have to worry about protocols authorization - this is the best option. ================================================================================ =============== 4. DATA CHANNEL =============== The characteristics of the Data Channel differ from the ones described for the Control Channel. In the most cases high bandwidth is the most important characteristic. However, stealthiness and latency are also significant. When we talk about the Data Channel, we think about a reliable tunnel, which can transfer all the user's information between the RTT Client and the Server. We could hide the presence of this tunnel when the requirements for the bandwidth are not high, but when the user's actions lead to huge data traffic we have to choose between a long time transfer or the risk of being detected. Of course the way chosen by our program should meet the user's requirements placed earlier in the configuration file or in the command line of our tool. We have a narrower selection of methods when implementing the Data Channel. This is due to the fact that we must take all the characteristics of the tunnels into consideration. - using mail exchange is very stealthy, but has extremely high latency and low bandwidth. This method is rather unsuitable for the Data Channel. When we want to establish a reverse shell, we need low latency. And when we want to transfer large amounts of data, we need high bandwidth. - http/https protocol is one of the best choices for the Data Channel. It does not have the latency problem and could be very stealthy. The "keep-alive connections" feature gives us the opportunity to send larger portions of data. However, the traffic generated under this method could differ from the one generated by ordinary web browsers, so this could also be detected by the administrator's tools. - low-level protocols are unsuitable for the Data Channel for several reasons. Firstly, they require root privileges on the client and server box, which is a rare situation. Moreover, the tunnels created by this method are often blocked by the firewalls by default. Furthermore, the bandwidth of these channels is low, and it's mostly very hard to code reliable tunnels. - direct tcp connections are the second possibility for the Data Channel. Their characteristics are good: low latency, high bandwidth, even good stealthiness if needed. The same situation as in the Control Channel: when we do not have to worry about protocols authorization, this is the best choice. ================================================================================ ========== CONCLUSION ========== RTT tools are used in the variety of situations. They could make it almost impossible to detect reverse tunnels from the outside to the internally located boxes. This could be a serious threat to the security of the whole internal network. On the other hand, people could use RTT tools to gain access from the Internet to the computers they can not access otherwise due to the administrator's policy. One of the most important assumption of the RTT idea is the existence of two separate Channels: Control and Data. The first one is for session handling: pinging the server, transferring the information about shared services, internal states and user requests. The second channel is created subject to the user request. All the data between the applications is transferred along this tunnel. When the user quits, the channel is closed. The methods used by the RTT tools should take into consideration the environment limitations. The user should be able to choose from various techniques, which meet the specific requirements. Moreover, the appropriate method could be also selected in an automated way. The learning mode allows the RTT tool to probe for secure and legalized tunnels in the local network. In order to better fulfill the user's requirements and meet the environment restrictions, multiplexing and demultiplexing methods should be considered. They provide a way of misleading the administrator's tools and help to create truly covered tunnels. This paper is only a prelude to the future GW implementation. If you are interested in the topic and want to check RTT tools in real environment, have a look at our team website for new tools releases. ================================================================================ ====== THANKS ====== Big thanks to the GW Team: to Alex for a lot of ideas, advice, loooong mails and almost 24h support to Simon for a lot of new ideas and interesting discussion to Arun Darlie Koshy for error corrections. Thanks to Ilia Perevezentsev who read and corrected the pre-release version of the paper. And all the readers who have enough will to read up to this point. If you are interested in this topic, please send any comments and/or requests to the author's mail address. ================================================================================ ============ USEFUL LINKS ============ to RTT related tools: - Open SSH - free SSH protocol suite http://www.openssh.com/ - AF - Active Port Forwarder http://gray-world.net/pr_af.shtml - CCTT - Covert Channel Tunneling Tool http://gray-world.net/pr_cctt.shtml to Papers: - Exploitation of data streams authorized by a network access control system for arbitrary data transfers: tunneling and covert channels over the HTTP protocol; http://gray-world.net/projects/papers/covert_paper.txt - Legitimate Sites as Covert Channels http://gray-world.net/papers/lsacc.txt - Using Spam As A Vector Of Back Door Communication http://gray-world.net/papers/spamdoor.txt to On-line dictionaries: - WordNet (r) 2.0 http://www.cogsci.princeton.edu/~wn/ - Free On-line Dictionary of Computing http://wombat.doc.ic.ac.uk/foldoc/ - Webster's Revised Unabridged Dictionary (1913) http://www.websters-online-dictionary.org/