http://info@tekcure.com http://info@tekcure.com
As was the case with U-Verse, DirecTV also has wireless cable box options for making installation easier. The Wireless Genie Mini (C41W) cable box pairs with a wireless video bridge to communicate with the main Genie DVR. The wireless video bridge in this case was a Linksys WVBR0-25. I had a bad experience with a wireless video bridge like this in the past, so it seemed like a good place to start looking for problems. I started out by trying to browse to the web server on the device. I expected to find a login page of some sort. What I found instead was a wall of text streaming before my eyes.
Instead of a login prompt or an index page of any kind, I was presented with the output of several diagnostic scripts containing just about everything you could want to know about the bridge, including the WPS pin, connected clients, running processes, and much more. This by itself is pretty bad as far as information disclosure goes, considering there was no authentication needed to get to this information, but I continued looking through it anyway. About halfway down the page, it started spitting out the contents of log files, and while scanning through those I saw something that made me stop dead in my tracks. With teeth clenching and knuckles turning white, I managed to get out a strained “WHAT…IS…THAT??” before attempting to confirm my suspicion.
A few lines in this log file, prepended with sys_cmd, seemed to indicate that they were using my IP address and user-agent in a system command to create an MD5 hash. Ostensibly, this is used as some form of access logging or tracking functionality. The logs showed the exact command that was being run and the subsequent output of that command. The problem here, however, is that users have complete control over what they want to send as a user-agent header. I surmised that if the device isn’t properly sanitizing the user-agent it is given, it would be sending untrusted data directly to the system for execution. There’s no way that could be the case though, right?
Thanks to the verbose logging on this page I could see that changing my user-agent to “; id; uname -a #” had indeed changed the syntax of the command to be executed. The return value also showed the device had happily executed my new commands and executed them as the root user, too! No login prompt. No input sanitization. Very helpful, verbose output. It literally took 30 seconds of looking at this device to find and verify an unauthenticated remote root command injection vulnerability. It was at this point that I became pretty frustrated. The vendors involved here should have had some form of secure development to prevent bugs like this from shipping. More than that, we as security practitioners have failed to affect the changes needed in the industry to prevent these simple yet impactful bugs from reaching unsuspecting consumers. So, once I finally managed to regain my composure, I decided to buy one of these off eBay to tear apart and figure out exactly what was going on.
The device was running a lighttpd web server, and as defined in its configuration file, browsing to the root of the web site would result in /dispatcher.cgi?template=SysInfo.asp being rendered. The SysInfo.asp file was the page responsible for displaying all the diagnostic output I was seeing. It also showed dispatcher.cgi was actually a symbolic link to apply.cgi, which itself is a compiled ARC executable file used as kind of a “do everything” agent for the web server. It was in apply.cgi that I found the actual root cause.
