mangOH and the Mirai botnet
Published:  14 November 2016

With the recent Distributed Denial Of Service (DDOS) attacks on internet infrastructure being blamed on poorly secured IoT devices, now is a good time to look at some basic security practices to secure IoT products being based on the mangOH platform.

Is the mangOH susceptible to the Mirai botnet?

Well, no ... and yes.

Mirai propagates by finding open Telnet ports (Port 23) and then trying a series of default username and passwords in an attempt to log into the device. Once a login has been sucessfully obtained, Mirai then attempts to install itself on the target device and if sucessful Mirai begins its nefarious work.

No?

As the Linux distribution used by the mangOH board doesn't have a Telnet server (telnetd) installed by default, the main vector for Mirai infestation is potentially blocked. Additionally, the 3G radio data connection is switched off by default so the only way into the mangOH is either via the Ethernet connection to your internal network, or via the USB ethernet connection from your development machine!

Yes?

The WP8548 processor that mangOH is based on

is an ARM cpu

runs Linux
and uses busybox

all of which are requirements to run Mirai. So if Mirai somehow gets onto your mangOH board, then it's probably going to run quite happily (and flatline your SIM data allowance in a short period of time!).

Warning:

Although the mangOH uses ssh as the remote access protocol, the firmware is (currently) shipped from the factory with an empty root password. So if (when) another piece of malware appears on the IoT scene the ssh protocol may be targeted instead of telnet.

eek! No root password - what else is listening by default?

Interested to find out just what servers are listening on your device? Or who is connected? netstat is your friend.

netstat -lantu on a mangOH running legato 16.04 shows the following 'listening' servers and connected devices:

$ netstat -lantu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:1534            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:5037          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN
tcp        0    132 192.168.1.5:22          192.168.1.45:49378      ESTABLISHED
tcp        0      0 :::22                   :::*                    LISTEN
tcp        0      0 :::53                   :::*                    LISTEN
udp        0 162624 0.0.0.0:1534            0.0.0.0:*
udp        0      0 0.0.0.0:53              0.0.0.0:*
udp        0      0 0.0.0.0:67              0.0.0.0:*
udp        0      0 :::53                   :::*

So the open 'listening' (open inbound) ports are:

  • TCP 22 (ssh)
  • TCP 53 (dns server)
  • TCP 1534 (Eclipse Target Communication Framework (TCF) agent discovery - used by Developer Studio to 'find' the board)
  • TCP 5037 (TCP Android ADB server)
  • UDP 1534 (Eclipse Target Communication Framework (TCF) agent discovery - used by Developer Studio to 'find' the board)

and there is one established connection:

  • 192.168.1.45:49378 is connected to 192.168.1.5:22 (this is a ssh connection from the develpment machine to the mangOH board)
Why is there a DNS server listening on port 53?

As part of the way that the USB ethernet connection is set up, the mangOH board requires a DNS server to issue a single IP address to the USB host when it's connected.

This service is performed by the dnsmasq daemon.

So how do I secure my mangOH board?

See Security hygiene for the mangOH board for some best practice information on securing your mangOH board.