Test Tools for IoT DDoS vulnerability scanning
draft-faibish-iot-ddos-usecases-06

TEEP WG                                                       S. Faibish
Internet-Draft                                Cirrus Data Solutions Inc.
Intended status: Informational                           M. K. Chowdhury
Expires: June 19, 2022                                   Deloitte Canada
                                                       December 19, 2021

               Test Tools for IoT DDoS vulnerability scanning
                   draft-faibish-iot-ddos-usecases-06
Abstract

   This document specifies several usecases related to the different
   ways IoT devices are exploited by malicious adversaries to
   instantiate Distributed Denial of Services (DDoS) attacks. The
   attacks are generted from IoT devices that have no proper protection
   against generating unsolicited communication messages targeting a
   certain network and creating large amounts of network traffic. The
   attackers take advantage of breaches in the configuration data in
   unprotected IoT devices exploited for DDoS attacks. The attackers
   take advantage of the IoT devices that can send network packets
   that were generated by malicious code that interacts with an OS
   implementation that runs on the IoT devices. The prupose of this
   draft is to present possible IoT DDoS usecases that need to be
   prevented by TEE. The major enabler of such attacks is related to
   IoT devices that have no OS or unprotected EE OS and run
   code that is downloaded to them from the TA and modified by
   man-in-the-middle that inserts malicious code in the OS. This draft
   adds list of MUD files for most IoT devices.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of Internet-Draft Shadow Directories can be accessed at
   https://www.ietf.org/standards/ids/internet-draft-mirror-sites/.

   This Internet-Draft will expire on June 19, 2022.    

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Faibish             Expires June 19, 2022                      [Page 1]

 
Internet-Draft   Usecases definition for IoT DDoS attacks December 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Usecases  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1. Upgradable OS less IoT devices . . . . . . . . . . . . . .   5
     4.2. IoT devices connected to a gateway server  . . . . . . . .   6
     4.3. Smart IoT devices with full OS . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7. References   . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Problems with IoT devices arise from the fact that manufacturers
   ship their devices with almost no security measures and the
   companies that buy these IoT devices don't have proper
   visibility/understanding of their networks with these new products.
   Applications executing in an IoT device are exposed to many different
   attacks intended to compromise the execution of the application, or
   reveal the data upon which those applications are operating. The
   problem is more acute for IoT devices that run low level of OS or no
   OS at all and have limited ability to prevent malicious network
   traffic leading to DDoS. These attacks increase with the number of
   applications running on the device, with such other applications
   coming from potentially untrustworthy sources or due to
   man-in-the-middle mangling with the application code inserting
   random packets in the communication of the IoT back to operator.

   The potential for attacks generated by these devices further
   increases with the complexity of features and applications on
   devices, with limited OS capabilities, running code that is
   downloaded from untrustworthy operators.

Faibish             Expires June 19, 2022                       [Page 2]

 
Internet-Draft  Usecases definition for IoT DDoS attacks   December 2021

   The danger of attacks on an OS-less system increases as the data
   transmitted by the devices to the operator increases. There is
   provision in the MUD protocol [RFC8520] to add security measures
   but it does not replace other security measures and only complement
   existing security measures if they are already in place.

   But for MUD to work, every IoT device requires a unique MUD-URL
   specific to the kind of device type/model and matches the needed
   configuration manifest. There is a MUD file that SHOULD be provided
   by the device manufacturing that contains instructions for the
   expected behavior of the device. For cheap OS-less devices the
   manufacturer does not always provide the accurate behavior and
   require the network routers to detect malicious traffic and stop
   it. Abnormal behavior could be limiting the peak request rate
   of how many requests per minute is normal for the device that is
   used as prevention control of DDoS. Unfortunately IoT devices
   manufacturers do not always generate MUD profiles specific to their
   devices or even their companies. MUD in itself is an important step
   towards securing IoT devices but it is not enough for preventing
   DDoS attacks.

   As an example, an IoT device that sends pollution data each minute
   from city wide sensors to a cloud application that analyses city air
   quality and generate reports and warning to the public can be used
   to send random data at much higher frequency like 1000 per second.
   This malicious transmission can shut down the cloud receiving this
   data. The worst part of this is that the IoT device OS has no idea
   that the transmission is wrong and is creating DDoS for the cloud
   used by the IoT devices. Additional there could be coordinated
   attacks coming from many IoT devices connected to the same cloud
   and shut down all the cloud services.

   In general case there is an edge server to which the IoT devices
   are connected and the server is managing the management of the
   data transmitted to the OA. In this case the edge server has an
   OS and a TEE that can prevent DDoS attacks that were generated
   by the IoT devices if the transmission is malicious. Moreover
   the edge server will facilitate the code upgrade and prevent
   malicious code being stored on the device code. So, the edge
   server will become the TEE for all the devices connected to it.
   Moreover if the code of the device is compromised the edge
   server will block the packets that were generated by the IoT
   devices connected to it.

   According to analysts study DDoS originated from IoT devices
   accounted for 90% of all the DDoS attacks and increased 10x
   in 2018 ([1]) and the majority of the attacks were from devices
   with limited compute and OS resources as well as webcams with REE.

