Re: Trapping attackers when trying to leave a honeypot

[George Washington Dunlap III <dunlapg () umich edu>]

I had done some thinking on this kind of thing before as well, but it
always seemed to me that a clever attacker could detect this kind of thing
very easily -- easily enough to put it in a rootkit script, even.  The
basic idea is similar to cross-examination: make a couple of requests from
the new victim (your honeypot), and the same set of requests from an old
victim; if they differ, they know at least one is lying (probably the new
one).  They could:
  * Try to open a connection to a backdoor on a previously-hacked system
  * Try to make a connection (or send an attempted exploit) to an IP 
address they know doesn't exist
  * Scan a couple of random IP addresses, in both places and compare the 
results.

The only way I could think of to reliably pass the 'cross-examination' was 
to actually send the packets and record the responses; but then you're in 
at least the same situation legally, perhaps worse, because it was *your* 
program that actually sent the damaging packets.

My conclusion was always that this might be marginally more effective at 
catching script kiddies, but easily dealt with by any competent black-hat.  
But as far as I can tell, catching script kiddies isn't that hard; and the 
fact that this test could be put into a rootkit and run automatically 
makes me thing that if it gets popular use it will quickly become a 
giant red "You are in a honeypot" sign, rather than a containment tool.

But I never tried it.  Any other ideas?

 -George Dunlap

On Thu, 4 Sep 2003, Nicolas STAMPF wrote:

> Hello all,
>
> I'm new to the list but have been interested in honeypots since quite some time 
> without the opportunity to install one myself. I've been reading the list 
> through a RSS feed since a few days and would like to expose an idea I had for 
> thoughts sharing.
>
> One of the problem of honeypots is, of course, the risk of an attacker to own 
> the box and use it as a bounce platform for attacking other places.
>
> Couldn't it be possible to catch the attacker in virtual hosts when he tries to 
> get out of the box? 
>
> What I have in mind is a sort of modified version of honeyd (let's call it m-
> honeyd) that only listens to outgoing requests from the honeypot. When one is 
> intercepted, the m-honeyd dynamically creates a new virtual host and activates 
> the service the attacker wanted to connect to. Of course, some issues arise:
> -about scans to your own network: a functionality such as LaBrea's where all 
> available IPs are taken by default could be useful. With such a situation, it 
> could be easy to trap the attacker: impossible to get out on neighboor 
> computers.
> -about scans to other networks. This is more difficult to handle, but we could 
> for instance make a further distinction between connected (TCP) and not-
> connected (UDP) connections. UDP probes could be searched for attack signatures 
> with some kind of snort-like tool and droped just like what an IPS could do. 
> packets for which we don't have a signature could be sent to a fake UDP daemon 
> that records everything (again, two solutions: no response or fake real UDP 
> server). TCP probles are, well, harder to handle. See below.
>
> About outgoing TCP connections, I'd say that on a properly configured site, the 
> firewall should be filtering ingoing and outgoing connections, so if I were an 
> attacker, I wouldn't be surprised to be blocked when trying to go back on 
> Internet. If I really needed to, I'd try to find a machine in the same DMZ 
> (cause I would logically be in a DMZ, right?) with outgoing Internet 
> connectivity, such as SMTP server, secondary DNS downloading zone from Internet 
> provider primary server, etc.
>
> That's when the trapping of outoing connections to IPs belonging to your own 
> domain seems interesting to me. By simulating a subset of the commands an 
> attacker would use to get out of the place, we could further trap his activity 
> using m-honeyd fake servers. We could even virtually replicate the real 
> architecture, with the real firewall rules to increase the verisimilitude.
>
> Let me give an example to clarify things.
>
> Let's consider an internet connection arriving on a router connected to a 
> firewall. This firewall has 3 interfaces: outside (to previous internet 
> router), inside (to internal router) and DMZ. In the DMZ are 5 machines: web 
> server, application server, SMTP server, DNS server and honeypot as a 
> vulnerable webserver.
>
> If an attacker enters the honeypot and tries to scan/connect to IPs from there, 
> he would see on the same LAN: an SMTP server, a DNS server, web and application 
> servers, all with the proper ports opened. Of course, would he try to connect 
> to these IP, the packets would get intercepted and redirected to the m-honeyd 
> for handling. He would also see another IP (the firewall's). On the firewall, 
> he could discover that by spoofing the appserver's IP (should not be too 
> difficult to guess for a real attacker), he could pass through to a database 
> server (ODBC port open, SQL*net, etc.). All of these would really exist, except 
> that from the honeypot they would be intercepted and sent to virtual addresses 
> on the same honeypot. Some kind of kernel interception for instance.
>
> I welcome your comments and criticisms.
>
> Nicolas Stampf

-- 
+-------------------+----------------------------------------
| dunlapg () umich edu | http://www-personal.umich.edu/~dunlapg 
+-------------------+----------------------------------------
| ...there be many, many ancient systems in the world, and it 
| is the decree of the dreaded god Murphy that thy next 
| employment just might be on one.  While thou sleepest, he 
| plotteth against thee.  Awake and take care.
|   - Henry Spencer, "The Ten Commandments for C Programmers"
+------------------------------------------------------------
| Outlaw Junk Email! Support HR 1748 (www.cauce.org)