Slashdot Mirror


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."

7 of 57 comments (clear)

  1. Follow the money by sjbe · · Score: 2

    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.

    1. Re:Follow the money by dargaud · · Score: 2

      Programmers who install telnet servers anywhere should be shot. 15 years ago it was already common knowledge that telnet was completely insecure and only a matter of time before it got owned. So why isn't there a daemon on all linux variants that monitors for the presence of a telnet server and KILLS IT ?!?

      --
      Non-Linux Penguins ?
    2. Re:Follow the money by Anonymous Coward · · Score: 2, Informative

      So why isn't there a daemon on all linux variants that monitors for the presence of a telnet server and KILLS IT ?!?

      There is. If you run systemd, it will eventually bring down your entire machine, including any errant telnet servers.

    3. Re:Follow the money by mlts · · Score: 2

      One ideal might be having good in and out firewall rules on the machine. It takes time for initial setup and maintaining, but isn't that bad (it can be put in your playbooks or .pp files.) That way, a telnet server will be not accessible by anything.

  2. Defective Product by SeattleLawGuy · · Score: 5, Insightful

    In this day and age, a device with telnet and no password is fundamentally a defective product.

    --
    Real lawyers write in C++
  3. Re:Wait, the story is in error by gweihir · · Score: 3, Insightful

    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.
  4. Make some IoT makers get an engineering seal by davidwr · · Score: 2

    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.