
Hacking the DSP-W215, Again, Again - ehPReth
http://www.devttys0.com/2014/05/hacking-the-dsp-w215-again-again/
======
noonespecial
This firmware is probably no better or worse than what you'd usually find on a
consumer grade router from BestBuy. The difference is that this one controls
AC power!

Hey manufactures: If you think there's nothing more to the Internet of Things
than adding a relay and a power socket to the same insecure schlock you've
been pushing for years, you're about to create a very interesting _(1)_ near-
future for us all.

 _(1) In the Chinese curse
sense:[http://en.wikipedia.org/wiki/May_you_live_in_interesting_tim...](http://en.wikipedia.org/wiki/May_you_live_in_interesting_times*)

------
TorKlingberg
This needs some context. DSP-W215 is a remote controlled power switch with
WiFi.

~~~
0x0
Also, this is the third remote code execution vulnerability blogged in about
as many days. Seems like dlink is having major quality issues with their
software/firmware, which is spooky considering the things the device is
supposed to do (manage power on an AC outlet). They did release a patch for
the first problem but failed to review and fix similar flaws in the
immediately surrounding code.

~~~
michh
I wonder if 3 vulnerabilities in 3 days means this device has exceptionally
bad firmware compared to other similar devices or is just suddenly getting a
lot of attention from skilled hackers.

Guessing by how frail software on these types of devices (routers, access
points, home automation stuff, DSL modems, cable boxes, consumer NAS
enclosures, etc etc) often feels, I fear it's the latter.

~~~
pasbesoin
In my stints doing QA, I've found that developers seldom look beyond the
immediately presented problem/issue, even when that problem makes it apparent
that further review and consideration is warranted if not demanded. [1]

Further, all too often, minimum mitigations -- sometimes, the word "solution"
cannot even be accurately applied to these -- are conceived and implemented.

When you see repeated problems cropping up like this, based upon experience, I
can express the opinion that the organization and/or the individuals involved
are not really paying attention or respecting sufficiently the security
aspects involved.

Hopefully, the repeated bad press will begin to change this. But... those in
the organization responsible for setting or sanctioning such initiative, are
often all-to-well insulated from the immediate "real world".

\--

[1] P.S. I guess I should qualify this to say that I'm speaking of what I
consider to be a typical "corporate" environment. Lots of politics and inertia
and, all too often, "just do what you're told".

------
userbinator
Every time I see these sorts of vulnerabilities I think that these devices are
becoming _far too complex_ for their own good --- in this hacking series I've
already seen mention of:

\- HNAP -> SOAP -> XML

\- HTTP

\- Linux

The first 2 items above are protocols that are primarily text-based and have
no easy way to determine things like lengths. This is bad because it often
causes whoever is writing the code to use an arbitrary length that "will
probably be big enough", and IMHO that is never a good thing, for various
reasons including security.

Making it controlled by a simple, _fixed-length_ (or length-delimited where
absolutely required) binary protocol would've reduced or even eliminated many
of these overflows, because such protocols are far easier to write correct
code for. E.g., if a command is always 8 bytes, then you are always going to
use a buffer of 8 bytes and read 8 bytes. Those that need variable-length data
can prefix the data bytes with a length, and that must always be read first
and acted on, since reading too much or too little just won't work. No need to
parse text lines of arbitrary length, (un)escaping, etc. Each additional layer
of complexity, each step that needs to be done, is an opportunity for bugs to
be introduced.

Also, this is a device that absolutely does not need to be running Linux; its
functionality would probably be achievable with an 8-bit microcontroller and
WiFi module, running none or maybe a minimal realtime OS. Instead of over 4MB
of firmware, a few tens of K would be sufficient. I've seen some very nice and
robust embedded devices, and some that seem more like the developers just took
a standard Linux devboard, put some code on it that looks like it works, then
shipped it. This device is very much one of the latter.

~~~
snops
The CoAP protocol does exactly this and is designed for the exact kind of
restricted requirements you specified. It uses similar concepts to Restful
HTTP to make the transition easier, but uses a binary protocol instead. You
can even get gateways between it and HTTP should you need to use that for some
reason (client side JavaScript etc).

[http://en.wikipedia.org/wiki/Constrained_Application_Protoco...](http://en.wikipedia.org/wiki/Constrained_Application_Protocol)

------
mschuster91
Why do people always implement stuff like this in CGI (C or C++)?

Using nginx+php/perl/python would work just the same and prevent a whole slew
of vulnerabilities in embedded devices, while at the same time reducing
maintenance and development costs.

~~~
bjackman
I agree with the sentiment but running nginx+Python on an embedded MIPS
device? That's getting pretty ridiculous! Better to go the other way (lower-
level), I think.

~~~
michh
I don't think using Python is significantly more ridiculous than the current
practice of either using shell scripts or your own C code to parse form-data
and generate HTML. In fact, it's probably a lot less ridiculous.

------
db48x
And the software is probably no worse than average quality for an appliance.

