IoT Devices With Default Telnet Passwords Used As Botnet (securityaffairs.co)
Slashdot reader stiebing.ja writes:
IoT devices, like DVR recorders or webcams, which are running Linux with open telnet access and have no passwords or default passwords are currently a target of attacks which try to install malware which then makes the devices a node of a botnet for DDoS attacks. As the malware, called Linux/Mirai, only resides in memory, once the attack has been successful, revealing if your device got captured isn't so easy, and also analyzing the malware is difficult, as it will vanish on reboot.
Plus the malware lays low at first, though "it is obvious that the main purpose is still for a DDoS botnet," according to MalwareMustDie, and it's designed to spread rapidly to other IoT devices using a telnet scanner. "According to the experts, several attacks have been detected in the wild," according to the article, which warns that many antivirus solutions are still unable to detect the malware, and "If you have an IoT device, please make sure you have no telnet service open and running."
Plus the malware lays low at first, though "it is obvious that the main purpose is still for a DDoS botnet," according to MalwareMustDie, and it's designed to spread rapidly to other IoT devices using a telnet scanner. "According to the experts, several attacks have been detected in the wild," according to the article, which warns that many antivirus solutions are still unable to detect the malware, and "If you have an IoT device, please make sure you have no telnet service open and running."
Why is telnet used to access these IoT devices? At the very least a secure shell session (ssh) with a strong default password randomly generated the first time the device is switched on after connecting it to a notebook or desktop computer via USB cable. The newly generated password could be transferred automatically to the computer as a text file and then the device's USB port automatically disabled by the device itself and the only way to change the password is by locally logging into the device via SSH. The owner can re-enable the USB port if they choose although best not to do so.
Sorry and unimaginative trolling
Are all of those IOT devices designed by millennials ??
Security is hard but it is really disconcerting to see companies fail to even try to create secure IoT devices.
Never EVER have open telnet (port 23). Unless you run a honeypot VM don't do it. Add a firewall rule to block all port 23 traffic on your LAN.
Silly question. Why telnet? Because it is cheap and they don't give a crap if you get hacked. Not their problem if you do.
In this day and age, a device with telnet and no password is fundamentally a defective product.
Real lawyers write in C++
"According to the experts, several attacks have been detected in the wild," - well, have a look at this article. It is about more than 6 million devices, 1 million of it being for sure IoT stuff like cameras and the likes. It is very likely they are talking about the same attack described here.
Here is a website where you can test if your device has such a problem, because it has been observed in Telnet honeypots for quite some time - https://amihacked.turris.cz/
Like the early, early internet, when nearly everything was crazy wide open. Who could have known IoT would be just as nuts? How could anyone guess such a thing would ever happen! Stay in school kids.
If the sysadmin is stupid (like you are, for example), then any Unix is less secure than even unpatched Windows. Linux security is what you get when you combine a competent sysadmin and Linux. The same effect exists on Windows, but the results are not nearly as good and that is what makes Linux a secure OS and Windows a problematic one.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Except for devices where the buyer WANTS this open - say, for use in a honeypot - I would consider this a design defect. Depending on the device, this could cause death.
The feds (in the USA) are probably going to turn the "voluntary" recall of the Samsung Galaxy 7 phone into a "mandatory" recall.
I would recommend they seriously consider doing the same for any device that has security hole like this that can't be fixed by end users, especially for devices that are designed to be used by non-experts.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Some things can hurt people or destroy property if they don't work right.
Maybe it's time to have the makers of HVAC systems and other things that could injure or kill if they become zombies get an engineer to sign off on all designs - including software design - before they are allowed to sell the equipment for its intended purpose, at least if the end user isn't an expert (e.g. thermostats designed for residential or small-office use where they aren't under constant monitoring by HVAC professionals). This would force the engineer to either prove to his own satisfaction that hardware and software, as a system, was safe or design the hardware so that no matter what happened, fatalities would not result (e.g. have a hardware limits on home thermostats, so someone remotely cranking things up to 100F or down to 40F wouldn't kill anyone in the room).
Now, I'm not calling for "locked down firmware" although that would be one way of dealing with the issue. Instead, I'm calling for firmware that is vetted by an engineer and which can only be updated either by an "authorized update" (e.g. signed binary or better yet, signed binary and a temporary "updates allowed=YES" button being pressed on the device) or by a hobbyist making a visible and permanent change to the hardware, such as blowing a fuse or cutting a trace on the motherboard. Failures by devices that had been put into "hobbyist mode" would not be the fault of the engineer unless it could be proven that the firmware was not at fault (e.g. engineers would still be liable for design flaws that would affect non-tampered-with systems, such as a failure in the hardware-limits of the thermostat example above).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
This story isn't about LUDDITE Linux. It's about the Appernet of Apps, the appiest way to app apps while apping other apps!
Apps!
Only LUDDITES would think that LUDDITE Telnet is secure! Modern app appers use secure apps by ONLY apping apps, NOT LUDDITE Telnet!
Apps!
Spread the meme
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Linux is nice because one can secure at as they see fit. Someone on the operator level can enable patching at certain times in RedHat and downstreams, Debian, and Ubuntu, with ease. This isn't something you would do in production for obvious reasons, but with modern mainstream Linux distros with their default installs, it actually is more work to not enable patching than to enable it.
An admin that is more versed would be using some sort of patch management system, if only to ensure that SSH, OpenSSL, the kernel, and other critical components are not just patched, but there is validation that things are at that patch level.
Next tier up, the admin would have a CM tool which either gets pushed or runs locally with a stanza like this:
---
- name: Update openssl
package: name=openssl state=latest
The above stanza would get pushed to all boxes every so often.
Of course, Linux can be horrific if unpatched, because there is so much a blackhat can do on a Linux box, even if root access is unavailable. However, in general, because Linux is open, there are fewer moving parts which are hidden away from the user. For example, when Shellshock came out, and a quick patch had to be done, it wasn't hard to build a static busybox binary as a workaround until a few hours later, bash was patched.
Speaking as a slightly paranoid home user.
Every time I add a new device to my network, I do a nmap port scan on it. Something like:
sudo nmap -A -T4 ipaddress
If access to those ports are needed, I'll do some poking on them, depending on what they are and probably some research to determine if they have had any security issues, and do a risk analysis.
Work follows a completely different model. Everything is blocked, there are various levels of approvals needed to open any ports. External access directly to internal systems without proxies/frontends/webheads is almost never granted. Periodic reviews, pen testing and renewals for exceptions are mandatory.
Security is the minimum of the system's capabilities, the integrator's capabilities and the user's capabilities. Granted, the integrator can take away sufficient options from the user to eliminate him from the equation, but if he is already a complete idiot, the system can't compensate for it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
It's idiots all the way down.