Faibish             Expires June 19, 2022                       [Page 3]
Internet-Draft  Usecases definition for IoT DDoS attacks   December 2021

   This will require special TEE protocol support preventing the use
   of these devices for DDoS attacks. This draft is trying to present
   the usecases that enable such attacks with the intention to request
   that TEEP WG addresses this special security loophole. And the major
   problem resides in the inability of IoT devices to prevent
   broadcasting network packets generated by unauthorized code, inserted
   at upgrade time, to execute on devices with low compute capabilities.

   Trusted Execution Environments (TEEs), including Intel SGX, ARM
   TrustZone, Secure Elements, and others, can enforce that only
   authorized code can execute within the TEE, and any memory used by
   such code is protected against tampering or disclosure outside the
   TEE.  This observation is only true if there is awareness that IoT
   devices are enabled to send data back to the cloud and or the SP
   that did the upgrade. In such environments malicious code includes
   a method of external triggered or time based attacks.

   In most such devices there is none or limited "Trusted Agent" or
   "Trusted Application Manager (TAM)" on the client side running
   inside the TEE. The purpose of this draft is to present 3 DDoS
   usecases that TEEP needs to address prevention of using the IoT
   devices as the origin of such attacks.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document also uses various terms defined in
   [I-D.ietf-teep-architecture], including Trusted Execution Environment
   (TEE), Trusted Application (TA), Trusted Application Manager (TAM),
   Agent, and Broker.

3. Assumptions
   This draft assumes that an applicable device may or may not be
   equipped with any TEEs nor pre-provisioned with a device-unique
   public/private key pair, which is securely stored.

   A TEE uses an isolation mechanism between Trusted Applications to
   ensure that one TA cannot read, modify or delete the data and code of
   another TA. We also assume that there can be a TEE running in a edge
   server to which the devices may be connected. The edge server will
   include such a TEE and will become the secure gateway as
   client/agent.

Faibish             Expires June 19, 2022                       [Page 4]
Internet-Draft  Usecases definition for IoT DDoS attacks   December 2021

4. Usecases

4.1 Upgradable OS less IoT devices

   The simplest IoT device we refer to here is a device that has enough
   OS and EE to perform a single function like sending back to the
   broker time series at given time intervals, Figure 1. As an example
   an IoT device that monitors the air quality in a city and send back
   to the cloud this data that will be aggregated with many sensors
   around the city. The device will run simple code that can be executed
   on the device and at a minimum it will be capable to receive and
   install code upgrades from the Broker. Such devices have very
   limited or no security or trust protection and it can be exposed
   to man-in-the-middle attacks target by malicious actors that are
   trying to insert malicious code MA (Malicious Application) in the
   upgraded code.

   One example of such code may include a trigger, that can be activated
   in a similar manner as the code upgrade request, and used to start
   DDoS attacks coordinated as a cluster. As the device function is to
   send time series data to the cloud the malicious code can send same
   data 1000s of times fludding the recipient cloud from all the devices
   in the cluster. As a second example the malicious code can use a
   timer and start sending empty network packets back to the provider
   network and also targeting a given IP address of a victim. Such
   examples are attackes related to Mirai botnets also in [2] as
   similar attacks were uncovered tergeting for example financial
   institutions in order to hide cyberattacks for stilling money or
   even crypto-currency.
   +-------------------------------------------+
   | Device                                    |
   |                                           |        Service Provider
   |                                           |                  |
   |    +-------------+                        |      +--------+  |
   |    | TEE         |<------------------------------|        |<-+
   |    |             |                        |      |  TAM   |
   |    |             |                        |      |        |<-+
   |    | +---+ +---+ |                        |      +---+----+  |
   |    | |MA | |TA | |                        |          |       |
   |    | |   | |   | |        +-------+       |          |       |
   |    | |   | |   |<---------| App   |<-----------------+       |
   |    | +-+-+ +-+-+ |        |       |       |               Device
   |    +---|-----|---+        +-------+       |           Administrator
   +--------|-----|----------------------------+
            |     +---------------------------------> Legitimate traffic
            |
            +---------------------------------------> DDoS traffic

                  Figure 1: OS less IoT devices diagram

