Just last week, we talked in the Naked Security podcast about what you can do if you’re stuck with a router with security holes that you can’t easily fix.
One way this can happen is if your ISP won’t let you connect at your end unless you use a router provided by them.
These “forced routers” are typically locked down so you can’t update them yourself, and may even have remote access permanently enabled so that your ISP can wander in at will.
Our recommendation, when you’re faced with someone else’s router in your own home, is simply to treat it as if it were miles away at the other end of your phone line or cable connection, back in the ISP’s data centre or the phone company’s local exchange where you can’t see it.
Buy a second router (or get yourself the free Sophos XG Firewall Home Edition), plug the ISP’s router LAN (internal) port into the WAN (external) port of the device you look after yourself, and pretend the ISP’s equipment doesn’t exist.
Don’t bother with the Wi-Fi and firewall parts of the ISP’s router – just treat it as a straight-up modem that interconnects your home ethernet network with the phone, cable or fibre network used by your ISP.
Unfortunately, this router-inside-a-router approach isn’t always a viable one.
Here’s an example of when that solution breaks down: a Google security developer just released details of a bug in a type of home router that’s specifically designed to integrate with your home automation kit, and is therefore supposed to be your innermost router anyway.
The bug was found in the TP-Link SR20 router, a device that would be pointless to own if you chained it through another router to shield your own network from it.
In other words, your main reason for having an SR20 would be to set it up at the core of your home network, where it could work with your TP-Link “smart home” kit such as light bulbs, plugs and cameras, as well as interact with TP-Link’s special mobile app, Kasa.
Kasa is a pun, given that casa is the Latin word for the what Germanic languages such as English, Dutch and Swedish call a house/huis/hus, and is still used to mean house in many Romance languages, including Portuguese, Spanish, Italian and Romanian.
Fortunately, this TP-Link vulnerability isn’t remotely exploitable – by default, at least – so SR20 routers aren’t automatically exposed to attack from anyone out there on the internet.
But the bug itself is nevertheless serious, and is a handy reminder of what can go wrong when developers allow themselves to get stuck in (or at least, stuck with) the past, supporting old and insecure code alongside the latest, more secure version.
How did the bug come about?
The SR20 supports a proprietary protocol used by TP-Link for debugging.
Debug interfaces on hardware devices are often problematic, because they usually exist so that developers or support staff can get a detailed look into the guts of a unit, and extract (and sometimes modify) information and settings that would normally be protected from tampering.
Interestingly, one of the earliest internet viruses, the so-called Morris Worm of 1988, was able to spread thanks to a debug feature in the popular mail server sendmail.
This feature wasn’t supposed to be enabled on production servers, but many administrators simply forgot to turn if off.
The sendmail debug setting instructed the server to treat specially constructed emails not as messages but as a list of system commands to run automatically.
You could, quite literally, email a remote server a message that ordered it to infect itself, whereupon it would try to mail itself to the next guy, and so on, all without a password.
Well, for TP-Link SR20 owners, it’s 1988 all over again, although an attacker does need a foothold inside your network already.
Living with the past
Simply put, this bug involves what’s known in the jargon as a downgrade attack.
Apparently, early TP-Link routers would happily carry out debug commands for anyone who could send network packets to the LAN side of the router – you could access the debugging functions without ever supplying or even knowing a password.
That weakness was apparently patched by introducing a new set of “version 2” debug commands that only work if you know and provide the administrator password – a reasonable precaution that limits admin-level activity to admin-level users.
According to Google researcher Matthew Garrett, however, you can still persuade the router to accept some dangerous version 1 commands without needing a password at all.
You just ask the router nicely to fall back to the old days, before passwords were deemed necessary for debugging.
The buggy command in this case is number 49, known rather benignly as CMD_FTEST_CONFIG.
You’d hope that a command that did any sort of configuration test would, at worst, report whether the test passed or failed – but this command is much more general than that.
How does the bug work?
Garrett decompiled the relevant part of the debug server in TP-Link’s firmware and found that the CMD_FTEST_CONFIG works roughly like this:
- You send the server a
file_name and some arbitrary additional_data.
- The server connects back to your computer using TFTP (trivial file transfer protocol) and downloads the file called
file_name.
- The server assumes that the data it just downloaded is a Lua program that includes a function called
config_test().
- The server loads the supplied Lua program, and calls the function
config_test() with your additional_data as an argument.
Lua is a free, open source, lightweight scripting language from Brazil that is used in many popular security products including Wireshark and Nmap, and widely found in routers on account of its tiny footprint.
The TP-Link debug server runs as root – the Linux equivalent of the Windows SYSTEM and Administrator accounts combined – so its Lua scripting engine is running as root, so your supplied program is running as root, so your config_test() function runs as root, so you pretty much get to do whatever you like to the router.
The bad news here is that even if an attacker doesn’t know much about Lua, the language itself includes a built-in function called os.execute() that does exactly what its name suggests…
…and runs an operating system command of your choice.
Lua also has the handy function io.popen() that runs a system command, collects the output and returns it back to the program so that you can figure out what to do next.
-- Example Lua code to run a system command
-- and retrieve the answer line by line...
uidcmd = io.popen('id -u')
getuid = uidcmd:lines()
if getuid() == '0' then
print 'You are root!'
end
-- or simply...
if io.popen('id -u'):lines()() == '0' then print 'You are root!' end
In short, anyone who can send network traffic to the LAN ports on your router can pretty much control your network.
If your Wi-Fi is password protected, an attacker will need to know the Wi-Fi key (the one that’s typically written on the wall of the coffee shop), but that’s all – they won’t need the router password as well.
What happened next?
The bad part of this story is that Garrett says he never received any feedback from TP-Link after contacting the company via what seems to be its official Security Advisory page.
According to TP-Link:
Security engineers and other technical experts can [use this form] to submit feedback about our security features. Your information will be handled by our network security engineers. You will receive a reply in 1-3 working days.
But Garret says that a reply never arrived; he tried to follow up via a message to TP-Link’s main Twitter account, but still received no response.
Because his original report was made in December 2018, Garrett has now gone public with his findings, following Google’s policy that 90 days ought to be enough time for a vendor to deal with a security issue of this sort.
You might think it’s a bit casual to use Twitter as a medium for a formal notifications that says, “Dear Vendor, the official bug disclosure clock is ticking and you have 90 days or else,” but, as Garrett found, TP-Link’s official security feedback page offers no way to stay in touch other than to give the company your own email address and wait for a reply.
What to do?
- If you’re part of the TP-Link security team, you probably want to acknowledge this issue and announce a date by which you can fix it, or at least provide a workaround. It feels as though simply turning off (or providing an option to turn off) unauthenticated access to the debugging server would be a quick fix.
- If you’re a programmer, don’t run servers as root. Code that accepts data packets from anywhere on the network shouldn’t be processing those packets as root, just in case something goes wrong. If crooks find a vulnerability in your network code and figure out an exploit, why hand them root-level powers at the same time?
- If you own an affected router, be aware that anyone you allow onto your Wi-Fi network can probably take it over rather easily using Garrett’s proof-of-concept code. In particular, if you run a coffee shop or other shared space, avoid using an SR20 for your free Wi-Fi access point.
- Whichever brand of router you have, go into the administration interface and check your Remote access setting. At home, you almost never need or want to let outsiders see the inside of your network, so make sure that remote access is off unless you are certain that you need it.
- If you are an IT vendor with an official channel for receiving bug reports, take care not to let any of them slip between the cracks. Provide a clear channel for future communications, such as a dedicated email address, where researchers can follow up if necessary.
- If you’re in the marketing department and you see a technical message in your Twitter feed, find the right person to talk to inside the company and pass the message on. Don’t make it hard for people who are trying to help you.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/HaRWjJsBaeg/
