The web interface on D-Link DIR-100, DIR-120, DI-624S, DI-524UP, DI-604S, DI-604UP, DI-604+, and TM-G5240 routers; Planex BRL-04R, BRL-04UR, and BRL-04CW routers; and Alpha Networks routers allows remote attackers to bypass authentication and modify settings via an xmlset_roodkcableoj28840ybtide User-Agent HTTP header, as exploited in the wild in October 2013.

**D-Link routers authenticate administrative access using specific User-Agent string**

**Vulnerability Note VU#248083**

Original Release Date: 2013-10-17 | Last Revised: 2014-07-29

**Overview**

Various D-Link routers allow administrative web actions if the HTTP request contains a specific User-Agent string. This backdoor allows an attacker to bypass password authentication and access the router's administrative web interface. Planex and Alpha Networks devices may also be affected.

**Description**

CVE-2013-6026:

According to security researcher Craig Heffner, the firmware for various D-Link routers contains a backdoor that allows unauthenticated remote users to bypass the routers' password authentication mechanism. A router's internal web server will accept and process any HTTP requests that contain the User-Agent string "xmlset\_roodkcableoj28840ybtide" without checking if the connecting host is authenticated.

D-Link has confirmed that the affected D-Link routers disable web configuration from the WAN by default.

According to D-Link, the following D-Link routers are affected:

*   DIR-100
*   DIR-120
*   DI-624S
*   DI-524UP
*   DI-604S
*   DI-604UP
*   DI-604+
*   TM-G5240

  
According to the original vulnerability report, the following Planex routers are likely affected:  

*   BRL-04R
*   BRL-04UR
*   BRL-04CW

  
It appears that Alpha Networks may be the OEM for routers branded by D-Link and Planex (and probably other vendors). It is not clear where in the supply chain the backdoor was added, so routers from any of these vendors may be affected.

CVE-2013-6027:  
A separate stack overflow vulnerability in the management web server has also been reported.

**Impact**

An unauthenticated remote attacker can take any action as an administrator using the remote management web server.

**Solution**

D-Link is maintaining a page to inform users of this issue and provide updates as patches are released.

**Restrict Access**

Restrict access to the administrative web server by disabling remote management features or by blocking HTTP requests on the external WAN interface. The administrative web server may listen on ports 80/tcp or 8080/tcp.

D-Link has confirmed that the affected D-Link routers disable web configuration from the WAN by default. There is some evidence that at least one ISP may have deployed vulnerable routers with the remote WAN management enabled.

**Vendor Information**

Filter by content: Additional information available

 Sort by:

  
**CVSS Metrics**

Group

Score

Vector

Base

8.3

AV:A/AC:L/Au:N/C:C/I:C/A:C

Temporal

7.5

E:F/RL:W/RC:C

Environmental

5.6

CDP:ND/TD:M/CR:ND/IR:ND/AR:ND

  
**References****Acknowledgements**

Thanks to Craig Heffner of /DEV/TTYS0 for reporting this vulnerability.

This document was written by Todd Lewellen.

**Other Information**

**CVE IDs:**

CVE-2013-6026, CVE-2013-6027

**Date Public:**

2013-10-12

**Date First Published:**

2013-10-17

**Date Last Updated:**

2014-07-29 23:29 UTC

**Document Revision:**

34

CVE-2013-6026: CERT/CC Vulnerability Note VU#248083

The NIST SP 800-90A default statement of the Dual Elliptic Curve Deterministic Random Bit Generation (Dual_EC_DRBG) algorithm contains point Q constants with a possible relationship to certain "skeleton key" values, which might allow context-dependent attackers to defeat cryptographic protection mechanisms by leveraging knowledge of those values.  NOTE: this is a preliminary CVE for Dual_EC_DRBG; future research may provide additional details about point Q and associated attacks, and could potentially lead to a RECAST or REJECT of this CVE.

In today’s news of the weird, RSA (a division of EMC) has recommended that developers desist from using the (allegedly) ‘backdoored’ Dual\_EC\_DRBG random number generator — which happens to be the _default_ in RSA’s BSafe cryptographic toolkit. Youch.

In case you’re missing the story here, Dual\_EC\_DRBG (which I wrote about yesterday) is the random number generator voted most likely to be backdoored by the NSA. The story here is that — despite many valid concerns about this generator — RSA went ahead and made it the _default_ generator used for all cryptography in its flagship cryptography library. The implications for RSA and RSA-based products are staggering. In the worst case a modestly bad but _by no means_ worst case, the NSA may be able to intercept SSL/TLS connections made by products implemented with BSafe.

So why would RSA pick Dual\_EC as the default? You got me. Not only is Dual\_EC hilariously slow — which has real performance implications — it was shown to be _a just plain bad random number generator_ all the way back in 2006. By 2007, when Shumow and Ferguson raised the possibility of a backdoor in the specification, no sensible cryptographer would go near the thing.

And the killer is that RSA employs a number of highly distinguished cryptographers! It’s unlikely that they’d all miss the news about Dual\_EC.

We can only speculate about the past. But here in the present we get to watch RSA’s CTO Sam Curry publicly defend RSA’s choices. I sort of feel bad for the guy. But let’s make fun of it anyway.

I’ll take his statement line by line (Sam is the boldface):

> _**“Plenty of other crypto functions (PBKDF2, bcrypt, scrypt) will iterate a hash 1000 times specifically to make it slower.”**_

Password hash functions are built deliberately slow to frustrate dictionary attacks. Making a random number generator slow is just dumb.

> _**At the time, elliptic curves were in vogue**_

Say what?

> _**and hash-based RNG was under scrutiny.**_

Nonsense. A single _obsolete_ hash based generator (FIPS 186) was under scrutiny — and fixed. The NIST SP800-90 draft in which Dual\_EC appeared ALSO provided three perfectly nice non-backdoored generators: two based on hash functions and one based on AES. BSafe even implements some of them. Sam, this statement is just plain misleading.

> _**The hope was that elliptic curve techniques—based as they are on number theory—would not suffer many of the same weaknesses as other techniques (like the FIPS 186 SHA-1 generator) that were seen as negative**_

Dual-EC suffers exactly the same sort of weaknesses as FIPS 186. _Unlike_ the alternative generators in NIST SP800-90 it has a significant bias and really should not be used in production systems. RSA certainly had access to this information after the analyses were published in 2006.

> _**and Dual\_EC\_DRBG was an accepted and publicly scrutinized standard.**_

And every bit of public scrutiny said the same thing: this thing is broken! Grab your children and run away!

> _**SP800-90 (which defines Dual EC DRBG) requires new features like continuous testing of the output, mandatory re-seeding,**_

The exact same can be said for the hash-based and AES-based alternative generators you DIDN’T choose from SP800-90.

> _**optional prediction resistance and the ability to configure for different strengths.**_

So did you take advantage of any of these options as part of the BSafe defaults? Why not? How about the very simple mitigations that NIST added to SP800-90A as a means to remove concerns that the generator might have a backdoor? Anyone?

There’s not too much else to say here. I guess the best way to put it is: this is all part of the process. First you find the disease. Then you see if you can cure it.

**Post navigation**

Tag

#backdoor