Root Entropy

Just a quick post to mention I've created a site to document (very lightly) some of my MSc research, its available at arf.rootentropy.co.za. The code for the AR-Framework will only released once I've submitted my thesis and changed the comments to be suitable for PG13.

So in my previous post I mentioned how one of my Dionaea honeypots was giving me trouble, the host it was running on was sitting at 20/20Gb used. Before that happened Dionaea was running fine. Anyway I finally had a chance to look at it today and found the problem, well not exactly but I used the lazy mans fix. Just posting it here in case someone else has to go through the same kak.

The Dionaea nfq module was failing hard, this is odd because by default it is not enabled (and I was running default settings). Taken from the official Dionaea site:

nfq can intercept incoming tcp connections during the tcp handshake giving your honeypot the possibility to provide service on ports which are not served by default.

It essentially replays whatever attack is coming in to the source in an attempt to keep the connection open and learn more, even from protocols and services it has no idea how to talk to.

Check diskspace with:

df -Th

in an actual directory you can use:

du -h

So my dionaea.log was just below 20Gb's in size (the log is normally located in /var/dionaea/logs/dionaea.log)

Inspecting the log I found that dionaea managed to work itself into a endless debugging loop while trying to do something with the nfq module, I don’t know why, I don’t even have it enabled. This was taking up all the space:

...

nfq_io_cb loop 0xaa5140 w 0x51d0dc revents 1

nfq_io_cb loop 0xaa5140 w 0x51d0dc revents 1

nfq_io_cb loop 0xaa5140 w 0x51d0dc revents 1

...

To lazy way to fix this is to just turn off debug logging in the "dionaea.conf" file, I believe this is found in:

/etc/dionaea/dionaea.conf

One of the first entries in the config file is logging, by default its set to log "all" just change that to something like "critical" or whatever level of logging is sufficient for you.

Why is there never enough time? I'm actually wondering if its possible to train oneself to type with 1 hand and then work across two PC's at the same time? I think my brain would melt. So with time being a sincere douche bag, I thought I'd make a post on what I've been busy with the last few months.

Besides paper season now officially concluded (I did not make it to the nac of sac that smelled of poo). I did managed to get 3 papers submitted, all to ISSA. One in the main, another in the Information Warfare stream and a third in the Forensics in the Cloud stream. Big thanks to Mr @kamp_staaldraad as we co-authored all of them. I'll edit this post with links to the papers once they are up on the ISSA site.

I've also managed to finish my AR-Framework, which I use in my research to automate the reconnaissance of malicious hosts on the intertubes. It does a lot, from session handling for various data sources to live fingerprinting. I do however believe that the AR-Framework deserves a separate blog post with lots of juicy details.

Speaking about data sources, I've written a little python script called hpclient.py which checks a dionaea (honeypot) database for new connections, creates a JSON encoded object and sends the data along (rather merely) to a RabbitMQ message broker. Its a neat way to get near real-time access to data on your honeypots. Not as neat as writing a custom ihandler, but, by god man! there is no time! This to will get a separate post (coupled with ntclient.py which is similar but slightly more heavy script for use with network telescopes)

I've also managed to get a dionaea honeypot up and running on the amazon EC2 cloud using their Free tier, thank you to Andrew for his quick and simple guide. My RabbitMQ broker has in the meantime decided that it does not like my EC2 honeypot and the reverse SSH tunnel I used to get AMQP traffic flowing, which made me sad. Hopefully I can figure it out soon.

In addition to the EC2 honeypot, a local (South African) VPS service has agreed to give me a free vps for September to run another HP. I got that up/running/sending data in 30mins and then another problem arose, disk quota exceeded warnings. Not sure how the hell I'm using 20/20gb but hopefully will get that sorted soon. The company also deserves a big thank you by name, but that will have to wait until my honeypot is no longer running. I don’t want you dirty internet folk messing with it.

