Last updated at Mon, 28 Aug 2017 15:11:22 GMT
Nginx Exploit for CVE-2013-2028
The most exciting element of this week's update is the new exploit for Nginx which exercises the vulnerability described by CVE-2013-2028. The Metasploit module was written by Metasploit community contributors hal and saelo, and exploits Greg McManus's bug across a bunch of versions on a few pre-compiled Linux targets. We don't often come across remote, server-side stack buffer overflows in popular software, so when we do, it's kind of a big deal. This is a big deal vulnerability, and hopefully, Internet-facing ops guys all over the world have already fallen all over themselves to fix this.
And yet, recall Jeff Jarmoc's recent findings on the Rails vulnerability, where this critical, remote code execution vulnerability continues to be exploited the wild, five months after disclosure. Now, apply that to what's likely going to happen with this bug, a mere three weeks out from disclosure. Yeah, it's not pretty.
If you're running Nginx, and you haven't applied the patch or the workaround, you are asking for trouble. If you think you've applied the patch or the workaround, or if you don't know if you're running vulnerable version of Nginx or not, you can check your defensive posture with this Metasploit module.
Jettisoning old tests
The update this week also brings a slightly slimmed down version of Metasploit. Way back when, we shipped a couple hundred "unit tests" to exercise some core functionality. While it's true that these testing scripts used the default 'test/unit' library that ships with Ruby, we have since moved on to more complete, thorough testing using Rspec and running every commit through Travis-CI. Also, these old tests haven't been touched, literally, this decade, so bitrot has set in pretty hard. Few of these tests still work, so it was best to just toss them and move on with rspec.
If you're of a mind to fix or extend core Metasploit functionality, when you write your fix, it would be delightful if you paid attention to the spec/ subdirectory. You can learn a lot from the several hundred example tests that are already there. Being able to prove that your patch actually fixes the problem described makes reviewing your pull request move along much, much faster. Tests can also do double duty as documentation of what you're expecting to happen.
In fact, if you were to write fixes and features following TDD (test-driven design), you'd do something like this:
- Write an rspec test that fails, because it's hitting a bug or exercising an unwritten feature. Commit that.
- Write your fix or feature.
- Run your rspec test again, and see it succeed. Do a little dance and commit that, and send up a pull request.
You will probably uncover more of your feature or fix as you're writing; that's okay, just add another test before you start writing a fix. In this day and age of split windows and featureful IDEs, there's really no reason to avoid this kind of back-and-forth development.
If you want to recover the old tests, it's as simple as checking out Metasploit Framework's unstable branch on GitHub, and running a quick
find . -name *\.u[ts]\.rb
to locate them. About the only reason I can think of to do this is to port the tests that (used to) cover some core Rex, Railgun, and Meterpreter functionality. In fact, doing just that would make a fine summer past time for you infosec kids who are off for the next couple months.
Testing Metasploit modules is a little different. Ask anyone who knows Ruby pretty well, and they'll agree that Metasploit modules are a little... weird. They also tend to require some very specific, not-very-mockable environmental elements (like functional targets configured with specific vulnerabilities), so the usual rspec route doesn't work out too well with them. We're working on open sourcing some of our QA practices on how to test those as well, though, so stay tuned and keep an eye on the test/modules directory. A bunch of excitement should be landing there soon.
In addition to the Nginx vulnerabilitu, we've got new modules for Firefox, IBM SPSS, and Adobe Reader.
- Nginx HTTP Server 1.3.9-1.4.0 Chunked Encoding Stack Buffer Overflow by Greg MacManus, hal, and saelo exploits CVE-2013-2028
- Firefox 17.0.1 Flash Privileged Code Injection by sinn3r, Marius Mlynski, and joev exploits CVE-2013-0757
- IBM SPSS SamplePower C1Tab ActiveX Heap Overflow by juan vazquez and Alexander Gavrun exploits CVE-2012-5946
- AdobeCollabSync Buffer Overflow Adobe Reader X Sandbox Bypass by juan vazquez and Felipe Andres Manzano exploits CVE-2013-2730
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.