GOSSIP-summerschool-2019-day4

Posted on | In |

Let’s GOSSIP软件安全暑期学校笔记

DAY 4: 7.23

今日演讲主题：

  1. 你的Password我来猜——口令安全分析技术揭秘 汪定
  2. 网络基础协议安全研究初探 郑晓峰

你的Password我来猜——口令安全分析技术揭秘 汪定

生物特征仅适合本地/离线认证，不适合在线认证。（深圳某公司人脸数据造泄漏，生物特征的不可再生性）

用户行为

人是系统中最薄弱的环节。

现状：

  1. 每个人的账号数量越来越多

  2. 网站口令策略杂乱无章

  3. 用户处理安全事务的能力和精力有限

研究所用信息获取的途径：

  • 用户问卷调查（效果不好）
  • 基于真实数据分析（使用泄露的口令集进行研究）

用户口令行为：

一：偏好选择流行口令（选择最热门的10个口令：1.28%～10.44%）

二：口令重用

三：使用个人相关信息（中文用户：37%～51%，英文用户：13%～30%）

口令分布

用户选择的口令是高度集中的（highly skewed）

基本假设有问题？口令的分布不知道。因为涉及到大规模的真实数据，涉及到多学科的交叉知识。

数学的部分听不懂了。。。

口令猜测

口令猜测攻击

定向在线猜测攻击越来越可行

口令猜测情境下对个人信息的分类

  • 个人信息
  • 个人可标识信息
  • 用户的身份凭证
  • 其他个人信息

攻击情景

  • TarGuess-I: 定向PCFG
  • 对数据集进行切割，进行训练，对口令进行刻画
  • TarGuess-II: 公开信息+姊妹口令
  • TarGuess-III: 姊妹口令+第一类PII
  • TarGuess-IV: 姊妹口令+第一类PII+第二类PII

口令评价

口令强度检测器

如何在未知用户旧口令的情况下，刻画用户的口令修改行为？

总结

口令安全分析的方法论，为之前盲目的口令猜测破解提供了系统的指引。

口令猜测部分可以基于已泄漏的口令数据集，对用户新设置口令的安全性进行分析。

口令评价部分可以在工程中实现，提高用户口令安全性。

具有较强的应用场景。

网络基础协议安全研究初探 郑晓峰

“来来来，我们黑掉 GoSSIP”：

介绍了一次从浏览器输入域名开始，访问网页中的的细节。

地址栏：

  • URL的组成

image-20190723135654518

Example：http://baudu.com&search=qq@167772161

实际访问：10.0.0.1

  • 复杂的编码 URL编码
  • Percent-encoding
  • Double-encoding
  • Case-insensitive
  • IDN 国际化域名 Unicode域名
  • http://xn--xkrp53d.edu.cn -> http://清华.cn
  • http://xn--pple-43d.com -> ‘a’ (U+0430) -> http://apple.com
  • 浏览器初期的防御：若域名字符不属于同一字符集，则直接显示
  • 引入更严格的检测算法，如黑名单
  • 利用Loading 掩盖掉地址栏真实的地址
  • 访问真实的，跳转到没有意义的地址，阻塞
  • 访问恶意的阻塞真实的：
  • 打开恶意网页，跳转到真实的网站，端口指向一个不存在的端口
  • image-20190723140938314

启程：DNS

篡改真实的IP地址

  • DNS劫持：Middle Box

  • 家用路由器（小米路由器 某一版本 会对请求的域名进行过滤）

  • DNS递归服务器

  • 良性的

  • ISP可能会对主干网上的DNS进行劫持/抢答

  • 在国内，356个自治系统中，有61个AS检测到DNS劫持

  • 运营商内部进行缓存，抢答至缓存

  • 攻击者

  • 对递归DNS缓存投毒：攻击难度较高（2的32次方）

  • 攻击者在递归服务器得到请求响应之前，抢答返回递归DNS服务器

  • 需要构造响应包的

  • 端口要相同

  • Transaction id相同

  • 防御：

  • 0x20编码：请求时对域名大小写随意置换，响应时必须匹配

  • 绕过：

  • IP分片

  • 不用猜 Source Port、Transaction id，转为猜IPID

  • UDP报文大于512字节时，IP可能分片

  • 攻击者只用伪造第二个IP报文，发给受害者。（IP分片到达对于时序没有要求）

  • IPID

  • IPID长度：2的16次方，16字节

  • IPID没那么随机：操作系统的生成算法（全局递增的占多数，甚至常量。超过90%可以直接探测/递增）

  • Meet in Middle: 分片缓存，Linux默认至少64个，因此，只需间隔布局，再进行尝试，使IPID递增，猜测空间降低为1024（2^10）。

  • 构造分片才是关键

  • 包足够大，DNS payload长度一般小于512

  • PMTU足够小，操作系统默认配置PMTU大于576（实际攻击比较难）

  • DNSSEC

  • DNSSEC仅能保障数据完备性

  • 部署程度很低

HTTP劫持

在运营商的层面http的劫持时有发生

HTTPS通过公钥体系，可以保证隐私性和完整性