Righto, so the other day I obliterated my postgre install, don't ask me why or how. It suffice to say it was gone. Add to the fact that metasploit has deprecated the db_driver command, only supporting postgre now, so the sqlite3 instance I had is no more. Oh and if at any point during this post you sit there thing, what the fuck is he on about, I'm writing it as I understand, which might not be correct.

Anyway, I installed postgress and setup a new user. I have constant issues with my Internet connection between home and campus (both going through the university connection, only one requires proxy auth). apt-get was failing and I hate constantly changing settings so I just downloaded and compiled from source.

wget <postgres URL> tar -xvf postgres-version && cd postgres-version ./configure make make install

Made a postgres user for metasploit, created a database and granted permissions to the metasploit user.

sudo -u postgres psql postgres-# create user msfuser with password 'somepassword'; postgres-# create database msfdb; postgres=# grant all privileges on database msfdb to msfuser;

I then fired up metasploit, connected to the db and thought everything was fine, but everytime I restarted my msfconsole session it would forget my db settings. mep.

Anyway, so did some digging in /opt/metasploit-X.X.X/config/

While working on my paper (Remote Fingerprinting and Multisensor Data Fusion) for a certain security conference that for the moment shall not be named,  I was distracted by the lack of security on their paper submission service.

After a tweet or two @RC1140 pointed me to the latest Phrack issue and the captcha owning therein. His efforts at inspiring evil overcame my weak will power towards all forms of malice and I decided that I will in addition to my initial paper, submit a WIP paper entitled How to 0wn conference proceedings and see how it goes. I hope there is enough time to complete it, but judging from past experience and sequential confirmation numbers(subtract number of papers published each year) on the afore mentioned paper submission service I'm pretty sure there will be another extension.

The paper outline and main ideas to follow, for you to see and here to live in-case it gets bounced from the actual proceedings.

No registration required!

Firstly to submit an abstract and paper, you are not required to register and confirm an account through email verification (as one would expect, *Cought* security conference? *Cought*). I have not even looked at their validation of MIME types and for the sake of my arguments this actually falls out of scope, but I'm sure someone can have some fun testing it.

So we are able to submit abstracts and papers without registration or a valid email, check.

Lack of Captcha!

Woe is me, nothing standing in the way of a simple script to generate and submit as many paper submissions as a while True loop and a cheap VPS's bandwidth will allow. Beautiful soup and Selenium come to mind, but I wont be surprised if generating an HTML page locally and submitting it also works.

So we are able to submit custom abstracts and perhaps upload papers without any validation that we are human and not a script, check.

Malice a minute!

So you might find yourself asking, "What fine evil can we get up to on this fine evening?" Well this is why a special spot in a hot place will be reserved for me one day, for now lets just let the creative juices flow.

Firstly submitting thousands of papers from spoofed email addresses could cause conference organisers a serious headache, obfuscating legitimate submissions by burying them between fake submissions. Sure with some database foo they might be able to delete the fake submissions because they look the same, so lets address this issue.

Create another script to spider google scholar, citeseer or any other archive of papers, grab their abstracts and submit them. Now you have legitimate (if plagiarised) abstracts being submitted, much harder to detect and sort through.

I mentioned spoofing the email addresses, lets take that a step further, create another script to spider the Conference website (perhaps more specifically the past papers section), download the PDF's and extract all the previous authors email addresses, now you have a nice long list of email addresses to really annoy the organisers and make your fake submissions look even more legit. It goes without saying that you can scrape the email addresses of other authors from citeseer, ect.

Other evil considerations!

Since the Conference in question so graciously sends you (or some other unfortunate soul) an email containing contents of the submission you made, how about using it to spam the masses with your own personal message, packed away in their email template. Perhaps using HTML to obscure some details?

Be naughty and re-use some work, as an added idea to thicken the plot of legitimate looking papers and fuel the ever increasing and annoying pattern of authors re-using their work, lets use a new script... The idea here is to scrape the Conference site for past papers, parse the paper and submit the contents to google translate, translate to language A (lets say German), then translate that to language B (Say Russia) and then finally (unless you want more repetitions) back to English. In so doing you should now have the same paper, but slightly reworded and ready for fresh publishing *ick*.

