This one is mind-bogglingly stupid. But the story serves as a good example of what I mean when I say that computer security can only get so good, because the whole ecosystem is so thoroughly undermined that any effort to secure it can be over-topped by the attackers, with minimal additional effort.
Is this a deliberate backdoor, or just a developer having the stupids? Back in the day when I started coding networked applications, it seemed like a good idea to code in a power-user account that was disabled when the final system was compiled – it meant I didn’t need to set up the whole authorization framework every time I wanted to test the software. Fortunately, I learned better – although I regularly used to get questions about whether I had backdoor’d any of my firewall products. The idea that someone might do that is shocking to me, but that was the late 80s.
Zyxel has released a patch to address a critical vulnerability in its firmware concerning a hardcoded, undocumented secret account that could be abused by an attacker to login with administrative privileges and compromise its networking devices.
According to the advisory published by Zyxel, the undocumented account (“zyfwp”) comes with an unchangeable password (“PrOw!aN_fXp“) that’s not only stored in plaintext but could also be used by a malicious third-party to login to the SSH server or web interface with admin privileges.
Zyxel said the hardcoded credentials were put in place to deliver automatic firmware updates to connected access points through FTP.
FTP’ing firmware updates to an access point, using an undocumented backdoor is less crazy than you might think. I mean, it’s really stupid, but it’s the kind of thing that software engineers come up with when a feature shows up on a product schedule and nobody tells them to do a bit of research and design before they just come up with a brilliant idea and run with it.
I’m not kidding. Back in 2012, I had a conference call with engineers and managers from a major printer manufacturer that was planning on expanding their product line from normally-USB-connected printers to local area network-connected print servers; I had to step them through the whole idea that a print server was a target and if it was running a general-purpose operating system, it was going to embed the operating environment’s vulnerabilities and be vulnerable, itself. I was fortunate, on that conference call, because I had documentation regarding an incident in which a Kyocera “Document Solutions” photocopier machine had been compromised by hackers (it was running Linux inside) and used to pivot into launching Nessus scans and Metasploit attacks onto the local network. The printer manufacturer I was talking to was furious that they were going to have to spend time figuring out how to write Ipchains rules to control traffic into/out of their print management software, which turned out to be a horrible, un-authenticated http-based piece of crap. You want a fun conference call? Tell some big vendor that they need to rewrite something they just announced was available on the market. Then, imagine it has a hardware distribution component, and they didn’t think of a way that the base operating environment can be updated, “ship your printer back to the manufacturer” does not cut it.
That’s the problem: when you depend on something, you’re embedding its vulnerabilities and those vulnerabilities must then be managed. Imagine if you had set up a financial transaction management system, and had used Xyxel’s otherwise excellent and inexpensive firewall/access points? Now, anyone who has read about it, can walk through your security architecture as if it’s not even there.
blue thing on top is a USB battery, little device on lower right is Xyxel Wifi/firewall. All together, a nice portable high-speed camera solution. Oh, yeah, the camera runs Linux so, if you could get into the access point, you could get into the camera and upload malware to it.
In fact, I have/use a Xyxel Wifi access point/firewall, because it is small, cheap, and USB-powered – in my case, it’s OK because I just used it as a way of providing Wifi access to a high-speed camera that was designed with a hard-wired interface (idiots!) [ranum] At $40 bucks apiece, you can be sure that lots of people have used the Xyxel firewall/Wifi points for all kinds of things. It’s a big deal because that type of application is exactly the type that does not get reviewed regularly, and never gets updated. Applications like that will never show up on vulnerability scans or on Shodan; this is a hole that will exist for a very long time.
When I first started working on firewalls, the state of the art was to write access control lists in a Cisco router. Many organizations used to just block telnet port 23 inbound and I was amazed when I scanned all the ports (this was 1989) and found an undocumented telnet listener at port 2020. That has finally been fixed, but it was an important lesson for me: you can’t assume that the vendor is not unutterably stupid.
In the Xyxel case, I assume it’s just common-or-garden stupidity, but Xyxel is headquartered in Taiwan and Taiwan is part of the US intelligence community’s sphere of influence. If it was a China-based company, like Huawei, you could expect the US Government to be freaking the fuck out, but instead this story is being treated like just another *yawn* design flaw. I’m willing to state with a high degree of confidence that this backdoor is not one that was influenced by NSA, because theirs are so much better.
[fas]
The Republic of China (ROC, Taiwan) is operating a major signals intelligence (SIGINT) facility in co-ordination with the US National Security Agency (NSA) on Yangmingshan Mountain, just north of Taipei, Jane’s Defence Weekly has learned.
The NSA helps the ROC co-ordinate and process its SIGINT data collected from various SIGINT stations located around Taiwan. Data collected by the facility is processed for use by Taiwan’s Military Intelligence Bureau (MIB) and relayed back by satellite to the NSA.
The facility is a “data processing centre” located on a ROC military compound that is also identified as the Taiwan headquarters of a US telecommunications company based in Maryland. The company has been identified by a high-level US State Department official and a source within the MIB as a commercial front for the NSA.
Taiwan headquarters of a US telecommunications company based in Maryland, eh? A bit of querying makes L3 Communications/Harris pop up. L3/Harris makes all kinds of stuff, including cell phone IMSI catchers (“stingrays”) and other surveillance tech.
One of the little games I still play with myself is to hypothesize how a vulnerability is discovered. In the case of the Xyxel backdoor, it would not be discovered by someone randomly connecting to the device’s web server and trying all the possible user/password combinations. Someone probably took a copy of the firmware [zyxel] and ran “strings(1)” against it. Hard, huh? Unless the user/password were obfuscated in the code, that’s all it would take.
I’ve discussed the Huawei problem before, and I’m not very impressed by the US Government’s frantic bleating about Huawei maybe having backdoors – if there were, and they were known, it’d be easy enough to simply trickle the backdoors out, one a month, and it’d make the products unmarketable by raising the management cost to be stratospheric; imagine if you were a telco and you had to keep upgrading your 5G infrastructure’s firmware every month. It’s that, or leave the vulnerabilities in (and then the NSA and FSB and Mossad would cheerfully exploit them) I still believe that the main reason behind the US Government’s Huawei freak-out is because Cisco hasn’t got a competitive offering and they’re lobbying hard to lock the Chinese company out of the US market until they do.
You can bet your bottom dollar that if there was a vulnerability like this in a Huawei product, it’d be trumpeted from the roof-tops, “Chinese government backdoor found in popular Wifi infrastructure device!”
What does the fact the camera runs a Linux kernel have to do with it being vulnerable?
I’d give you evens that the relevant bit of code is tagged with something like // TODO: Replace this before we ship!!!
I inherited a maintenance project from a client not long ago with #define MYTESTACCT__ 1 peppered throughout. Worse, #define MYTESTACCT__ 0 occurred with about equal frequency. I can only guess the previous author had never heard of grep.
Broken garbage like this is prevalent everywhere. Human is as human does and that’s why we can’t have nice things.
@1 There’s a very large slate of known vulnerabilities to try out first, and if none of them work it’s relatively easy to find some more in one of the many many separate networking components that are undoubtedly installed on it as well. (Note: Marcus said it runs “Linux inside”, not that it runs “a Linux kernel” – the implication being there’s a whole ecosystem being imported and you get the separate bugs in each part of that.) On top of that, manufacturers (or their eng teams) will be choosing Linux not only because it’s free, but because it’s very easy to drop onto a relatively novel piece of hardware and have something running with minimal time and effort. That means minimal effort spent on making sure that the configuration is secure too.
@4 – Yes, of course. I was being annoyingly pedantic. I try to distinguish between “Linux” and “Linux distribution.” Again, it usually boils down to something avoidable and stupid, such as running an open telnet server “to be fixed later” because the dev is too lazy to think about security up-front.
fossboxer@#5:
@4 – Yes, of course. I was being annoyingly pedantic. I try to distinguish between “Linux” and “Linux distribution.”
So do I, which is why I wrote “linux” not “linux kernel.” You added that, which made my statement wrong, and then complained that I was wrong. Nice try but that’s bad kung fu.
@#5-6
Now we are just missing a hardcore fan who insists that it should be called GNU/Linux. ;-)
The reason I know the camera is vulnerable is because it’s ~5 years old and it’s still running whatever version of linux was loaded on it when I got it. Since I know that the linux instance in the camera is configured with both an http/https server and an SSH server, I can’t be arsed to look up the list of vulnerabilities that it contains but I guarantee there’s more than one that is exploitable.
Should I be upgrading the linux distro in the camera? Aaaaahahahahahahaaaaaa!! No. Because there’s doubtless some kind of custom driver to talk to the high speed camera’s control plane, and if I mess with it, I may wind up with a brick. Sure, I could invest time in downloading and rebuilding the boot image, but the camera’s old and out of maintenance, etc.
That’s the same old song and dance and it’s why so many medical devices, internet of things devices, and automation controls are trivially vulnerable to a slightly motivated attacker.
By the way, the idea that there is a difference between the kernel, and the system software distribution is largely false, because there are privileged processes outside of kernel space, that also can contain vulnerabilities. I discovered/exploited my first such vulnerability on BRL V6 UNIX running on a PDP-11/44 in 1983, and I don’t think the situation has improved since then – in fact, loadable device drivers and shared libraries make it substantially worse. (Shared libraries haven’t been a popular point of attack because they’re a pain to work with, not because they aren’t a glaring hole in the system; we knew dynamically linked executables were a bad idea in 1985 and … now, look upon our works, ye mortals, and despair!)
Jörg@#7:
What I call it, when nobody else is around to hear me, is unprintable and may even be illegal.
Unrelated but related, just this afternoon, I was texting back and forth with a nerd-friend, and it went something like:
Me: Did you know that systemd was on the grassy knoll in Dallas, that day?
Him: Systemd causes cancer; everyone knows that and they are trying to deflect attention by blaming it on 5G
Me: Huawei wrote systemd, that’s why the NSA is having shitfits
Him: Yup, because NSA wrote init
Me: Bullshit, they’re not that good at programming.
etc.
When you’re talking about the security of a system, you have to consider the entire environment, because any place where any data is used to control execution is a potential vulnerability.
Here’s an example I suppose it’s OK to mention, now: how many of you have written your own troff macros? I have. I used my own macro package (that was much simpler than the system default) from 1982, on. In the course of learning troff inside and out, I discovered that you can write macros that call out to external processes (shell escapes, whatever you want to call them) once, for fun, I wrote a couple of manual pages that checked to see if the troff instance was being run as uid=0, and nicely formatted some text and appended it to the password file. Since catman ran as a service every day, my backdoor re-installed itself magically. I did a lunchtime briefing on it when I worked at TIS and everyone was full of hate because i had just added another entire attack vector that had to be controlled for in trusted operating system releases. It turned out, to my amusement, that one of the guys went upstairs after my talk and added my macros to a manual page on a Sun Compartmented Mode Workstation and, sure enough, the next morning, there was a gid=10 user in the password file.
Oh, the fun we had.
Dunc@#2:
I’d give you evens that the relevant bit of code is tagged with something like // TODO: Replace this before we ship!!!
I wouldn’t bet against you.
Scariest comment I ever saw during a code audit:
/* Drunk, fix later */
The funny part was I went to talk to the guy who wrote that module and walked into his office just as he was checking in the update to that routine. He was one of the best programmers I ever worked with, and he also had a great snout for vintage port.
@6 – Fair point. I stand corrected. It’s by habit I associate the two but you are certainly correct. My pedantry skills have just gone up a level.
@7 – Despite the (possible) implication in my tone, I’m no hardcore fan of Linux, nor any other operating system, kernel, etc.
New highly secure local network.
@13 There is one known vulnerability…
https://www.dailymotion.com/video/x6v732o?start=1420
(From 23:40 to 25:20.)
(And, what the *hell* do they do with that if they suspect infected materials may have gotten into it?)
Unrelated but I’m still pissed about it: had the misfortune to encounter the worst account security design yet. Tried to log into my ubisoft account last week. I had no access because of too many unsuccessful login events. Apparently my email got leaked in one of their numerous data-leaks. I contacted their customer service who said I should just wait until the block expires and try again. I could change my password from outside of the account, but not my email. Now either there is a bug and the block doesn’t expire or someone is running a script trying to brute force my password, but I am still locked out of my account, customer service can’t lift the block and I can’t change my email. So if you want to lock people out of their accounts, all you need is their email address and run a script trying to unsuccessfully log in. Great design! Need to find out the email of the guy who came up with it.
kurt1@#16:
Unrelated but I’m still pissed about it: had the misfortune to encounter the worst account security design yet.
Facebook can top that. It used to be (not sure if it still is) that if you wanted to re-activate a closed account, it would let you use any email address as the new email address, so long as the account had not been used in 3 years. I was able to re-activate my old account using a gmail user-id, then flip it over to my normal address once I had taken control of the identity.
@14 xohjoh2n
Might work but assuming a pipe under pressure (negative or positive) I have my doubts.