零配置协议安全性分析及利用_零配协议(zero rating agreement)-CSDN博客

本文链接：https://blog.csdn.net/weixin_49393427/article/details/117318396

本文依托于2016年信息安全顶会IEEE S&P中的《Staying Secure and Unprepared: Understanding and Mitigating the Security Risks of Apple ZeroConf》讨论一下零配置协议的一些安全问题，以及一些具体攻击的实现细节

基础知识

零配置（Zeroconf）

零配置协议的目标：让用户即插即用，使用户在使用设备时免于配置，就可以将设备或服务添加到本地网络中，并且已经存在的设备可以自动发现并连接到新的设备或服务
零配置网络（Zero-configuration networking），一组技术实现为网络设备自动分配网络地址；自动分配和解析主机名和自动定位网络服务（如打印服务等）。
典型例子：Bonjour，llmnr，ssdp

论文分享

发布于2016年的信息安全顶会IEEE S&P。
题目：Staying Secure and Unprepared: Understanding and Mitigating the Security Risks of Apple ZeroConf
链接：IEEE - 论文页面
视频：YouTube - 论文视频
PPT：S&P - PPT下载

苹果的零配置实现

BLE

peripheral（外设）：提供服务
central（中心）：发现和使用服务

两者都有UUID来标识，同时外设的每一个服务也有一个UUID

传统上需要配对使用PIN，建立链路层密钥。BLE使用了Secure Simple Pairing模型，支持以下配对方法：

数字比较：比较显示的数字是否相同
PIN输入：和传统的PIN相同
just works：让中心直接与外围设备配对，在UUID已知的情况下
OOB：需要通过NFC或者苹果证书来验证

其中just works和OOB是两种零配置方法。
苹果的Core Bluetooth框架隐藏了这些配对细节，来减轻开发的负担。

Bonjour

Bonjour使用mdns（https://zhuanlan.zhihu.com/p/255273790）来发布和发现本地网络或wifi direct网络中的服务。通过广播来注册服务和创建mdns记录，更新ip和主机名的映射关系，发布服务时时至少包含一条PTR和SRV记录

bonjour实现了ip和主机名的自分配，使得用户可以直接从服务列表中选择需要使用的服务。

服务的格式：_ServiceType._TransportProtocol._DomainName

一个服务实例通常有一个实例名在整个服务名前有一个唯一标识符，例如9c5e3d2._airdrop.tcp._local。

三种记录类型：

PTR：特定实例的服务名称，使其它设备的服务可以将服务类型映射到实例名称
SRV：映射实例名称到实际使用服务需要的信息，包括主机名和端口
TXT：关于服务实例的附加信息。

在这里插入图片描述

客户端流程：

广播PTR找特定服务，设备回复PTR服务在某个实例名。
问实例名在哪个主机和端口
问主机名到对应的ip地址

苹果建议保存发现的服务实例名，因为其相对稳定，不向ip和主机名经常变化。

攻击

攻击蓝牙

不安全的配对

Core Bluetooth框架默认通过just works工作，面向可用性的设计允许自动连接到UUID而不会报告冲突（多个设备声明相同的UUID），使得对通信通道的攻击难以检测。

BLE客户端（central）面对两个相同的UUID会随机选择一个进行连接；
peripheral外设显示的中心名称由中心指定的，攻击者可以利用该名称误导用户。

攻击Handoff

Handoff是一个让ios和osx可以无需配置通过BLE同步数据的服务。
通过OOB进行配对：当用户登录icloud账户时，设备的UUID和凭据通过账户进行交换，以确保只有经过授权的设备才可以配对。说白了就是通过把UUID信息绑定到账户。这样登陆以后就知道附近哪个UUID是同用户的设备了。

存在问题：数据同步应该只发生在特定的外设和中心应用之间，而零配置设计并没有在应用级别提供身份验证，所以导致iphone上任何广播的BLE服务都会暴露给MAC上支持BLE的应用程序。

一旦攻击者打开了handoff登陆了账户并且mac和iphone建立了连接，攻击app调用discoverServices来发现iphone广播的ANCS服务并且找出其通知源和数据源，通过向他们注册，攻击者可以在iphone收到通知时收到通知。

后续苹果停用了该渠道。

攻击文件共享APP

腾讯QQ，FileDrop，AirDrop等。
略。

对bonjour的攻击

