News - Easy to exploit backdoor found in several D-Link router models

[HEXUS]

D-Link says a fix will be available by the end of October.

Read more.

[Saracen]

Hmmm.

Re: the "advice" from DLink, ....

• Ignore unsolicited emails about security vulnerabilities that prompt you to action. These could allow unauthorised access to your network
• Make sure that your wireless network is secure.
• Disable remote access to your router if it is not required (this is disabled by default).

The first is good, standard advice, but I struggle to see how it helps address a remote-access backdoor.

The second is again good, standard advice, but again, relevant how?

The third, if and I stress IF some other reports on this are accurate, is utterly disingenuous, if not deceitful, because those reports have pointed out that IF you have backdoor access to the router admin panel , you can simply re-enable remote access.

I'm glad I don't have a Dlink router, and certainly not one of the affected models, but if I did, I want clarification on that issue.

But more worryingly, if Dlink have such a security breach in their firmware, then either it was deliberate and authorised, or control over code is pretty poor, and that is inexcusable in a product like this. If a lone programmer can sneak a backdoor in router firmware, what else could a rogue lone wolf sneak a backdoor into? Windows? Firewalls? Your bank's software? Nuclear launch systems? Okay, the last is a tad extreme, maybe, but it does highlight one point I've long believed .... if you want to be sure your systems and data are safe from net intrusion to your network, the ONLY way to do it is to not have a net connection to your network.

And most worryingly of all, if an apparently reputable company like DLink can screw up like this, the rest of us that don't have affected models can't be smug about it, because it may be that other backdoors in other makes (or models) just haven't been spotted yet.

[sula]

If information in article are correct it seems that this backdoor was put there deliberately by a D-Link. I really doubt it was done by some rouge 'lone wolf' programmer from D-Link.

[burble]

The third, if and I stress IF some other reports on this are accurate, is utterly disingenuous, if not deceitful, because those reports have pointed out that IF you have backdoor access to the router admin panel , you can simply re-enable remote access.

But if admin panel access from the WAN interface is disabled, ie, the web daemon isn't listening on 80/tcp on the WAN interface, how can someone get into it to enable it?

[Steve]

I think the assumption is that if remote access is disabled and wifi is secure, then you need to either break the wifi or gain physical network access in order to use the user-agent exploit, after which you can re-enable remote access.

The first bit of advice... you could follow a link that used XSS to then enable remote access on the router.

The second and third are explained in my first paragraph.

Still, here's another reason why Open Source software is good - this would not have slipped past.

Also, poor Joel.

[Saracen]

But if admin panel access from the WAN interface is disabled, ie, the web daemon isn't listening on 80/tcp on the WAN interface, how can someone get into it to enable it?

It all depends how a backdoor works, doesn't it? If the router isn't listening on 80, then fine. But if the code merely dumps anything that arrives on 80, then it could be that the backdoor bypasses that process just as it bypasses username/password routines.

[burble]

It all depends how a backdoor works, doesn't it? If the router isn't listening on 80, then fine. But if the code merely dumps anything that arrives on 80, then it could be that the backdoor bypasses that process just as it bypasses username/password routines.

I'd expect that if WAN access is disabled then the router isn't listening on port 80, but yeah, I hadn't thought about it that way.

[Saracen]

I think the assumption is that if remote access is disabled and wifi is secure, then you need to either break the wifi or gain physical network access in order to use the user-agent exploit, after which you can re-enable remote access.

The first bit of advice... you could follow a link that used XSS to then enable remote access on the router.

....

But that's exactly my point .... it's an assumption . As I said, some other reports suggested, or at least implied, that remote access could be re-enabled. One, and I don't remember which one, implied that Dlink could use it to "update" firmware by re-enabling remote access where it had been disabled. That may well be a mistaken inference, which is why I said I'd want clarification if I owned an affected model. I also note that, so far, this is a lab discovery with no evidence of "in the wild" exploitation. Though, with the publucation of the string, assuming it's both accurate and complete, in the wild attacks now have to be more likely.

