I have already discussed about Honeypots. Today we discuss the methods that can be used to detect the existence of Honeypots on the network. If a attacker is unaware about Honeypots then it can be a great problem for him/her because honeypots logs all the activities of the attacker.
So now how can we detect that whether the system with which we are interacting is a honeypot or real system ? Following are some methods to detect Honeypots.
1. Tar Pits :
A tarpit is a computer entity that will intentionally respond slowly to incoming requests. The goal is to delude clients so that unauthorized or illicit use of a fake service might be logged and slowed down. Note that some purists do not really consider a tarpit to be a honeypot, though it is certainly a fake information system resource that can delay any incoming aggressors. For example, to fight off spammers, some people run tarpits that look like open mail relays, but instead answer very slowly to SMTP commands. These are layer 7 tarpits. Other known tarpits are those that play with the TCP/IP stack in order to hold the incoming client's network socket open while forbidding any traffic over it (layer 4).
The Labrea Tarpit is an excellent example that plays with the TCP/IP stack and has been used to slow down the spread of worms over the Internet, but there are also others such as Honeyd and some native tools in Linux. For example, netfilter/iptables supports a TARPIT target. To achieve this tarpit state, iptables accepts an incoming TCP/IP connection and then immediately switches to a window size of zero. This prohibits the attacker from sending any more data. Any attempt to close the connection is ignored because no data can be sent by the attacker to the target. Therefore the connection remains active. This consumes resources on the attacker's system but not on the Linux server or the firewall running the tarpit. An example iptables rule for TARPIT mode looks like:
iptables -A INPUT -p tcp -m tcp -dport 80 -j TARPIT
Though tarpits are not built to avoid fingerprinting, this is an interesting technical case to propose for our first example.
For a layer 7 tarpit, by looking purely at the latency from the service, an attacker might guess that he/she has found a fake system after multiple attempts.
For a layer 4 tar pit like Labrea, the TCP window size is reduced to zero, and the tar pit continues to acknowledge incoming packets. This simple signature will probably alert the attacker.
For eg: You can see that an attacker (10.0.0.2) trying to reach a fake web server, simulated by Labrea in persistent mode (10.0.0.1), in the following recording made with tcpdump:
03:26:01.435072 10.0.0.2.1330 > 10.0.0.1.80: S [tcp sum ok] 911245487:911245487(0) win 64240 (DF) (ttl 64, id 6969, len 48) 03:26:01.435635 10.0.0.1.80 > 10.0.0.2.1330: S [tcp sum ok] 3255338435:3255338435(0) ack 911245488 win 3 (ttl 255, id 48138, len 40) 03:26:01.435719 10.0.0.2.1330 > 10.0.0.1.80: . [tcp sum ok] 1:1(0) ack 1 win 64320 (DF) (ttl 128, id 4970, len 40) 03:26:01.435887 10.0.0.2.1330 > 10.0.0.1.80: . [tcp sum ok] 1:4(3) ack 1 win 64320 (DF) (ttl 128, id 4971, len 43) 03:26:01.436224 10.0.0.1.80 > 10.0.0.2.1330: . [tcp sum ok] 1:1(0) ack 4 win 0 (ttl 255, id 44321, len 40) 03:26:03.731433 10.0.0.2.1330 > 10.0.0.1.80: . [tcp sum ok] 4:5(1) ack 1 win 64320 (DF) (ttl 128, id 4973, len 41) 03:26:03.731673 10.0.0.1.80 > 10.0.0.2.1330: . [tcp sum ok] 1:1(0) ack 4 win 0 (ttl 255, id 35598, len 40)
By looking at the answers from 10.0.0.1, you will at first notice a window size of 3 and then 0 for the next connection (win 0) marked in pink. You can then understand how an attacker could fingerprint this behavior easily.
2. About layer 2 :
If an attack is launched from the same LAN segment as a honeypot, there might be issues seen at layer 2. This might be important if you want to handle the inherent risks with an intruder who would otherwise succeed in gaining access deeper and deeper into your network infrastructure. It might also be important with a honeypot that would be used to catch malicious internal users.
Labrea also has the capability of answering requests sent to computers that do not exist. By looking at unanswered ARP requests, Labrea might be configured to simulate unused IP addresses, which is very interesting way to fight worms on large networks with thousands of such IP addresses. If an attacker is on the same network segment as Labrea, there is a way to do fingerprinting at layer 2: this daemon always answers with the same unique MAC address 0:0:f:ff:ff:ff, which acts as a kind of black hole, and thus there is an obvious way to detect it. By looking at such ARP responses, the attacker might have such a concern:
04:59:00.889458 arp reply 10.0.0.1 (0:0:f:ff:ff:ff) is-at 0:0:f:ff:ff:ff
If you want to explore this as an exercise, you can find and change this hard coded value in the sources of Labrea (PacketHandler.c):
u_char bogusMAC[6] = {0,0,15,255,255,255};
VMWare is a well known commercial software for virtual machines that allows you to launch multiple instances of different operating systems on a single piece of hardware. These operating systems are isolated in secure virtual machines and the VMware virtualization layer maps the physical hardware resources to the virtual machine's resources, so each virtual machine has its own CPU, memory, disks, I/O devices, etc. It only emulates x86 hardware at the moment and it is widely used by honeypot operators because it allows, among other things, an easy deployment of honeypots. Sometimes you can guess that a system is running on top of VMWare by looking at the MAC addresses. It does not mean that this is a honeypot, but this might give pause and some doubts to an aggressor. If you look at the IEEE standards, you will find this current range of MAC adresses assigned to VMWare, Inc:
00-05-69-xx-xx-xx 00-0C-29-xx-xx-xx 00-50-56-xx-xx-xx
So, if you see such a MAC address either by looking at the cached MAC addresses (via arp -a) or by looking at the data related to the interface (Unix: ifconfig or Windows: ipconfig /all), an aggressor might find something interesting.
Some attackers try to reach remote NetBIOS services in order to launch Windows specific attacks. Honeypots builders dream of catching 0-day exploits against a patched system, but using the Windows integrated firewall might stop most attackers. That's why they often open the related Windows ports (NetBIOS ports, including 135, 137-139 and 445 TCP/UDP), waiting for an intruder. But what if an attacker interacts with the NetBIOS service? He/She will be able to get the MAC address and guess that a system is in fact a VMWare guest (Unix: nmblookup or Windows: nbtstat -A @IP). Some could argue that it is possible to change the MAC address in the configuration of VMWare, but still only some addresses might be accepted: VMWare's MAC addresses are beginning with 00:50:56 (e.g. ethernet0.address = 00:50:56:XX:YY:ZZ).
There are also other points of interests for attackers that would like to fingerprint a VMWare owing to MAC addresses. For example, when the VMWare ESX server automatically generates MAC addresses like 00:05:69:XX:YY:ZZ, it usually means that the IP address of this server is like A.B.C.D where XX is the hexadecimal of C, and YY is the hexadecimal of ZZ. This might reveal the use of NAT before the VMWare box (different external address).
Honeyd is a powerful open source honeypot daemon written by Niels Provos. In the past, most people have used Honeyd with another tool, arpd. This one answered ARP requests in order to redirect needed traffic to Honeyd. Some people thought that this could create a stealth problem because there would be multiple IP address with the same MAC address (but this can also happen on a layer 2 bridge). If you use a recent version, Honeyd now allows you to specify a MAC address for each virtual computer without being limited to just one. Simply add this line for a created template, by choosing the MAC address for your simulated systems:
set template ethernet ""
This might be better than using the arpd daemon and gives a great opportunity for stealth at layer 2. Maximillian Dornseiff has also outlined some possibilities for using honeyd without arpd.
User-Mode Linux (UML), a free software under the GPL, is another tool to create virtual machines. It virtualises Linux itself so that you can run an entire Linux environment in user-space and it allows you to run multiple instances of Linux at the same time and on a single piece of hardware. Dedicated to Linux, it looks similar to the commercial solution VMware. That's why so many people use it to build honeypots. From a layer 2 point of view, there is a powerful option to fix the MAC address of the UML guests by appending some parameters while launching it:
eth0=tuntap,,xx:xx:xx:xx:xx:xx,@IP (where xx:xx:xx:xx:xx:xx is the MAC address and @IP is the IP address).
3. Sebek-based Honeypots :
Sebek is client/server based application, and it is the primary data capture tool used by honeynet researchers to capture the activities of an attacker found inside a honeypot. It is a kernel-based rootkit that hijacks the read() system call and it is therefore able to record all data accessed via read(). Sebek lives entirely in kernel-space and has access to all data read, so it is able to access most communication unencrypted. It can, for example, log SSH-sessions, recover files copied with SCP and record all passwords used by intruders. The recorded data is sent in a covert manner via UDP to the Sebek server, the other part of Sebek's client/server architecture. This transmission is done by modifying the kernel in order to hide these outgoing packets such that an intruder cannot see them. In addition, all network counters and data structures have to be adapted in order to make detecting these changes more difficult. Further information about Sebek and its architecture can be found on the Honeynet site.
It is possibile to detect the presence of Sebek by using the network layer, however. Because Sebek records everything which is accessed via read() and then sends this data over the network, some congestion effects will be visible if we read lots of data coming out of the system. When we read a single byte via a read(1) call, Sebek has to transfer nearly 100 bytes of data, including all the network headers, over the network to the host doing the logging. So if we are able to do a read(1) some tens of thousands of times per second, this will lead to a congested network and finally to dropped packets.
We are able to generate many read(1) calls with the help of the dd command:
dd if=/dev/zero of=/dev/null bs=1
And we are able to identify a congested network with the help of the ping command, as outlined below.
We first ping a local IP-address (for example, the gateway) in order to get an overview of the current congestion of the network. Then dd is started in the background and we run the ping command again. If Sebek is installed on a host, this leads to a significant increase in the average round-trip time. In practical tests, the average round-trip time grew from 0.7 milliseconds to over 4800 milliseconds.
There are also further methods to detect and circumvent the presence of Sebek if we use layers than the network layer.
4. Snort_inline :
Snort_inline is an inline packet modification engine, and it provides for packet rewriting of what looks like something dangerous into something harmless. It is basically a modified version of the popular Intrusion Detection System (IDS) Snort and adds several new rule types (drop, sdrop and reject) to tell iptables whether a packet should be dropped, rejected, modified, or allowed to pass based on a Snort rule set.
An example for this technique is the replacement of the string /bin/sh in shellcode with the string /ben/sh. Another example is the replacement of certain characteristic patterns in network traffic in order to render these attacks useless, as shown in the following listing which modifies x86-shellcode:
alert ip $HONEYNET any -> $EXTERNAL_NET any (msg:"SHELLCODE x86 stealth NOOP"; sid:651; content:"|EB 02 EB 02 EB 02|"; replace:"|24 00 99 DE 6C 3E|";)
This kind of Intrusion Prevention System (IPS) is used in GenII (2nd generation) Honeynets in order to identify and block known attacks. Snort_inline is also necessary because it hampers the possibility of an attacker bouncing from a compromised honeypot to attack further systems. So Snort_inline also adds some safety from a legal point of view.
But the dropping or modification of outgoing packets leads to an easy way for attackers to spot the presence of Snort_inline: If outgoing packets are dropped, that might look suspicious for an attacker, like a kind of black hole. If outgoing packets are modified, this will be detected by an sophisticated attacker. He/She will send packets with malicious content to another host which he/she controls and check whether the packet arrives at the destination in unaltered form (albeit with some small things changed, like a decremented Time To Live). If the content of the packet differs, he/she will probably conclude that this is a bit fishy. The stealthiness of Snort_inline can be increased with fewer rules, but this leads to more attacks that will not be noticed. A trade-off between stealthiness and safety has to be found.
Moreover, GenII Linux Honeynets typically use the netfilter/iptables-functionality of the kernel to implement connection limiting. This prevents the abuse of a compromised honeypot for denial-of-service attacks or mass scanning and nevertheless allows an attacker to download toolkits or setup automated bots. As an example, the default configuration of the rc.firewall script provided by the Honeynet Project allows 15 outgoing TCP-connections and 50 outgoing ICMP packets per day.
[...] ### Set the connection outbound limits for different protocols. SCALE="day" TCPRATE="15" UDPRATE="20" ICMPRATE="50" OTHERRATE="15" [...]
This connection limiting also leads to a problem with the secrecy of a honeypot: an aggressor can simply try to open many outgoing connections to different hosts or send a lot of ICMP echo request packets to varying hosts. If he/she notices that after some time no more outgoing packets can reach the target, then this is a clear sign that something weird is going on and that he/she probably fell for a honeypot. Again, a trade-off between stealthiness and safety has to be found. If you allow more outgoing packets, the detection will be harder, but an attacker has more ways to abuse the honeypot.
5. Fake AP(Access Point) :
Fake Access Point is a Perl-script that generates bogus 802.11b beacon frames with random ESSID and BSSID (MAC-address) assignments. It sends these frames on a random channel and is also able to simulate the wired equivalent privacy (WEP) protocol. A normal access point will "hide in sight amongst Fake AP's cacophony of beacon frames" and therefore this kind of tool can also be used as a wireless honeypot: just deploy one Linux machine running Fake AP near your wireless network and watch for any suspicious traffic. Legitimate users will know the SSID of the network and can connect without problems. Malicious users will try to connect to your network with different SSIDs and can thus be spotted easily.
In its current version, Fake AP does not generate fake traffic on one of the simulated access points and hence there is an easy way to detect the presence of Fake AP: This tool only sends beacon frames and also does not send any real traffic. So an attacker can just monitor the network traffic and easily notice the presence of Fake AP.
6. Bait and Switch Honeypots :
Traditionally, information security follows the classical security paradigm of "Protect, Detect and React". In other words, try to protect the network as best as possible (such as by using firewalls), detect any failures in the defense (with intrusion detection systems), and then react to those failures (perhaps by alerting the admin via mail). The problem with this approach is that the attacker has the initiative, and he/she is always one step ahead. The Bait and Switch Honeypot is an attempt to turn honeypots into active participants in system defense. It helps to react faster on threats. To archieve this goal, the Bait and Switch Honeypot redirects all malicious network traffic to a honeypot after a hostile intrusion attempt has been observed. This honeypot is partially mirroring the production system and therefore the attacker is unknowingly attacking a trap instead of real data. Thus the legitimate users can still access all data and work on the real systems, but the attacker is lured away from all interesting systems. As an additional benefit, the actions of the aggressor can be observed and then his tools, tactics and motives can be studied. A Bait and Switch Honeypot is based on Snort, iproute2, netfilter/iptables and some custom code.
An attacker might detect the presence of a Bait and Switch Honeypot by looking at specific TCP/IP values like the Round-Trip Time (RTT), the Time To Live (TTL), the TCP timestamp, and others. After a switch event, the attacker will stop talking to the real computer, and will start to interact with the honeypots. During the switch from the real system to the honeypot, a sudden change in the IPID can be observed. Previous TCP/IP values will also probably change after the switching has taken place and this can be observed by a sophisticated attacker.
Once again, tcpdump is valuable tool for attackers to gather information about what is going on. Furthermore, the honeypot will probably differ noticeably from the real system. The attacker will presumably try to find a way to identify the honeypot by looking at specific differences that might exist between the real system and the honeypot. Notice that some attackers will use multiple IP addresses as sources of their attacks, in order to defeat such kinds of IPS. For example, if the shellcode of the attacker is a reverse shell that connects back to an IP source which is different from the IP that sent the exploit, the IPS will not be able to change anything. The modus operandi will differ with every deployment of a Bait and Switch Honeypot, and so the operator of this kind of honeypot has to take great care in the setup process.
There are commercial tool for detecting honeypots like Honeypot Hunter. For more about Honeypot Hunter go here:
www.send-safe.com/honeypot-hunter.html
No comments:
Post a Comment