C:\> scancsrf.exe

By Puck Meerburg

Those who don’t learn from history are doomed to repeat it. Over, and over, and over, and over, and over (At this point I got bored looking. Wait! I just found another one! This one in the US!)

TL;DR: →Press clicky; check vulnerability

So, what’s going on?

A while back, on *checks email chain* 15 December 2015, I sent a mail to Ziggo’s security address. This contained a set of multiple vulnerabilities, only one of which is critical enough (and might be already exploited in the wild!) that I am going to highlight it.

Ziggo has, in their time, deployed multiple models of routers. Eventually, our household got sent their newest Wifi router/modem, which they were phasing in at that point. This modem was a Ubee EVW3200, and I suspect that the largest group of Ziggo users (that haven’t been migrated from UPC) have this router/modem combo.

So, after a while, I started poking around and found an issue that allowed practically any web page to authenticate with this device and send it commands. This is due the modem using a static default username/password combination; Practically everyone remembers ziggo/draadloos, the default user/password combination on these devices. So, what can I do with this? … Everything.

  • I can change your DNS settings
  • I can set up a (secure :)) VPN tunnel to my own IP. With this I can basically ‘merge’ into the internal network, allowing me to poke at all the devices you have connected (and view the router settings!)
  • I can (using another redacted trick) set the modem to broadcast another network, which has been set up with SSID and password of (my) choice.
  • I can change port forwards

So, I can change everything that you, as user, can change too. Yay. And the worst part? This could be happening to you, right now, without you knowing! (don’t worry, I am not that evil… yet)

Oh no! How do I fix it?

You can’t. It’s a bug in the firmware, and I assume it’s also a bug in Broadcom’s reference firmware, as the EVW3200 makes a lot of use of it, including the web server system (recognizable by /goform/).

Oh no! How do I avoid this happening to me?

Better question, because yes! There are ways to avoid being hit by this issue:

  1. Change default username and password to something else

    When you do this, people won’t be able to just use ziggo/draadloos to log in, and it will not be worth it to crack it (as you have no feedback that a login succeeds)

There is a disadvantage, because the login mechanism in the modem is a bit wonky, and the logout button is very well hidden. It remembers you are logged in based on your IP, and not cookies or other mechanism, so login sessions survive multiple reboots, other browsers, and even a full reinstall of your operating system. This makes it easier for attackers to change the settings on your modem.

More technical stuff

Basically, this is just your plain old CSRF attack. It’s not anything special, although of course it’s easy to deploy the exploit in a targeted way (based on Ziggo IP ranges), and it’s not that difficult to pull off. I’m not even the first one to publish it, see this. Of course, this isn’t all, as there’s enough persistent XSSes to find. I’m not even going to name them, as basically any field is a XSS vector. There’s a few fun ones, but figure them out yourself :)

If anyone has any clues on the format that GatewaySettings.bin is in, please contact me, via Twitter, Freenode, or just mail, via puck@puckipedia.com or puckipedia.

Intermission

I reported this on 15 December of 2015, and as of now (25-04-2016, including a month break) there hasn’t been any satisfactionary result on basically any of the vulnerabilities I’ve mentioned. The last response I got was April 4, 2016, which said “We will look at it”. So, I’ve given up on Ziggo actually properly responding, and I feel like they need to fix this, and fast. I’ve given them 5 months of time to fix it, which should be waaay more than required to at least say “We figured out how to fix it, but it’ll take a year.” That’d still be unacceptable, but at least I wouldn’t decide to post this blogpost. So, instead of waiting responsibly, I decided to waste my time and write a webpage that checks for this issue in the most humorous way possible (incidentally also the most useless). I do think that this issue should have never existed in the first place, and as these issues have come up so often before, do I really bring something special up? I really don’t know, but it’s plain irresponsible of Ziggo to not respond. I mean, Daalder was fixed literally the next day and KPN has acknowledged the (pretty large) issue I sent and fixed them well within two weeks! (at least, I didn’t check yet…) Ziggo hasn’t even acknowledged to me that the issue exists, just that “they are looking into it”, after I sent a full set of files that exploit not only that, but another issue, to run javascript when visiting the router page. I know bureaucracy is slow, but come on, I’ve been waiting on this for more than a month! That’s just plain unacceptable.

(While we’re on the subject, it’s interesting how Ziggo has decided to stop Bapp basically a few weeks after I posted my blog post. I bet they went “Wait, do we have this? Huh, that’s weird.”)