Skip to main content

3 Years of DirecTV User-Agent Command Injection

I found a bug in one of my DirecTV devices in 2015 after I got DirecTV. DirecTV didn't have a bug bounty program at that time so I used it as a demo in my classes. When AT&T bought DirecTV it then fell under AT&T's bug bounty, which is awarded quarterly. I forgot to submit it in the first post-merger quarger (2015Q4), so I submitted it 2016Q1. Screenshots from the bug bounty submission are at the bottom of this post.

EDIT: I in NO way want to steal the thunder from Ricky Lawshae and or diminish his hard work (although I think we can both agree this is about the lamest work either of use have ever had to do ;) ). My goal is to show how long crappy bugs like this sit.

I got bored a few years ago and decided to see what services the devices in my house expose.  A simple Nmap scan found listening web server on one of the devices. I browsed to it and I see this:

This is one of my DirecTV devices (I have DirecTV, solely so I can watch my precious Green Bay Packers on Sundays. And yes, it was a bad season this year). Scrolling down  further I see the following line (cleaned up for brevity):

local7.notice UTOPIA: config.webui sys_cmd : echo " (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36" | md5sum

If you look closely you see it has echo "USER AGENT" | md5sum which means that if I add a quote to my user agent I can run arbitrary commands on the device. For a quick test, I can fire up Firefox and edit my useragent.

After starting a netcat listener on my system and browsing to the remote system I see the shell come back. I got tired of using the tools on the device so I extracted the contents with netcat and tar for easier analysis on system.

One of the fun things I found was the passphrase for the device.

I performed the same test on another device and the passphrase was different. I spent a little time trying to figure out how the passphrase is generate, but didn't have much luck. I couldn't connect using the passphrase, so my guess is that there is some MAC filtering. We'll come back to that.

You can also take a peak at all the files in the www directory for all kinds of fun files.

If you browse to any of these files you see a login prompt. A simple "admin/admin" and you are in.

... and you can see the wifi settings.

It sure looks like the passphrase is correct. Let's look at the MAC address filtering.

So the connection isn't filtered by the MAC. Just to confirm that I have the correct passphrase, I captured the WPA handshake and cracked it with aircrack.

The WPA passphrase is correct and the interface doesn't show MAC filtering, but I took the MAC address of one of the DirecTV devices and it connected just fine.

So if you can access the device you get permanent access to the internal network. That a little cool.

Honestly, at this point I got distracted with other fun things and never really went back to it. For the past few years I've been using it as an in-class demo of real world command injection via the User-Agent. 

The bug is not really valuable. It is a bad bug on a near zero value device. I've been looking at Google's indexing for years and never found more than a half dozen or so devices indexed. The other attack scenario requires network access to a home user's network. If you are already on that network then there are other higher value targets. I thought about using it to maybe access content on my DirecTV system, but there are much easier ways to watch movies that don't involve "stealing" content from your own device that you pay for... monthly.

I submitted the bug to AT&T/DirecTV in March 2016. I received a follow-up email asking which product it was in to which I described the wireless bridge. I never heard anything back. Below is a screen shot of the email sent from AT&T/DirecTV after I filled in their online bug submission form. The crappy formatting is theirs, not mine.


Popular posts from this blog

Extracting Users from LinkedIn via Burp

We do a lot of pen tests and red teaming at Red Siege. Part of reconnaissance includes gathering a list of employees from a target organization. Typically, those usernames will be used in either phishing or password spray attacks (trying a few passwords across a long list of users). LinkedIn is a treasure trove of information! I'm going to use my good friends at Black Hills Information Security as my guinea pigs (sorry, and thanks!). The tool is here. First, let's look at what the data from LinkedIn looks like a response.

After performing a search for "Black Hills Information Security" we can look at the requests and responses. LinkedIn includes all the user information in responses to "/voyager/api/mux".

We can click the "Next" button a few times in our search to load multiple pages of info. Now, for the extraction. First, select everything in the "HTTP history" with Ctrl+A or Command+A on macOS. Second, right click in the top portion. …

Beyond Net User - Part 1: Limitations of the "Net" commands

I've had a number of cases where the Windows "net user", "net group", and "net localgroup" have failed me. I've had SQLMap fail to give the last line of "net user" output, I've had "net group /domain" not give me the full names (I still don't get how that failed!). On top of that, the commands don't support wildcards. Also, the output of those commands is a pain to parse due to the columns. I'd much prefer to use the AD PowerShell cmdlets, but those aren't always available. I set to find other ways to get the same data. First, let's look at the limitations of the "net" commands.
Net command limitations Hiding Groups in Groups Often when pen testing and red teaming, we would like to figure out information about the domain, most notably the members of the Domain Admins group. Output of the net group "domain admins" command as shown below.

It shows three members: Administrator, sqlagent,…

Beyond Net User - Part 2: DS Commands

In the previous post we discussed some of the limitations of Net commands. Most notably, the output limitation (doesn't show all groups) and it doesn't allow for flexible searching. In this post we'll discuss the DS commands to get around these limitations.
DSGet, DSQuery, DS* While these tools are useful, they aren't always available. As a pen tester and red teamer, I have to live with what I can find on the systems I come across. I find that these tools are still more widespread than the latest PowerShell Active Directory cmdlets, at least on non-system administrator systems. Here is a useful Stack Overflow post on the subject. Recursive Searches In the last post, we discussed a limitation in net group in that it doesn't show groups in other groups. The DS commands do! As a reminder, let's take a look at what we saw with net group when looking at the list of domain administrators.

Now let's do the same search, but use the dsquery and dsget.
dsquery group -…