D-Link Embedded Device Shells

This week, esteemed Metasploit contributor @m-1-k-3 has been at it again with his valiant personal crusade against insecure SOHO (small office/home office) embedded devices with known vulnerabilities. We have a new trio of modules that target D-Link gear, based on the research released by Craig Heffner and Zachary Cutlip, which exploit two bugs present in the DSP-W215 Smart Plug, and one UPnP command injection bug found in the DIR-815.

The research on these embedded devices is really quite solid -- if you're at all interested in this kind of research, you can Craig's excellent notes on his first and second SmartPlug bugs, published in May of 2014, and Zachary's notes on the DIR-815 bug. Following along is now a ton easier with m-1-k-3's Metasploitization of these exploits, too, since you can now see the traffic on the wire if you happen to have one of these routers in your home or lab.

This is the part where I rail about the Internet-of-Things. I'll keep beating this drum because it's not "merely" your home networks that are at risk. If the gadgets are cool and useful enough, you can be sure they will find their way into office spaces across all kinds of industries, making the job of the penetration tester less of an exercise in finding vulnerable devices to target and more of prioritizing which ones should get exploited first.

Nobody updates firmware, ever. Nobody.  As long as they're passing packets, and there's no IT department control over these things, these guys will remain vulnerable forever -- at least, until something radical changes in the embedded device space where updates are automatic and routine -- and don't fall prey to Evilgrade-like attacks, which have been around for a few years now.

Rubocop

Back in Metasploit developer land, we've had some good discussion this week on how to nudge the quality of code we get from our beloved contributors up the maintainability scale. Rapid7's Jon Hart suggested, and then promptly implemented, some hooks to Rubocop, a style-checker based on the well-regarded Ruby Style Guide by Bozhidar Batsov and friends.

So, as of now, default runs of msftidy.rb will include a Rubocop check. The best part of Rubocop is that it can allow for some level of automatic code fix ups, if you launch it with the -a argument. While we don't want to fix your code out from under you, you can at least get a sense of your style guide conformance if you hook up msftidy to your own local git pre-commit hook.

It's important to make clear that style is kind of important for maintainability. If you're involved in an open source endevor and you have more than one contributor to your code base, having multiple, personal styles is not only difficult to read in any sane development environment, but makes the likelihood of logic bugs creeping into your code much, much higher. Please believe me, we're not trying to make Metasploit contribution less fun by sticking to reasonable standard coding practices -- we're trying to make the code base, as a whole, more accessible, more reliable, and as bug free as we possibly can.

You can see rubocop -a in action over on Pull Request #3543, where we apply some automatic fixes on the tried-and-true MS08-067 module. Keep in mind we're still experimenting here -- if you have a module that doesn't hit the style guide 100%, we're not going to hold it against you, and won't block commits because of it. Hopefully, though, this kind of automatic syntax checking will go a long way to shoveling more awesome into Metasploit faster.

New Modules

As reviewed above, we have three new exploits, all D-Link, and one new auxiliary module, which targets Michele Spagnuolo's Rosetta Flash vulnerability, CVE-2014-4671.

Exploit modules

Auxiliary and post modules

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