Session如何泄漏的：Cookie安全

HTTP Session

  • 用于保持HTTP会话状态/缓存信息

  • 由服务器/浏览器（脚本）写入

  • 存储与浏览器/传输与HTTP头部

  • 属性

  • Name, domain, path……

  • 三元组

  • [name, domain, path]: 确定一个cookie

  • 很容易被劫持

Cookie基础：同源策略（SOP）
  • Web SOP 资源的同源策略：域名、端口、协议相同
  • Cookie SOP：跨协议的
  • 仅以domain/path作为同源限制
  • 不区分端口
  • 不区分HTTP/HTTPS
  • Domain向上通配
  • 写入时向上通配
  • 读取时
  • Path向下通配
  • 以目录为单位

image-20190723151913751

image-20190723151923945

  • 带有Secure属性的Cookie仅用于HTTPS使用。
  • Secure Cookie缺乏完整性保护：无法读取，可以覆盖
  • Secure Cookie注入、覆盖
  • Cookie 注入：Authenticated as Attacker
HTTPS Session

  • 惯性思维：“一个”HTTPS页面

  • 现在通常的Web页面由多个请求组装起来的，并不少原子性的。替换一个请求

  • 惯性思维：“唯一”的Cookie

  • Server只能看到name，domain/path由浏览器决定

  • 写的时候带属性，读取时不带属性

  • 允许重名（name相同，value不同）

RFC对于重名的处理没有标准

目前主流的处理：顺序即优先级

控制优先级（顺序）

  • 浏览器对Cookie String的排序标准：path更长，创建时间更早
  • path
  • 更长
  • 无’/‘加入’/‘
  • 甚至加上‘index.php’或’index.php?type=1’(Firefox)
  • 更早创建
  • 可以删除原来的，再加入

Gmail的例子

注入了25个cookie

如何正确看待HTTPS页面：

  • HTTPS页面并非一个“原子”的页面，由很多个HTTPS请求组成，请求是离散的
  • 由多个ajax组成
  • 其中的部分请求可能被更改

补丁后的现状：Secure Cookie不能被重写

  • 解决了Strict Secure Cookie避免了同名混淆

  • HTTP下仍能合法写入的Cookie，仍能在同domain HTTPS请求中传输

  • HTTP下能够控制HTTPS请求长度的变化

HTTPS Path侧信道

  • 对已知路径识别
  • 朝目标路径注入大量cookie，长度一旦发生变化，即可判断
  • 未知路径泄漏
  • 长hash作为路径，知道hash即可访问（云盘）
  • Safari/IE未遵循规范，错误地采取了字符串前缀匹配
  • 攻击者可以逐字节猜解

协议中歧义性的问题大量存在，特别是文本协议

Host of troubles

请求中的host字段，存在歧义。

服务器端第一次理解歧义产生的问题，影响了后续的请求。

image-20190723161902809

CDN安全

国内80%的情况会遇到CDN，CDN用来加速，帮助服务器进行防御

CDN原理

image-20190723162518781

Forwarding-Loop 1: CDN节点自循环
  • 静态配置本地地址127.0.0.1
  • 支持域名作为原站地址，DNS实现动态绑定本地地址

image-20190723162921162

Forwarding-Loop 2: CDN内部多节点循环

image-20190723163259306

Forwarding-Loop 3: 跨CDN循环

image-20190723163617605

Forwarding-Loop +: DNS调度

image-20190723163731737

Forwarding-Loop +: 主动探测 & 超时重传

让爬虫来发起

image-20190723164103301

Forwarding-Loop +: Non-Streaming VS Streaming

之前链路中之有一个/数个请求

使用Request Streaming（仅部分支持）

image-20190723164258565

Forwarding-Loop +: 利用Response Streaming

image-20190723164738795

攻击的增长仍是线性

Forwarding-Loop +: GZip炸弹

本身很小，解压后十分大

发起请求时不带gz，响应时带gz，使CDN解压后回传

image-20190723165054748

Q&A：DNS over HTTPS

依赖浏览器，（可指定权威DNS服务器？），大范围推广还是有一定距离；如邮件服务器等，仍需要传统DNS。

其能够建立新的生态，可能出现新的攻击点。

Q&A：WAF、云盾

Q&A：支付前的安全检查有什么用

总结

演讲十分精彩，网络协议研究、网络基础设施研究有很大的乐趣。

网络协议中存在很多未被规范的细节，同时各个软件在实现上的方式不同，造成了协议中字段存在歧义。可以通过发现网络协议字段的歧义、网络协议中的细节，伪造、篡改信息，这是一个攻击面。

如何系统的去解决、检测，也是一个值得思考的问题。

网络是一个不信任域，如果没有协议的保障，任何来自网络的数据都是不可信的，中间有太多的环节可以对传输的数据进行攻击。这就要求我们：1. 设计网络协议时要考虑完整性、保密性、可用性，需要考虑可能遇到的时序相关的问题；2.在设计网络程序时，对接受的数据要进行多方面的验证，保证数据的完整性、保密性；也需要纵深防御的原则，对程序进行监控，及时发现并处理异常情况。