攻击打印机发现过程

用户通过bonjour来发现本地网络中的打印机，并将打印服务实例名称保存到本地，下次打印时通过打印服务实例名称解析打印机主机名与IP。

打印机发现有人宣告和自己一样的名称实例，打印机会修改自己的名称实例。然而用户端并不知道这些。

这样攻击者可以宣告自己是打印机，客户端从而将打印内容发送给攻击者。

攻击AirDrop

airdrop的过程：

进行bonjour的发现及解析
发现另一个设备的服务实例名称，IP及端口
建立TLS连接，收集设备名称（Jeff的iPhone），账户信息等，用这些信息构建一个发现设备列表，供用户选择
通过 https://Jeffs-iPhone.local/Ask 和 https://Jeffs-iPhone.local/Upload 连接到对端进行文件传输

无法了解客户端如何验证服务端证书，以为服务实例名称，ip及设备名都不是永久使用的。实际上绑定到个人的用于TLS连接的证书实际上是一个以com.apple.idms.appleid.prd为前缀的随机字符串，与用户apple id相关，但是很难检查是否与用户对应，这种对应关系的设计也没有被公开。

服务器通过 TLS 连接向客户端发送其所有者的 Apple ID（电子邮件地址）的哈希值，该哈希值由 Apple 与其证书上的随机字符串一起签名。客户端使用哈希值来搜索她的联系人：只有当它与保存的电子邮件地址匹配时，客户端才能识别出 TLS 服务器确实是谁，因为保存的联系人图片会显示给用户。否则也就是电子邮件哈希客户端不知道），上述绑定关系客户端不知道：服务器显示的设备名称是服务器在TLS通信中任意声明的。

人们一般会存储手机号而不是apple id。所以即使证书的身份检查失败了，apple仍然会向用户显示设备名称列表。
在这里插入图片描述

攻击者回复客户端的SRV及A或AAAA记录请求，单播声明自己是服务端，来欺骗客户端与自己建立TLS连接。

截止论文发布暂无解决方案。

保护手段

在不破坏零配置系统可用性的基础上研发了新的技术。

冲突检测

假如受害者设备始终在线，那么冲突是不可避免的。当正常的业务询问特定的服务时，正常服务和攻击者都会回复这个报文，询问者应当可以看到冲突，来判断当前网络存在攻击。如果攻击者与询问者进行通信来更新其缓存，询问者可以用过广播收到的更新，并等待正常业务返回的冲突投诉。如果没有收到冲突投诉，则认为更新是合法的。

对于攻击者迫使服务改名的情况，令服务的改名符合一定的规则，比如加后缀，冲突检测是也会询问后缀是否存在。

说出你的证书

冲突检测虽然可以完全保留零配置系统的特性，但是无法帮助用户识别要连接的受信任方。

主要挑战是如何正确验证一个人对证书的所有权？

提出了SPYC vouch，“说出你的证书”方案，这部分可以参考原文

攻击细节

分析过程的过滤规则：
mdns or llmnr or snmp or tcp.port==9100 or srvloc
mdns是QM多播发送到224.0.0.251
llmnr一般是组播问询，单播回复
有一些情况下，通过NBNS对主机名进行查询也会影响实际通信的设备

官方驱动的打印机添加过程

用户发出SRVLOC请求到组播224.0.1.60，搜索服务资源x-hpnp-discover。
打印机回复SRVLOC，包括版本，mac，ip，支持的打印语言，序列号，主机名等信息。（此处因为内网还有别的打印机，发现有的打印机回复srvloc的时候事务ID是0，而不是和请求事务ID对应）
用户向239.255.255.250的3702端口发送wsd:probe，探测hpd:hpDevice设备
打印机回复设备类型，支持的服务在哪个ip及端口，以及一些型号等其他信息
用户ping打印机两个包，网络连通，添加打印机完毕。
添加的打印机是以打印机名保存在设备中的，在windows管理打印机的页面可以看到，如：NPIC6E810

正常打印过程交互

用户通过mdns询问NPIC6E810.local的A和AAAA记录，并要求通过多播回复
打印机通过多播回复，并刷新用户缓存
用户通过llmnr询问NPIC6E810的A和AAAA记录，并收到打印机单播的回复
用户通过snmp连接打印机，查询打印机的ip地址mac地址相关oid
建立9100连接，发送打印数据
优先ipv6