HoT-TAI-0011: Firmware and application updates sent without encryption

Summary:

Attackers often attempt to acquire device firmware in order to analyze the firmware for vulnerabilities or to modify the firmware with malicious software that will give the attacker access to a device. If an attacker cannot acquire the IoT device's firmware from the IoT device manufacturer's website, it is possible that the attacker will acquire the physical IoT device. They will then force the device to update, in the hopes that they will be able to capture and extract the device firmware due to the lack of transport encryption to prevent the firmware from being extracted in a readable format. More sophisticated attackers may even have the means to conduct a MITM attack to inject malicious backdoors / software into firmware upgrades in transit to the device.

• CWE-311 Missing Encryption of Sensitive Data: The lack of proper data encryption passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys. If the IoT does not use a secure channel, such as TLS, to exchange firmware and application updates, it is possible for an attacker with access to the network traffic to sniff packets from the connection and uncover the data. This attack is not technically difficult, but does require physical access to some portion of the network over which the sensitive data travels. This access is usually somewhere near where the user is connected to the network (such as a colleague on the company network) but can be anywhere along the path from the user to the end server. Omitting the use of encryption in any program which transfers data over a network of any kind should be considered on par with delivering the data sent to each user on the local networks of both the sender and receiver. Worse, this omission allows for the injection of data into a stream of communication between two parties -- with no means for the victims to separate valid data from invalid. In this day of widespread network attacks and password collection sniffers, it is an unnecessary risk to omit encryption from the design of any system which might benefit from it. Additional / related vulnerabilities include:

• CWE-319 Cleartext Transmission of Sensitive Information

• CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

• CWE-327 Use of a Broken or Risky Cryptographic Algorithm

Estimated Overall Risk Assessment: HIGH

• Technical Impacts: HIGH

  • If an attacker can gain access tp the firmware of an asset they are targeting within your organization through this vulnerability they can conduct offline research of vulnerabilities associated with your asset. In addition, if an attacker has the ability to conduct a MITM attacker they can compromise the integrity of the asset.

• Business Impacts: HIGH

  • An attacker could gain control over the IoT device and could establish a foothold within your network for further actions-on-objective (e.g. further exploitation of internal network OR to utilize the IoT device as part of a botnet to launch attacks against national critical infrastructure).

• Detectability: EASY

• Prevalence:TBD

• Exploitability: EASY

Attack Surfaces Grouped By Layer of Cyberspace

• Physical Network Layer
  • Update Mechanism

Known Intrusion / Exploit / Attack Cases and Threats

TBD

Identify, Detect, Protect, Respond, and Recover (NIST FICIC)

This vulnerability page (and some information contained in the associated attack page) address the following:

• IDENTIFY-RISK ASSESSMENT (ID.RA)

  • ID.RA-1: Asset vulnerabilities are identified and documented
    • See "Analysis Tools and Training" below.
  • ID.RA-2: Cyber threat intelligence and vulnerability information is received from information sharing forums and sources
  • ID.RA-3: Threats, both internal and external are identified and documented
  • ID.RA-4: Potential business impacts and likelihoods are identified
  • ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
  • IS.RA-6: Risk responses are identified and prioritized

• PROTECT-Information Protection Processes and Procedures (PR.IP)

  • PR.IP-12: A vulnerability management plan is developed and implemented

• DETECT-Anomalies and Events (DE.AE)

  • DE.AE-2: Detected events are analyzed to understand attack targets and methods

• DETECT-Security Continuous Monitoring (DE.CM)

  • DE.CM-1: The network is monitored to detect potential cybersecurity events

Analysis Tools and Training

• Identify
  • Utilizing a packet capturing tool such as Wireshark, monitor the firmware and application updates to ensure that they are only download over encrypted channels. This video demonstrates what encrypted (TLS/SSL) traffic should look like when implemented.
• Protect
  • This vulnerability should be reported to the manufacturer for mitigation within the firmware.
  • If it is possible, manually download and update the asset's firmware.
• Detect
  • When updates are available, utilize Wireshark to capture and reassemble the firmware. Compare a cryptographic hash (e.g. MD5, SHA1, SHA-256) of the downloaded firmware to the cryptographic hash provided by the manufacturer. If a cryptographic hash is not available from the manufacturer, the last resort would be to examine the firmware for malicious logic.

Associated CVEs / Manufacturers / Devices

Use this link to identify the latest access control vulnerabilities. This search query is not specific to the IoT.

CVE-2017-9035

References

TBD