Unconfigured Ad Widget

Collapse

Anúncio

Collapse
No announcement yet.

IoT security from entry to entry

Collapse
X
 
  • Filter
  • Tempo
  • Show
Clear All
new posts

  • Font Size
    #1

    Dica IoT security from entry to entry

    Author: 0431 Laboratory
    Public number: Jilin letter Core Network

    IoT Security-Part 1 (101-Introduction and Architecture of the Internet of Things)
    For security researchers, the problem with every new complex technology is that it doesn't know where to start and how / where to launch the attack. This is a common problem and has a common solution, which is to break down the technology into multiple small components and start learning each component separately. This process gives you a grasp of each component and guides you to focus on the most interesting components

    IoT! = Hardware
    This is a common misconception that the Internet of Things refers only to hardware, which creates imaginary obstacles and makes most security researchers unwilling to get involved in IoT security. Yes, it involves hardware, and you can learn the skills you need to analyze hardware. If it helps, "IoT security research is not difficult", but it requires dedication and willingness to learn. As you read this blog post, you will realize that hardware constitutes only a third of the IoT ecosystem. Most importantly, if you can break other components (for example, the Cloud), you can not only invade the device, but also cause even greater damage.

    Introduction
    What is the Internet of Things?
    There are many definitions of the Internet of Things on the Internet, and the key to mastering a technology is to understand the basic ideas behind it, which helps define your own meaning and applicability. Everyone can have their own definition. For me, the Internet of Things mainly involves three things:

    1. Automation: In the face of reality, we are lazy, and the future is to make us more lazy and automate tasks that we complete manually.

    2. Virtual physical world interface: build a bridge between the physical world and the virtual world. In short, it allows the virtual world to read from and write to the physical world. When I say read, I mean sensing the physical environment and converting the state into data, and sending it to a virtual data store for further analysis, such as temperature sensors, medical sensors, cameras, etc. The writing method is to control the physical world through actions, that is, to convert data into actions in the real world, such as door locks, controlling vehicle operation, water spray, medical pumps, etc. You will understand.

    3. Insight and decision-making ability: can analyze the data collected from the equipment in real time to better understand the environment, take action on certain events, find the root cause of any physical world problem, etc.

    As a result, IoT technology provides end users and suppliers with real-time information and automation of the task at hand.

    Based on the definition above, if we were to create a technology to solve this problem, we would need

    Hardware device providing virtual physical interface
    Back-end data storage area for storage and computing power for statistical analysis of data.
    A virtual interface for users to view the analyzed data and send commands to the physical world.
    The first is solved by embedding economical hardware devices into the corresponding sensors / controllers, the second is easily solved by the cloud, and the last third is easily solved by mobile and / or web applications.

    Where is the Internet of Things used?
    As I mentioned above, the Internet of Things is what makes us fat and lazy. Human beings are good at innovation, and for whatever reason, we can find areas for improvement in an almost perfect system. In today's world, the use of IoT technology is unlimited. I bet if you look around you might think of an IoT idea. Currently, the Internet of Things has many innovations in various fields, and its sole purpose is to achieve automation and real-time data analysis from the physical world.

    Home automation
    Intelligent infrastructure
    medical insurance
    Industrial control system
    transport
    Utilities
    there are more
    IoT architecture
    High-level vision
    The IoT architecture includes three components in its simplest form, as shown in the following figure.

    mobile
    cloud
    device
    upload successful

    Communication between components depends on the purpose and / or type of IoT product. Here are some examples that will make it clear how and why components don't talk to each other.

    The device can only make mobile calls-for example. BLE-based device

    The device only talks to the IoT gateway – for example. ZigBee, wireless HART devices, etc.

    Mobile only talks to the cloud – if the user does not have proximity access to the device and can only be controlled through the cloud.

    Functional architecture
    The functional architecture can be further extended to define a sensor network that communicates with the cloud and mobile / web interfaces via the Internet. Where traditional TCP / IP-based technologies cannot be implemented, the sensor may have its own network or, where traditional networks cannot be implemented and radio communication provides higher efficiency and meaning, radio-based networks. In the latter case, a gateway (our IoT gateway / hub / router) is needed to serve as the interface between radio communication and traditional TCP / IP communication. From now on, I will refer to TCP / IP as traditional networking / communication.

    upload successful

    We can also have geographically dispersed sensor networks that can communicate / connect with each other through traditional networks through IoT gateways, as shown below.

    upload successful

    Layered model
    If we look at the Internet of Things technology from a layered perspective, we can define it as the 3 simple layers that form the core of the Internet of Things

    Sensing layer-consists of hardware sensors and sensor networks.

    Communication layer-It consists of a communication mechanism that allows the sensor layer to communicate with the management layer, for example-Wifi, 3G, LTE, Ethernet, etc.

    Management-This is the top level, responsible for figuring out the meaning from the raw data and providing users with a beautifully presentable view. It includes cloud, storage, applications, etc.

    upload successful

    IoT Security-Part 2 (102-IoT Attack Surface)
    Now we can easily isolate the various components of the IoT and try to define attack surfaces for each component separately, and then combine them to create a holistic overview. Attack surface of the IoT ecosystem. I call it an IoT ecosystem, not an IoT product, because it is really an ecosystem where different components talk to each other and solve specific real-world problems. Let us continue to define the attack surface of the IoT ecosystem and discuss the attack surface of each component in detail. The attack surface by component can be divided into three or four (if we use communication as the attack surface). The main areas are as follows:

    mobile
    cloud
    communication
    device
    upload successful

    OWASP has also done a lot of work on IoT security. They also define attack surfaces. Hope everyone can read it well. Understanding different ideas is a good thing because it helps you create your own comprehensive attack surface.

    note
    Unless specifically stated otherwise, the general term "microcontroller" means a microcontroller, microprocessor, or SoC (system on a chip).

    The attack surface below is our definition and may differ from other sources.

    mobile
    Mobile is one of the important user interfaces of the Internet of Things, through which end users can gain insight into the state of the physical world. Since mobile applications communicate with the IoT ecosystem to send commands and read data, it becomes one of the entry points for the IoT ecosystem. We will try to list the attack surface of mobile devices from an IoT perspective

    storage
    Certification
    encryption
    communication
    Universal Mobile Vulnerability-Think of OWASP Mobile Top 10
    cloud
    The cloud is one of the important components of the Internet of Things, and usually data from all instances of the product line are gathered here. This makes it a very interesting point of attack. Remember, I mentioned in the last article that the Internet of Things is not just about hardware. The reason is that the cloud will save data for all deployed IoT instances and has the privilege to send commands to all instances. Usually it is initiated by the user, but if compromised, an attacker would gain control of globally deployed devices (and their data), which is dangerous. Overall, the attack surface focuses on the interfaces it provides, including

    storage
    Certification
    encryption
    communication
    bee
    Universal Web / Cloud Vulnerability-Think of OWASP Web Top 10
    device
    Next is the device, which is a game changer for IoT technology . It interacts with the physical world and communicates with the virtual world. This is the first stop of the physical world data. Given the sensitive user data (such as house data, physical data, personal information) stored around user privacy, there is an entire debate around user privacy. In the future, the device may use the user's cryptocurrency to purchase items, perform repairs, etc. directly through its wallet or a separate temporary wallet. The attack surface looks like this

    storage
    Certification
    encryption
    communication
    Sensor interface
    Peripheral interface
    Hardware interface
    HMI
    communication
    Although this is not a tangible attack surface, ideally the tangible attack surface will be the communication interface and the various drivers / firmwares responsible for communication. However, this requires a separate part because the list of communication protocols that the IoT ecosystem can use on both wired and wireless media is large. The following are some of the areas that constitute a communication attack surface.

    Certification
    encryption
    Deviation from protocol standards
    Protocol implementation exception
    The hardware interface allows actual communication. However, the actual data communication / data packet is defined by the upper layers implemented in the software. Therefore, in this "attack surface area" (communication), we will only discuss protocols. Although flaws in the protocol can lead to attacks on protocol endpoints residing on mobile devices, devices or the cloud, we keep them as a separate attack surface for clarity. There are too many criteria to mention in this list. However, we will list some common protocols used in various IoT products.

    Website
    The web or technical term HTTP (S) is the most common protocol used for communication and is used everywhere. Due to the large attack surface on the network, we make a separate entry for this purpose. However, the good news is that because of more than two decades of research, attack surfaces, vulnerabilities, and mitigation techniques have been basically standardized. There are numerous resources online that describe attacks and protection in detail. For starters, OWASP does a good job with its Web Top 10, testing guides, and various open source tools ( Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ) .

    2. Other
    In addition to networking, there are many protocols, some are domain-specific, some are general, and some are for efficiency reasons. There are too many protocols to list here for brevity. For simplicity, we will list some common protocol standards to give you a clear understanding of the types of protocols used. History tells us that all protocols have their implementation flaws, protocol design flaws, and configuration flaws. These need to be analyzed in penetration tests.

    CoAP – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    MQTT – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    AMQP – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    WebSocket – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    CANbus – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    Modbus – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    Profibus – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    DNP3 – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    BACNet – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    HL7 – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    XMPP – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    UPnP – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    DNS
    SSH
    <Your name is here>
    The above should give you a comprehensive overview of the attack surface of the IoT ecosystem. Now that we have a clear idea about this, let's define a detailed attack surface for the device so we know exactly what we need to attack in a standard IoT penetration test. This also helps IoT security designers create threat models for IoT products.

    Please note that we will not (re) define the attack surfaces of Mobile and Cloud, because you can find a lot of resources on the Internet that describe the same content. The purpose of this blog series is to build a bridge for IoT security for security researchers, so we will focus on knowledge that is currently not available or structured. Whereas we will still discuss mobile and cloud security related to the IoT ecosystem from our perspective

    Device attack surface
    OK, let's do this . The following is a separate structured definition of the IoT attack surface. Please note that this is our understanding and not obtained from other sources.

    Storage
    Storage space used by the device. This can be further divided into internal and external, persistent and volatile.

    1.1 SD card
    SD cards are often used to store configuration and product data. They can also be used to store firmware updates. This is a very interesting attack surface, and we will discuss some of the attacks that can occur through SD cards in a future blog post.

    1.2 USB
    Some products may use a USB drive to store data similar to an SD card, and to read data that has been downloaded or stored on a USB drive. Similar attacks to SD cards also apply to USB storage devices.

    1.3 Non-volatile memory
    These are used for a variety of purposes, including reading / writing sensor data, bootloaders, firmware, credentials, keys, and more. When testing a hardware board, it is important to look at the data stored on the chip. We can also perform runtime analysis of the communication between the memory and the microcontroller to analyze the type of data stored / read during different operations. This can be achieved by having the logic analyzer sniff the bus communication. When triggering specific actions on your device, you will find interesting data being read / written. There are several types of memory chips:

    EPROM
    EEPROM
    Flash – more commonly used due to its speed and efficiency
    upload successful

    I2C serial EEPROM

    1.4 Volatile memory
    When it comes to volatile memory, the word "RAM" comes to mind immediately. They are widely used in PC and embedded systems and save code and data at runtime. Data will be lost when the device is powered off. Some common RAM types are as follows

    SRAM (Static Random Access Memory)-A type of RAM used to hold data that is lost in the event of a power failure.
    DRAM (Dynamic Random Access Memory)-Data is retained for a period of time until lost, unless refreshed at runtime. This means that compared to SRAM, even during chip power-up, the life of the data is very short. When the chip is powered off, data is also lost.
    1.5 Microcontroller Internal Memory
    The microcontroller also has its own internal memory, which is usually used to store code. These memories are usually accessible when debugging a microcontroller, such as through JTAG. The various memories used in the microcontroller are:

    SRAM
    EEPROM
    flash
    2.Hardware communication interface
    Different hardware components on the same board need to communicate with each other and talk to the outside world. All of this communication is done using well-defined standard hardware communication protocols. From an attacker's perspective, it can give them insight into the actual communication by sniffing or injecting malicious data. You should analyze some of the most common interfaces mentioned below to identify security issues.

    2.1 UART
    UART (Universal Asynchronous Receiver Transmitter) is a hardware component that allows asynchronous serial communication between two hardware peripherals. They can be on the same board (such as a microcontroller that talks to a motor or LED screen) or between two different devices (such as a device microcontroller that talks to a PC). This is an interesting attack surface because it may allow read / write access to the device in a serial manner. In many devices, the UART port on the board remains open, and anyone can connect and access through the serial port to get some type of console, such as a simple shell, a custom command-line console, and log output Wait. Devices usually have a set of pins with outputs connected to the microcontroller's UART RX and TX pins for sending and receiving serial data.

    upload successful

    Typical 4-pin UART port

    2.2 MCU debug port
    The microcontroller has provisions for debugging at runtime using specified pins, which are connected to the pin outputs on the board. These pins (ports) are used by developers and designers to debug, read / write firmware and microcontroller internal memory, and control / test microcontroller pins after production. Given the capabilities and access rights provided by the debug port to an attacker, this makes the debug port one of the most critical attack surfaces. Some standard interfaces for this purpose are as follows:

    JTAG (Joint Test Action Group): As microcontrollers and PCBs get smaller, it becomes more and more difficult to test them after production. Therefore, in order to effectively test circuit boards after production, the electronics industry created an eponymous association and defined a method for testing circuit boards after production. It was later adapted to IEEE Standard 1149.1. The JTAG protocol defines standard interfaces and commands that can be used to test and debug microcontrollers. JTAG defines four pin interfaces (and an additional optional pin TRST):
    TMS-test mode selection
    TCK-test clock
    TDI-test data entry
    TDO-test data output
    TRST-test reset (optional pin)
    In addition to the test chip, the debugger also uses these pins to communicate with the TAP (test access port) implemented on the microcontroller. From a security perspective, identifying and connecting to the JTAG port can allow an attacker to extract firmware, reverse engineer logic and flash malicious firmware on the device. More information will be provided in future blog posts in the future.

    cJTAG (Compact JTAG): This is a new JTAG protocol defined in the standard IEEE 1149.7. It will not replace the 1149.1 standard, but will further extend it and be backward compatible with JTAG. It defines two-pin interfaces (TCK and TMS) and a new TAP that implements new functions.

    SWD (Serial Wire Debugging): SWD is another interface / protocol for debugging microcontrollers. It is a two-pin interface: a. SWDIO (bidirectional) b. SWCLK (Clock) This is an ARM-specific protocol, using the ARM CPU standard two-way wired protocol defined in the ARM debug interface v5. The benefit of SWD is that it claims to be more effective than JTAG.

    upload successful

    How does the JTAG port look on the PCB

    Note that the JTAG port is not necessarily 10 pins as shown in the figure above.

    2.3 I2C
    Inter-integrated circuit is a short-range communication protocol used for communication between chips on the same board. It was invented by Philips (now NXP). It has a master-slave (multi) architecture and uses a two-wire bus

    SDA-Serial Data
    SCL-Serial Clock
    One use case for I2C is in an EEPROM chip, which is connected to the microcontroller's I2C pin, and typically stores data or code. Typical attacks include tampering with data, extracting sensitive information, and destroying data. We should analyze the static data on the EEPROM chip and perform runtime analysis by sniffing the I2C communication to understand the behavior and security risks. As mentioned earlier, we will write a blog post in a series of articles to understand and analyze I2C communication.

    2.4 SPI
    The serial peripheral interface is also a short-range communication protocol for communicating between chips on the same board. It was developed by Motorola. It is full-duplex and uses a master-slave structure (single master server). Compared with I2C, it also has higher throughput. It uses a four-wire serial bus:

    SCLK-serial clock. Other names include SCK
    MOSI-Master output slave input. Other names include SIMO, SDI, DI, DIN, SI, MTSR.
    MISO-Master in and slave out. Other names include SOMI, SDO, DO, DOUT, SO, MRST.
    SS-Slave selection. Other names include S? S ?, SSEL, CS, C? S ?, CE, nSS, / SS, SS #
    It is used to communicate with various peripheral devices. Flash and EEPROM chips also use SPI. The test and analysis method is similar to I2C, except that we have different bus interfaces. We will discuss SPI in detail in a later blog post.

    2.5 USB
    The device can have a USB (micro / micro, etc.) interface for charging or communication. For the latter, it is necessary to test known or unknown issues with the interface. We should sniff the communication for runtime analysis and obscure unknown errors in the USB interface.

    2.6 Sensor
    This is a loose name, and we mean the interface to the physical world. It may not necessarily be limited to a sensing type interface. For example, a temperature sensor would be a perfect example, but a door lock will not sense anything except the "Lock / Unlock" action that controls the physical world. According to their operation, they can be divided into three types:

    Monitor: This is more closely tied to the literal meaning of the sensor, which is to sense or monitor any change in the physical world. Explosion-proof. Temperature, exercise, pulse, blood pressure, tire pressure, etc.

    Control: These types of devices control the physical world in some way. Explosion-proof. Locks, distributors, etc.

    Hybrid: This is a combination of the above two types, such as temperature control, lighting based on the time of day, etc. This is one of the key interfaces because all values ​​and data obtained from the physical world are transferred to the cloud. If an attacker can force the device with wrong (wrong) data, the entire ecosystem will be affected, because all decisions and statistics are based on this data. In other words, this is the key to the IoT ecosystem. Incorrect values ​​can have catastrophic effects on decisions made by the ecosystem.

    2.7 HMI
    Like the sensor interface, we use HMI as a general term to define the interface between the user and the device, and not limited to the term used in industrial control systems. This is the interface that users can use to communicate with and operate directly on the device. Some common examples are touch screens, buttons, touch pads, etc. It is important to test this interface for any bypass mechanisms, security holes, etc.

    2.8 Other hardware interfaces
    There are many other hardware interfaces for communicating with devices. As a final stage, it is important to analyze and discover defects and bypass mechanisms in all interfaces. Some well-known interfaces include (but are not limited to):

    Class D miniature- https : //en.wikipedia.org/wiki/D-subminiature
    ecommended standards (RS232, RS485, etc.)-For more details on the RS protocol, see Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    On-Board Diagnostics (OBD) – Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    3. Network communication interface
    The interface allows devices to talk to the rest of the virtual world, including sensor networks, clouds, and mobile devices. The hardware interface responsible for network communication may have a separate microcontroller / firmware that provides communication functions. In this case, the attack surface is firmware or driver code that implements low-level communication.

    3.1 Wifi
    There are some known issues with the wifi interface. From an attack surface perspective, attacking a wifi chip can damage it, DOS, bypassing security restrictions or executing code can be fun.

    3.2 Ethernet
    The Ethernet interface (like the wifi interface) has low-level TCP / IP stack vulnerabilities, hardware implementation vulnerabilities, and similar attack vectors.

    3.3 Broadcast
    Considering that many IoT products have been moved to / are being built using radio communications, radio interfaces have become one of the most important attack surfaces. The preference comes from the fact that in many cases it is more efficient to use the radio over a Wifi / wired network connection. The reason I classify Wifi separately rather than in this section is mainly to clearly distinguish between devices that can be directly connected to the Internet (Wifi / Wired) and devices that require a gateway (such as a smart hub), which must be implemented simultaneously Radio and Wifi / Wired interfaces are used to communicate with sensors and the Internet, respectively. From a practical communication perspective, it can be considered as two different communication modes:

    Simple / Unstructured: This type is often used for simple products such as shutters, locks, doorbells, etc. Simple unstructured means that it uses simple (mostly proprietary) data (streams) and sends it over the radio interface. As a penetration tester, you need to reverse engineer your communications to find flaws in your implementation. It is easy to sniff radio communications using a radio sniffing hardware tool such as SDR (Software Defined Radio).

    Complex / structured: Complex and structured communication means that it uses structured data packets for radio communications, which is complicated because they carry not only data but also other information and meta-information about the protocol. These protocols are well known in the IoT world for efficiency, standardization, economic chips, and ease of implementation. Similarly, there are several tools available for sniffing and parsing protocols to extract application-specific data sent across applications. Some common protocols include:

    a.Bluetooth and BLE
    b.ZigBee
    c.Zwave
    d.NFC
    e.RFID
    f.LORA
    g.Wireless HART…

    IoT Security-Part 3 (103-Ten Vulnerabilities in IoT)
    When talking about the top ten vulnerabilities, the first thing we think of is OWASP. Why not? After all, they are pioneers in defining the top ten vulnerabilities in the web and mobile. I'm a fan of OWASP because of the work the OWASP community has done over the years to define application security issues, providing the industry with free tutorials and open source tools to mitigate risks and vulnerabilities. You are unlikely to have heard of OWASP or read from their website, but if you have n’t heard of it, I highly recommend that you browse their website Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...

    OWASP has also launched the IoT Security Initiative, a community that has defined the IoT attack surface and the top ten IoT vulnerabilities other than Web and mobile devices. They are moving in the right direction, and soon it will be a great place to secure content for the Internet of Things.

    The content related to IoT security readers on the OWASP website is as follows:

    OWASP Web Top Ten Projects: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    OWASP Mobile Top Ten Projects: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    Things Project OWASP Internet: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    OWASP IoT attack surface: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...

    OWASP IoT Top Ten Vulnerabilities: Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...)

    Top ten vulnerabilities in OWASP IoT
    OWASP recently defined the top ten vulnerabilities in IoT. They are very comprehensive and we recommend that you read them carefully to understand the threats and issues of the IoT ecosystem. As a homework, you can map it to the attack surface defined in the previous blog post. Top 10 vulnerabilities in OWASP IoT (according to Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... )

    Insecure web interface
    Insufficient authentication / authorization
    Insecure network services
    Missing transport encryption / integrity verification
    Privacy issues
    Cloud interface
    Insecure mobile interface
    Insecure security configuration is insufficient
    Insecure software / firmware
    Poor personal safety
    We won't go into detail about each item in the top ten list. Details can be found in the OWASP link (above). Instead, we will refine the top ten based on our experience with issues we find or issues posted on the Internet.

    Ten IoT vulnerabilities 2018
    Disclaimer: Please note that our goal is not to exceed the OWASP Top Ten, this is an excellent job for guys. Sincerely, The OWASP Team! This is an exercise based on our experience that should focus more on hardware and new IoT technologies, which deserves our attention.

    Top 10 vulnerabilities in Payatu IoT, combining the web and the cloud into one project, because not all sensors or IoT devices will have a web interface, so the cloud is an important part of the ecosystem. From the perspective of the attack surface, the cloud is mainly It is based on Web API. In addition, some vulnerabilities may apply to multiple components, for example, hard-coded for devices and mobile applications.

    We will define the top ten IoT vulnerabilities that affect the IoT security market and products. We will explain all IoT vulnerabilities below to provide an understanding of basic security issues.

    P1. Hard-coded sensitive information
    P2. Hardware debug port enabled
    P3. Insecure firmware
    P4. Insecure data storage
    P5. Insufficient authentication
    P6. Insecure communication
    P7. Insecure configuration
    P8. Data input filtering
    P9. Mobile interface
    P10. Not secure. Insecure cloud / web interface

    P1. Hard-coded sensitive information
    It is a common practice for developers to hard-code static data in their programs during the development process. However, problems arise when sensitive information is hard-coded. It is likely that sensitive information is hard-coded in firmware as well as in mobile applications or thick clients. The problem is that all instances of the product remain the same and can be used to attack any product instance deployed in the field. Some examples of hard-coded sensitive information:

    Credentials-device services, cloud services, etc.
    Encryption key-private key, symmetric encryption key
    Certificates-client certificates, etc.
    API Key-Private / Paid API
    URL-development, firmware related, user related, backend, etc.
    Configuration
    P2. Hardware debug port enabled
    The device hardware may have a debug port open to interact with the system. In a nutshell, it is a set of pins on a PCB that are connected to microcontroller / microprocessor pins. You can use client software to connect to these pins to communicate through a hardware communication protocol so You can interact with the system. The level of interaction and privilege depends on the type of protocol and its usage. For example, there may be pin outputs for the UART interface, which gives you access to advanced software / applications, ie command shells, logger outputs, etc. You can also use the following protocols for low-level interaction with the microcontroller: JTAG, SWD, etc. These allow you to control the microcontroller directly, so you can test and analyze the pin values ​​of the microcontroller, read / write internal flash memory, read / Write register values, debug OS / basic firmware code, etc. If these ports / pins are enabled on the device, an attacker can hijack the device and / or extract sensitive information from the device, including firmware and data. These ports are typically enabled to troubleshoot / debug problems in production equipment.

    P3. Insecure firmware
    The term "unsafe" here refers to the way the firmware is managed, not the code loopholes in the firmware itself. The firmware contains the business logic of the device and is mostly proprietary, that is, the vendor's IP (Intellectual Property). If the attacker has access to the plain text firmware, he / she can reverse engineer it to discover security issues or clone logic and eventually clone the product itself. Vulnerabilities depend on how the firmware is stored and updated on the device. If the firmware in storage or on the fly is accidentally encrypted (updated), an attacker can control it. Some issues with the firmware are (but are not limited to):

    The firmware is stored on the memory chip in plain text
    The firmware is not signed and / or the bootloader has not verified the integrity of the firmware before loading.
    Firmware updates are transferred from the cloud or mobile device to the device in plain text format.
    The firmware update is transmitted via a clear text communication protocol (for example, http).
    Firmware encrypted with a single symmetric key for all device instances.
    The firmware encryption key is transmitted to the device along with the update.
    A properly implemented PKI-based system can ensure optimal security, but most low-power sensors lack the computing power to effectively implement PKI. Similarly, if the update is secure, but other vulnerabilities can be used to extract keys from the device, the entire exercise will be futile.

    P4. Insecure data storage
    This problem is prominent in both devices and mobile applications. This is more apparent in device hardware, probably due to the assumption that it is difficult to reverse the hardware. Sensitive data (if not stored securely) could be extracted and used by an attacker to damage the system. In addition to security issues, if a user's personal data is not properly protected, it may also involve privacy. Some common questions:

    Sensitive data is stored on the memory chip in clear text;
    Sensitive data is stored encrypted, but the encryption key can be accessed;
    Custom encryption is used to encrypt data;
    No access control rights to modify data;
    Data storage on mobile devices is not secure. Application (see "P9. Insecure mobile interface")
    P5. Insufficient certification
    The device may use an incorrect authentication mechanism or not. If the authentication mechanism is not implemented well, an attacker will bypass the authentication mechanism completely and send unauthorized commands to the device. This is a serious problem for critical IoT devices, as anyone on the network (TCP / IP or radio) can cover normal operations and control the device. Some authentication issues that occur on the device include (but are not limited to):

    Clientless authentication
    Authentication via clear text communication channel
    Incorrect encryption used for credentials
    Predictable credentials
    Default credentials
    P6. Insecure communication
    If an attacker is able to sniff, analyze, replay, and extract sensitive information in a communication, the communication in the IoT ecosystem may be insecure. The vulnerability may be caused by the use of an insecure communication protocol or the protocol flaw itself. For simplicity, vendors may choose to use insecure communication methods. Because IoT is an emerging technology, many IoT protocols do not define appropriate security mechanisms or vendors implement default insecure models. Issues include (but are not limited to):

    Unencrypted communication when sharing sensitive information
    Use custom encryption
    Use custom / proprietary protocols
    Incorrect encryption used
    Use protocol default (weak) security mode
    Protocols using known issues
    Replay problem
    P7. Insecure configuration
    This issue occurs when the device configuration is not secure or the device does not allow the user to modify configuration parameters. This issue also occurs in mobile applications and cloud configurations. To make things simple or fast to deliver the product, developers may choose to use simple but insecure configurations and / or not allow changes. Some obvious issues are (but not limited to):

    Use default insecure configuration
    Prevent integrators and / or users from modifying configuration
    Low-level protocols and hardware configuration in version products are not secure
    Encryption mode and settings are not secure
    Little or no visibility into shared or stored user personal data
    P8. Insufficient data input filtering
    As more and more IoT protocols are implemented in the IoT ecosystem, this will become a major issue. For example, telemetry data from a device may be trusted by the cloud or IoT gateway, leading to known and unknown security issues such as remote code execution, web-based attacks (such as SQL injection), cross-site scripting, and more. We hope that this will be prioritized in the future. Although mature implementations can indeed filter data from traditional technologies, for new IoT protocol implementations, there is also room for improvement.

    P9. Mobile interface is not secure
    From a security perspective, mobile technology is mature compared to sensor technology, so we group all mobile security issues into one category. This does not mean that they have lower priority because you can see that some high-priority vulnerabilities also apply to mobile devices. However, as the technology matures, it already has a wealth of information on security issues and security implementations. As a fan of OWASP, we recommend starting with OWASP Mobile Top Ten Vulnerabilities, which will solve most security issues.

    P10. Insecure cloud / web interface
    Such as "P9. Insecure mobile interface", the same applies to the cloud and the network. If the device has a web interface, you can still own the device through a web attack, but these security issues are well defined and understood. Similarly, we recommend starting with the OWASP Web Top Ten Vulnerabilities to understand and mitigate web security issues and cloud security documentation from the Cloud Security Alliance. Please note that this is not the only knowledge base available, and you should check out the tools and research papers available on the Internet. It is important to note that the cloud forms the data storage and communication backbone of the IoT ecosystem. If the cloud is disrupted, it could lead to the destruction of the entire IoT ecosystem, including all deployed products globally and throughout the universe.

    reference:
    Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
    WhiteCollarGroup till I die
    MI5, MI6,NSA,FBI,Army, CIA,Navy,Air Force, Mossad, PF and all this shit can't stop me.
    Similar Threads
X
Working...
X