Request: meterpreter python additional command bindings

[s3c]

Although the python hooks currently support a number of commands, a handful of really useful commands aren't currently supported. The use, upload, download and uuid meterpreter commands come to mind. An example use would be a persistence script, that instead of just using stock methods of persistence, could do things like search for a vulnerable startup method such as a writable path, and upload a bypassed meterpreter dll.

Another would be to automatically start a keyscan and take a screenshot when certain applications were in use. This could be nicely tied in with the AutorunScript command, to automatically capture and report juicy information.

Lastly, with access to the use command a script could first enumerate which applications were installed that had post gather modules, and only these modules could be run to return as much information as possible without having to run each command blindly, or investigating it yourself.

[OJ]

Another set of non-trivial requests! :)

• uuid is a no-brainer, that can be added really easily.
• upload and download aren't so simple and would probably require MSF changes as well. This is because Meterpreter doesn't currently invoke those commands, MSF does. For this to be exposed in the way you want it to MSF would have to expose functionality to make use of such requests from Meterpreter. This concerns me, Meterpreter should not be able to read files from the MSF user's filesystem without authorisation, nor should they be able to download without auth. I think this opens a potential security concern.
• use is never going to be automated from any other extension.
• keyscan stuff is a possibility, but not currently implemented.
• screenshot requires a binary upload that's RDI's into a process. Each time you invoke the command that happens. The only way around this would be to rely on espia, which only needs to be uploaded once.

So yeah, use won't happen, and as far as I'm concerned download and upload won't either unless someone gives me a compelling set of reasons to consider it further that outweigh the technical and security concerns.

[s3c]

The security issue is a really good point, and admittedly stems from my reluctance to learn more ruby. This can always be done through other channels, which is what I'm doing now. Workarounds like these are possible for most of the commands, but I was hoping to rely on existing code that's been throughly tested.