@1qaz
2016-06-21T15:03:54.000000Z
字数 1990
阅读 1377
proxy
Xavier et al. Concordia University,Canada, NDSS'16 原文
一句话:杀毒软件等应用会起到TLS代理的角色,如果在私钥保护、证书校验、密码套件等方面处理不当,会产生中间人攻击的风险
为了过滤TLS流量,有些杀毒软件和家长控制软件会起到TLS代理的作用。除了常见的TLS客户端问题外,此类软件还会引入新的问题,如信任自签名的证书。作者设计了一个框架来检测此类软件,并发现了其中私钥保护、证书校验、密码套件等问题
制造商的广告软件 SuperFish事件
软件选择:
55款杀软和家长控制软件中,有14个将自己的根证书导入到操作系统/浏览器的trusted store中,其中的12个有实际代理TLS流量
TLS代理需要在操作系统的trusted CA中添加自己的根证书。浏览器会信任任何由该根证书签发的证书。
当代理软件被卸载/关闭,或者license失效,根证书可能仍然留在trusted store中。
威胁模型:
攻击者目标:主动的TLS MITM
攻击者不能在victim机器上运行admin权限的malware(直接读取目标进程内存),但可以在自己机器上研究proxy
通用MITM:proxy预先生成的证书,在不同安装间相同,攻击者在本地提取出私钥后就能MITM
有目标的MITM: 攻击者可以在victim上运行unprivileged code,希望能截取到proxy动态生成私钥
从文件和windows注册表中寻找证书的私钥:.cert,.pem,SHA fingerprint
内存:
1. 寻找内存中和公钥匹配的RSA私钥 (heartleech,heartbleed利用工具)
2. 寻找私钥的passphrase:
strings
反编译 OpenSSL private key相关函数
trace: consumer使用私钥;将入口点改成consumer之前的2-3个函数(调试很复杂,service在开机时启动,在debug之前就获得了私钥)
(在实际中只遇到了硬编码的情况)
3. 破解加密数据库:SQLlite中的SQLCipher,AES-256。在程序打开数据库后立即用空key重加密,在程序之后操作数据库的地方patch成无须密码访问(?)
可能存在的问题:
1. 生成时间:pre-generated 和install-time generated
2. 生成时的熵源:OpenSSL RAND_seed() RSA_generate_key_ex()
3. self—acceptance:作为proxy,不应当接受远程的由proxy自己签发的证书,这些证书只应该在本地使用
4. license过期/被卸载:proxy停止工作,但根证书还在trusted store中,
加载不合法证书的服务器上的CSS/JS
证书校验:
1. 未实现SNI扩展:相同IP不同域名,不支持SNI时导致测试结果不对
2. 证书缓存
3. Proxy可能只对特定的网站过滤
TLS参数
14个杀软/家长控制软件,12个支持TLS proxy
1. 根证书
证书生成:2个预生成,其他在安装时生成
私有trusted store:8个将自己的根证书导入到Firefox trusted store中
self-acceptance:10个接受任何由自己根证书签发的远程证书
用ZMap寻找公网中由这些根证书签发的证书,只找到一个 Kaspersky Antivirus Personal Root Certificate
license 过期:Kaspersky 2015年3月的某个版本在30天试用过后仍然过滤所有TLS流量,接受不合法的证书
卸载:8个在卸载时没有移除trusted store中的根证书
TLS key-logging:Firefox和Chrome支持记录TLS session key来解密流量,杀软可以通过这种方式被动检测流量,将证书验证交给浏览器
私钥保护:不自己管理私钥,使用OS提供的接口来保存,这样攻击者只有获得admin权限才能获得私钥
浏览器:浏览器在检测到proxy时给用户明显的UI提醒