Awesome IOT hacks repost

Mirroring from https://github.com/nebgnahz/awesome-iot-hackss for easy access.

A curated list of hacks in IoT space so that researchers and industrial products can address the security vulnerabilities (hopefully).

Thingbots

RFID

Home Automation

Connected Doorbell

Hub

Smart Coffee

Wearable

Smart Plug

Cameras

Traffic Lights

Automobiles

Airplanes

Light Bulbs

Locks

Smart Scale

Smart Meters

Pacemaker

Thermostats

Fridge

Media Player & TV

Toilet

Toys

Software Defined Networking Security

Software Defined Networking seeks to centralize control of a large network. The abstractions around computer networking evolved from the connecting nodes via switches, to applications that run on top with the OSI model, to the controllers that manage the network. The controller abstraction were relatively weak – this had been the domain of telcos and ISPs, and as the networks of software intensive companies like Google approached the size of telco networks, they moved to reinvent the controller stack.  Traffic engineering and security which were done in disparate regions were attempted to be centralized in order to better achieve economies of scale. Google adopted openflow for this, developed by Nicira, which was soon after acquired by VMWare; Cisco internal discussions concluded that such a centralization wave would reduce Cisco revenues in half, so they spun out Insieme networks for SDN capabilities and quickly acquired it back. This has morphed into the APIC offering.

The centralization wave is a bit at odds with the security and resilience of networks because of their inherent distributed and heterogenous nature. Distributed systems provide availability, part of the security CIA triad, and for many systems availability trumps security. The centralized controllers would become attractive targets for compromise. This is despite the intention of SDN, as envisioned by Nicira founder M. Casado, to have security as its cornerstone as described here. Casado’s problem statement is interesting: “We don’t have a ubiquitous and horizontal security layer that provides both context and isolation. Where do we normally put security controls? We put it in one of two places. We might put it in the physical infrastructure, which is great because you have isolation. If I have ACLs [access control lists] or a firewall or an IDS [intrusion detection system], I put it in a separate box and I put it away from the applications so that the attack surface is pretty small and it’s totally isolated… you have isolation, but you have no context. ..  Another place we put security is in the end host, an application or operating system. This suffers from the opposite problem. You have all the context that you need — applications, users, the data being accessed — but you have absolutely no isolation.” The centralization imperative comes from the need to isolate and minimize the trusted computing base.

In the short term, there may be some advantage to be gained by complexity reduction through centralized administration, but the recommendation of dumb switches that respond to a tightly controlled central brain, go against the tenets of compartmentalization of risk and if such networks are put into practice widely they can result in failures that are catastrophic instead of isolated.

What the goal should be is a distributed system which is also responsive.

Lessons from SF Muni Ransomware

On Nov 25, a hacker going by “andy saolis” infected the San Francisco Municipal Transportation Agency’s (SMFTA) network with ransomware that encrypted data on 900 office computers, spreading through the system’s Windows operating system. Saolis threatened to publish 30 gigabytes of data, including contracts, employee data, customer information.  SMFTA’s ticketing system was shut down to prevent the malware from spreading. The attacker demanded a 100 Bitcoin ransom, around $73,000, to unlock the affected files. Salted hash reported the malware is likely a variant of HDDCryptor, which uses commercial tools to encrypt hard drives and network shares.

The service was restored due to backups . However consider these systems were in an ICS scenario. An unexpected downtime would result, which would be unacceptable.

Containers and Privileges

Cgroups limit how much you can do. Namespaces limit how much you can see.

Linux containers are based on cgroups and namespaces and can be privileged or unprivileged. A privileged container is one without the “User Namespace” implying it has direct visibility into all users of the underlying host. The User Namespace allows remapping the user identities in the container so even if the process thinks it is running as root, it is not.

Using cgroups to limit fork bombs from Jessie’s talk:

$ sudo su
# echo 2 > /sys/fs/cgroup/pids/parent/pids.max
# echo $$ > /sys/fs/cgroup/pids/parent/cgroups.procs  // put current pid
# cat /sys/fs/cgroup/pids/parent/pids.current
2
# (echo "foobar" | cat )
bash: for retry: No child processes