Faibish             Expires June 19, 2022                      [Page 5]
Internet-Draft Usecases definition for IoT DDoS attacks  December 2021

4.2 IoT devices connected to a gateway server

   In this case the OS less IoT device is connected to a local edge
   TEEP server which has rich execution OS and acts as a bridge between
   the device and the cloud collecting the time series from the device.
   In this usecase the upgrades are done via the edge gateway server
   that has full TEEP capabilities and can detect DDoS attacks and
   prevent the DDoS traffic to escape outside the edge server. For
   example the edge gateway server could be a computer with full
   security protection or a mobile device such as a tablet or even a
   cell phone. We assume that in this case the edge server has a full
   TEE and can manage several IoT devices running multiple different
   applications. We also assume that the edge server is connected to
   a TEEP Broker. For example webcams can be such IoT devices connected
   to gateway server used for DDoS attacks [1] spoofing [4]. A list of
   such IoT devices MUD files is found in [3] used by python tool [5]
   to test vulnerabilities is available.

                                   +--------------> Legitimate traffic
   +-------------------------------|-----------+
   | Edge gateway                  |           |
   |                          +----+---+       |        Service Provider
   |                          |        |----------+               |
   |    +-------------+       | TEEP   |       |  |               |
   |    | Device      |<------| Broker |       |  |   +--------+  |
   |    |       DDoS  |       |        |       |  +-->|        |<-+
   |    |   +---------------->|blocked |       |      |  TAM-1 |
   |    |   |  traffic|blocked|        |<-+    |      |        |<-+
   |    | +-+-+ +---+ |       +--------+  |    |      +--------+  |
   |    | |MA | |TA | |                   |    |                  |
   |    | |   | |   | |        +-------+  |    |                  |
   |    | |   | |   |<---------| App   |--+    |                  |
   |    | +---+ +---+ |        |       |       |    Device Administrator
   |    +-------------+        |       |       |
   |                           |       |       |
   |                           +-------+       |
   |                                           |
   |                                           |
   +-------------------------------------------+

            Figure 2: OS less IoT devices connected to gateway server

   In this scenario the DDoS traffic is only generating network traffic
   inside the edge limits and can be stopped by the TEE inside the
   server. For example when an edge server is connected to home
   appliances such as home temperature control or electricity and water
   meters that are supposed to send time series to the cloud,
   triggering a DDoS will not be allowed to send packets outside the
   gateway limits.

Faibish             Expires June 19, 2022                      [Page 6]
Internet-Draft Usecases definition for IoT DDoS attacks  December 2021

   It can still prevent sending the sensing data to
   the cloud destination but TEEP will prevent DDoS traffic outside
   the edge server. Additional to this using TEEP will prevent
   code upgrades done from untrusted sources and even detect
   malicious code to install on the device. In this configuration
   (Figure 2) SPs do not directly interact with devices. DAs may
   elect to use a TAM for remote administration of TAs instead of
   managing each device directly. Moreover the Legitimate traffic
   can be sanitized to prevent malicious code spread to other devices.

4.3 Smart IoT devices with full OS

   The Internet of Things (IoT) has been posing threats to networks and
   national infrastructures because of existing weak security in
   devices. But there are IoT devices and systems that have the OS
   and compute power to detect and prevent malware for generation DDoS
   attacks. It is possible that for such devices can implement measures
   to prevent malware from manipulating actuators (e.g., IoT controlling
   computer assisted automobiles or self driving cars), or forcing such
   cars into accidents and damage infrastructures and even lose life.

   Such an experiment was done in the research communities and there was
   even a contest about how fast hackers can take control of a car
   using automatic driving. The results were that the current security
   of such cars is not strong enough to prevent taking control over the
   internet. A TEE can be the best way to implement such IoT security
   functions for "smart" environments using advanced OSes such as cars.

   TEEs could be used to store variety of sensitive data for IoT
   devices. For example, a TEE could be used in smart cars to
   store a driver's biometric information for identification, available
   in some new cars, and for protecting access driving wheel control
   mechanism. Figure 3 presents the architecture of such a self
   driving car. In this usecase the applications run inside the TEE and
   are connected to the service provider's cloud similar to some
   "connected" cars (BMW for example). The applications running inside
   the TEE can be either monitoring functions or car status (TA1) or
   diagnostic malfunctions (TA2). All these applications can be vital to
   the operation of the car and the safety of the drivers and roads.
   In general in this usecase the Service provider and the Device
   Administrator are represented by the vehicle manufacturer during
   the warranty time and after that they can be a different service
   provider doing maintenance.

   There are additional usecases similar to this one like electric
   power and grid monitoring and control that have rich compute and
   memory resources running in a centralized location (secure) or
   in the cloud (unsecure) but need high levels of security.

