D-Link router user? Keep your ears and eyes open for the next firmware fixes!

If you’re a D-Link router user, keep your eyes and ears open for the next round of firmware fixes.

The company is apparently scrambling to fix a long-standing bug revealed earlier this month by keen router security researcher Craig of /dev/ttys0.

Unfortunately, it sounds as though the first round of patches for this bug didn’t actually fix the problem, and the next round of patches-to-the-patches aren’t quite ready as we write this.

Of course, even when they are available, many users may be slow to apply them, or even to realise that they’re available.

The bug is caused, quite literally, by three misplaced letters.

The D-Link programmers wrote strstr() where they should have written strcmp().

If that sounds like gobbledegook to you, don’t worry: here’s a quick explanation.

HNAP in brief

D-Link routers support a feature called HNAP (Home Network Administration Protocol), which sounds like exactly what you need to administer a home router.

To prevent just anyone from playing around with the settings on your router, however, you need to authenticate before you use it, meaning that you have to provide a secret password.

Requiring a password is a jolly good idea, because it authorises you to perform HNAP commands such as: SetWanSettings, AddPortMapping, SetWLanRadioSettings, FirmwareUpload and Reboot.

These commands, in order, let you: configure the external network; allow connections into the network from the outside; set up Wi-Fi; and to reconfigure the router completely.

Powerful stuff for an unauthenticated crook, which is why you have to be authenticated first.

Sadly, there is one command that doesn’t requires authentication: GetDeviceSettings.

We say “sadly” because it’s the lines of code that exempt that command from needing the password that contain the bug.

The programmers tried to verify that the command you sent in was exactly GetDeviceSettings.

If it was, then they would skip the password check.

Usually, in C, you check whether two text strings are the same using strcmp(X,Y), short for “string compare of X and Y.”

But the coders wrote strstr(X,Y) instead, which is short for “does string X contain string Y?”

Once they’ve decided whether to require a password or not, the programmers process the command by chopping it off from the end of the HTTP request and deciding what to do based on its text string.

What happens next

You can see what happens next.

You send a command that contains the text GetDeviceSettings, but ends with the text, say, DoSomethingImportant.

The system will let you DoSomethingImportant, but will skip the password check because of the GetDeviceSettings.

If you like, putting the string GetDeviceSettings into the middle of a command is a sort of skeleton key to HNAP.

Command injection

Worse still, you can actually persuade the router to run any Linux system command that you put at the end of the HTTP request, not just commands listed officially in the HNAP specification.

In other words, sticking the string GetDeviceSettings into the middle of a command is a sort of skeleton key to anything and everything on the router.

In penetration testing parlance, that’s known as command injection, for rather obvious reasons.

In the slightly garbled prose [quoted verbatim below] of D-Link’s own security advisory:

An attacker who wishes to gain acces to the router sends an unprivileged HNAP command such as GetDeviceSettings, they append to the command an additional command separated with an "/", which is used as a separator between commands. Any command(s) after the first will be executed unauthenticated. Additionally, additional commands will be passed directly to the underlying Linux system, allowing the injection of arbitrary system commands.

Worst of all, until the patches come out, Craig says that he hasn’t been able to find a way to disable HNAP.

Presuambly, it’s so important for setting up and using your router that turning it off would be like blocking up the fuel filler cap in your car: good for theoretical safety, but not much practical use in real life.

What to do?

• If your router supports it, consider using a community-based open source firmware like OpenWRT.

Like most vendor firmware, the community versions are Linux based, but are generally much more modular, meaning you can leave out parts you don’t need.

• If you don’t want to, or can’t, switch firmware, consider setting up a dedicated network security gateway.

You can use a commercial quality product between your insecure router and your home network to backfill the security you are missing in your SoHo product. Example: Sophos UTM Home Edition, which is is 100% free. (Many routers are also modems, and can’t simply be replaced by a dedicated gateway product.)

• Whatever firmware or router you use, check for and install updates promptly.

Home routers have been plagued over the years by bugs that may open up your entire home network to crooks.

Yet many of us, even if we are quick with Windows or OS X updates, are slow to sort out our routers.

• If you are doing string handling in C, be super-careful when you write your own code.

And be super-scrupulous when you are reviewing other people’s code.

Even severe bugs are often subtle enough that they look correct at first sight.