This paper is written for those paranoid administrators who are looking for a stealthy technique of managing sensitive servers (like your enterprise firewall console or IDS).
Such techniques can be accomplished at different levels:
- Network Layer: NIC still sees the packets but they are filtered by the kernel,
- Physical Layer: NIC does not see any packets at all since there is no physical connection to it.
This is controlled by another attached device called "Air Gap" which allows specific traffic to pass through, providing a true stealthness. I assume that most of you are not going to use the latter method yet, so I will focus on the first one.
A Bit Of Introduction
By following very simple steps, you will be able to remotely access hosts with a "DENY ALL" firewall policy set or even hosts without an IP address assigned. This technique is based on a tool called SAdoor (http://cmn.listprojects.darklab.org) which is available for Linux , BSD and SunOS.
This tool is comprised of two components: SAdoor: a daemon program which listens on an NIC for a set of pre-defined packets. Sash: a client program used to craft these special packets and send them to SAdoor host. Although in certain configuration, it is be possible to use ordinary tools like ping, telnet or netcat to generate such desired packets instead of relying on Sash. Seems interesting enough? Nows lets get into details of how to put things together.
The Server Side
SAdoor itself is a non-listening daemon, thus requires no listening port. It grabs packets directly from NIC and watches for special key and command packets then executes a pre-defined command (ie: /bin/sh). All command packets are encrypted using a conventional symmetric cipher namely Blowfish. It also has a replay attack protection and other cryptographic features. For more detailed information, please read the documentation at: (http://cmn.listprojects.darklab.org/doc/sadoor.ps) SAdoor has three configuration files as follows:
sadoor.conf:
|
# This file is the main configuration file where you can # turn on/off many options of SAdoor. # However, the main purpose of this paper is a stealthy # remote administration, so we will # need to have a certain configuration. The NULL command # on the last line is a command # to be executed after SAdoor has validated all key packets, # will enable us to achieve the # desired goal. ListengIface eth0 IPv4address 10.0.0.1 PrivateLogVerboseLevel 4 SyslogVerboseLevel 3 RunPromisc no PacketsTimeoutSec 20 EnableReplayProtection yes NULLCommand /etc/sadoor/ncmd.sh |
Then, you will have to generate a seed from any random pool on your system. This seed will be used by SAdoor to generate a 448-bit Blowfish key for symmetrically encrypted client/server communications. Most *NIX already have a random device which gathers these entropy sources and can give an acceptable level of pseudo-randomness. For instance, on Linux you could do:
| dd if=/dev/random of=/etc/sadoor/sadoor.key bs=56 count=1 |
Then it's time to define a set of those special packets we've talked about earlier.
sadoor.pkts:
|
# There are two types of packets that will be marked by SAdoor: # Key Packets and Command Packets. # A minimum set of packets required by SAdoor is at least one # key-packet and exactly one command-packet. To allow the use of # ordinary tools, we must use a normal packet structure and # certain settings as depicted below. Currently, SAdoor # supports IPv4 , TCP, # UDP and ICMP (type 0 and 8 only) # protocols and their associated # settings (TTL, DPORT, # SPORT, etc). For more options, # read SAdoor manual pages. # For the sake of simplicity, we will use a set of simple # packets that can be easily generated by ping and telnet # commands. In practice, you should increase the level of # complexity of packets. However, the more uncommon your # packets are the more chance that someone will notice them. # Therefore, it is advised that you try to mimic the real # traffic.
keypkt
{
ip {
daddr 10.0.0.1;
icmp {
type = 8;
seq 27;
}
}
}
keypkt
{
ip {
daddr 10.0.0.1;
icmp {
type = 8;
seq 3;
}
}
}
cmdpkt
{
ip {
daddr = 10.0.0.1;
tcp {
dport 6666;
}
}
} |
Using the above set of pre-defined packets, SAdoor will first mark any ICMP echo-type 8 (echo request) with icmp sequence = 27, then wait for any occurrence of ICMP echo-type 8 with icmp sequence = 3. Upon completion of two key-packets, SAdoor will now look for a valid command-packet which in this case is specified as ^\any TCP packet with destination host 10.0.0.1 and destination port 6666^]. If a ll these packets are seen by NIC on SAdoor host in the right order within a given timeframe (in this case, it is set to 20 seconds) then it will execute a script /etc/sadoor/ncmd.sh which may contain the following entries:
ncmd.sh
|
# The command below will allow a *temporary access to a # running SSH daemon from any ip addresses. Assume that # you have initially have "DROP ALL" policy set /sbin/iptables -I INPUT -dport -p 22 -j ACCEPT # To make your SADoor host even more stealthy, you could # have its IP address unassigned (ifconfig eth0 0.0.0.0) # and use SAdoor to reassign it. For this technique to work, # you must statically map the ip address of your SAdoor host # and its corresponding MAC address on a # switch or on a # connecting host (if they are on the same segment) /sbin/ifconfig eth0 10.0.0.1 |
The Client (hopefully you)
- Assume SAdoor is running SSH daemon and listens on port 22, and this host has a "DROP ALL" policy enabled
[root@0x90 /]# telnet 10.0.0.1 22 Trying 10.0.0.1...
- Provided that you know SAdoor host MAC address set a static ARP entry of your SAdoor host. Simply skip this step if you are on a different segment.
[root@0x90 /]# arp -s 10.0.0.1 00:50:BA:BA:37:EB
- Now let's trigger the first key packet using a ping command with ICMP sequence of 27
[root@0x90 /]# ping 10.0.0.1 -c 27 PING 203.155.33.1 (203.155.33.1) 56(84) bytes of data.
Then, the second key packet now with ICMP sequence of 3 and the final command packet:
[root@0x90 /]# ping 10.0.0.1 -c 3 PING 203.155.33.1 (10.0.0.1) 56(84) bytes of data. [root@0x90 /]# telnet 10.0.0.1 6666 Trying 10.0.0.1...
Obviously, there is no response from the target host. Don't worry, we just need the NIC to see these packets and have them marked by SAdoor. You can check if everything works out by looking at sadoor .log on SAdoor host
sadoor.log:
|
Received key packet 1 Received key packet 2 Received valid command packet (command length: 0 bytes) Running default command "/etc/sadoor/ncmd.sh" |
Viola! , You now have successfully executed ncmd.sh script which contain something like:
/sbin/iptables -I INPUT -p tcp -dport 22 -j ACCEPT
or
ifconfig eth0 10.0.0.1 |
This means that SSH service is now accessible. Now try to connect to SSH port 22 again:
[root@0x90 /]# telnet 10.0.0.1 22 Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_3.5p1 |
Please remember that when you are done with your job , bring your SAdoor system back to a stealthy state again (iptables -F && iptables -I INPUT -j DROP or ifconfig eth0 0.0.0.0 arp)
Note that: Make sure your key-packets are indistinguishable from "real" traffic. Although, this is more like a security through obscurity because anyone could figure out your key-packets and replay them. The impact of this attack is not that high since it will only bring the interface up temporarily. So, it works at an acceptable level for us.
More Advanced Stuff
As I have mentioned earlier, SAdoor can watch for certain packets on a promiscuous mode NIC, So it is possible that those key and command packets be directed to other hosts on the same segment where SAdoor can see the them. This will make your SAdoor host completely blind from the network and nearly impossible for anyone to detect. Note that the key and command packets used in this paper are considered simple. You may need to play around with TTL values , IPID , ACK number or even use the application-specific data like (GET /index.html HTTP/1.0) to trigger the command. To achieve higher security, you should always use a Sash client to connect to SAdoor daemon as it provides encrypted and replay-protected communications. Though, you will have to be able to access some data like sash.db, which in some cases you don't.
Another thing is that, SAdoor daemon is also available as a kernel module to make the daemon process hidden from users. (currently *BSD). If possible, you could even make it unkillable or unloadable through the use of additional kernel ACL depending on your OS.
Having said all these, I hope you find this paper useful in some ways.
Nawapong Nakjang has been working in the areas of information security, network security and cryptography for several years. His interests include intrusion detection, honeypots, incident investigation, malicious code analysis, computer forensics and penetration testing. Occasionally, he writes security-related articles.. He plans to pursue his second degree in Information Security and publishes more papers to the security community.
|
|
Only registered users can write comments.
Please login or register.
Powered by AkoComment!