Eystein Stenberg, CTO of Mender.io , walks through the various malware infecting Linux IoT devices including Mirai, Hajime, and BrickerBot and the vulnerabilities they leverage to enslave or brick connected devices. He covers specific vectors they used to exploit devices and cover some basics in security hardening that would have largely protected from many of the widespread malware.

1. Eystein Stenberg
CTO
Mender.io
Linux IoT Botnet Wars and the Lack of Security Hardening

2. - Chris Pirillo

3. ● Eystein Stenberg
○ 8 years in systems security management
○ M. Sc., Computer Science, Cryptography
○ eystein@mender.io
● Mender.io
○ Over-the-air updater for Embedded Linux
○ Open source (Apache License, v2)
○ Dual A/B rootfs layout (client)
○ Remote deployment management (server)
○ Under active development
About me

4. We need to learn from past compromises
● Avoid the same mistakes
● Think about security design of your products or code
● Peace of mind you will not be next

5. Session overview
● Case-studies of device compromises & botnets
○ Mirai (August 2016)
○ Hajime (October 2016)
○ BrickerBot (March 2017)
● Common security problems
● Solution designs

6. Mirai - Purpose and impact
● Discovered: August 2016
○ Mirai means “future” in Japanese
● 200,000 - 300,000 “stable” infections
○ Peaked at 600,000 infections
● Used for DDoS in late 2016
○ Krebs on Security (600 GBps), OVH
○ Dyn DNS
○ Can be extended for other uses
● Source code on GitHub
○ Leaked in hacker forums, published by researchers
○ https://github.com/jgamblin/Mirai-Source-Code
Source: Understanding the Mirai Botnet, Usenix

7. Mirai - Design (1/2 - Discovery)
1. IPv4 TCP SYN probes for port 23 and 2323
○ Later iteration: SSH, CWMP/TR-069 exploit
2. 10 brute force Telnet login attempts
○ From list of 62 username/passwords
3. Send IP & credentials to report server
Existing infection
23
2323
1. Scan
2. Login
admin/admin
IP: 1.2.3.4
Report server
(attacker-controlled)
3. IP: 1.2.3.4
admin/admin

8. Mirai - Design (2/2 - Infection)
1. Loader program
○ Detects environment and installs Mirai
2. Obfuscation
○ Randomize process name
○ Delete executable
○ I.e. Mirai does not survive reboots
3. Remove “competitive” services
○ Remote login (Telnet, SSH)
○ Other malware
4. Listen for commands, scan for more victims
23
2323
IP: 1.2.3.4
Report server
(attacker-controlled)
Loader
(attacker
controlled)
1. IP: 1.2.3.4
admin/admin
Infection
Install Mirai
Command
& Control
server

9. Mirai - Summary
● Embedded Linux devices
○ DVRs, IP cameras, routers, printers
○ ~30 vendors, many devices
● Efficient spreading
○ Remote login (port open)
○ Internet-wide scanning
○ Asynchronous
● Exploited default credentials
○ username / password
● “...demonstrate that novice malicious techniques can compromise enough low-end devices to
threaten even some of the best-defended targets...”
○ Surprising scale of trivial problems (600,000+ devices)

10. Hajime - Purpose and impact
● Discovered: October 2016
○ Similar timeframe and net pattern as Mirai
○ Named “beginning” (Japanese) by researchers
○ Hajime author adapted it after report published
● Modest estimate: ~30,000 infections
○ Likely 200,000 max infections
● Seemingly not used for attacks
○ No DDoS capability
○ No attack code
○ Can change at any time (via update)
● Displays a terminal message every 10 minutes
○ “White worm” by a vigilante?
Sources: Hajime worm battles Mirai for control of the Internet of Things, Symantec
Hajime: Analysis of a decentralized internet worm for IoT devices, Rapidity Networks

11. Hajime - Design (1/2 - Discovery)
1. IPv4 TCP SYN probes for port 23
2. Brute force Telnet login attempts
○ From list of 64 username/passwords
○ Same as Mirai + 2 more
3. Write a file transfer binary on victim
○ 484 bytes (raw TCP transfer binary)
○ Written in assembly(!)
4. Victim connects to attacker and downloads Hajime binary
Existing infection
23
1. Scan
2. Login
admin/admin
3. Write file
transfer binary
IP: 1.2.3.4
4. Connect back
to download
Hajime binary

12. Hajime - Design (2/2 - Infection)
1. Victim connects to decentralized “overlay” peer network
○ BitTorrent DHT (discovery)
○ uTorrent Transport Protocol (data)
○ Installs Hajime scanner (“exp module”) and network configuration
2. Obfuscation
○ Renames itself to telnetd
○ Remove its binary
○ Does not survive reboots
3. Improves security of device
○ Closes ports 23, 7547, 5555, and 5358
○ Mirai targeted some of these
4. Scan for more victims
IP: 1.2.3.4
Join peer
network
Infected peer network

13. Hajime - Summary
● Embedded Linux devices
○ ARMv5, ARMv7
○ Intel x86-64, MIPS (little-endian)
● Decentralized spreading
○ Remote login (port open)
○ DHT/uTP based
● Exploited default credentials
○ username / password
● Target the same devices as Mirai