Link to the 122 page paper on linux containers security here.  Includes this quote on linux kernel attacks.

“Kernel vulnerabilities can take various forms, from information leaks and Denial of Service (DoS) risks to privilege escalation and arbitrary code execution. Of the roughly 400 Linux system calls, a number have contained privilege escalation vulnerabilities, as recently as of 2016 with keyctl(2). Over the years this included, but is not limited to: futex(2), vmsplice(2), mremap(2), unmap(2), do_brk(2), splice(2), and modify_ldt(2). In addition to system calls, old or obscure networking code including but not limited
to SCTP, IPX, ATM, AppleTalk, X.25, DECNet, CANBUS, Econet and NETLINK has contributed to a great number of privilege escalation vulnerabilities through various use cases or socket options. Finally, the “perf” subsystem, used for performance monitoring, has historically contained a number of issues, such as perf_swevent_init (CVE-2013-2094).”

Which makes the case for seccomp, as containers both privileged and unprivileged can lead to bad things –

““Containers will always (by design) share the same kernel as the host. Therefore, any vulnerabilities in the kernel interface, unless the container is forbidden the use of that interface (i.e. using seccomp)”- LXC Security Documentation by Serge Hallyn, Canonical”

The paper has several links on restricting access, including grsecurity, SELinux, App Armor and firejail. A brief comparison of the first three is here. SELinux has a powerful access control mechanism – it attaches labels to all files, processes and objects; however it is complex and often people end up making things too permissive, instead of taking advantage of available controls.  AppArmor works by labeling  files by pathname and applying policies to the pathname – it is recommended with SUSE/OpenSUSE, not CentOS.  Grsecurity policies are described here, its ACLs support process–based resource restrictions, including memory/cpu/files open, etc.

Blockchain ideas

I think of bitcoin as a self-securing system. Value is created by solving the security problem of verifying the last block of bitcoin transactions. This verification serves as a decentralized stamp of approval, and the verification step consists of hashing a nonce and a block of transactions through a one way hash function and arriving at a checksum with a certain structure (which is hard because hash is random and meeting the structure requirement is a low probability event).

What happens if parties collude to get greater hashing power and increase their share of mining ? This is what happened with GPU mining farms on bitcoin. It was one of the motivations behind Ethereum, which enables code to run as part of transactions, and for the hashing algorithm to be not easily parallelized over a GPU. But it is not economical to mine on desktops as the motivation seems to suggest.

The important aspect I think is the self-securing idea – how can a set of computational systems be designed so that they are incentivized to cooperate and become more secure as a result of that cooperation.

At a recent blockchain conference, some interesting topics of discussion were zero knowledge proofs, consensus algorithms,  greater network-member-ownership in a network with network-effects instead of a centralized rent collection, game theoretic system designs and various etherereum blockchain applications.

The Dyn DNS DDOS Attack Oct 21

DYN is a DNS provider internet infrastructure company. It’s the name behind widely used DynDNS. It supports DNS for twitter, visa, github, mongo, netflix and several other big tech sites.

Doug Madory a researcher at DYN, presented a talk  on DDoS attacks in Dallas at a meeting of the North American Network Operators Group (NANOG) 68 – his was the last talk on Oct 19, wednesday. The talk discussed the attack on Krebs on Security last month and details other such attacks.

On Friday several sites serviced by DYN were attacked in a distributed denial-of-service (DDoS) attack.

The distributed denial-of-service (DDoS) attack involved malicious DNS lookup requests from tens of millions of IP addresses including a botnet on a large number of IoT devices infected with the Mirai malware, which is designed to brute force security on any IoT device. There are cameras involved with fixed passwords that are burned into the firmware, that cannot be changed.

The implications of IoT devices that are 1) unsecure 2) impossible to secure and 3) infected by malware and 4) controlled by a botnet that is controlled by malicious intent are made clearer with this attack.