UniFi – “Jack” and my VOIP Phone Line
Most of us keep our house keys to ourselves.
But in some buildings, the superintendent/maintenance manager keeps a copy of the keys to each house. This is useful when you need things fixed when you are not at home, or when there are there are emergencies, and it is essential to be able to enter your house. It’s a trade-off but many are willing to give up some privacy for safety and convenience.
But what happens when the superintendent changes all the locks so that every house can be opened with the same key? You may trust the superintendent, but do you trust your neighbor? What about the guy down the road? And that shady looking fellow who lives at the other end? Care to let him into your house at any time?
Data corruption issues aside, my TM UniFi phone line has been offline the last few days. When you pick it up there is just a busy tone, and you can’t dial in from outside. When I compare the photos I took of the fiber unit, it seems the VOIP (Voice Over IP) that should be on is now off. I still have my telekom copper phone line, so it’s not that big of a service disruption.
Browsing the LowYat.net UniFi forum, it seems I was not the only one facing this problem; many others had lost their phone line at about the same time as me. “TM UniFi doing maintenance”, or “some outage somewhere” were put up as the likely reasons. This is new technology, and let’s face it: we early adopters are the (paying!) guinea pigs. We knew this is just being rolled out, and so expect and understand that both us and TM are learning as we go along. Even JARING dial-up had its fair share hiccups in the early days.
I was actually wondering if it was worth reporting the problem, with so many people facing issues, it’s unlikely that it’s not something wrong in my house itself, most likely some thing central that affects many users. So hopefully when TM fixes that, my line will just magically work again. Well, that’s the logic we used when our TNB supply goes out, if it’s many houses, just wait, if it’s just yours, call them up.
One LYN user did report the problem to TM. The engineers came over within 24 hours, and found that the settings in his BTU unit (the box that supplies the phone service) was wrong. So they changed it, and the he got his phone line back.
Then things started getting interesting. Another LYN users (who had the login id and password for his BTU) took a peek inside his BTU, and noticed that the number inside was different too. He changed it to the correct number, and his phone line came back!
One by one other LYN users checked their BTU units, found their phone numbers or settings were changed or the settings different, and got their phones back by setting the correct number.
Well joy at solving the problem soon turned into anger as people started wondering how it could change in the first place? Occasionally, an engineer will forget to “save” the settings in a unit, and so the next time it powers on, things revert to their previous settings. But there were too many instances of this happening for that to be the case.
It appears likely that someone had made changes to the BTU in these people’s homes. How could they do that? Well, for one, the login and password to all the BTU units are standard … this makes it easy for TM’s maintenance staff to quickly get to work when they are at your premises, without having to ask you for details (trust me, asking your aunty and uncle type customer this kind of thing can delay you for hours).
Secondly, the BTU has remote maintenance enabled by default. This allows TM to diagnose or re-configure your BTU’s settings without even having to go to your house. It’s very useful to have this kind of capability, they can respond to your issues faster, and they can also deal with more cases in day than if they had to mobilize people to go from one place to the next.
Both of those are valid and reasonable approaches to maintenance on their own. But combined together, it creates a big security nightmare. Why? Because with everything sitting on a network, it’s not just TM who can gain access to your BTU, but so can anybody else with the right skills who knows the common login id password. And with hundreds of TM installers, and even more tech-savvy users, the whole idea of “let’s keep this secret and everything will be fine” … is rather lacking in wisdom.
Now what’s the big deal? So some prankster has knocked out a number of phones. Ha ha, great joke right? Well, I’m a bit more concerned than that. In the (really) old days, TM would know who made which call based on which physical wire it came on.
In the VOIP world however, communications goes over a network … everyone sharing the same lines and wires. To identify callers, each phone would have some unique identifier (phone number +authentication key) so that TM’s exchange can authenticate it, and know who to bill for the calls.
What if you could change your phone identity to someone else’s? Well, whatever calls you made, would appear on the other person’s bill.
When I was in school, someone tapped the phone line near the window as it went into our computer lab and made some international calls. These days, with the phone number + authentication key, they don’t have to crawl to the window outside your house, they can be sitting across town, on the same Unifi network, and probably get away with it. If they had access to a lot of VOIP accounts, and were smart about it, they could get away with a lot of calls without being noticed. After all, do you check every single line of your bill?
So now … I wonder … by the fact that someone has gotten in my BTU and fiddled with things … will I see anything interesting in my phone bill later this year? And what happens then? Who is responsible for it?
We live in interesting times.
So … I decided to just poke my nose around my own BTU a bit, and see what is there to be seen.Connected my laptop with a LAN cable to LAN Port 3 on the BTU (any one will do)Set my laptop IP to 192.168.100.20Open browser to http://192.168.100.1Login with the most ridiculously obvious id and password ever. I won’t write it here, but it’s pretty much public knowledge anyway. Get in touch with me if you need it for some valid purpose.
Made a backup of the settings, so i can undo anything I screwed up.
Took a look at the SIP settings.
My SIP account details were fine, but what’s this second SIP setting for “jack” ? Who the heck is jack? And whose number is that? Unfortunately, i didn’t make a backup of the settings when my phone was working before, so I don’t know if it should be there or not.I decided to try my luck, and unticked to disable the “jack” SIP account, and applied the changes.The VOIP light came on on the BTU, and my dialtone came back. I can now dial in to and out of my VOIP line again!
So … if it works without it, I guess the “jack” SIP account should not be there? I wonder if “jack” is short for “hijack” — possibly what happened to my BTU.
I made another backup copy of the settings, this time of a “known working” configuration. I took a peek at the exported settings file, it’s an XML file, and inside it are the admin passwords and also my SIP account and password details.
If “jack” can set up a SIP account on my BTU, I’m pretty sure he can make a backup of the settings as well, and get access to my SIP account and password. And I assume with that, make calls and have it charged to my phone bill.
So what does one do next? This is pretty techy stuff, and I don’t really fancy dealing with the front line call center staff and say “I want to have my SIP account password changed”. Dealing with streamyx tech support is frustrating enough due to their scripted problem resolution flow, I doubt if the Unifi frontliners have a script for this process yet.
There’s no point too, unless we can permanently secure the id and password for the BTU. I’m not sure if that can be done, or if it should be done by end users — this box should pretty much be under in TM’s zone of control.
Besides, this shouldn’t be just about me … what about all the aunties and uncles out there who don’t even know what SIP is? Should we be worried?
So … how now?
This post was originally published as a Facebook Note at 2010-09-08 01:24:56 +0800.