Recently @barryirwin asked myself and @kamp_staaldraad to give a lecture on metasploit. The audience would be the 4th compsci students who selected to do the 5 week information security module. The lecture would be on the second last day of the course so they already had a feel for info sec, but had no actual hands on experience.

So with that in mind I set out to find some content and ideas for a introductory lecture on metasploit (a 2 hour slot was given to us).

The slides can be found here.

The Content:

I started off by introducing them to the structure of penetration testing, the different kinds web/infrastructure and some of the tools they might encounter (along with a nmap primer).  I then gave them a basic overview of what metasploit is and the various was you can interact with it (msfconsole, msfcli and armatage).

We then jumped into the metasploit database and how to use it, after which I went over the basic commands in msfconsole (use, set, search, back, show) and the directory structure. That covered the really basic and boring but necessary introduction, now it was time to move on to some demos (content still in the slides for later reference).

I showed them how to use msfconsole to bruteforce a mysql server, I started by showing them how to use nmap to find a server and then using auxiliary/scanner/mysql/mysql_login to bruteforce with a custom dictionary.

Next I gave them a quick primer on bind shells, reverse shells and meterpreter. After this was done I jumped into the hello world demo of metasploit => ms08-067. I showed them how to use the nmap scripting engine to check for smb vulns and then finally how to exploit one with metasploit. After the exploit I showed them how to use meterpreter and some of the common commands. I migrated from one process to another to show how you could move to a safer more permanent process and illustrate meterpreters new way of privilege escalation.

After the demo I went into msfpayload and showed them how to use it, I then went into msfencode and talked about why you would want to use an encoder and how to test your payloads with virus vault. The final topic I spoke about was using a custom executable templates and packers to further obfuscate a payload.

The Practical:

This is a repost of what I sent to to the kippo users group on google.

I’m sure some of you have heard of LaBrea the ‘sticky’ honeypot that created a tarpit to throttle certain tcp based worms and in some cases stop them completely. Well, I thought the notion of using a honeypot for something other than information gathering and analysis was quite interesting. I think my discovery of LaBrea might have been the first steps towards realising an offensive honeypot and now I would like to take things further.

The first time I used a honeypot in an offensive manner was last year (2011) when I combined Dionaea and ettercap to create a service that would detect worm propagating on your local network and isolate/quarantine that host using ARP poisoning. This approach has its limitations but from an academic point of view I thought it was pretty neat, it’s a new way to use honeypots, it might not be the most efficient but it opens up new avenues of research and different ways of solving a problem.

I would now like to propose to you my current project, the offensive honeypot (still lacking a name at this point). I present this hoping to start a discussion; I would appreciate your thoughts on the topic, suggestions, concerns, requests and tips.

The basic idea here is to have an offensive honeypot that is used for username/password dictionary collection and striking back at the attacking hosts. I’m going to break the rest of this post into 4 sections to illustrate the functionality of this honeypot.

Services/Protocols

Initially it will only support ssh, this is just for me to get a feel for how it’s going to work and to sort out logic issues. Then later on I would like to add support for as many services as possible, if it is getting brute forced out there, it should be emulated by this honeypot. The honeypot will be written in python, I am currently busy with the ssh side of things and using twisted.conch. Further services emulation I would like to support include; ftp, mysql, mssql, postgres, vnc, rdp (what else can you think off?).

Dictionary Collection

This is a very important aspect of the honeypot, I would like to collect the actual dictionaries used by attackers and record the popularity/frequency of the use of these dictionaries according to the service being attacked. The honeypot will include logic to check once a new attack session has started, if the first username/password(u/p) matches any previously seen starting u/p combinations.

If there was a match it keeps a record of the u/p’s coming in (as associated with that dictionary) and if they all match the previously seen dictionary then increment the frequency of that dictionary for whichever service was being attacked. If the first u/p combination or subsequent ones don’t match a previously seen dictionary a new dictionary entry is made. There is a bit more to the logic, but this should give you an idea of what I’m after.

