NetUSB Impacts the Security of Millions of Devices Worldwide
blog.sec-consult.com
blog.sec-consult.com
What sort of programmer writes code to handle a protocol with a length field and yet uses a fixed-size buffer without ever considering the possibility of what would happen if it could be larger than the buffer...?
I've seen plenty of source code out there, written for educational/example purposes, where arrays to hold strings are declared with an arbitrary size and no justification why - and naturally, no consideration of this fact is made evident. It's a horrible habit to get into writing code like that, since it makes others, less knowledgeable, think it's acceptable...
The sort of programmer who's not passionate about how the code looks, or works, as long as it passes the (very rudimentary) tests which don't cover protocol violations or borderline cases.
The sort of programmer that didn't have any experience and directly went from Sandbox-Java to bare-metal kernel-code in his first project?
I don't want to disillusion you, but I know plenty of people with (at least part-time) programming jobs who don't care at all about all the new programming paradigms, programming languages, libraries, frameworks... boasted often here on HN. I'd say that a huge majority is pretty pleased with what they know, as long as it's enough to do the job.
And, frankly, economically it makes sense: How many plastic-routers are chosen based on their track-record regarding security? And how many "Security-Incident-Handling Stars" does any of the devices mentioned in the article have on Amazon.com? No one cares. The company and their programmers can just continue writing "almost working" code, and patch the security-incident-of-the-month when it surfaces.
Actually I'd consider myself in that group; most of my work is in Asm and C, with some C++, sometimes Java, and very occasionally do I do anything with Web technologies.
The difference, however, is that I do consider all possible inputs, think about how much space things take up, and generally try to cover the problem space. If there is a variable-length field, there will be a statement in the documentation/requirements which states any length restrictions, and what happens if that length is exceeded.
The sort of programmer that didn't have any experience and directly went from Sandbox-Java to bare-metal kernel-code in his first project?
I think this has much to do with it - those starting with HLLs that cover them with a safety net, letting them do stupid things without all that much consequence, may not develop the same type of thinking; but, even if this was written in something like Java, a Nullpo or IOOBE is unacceptable, and perhaps they would just patch in code to catch the exception and ignore it, not giving this case the proper thought it deserves.
To put it a bit more bluntly: when you're writing in Asm on a machine running DOS, and any bug is probably going to make you reboot, you quickly tire of hitting the reset button and learn to think more carefully about what you write. Although I've migrated from such an environment a long time ago, the habit has stuck.
I completely agree, a good argument for teaching programming "from the bottom up".
> And, frankly, economically it makes sense
because they are treated as disposables by their companies, as far as I understand from all the comments from sysadmins and programmers here and at other forums.
I know we like to think all programmers are the best and brightest and most talented citizens of the entire world, but the truth is: most programmers have the dedication of fast food workers and as long as "it works for me," they'll ship it.
The projects people here are used to (modular, decomposed, open source, documented) are rare. The world is full of multi-million line code bases with little usable documentation (either no documentation, outdated documentation, or 8,000 pages of documentation) and comments not describing actual behavior. Plus, everything gets compiled using 300 recursive Makefiles written across 15 years in 8 different countries by people who only keep their job for 8 months at a time.
The router companies shipping NetUSB routers are meeting a market need; people want to plug printers into routers and print from anywhere on their network. For many users and applications, low-quality code will work.
It's in the long term that high-quality work differentiates itself.
Oh, don't pretend "quality" is just a proxy for "has pretty animations and makes the user feel warm and fuzzy."
The failure to ensure "quality" of this embedded router component has put millions of never-going-to-be-updated hardware devices in the wild at risk of 3rd party takeover, personal information leakage, installing proxies on them to send user details to hostile actors (monetary losses, blackmail), ....
Programming errors shouldn't be excused just because we always say "whoops! we'll do better next time!" But, since humans are objectively bad at something as complex as programming, we can't hold people accountable (who wrote it? an intern from 8 years ago? punishing them does no good). We can't hold organizations accountable (recall all the consumer routers!) because public policy doesn't think that way.
We're in a weird period of history where companies can get away with great computational damage with no repercussions at all. The market currently _does_ favor "just do whatever and try to fix it later (or not, whatever)," but that doesn't make it right.
Contrast that with the completely different approach taken by the aerospace industry, where people and organisations are held accountable; and it has resulted in great reliability overall --- interesting discussion about that here:
https://news.ycombinator.com/item?id=9569077
We're in a weird period of history where companies can get away with great computational damage with no repercussions at all
In critical software for a plane it is literally a matter of life or death, and people are willing to pay much more for that level of quality; but if a consumer router gets exploited, what's the worse that could happen?
I think it is important to put the risk into perspective: this is bad, but it's not really a people could get killed sort of thing.
Then there's a whole "stake you claim" mentality. Want to be the best C person in the world? You can't. It's too wide spread. What to be the best Go person? Sure, fight that battle for your own glory since it's new and you can take part in everything.
Lack of education/experience also creates a great breeding ground for new, duplicate, half-implemented versions of things that already exist. The older a developer gets, the more they see things they already know re-implemented as completely new but with unfamiliar interfaces they'll have to re-learn again every 6 months. It's a huge waste of human capacity to always be "new new new" instead of creating a stable and reasonably extensible base to work from. But, at the same time, we don't want to be stuck on Perl 4 and CORBA forever.
There's a tradeoff between building new things for advancing the future versus building new things just because you think you're better than all the previous research/experience that has come before you. See the case of Cathedral v. Bazaar.
Deleted comment
What would you use for that kind of code 5 years ago? The code in question likely took some time to write, get from proof-of-concept to beta to production to widespread use, before it could start to be a threat for many people.
Of course, the other mentioned vulnerability - that some of these devices are exporting your USB devices to the whole internet - was language-neutral.
From the point of view of a race-to-the-bottom consumer hardware manufacturer, the choice is obvious.
> -----------
> Sometimes NetUSB can be disabled via the web interface, but at least on NETGEAR devices this does not mitigate the vulnerability. NETGEAR told us, that there is no workaround available, the TCP port can't be firewalled nor is there a way to disable the service on their devices.
https://www.sec-consult.com/fxdata/seccons/prod/temedia/advi...
Eeesh
I should probably replace my commercial-grade WiFi router with some custom box that can run OpenBSD or something.
When I first got it, I tried to go through and lock down everything I could find. But I suspect that may not be enough.
The cool thing about the ALIX and APU boards is they often support buying things like 3g modem cards which you can use to multi-home your connections with pfSense. You could also create an SMS gateway or similar service.
If you could keep performance and consumer costs comparable, you could probably sell quite a few.
The biggest challenge is whether this will impact your internet speed. If you have a faster broadband connection, you can quickly exhaust the throughput capabilities of such a limited platform. Things get significantly worse if you are relying on the router for your LAN traffic as well (i.e. you don't have a switch to offload the LAN only traffic).
With the more commercial solutions, whether for SOHO or SMB, the biggest advantage they bring to the table is the ability to utilize hardware optimizations such as offloading for checksum, TCP segmentation, and large receive.
pfSense actually has code to perform the offloading, but you have to ensure the hardware you're using is capable of performing the work.
[1] http://www.amazon.com/dp/B008KB5YCK/ref=wl_it_dp_o_pC_nS_ttl...
Are there manufacturers or product lines that are safe(r) from such approach? Are alternative firmware such as OperWRT or independent open-source firmwares (m0n0wall, pfSense, OPNsense) better in this regard?
This is a very important caveat that seems to be a bit buried in the article. If this service is not exposed to the Internet, an attacker would have to be on your local network to exploit the vulnerability--either authenticated into your WiFi, or already resident on one of your devices (through a previous exploit). Both are fairly high hurdles if you encrypt your WiFi.
Coffee shops etc. that run open consumer-grade WiFi access points could be vulnerable to this. Exploiting that router would provide bad guys with a platform to harvest or attack traffic from all the computers that connect to that router.
If your device does expose this service to the Internet, then any script traversing known consumer ISP netblocks could try to hit it. So that is worth nailing down.
I have no idea what the truth actually is, but my experience would lead me to believe worst case.
1: One expensive (8 digit) system that was targeted at multi tenant setups used Java for the UI. Annoying but OK. But, how did the Java app determine your login privileges? Oh, easy! The app would download the root credentials for the system, use them to login to MySQL over the Internet, then "SELECT Permissions from user where...".
I met the developers and their response was " yes that's a known issue in the current version ". Ignoring that many users were stuck on that version for a long time. For bonus points, this system logged the root credentials to debug log, in the user's home directory. I'll let you guess if their updated version was vulnerable as all hell, too.
Edit: This was a major VoIP switch vendor (NexTone, now killed/bought by Genband IIRC), so exploits were easily turned into money. (Just route traffic on someone else's trunk for a bit.) Though I've dealt with other VoIP providers, ones that keep much more info (full end user info, CALEA module available) that had SQL injection-> root takeover on the login page. That puts end users at risk, too. Their response? " Our programmers are top notch C/C++ guys, they just aren't perfectly familiar with PHP... "
Working at a Taiwanese company, unfortunately this does not surprise me at all: both the nonsensical (ie. likely no foreign educated and definitely no native speakers on the team), or being ignored ("I have no idea what they are on about but if we don't reply, maybe they will go away") :(
I love this place to pieces, but could use a few level-ups in English, technical skills, and customer support.
> Easy as a pie, the ‘90s are calling and want their vulns back
exploits actually exploit things
I used to use one of the affected devices (TP-LINK Archer C2), but primarily bought it to run OpenWRT on it. Eventually I got tired of tinkering with it and replaced it with something else, though.
Nmaping port 20005 is not accurate enough.
I want to check 3 of my routers, both from LAN and WAN.