OSDP漏洞利用

OSDP攻击工具（以及精灵语中的“朋友”）

OSDP支持但不严格要求加密。因此你的连接可能根本没有加密。攻击#1只是被动监听，看看能否读取线缆上的卡号。

仅仅因为控制器和读卡器支持加密，并不意味着它们被配置为要求使用加密。攻击者可以修改读卡器的能力回复消息（osdp_PDCAP），声明其不支持加密。当这种情况发生时，一些控制器会继续在没有加密的情况下运行。

OSDP有一个准官方的“安装模式”，适用于读卡器和控制器。顾名思义，它应该在首次设置读卡器时使用。它的作用是允许读卡器向控制器请求基础加密密钥（SCBK）。如果控制器被配置为持久处于安装模式，攻击者就可以出现在线缆上并请求SCBK。

OSDP示例代码通常带有硬编码的加密密钥。显然这些只是示例，用户应该自己以安全方式生成密钥。但这并没有向用户解释或简化操作。而任何在安全领域待得够久的人都知道，默认设置很可能出现在生产环境中。

因此，作为一个攻击向量，当读卡器和控制器之间的链路加密时，枚举一些常见的弱密钥是值得一试的。这些是128位AES密钥，我们无法枚举所有可能性，甚至无法枚举有意义的比例。但我们可以针对硬编码密钥时常见的一些模式进行尝试：

OSDP没有带内密钥交换机制。这意味着攻击者可以：

搭建测试平台（Linux/MacOS）

你可以在 attack_osdp.py 中找到每种攻击的概念验证代码。查看 --help 命令以获取更多用法详情。这是一个Python脚本，旨在从带有USB<-->RS485适配器的笔记本电脑上运行，类似于这款。因此你可能需要准备一些这样的适配器，但不一定非要这个型号。

如果你有想要测试的控制器，那太好了，直接使用即可。如果没有，我们提供了一个故意存在漏洞的OSDP控制器供你使用：vulnserver.py。

attack_osdp.py 中的某些攻击预期作为功能正常的读卡器和控制器之间的完整中间人存在。要测试这些攻击，你可能需要三个USB<-->RS485适配器，通过面包板连接在一起。

这些问题本身无法被利用，但依然削弱了协议、实现或整体系统的安全性。

MAC被截断为32位以“减少开销”。这几乎（但经过我们的计算并非完全）处于实际可利用的范围内。
IV（从MAC派生而来）同样减少为32位熵。这会导致IV重用，对于协议来说是一个巨大的警示。
会话密钥仅使用控制器RNG随机数的48位熵生成。对于观察中的攻击者来说，似乎无法离线枚举。（除非我们遗漏了什么，否则这将成为一个严重问题。）
序列号仅由2位组成，无法提供足够的时效性。
使用CBC模式加密。GCM会是更现代、适合网络协议的块密码模式。
SCS模式15和16本质上是“空密码”，不应存在。它们不加密数据。
OSDP命令字节始终未加密，即使在安全通道会话期间也是如此。这对攻击者来说是巨大的优势，使得编写攻击工具更加容易。这意味着攻击者总能看出正在发送什么“类型”的数据包，即使其他部分已加密。攻击者可以知道何时有人刷卡、LED何时亮起等……这些信息不应以明文形式存在。
SCBK-D（硬编码的“默认”加密密钥）不提供任何安全性，应被移除。它只会混淆视听并提供虚假的安全感。