Faibish             Expires June 19, 2022                       [Page 7]
Internet-Draft  Usecases definition for IoT DDoS attacks  December 2021

   +-------------------------------------------+
   | Device                                    |      Car Manufacturer
   |                          +--------+       |   or Service Provider
   |                          |        |----------+               |
   |    +-------------+       | TEEP   |---------+|               |
   |    | TEE-1       |<------| Broker |       | ||   +--------+  |
   |    |             |       |        |<---+  | |+-->|        |<-+
   |    |             |       |        |    |  | |  +-|  TAM-1 |
   |    |             |       |        |<-+ |  | +->| |        |<-+
   |    | +---+ +---+ |       +--------+  | |  |    | +--------+  |
   |    | |TA1| |TA2| |                   | |  |    | TAM-2  |    |
   |  +-->|   | |   | |        +-------+  | |  |    +--------+    |
   |  | | |   | |   |<---------| App-2 |--+ |  |                  |
   |  | | +---+ +---+ |    +-------+   |    |  |       Car Manufacturer
   |  | +-------------+    | App-1 |   |    |  |
   |  |                    |       |   |    |  |
   |  +--------------------|       |---+    |  |
   |                       |       |--------+  |
   |                       +-------+           |
   +-------------------------------------------+
         Figure 3: OS capable IoT devices for connected cars

   There are additional security models of IoT devices that can fit
   in these 3 examples and we will extend the protocols to apply to
   as many as we can consider as useful.

5. Security Considerations

   Although TEEP architecture document [I-D.ietf-teep-architecture]
   addresses some IoT devices examples there are IoT usecases that
   require more detailed design and better definitions of the Broker
   behavior in different usecases discussed in this draft. As such,
   Broker implementations MUST support many of this usecases critical
   for security and safety.

6. IANA Considerations

   This document does not require actions by IANA.

7. References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

Faibish             Expires June 19, 2022                       [Page 8]
Internet-Draft  Usecases definition for IoT DDoS attacks  December 2021

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8520]  Lear, E., Droms, R. and Romascanu, D., "Manufacturer
              Usage Description Specification", March 2019,
              <https://www.rfc-editor.org/rfc/rfc8520.txt>

7.2.  Informative References

   [1]        Vlajic, N., and Zhou, D., "IoT as a Land of Opportunity
              for DDoS Hackers", Computer Magazine, July 2018, pp.
              26-34.

   [2]        Kolias, C., Kambourakis, G., Stavrou, A., and Voas, J.,
              IP Spoofing In and Out of the Public Cloud: From Policy
              to Practice,

   [3]        MUD files for testing DDoS vulnerabilities of IoT devices,
              https://iotanalytics.unsw.edu.au/mudprofiles/

   [4]        Vlajic N., Chowdhury M., and Marin Litoiu,
              "IP Spoofing In and Out of the Public Cloud: From Policy
              to Practice", Computers
              2019, 8(4), 81; https://doi.org/10.3390/computers8040081

   [5]        IoT devices scanner for DDoS vulnerabilities test tool,
              python code, https://github.com/mashrufkabir/IoTScanner

   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig H., Thaler, D., Wheeler, D.,
              "Trusted Execution Environment Provisioning (TEEP)
              Architecture", draft-ietf-teep-architecture-15 (work in
              progress), July 2021.

Acknowledgments

   This draft has attempted to capture many IoT security usecases known
   to the author and presented in the literature as well as discussed
   in the security forums. These usecases present challenges both for
   DDoS attacks that became critical as well as applied security for
   new autonomous devices. We proposed to add these usecases to the
   TEEP Architecture draft.

Faibish             Expires June 19, 2022                       [Page 9]
Internet-Draft  Usecases definition for IoT DDoS attacks  December 2021

Author's Address

   Sorin Faibish
   Cirrus Data Solutions Inc.
   11 Selwyn Road
   Newton, MA  02461
   United States of America

   Phone: +1 617-510-0422
   Email: sorin.faibish@cdsi.us.com

   Mashruf Kabir Chowdhury
   Deloitte Canada
   Apt 2112 - 70 Temperance St
   Toronto, Ontario M5H 0B1
   Canada

   Phone: +1-416-388-5146
   Email: mashrufkabir@icloud.com

Faibish             Expires June 19, 2022                      [Page 10]