我看过 OWASP 前 10 名的 Web 应用程序、原生应用程序等指南,但从来没有任何关于嵌入式系统或硬件设备的指南。这些通常涉及执行代码并接受来自各种数据源的输入的微控制器(例如 Atmega / PIC)或小型微处理器。物理设备中各种接口(包括 HDMI、HDCP、802.11b/g/n 甚至 IR 遥控器)的许多实施已被证明容易受到 DoS 和更邪恶的攻击。
是否有针对此类设备的指南,尤其是从缓解和测试的角度来看?
我看过 OWASP 前 10 名的 Web 应用程序、原生应用程序等指南,但从来没有任何关于嵌入式系统或硬件设备的指南。这些通常涉及执行代码并接受来自各种数据源的输入的微控制器(例如 Atmega / PIC)或小型微处理器。物理设备中各种接口(包括 HDMI、HDCP、802.11b/g/n 甚至 IR 遥控器)的许多实施已被证明容易受到 DoS 和更邪恶的攻击。
是否有针对此类设备的指南,尤其是从缓解和测试的角度来看?
工程师通常在硬件中包含后门机制和测试帐户以用于调试目的,而没有采取微不足道的安全措施来保护它们。不幸的是,大量设备在没有禁用这些机制和帐户的情况下进入市场,从而使攻击者能够非法访问设备。
许多设备实施 SNMP 或 UPnP 以进行远程管理,但甚至无法围绕它们实施基本的安全级别。办公设备、网络硬件、工业控制系统等经常通过SNMP泄露敏感数据(如路由表),并可能通过UPnP提供各种控制功能。许多支持 UPnP 的设备实现了标准的网络接口管理功能,允许攻击者禁用网络接口。进一步的功能可能允许攻击者永久损坏设备,或导致严重的功能问题。
众所周知,硬件实现不检查目标缓冲区大小是很糟糕的,并且可能会导致内存状态完全损坏。这可能会导致代码执行,但更常见的是导致拒绝服务情况,即必须对设备进行硬重置才能再次使用它。
当无符号整数输入被视为有符号,或者较大的整数类型直接转换为较小的整数类型时,就会发生这些情况。这两个问题都可能导致值超出预期范围的情况,这可能导致数组范围检查和缓冲区长度检查通过,尽管输入缓冲区太大。这些也可能导致 read-what-where 条件,其中负数组索引导致内存操作访问前面的内存区域。
硬件实现中的输入值通常被认为具有很强的完整性,因此通常不执行完整性检查。这可能允许恶意用户提供意外的值并更改设备的行为。一个常见的例子是使用一组位标志,并设置冲突位。
硬件设计人员有时会产生错觉,因为某些东西存储在板上的 EEPROM 芯片中,因此希望干扰设备的人不会/无法读取其中的数据。通常会找到存储在设备固件中的硬编码加密密钥和其他凭据。这些可能被用来破坏设备或其通信,并且通常在相同型号的所有设备中都是相同的。
在嵌入式系统中实现适当的加密算法通常很复杂,尤其是在使用不太广泛的微控制器和微处理器时。参考实现通常采用类似 x86 或类似 ARM 的架构,这会增加工作量。工程师通常也缺乏正确实施密码学的知识和经验。因此,在嵌入式系统中发现的密码算法往往难以实现,或者是具有严重安全漏洞的自制设计。许多系统完全没有任何形式的密码和其他凭据散列。这种类型的数据通常可以使用现成的工具从非易失性存储器中提取。
设备固件的完整性通常通过 CRC32 或 MD5 哈希进行检查,但很少通过任何强大的方式进行身份验证。许多制造商依靠默默无闻作为一种安全措施。虽然对设备固件进行逆向工程的成本可能相当高,但随着嵌入式系统中常见微处理器架构(例如 ARM)的出现,成本变得越来越低。一旦攻击者获得上传固件映像的能力,他们可能会彻底颠覆系统。
许多 OWASP Top 10 Web 应用程序缺陷在嵌入式设备的 Web 控制面板中非常常见。CSRF、XSS 和会话盗窃在常见漏洞列表中占有很高的位置,但由于实现完整关系数据库的系统数量相对较少,SQLi 不太常见。
嵌入式设备上的许多网络服务都配置为绑定到 0.0.0.0,而不是直接绑定到 LAN IP 地址。这可能允许攻击者从 LAN 外部与设备进行通信。适当的隔离和防火墙配置可能有助于缓解这种情况,但这仍然是一个问题。
信息安全是一门系统学科,因为它需要整个信息系统(包括人员)的专业知识才能成功。在一个更大的系统中,硬件和软件永远不会超过碎片。对嵌入式系统进行安全分析需要了解系统中的人员将如何使用它。一个好的系统分析总是比一个检查清单更好。
1. 对安全关键部件或组件的轻松物理访问。
嵌入式设备的某些部分对其以安全方式运行至关重要,而其他部分则不然。精心设计的设备将使通过各种技术访问这些组件变得困难。简单的技术包括排除螺钉和使用实心板覆盖设备的外部。测试需要拆卸专家。
2. 过分信任设计的独特部分。
从“其他人无法获得”的定制连接器到“其他人无法使用”的独特频率,这些设计特征通常对授权用户的伤害大于未经授权的用户。有效地使设备的使用成本更高。没有办法直接测试信任的集中度,但对故障模式和系统状态的分析可能有助于识别单点故障。
3. 不保护图纸、原理图和维护手册。
这些文档和信息可帮助攻击者找到物理软点以及识别设备的安全关键组件。缓解措施涉及文件和设备会计以及定期审计
4. 使用相同的密钥对相同设计的所有设备进行键控。
这样,当一台设备受到威胁时,它们都会受到威胁。根据环境中的设备总数和威胁,可以按设备或批次更改密钥。批次中的设备数量将是密钥使用效率和批次密钥被泄露时造成的损害之间的折衷。
5. 没有设计密钥更新系统。
几乎任何安全设备都需要一个或多个加密密钥。随着时间的推移,随着设备暴露在威胁环境中,一个或多个密钥将被泄露。当这种情况发生时,能够重新键入设备而不是刮擦它的零件是件好事。测试密钥更新功能的故障模式尤为重要。
6. 没有建立篡改检测
如果没有篡改检测,您将无法构建任何主动机制来防止篡改。机制包括清理敏感数据、销毁密钥或“破坏”设备。
7. 射频屏蔽不当。
这可能会将带外信号暴露给环境,这些信号可用于推断与设备安全操作相关的重要信息。一个简单的示例是确定安全请求的成功或失败。许多系统在请求部分成功时会花费更长的时间,而不是在请求的任何部分都不成功时。这通常被描述为侧信道攻击。
您可以查看Common Criteria Protection Profiles,当然不是详尽的列表,但确实是不同系统的要求列表。有些可能涵盖您正在开发的内容。
每个保护配置文件 (PP) 都遵循介绍评估目标 (TOE) 和保护 TOE 目标的格式。因此,PP 是通用标准评估的正式要求公式。
一个示例 PP 是美国政府的通用网络操作系统 PP。此处针对审计的具体要求如下:
TSF [操作系统受信任的安全功能] 应为授权管理员提供从审计记录中读取所有审计信息的能力
此外,还提出并正式确定了对系统的威胁:
[威胁 T.CRYPTO_COMPROMISE:] 恶意用户或进程可能导致与加密功能相关的密钥、数据或可执行代码被不当访问(查看、修改或删除),从而危及加密机制和受这些机制保护的数据.
总之,考虑了以下威胁:
每个已识别的安全威胁都由一个或多个安全目标来解决。[提供]从安全目标到威胁的映射,以及讨论如何解决威胁的基本原理。每个威胁和安全目标下方都提供了定义(斜体字),因此 PP 读者可以参考这些定义,而无需返回第 3 节和第 4 节[讨论安全环境和目标的部分]。