And, if that "re-enabling" inference is correct, it also implues that DLink could re-enable remore access, update formware, then disable remote access, all without the owner's permission or even knowledge. And if true, I for one have a problem with that. As I said, clarification us needed. And it should be simple enough for Dlink to state, categorically and explicitly, that disabling remote access ENTIRELY renders this backdoor inoperative .... if indeed, that is the case.

....

Also, poor Joel.

Well, depends. If he put this in without the company's knowledge, then at best it begs questions as to his competence in leaving such a security loophole in in shipping code. It might also raise questions as to his motives. And to company review procedures in not picking it up.

If he did it with authorisation, then he's safe, unless he gets scapegoated, in which case, yes, poor Joel. But unless that's the case, I not only gave no sympathy but he deserves to be fired. This is a security risk that potentially affects any buyer of affected DLink models, and sure as hell damages DLink's reputation. I would think long and hard before buying a DLink router after this, because I'd be wondering what else one of their programmers may have left in.

Discovering a weakness in code that can be exploited is one thing. Building it in deliberately for testing is ojay, provided it's removed in shipping code. But building it in and leaving it in when product ships is inexcusable, IMHO, and either Dlink carry the can for it, or a rogue programmer does. I have no idea which.

....

The first bit of advice... you could follow a link that used XSS to then enable remote access to the router.

The second and third are explained in my first paragraph.

Still, here's another reason why Open Source software is good - this would not have slipped past.

Re: Open Source, agreed.

Re: the email thing, yes, you could. But IF the backdoor allows remote access to be re-enabled, then while an email could enable it, it's not necessary and wouldn't protect the user.


On the second and third being explained, erm, nope. Remember, I was referring to OTHER reports, not yours, that suggested remote access can be re-enabled by this backdoor.

