 Thank you. So a machine being up for four minutes and already transferred four gigabytes of traffic. What could that be? Something screwed the network stack? Something strange with that machine? If you're on this machine, and it perhaps is not your own machine, you really, really should get suspicious at this point. That might be a honeypot. We show you how you find out and what to do about that. So, who of you knows what a honeypot is? Just for a... Okay. So, nearly everybody knows what a honeypot is, so I can do a very quick introduction. On this page, you see the typical setup of a generation to a honeypot. A honeypot is, according to the definition by an even-in-net org people, a concept to monitor the two detectives and motives of the placard community. Basically, they want to see what you do once you've routed one of their boxes, what tools you use, what commands you use, whether you connect and what are your actions. As you can see, in the orange box, the honeypot typically consists of two main components. In the upper part, you see a hang-all. That's a transparent bridge. That means it has no IP address. It doesn't decrement the TTL of a bypassing packet. Basically, you only do data capture and data control on this device. Data capture means that you run TCP dump on this box, so you can lock every packet that's going inside and outside of your network. You also collect all data that your honeypots are producing on this box. On the other hand, you only roll just data control. That means you install Snort Inline, an intriguing prevention system on this system. Snort Inline is a modification of Snort. Basically, what it does is it filters all the outgoing traffic such as for exploits and can block them or modify them so that you, as you own one of these boxes, can't do any harm to an outgoing box. It's mainly used for legal actions so that you don't have to feel that someone who boots one of those honeypots can do some damage to another side. The other data control that's done by the Honeyworn is something like a traffic limitation. For example, they do traffic shakings, though so that you've got only perhaps 10 kW per second of output, or they do some kind of traffic restriction. Basically, only 25 TCP connections per day, for example. So apart from the Honeyworn on the downside, you see the Honeypots. The Honeypots are the main interesting part of the Honeypot, of the main Honeymat. A Honeypot is basically a tool that should be prepped, attacked, or compromised. So you just install another system. For example, a Linux box, a Windows box, as well as a PSD, whatever comes to mind. You do not very much change things on this box. Basically, you just add some logging capabilities, and then you install normal services. You connect those Honeypots through the Honeyworn to the Internet, and then you just watch what happens. In order to learn the tool taxive and models of the packet community, you have to do something so that you can watch the actions. For example, the TCP dump is completely useless if the intruder loop uses something like an SSH connection. You only see then the encrypted traffic, and without the appropriate key, you can't decrypt anything. So basically, you have to do other things to watch the attackers who own your Honeypots. The main tool used nowadays is Zivac. Zivac has the capabilities to monitor all activities on the Honeypot. So basically, it claims that it can lock everything. We'll show later in this talk that this claim isn't true. With the help of Zivac, the operator of the Honeypot is able to control everything that you do on one of those boxes. If you do an SSH connection to the Honeypot, you'll see everything you type. If you do something like a secure copy, he will notice everything. If you decrypt your burn ID protected binary, he'll notice the password and can also decrypt your burn ID encrypted binary. How does he do it? Basically, Zivac is a kernel module. There are variants of Zivac for Linux. It's the main, or the current implementation, only for 2.4 kernels. Then there's also an implementation for OpenBSD for Windows. It's only a huddle-and-herry implementation. We've got also fresh allows or some other operating systems implementations of Zivac. In this talk, we'll mainly cover Zivac for Linux because Linux is the main Honeypot used nowadays. So, how does Zivac work? In the first version, Zivac was based on a door. A door is perhaps everyone here knows what a door is. It's one of the most known woodkits nowadays. In the current version, version 2.1.7, everything is re-implemented, and Zivac has a complete new system. What it basically does is hijacks the system called suede. So, every time one of your diagrams, or any diagram, calls weed, then Zivac does the following. It passes the data to the original system call. The result is copied into another buffer. To a buffer is added something like a Zivac header. Then everything is copied into an SKBuffer structure. The structures are handed to the driver, and the driver sends everything to the outside. The sending is done in a covered way. Because you use the SKBuffer structure, all the picker-based firewall rules won't notice that anything is going wrong. So, if Zivac is running on the box and you fire up TCP, one of these Zivac packets will not notice one of them. It basically modifies prognetic depth in order to hide its presence. It fiddles with the counters, so you can't see that Zivac is sending anything to another box. The packages that are hidden are identified by a magic number. That's a 30-bit value. They are identified by being in a UDP packet, and a special port number for UDP, basically. In order to hide Zivac, or the presence of Zivac and the host, there are some things that are currently done. For example, Zivac loads as a kernel module, and in the basic installation, it has just got one run domain consisting only of some memory values. After once, the second module is loaded. It's cleaner.o. That's also part of the other rootkit. Cleaner.o has basically only one function. It unwinds the next module in the module structure list, and then unlocks itself. So, basically, after cleaner.o is loaded, Zivac is unloaded from the module list, and so something like AliceMod won't see that there's any other package showing up. So, now we are going to demonstrate our toolkit. To give you a first impression on what we did, and then after a step by step we will install, and we will show you how everything works. So, we have the honeypot run by an evil entity. In this case, Thorsten is running it on his notebook. We have the logging server run by an evil entity too, which in this case, I'm on my notebook. And we have the attackers machine, by a good hero, in this case, me, my notebook. I'm now logged in on the honeypot, and for demonstration purposes, I'll start a web server there, which is badly vulnerable. So, this web server, basically, you can upload a binary and it executes it if you use the secret postparameter exploit. This is in simple vulnerability. You could go for more difficult ones, but for the demonstration purposes, we have this very vulnerable web server. So, now I'll work on my own machine. First, because this machine has to act as a logging server, I have the window getting the logging packet sent by the honeypot. This is this one. Thorsten will now type something on the honeypot, and as you can see, we have basically keystroke logging here. Okay. Now, I'll start an attack on the honeypot by uploading a binary to the vulnerable server. This binary is built on demand and basically contains our attack tool, which was uploaded via call to the server now, and now we are connected already to our attack server. As you might have seen, there did some logging taking place because the uploaded tool was basically a share archive extracting itself and executing the attack server, which is written in Python. Basically, if you're willing to code C or do something else dirty, you can get around that. I'm now connected with the server, with our attack server called KBS, and can execute arbitrary commands, for example, listing the root directory of the honeypot, and as you see in the lower window, there's no further logging taking place. I can get information on the machine. You might notice that now I'm still running with the new ID of the web server, nobody, 65534. I can read files on the server, as long as nobody can read them, for example, ETC PassVD, without any logging still taking place. I can upload files, and I can execute files without any further logging. In this case, I'll execute a vulnerable SUID script replaced on the server for demonstration purposes. And then again, we get a little bit logging because this again is written in Python but too lazy to convert it to C. And now a wonder, we use the vulnerable SUID already to execute a second KBS server, now running as root. I'll demonstrate by connecting with a second client to the server, now running in a different part. And again, can execute all kinds of commands there without further logging. You might notice that now the effective user ID is zero, so this KBS server is running as root. We can read files now only readable by root, like Shadow, ETC Shadow, without any logging. And we can send special commands like the NOSPRAID command with some logging, but basically we'll get warning messages because KBS, because the Zbeck Toolkit is completely out of his mind and gets too much data and can't log anything. And now we have the nice information of a cleanup routine and we can jump there with a tool we uploaded before. And now we get some warnings because the GNU people are bigots and there's no honey pot anymore. As you can see, I'm now again on the honey pot and there's no logging taking place, no keystroke logging, and if Torsten works on the honey pot no keystroke logging still. This is the Zbeck Toolkit from the corner with nearly no logging data. Okay, so much for the teaser now for the background. Who are we and why do we do that? We are both from the Laboratory for Dependable Distributed Systems at Aachen University. We have Torsten as a research student and I'm a research assistant and this laboratory is running a honey net. We wanted to see if this is really a good thing and if we can trust the data on there and for the heck of it if we can bring it down. The authors of Zbeck, just for information this is not a picture of the author of Zbeck which is a really nice guy and a smart one too but that Zbeck himself, at least at the ancient Egyptians saw them because it's an ancient Egyptian name. Claiming that even if Zbeck is being disabled one would be able to log how it is being disabled and we had our issues with it assumption and tried if we can attack it and we were able to. I think we did this demo already with the vulnerable server. So now we come to detecting Zbeck. So as you've seen in our demonstration we are basically able to detect the presence of Zbeck on the hosts. We can avoid the complete logging and we are also able to disable Zbeck once we are out on the box. So basically we are able to compromise the honey pot completely. We will now give a step-by-step introduction to how we did it and at first we wanted to talk several ways to detect Zbeck. If you think about Zbeck, Zbeck is basically a rootkit so our results can also be extended to some kind of rootkit detection. If you think about this whole task then there has come several ways into mind. At first as I explained was the honey wall. The honey wall is running in front of the complete honey net and it does some kind of data logging and data restriction. So basically you could find some ways to detect the honey wall and if you detect the honey wall then this is a strong sign that there is also a host which is Zbeck running. Detecting the honey wall is left as an exercise for you. If you need some information on this just look at one of the two fake issues. I think four or five months ago there are some hints so it's basically just a few total scripts that you have to write. As I said before, the logging takes place by putting all data that's logged by the suite into a buffer and then sending this to over the line to the logging host. So basically if we do much reading then we should be able to fill up the complete line and see some latency effects. Also, Zbeck has to fiddle with the network counters because it communicates directly with the driver. You have to adjust the drivers so that the output of fconfig and any other tools is consistent with the system. So if you take a closer look at the network traffic counters we will also probably find some signs of Zbeck. The app for Zbeck is the modification of the syscall table. Basically there are some pointers which are changed and perhaps we can detect it. With the help of cleaner.o, Zbeck also unloads itself and tries to hide itself so we should be able to find the hidden module in memory and perhaps we can do some other things in memory in order to detect Zbeck. I can now step-to-step on these five points and explain what we've did. At first we take a look at the latency. Perhaps you all know the DD command. It's a very easy tool and with the help of this command we can within perhaps 10 seconds detect that Zbeck is running on a host and we'll just show you this. The command is something like dd. As input file we take dev0 and output file devnull. So basically we copy just inside the system some from dev0 to devnull with the block size of one. And then we should see some effects. So basically Maximilian will now understand the situation. So we booted the HoneyNet because we just removed the HoneyPot software for demonstration. We installed the HoneyNet and we started SSHD. We are doing that now. Basically I shut it down SSH for purposes. So we are on DevCon Network and probably it's not secure. So, yeah. Okay, now Zbeck is running on the host. And at first you should ping... So at first we just do a ping from this machine to this machine. We've got connected through a direct connection just a cross cable and as you see we've got a latency of about 0.3 milliseconds. So now we start DD in the background and do this kind of ping again. As you see on the output there's some latency. We can't type anything. It should take a few seconds. And as you see the reply times go about a factor of 10 or something like this. We've got more than 2 milliseconds now. So we've got a latency effect and basically within 10 seconds we were able to detect that there's something going on. So at the next step to detect the presence of Zbeck as another approach we take a look at the network traffic counters. As I said before, Zbeck just fiddles with PROC NAT Dev. It basically changes the output of the TX bar TX packets inside PROC NAT Dev and then if we compare this output to the output of fconfig then we should see also some differences. For the purpose of this we wrote some kernel module. The kernel module is basically a modification of Zbeck. I just removed a lot of lines and basically changed only two lines. And now as you can see at the TX bytes counter we've got I don't know no laser pointer. About 20.6 kilobyte We are connected to the box as an edge connection so basically we have about 2 kilobyte per second on additional TX bytes output. Now we insert into the kernel this Dev Checker basically changes the output of PROC NAT Dev back to its original values and if we now have something like the DDE command in the background we see that we've basically now 70.4 megabytes and if we forgot now we've got 22 so within a few seconds we've got more than 5 megabytes on data. If we now unload the module as always well we see these latency effects again because DDE is running in the background. So if we now amod the module from the kernel then we should see that the Neville counter goes back again. So I think the latency now went up to infinity and now it works and you see the transmit counter is now 22 megabytes and if we unload our module it goes back down to 42 kilobyte so there's something fishy with the transmit counter obviously. Okay and the third approach to detect the presence of Sivec is based on the syscall table as you already perhaps know the syscall table is just a table with every syscall and each syscall points to somewhere in the memory it's something like a function pointer nothing more. As you see on the left side we've got sysexit, sysread, syswrite, sysopen so syswrite is the one that hijack sivec if sivec loads now into memory we are depicted as this mod.12345.0 it just changes the pointer from the sysread to the other module and so we should see that the pointers from sysread syswrite and sysopen are not in the neighborhood we just wrote in a small kernel module before the loading of sivec the counters of sysread the memory locations of sysread and syswrite were very close together and after reading you see that this oh I think that's wrong the upper part should be syswrite the other sysread that's now in another memory location and so that there's something fishy going on. So sivec currently is implemented as a loadable module because seemingly setting up a honeypot has to be idiot proof and patching your kernel isn't acceptable a kernel module probably will just find it even if it's hidden and if we can find it we can start to extract the variables inside the kernel module and probably we might be even able to disable it every module in linux starts with a module header which is defined in includelinux module h and this module head starts with a struct with a size of the struct of the module header which is 96 implementations with pointers to the name of the module and to the next module so these are two pointers into kernel space and the one even has to point to another related module structure and the name pointer has to point to some ASCII string and some other pointers further down which should point into kernel space too then function pointers to the startup function and the shutdown function of the module which should point into the module space and some integers have only a very small reasonable space of values of usually 1, 2 or 3 and with all these values we can properly fingerprint memory locations which look like a module header that's not that hard because the module header and the whole module is allocated by the kernel's Vmalloc function and this function aligns all memory allocated to page boundaries so every 4k is the only position where module header can start this means we only have to check every 4k or every page for module header and Vmalloc only starts allocating Vmalloc at Vmalloc start with this kernel constant and only reserves memory for Vmalloc reserved bytes so a very simple loop about 128 bytes of megabytes of kernel memory in 4k steps helps us to check out the possible locations of a module header and we'll now shortly demonstrate that Torsten now says we don't have to at least I can show you the LSMod outputs 5 modules but if we start module hunter which was published in a recent FAQ article we see another module which is SNT PCMCA which is our kernel module in this case so if we are able to find this module with other techniques in module hunter we should be able to expect the variables Zeebeck is very sophisticated at least a little bit sophisticated in hiding its modules whenever Zeebeck is recompiled this Perl program or the fragment of a Perl program changes the location of the variables used by Zeebeck in a block of allocated memory basically Zeebeck has a huge block that's about between 512 bytes and I think 1k is the random size of this block and the variables used by Zeebeck are randomly placed in this block at every compilation so but if we start looking into this block we can use heuristics to decide or to at least guess to an educated guess which value may be which variable for example this might be an IP address but if it would be an IP address it is a multicast address which is quite unlikely that a multicast address is the address of the logging server so perhaps it's the magic value used by Zeebeck to hide its packets and full code might be a magic value another number like this is a value type here address so it might be the address of the Zeebeck logging server this might be a port number the port number using for the logging server and these short values might be parts of a MAC address just bytes sized which looks very much like a MAC address so by searching for the kernel module and then using the heuristics to get quite good results in guessing if Zeebeck is there and what are the kernel and the variable values so we have written a Python tool which passes the kernel structures at one time the most difficult part is finding the syscall table because the linux people have removed and there is the kernel symbol for the system call table because nobody needs the address of the system call table and we locate them by looking for other kernel symbols and from there tracing the address of the system call table then here the system call table is finally found this message has a typo it's not this white which is probably hijacked but this read which is hijacked which we showed a torsten showed you when the values are part as something probably wrong and then our heuristics guessing that there is a module which should be Zeebeck named soundPCMCIA and we guess at MAC fragments for example probably all these ones are not MAC fragments but I assure you that 3D, 3F, 5E and I think 7B some of them are fragments of the MAC address of this computer acting as a that computer of the honey wall the send us MAC address and this FF, FF, FF, FF, FF is actually the MAC address we use for sending out the Zeebeck logging data so while we can't get the exact variables of the Zeebeck kernel module we can reduce the space you have to try to very small one and we have a lot of possible port addresses and in fact we used port address and 2222 as a destination port address in most instances we get a lot less variables a lot less possible guesses but you know there is a demonstration effect of Murphy's law if you do a demonstration the heuristics will draw a bad day the possible IP addresses there again in this list of about 2,000 addresses this is the address of our logging server and after that is the address of the honey pot so we already again guessed the right IP address and the magic value we actually used is in this list of possible magic value at least it should be there yeah that deadbeat messed that up so how to disable Zeebeck that's a very nice and easy way the authors of Zeebeck thought it should be disabled and so they placed being good designers of kernel modules a nice little clean up function in there which does everything we need it's D hijacks the read pointer cleans nicely up everything and exits the module and if we are able to get the address of the clean up function we just call that clean up function and Zeebeck cleans up after itself and this is a way and as you might remember that we are able to locate the module header and the module header has a pointer to the clean up function so basically getting rid of Zeebeck is more or less trivial find the module header get the address of the clean up function jump in the clean up function that was a kernel jumper module we uploaded in our demonstration it just does nothing more than jump to address in the kernel and you are all set and done the obvious way if you don't think about the clean up function is reconstruct this read pointer and let it point again back to the original kernel function for doing so but the tricky part is getting the address of the original kernel function there are ways to reconstruct that from the kernel binary itself but they are tricky or you could find if you can poke into the Zeebeck module the pointer to the original read function but why do that if you can clean up if you are really crazy or if somebody decided to use Zeebeck not as a kernel module but to compile it into the kernel you just look to the actual this read function which is in there probably Torrent by Zeebeck and overwrite it at one time with the clean read function that's not that trivial because you have to get all the pointers the jumps right leading from the new read function which is untainted to the rest of the kernel but it should be possible so after we've seen some ways to detect Zeebeck and now we take a look at how to avoid logging at all so basically we have to we have some problems there are some data that the operator of the honeypot is always logging for example the network traffic we have to connect remote to the honeypot because it's not on our physical control so we have to use some kind of network and all network traffic has to flow through the honey wall so basically the operator can catch all traffic there so we can't do anything against this also Zeebeck is loaded on the box so before we can unload it the operator will see all calls to read everything we've done that via read he is able to log and he can analyze this later and there are some other data that the operator can obtain for example if we use some of our tools and then write them on disk then the operator can after he has seen that we've compromised this box then he can do some kind of forensic and reconstruct all data that we left on the disk so basically we want to find a way that we can in a limit as far as we want to keep everything in memory and not write anything to disk at all there are some syslog data that we can't control because the services are perhaps logging something and the operator will also get these values and he can analyze them so what can we do against logging for logging of the networked traffic there is an obvious way we simply use encryption whenever possible because when there is encrypted network traffic the operator can lock everything but without the appropriate key he can't decrypt anything so we have to encrypt everything and the only problem with this approach is how to deliver our initial exploit at the initial exploit if we can't use any kind of connection any kind of encryption then the operator will see this exploit and we lost our zero day so perhaps we should use something like an HTTPS connection or POP3S or something that's secure so that this connection is also encrypted and the operator can't see anything for this purpose we use in our demonstration an HTTPS server basically no one can see something with the help of TCP dump or similar tools another possible way to disable the logging of networked traffic would be if we could compromise the honey wall if we have got root on the honey wall we could erase everything or logging data but usually the honey wall is extremely secured often with gas security and similar patches and it has no RP address so it's basically a hard task to find it and to get root on this box so probably you have to find other ways with and then with the help of Zeebeck the operator can see everything what we do via read so what programs do use read nearly every program that uses some kind of interaction most programs you see use read to read some kind of configuration files or user input so we have to avoid read at all another example for avoiding read would be network programs network programs use receive to read from a socket so basically if we can use receive instead of read there's some way to avoid everything the problem is why is every program using read and why does encryption help if you have a connection from the internet to SSH daemon sure the SSH daemon is reading from a socket but the whole communication from the internet is encrypted and so is the communication over the socket it's decrypted inside the SSH daemon so even if SSH is reading from the socket that shouldn't help the operator of the honey net because it's just seeing the encrypted data the problem is SSH HD can't do anything at all it starts all the time external programs even for copying files in SSH and usually it has a bash or another shell behind it and SSH has to communicate with that shell and that is done by using a unix pipe and this unix pipe has two file descriptor at its end the SSH the end and the bash is reading the keystrokes we have that file descriptor and these are unencrypted so basically if we could marry SSH the end bash into a single program and get rid of that pipe no logging would take place so before taking a look at how we can avoid the users of reach we just take a short look at what is actually logged by Sebeck as you can see Sebeck Tungta and this is just the structure that basically consists of the Sebeck header there are some values that are logged for example the magic number the version number type number there is some information about the current time the PID, the UID the file descriptor and then the 12 first bytes of the program that's calling read and the length of the total Sebeck packet so the operator gets quite a few information about everything for example the PID and UID so he knows who is just calling read and what PID and UID it has also it sees the file descriptor but perhaps we can fiddle with the file descriptor for example we can there are the three standard file operators 0, 1 and 2 perhaps we can fiddle with them so just use the 1 for standard out or something like this and we can just play with these and it also logs the 12 bytes of the program that's calling read perhaps we can also fiddle with this for example if we rename the binary if you just copy to another location or something like this if you use a name that starts with at first 12 space characters and then the real program name or something similar so if we want to avoid read the first thought is that we should make read unreliable as we've seen in our demonstration in our second demonstration I think if we start DD in the background then we generate lots of packets then we've got some kind of denial of service again the honey wall it doesn't react to something like this so basically if we just put enough data through the read system calls we make it unreliable as we've seen in the demonstration there were some error messages about lost packets these were basically error messages made by Zeebeck because Zeebeck was unable to send some packets so we made the read by Zeebeck unreliable but basically we can't control which which information are lost so basically if we start DD in the background we are sure that some packets are lost but we don't know which packets are lost so this is an unreliable approach a better approach is that we just quit using read so we can use mmap to directly map some files into memory we just map them into memory and can then work with them as normal so basically we can nearly live without read there are some problems for example we can't use devices we can't map devices into memory we can't use Unix pipes or similar things we are just stuck with files but perhaps we can exploit this and avoid reading and avoid the read system it's very hard to monitor mmap because with mmap I'm able to just map 2 gigabytes of contents into my memory and no one wants to transfer 2 gigabytes over such a small link just to log something so how can I live without read the first thing I have to say goodbye to my shell the shell is designed to read anything from its standard in so I can't use it I need something like mentioned before directly talk to the network encrypt it and execute the command the nice thing is that the command used in Unix to execute actually a program exec does not call read at least in Linux so it doesn't use the internal call to read call but if you execute a program it might import libraries and some of those libraries are read we are read some are mapped into the memory I wasn't able to find out the system behind that but probably there is a system behind that people might guess which program you have been started by exec by seeing the libraries being imported and if the program you are executing is reading config files by seeing the config files being read we can mess with the process name we just can copy and rename the binary for example if we rename cat to sudo and then cat something which looks like a sudoer's file probably the forensic expert looking at the log file will think we were successfully executing the sudo program I think sudoer's executed by everybody by world on usually Linux systems on time and in Linux systems it's just executable by the read group I'm not so much into Linux more in free BSD so the results are read files unnoticed by mapping them into memory we can possibly execute programs unnoticed by calling exec if they don't pull into any libraries we are reading to memory since file names are not locked there's a file descriptor locked but not the name associated with the file descriptor we can give the impression of reading certain files if we have a file, create a file which looks like a password file and cat that the forensic analyst will see something which looks like a password file and probably guess that it was just the password file and it will take him some time to find out it wasn't and we can give the impression that we are executing programs which we can't execute because they are only executable by higher privileged users so we implemented all of this into the keybase tool which is proof of concept code and the nifty thing about it it's a network attack tool which is entirely written in a very high level language in Python so it's very very portable you don't have to compile it for an architecture or so as long as there's a Python interpreter on the target machine at once and if there is no Python interpreter and you are willing to move a lot of data around the network you just can bundle the program with the Python interpreter itself and push the interpreter on the target machine like you would do with a C program where you put the C code into the target machine it can do everything you can expect from shell not bash but perhaps asher something a basic shell and it's very highly dynamic the GRUG recently published a tool which had some of the same ideas in the latest frag I think it's keeping your zero days safe part two or something and he has a tool which is able to transfer binary to a target machine and execute it there without ever writing it to this basically that's what keybase is doing too but on a very different level because we were able to do different things with our high level language KBS used TCP sockets for networking but it could use anything else because it's modular designed for example if you deliver your exploit and still have an open socket or something like that you could use that on top of that TCP we implement a crypto layer the crypto layer is generating the key pair by Diffie Helman that's nothing in our case Diffie Helman is would be fall to a man in the middle attack but the honey wall up to now or the honey walls we know are only passive devices and Diffie Helman is safe against passive devices and later we use the AES for providing the crypto and the crypto layer also contains compression and random length padding to make it difficult for a forensic analyst seeing the network traffic to guess at the commands we were sending by the length of them the main problem is to get entropy for Diffie Helman because we can't read from Diff random on the honey pot that would be locked by Zabek and a forensic analyst would be able to reconstruct our whole Diffie Helman key exchange if he had that random numbers we solved this problem today by using other techniques like thread races and hashing the whole content of TMP and VA and so on that is no really high security crypto entropy but it should be enough to frustrate a forensic analysis on top of the crypto layer we have a python specific KBS layer which basically communicates by sending objects across the network the KBS layer we send multiple commands at once and the commands can work on multiple objects so for example you can send white these two dozen files read this one file and delete that ten files all in one KBS command on one KBS data packet and the asynchronous commands at the moment are not implemented but the protocol supports them because asynchronous communication basically a pain in the ass the nice thing is the KBS server when you inject it on the target machine it knows only a single command single python object you can use add command so if this server falls into the hands of a forensic analyst he will learn very little because of Diffie Helman there are no keys in the server and there is only this very simple command add command and the code for all additional and interesting commands for exploiting the honeypot are pushed into the server at one time the client is basically having the code for the advanced commands compiles them to python byte code and pushes this byte code objects over the line into the server but they only exist in RAM and if you are very unlucky they might be exist on swapspace have to keep that in mind that is very nice thing of development is a server actually because you never have to restart the server because on every connect when you use the client just all the code is pushed into the server so basically the server is reloaded the commands we have implemented are reading and writing using memory mapping so without this read and this write so overwriting a file, truncating it to zero bytes, renaming it and then deleting it direct execution via listing directories, getting system info it would be nice to implement the execution without any help of the server that would be the userland exec library but implementing them in pure python would be very difficult more information on the design of CBAG and CBAG can be found in an academic paper which should be on your CD-ROM also on your CD-ROM should be the nose break program which is able to find CBAG in memory the CBAG toolkit itself when the CD-ROM was created it was in a shape we were very afraid to give it away like this code you write in the early morning hours but under this URL you can download CBAG toolkit and you can download videos of our demonstrations showing how we use CBAG and CBAG and get rid of CBAG and so on so are there any questions? yeah the question was that we said that hijacking M-MAP would be very difficult but CBAG could hijack exec and that stuff yeah you are right so we have to avoid using CBAG as much as possible one solution would be to use userland exec which is by the guac and it's a library with executives and binary without ever using this kernels exec function that would be very hard to hijack the problem is that this is C code and we basically have to push then a binary object to the honeypot machine which works as long as it's the right linux version the current development version of CBAG uses also as a suite this exec and receives those calls but it's not yet publicly released it's in better status so no more questions? so just download it and check for honeypots