A backdoor in the firmware of certain D-Link routers could allow an attacker to access and change the device’s settings or to execute arbitrary code. The issue was discovered and publicly reported in a blog post by Craig Heffner, a vulnerability researcher at Tactical Network Solutions. The backdoor enables anyone with the user agent name “xmlset_roodkcableoj28840ybtide” to access the Web-based device settings interface without authentication.
This user agent string is visible in the code, and, when reversed, it reads “edit by 04882 joel backdoor,” suggesting that it was knowingly included in the code by one of the engineers – named Joel, presumably. Heffner speculated that it was included as a workaround solution for an engineer determining how to authorize certain automated services to modify settings as needed.
“My guess is that the developers realized that some programs/services needed to be able to change the device’s settings automatically; realizing that the Web server already had all the code to change these settings, they decided to just send requests to the Web server whenever they needed to change something,” Heffner wrote. “The only problem was that the Web server required a username and password, which the end user could change. Then, in a eureka moment, Joel jumped up and said, ‘Don’t worry, for I have a cunning plan!'”
A malicious party could use the backdoor to perform attacks like changing the DNS servers used by the router to redirect users to certain websites or executing arbitrary code. D-Link announced that it plans to release a fix by the end of October.
An ongoing design challenge
The backdoor is not the first such security incident at D-Link, however, InfoWorld’s Serdar Yegulalp wrote in a recent post. Yegulalp suggested that the existence of a built-in backdoor implies a lax organizational attitude toward security, particularly in light of a string of similar vulnerabilities and vague documentation on fixing errors on the company’s website. Among the ways D-Link might reaffirm its commitment to security would be to use open source firmware components that have been more rigorously tested or to open its code up to third-party code review audits.
A more secure design process that incorporates peer code review can also be a valuable step in improving overall software security. By requiring code reviews, a company can improve the chances that the development team will catch one developer’s quick but flawed workaround or other minor design flaws that ultimately could undermine security.