在浏览器场景下的 DNS 重绑定攻击有什么不一样?
最近 Chrome 的正在推广(https://developer.chrome.com/blog/private-network-access-
preflight/)的PNA(Private Network Access) :https://wicg.github.io/private-
network-access/策略真的能完全防御吗?
DNS重绑定
这里不过多介绍,不了解的师傅可以先看一下下面的文章:《从 0 到 1 认识 DNS
重绑定攻击》(https://xz.aliyun.com/t/7495)
DNS 重绑定本质上是欺骗客户端请求的 IP 地址。
这个客户端可以在服务器上,就是 SSRF,攻击对象一般是各种后端语言的网络库,或者是无头浏览器。
SSRF 安全指北:https://security.tencent.com/index.php/blog/msg/179
这个客户端也可以在个人 PC 上,就是 CSRF,攻击对象一般是浏览器。
浏览器Tips
在浏览器中使用 DNS 重绑定技术一般是服务于 CSRF 攻击,实现绕过同源策略,实现访问本机服务,或者内网服务。如果服务没有对 host
进行校验,那么就可以进行攻击。
在GitHub
上有个项目:https://github.com/nccgroup/singularity实现了一个
DNS 重绑定的攻击框架,核心亮点在于实现多种 DNS 重绑定攻击策略,并有很多Bypass 技巧,在PPT
中:https://bit.ly/Singularity_Defcon27有比较完整的技术细节,这里我挑几个我认为很酷的技术点介绍一下:
还有其他的比如缓存覆盖刷新,websocket 远控都很酷,感兴趣的师傅可以看代码。
Multiple answers
使用这个重绑定策略能实现全平台全浏览器 3
秒内完成攻击。
Multiple answers简称 ma,这个策略利用 DNS Multiple Answers,查询 dns 的时候响应两个 IP
地址,一个是真实的服务器 IP,另一个是内网 IP,比如 127.0.0.1,官方 PPT 上有一个很棒的图。
浏览器在拿到多个 dns 响应时,会尝试用第一个连接,失败之后就会尝试另一个,这时就实现了 DNS 重绑定。这个其实算是一个正常功能,也非常常见,可以说是
DNS 层面的负载均衡技术。
ma策略下还有些小问题:
1.当客户端拿到多个 dns 结果的时候会先选择哪一个?
参考 How do DNS clients choose an IP address when they get multiple
answers?(<https://serverfault.com/questions/102879/how-do-dns-clients-choose-
an-ip-address-when-they-get-multiple-
answers>)。大多数都会按照响应的顺序连接,有些是随机的,有些则会根据子网掩码计算最近的 IP 进行连接。
2.客户端会尝试整个 IP 列表吗?
完全看客户端实现,从测试看至少浏览器会。
3.公用 dns 服务器会打乱这个响应顺序吗?
部分服务器存在打乱顺序和强制设置 TTL 的情况,所以 ma策略在使用某些 dns 服务器时有一定概率失败。
原始响应
8.8.8.8
查询多次尝试一致
1.1.1.1
查询存在排序混乱
119.29.29.29
失败
223.5.5.5 存在排序混乱,强制
TTL
114.114.114.114 首次查询正常,后续查询强制 TTL,并存在排序混乱
所以… 一些不规范的 DNS 服务器一定程度上能缓解攻击…
0.0.0.0 Bypass
在 Linux 和 macOS 中 0.0.0.0实际上是 127.0.0.1,如果一个程序监听 127.0.0.1,使用 0.0.0.0也能访问到。
而在 Windows
中,0.0.0.0就不是一个有效地址。
PNA策略
PNA (Private Network Access) 是目前 Chrome 正在推广的一个安全策略,目标就是缓解 CSRF
对本地或者内网服务的攻击利用。
- https://wicg.github.io/private-network-access/
- https://developer.chrome.com/blog/private-network-access-update/
- https://developer.chrome.com/blog/private-network-access-preflight/
在 Chrome 94 版本中,开始拦截公网 http 网站对私有网络的请求。
在未来的 Chrome 98 版本中,在访问私有网络前会尝试 CORS preflight,纯测试警告提醒开发者,并不会拦截,和常规的跨域类似,只是响应头为
Access-Control-Request-Private-Network: true,后续预计在 Chrome 101 版本中将会严格执行安全策略,拦截
preflight 失败的请求。
目前 Chrome 是 97 版本,已经会拦截 http 网站的内网请求了,可以简单尝试一下。
The request client is not a secure context and the resource is in more-
private address space private. 请求客户端不是安全上下文,资源位于更私密的地址空间 “private” 中。
这里多了一个概念 more-private address space,可以在 DevTools 中 Network
右键打开一列。
可以看到 http://rebind.it/网站属于 Public,如果打开一个内网或者本地服务,可以看到是
Private。
可以猜到浏览器是根据远程地址进行空间划分,分为 Public,Private,Local 等,然后限制 Public 到 Private 或者 Local
的请求。
在 issues 中也能看到 DNS 重绑定攻击在 Chrome 中失败的惨案,DNS 重绑定到内部地址的请求全部被拦截。
- https://github.com/nccgroup/singularity/issues/44
同时这里也没有特别注明是 fetch,使用 script或者
img自带跨域的标签加载也会被拦截。
PNA 的防御还是挺狠的。
PNA Bypass
PNA 一共 3 个判定条件,一个个看。在 CSRF 攻击场景中,目标服务一般都是 http,意味着攻击请求是 http 的,而且对于 DNS
重绑定来说,只能攻击 http 服务,https 服务直接就会因为证书错误而失败。同时 Chrome 又拦截了混合内容,意味着我们的服务也得是 http
的。
第一个条件 isFromHTTP==true,没法绕了,后两个条件似乎是类似的,问题都在于 Chrome 是如何给地址分类的?
Bypass 1
还记得前面提到的 0.0.0.0吗?Chrome 认为 0.0.0.0是 Public。
同时在 Linux 和 macOS 上 0.0.0.0是指 127.0.0.1,isToPrivateOrLocal==false这样就绕过了
PNA,当然这个 Bypass 不适用于 Windows。
Bypass 2
除了Chrome对IP的分类错误,还有一种情况让Chrome直接 “跳过” 分类。
如果有师傅按照上面自己操作一下,应该就能发现,在 Chrome 使用代理的时候,Remote Address
Space永远都是一样的,实际上都是代理服务器的 Address Space。
因为浏览器配置代理后,浏览器就不解析 DNS 了,所有的请求直接转发给代理服务器,实际产生连接的也是代理服务器,这里标记的 Remote Address
Space自然也就是代理服务器了,isFromPublic==false,实现绕过 PNA。但是,此时发生 DNS
重绑定攻击就不是在浏览器中,而是在代理服务器中,因为实际客户端是代理软件,DNS Rebinding in Proxy Server 这就是另一个话题了。
最后
在 Linux 和 macOS 中,利用 0.0.0.0还是可以使用 DNS 重绑定攻击本地服务。在代理场景中,PNA 策略直接失效,DNS
重绑定如旧。PNA 还是很棒的,继 SameSite 之后 CSRF 漏洞又遭一锤,有认证的外部服务无了,无认证的内部服务也无了。
说起 SameSite,前几天发布的 Firefox 96 版本(<https://www.mozilla.org/en-
US/firefox/96.0/releasenotes/>)
也开始默认设置 SameSite=lax了,现在好像就差 Safari 了。
(<https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-
Cookie/SameSite#%E6%B5%8F%E8%A7%88%E5%99%A8%E5%85%BC%E5%AE%B9%E6%80%A7>)
SameSite 的可以看这篇 《CSRF 漏洞的末日?关于 Cookie SameSite
那些你不得不知道的事》。
对于 CSRF 来说,在浏览器层面做防御,和服务端的修修补补比,可以说是降维打击了。
这让我想起了 NAT Slipstream ,Chrome 直接把相关端口都给 Block 了 ,简单粗暴。
6e0b4f21fddcbe2d19f667b6e6cf2bdb66160a744d161a7bac7b420acac005&scene=21#wechat_redirect)》。
对于 CSRF 来说,在浏览器层面做防御,和服务端的修修补补比,可以说是降维打击了。
这让我想起了 NAT Slipstream ,Chrome 直接把相关端口都给 Block 了 ,简单粗暴。
学习网络安全技术的方法无非三种:
第一种是报网络安全专业,现在叫网络空间安全专业,主要专业课程:程序设计、计算机组成原理原理、数据结构、操作系统原理、数据库系统、 计算机网络、人工智能、自然语言处理、社会计算、网络安全法律法规、网络安全、内容安全、数字取证、机器学习,多媒体技术,信息检索、舆情分析等。
第二种是自学,就是在网上找资源、找教程,或者是想办法认识一-些大佬,抱紧大腿,不过这种方法很耗时间,而且学习没有规划,可能很长一段时间感觉自己没有进步,容易劝退。
如果你对网络安全入门感兴趣,那么你需要的话可以点击这里👉网络安全重磅福利:入门&进阶全套282G学习资源包免费分享!
第三种就是去找培训。
接下来,我会教你零基础入门快速入门上手网络安全。
网络安全入门到底是先学编程还是先学计算机基础?这是一个争议比较大的问题,有的人会建议先学编程,而有的人会建议先学计算机基础,其实这都是要学的。而且这些对学习网络安全来说非常重要。但是对于完全零基础的人来说又或者急于转行的人来说,学习编程或者计算机基础对他们来说都有一定的难度,并且花费时间太长。
第一阶段:基础准备 4周~6周
这个阶段是所有准备进入安全行业必学的部分,俗话说:基础不劳,地动山摇
第二阶段:web渗透
学习基础 时间:1周 ~ 2周:
① 了解基本概念:(SQL注入、XSS、上传、CSRF、一句话木马、等)为之后的WEB渗透测试打下基础。
② 查看一些论坛的一些Web渗透,学一学案例的思路,每一个站点都不一样,所以思路是主要的。
③ 学会提问的艺术,如果遇到不懂得要善于提问。
配置渗透环境 时间:3周 ~ 4周:
① 了解渗透测试常用的工具,例如(AWVS、SQLMAP、NMAP、BURP、中国菜刀等)。
② 下载这些工具无后门版本并且安装到计算机上。
③ 了解这些工具的使用场景,懂得基本的使用,推荐在Google上查找。
渗透实战操作 时间:约6周:
① 在网上搜索渗透实战案例,深入了解SQL注入、文件上传、解析漏洞等在实战中的使用。
② 自己搭建漏洞环境测试,推荐DWVA,SQLi-labs,Upload-labs,bWAPP。
③ 懂得渗透测试的阶段,每一个阶段需要做那些动作:例如PTES渗透测试执行标准。
④ 深入研究手工SQL注入,寻找绕过waf的方法,制作自己的脚本。
⑤ 研究文件上传的原理,如何进行截断、双重后缀欺骗(IIS、PHP)、解析漏洞利用(IIS、Nignix、Apache)等,参照:上传攻击框架。
⑥ 了解XSS形成原理和种类,在DWVA中进行实践,使用一个含有XSS漏洞的cms,安装安全狗等进行测试。
⑦ 了解一句话木马,并尝试编写过狗一句话。
⑧ 研究在Windows和Linux下的提升权限,Google关键词:提权
以上就是入门阶段
第三阶段:进阶
已经入门并且找到工作之后又该怎么进阶?详情看下图
给新手小白的入门建议:
新手入门学习最好还是从视频入手进行学习,视频的浅显易懂相比起晦涩的文字而言更容易吸收,这里我给大家准备了一套网络安全从入门到精通的视频学习资料包免费领取哦!
如果你对网络安全入门感兴趣,那么你需要的话可以点击这里👉网络安全重磅福利:入门&进阶全套282G学习资源包免费分享!