Rapid7 Blog

Python  

Virtual Machine Automation (vm-automation) repository released

Rapid7 just released a new public repo called vm-automation. The vm-automation repository is a Python library that encapsulates existing methodologies for virtual machine and hypervisor automation and provides a platform-agnostic Python API. Currently, only ESXi and VMWare workstation are supported, but I have high hopes…

Rapid7 just released a new public repo called vm-automation. The vm-automation repository is a Python library that encapsulates existing methodologies for virtual machine and hypervisor automation and provides a platform-agnostic Python API. Currently, only ESXi and VMWare workstation are supported, but I have high hopes we will support other hypervisors in time, and we would love to see contributors come forward and assist in supporting them! That's awesome. I want to get started now! Great! Instructions on how to use the library are here: https://github.com/rapid7/vm-automation Why? The Metasploit team has an embarrassment of riches when it comes to modules and payloads thanks to our amazing community and staff. To give some idea of the embarrassment of riches, feel free to launch msfconsole and check the output: =[ metasploit v4.15.0-dev-7e1b50a ] + -- --=[ 1665 exploits - 953 auxiliary - 294 post ] + -- --=[ 486 payloads - 40 encoders - 9 nops ] + -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ] We have 486 payloads, 1,665 exploits, nearly 1,000 aux modules, and 294 post modules. Additionally, we have 443 super-awesome contributors across the globe sending us modules every single day. All this is impressive, and we are incredibly thankful for everyone's support. At the same time, this is a challenge to test—especially since Microsoft and Linux keep updating things to break our code without warning (don't they know who we are?!). One of the efforts that we are working on is some test automation to help us maintain our modules and payloads—or at least know when things break faster—and to streamline the PR landing process. To do that we made a testing infrastructure that uses virtual and physical machines as attackers and targets; then we launch payloads, scripts, and modules on the virtual machines and track the responses. As we are all lazy, it needed automation, so we looked for a clean, simple way to interact with different kinds of vms that was consistent across hypervisors. In a former life, I was also an instructor and CTF developer; as a result, I know that ability to script vm management tasks makes life much easier for a lot of people beyond the narrow case of module and payload testing in Metasploit, so we split the library for automating vm tasks into a separate repo for anyone to use (and contribute new ideas!). Aren't there already things that do this? Yes...sort of. There are multiple projects out there that exist and give varying amounts of control over vms using lots of different languages. Pyvmomi is one great example; it allows spectacular levels of customization and power over virtual machines that the average CTF-er or tester has absolutely no need to use, while simple tasks like getting a list of snapshots take ~40 lines of code. I certainly do not want to denigrate or disparage Pyvmomi: they provide an awesome API, and I know people who need that level of power over virtual machines, but it is just too powerful and complex for a lot of hobby-level hypervisor scripters. This library wraps a lot of Pyvmomi API calls into simple, comprehensible API calls to support the majority of what most hypervisor script users would need, while abstracting a lot of the complexities in Pyvmomi. Also, Pyvmomi only supports ESXi, and this library leverages Pyvmomi API calls to support ESXi, but then uses VMrun.exe to support VMware workstation. So while much of the underlying code is changing, the functions to interact with vms remain the same across hypervisors, supporting the main goal for this repo: one function call, multiple hypervisors. So what is it you say you do around here? The supported functions are currently limited to those you might want to automate a CTF or test-range: checkTools Returns the state of VMWare tools deleteSnapshot Deletes a given snapshot getArch Returns the vm architecture getFileFromGuest Pulls a file from the virtual machine getSnapshots Updates the vm object's snapshot list attribute getVmIp Updates the vm object's IP address to match the vm getUsername Returns the vm's username isPoweredOff Returns true or false isPoweredOn Returns true or false makeDirOnGuest Creates a directory on the specified vm powerOn Turns on the vm powerOff Turns off the vm revertToSnapshot Reverts the vm to a given snapshot runCmdOnGuest Runs a command or executable on the vm setPassword Updates the password in the vm object setUsername Updates the username in the vm object takeSnapshot Takes a snapshot of the vm updateProcList Updates the process list in the vm object uploadAndRun Uploads a script or executable file and runs it uploadFileToGuest Uploads a file to the vm waitForTask Waits for a given task to complete before allowing continued execution. Most of the API calls can be synchronous or asynchronous. This function allows us to toggle between the two. How are you implementing the functions? The basic layout is this: for each hypervisor (currently two), there are two classes. The first class is the hypervisor class. It contains all the attributes required to make the hypervisor work, like IP address, login information, and vm list. The other class is the vm class with supporting functions and attributes associated with the vms to handle normal vm interactions with snapshots, process lists, IP addresses, and the hypervisor. By overloading the function names across the vm classes, we can interact with any vm exactly the same, regardless of the hypervisor (or type of hypervisor) on which it runs. Moving forward The obvious thing is that we need to support more hypervisors: I would love to support cheaper or free virtualization options like VirtualBox or even Hyper-V. I hope that this library proves as useful to others as it would have been to me over the years. I welcome anyone who would like to contribute, especially if they want to start work on supporting extra hypervisors! It is a relatively simple project. I think if we do it right it will see a lot of use, and we can help a lot of people.

Recent Python Meterpreter Improvements

The Python Meterpreter has received quite a few improvements this year. In order to generate consistent results, we now use the same technique to determine the Windows version in both the Windows and Python instances of Meterpreter. Additionally, the native system language is now populated…

The Python Meterpreter has received quite a few improvements this year. In order to generate consistent results, we now use the same technique to determine the Windows version in both the Windows and Python instances of Meterpreter. Additionally, the native system language is now populated in the output of the sysinfo command. This makes it easier to identify and work with international systems.The largest change to the Python Meterpreter is the addition of Railgun functionality. Railgun - in the context of the Metasploit Framework - refers to a set of features available in the standard API (stdapi) extension of Meterpreter. The intention of the feature set is to allow the Metasploit side to call functions in native libraries on the compromised host. This has some very practical applications when it comes to post exploitation, but is also used in some older local exploit modules. The functionality has been around since 2010, but until recently was only supported by the native Windows Meterpreter.Recent additions to Metasploit are expanding the scope of this functionality to support non-Windows platforms. Specifically, the Python Meterpreter has received support for these Railgun API functions when on the Windows and Linux platforms. Bringing this functionality to the Linux platform will increase what Metasploit users can do with their sessions. To demonstrate the functionality, one of the newest Linux post-exploit modules uses Railgun to call functions in libgnome-keyring.so.0 as the current user. This is then used to enumerate and extract all plaintext passwords that it holds for the user - all without having to write any files to disk.Without Railgun, a common practice to call a native library code would be to upload a precompiled binary to perform the necessary tasks, or upload the source to compile one. Most penetration testers want to avoid writing things to disk for obvious reasons. With expanded Railgun support, uploading files such as these isn't necessary.For more technical details on how the new Python Meterpreter Railgun implementation works, check out this War Room blog post.

The Foam Goes Straight to Your Brain

Yesterday, we announced the availability of a PowerShell extension for Meterpreter, primarily as a toy for laughs because no one would seriously consider using it for anything important. But today? Today we've got a real treat for you. For serious programmers and serious pentesters, what…

Yesterday, we announced the availability of a PowerShell extension for Meterpreter, primarily as a toy for laughs because no one would seriously consider using it for anything important. But today? Today we've got a real treat for you. For serious programmers and serious pentesters, what you really want is a serious language. Something with the power of a Turing Machine and the readability of raw bytecode. Something beautiful and subtle, like a chainsaw. Something with a name you can pronounce in polite company, unlike the crude "Python". You need BF. Today, we landed an incredible tool that will be the benchmark for ease in post-exploitation for years to come. Today, you can run BF inside Meterpreter.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now