UniBot, a recipe for disaster

Guest Post By SexyKambingz

First of all, if you have no idea what UniFi is, click the image below.

We’ve noticed a couple of flaws in TM’s implementation of UniFi ever since it rolled out. One flaw being that the technicians will ALWAYS enable remote management. RuFI0 noticed this when the technicians installed UniFi at his place during the first roll out (and he quickly patched it :p). According to them, it’s to make it easier for them to troubleshoot problems remotely. Actually, we’ve realized that a lot of other UniFi customers are aware of this and that this had been reported to the folks at UniFi numerous times, but yet here we are. We’ve seen forum threads about this dating back since May of 2010. Another interesting find was by rizvanrp that besides the usual admin account on the router that is usually the so called “root” account, there is actually another hidden account with higher privileges. But how would one go about in finding this mythical hidden all powerful account?


Of course, this is a rebranded D-Link DIR-615 with custom firmware by the folks at TM. So don’t expect to see the same html comment in any normal DIR-615. Now i’m pretty sure you’ll be asking “so yeah, you have the username but you don’t have the password. This is bull!”. Yeah well, rizvanrp also discovered that one can actually download the router’s config file without authenticating with the router. We couldn’t find any advisories on this but we’re not surprised since it is custom firmware by TM. We consider his discovery as a 0day.

When UniFi first rolled out, the routers came with firmware 7.05. According to rizvanrp’s website (which is specifically focused on UniFi btw), the folks at UniFi had rolled out a new firmware upgrade, 7.05B. However, this DID NOT fix the authentication bypass bug.

So being bored with nothing to do, we took up the challenge of writing a PoC. Don’t really expect much from it though (that’s right skidies, weep!). All the PoC does is download the router config, decrypts and prints it out. Everything you need/want to know is inside the router config. So back to the operator password, it’s actually in the router config. We of course have a much more awesome script that we use to implement our theories (refer below) on RuFI0′s router.

Once we were done with the PoC, we decided to do some research and see just how many routers/accounts this flaw would affect by exploiting this flaw. We created another script to run tests on the whole UniFi IP address range. Nothing fancy. It just checks if the config file is downloadable. In 2 days we managed to find more than 7.6k vulnerable routers. That’s 7600++ home and business users in only 2 days. On day 3 the total number of routers we found vulnerable topped 11k. Now just think of all the fun and malicious things you can do with this. 11k accounts just waiting there be snatched. But wait! There’s more!

You can do a lot more damage then merely stealing other peoples’ accounts. You can even whip out a simple script that’ll backdoor the routers by enabling the built-in ssh server. An automated script that does all of this is something easy to do and not exactly rocket science. From our research, we found out that one could even turn all the affected UniFi routers into a botnet. To make the attack even more complex, you could also launch attacks into the internal network remotely from outside (which is highly posible). All it takes is a script that reads the dhcp table for a list of internal users then does the necessary port forwarding or put the target into the DMZ.

Among other things, just like Streamyx, UniFi also uses the same operator password (or same password pattern) for all UniFi routers. Also, rolling out with a flawed router doesn’t really help :p

Here’s a list of all the scenarios we tested for:

[table id=8 /]

This issue had been reported countless times and months back and yet it’s been ignored for quite some time now. So by writing this blog post and working hard on pulling off neat yet serious hacks, we’d hope it would make a huge enough impact for the folks at UniFi to take this seriously. We think that protecting the customers should be a priority. We’re pretty sure that they themselves would say the same thing.

* UPDATE* (9/11/2010)

We’ve realized that UniFi has started rolling out fixes the following day after we disclosed this information to them. They fixed it by disabling the remote management port on the public facing side of the router. They also patched up the authentication bypass for the config file. Good job guys. They’re also working on patching up more problems, both security and performance.

A Temporary Solution!

We think that rizvanrp has done a really good job at documenting this. It doesn’t exactly fixes the flaw per say but it does help in preventing remote attacks. We highly encourage UniFi clients to check out his page on how to fix this issue and read more about his findings.


Also, like we mentioned in an update earlier (refer to above text), they are pushing new updates to customers and might offer the new firmware for download on UniFi’s website. So if you can’t wait for the “push”, you may grab the firmware and manually update the router yourself once it’s up.

* UPDATE* (8/11/2010)

Sorry folks! It seems that we can’t release the poc.

A few other blog posts that mentioned this problem:

There’s a lot more actually if you google around for them.


Post a Comment