Itâs worth mentioning that (while users are reliably almost-never-on-the-ball about this stuff), vendors are the prime evil when it comes to the sheer shittacularity of embedded firmware.
Firmware support just stops (after the patch that at least fixes anything you have to reboot it more than twice a week for, if you are lucky; but only if)? Oh yes. âFirmware updatesâ built and released with outdated, internal forks, with known vulnerabilities, that were fixed in the mainstream before the firmware was even released? Sure, who cares?
Really, unless it involves locking you into their app store, upholding their DRM agreement with some streaming video service or keeping you from tethering a device on your data plan, vendors donât give a damn(and, given the margins on a lot of embedded consumer goods, it is understandable why they canât hire anybody who does).
The desktop/laptop/general-purpose-OS scene is bad, security wise; but a computer set to automatically receive updates from the mothership (whether it be Redmond, Cupertino, or whever the various linux distros hang their hats) is a damned miracle of impenetrability compared to all those litle devices that lurk, blinking their LEDs and waiting, biding their time.
I wrote a short story about this, called âThe Brave Little Toasterâ
âŚ
Um. Cory, youâŚuhâŚoh, fuck it.
Open wins again!
Iâm not sure if I find these instructions helpful. I suspect 90% of router owners would say âVerify, how? Update, how?â
To protect from infection by the worm, Symantec recommends users take the following steps:
Verify all devices connected to the network
Update their software to the latest version
Update their security software when it is made available on their devices
Make device passwords stronger
Block incoming HTTP POST requests to the following paths at the gateway or on each device if not required:
-/cgi-bin/php
-/cgi-bin/php5
-/cgi-bin/php-cgi
-/cgi-bin/php.cgi
-/cgi-bin/php4
ââŚcan reprogram it to give the appearance of accepting updates without actually installing them, meaning that the system can never be provably restored to your control.â
What nonsense - I have multiple flash & universal device programmers that can and have brought several linux embedded devices back from being completely bricked (by completely reprogramming the flash memory), and for that matter have JTAG equipment that could have accomplished the same in some cases.
For that matter, most devices have a recovery flasher built in to their bootloaders, meaning that the malware would have to be custom written per bootloader to prevent recovery flashing - which could be interesting in the case of devices with protected/readonly bootloaders. Some bootloaders also verify a signature, hash or CRC of the kernel and/or filesystem (or even the entirety of flash, excluding the config area, in some cases) before boot, so these checks would need to be patched out or defeated as well by any prospective malware.
Lol, heâs probably from the NSA - theyâre going âDangit! One of our best intrusion methods revealed!â
All I can say is that if this portends the end of shitty little consumer-grade âfirewallsâ Iâm all for it!
Or simple incompetence: more than a few networked consumer devices (routers, IP cams, sucky NAS boxes, etc.) have shipped with exploits that either work without authentication, or with hardcoded credentials that cannot be disabled by any means short of nontrival modification/replacement of the vendor firmware. (Also, does your router even bother to rate-limit password failures, or tell you that there have been any? If yours doesnât, that substantially expands the universe of âunacceptably weakâ passwordsâŚ)
Not leaving the default password set is a nice start; but if you think that that is âsecurityâ, the world has some unpleasant lessons waiting for you.
I moved 3 posts to an existing topic: What about additional post reactions other than âlikeâ?
No such luck, I suspect⌠Consumer ISPs will probably still be charging a hefty premium for public IPs even when theyâve finally finished switching to IPv6 and have enough of the things to route packets to every quark in the solar system, which means NAT boxes, probably built right down to price.
(Even worse, just think of the⌠creatively sub-optimal⌠things that lurk behind consumer firewalls, mercifully not being passed outside the LANâs local private block⌠If those were exposed to the public internet, itâd be a total bloodbath, even by the standards of todayâs not-exactly-tame threat level.)
Dating this specimen is actually a bit tricky (the same may be true offline as well, though Iâve definitely not moved to confirm): âXyzzyâ is a reference a good generation or more too old to suit a 12 year old.
This is why you only buy routers that have support past the end of their life (which is typically around a year). In other words, only buy routers on the DD-WRT supported list.
Honestly, Iâm a bit surprised that more router vendors donât skip making their own firmware and just install DD-WRT right from the start. It seems like it would be a cost savings and it improves the quality of the device.
This article (and others, similar) are IMHO irresponsible for a couple of reasons, not limited to:
- The vulnerability (if it may even be called that) is NOT a gnu/linux vulnerability, its a PHP vulnerability.
- The vulnerability affects a very limited subset of server types and DOES NOT affect most users on the net, nor most users who will read the article.
- The vulnerability is NOT in the wild, is more hypothetical than real, and is not likely to be a problem across the boards. (most new routers, even home routers, are not going to be affected by this PHP vulnerability.
- This article (and others, similar) are written to affect users with fear, uncertainty, and doubt. It is time for FUD writing to come to a complete halt.
- This vulnerability (if it may even be called that) is NOT a linux vulnerability⌠it is a server vulnerability in PHP⌠(it has absolutely nothing to do with linux (the kernel). This vulnerability is based in PHP, is hypothetical, and is a vulnerability on any server platform with the PHP extensions to the web server on that platform⌠*this is not a gnu/linux , nor linux, * vulnerability.
Cheers
While the instructions are probably very helpful, unfortunately, for a vast majority of owners, they might as well be written in Middle English. They will recognize a few words but quickly give up on understanding what the hell it says.
Iâve long thought that instructions for hardening an installation ought to be distributed â by the publishers, preferably, but from some trustworthy source in any case â as an executable. Preferably one in a script language so they can also be validated using the Mark 1 Educated Eye.
I agree with the spirit of the idea; but Iâd argue that if you can trust a generic script, written with the idea that it could be an aid to nontechical users, to harden something, that something should have shipped hardened in those ways to begin with.
Obviously, more application-specific, or lots-of-dangerous-knobs-and-buttons scripts can (and are, admins generally know and embrace the virtues of applied laziness, as well as avoiding human error in repetitive tasks) be used to harden things that can safely be hardened under certain circumstances, but not others, or apply other optional-but-might-break X, Y, and Z use cases type modifications in situations where the person using them is expected to have nontrivial site or applicaiton specific knowledge.
Thatâs the tricky bit: much of the âhardeningâ in the world occurs either because the vendor is incompetent/mendacious/no longer in business, or because somebody who has no need of a given, potentially risky, feature is turning it off. Neither situation is wholly tractable, the former because you are specifically not trusting the entity most plausibly responsible for providing hardening advice and tools, the second because it canât easily be handled in a generic way without assuming some knowledge by the user.
Now, if you are stuck in a situation where something is going out into the world broken, automated fixing is probably your best bet, but itâs a somewhat perverse situation where an entity competent to fix automatically exists; but broken stuff is still being unleashed on the world.
Almost agree with you, Fungus â but many systems which are shipped in reasonable configurations are promptly stepped on by users who have only half a clue. So even in that scenario you need automated checking â or you need to block reconfiguration, which wonât fly with the users.
Automated validation (probably a mixture of âfriendlyâ advice from the system, after you modify it and âcontrolled hostileâ white-hat runs of vulnerabilitly probing tools) would be a very good thing to have. Not sure how far you could easy them down; but hopefully theyâd provide something better than nothing to the noobs as well as pointing out more obscure problems before the hostiles find them.
Well, importantly enough the old routers will be turned into perovskite rather than vampire failIoTs. Can people be convinced to throw 30-cent âfailed for trivial appliance deprecation and replacement, inbound firmware vulns, ipv4 deprecation and lame RTOS availabilityâ RFID tags in as a hint? Thatâs one of the little nulls they have for RFID, right?