If so, then while securing wifi and locking off remote access are both things any cautious and moderately technical user would do automatically (unless there's a good reason for not doing it), and are both very good advice for anyone not technical enough to do it without needing to be told, neither will prevent the backdoor exploit. But again, I stress IF remote access can be re-enabled. Which is why I said I'd want clarification if I owned DLink routers, though given that my network structure is, to say the least, unusual, I personally wouldn't be much bothered. Any data on my network that is at all sensitive is utterly invulnerable to this kind of backdoor, but I'd bet that very few home networks are organised in a way that guarantees that.

[Saracen]

I'd expect that if WAN access is disabled then the router isn't listening on port 80, but yeah, I hadn't thought about it that way.

Agreed, but what would worry me is "expect" and "assumption".

If, as implied by some other reports, this was a deliberate move to allow easy remote updates of firmware, then at least in some way, and perhaps solely for code accessed via this backdoor, the router would have to be listening .... though not necessarily on 80.

It could, for instance, be listening only on a customised port, specifically to allow normal remote access to be re-enabled .... or disabled. It may also depend on what the backdoir gives access to .... such as a "remote re-enable" switch that may ONLY be accessible via the backdoor, and perhaps not available via the normal router interface. Just how big a backdoor is it? A small hatch, or a double barn door? We don't know.

I don't know if remote access being disabled can be overcome via this backdoor or not, but I can certainly see how it be written so that it does.

[DanceswithUnix]

But more worryingly, if Dlink have such a security breach in their firmware, then either it was deliberate and authorised, or control over code is pretty poor, and that is inexcusable in a product like this. If a lone programmer can sneak a backdoor in router firmware, what else could a rogue lone wolf sneak a backdoor into? Windows? Firewalls? Your bank's software? Nuclear launch systems? Okay, the last is a tad extreme, maybe, but it does highlight one point I've long believed .... if you want to be sure your systems and data are safe from net intrusion to your network, the ONLY way to do it is to not have a net connection to your network.

"Air gap" security is one of those fine ideas that doesn't work in practice. At some point some software needs updating, and a USB stick needs to bridge the gap, and all bets are off. It isn't needed either.

From working on credit card PIN handling software in the past:

1/ All code checkins are broadcast to all the relevant devs so no sneaky checkins are possible.
2/ All checkins are peer reviewed by at least one person.
3/ Entire source tree is regularly audited by an external security auditor.
4/ Development processes are audited by an external auditor.
5/ Release process is entirely automated to guarantee it is built from proper source code.

I think for Windows they skip step 3, I would hope missile launch systems are more stringent.


Is it just me that thinks Joel has been framed here?

An official back door could easily be done using cryptographic challenge/response, preferably using a key derived from a master key, the date that support want access and the product serial number or LAN port MAC address. If this is an official D-link thing, then they really don't know much about security.

If it is a test facility, then it should be de-activated on shipping, the final test being that test mode is removed.

Whilst Open Source isn't a golden bullet against this sort of thing, this is a good advert for OpenWRT.

[Saracen]

"Air gap" security is one of those fine ideas that doesn't work in practice. At some point some software needs updating, and a USB stick needs to bridge the gap, and all bets are off. It isn't needed either.

....

Are you talking general practice, or having quoted me, my claim about "air gap"?

If the latter, it depends what you mean by "doesn't work". My air gap absolutely, categorically, 100% works against intrusion, hackers, or data loss, in terms of losing data to unauthorised users. Why? Because there is no connection, st any time, between machines with my "private" data, and the connected world. Ever.

Nor is a USB stick necessary. That's what write-once media are for, or rather, can do.

Does this prevent virus infection? Not entirely, no, but even in that event, data cannot get out . So, if it happens, that what backups and my own version of a disaster recovery procedure are for.

This doesn't guarantee data safety from virus damage, and it doesn't guarantee resilience (though RAID and a decent backup regime goes as far as reasonable and pragmatic), and it doesn't guarantee physical safety from burglars, fire risk etc, but it DOES ensure no risk from net intrusion, be it remote over the internet, or insecure wifi, because there is no internet connection, nor wifi.

Nor, for the record, am I suggesting that this would be a practical general solution for everyone. But it does work for me.

[DanceswithUnix]

Are you talking general practice, or having quoted me, my claim about "air gap"?

If the latter, it depends what you mean by "doesn't work". My air gap absolutely, categorically, 100% works against intrusion, hackers, or data loss, in terms of losing data to unauthorised users. Why? Because there is no connection, st any time, between machines with my "private" data, and the connected world. Ever.

Nor is a USB stick necessary. That's what write-once media are for, or rather, can do.

Does this prevent virus infection? Not entirely, no, but even in that event, data cannot get out . So, if it happens, that what backups and my own version of a disaster recovery procedure are for.

This doesn't guarantee data safety from virus damage, and it doesn't guarantee resilience (though RAID and a decent backup regime goes as far as reasonable and pragmatic), and it doesn't guarantee physical safety from burglars, fire risk etc, but it DOES ensure no risk from net intrusion, be it remote over the internet, or insecure wifi, because there is no internet connection, nor wifi.

Nor, for the record, am I suggesting that this would be a practical general solution for everyone. But it does work for me.

What you describe is how some external security auditors work. Code is carried over the half metre gap, unzipped onto workstations where it can be analysed, notes written on a piece of paper can be carried back over, all else is shredded. But that is the crux, the auditor almost no information to return to the customer. Most people need more than that from their computers, so they have to interact with the outside world.

Air gaps are useful, but really hard and for most people not worth the effort. Security is always a trade off. I have dual firewalls and wifi in the DMZ in my home network, but only because I find that sort of thing easy and frankly for what little I have worth protecting these days is total overkill.

Stuxnet breached an airgap.

https://www.schneier.com/blog/archiv.../air_gaps.html

Edit to add: Yes I know that data didn't get back out, but it shows that these things are hard to maintain.

[Steve]

You won't even get a TCP connection on port 80 if remote access is disabled, so you can't establish an HTTP session.

So it's a bit more than assumption. It's easy to check if I'm wrong... telnet a vulnerable router on port 80, where remote access is disabled, and if it times out of refuses connection, it's safe.

You can't port knock it like you could with UDP or some other stateless protocol. It'd be funny if there was a port knock to enable port 80 remotely, though.

[Saracen]

What you describe is how some external security auditors work. Code is carried over the half metre gap, unzipped onto workstations where it can be analysed, notes written on a piece of paper can be carried back over, all else is shredded. But that is the crux, the auditor almost no information to return to the customer. Most people need more than that from their computers, so they have to interact with the outside world.

Air gaps are useful, but really hard and for most people not worth the effort. Security is always a trade off. I have dual firewalls and wifi in the DMZ in my home network, but only because I find that sort of thing easy and frankly for what little I have worth protecting these days is total overkill.

Stuxnet breached an airgap.

https://www.schneier.com/blog/archiv.../air_gaps.html

There's no guarantee that an air gap will prevent a breach, necessarily, especially where human factoes are at play, but as I ubserstand the Stuxnet breach, that was more a social engineering breach. And besides, what was the objective of Stuxnet? Getting in, and infecting, or getting data out? Even if a Stuxnet type approach was used to attack my 'secure' network, can you suggest how data gets out? Exactly one person (me) has local access. Well, the wife can get in the room, but can't even log in to that network. The only way data is getting out is if burglars nick hard drives .... encrypted hard drives, I might add. Even if a Stuxnet-type breach succeeds, it might get the virus in, and (as I've already said) could damage it, but it can't get the data out.

As for whether the data is worth protecting, well, that depends on what data we each keep, and how you value it. Without going into full details, I have a document archive system that would be an identity thief's wet dream, with everything from birth and marriage certificates, passport copies, to bank statements, investment records, copies of tax returns, medical data and copies of letters, home inventory records, insurance records, every pay slip I've ever had, and so forth.

I'd agree that most people want more from a PC than you can get without a net connection, too. That's why I have two networks. One is as above, with no connection either to the internet, or to the other network. The other is internet-facing, with wifi, tablets, smart TV, and so forth, but NO access to all the private data on the other network, and little or no sensitive stuff on the net-facing network.

Is this practical for most people? Nope. But most people aren't technology journalists with a dozen or so PCs at home, many of which are old-ish and on that second network. I wouldn't necessarily have bought machines to do that, but I already have them, and they're perfectly functional, though probably so old as to be unsellable. So, it costs me nothing other than space, and that I do have.

[Saracen]

You won't even get a TCP connection on port 80 if remote access is disabled, so you can't establish an HTTP session.

So it's a bit more than assumption. It's easy to check if I'm wrong... telnet a vulnerable router on port 80, where remote access is disabled, and if it times out of refuses connection, it's safe.

You can't port knock it like you could with UDP or some other stateless protocol. It'd be funny if there was a port knock to enable port 80 remotely, though.

The backdoor is written by a firmware programmer seeking to write a backdoor. So it may or may not involve port 80, or an HTTP session. It's perfectly possible to telnet into a variety of ports. Does BackOrifice use port 80? Nope. 31337, IIRC, is common, but it'll work on just about any available port. I cannot see how it is beyond the wit of a firmware developer to have conceivably used a non-standard port, and telnet, to flip a remore-access switch, or even more.

[DanceswithUnix]

The backdoor is written by a firmware programmer seeking to write a bacckdoor. So it may or may not involve port 80, or an HTTP session. It's perfectly possible to telnet into a variety of ports. Does BackOrifice use port 80? Nope. 31337, IIRC, is common, but it'll work on just about any available port. I cannot see how it is beyond the wit of a firmware developer to have conceivably used a non-standard port, and telnet, to flip a remore-access switch, or even more.

Firstly, respect for your airgap. I just couldn't do that, I simply keep that stuff in paper form in filing cabinets. Moving on...


Even not seeking a back door, some companies seem to introduce them.

The previous router I used at home opened an SSH port for admin use. Nice. Now this just gets you some simple proprietary admin commands in a captive command line interface, so I'm sure someone thought it was secure. First command I typed was "ps". Thinking it looked rather linux like, the next command I typed was "px ;/bin/sh" and lo and behold I have a root command line and total access to the internals of the router. I sure hope that is usually disabled on the WAN port, though in my case it was overridden anyway.

It's sad when you have to harden these devices yourself, but sadly that's the world we live in, despite the development processes existing to very much reduce the risk of these things happening.