 Howdy, I'm Wes Brown and this is Scott Dunlop and we have been working on this for the last year or so. Some of you may have seen last year's presentation where we had a Lula-based prototype, but we are Ephemeral Security and we conduct research development in engineering very interesting solutions and products. Many of them are available openly with the option to purchase an unencumbered lighting for integration into commercial products. That's the stuff you will find on the internet on LGPL or GPL so you can download it and try it yourself. What is mosquito? Mosquito is a virtual machine environment with a lightweight framework to deploy and run code remotely and securely in the context of penetration tests. It makes a best effort to ensure that communications are secure because historically exploits are not trying to make sure that the communication is secure and it can't always do so. Deploy code in a virtual machine is not stored outside the process space, meaning it never hits the disk. When you have an exploit it will not hit the disk. If you have a methodology it will not hit the disk unless God forbid you manage to swap. It protects the confidentiality and trace secrets of code that is deployed and run on a target. This could be an exploit or a methodology. Why do all this? Often it is desirable to leverage zero-day code but doing so in an uncontrolled fashion can harm repercussions like if you use zero-day code and somebody of a target managed to get hold of a zero-day code. He might spread that around or something. Many practices have trace secrets and methodologies distilled in the form of audit or exploit code that they would keep out of the hands and for that reason they would tend to keep it on their own machines that they can control. What mosquitoes should do is deploy the code you want to control on a victim machine and have a reasonable precaution of it being secure and safe from being reverse engineered and tampered with. As I have said before, mosquitoes use a very strong cryptography to ensure that communication between the target and the console is secure and more and more interestingly it provides a dynamic like remote institution environment around inflight modifications of code. How does this approach compare to the others historically? Shell code. Shell code is static, influxable, low-level and targeted to one environment. It can break with patches or environment changes. Many exploits I have seen break between Windows service pack levels and so you would have to re-factor your exploit targeted towards that new service pack level. We also have syscall proxies. They are more flexible than shell code in higher level. However, the driving logic is on the attacker side. The target doesn't have any of the driving logic because the console is pushing syscalls to the target. What happens when that one is unreliable, it breaks and that happens a lot. Syscalls are great if you just want to get a shell, but syscalls are very clumsy if you want to actually implement a program to run on the client. We also have DOL injection. We can implement higher level features easily. Logic can be placed on the target side and run, but it is still static and it's Windows only. When you write DOL injection code, it will run only on Windows. And taking my next step up, we have exploit compilers that are often compilers reading and scripting languages targeted towards the assembler of a target platform allowing some level abstraction at programming time, but they are still static at compile time. Once you compile them, once you got them on the victim, you can't easily change them. So we come to lightweight application virtual machines. It can be very small, most of them is 128k, binary size and Linux. That's the whole virtual machine with all the libraries you need to run it. It can be even smaller with executable compression tricks. I would say we can get 64 to 80k with executable compression tricks. And more interestingly, it's white once run anywhere. Cold running on a Linux VM will run on a Windows VM on Altruz. You don't need to write custom code for your different platforms. While I've seen exploit code or attack code, you have to write it specific to the platform. But if you write it using master, you don't have to. And with master, we can use languages designed for the task. We created our own language called mosquito list. And because we had the flexibility of creating our own language, we can have a language custom designed for this sort of problem. It provides a very nice orthogonal development environment. Dynamic. Code can be altered and updated even on a remote VM. If you get a remote VM on a target, you can continue altering code there dynamically. So if you have an exploit that doesn't quite work on your target, you can modify it on the fly, on the target, and maybe get root level escalation or attack another machine on the network. There are several major components to mosquito. We got the core virtual machine, MOSFIM, the small core, which is 128k. We got the language mosquito list environment and libraries. We got the console, which provides the user with interface to manage and deploy drones. And we have a drone, which provides a remote process that contacts this match console and attitudes by code and statements on its behalf. The virtual machine is production ready and stable. We are in beta three, meaning we think we're ready for production, but we don't like to say it because we have had hundreds of people hammer it, and I'm sure they will find bugs, which we will elaborate in the future. It's easily extensible. We were able to implement regats in a few hours. We just pulled in the BSD regats library and we implemented regats in a few hours. It's pure NCC. It will run on anything, pretty much. We, for our development environment, we used OpenBSD, Mac OS X, Linux, and Windows. Some other people ported it to the MIPS, ARMS, and NILES 2. You can run it on your wireless router. The 128k I mentioned is the virtual machine stub. It's the actual binary extensible target to towards the platform. And we can attach bytecode to the stubs. Programs and applications can be compiled and attached to stubs. So if you have stubs for four different platforms, you can, in one pass, build an extensible for every platform you have. And it allows standalone extensible for no external dependencies. If you've got an XML library, you've got an HTTP library, you've got a regats library, you can have it all in one extensible without having to install anything else on your target system. Dependencies are automatically solved when you use an import statement. Mosquito will automatically figure out what modules you need, compile it, the bytecode, and attach it to the virtual machine. And we have integrated very strong cryptography using ECDH for key exchange and AES for the communication itself. Now, Mosquito Lisp, the language. It's a network oriented and compact Lisp with strong influences from scheme. It's designed for network applications as highly concurrent and provides simple and efficient network and process APIs. Over the last year, we have implemented our library function. We have over 300 primitive functions or 200 library functions in the standard library, not including additional library specifically to Mosquito. We are well documented, at least I like to think so. We have a complete reference manual for the functions that we have. How many programming languages can claim that? The language is sufficiently developed that we wrote the compiler in it. The Mosquito compiler is written in Mosquito Lisp to compile or compile itself as part of the build process. And we got all sorts of nice goodies in the standard library. It can be available on the drone if you like. You can have a SML, you can have an in-memory database, a queryable database, we have rega support, we have HTTP, all of that in this tiny little drone you can put on a remote host. One of the more powerful features of our language and environment is channels. It allows for abstract communication. A cryptographic channel is provided for easy encryption. We transparently negotiate on top of channels and it provides a layer of abstraction from an actual communication mechanism in use. Right now we use TCP, but there's no reason we can't use ZUDP, CMP or DNS. It will not change any of your higher level applications or functions. All you have to do is write a little library to do it to guarantee a network connection and Mosquito will take care of the rest of it. But programmers do not care about how communication is done. Processes and sockets have really nice channels that can be mapped to other channels. Some people keep thinking that we could use that for distributed computing. Well, we could, but it's not our way to go, our target, but I wouldn't stop anyone from creating a distributed computing with this. The drone is a virtual machine with Kwiper and drone functionality. It's highly optimized to reduce size. It does not include the Mosquitoless bytecode compiler. It cannot compile things by itself. It stores and executes bytecode programs sent by the console. It can pull additional libraries from consoles over channels rather than embed in drone stuff, including the compiler. If you have a drone, you can jump a drone. You can start pulling libraries over the link to meet your circumstances. So you would put the minimum function needed to establish a connection to the console in the drone. And once the drone is in, you can pull in all the libraries you want over the network. This is to keep the drone as small as possible. And while after we bootstrap, we can expand the functionality. By code sent by the console, it's only stored in processed memory. When the console sends it to the drone, we do not write it to the disk. It's kept in memory. And even more than a drone can relay for a drone to the console. So if you have a console and you start up the connection to a drone, you inject it using the exploit, then you can upload the exploit program to the drone and then inject it into another drone. And the drone will talk to the console through the drone in between. It's useful for attacking intranet and VMZ networks from an external network. You can puttohop very easily with Mosquito. We have a console with just a virtual machine plus Kripto plus console functionality. It provides a local process to control deployed drones. It provides a full Mosquito list environment. It includes the compiler to compile Mosquito lists and statements and programs for the drone on the fly. It interface, we have interface to interact with drones. And we can create drones on the fly using the stub. So if you begin a penetration test and you have no idea what your target is, you find a Windows machine. You can create a drone for the Windows machine right there with all your libraries. What can you use Mosquito for? You can reach back to exploits into Mosquito limits for security appointment on a target. Network and host recon code management and research over a secure channel. If you have a remote support scanner, we can make sure that the data you send back to the console is not eavesdropped. It makes it safer for the client actually. It simplifies deployment of all these intrusive hosts. All dependencies are included with the drone and managed by the console. You don't need to implement a ton of dependencies for in-map work alike. You just drop the drone and you got it running and anything. And here's the demonstration. This is Mosquito list console prompt. You can do things like add three and five into it, that sort of thing. Would you like to demonstrate Mosquito list? I guess I could. Let's see. You know, you didn't tell me anything about me doing a demonstration. Actually, that's not a bad idea. It's there. Okay. What's the address of one of the victims? See, you don't even remember. Okay. Why don't you just, Wes? Why don't you let me just have a virtual machine and I'll put a web server there. That's a really annoying beep. Why? He's still loaded. I'm glad we're not demoing VMware today. Come on. Let go. Yeah. You didn't tell VMware to allocate a full gig for that image, did you? It's weird to pull up at us. Oh, wait. Here we go. Well, I'm glad we've got the calendar. If you're a little closer, you can hear this thing paging like crazy. You know, I'm not a patient man. I'm kicking myself right now. They're asking, do you want to put the other laptop in the switchbox? You started loading another virtual machine. Now Windows 2000 is massively efficient boot-up processes. Well, we'll give it an hour. Maybe you should shut down your BitTorrent clients. At least the Linux image is being helpful. It's still paging like mad. I don't think you can hear it. I've got flashy cursor. That's enough. Back away before I break something else. All right. As we were, I tend to use make-repple because I really like our all-wrap. I can never remember the exact symbols file. Let's see. TCP server. What we're going to do is create a little TCP server real quick. Nothing fancy. Let's hope I gave it a port. For anybody to get some clever ideas, no, my wireless is not on. Any coffee? Can you give me coffee? All right. As you can see, we spawned TCP server. Lambda is a funny way of just saying an anonymous function for those of you not familiar with Lisp. So we spawned it. It kicked the process off in the background to listen to port 9911 for TCP connections. We did define C. Oh, we did. We told it define C, bind it to a new TCP connection to local host port 9911. Now, the first thing we have to do, because the connection is asynchronous, we have to check to see that it actually has connected, connects. Good. Now we can do another wait, get the buy message that we sent earlier or not. Let's take a look at why. No, that should be okay. Oh, actually, that is correct. The single quote there actually is Lisp for do not evaluate. If I just sent close here, I'd be sending the close function or whatever is bound to close. It's a little weird. It's how Lisp likes to escape things. Oh, somebody else wants to try it. All right. Let's try that again. This is a little bit of insurance. Timeout C was reasonable. 10,000. That gives us a timeout. Now we do another wait. Still no good. This is a good time for me to ask you what firewall policies you put on this thing. Timeout. You're sabotaging me. You know that, right? Okay. So that's no good. Well, I've shown the interaction debugging capabilities. Did any of the other virtual machines manage to make it up? That was a virtual machine that clashed. Is the victim alive? Yes, open that. I know. About 190. What is that? 190, 130. All right. One memory. Got 130. You can tell it's got the idetic memory around here. And we get a bad request. The website clashed. A testament to IIS's reliability here. Actually, no. I got a bad request directly from the server. You get to guess how it fouled up all your virtual machines for your test. Okay. We're back at the MOSFET console. And these are all the commands that we have in the MOSFET console right now. We have copy. We have drone. We have create a drone. We have fork. For example, do plus three, five. And that gets you eight. And now we evaluate all this expression. We have, we create a drone on the file ID platform. So we can do drone. And then it's drone. ID, Ubuntu, drone. And then it's 86. And I will specify the platform. We can do Darwin or we can do Windows or we can do Linux. So, but when I would do it in Linux. But first we have to define the address that the drone knows to connect back to. Which is 1.9129. And I'll just create the drone. Now the console is listening for the drone on 0.26070. So all we need to do is get the drone running. So let's start another terminal. And then that's the file with the virtual machine itself with the drone functionality attached in bytecode. So we just modded it. So let's run it. And now the drone has to cryptographic connection to the console. I'm sure it behaves for you. Yeah. And we did key change and all that while we did the connection. The drone is giving a key, a one time key that is used when it's connected to the console. No other drone will have that key. So we have a drone named Ubuntu drone. And it's listed in the list of nodes. There's a node command which shows all the drones that are connected. So we have a special command called on Ubuntu drone do plus three five. This looks simple, but it's doing a lot of magic behind the scenes to let this happen. What it was doing was it was taking the list expression plus three five. It was compiling the bytecode. It was taking this bytecode, transmitting it over the cryptographic connection to be executed on the drone itself. And then the drone passed back the result. So we have some pretty neat functions like and respond a new window. This will work on Mac OS 10. This will work on Windows. We have some sort of platform native way of spawning Windows on each of these platforms. But we just spawn a new window for that particular context, Ubuntu drone. So whenever you type a statement in that it will happen on the drone itself rather than on the console. So we have plus do plus eight five three five. All right. Now we can create a new drone. Drone, Ubuntu drone two minutes. Drone two. Ubuntu drone two minutes. That's 86. Whoops. I forgot to set the address. Okay. And now the drone listening on that port. Not the console. The drone listening on that port. So let's make a new terminal window. Set it as suitable. And now the drone connected to the drone. And through the drone, it's talking to the console. So let's check out the console. There it is. And now we can do on Ubuntu drone two on Ubuntu. Do plus three five. And now what happened here is the byte code was compiled. It was transmitted to the drone through the drone lay in between. And further, the drone in between doesn't know what's going on because the channel between the console and the second drone is its own good product channel. Only the console has keys for the drones. So even if you have intermediary drones and somebody intercepts the drones in between, no good. You don't have the keys for any of the other drones. And then this is it. We have a proxy, a socks proxy on Ubuntu drone two proxy. And now we have a socks proxy running. So let's fire up by a box. Let's go to preferences. And then we can connect manual proxy connection, local host, and we got 27241 27241. It's a socks for proxy. Just push okay. And then it's a little slow. But this proxy was happening through two drones. So the proxy was originating from Ubuntu drone two. So we can have a chain of drone and you can proxy all the way through. We have a port scanner too. So we would do on Ubuntu drone two port 80. And then 192.198.130.80. And then we got the port scanner. What it did was it sent a little program to the drone with an import statement to the drone port scan library. And because our important network transparent, it pulled the byte code for the port scanner across the network to the drone before the drone didn't have a port scanner. But now it does. All you have to do is issue the client name. And we have the functionality on the drone that we did not have before. And then I wish I could demo some of the really neat things that we have a Win32 drone. But as you saw, the Windows VM crashed. But we have Windows drones. We have Linux drones. We have Macintosh drones. And other people have compiled it for their wireless routers too. So they could put the drone on their wireless router. And it was pretty neat to see. You forgot to do something fun. First of all, I hate having to type this over and over again. There. You do have NMAP installed, right? Maybe not. No. Boy, Ubuntu never has anything useful. Why do I need NMAP? I got the port scanner. I'd like to verify. Oh, you cheap little SOBs. You didn't actually use your standard NMAP. All right. Well, that's in the wrong place. So you just do this, I guess. Or wanted. Let's see. Keep your game to put Alice on. Pardon? I suppose I could. Let's look at index HTML again. Oops. Need to get that failover code done. And it's right there. The SH stuff works pretty well, but I wouldn't recommend trying to use VI through it. Anything that wants a pseudo terminal that we don't support yet. And what you see is still an unfinished product. There's always features that we can add. So in the works, in plans, we have what's just called FFI interface. And with the just call FFI interface, we can abstract it out using mosquito list programs. So you have a form function in Windows that behaves similarly to a unit post-it call. We can just implement a mosquito list library to abstract it out. So when you write your methodologies, it will work on Windows and Linux, regardless of the platform differences. One of the neat things we're looking at is the oil and share library injection so that we can insert a drone. And then we can pool additional binary level libraries, I guess, over the wire. Right now, we can pool mosquito list bytecode, but we can't extend the functionality of the virtual machine. But we use the oil and share library or any injection. We can do that. We can add kernel drivers for packet sniffing and the like. One thing we're looking at is executable compression techniques with a target size of a 64K payload for the virtual machine drone. And another thing we're looking at is additional transports, UDP, ICOMP, and CTP DNS. And of course, they're always core language and environment enhancements. Another thing we're looking at is in the work as a proposed guess, which is the fetal tube of a mosquito. It's the only job is to pool a higher level environment like mosquito. We're thinking about making it a fourth virtual machine with an FFI system call interface, and it abstracts out the low level assembler, and it allows multi-architecture shell code because fourth is very close to assembler, it's closer than C is, but it's still a pretty nice language to develop here. So we have a tremendously binary size of 2K binary around inline with exports, and we have handcrafted assembler with relocatable code so you can use it as any export. Another thing we're looking at in the works is IPAP, the framework for network applications to generate, collect, and analyze network packets. It's a sophisticated library to classify packets and manipulating packet fields without forcing developers to resort to complicated structures and pointer arithmetic. It will extend multiple console drones with packets never in generation functionality. These are our email addresses, and you can find us online at www.fmallsaturity.com. All the code is available by LGP off on www.fmallsaturity.com. What you have on the DEPCON 614 CD is a beta 2, what we have on the site is beta 3, because we have been constantly improving it since we submitted for the CD color. So if you want to try and mosquito, I would encourage you to download it from our site. We also have a mailing list where you can find our site for discussion and questions. You have any questions? Thanks, as you may have noticed Wes is deaf, so it's easier for me to handle the questions. He can't lip read from quite this distance, though I still think we should brought binoculars. Hey, this is the first time I've ever heard of what you're working on. Sure. Sounds really cool, but I'm just curious, what happens if you lose the connection to a drone? Does it automatically try to reconnect back? Actually, I can demonstrate that it does not automatically try to reconnect. Let me see if I can safely find my way to another drone without causing another crash. Did leave the drones up, right? Yes. Let's see. Would the console please stand up? But actually, we engineered for that because it's fairly common. Oh, you killed it, didn't you? You caused me no added trouble, Wes. All right. Okay, everything's running good. Hunky Dory. Now on one, we will do exit, which is our brute force. I want to quit right now. That didn't work. What the heck? Why is there a touchpad there? You know, people should choose if they want a stick or a pad. Anyway, okay. Now, why are you scrolling? Wes, your console is drunk. All right. As you can see, we've lost connection because some bastard did the control C. So what we do is you simply instruct the console that one will be reconnecting. We re-initiate. And as you can see, it's right there again. On one, do print. And as you can see down the corner, hi. The reason it does not re-affiliate immediately, and it doesn't automatically try to re-affiliate, is that each time a drone is reused on an untrusted network, it weakens the protections afforded. Because the first drone to successfully complete the affiliation wins. They're the one that the console will consider to be the actual drone. You have to do some verification afterwards, of course. This checking IP can figure whatever. So if D1 goes down, if your drone goes down and you do a recovery, it gives a new opportunity for an attacker in the middle to try to complete the affiliation first. Thank you. So recover is a manual process. It's something you should do just when you know you're about ready to re-invoke the drone. Okay. Well, so if you say you have a drone on a private network and you're trying to connect yet your console is externally accessible and you lose a drone on the private network and you have no way of getting back to it, it's pretty much a lost drone. You can't really... It is a lost drone, but you can get out there. Drones really don't store a lot of data. Any information that they report is collected and maintained by the console using an in-memory database. So, for example, ports that you found, other things. We have an expert system that we've been working on to implement AMAP-like functionality. And you can just go ahead and do the AMAP once you've managed to redeploy and re-establish a new drone. All right. Thank you. No problem. I was just sort of wondering, since you're running bytecode and for some reason it might get mangled at the destination, what would happen if I would try to... If the bytecode would be bad? Like, would it crash? Very possibly the drone will crash. The console itself does not execute any bytecode on behalf of the drone. So the console is pretty much insulated against that. The drone may crash, but first it would have to get past the integrity checks in the actual protocol. This is the CRC32 that's encrypted along with the rest of the stream. And that would be the first thing you'd notice is that the actual connection would drop and it would say that there's been an integrity problem and that you need to re-establish the affiliation. Right. And that would mean that if the drone was in the middle of holding a certain resource at the destination or something, that would possibly lead to a deadlock or something? The console should handle it correctly. We use a cooperative multitasking system so that it's very hard to actually have a race condition in the console. Basically, the commands are written in such a way that they constantly monitor for the event of a closed event. It says, okay, I've lost the TCP connection. The data I have is all I have. The command is incomplete. And all this is notified to you on the console. All right. Thank you very much. No problem. Anyone else?