Botnets and LibreELEC

1st Official Post

    I was reading about the causes of the recent DDOS attacks on DynDNS that caused massive service outages. These attacks came from botnets composed of compromised IOT devices using a MIRAI variant. This has me thinking about possible vulnerabilities in the OpenELEC/LibreELEC OS. I have a few questions.

    1) Is there a potential for a device running vanilla LibreElec to become co-opted into a botnet via default passwords?
    2) How much vulnerability does the system have with a malicious addon installed, how much control is an addon allowed?
    3) What are best practices for the platform?

    I have shied away from android TV boxes out of concerns due to most of them not being rooted but having permissions granted to strange parties. Paranoid? Maybe, but I've elected to use devices (RPi, M8) that can be cleanly flashed with OE/LE in hopes of eliminating vulnerabilities (and because it's faster and runs superbly). This zombie-network attack has shaken my confidence and sense of security in everything, including my Kodi systems.

    Any thoughts are appreciated, thanks to the team for all of the great work.

    Quote from KLabs


    1) Is there a potential for a device running vanilla LibreElec to become co-opted into a botnet via default passwords?
    2) How much vulnerability does the system have with a malicious addon installed, how much control is an addon allowed?
    3) What are best practices for the platform?

    1) If it's not behind a router/firewall, or ssh/http ports are forwarded to it: very high.
    2) and 3) see Warning - Be aware what additional add-ons you install | Kodi | Open Source Home Theater Software

    • Official Post

    1. The packaging of LE/OE ultimately prevents this issue being solved. The OS password file is inside a read-only compressed file. If you can figure out how to write to things inside the read-only file, we welcome the PR on GitHub. The compromise to minimise attack surface (in the context of 99%+ installs being domestic behind router NAT/firewall and without IP/port forwarding) is that SSH access is off by default. We also advise users NOT to expose LE directly to the internet.

    2. In LE/OE a malicious add-on has root access to the OS and can do what it likes. This is partly a failing of Kodi (no sandbox) and partly a failing of LE (where everything runs as root). Neither situation is likely to change in the medium-term and if you have root/admin access to any OS (Win, Mac, Linux, even ye olde OS/2 warp) there are enough binary OS tools for any competent attacker to wreak havoc; we are not unique. There are current examples of add-ons that maliciously attack other add-ons (pirate stream repo's trying to break their competitors). There are also examples of add-ons that take content from the local system and upload it to torrent networks without asking. I am not personally aware of examples of anything that co-opts the box into a botnet, but it is technically possible; hence Kodi Krypton has a new feature to auto-block the installation of add-ons from zip files (which is how you install pirate repo installers which host dubious add-ons) unless you opt-out. In the long-term there are thoughts on how to sandbox things, but that's a complex discussion. TL/DR; be careful what you install and where you install it from, same as every other OS.

    3. As per #1, keep SSH off unless it's being used, use key-auth not password auth, and do not expose/connect the box directly to the Internet.

    NB: Shodan searches reveal a small number of fcukwits who have exposed the SMB or UPnP shares of their LE/OE boxes to the Internet. It's hard to say how that correlates to the number of SSH exposed systems there are without actually self-scanning for them (and I'm not Brian Krebs) but from the number of SMB systems I believe the number is not statistically significant enough to represent a worthwhile/economic opportunity for the actors who perpetrate these attacks; they are normally looking for "low hanging fruit" that provide much larger device counts. This is obscurity not security but it still counts, sort of. On the positive, I have been periodically checking the LE/OE system count via Shodan for some time and the number has not grown proportionally with the size of either project's installed base. I can also assure you that both LE and Kodi teams take security and privacy seriously; both teams have vocal people with professional security credentials on their staff.

    Quote from chewitt


    It's hard to say how that correlates to the number of SSH exposed systems there are without actually self-scanning for them (and I'm not Brian Krebs) but from the number of SMB systems I believe the number is not statistically significant enough to represent a worthwhile/economic opportunity for the actors who perpetrate these attacks; they are normally looking for "low hanging fruit" that provide much larger device counts.

    Well, I'm owning/running a dedicated server in a data center and among other things I log failed ssh access credentials. The root/openelec combination shows up quite regularly. The root/libreelec combination has appeared a few times in the last 2 months, so there is at least one tool out there that has it in it's database as a combination to try.

    Quote from Grimson

    Well, I'm owning/running a dedicated server in a data center and among other things I log failed ssh access credentials. The root/openelec combination shows up quite regularly. The root/libreelec combination has appeared a few times in the last 2 months, so there is at least one tool out there that has it in it's database as a combination to try.


    Well this thread here is a perfect example for the concerns I posted in feature request subforum some days ago: VPN: Include default iptables rule for tun0 or at least optional
    I'd be somehow more satisfied if there would be some open and serious discussion about this. From my point of view this hijacking of IoT and VPN devices is a pretty up-to-date topic on systems like LibreELEC.

    @Grimson
    It's quite interesting to read that you logged the user/pass variations. Is it hard to achieve? I'm running a Banana Pi Seafile server and would also like to have this kind of logs after reading your post. Is there a guide/tutorial you could recommend (for linux noobs who can follow guides)?

    Edited once, last by infinity85 (November 21, 2016 at 5:32 PM).

    Quote from infinity85


    @Grimson
    It's quite interesting to read that you logged the user/pass variations. Is it hard to achieve? I'm running a Banana Pi Seafile server and would also like to have this kind of logs after reading your post. Is there a guide/tutorial you could recommend (for linux noobs who can follow guides)?

    There is no guide I'm aware of, you will need coding experience:

    First you'll need to modify the OpenSSH (or whatever ssh daemon you use) source code to log the passwords on failed attempts, then you'll have the log data in "/var/log/auth.log". Some ssh daemons might log the passwords in high debug log levels, but this will likely explode the size of your log file, so editing the source to log the passwords in the normal log level is always advised.

    From there it's up to you on how you handle it. I've created a file parser in PHP, that is called by cron and writes the failed attempts into a mysql database. From there I can easily manage the data and display statistics and search for specific entries in a custom PHP based web interface. You don't have to use PHP for this, but I personally prefer it when working with mysql and simple file operations.

    Edited once, last by Grimson (November 21, 2016 at 4:06 PM).

    Quote from Grimson

    There is no guide I'm aware of, you will need coding experience:

    First you'll need to modify the OpenSSH (or whatever ssh daemon you use) source code to log the passwords on failed attempts, then you'll have the log data in "/var/log/auth.log". Some ssh daemons might log the passwords in high debug log levels, but this will likely explode the size of your log file, so editing the source to log the passwords in the normal log level is always advised.

    From there it's up to you on how you handle it. I've created a file parser in PHP, that is called by cron and writes the failed attempts into a mysql database. From there I can easily manage the data and display statistics and search for specific entries in a custom PHP based web interface. You don't have to use PHP for this, but I personally prefer it when working with mysql and simple file operations.


    Okay, that sounds more like an overkill for me. The effort wouldn't be worth for this. I hoped that there might be just some package or a script ;). Fail2ban etc. will have to do it's job and I'll rely on that :)

    Thanks anyway for your description regarding this, Grimson :)