GOSSIP-summerschool-2019-day4

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.在设计网络程序时,对接受的数据要进行多方面的验证,保证数据的完整性、保密性;也需要纵深防御的原则,对程序进行监控,及时发现并处理异常情况。