Strike Back

This is the actual offensive part of the honeypot, it replays the u/p combination the attacking host used back to that host. There are a couple of reasons for this, firstly from ethical standpoint the honeypot is not actively going out and attacking hosts on the internet, it is merely using a form of offensive self-defence replaying the attack it received to the host who sent it (I consider this reasonable and acceptable force) in reference to laws regarding self-defence in the physical world.

Secondly, this replay attack has a very high probability of working as the host that is attacking you has most likely been a victim to that same attack. Meaning the attacker is simply using a host they have already compromised to pivot attacks from.

Once a legitimate username and password combination has been found it is left to the discretion of the honeypot owner to what they would like to do, by default the honeypot will not store this u/p. The offensive honeypot could however be configured to do so and execute commands on the remote host if so desired.

Something that might be useful is to view currently logged in users, bash history, uptime and the IP address the last ssh connection came from. Once again, the responsibility of ethical and legal behaviour falls on the owner of the honeypot here. Guns don’t kill people, people kill people.

Informant Functionality

With this functionality the honeypot may be configured as a semi-automated warning system to inform compromised hosts of their current state. Using whois information or crawling a webpage for mailto tags to retrieve contact information and then compiling an email that would only require the honeypot owner to verify the details and then send.

I'm throwing this bit of code out there, just to show how easy it can be to write nifty little scripts in python. Use this script for detecting the SQL slammer worm(or rather the exploit it uses). The SQLSlammer worm is a really neat little creature (if rather archaic). By neat and little, I mean all contained in a single UDP packet and able to make a MSsql server cry.

I had a look at the payload contained in the UDP packet and illustrate how to detect if the buffer overflow exploit for a vulnerable MSsql server is present.

And now I present to you the crude but effective python script I wrote to inspect traffic on a interface and alert you once a MSsql server buffer overflow exploit (the one used by Slammer) has been detected.

Edit: Added short guide from Ryan Dewhurst (@ethicalhack3r) on how to get it running on Ubuntu [see bottom of post].

MS11-083 has arrived and people are getting both excited and scared, it looks like its going to be the next MS08-067. Which if you remember, Conficker used to bend windows over and have a jol. Time for a honeypot?

Disclaimer: This script is not intended to be a complete, efficient or stable. It’s just quick and dirty.

In anycase I took a moment and decided to write a script that would capture potential MS11-083 traffic in an attempt to capture this exploit in the wild (once its out there, might as well start looking). According to the security bulletin "The vulnerability could allow remote code execution if an attacker sends a continuous flow of specially crafted UDP packets to a closed port on a target system". So that's exactly what I looked at, I used netstat -un and -lun to find all open and listening ports and filtered them out. UDP packets to a closed port normally results in a ICMP Port Unreachable response or no response at all, so I've ignored them.

The code is commented and you need the little bash script in the same folder to get the ports. Remember to make it executable (sudo chmod +x getports.sh) and run ms11-083_sniffer.py as root. It will create a pcap file named the <current datetime.pcap> and any UDP traffic heading towards a closed port will be logged.

Once you have some pcaps and you think they might contain exploit traffic remember that sharing is caring and karma is a bitch, don't share if it was just Chuck Testa. My code is dirty and I wrote it quickly so don't hate, feel free to modify and make it better (in fact, you probably should).

I'll try and add my nmap enumeration script tomorrow, it does a portscan and OS fingerprint on a given host and inserts that data into a sqlitedb. That way you can check if the traffic was coming from a windows host.

ms11-083_sniffer.py

getports.sh