14. BrickerBot - Purpose and impact
● Discovered: March 2017
● Author claims 2,000,000 total infections
● Erases all storage and bricks the device
○ Destructive “white worm” by a vigilante
○ “PDoS” attack against devices
Sources: BrickerBot, the permanent denial-of-service botnet, is back with a vengeance
BrickerBot PDoS Attack: Back With A Vengeance

15. BrickerBot - Design
1. IPv4 TCP SYN probes for port 23
2. Brute force Telnet login attempts
3. Brick device
○ Erase disk partitions & files
○ Disable networking
○ Reboot
4. Connect to next device
○ Victim is not attacking other devices (gets bricked)
○ Static set of attacking devices (tens)
Attacking devices
(just 10s of them)
23
1. Scan
2. Login
admin/admin
3. Brick device
IP: 1.2.3.4

16. BrickerBot - Manifesto of claimed author
“[...] I was dismayed by the indiscriminate DDoS attacks by
IoT botnets in 2016. I thought for sure that the large
attacks would force the industry to finally get its act
together, but after a few months of record-breaking
attacks it became obvious that in spite of all the sincere
efforts the problem couldn't be solved quickly enough by
conventional means.”

17. BrickerBot - Summary
● Embedded Linux devices as attackers
○ Dropbear with Telnet
● Fixed set of attacker devices
○ Likely in just in the 10s
○ Cannot spread as it bricks the victim
● Exploited default credentials
○ username / password
● Target the same devices as Mirai and Hajime

18. Mirai Hajime BrickerBot
Discovered 2016, August 2016, October 2017, March
Purpose DDoS (profit?) Secure devices (?) “Secure” devices
(permanently)
Negative impact Internet-wide outages No significant (so far) 2 million bricked devices
Reconnaissance Async SYN, multi port Test port 23 Test port 23
Access Default user/pass Default user/pass Default user/pass
Architecture Centralized Distributed Centralized
Est. peak reach 600,000 30,000 - 200,000 2,000,000 (all time)
Est. attacking devices 600,000 30,000 - 200,000 <100
Malware summary

19. Attack vector Mirai Hajime BrickerBot
Remote login (port open)
Default credentials
Elevated privileges
Software exploit (vulnerability) New strains? New strains?
The attack vectors (even credential list) are almost identical!
Malware attack vectors

20. Improving motivation of device manufacturers
● The attack vectors are too trivial
○ Like Windows in the 90s
○ Can be significantly remediated with little effort
● Device manufacturers should be held accountable
○ It should not be end users!
○ Buyers can demand better security
● IoT Cybersecurity Improvement Act of 2017
○ Basic security for devices purchased by government
○ Covers all Internet-connected devices
○ Likely improves security of other sectors
○ Not passed to law yet
● More BrickerBot flavors?

21. ● It is always possible to compromise
● Lower Return on Investment (ROI) for attacker
○ Decrease value of successful attack
○ Increase cost of successful attack
● There are generic solutions to increasing cost of an attack
Your goal is to lower attacker Return on Investment

22. Action
1. Reconnaissance
2. Intrusion
3. Insert backdoor
4. Clean up
Desired outcome
➔ Discover vulnerabilities
➔ Initial access
➔ Ongoing access
➔ Avoid detection
Anatomy of an attack

23. Action
1. Reconnaissance
2. Intrusion
3. Insert backdoor
4. Clean up
Approach
➔ Distributed & fast portscan, especially telnet
➔ Default username/password list (64 combos),
CWMP exploit
➔ Detect environment, download & run binary
➔ Process name obfuscation, remove binaries
Anatomy of the three botnet attacks

24. Action
1. Reconnaissance
2. Intrusion
3. Insert backdoor
4. Clean up
Approach
➔ Distributed & fast portscan, especially telnet
➔ Default username/password list (64 combos),
CWMP exploit
➔ Detect environment, download & run binary
➔ Process name obfuscation, remove binaries
Default closed ports
Network segmentation
Random initial passwords
Service security updates
Principle of least privilege
Mitigating the botnet attacks

25. Action
1. Reconnaissance
2. Intrusion
3. Insert backdoor
4. Clean up
Approach
➔ Distributed & fast portscan, especially telnet
➔ Default username/password list (64 combos),
CWMP exploit
➔ Detect environment, download & run binary
➔ Process name obfuscation, remove binaries
Default closed ports
Network segmentation
Random initial passwords
Service security updates
Principle of least privilege
Some of the vendors had manual 1-by-1 updatability; passing the burden to the user (like your wifi router).
OTA updates can also address
currently unknown vulnerabilities.
OTA updates can mitigate most cases

26. ● Power loss during the update process
○ Atomic? Automated rollback?
● Secure communication (e.g. TLS, certs)
● Signed updates
● Homegrown seems easy?
Tesla hacked by security researchers
in September 2016
“Cryptographic validation of firmware
updates is something we’ve wanted to do
for a while[…]” - Tesla’s CTO JB Straubel
Vulnerability in Deutsche Telekom’s updater exploited
https://krebsonsecurity.com/2016/11/new-mirai-worm-knocks-900k-germans-offline/
We need robust and secure OTA updates

27. Let us remove the similarities with basic security hardening