I think that's for real this time.
Can everybody hear me? Okay.
Thank you for coming. Good afternoon.
I am Wes Brown, and this is Scott Dunlap, my partner.
And we both do security research as an interest.
And we have previously worked in security industry
as penetration testers and security assessment and application assessment and all that.
What is Mosquito?
Mosquito is 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 the communication is secure.
Special care is taken to ensure that deployed code is not stored outside of process memory space.
It protects the confidentiality and trade secrets of code that is deployed and run on the target.
This could be an exploit or a methodology.
From past experience with working with proprietary zero days,
I have hesitated to puddle jump using the exploit
because I'm afraid of losing control of the exploit,
that somebody could be eavesdropping or somebody could be watching the file system for the exploit.
And I cannot ensure that they can do file recovery on the disk,
but this way we can ensure that the exploit only remains in memory, the process space.
At no time is the exploit written to disk unless you swap.
That's one case we can't really control if you force a swap.
I have discussed the why.
Often it is desirable to leverage zero day code, but doing so in an uncontrolled fashion can have repercussions.
Many processes have trade secrets and methodologies distilled in the form of audit and exploit code
that they would like to keep out of a target's hands.
Also very important is one problem I've had with many exploits
is it transmits data and control information in the clear.
And if I transmit the control and data in the clear, I am endangering my client.
I mean, using Netcat and all that is great, but you're sending your client confidential data over a clear text connection.
So that's one problem I'm hoping to resolve.
Well, here we have a technical overview.
We have written proof-of-concept code to prove that this idea works.
The interpreter is Lua.
Many of you may know Lua as an extension language for games like World of Warcraft.
We use a synchronous cipher called RSA, which all of you know is used for the initial handshaking between the client and server.
It's a computationally expensive operation.
So once handshaking is done, we move to a synchronous cipher called ISAC
where we trade a cipher and the clone and drone communicate by a synchronous cipher.
Another component is entropy generation.
Cryptography is worthless without good entropy, without a good pseudorandom number generator.
As you may have figured out, we use a console drone model.
One big plus is this code is extremely portable.
We have personally tested and built on Win32, OpenBSD for Intel 386, and Darwin.
By testing on Darwin, Mac OS X, we have resolved any Indian issues.
By ordering Indian issues between 32-bit, 64-bit, or RISC and CISC platforms.
Why did we pick Lua?
It is a lightweight and powerful procedural language.
It is easily extensible with bindings.
We have created bindings for RSA and OpenSSL.
It is bytecode compiled, which is a plus when you're trying to deploy code.
It is highly portable.
It is written in straight ANSI C.
And it has run on PalmPilot without any changes.
It is easy to learn.
It takes about one hour to learn if you already know a procedural language.
Moving on, we need to talk about the asynchronous cipher.
As I've said before, the asynchronous cipher is used for initial negotiation and handshaking of secure channels.
We pick RSA because it is well known in the cryptographic community.
While it has weaknesses, these weaknesses are known.
And that is more important to us than trying out some new cipher.
We investigated elliptic curve cryptography, and we might enable that.
But RSA is a known quantity.
We use 4096-bit keys for the handshaking, so it is very unlikely that you will crack it.
For the synchronous cipher, we ran into issues when we were looking for a synchronous cipher
because many of them had packet problems and packet implementation or copyright problems.
But we found one that we like, and it is ISAC.
It is a synchronous cipher used for console and drone communication, the actual communication itself.
Once the synchronous keys are changed, the stream cipher is one byte at a time.
It is very fast and very safe.
And one of the nice things is we can use a large key, 182-bit, because ISAC does not penalize you for stealing the key.
We could use a 16-bit key, a 32-bit key, and it would make no difference.
To computational performance.
Now, along with the good, we will be remiss as security researchers that we need to talk about the bad things about our proof of concept,
and that is entropy generation.
It is essential to good cryptographic security.
The problem is it uses OS facilities for entropy.
The pseudorandom number generator in many operating systems are not very good at all.
But on unit machines, we use devurandom.
How good it is depends on the unit's derivative.
OpenBSD, not surprisingly, is very good.
We use Windows 2000, and HP has a very good cryptographic library.
And because we use the OS facilities as a possible avenue of attack.
We will probably investigate this in more detail.
The cryptography library we're using, LibTomCrypt, has some entropy generation functions, but they are too slow.
When we tested it, it took two minutes to generate entropy.
Mosquito is divided into several components.
We got the core, which provides the basic functionality required by a drone and console.
A drone provides a remote process that contacts a matched console.
And to execute scripts and commands that the console sends to it over the secure channel.
A console provides a local process that controls the deployed drone.
One of the neat features that we put in Mosquito is transport.
And it's an abstracted way to connect the drone and the console.
I'll talk about that more in a bit.
Let's talk about core.
Core is really nothing more than an augmented neural interpreter extended with the following functionalities.
We have RSA encryption functions, ISAC encryption functions, networking functions, entropy gathering functions, and structured buffered functions.
The drone is the Mosquito component that is deployed onto the target machine.
It integrates the core with drone-only functionality, meaning it's a superset of the core.
It executes Lua code sent by secured communication.
And Lua code sent by the console is stored only in process memory.
It is not stored on a disk.
The console is the Mosquito component that provides a local process that controls the deployed drone.
It integrates the core with console-only functionality. It's a superset of the core.
The user uploads code to the drone by secured communication.
And even more neat is the user can also interact with the drone in real time.
We can interact with the Lua interpreter remotely.
So you can do debugging and you can do code on the fly on the drone.
Transport is an abstract functionality for the console and the drone to communicate with each other.
It transparently negotiates a communication channel between the drone and the console and provides a read and write method.
And read and write are separate.
And it's really neat because we can do different transport methods for different channels.
We have HTTP transport which is implemented by default.
But we have skeleton code to implement DNS transport, ICOMP transport, UDP transport, HTTP transport.
So if you could send HTTP in the pacifier wall but you can only go out by ICOMP, you can do that.
You can send a message by HTTP and go out by ICOMP.
You can mix and match however you want.
Affiliation is handshaking.
It's a process of identifying endpoints as valid to each other that they are who they are.
And it sends a passphrase to each other.
So unless somebody gets a hold of a drone, it's very hard to intercept.
And during the handshaking, they are changing synchronous keys for ISAC.
This is the outline of the flow of console affiliation.
We have...
When console affiliation begins, it starts and waits for the drone to contact it.
And if it times out, we actually have a timeout feature because we don't want it to go for too long
where other people may intercept the drone and modify it and then do whatever evil things they want to do with it.
So we would have maybe a one-minute timeout or a 30-second timeout.
And we have a drone in a secret mattress.
It generates the key to send to the drone.
And that's the key that the drone is going to use to send to the console.
And then we got the console affiliation mode.
The drone mode is a little more simple.
It generates the key.
It sends its handshake to the console.
And in that affiliation, it sends its key.
And then it awaits the response from the console.
If it times out, the poop is gone.
And then if the console sequence matches, then it enters operation mode
where the console can send Lua commands to the drone.
One of the neatest things about Mosquito is the build environment.
The virtual machine is statically linked for easy deployment in a project.
It's to ensure that all libraries that are needed to function are available.
Gloob is a deep Lua script.
It takes the executable file, the stub, with the binary C code functions
like the virtual machine, the interpreter, the socket library, the cryptography library.
And then it will attach the scripts in bytecode format to the end of the executable.
And when the executable runs, it will go through the bytecode
and have all the functions defined in the payload.
So there's two ways to get code in the drone.
One is to embed it in the drone, and the other is to send it over the network.
So if you have library functions that you're not concerned about,
you can put it in the drone itself and have them available for all penetration tests.
But then you can have exploit functions used for library code.
Now, we have some ways to attack Mosquito.
We have introspective debugging.
If somebody is sitting on the machine with sharp eyes, there's not much we can do about it.
As I've discussed, they use entropy attacks.
And if you are fast enough, you can modify the drone binary itself before it's invoked.
But you have to be very, very quick, because the interval between the drone being deployed and being invoked is very short.
Two, three, four seconds at most.
And, of course, there's always cryptography attacks, known test attacks.
There are some neat uses of the framework.
As is, we can refactor exploits into Lua for security deployment on the target.
It is easily extensible.
Additional cryptographic methods are transformed.
We can write port scan code.
We can write SMB scan code and deploy it on the drone.
So if you deploy the drone, you have all your exploit code, all your functionalities there.
It will also simplify the deployment of auditing tools if you have one VM for all the platforms you attack.
All the dependencies are included with the drone.
When we deploy a drone, we have functions that will detect the target architecture.
Look in the stub library of executables.
We have a Win32 executable, we have a Darwin executable, and then we have an OpenBSD executable.
It will detect that, take the stub, latch on all the Lua library code you want, and on the fly stream it to be deployed.
That's one of the neat things we can use with Glue, because not only is Glue a script, it's also a library function in Mosquito.
We have some future ideas that we could use.
One of the neatest ideas would be an integral high-speed packet snipper and generation in the drone.
That would be great for port scanning or listening to traffic and interpreting the traffic.
One thing that we wanted to do, but weren't able to do yet, was drone-to-drone relay.
You've got the console, you've got the drone, and then you've got another drone.
And the communication is relayed through the drones as many times as you want.
But at no time does any of the drones in between know what's happening at the endpoint drone.
Because we've got nested encryption.
When you've got the endpoint drone sending a... it's got its own key that only the console knows, it's passed and encrypted again and passed and encrypted again.
Remember, ISAT has no penalty.
So you can nest it as many times as you want.
And we would like to do further refinement of the automated configuration and drone console pairs.
And consoles that can manage multiple drones. Right now we can only manage one drone.
Who are we? Got work for us?
I'm Wes Brown. I'm a security consultant and security researcher.
And Scott Dunlop is a software engineer and security researcher.
He's more of a software engineer while I'm more of a consultant type.
We are available in activity-seeking work. Wes is particularly interested in full-time employment as a security researcher.
We have a website, fmosecurity.com.
Worldwideweb.fmosecurity.com if you want more information.
Got any questions?
Tomorrow we will be putting the entire framework code on SourceForge.
It is under the BSD license. Feel free to do whatever you want with it.
And that's it.
Scott will be taking the questions because I'm deaf and I can't hear the audience.
We didn't bring any binoculars so we could lip-read.
Yes?
The 0.2 footprint was about 160k. We hadn't done any optimizations with the C compiler flags.
We were hoping to target for about 80 to 90k.
We were encountering some problems with the fact that we have to bundle most of our dependencies with the actual drone.
We're not making any assumptions about availability of things.
We're just assuming standard C live in the case of Win32, you know, the standard DLLs.
The current 0.3 is a little bit heftier because we put in live TomCrypt.
And a lot of TomCrypt is very easy to strip down. We just haven't had a chance to do it.
Sure.
We are supplying a general purpose socket library called LuaSocket.
It's not quite performing up to the standard that we'd like, but the goal was to provide the ability to do further network penetration and auditing from the drone.
Very often in audit you have a situation where you've managed to breach an edge system and you need to get deeper in now that you're past the firewall.
And to see where you can go once you've gotten into the bastion.
And that was kind of the purpose of the drone.
Yes.
We certainly kicked around the idea of abusing some of the DRM APIs in Windows XP.
Unfortunately most Unixes don't provide these.
OpenBSD does provide some functionality for preventing writing into swap space.
But that is one of our more major vulnerabilities.
This is a possibility of later analysis of the swap file.
Unfortunately I don't have a console running on Win32. I haven't linked one.
I've got the Macs, but they're not cooperating with the projector today.
It's very embarrassing.
Oh, I'm sorry. Yes.
We are relying on libtomcrypt, which is fairly simple. It's configurable and can be stripped down.
And of course Lua, as you mentioned.
And our only other major dependencies have been just Lua extensions.
The stuff that we've added in, structure buffer and everything else, are actually pretty simple.
If there are buffer overfunds in Lua, that is a problem.
However, the way the construction works...
Once the drone has been deployed, there's a fixed window which is configurable of how long the drone has to contact the console.
The first one to contact and correctly complete affiliation within that window basically gets the connection.
After that, we drop the listen socket and basically we just run with that one transport until it dies.
So buffer overrun exposure is pretty minimal.
As you mentioned, there's always a possibility of someone trying to respond before the affiliation goes through.
But unless there's some kind of very specialized IDS, I don't see that happening.
We were investigating how to deploy this by shellcode.
And if we can do this, then we would have no drone in the file system at all to intercept.
It would be in the process memory of whatever program we buffer overran.
Any other questions?
I've got to cover for a time not having a demo.
Well, you're always free to email the questions to the address over there.
And of course, the code itself will be available for your inspection tomorrow at SourceForge.
We will deploy it to SourceForge.
Well, once you put something on SourceForge, barring intervention by lawyers, it's there pretty much permanently.
Matter of fact, their policies are pretty strict about not taking something back out in the public domain once you put it there.
So once it's there, it's there.
Yes?
It really depends on public interest. I don't have an active use for Mosquito, Wes does.
It was basically my entertainment here was just getting it out in the open and just basically I wanted to see what everybody thought of the idea and the actual algorithm.
Wes, of course, considers it a more usable tool because it's more in his line.
Is that all?
I guess.
Thank you for the loan for the laptop.
Thank you for the patience.