With the bash script, just remove the .txt file extension (my hosting is being annoying). Below is the code if you want to have a peek.

    from pcapy import * from impacket import ImpactDecoder, ImpactPacket from socket import * import fcntl import struct import os import time class Sniffer: def __init__(self): self.promiscuous = True self.called = 0 #silly habits self.interface = 'eth0' self.max_bytes = 65535 # Theoretical max size for a UDP packet self.read_timeout = 100 self.ip = self.get_ip_address(self.interface) self.bpf = 'ip dst host %s and not src net 192.168.1.0/30'%self.ip print "\n---------------------------------------------------" print "Sniffing for unsolicited UDP packets to closed ports." print " \"Open ports are for losers\" - MS11-083" print "Pcap log started, listening from %s"%time.strftime("%d:%m:%Y %H:%M:%S", time.localtime()) print "---------------------------------------------------" def get_ip_address(self, ifname): s = socket(AF_INET, SOCK_STREAM) return inet_ntoa(fcntl.ioctl(s.fileno(), 0x8915, struct.pack('256s', ifname[:15]))[20:24]) def start(self): self.reader = open_live(self.interface, self.max_bytes, self.promiscuous, self.read_timeout) # Pcapy uses BPF to filter packets, not src net 192.168.1.0/30 # should be changed, it just filters out 1.0, 1.1, 1.2 and 1.3 # which I use for diffrent gateways and dont want traffic # from the router hitting the logs. self.reader.setfilter(self.bpf) # Run the packet capture loop self.reader.loop(0, self.callback) def callonce(self): self.dumper = self.reader.dump_open(time.strftime("%d-%m-%Y_%H-%M-%S.pcap", time.localtime())) self.called = 1 def callback(self, hdr, data): # Parse the Ethernet packet decoder = ImpactDecoder.EthDecoder() ether = decoder.decode(data) # Parse the IP packet inside the Ethernet packet, typep iphdr = ether.child() udphdr = iphdr.child() # First check that the packets are not comming from the local host # Then check that it is a UDP packet (incase you changed the BPF) also # Check that the destination port for the packet is a closed port on the host if (iphdr.get_ip_src() != self.ip): self.refresh_portlist() if (iphdr.get_ip_p() == ImpactPacket.UDP.protocol and udphdr.get_uh_dport() not in self.portlist): if self.called == 0: self.callonce() print "Incoming UDP packet from %s"%iphdr.get_ip_src() self.dumper.dump(hdr, data) def refresh_portlist(self): # bash script to get all the open and listening UDP ports # used in the callback function as criteria for logging traffic output = os.popen("./getports.sh") pl = output.readlines() self.portlist = [] for p in pl: self.portlist.append(int(p)) def main(): snf = Sniffer() snf.start() if __name__ == "__main__": main()

Getting it up and running:

If anyone is stuck getting this working on ubuntu, Ryan Dewhurst (http://www.ethicalhack3r.co.uk/) made a short guide. Thanks!

Well since I'm useless at writing/finishing stuff within a linear timeline, I have decided to write a post on what is sitting in my drafts folder, all 7 of them. I guess its not a big issue since no one actually reads these ramblings, they are more of a reminder to myself to get things done.

So here follows the posts I'm busy working on:

Inferring DDoS Part 1: Flow Based Analysis.

I digg network telescopes (also known as blackhole, sinkholes or darknets if it floats your boat), they form a decent proportion of my research (both last year for Honours and this year for my MSc). This post explains how flow based analysis is used to detected DDoS attacks from traffic captured by a network telescope.

Inferring DDoS Part 2: Event Based Analysis.

Same as above but looks at event based analysis, which makes use of some time-domain qualities, which are essentially just a handful of metrics that help to detect and single out DDoS attacks.

Researching potentially malicious IP addresses

This post documents some of the analysis and information gathering scripts I have written over the last while to help me expand on data I collect with network telescopes. These include geoip lookups, projecthoneypot lookups, nmap scans, reverse dns and worm fingerprinting (slammer so far) from live traffic.

Dissecting W32/SQLSlammer.worm

This post is based on the analysis of slammer, a really neat little worm. By neat and little, I mean all contained in a single UDP packet and able to make a MSsql server bend over. I look at the payload, how to read the opcodes, what they do and how the exploit works. I then go through a pythons script I created to inspect traffic on a interface and alert you once sql slammer has been detected.

Penetration Testing Lifecycle

This is my attempt to get more familiar with what happens during a pen test, I've got some theoretical knowledge but not nearly enough practical hands covered in shell code, nitty gritty experience. So the post will cover pen testing broadly and also lay the foundation for subsequent posts based on more specific aspects, techniques, tools and considerations.

Pen Testing: Null byte problem

Really old bug that is still very prevalent and has decent coverage since it's concerned with C string handling and subsequently effects almost everything built on C, which is harsh. The other issue is, its been around for ages but I believe it's lost on most of us young folk and theses are the people who are building sites that will be vulnerable to the %00.

Defending against Phishing - Thats my image!

This post is based on the ridicules notion you could perform a DDoS attack through some basic JavaScript.

The idea here is to have a site with some embedded JavaScript that would make repeated requests to your targets website. We don't actually want the JavaScript to display any of the content its requesting, just keep on requesting. Now I realise this would require a whole boatload of people to visit our site with the naughty JavaScript and actually stay a while (and listen, as pronounced by Deckard Cain).

Within the web 2.0 circle, sharing is caring and everyone is connected, it's not to difficult either. Creating a sockpuppet army is however beyond the scope of my productivity at this point and as such just make use of redit, digg, 4chan to get a steady flow of visitors.

The page your going to put the JavaScript on will (for now) contain some interesting information that will keep the user busy for a little while, what exactly is not of importance (magical robot unicorns, naked celebrities, ect.). Just pull something from a news site, digg or google trends and copy/paste the content. For simplicities sake, lets have the JavaScript request an image on the target site.

The image can be a tiny blip on the screen just set the width and hight to 1 pixel, the whole image is still being pulled, rinse and repeat. Now I'm sure there are other ways you might be able to sap more bandwidth from a site, but for now this will have to do. I did have some POC code for this, but in the intrem of starting this post and finding it months later in my drafts it has been lost. So I've decided to push out the post now and have it staring at me on the blog in attempt to motivate the new POC once I get a chance to redo it.

I recently had some trouble getting a php script to write to a sqlite database on my Ubuntu box running Apache. This annoyed me for a bit since I copy and pasted an existing folder with scripts and a sqlite db in and renamed it so that I could work from there (the original was working fine).

Turns out the permissions where a bit bork, anyway quick way to fix, first find out what user is running PHP. This can be done by adding

echo `whoami`;

to your php file, the output would be the user running php. Then switch to root and use:

chown <user>:<user> -R /var/www/website/

in my case I had to use

chown www-data:www-data -R /var/www/ponies/

Its always a great feeling when you wake up in the morning and realise you have to do a presentation the next day. So its my turn to present this week at our weekly SRNG meeting and I've decided to talk about what I've been doing for the last month, or rather what one of the papers I wrote was about.

The Tartatus framework is a threat detection and mitigation tool that primarily makes use of honeypots to detect and isolate potentially malicious host on a network. The framework is able to quarantine hosts on a network through ARP-poisoning with a little Python script I wrote to interface with Ettercap. This will scale for larger networks by rather using an upstream router and some dynamic route injection to quarantine host traffic, but for the moment good old ARP-poisoning will do.

A while back a wrote some code to visualise the traffic sources captured by a network telescope. I used MaxiMind geolocation lookup to get the latitude and longitude for a given ip address through their python API. I then wrote another script to interface with nmap and do a portscan + OS identification on that host, the data was parsed and inserted into a sqlite3 database.

Once I get the code cleaned up a bit more I'll post it online and add a link to a demo.

These are some images illustrating the visualisation, I used three different coloured markers to indicate the age of the data, it also happened to indicate how constant a general area was at producing traffic. Every 5 seconds a new marker would be added to the map, the data set I used from the network telescope contained about 300 unique hosts (whose details I could enumerate).

Running shellcode on most linux operating systems has a few prerequisites, basically you need to disable some security features, otherwise all your going to get is a heap full of segmentation faults.

To disable stack randomization open up the terminal and use:

sudo sysctl -w kernel.randomize_va_space=0

I'm using this little template to test shellcode (found at: http://www.vividmachines.com/shellcode/shellcode.htm)

char code[] = "Byte code goes here"; int main(int argc, char **argv) {   int (*func)();   func = (int (*)()) code;   (int)(*func)(); }

To get it to work its going to require some extra compilation flags:

gcc -fno-stack-protector -z ExecOnStack shellcodetest.c

then run it:

Any traffic observed on a network can lend itself to interpretation and assumption of the events that created it. Some might not find it interesting while others might be intrigued by it, to see how much you can really learn from packet analysis have a look at Jogn Kristoff's blog at Team Cymru on Deep Darknet Inspection.

Below is a small list of common packet requests and responses that might be useful.

[ REQUEST => RESPONSE ]

TCP SYN (to open port) => TCP SYN/ACK

TCP SYN (to closed port) => TCP RST (ACK)

TCP ACK => TCP RST (ACK)

TCP RST => No response

TCP NULL => TCP RST (ACK)

ICMP ECHO request => ICMP Echo reply

ICMP TS request => ICMP TS reply

UDP pkt (to open port) => Protocol dependant

UDP pkt (to closed port) => ICMP Port Unreachable

While most honeypots are used to lure malicious agents so that they may be studied and their behavior analysed, some honeypots purpose is to hinder those agents. LaBrea is such a tool, used to slow down and even stop self propagating TCP based worms such as Code Red.

This image illustrates the spread of the Code Red worm through its lifetime.

The method of slowing down or trapping these worms is referred to as tarpitting. Worms are not the only malicious denizens that can be targeted, there are also frameworks that aim at crippling spammers and methods for creating active defenses against them such as generating real-time blackhole lists (RBL) which may be used by mail servers to drop incoming spam.

LaBrea makes use of two techniques to cripple the spread of some self propagating TCP based worms namely persistent capture and throttling. It does this by intercepting probes from the worms that are directed to unused IP addresses that LaBrea is monitoring and forcing those connections into undesirable states. When an external host attempts to send traffic to an unused IP address in our network a router will broadcast ARP queries to find the host that belongs to that IP, if no host replies the router will continue sending multiple ARP queries.

LaBrea takes note of multiple un-answered queries and will then respond to the router indicating that the IP address belongs to itself (thus taking over that IP address). Labrea then creates a virtual machine for that IP address and will continue to monitor all traffic destined for the MAC address it has given to the router.

It is important to note how Labrea consumes IP addresses on a network since incorrect configuration will result in LaBrea leasing all available addresses from a DHCP server which could starve a network.

When LaBrea receives a SYN packet it will setup the connection by completing the 3 way TCP handshake. Once the connection is made there are two ways that LaBrea could use to slow down or incapacitate that connection, the first of which is throttling.

Throttling allows LaBrea to slow down the transfer rate of traffic from the open connection, it does this by advertising a very small receiver window. The receiver window essentially instructs the sender to not send more data per packet than the window allows, while the connection is still operating and sending data, it will be doing so at a much reduced rate thus slowing down its probing attempts greatly.

The second method that LaBrea makes use of is that of persistent capture, with this method the LaBrea host is able to indefinitely hold the connection and thus tarpit the attacker. Persistent capture works by moving the TCP connection from an established state to a persist state, this is done by advertising a receiver window size of 0. Resulting in the attacker having to send periodic window probe packets to determine if the window has been opened again.

Both throttling and persistent capture incurs bandwidth usage on the LaBrea host, even though the traffic is minimal, there might still be a need to control its bandwidth usage. Luckily LaBrea allows for this and users may set a predetermined limit on the bandwidth usage of the LaBrea host. Some of the options that may be set include:

Throttle size of the receiver window. t (-throttle-size)

Data rate to prevent over use of bandwidth. p (-max-rate)

ARP request timeout, used to determine if address is un-used. r (-arp -timeout)