一篇文章带你读懂 TLS Poison 攻击（三）

STATEMENT

声明

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，雷神众测及文章作者不为此承担任何责任。

雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经雷神众测允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

NO.1 前言

本篇文章是《一篇文章带你读懂 XXX 攻击》系列的第二篇文章，主要讲述了 TLS Poison 攻击对应的三种攻击方式、一些可能算是“新”的 DNS Rebinding 技巧以及一些关于 IP 选择探索等内容。

使用《一篇文章带你读懂 XXX 攻击》的标题既是为了督促自己把一个攻击尽可能多的细节尽可能地搞懂，也是为了提升自己的写作能力以及表述水平。本文旨在帮助大家了解学习 TLS Poison 攻击，希望能够通过一篇文章让大家读懂 TLS Poison 攻击。但是，仅仅是网络协议便涉及到很多内容，仅靠本文是不可能完全读懂的，本文的内容也并非完全正确，所以也希望大家抱着怀疑的态度合理对文章提出质疑。

本文主要是对 Black Hat USA 2020 - When TLS Hacks You 议题的整理与复盘，该攻击是一种利用 TLS 协议特性结合客户端实现缺陷达到攻击内网应用的攻击方式，可以达到任意写入 Memcached 等内网服务的攻击效果，进而配合其他漏洞造成 RCE 等危害。

这是去年在 black hat USA 被提出的一项攻击方式，但作者在提出这个攻击方式后，由于种种因素，他放出来的 demo 并不能直接使用，所以我在对该项的研究复现中整理了很多攻击细节，以及一些可以拓展的地方，还有一些关于计算机科学知识的探索。

本文主要分成三部分，第一部分主要简单讲述一些必要的背景知识，第二部分会详细记录三种攻击方式的实现步骤，第三部分会讲述一些关于在复现过程中的一些思考以及相关探索的内容。如果还有后续的进展，我也会同步到自己的个人博客上，欢迎关注，以及前来交流：https://blog.zeddyu.info/

如果对该篇文章有任何疑问或质疑，欢迎来信：

echo emVkZHl1Lmx1QGdtYWlsLmNvbQ==|base64 -d

欢迎对协议安全等内容感兴趣的同学一起交流学习！

PS: 如无特殊说明，整个实验背景均基于 Ubuntu 20.04 LTS ，curl 7.68.0 build with OpenSSL/1.1.1f  ，后文提到的 IPv6 均指的是  IPv4-mapped IPv6 addresses 这类地址

由于内容较多，原文将会被分成四节文章在该平台上进行发布，本篇为该文章的第三节。

NO.2 TLS Poison

上一篇文章详细展开讲述了TLS Poison 攻击，今天让我们来继续讲述这一攻击方式。

- The Optimization Method OF DNS Rebinding

就像我们前文所提到的，这个攻击主要取决于两个点，一个是 TLS Session Resumption ，另一个就是 DNS Rebinding 。一个好的 DNS Rebinding 可以起到事半功倍的效果。

我询问了一些 CTFer ，也查证了一些 DNS Rebinding 的工具，诸如 rbndr / ceye 等比较常用的工具，一般统一做法都是每次返回一个 TTL 较小的 A 记录，只不过每次返回的记录不同，大部分都是在用户指定的 A 记录当中随机概率返回一个。这样如果使用这些 DNS Rebinding 工具在这里就不是一个非常好的选择。

随后，@zhaojin 在 基于 A 和 AAAA 记录的一种新 DNS Rebinding 姿势–从西湖论剑2020 Web HelloDiscuzQ 题对 Blackhat 上的议题做升华 提到新的方法，似乎可以使用一个域名同时分配一个 A 记录跟一个 AAAA 记录，因为 curl 会优先使用 AAAA 记录，而当 AAAA 记录的 IPv6 无法建立连接时，会尝试跟 A 记录的 IPv4 进行建立连接。我觉得是个很有趣的想法，整个思路大致如下：

在 CURL 中，对于一个域名，如果同时具有 A 记录和 AAAA 记录，那么 CURL 会去优先请求 AAAA 或者 A 记录所指向的地址，如果这些地址无法连接，则会尝试连接同时得到的 A 记录或者 AAAA 记录。

在某些情况下，会出现：

AAAA 记录地址不通，会连接到 A 记录地址上。

A记录地址不通，会连接到 AAAA 记录地址上。

但是比较遗憾的是，如果对于一个域名进行这样的设置，AAAA 记录指向 TLS VPS 的 IPv6 地址上，A 记录指向 127.0.0.1 地址，实际测试 当中， curl 总是优先 127.0.0.1 ，并且没有随机的做法；如果对于一个域名进行这样的设置，AAAA 记录指向 ::ffff:127.0.0.1 或者 ::1 地址上，A 记录指向 TLS VPS 的 IPv4 地址上，虽然似乎可以做到 curl 因优先 AAAA 记录与 TLS VPS 建立连接获得恶意 Session ID ，但是实际测试默认 memcached 配置，无法通过这两个(::ffff:127.0.0.1 或者 ::1)地址进行写入 memcached 。

虽然有些遗憾无法复现 @zhaojin 所说的这个方法，但是我觉得是个很有趣的想法，以及 @Ivan Komarov 提到 DNS 对于一个域名可以返回双 A 记录，也能有类似的效果，所以我们可以这样进行尝试：

那根据已知信息，那么与上文的做法类似，我们是不是也可以让 curl 第一次建立链接，拿到我们分配的 payload 后，断开连接，让其第二次连接不通而去选择另外一个 IP 呢？

事实说明，我们也确实可以这么做。基于 @Ivan Komarov 提供的 DNS Server 以及 @zhaojin 使用的 proxy.py ，我们可以拉取我整理的仓库 https://github.com/ZeddYu/TLS-poison 进行实验。

这里 DNS VPS 的 setup 我们需要使用 client-hello-poisoning/new-custom-dns/alternate-dns.py 进行我们域名的解析：

python3 alternate-dns.py tls.example.com --ip x.x.x.x --mode static_zero

x.x.x.x 为你 TLS Server IP ，mode 有两种，rebinding模式则为普通的重绑定解析模式，static_zero则是我们这次测试的双 A 记录。

TLS VPS 的 setup 还是与之前一样，只不过这次我们需要把 TLS Server 的端口绑定在 11210 上，使用 proxy.py 将 11211 的流量转发到 TLS Server 上，而且该转发只转发一次，所以可以造成 curl 第二次连接失败，也就能让其切换到另一个 IP 进行连接了。

target/debug/custom-tls -p 11210 --verbose --certs /root/tls/fullchain.pem --key /root/tls/privkey.pem http

Ok. Let's have a try.

可以看到这里 curl 不需要再经过多次重定向，只需要一次重定向就可以稳定进行 SSRF ，也不再需要依靠 DNS Rebinding 的稳定性了。

- Use The Optimization Method To Deal With TLS 1.2 Session Ticket

尽管我们可以使用 TLS 1.3 PSK 进行 Session Resumption ，但是根据 https://caniuse.com/?search=tls%201.3 的数据显示，目前 TLS 1.3 全球覆盖率为 91.12% ，而 TLS 1.2 的覆盖率为 98.4% ，并且目前淘宝、百度等知名主站均还没有完全支持 TLS 1.3 ，所以有些时候还是需要我们使用TLS 1.2 ，而作者又偷了一点懒，没有实现任何 TLS 1.2 相关的利用方式，而 @zhaojin 使用的 tlslite-ng 目前还并未支持 TLS 1.2 当中的 Session Ticket ，而又正好作者修改的 rustls 实现的功能比较完善，所以我只能硬头皮刚了一波 rust ，为原作者的 TLSServer 增加了基于 TLS 1.2 Session Ticket 的修改功能。

依旧使用我修改的仓库 https://github.com/ZeddYu/TLS-poison ，对于 DNS Server setup 还是使用优化的双 A 记录的方法，但是对于 TLS Server setup 我们需要改变一下：

target/debug/custom-tls -p 11210 --verbose --certs /root/tls/fullchain.pem --key /root/tls/privkey.pem --tickets --protover 1.2 http

使用参数--tickets，允许 TLS Server 使用 Session Tickets 进行 Session Resumption ；使用--protover 1.2参数，只允许 TLS Server 最高使用 TLS 1.2 版本。并在 redis 设置 ticket_payload ，这个与之前设置的 payload 值一样，是用来对 memcached 进行利用的，我们这里就区别于之前随便设置一下就可以了，例如set ticket_payload "rnset foo 0 0 41nThis is a TLS 1.2 session ticket example.rn"

对于 Client ，我们不能再使用 curl ，因为其并没有实现 Ticket Session 插件...所以我选用了老版本 Chrome 70.0.3538.77 for Ubuntu 进行学习。（提醒这里不要用 Firefox ，因为作者在 PDF 中表示过 Firefox 没有这个“特性”）

依旧在 TLS Server 上使用 proxy.py ，接着确定准备好就可以在本地打开 chrome 访问自己 TLS Server 的地址：

因为 Chrome 的一个特殊机制，使用 Chrome 测试我们并不能像 curl 那样一次就能成功，这里我们最好使把 Chrome 的 Keep local data only until you quit your browser 选项打开以及设置每次打开 Chrome 时就打开我们的 TLS Server 地址，这样实验就比较方便了，多试几次我们就可以看到上图这个效果。

- Use The Optimization Method To Deal With TLS 1.2 Session ID

那要是遇到只能用 curl/libcurl ，而且 TLS 1.3 又不支持的情况，那就只能通过 TLS 1.2 Session ID 来实现我们注入 payload 实现 SSRF 了，我们能做的就是使用双 A 记录的方法来提高攻击稳定性。

由于作者写的不是很好，并没有对 TLS 1.2 进行适配，而我也并不熟悉 rust ，只能勉强找到作者代码库的问题，大概就是由于作者在 main.rs#730 循环中每次都使用了新的 config ，如下代码所示：

loop {  poll.poll(&mut events, None)  .unwrap();
  config = make_config(&args, session_id_generator.clone());  tlsserv.tls_config = config;
  for event in events.iter() {    match event.token() {      LISTENER => {        if !tlsserv.accept(&mut poll) {          break;        }      }      _ => tlsserv.conn_event(&mut poll, &event)    }  }}

导致了在 rustls/src/server/hs.rs#718 中每次根据client_hello.session_id.get_encoding()都取不到存储的 Session ID

// Perhaps resume?  If we received a ticket, the sessionid// does not correspond to a real session.if !client_hello.session_id.is_empty() && !ticket_received {  let maybe_resume = sess.config.session_storage  .get(&client_hello.session_id.get_encoding())  .and_then(|x| persist::ServerSessionValue::read_bytes(&x));
  if can_resume(sess, &self.handshake, &maybe_resume) {    return self.start_resumption(sess,      client_hello, sni.as_ref(),      &client_hello.session_id,      maybe_resume.unwrap());  }}

所以我们只需要把 main.rs#734 以下两行进行注释即可：

  // config = make_config(&args, session_id_generator.clone());  // tlsserv.tls_config = config;

虽然可以 debug 找到问题所在，但是并不能完美地修正这个问题，只能做个临时的处理办法来解决这个问题，而且自己时间精力并不太足够，所以如果有同学有比较好的办法解决这个问题欢迎提 PR 修正这个问题！

然后在 redis 中修改 payload 为 32 字节长度：set payload "rnset foo 0 0 13nI am so poor.rn"。好了，那就让我们来试一下吧！

虽然我们只能使用 32 字节的 Session ID ，但是对于 memcahed ，我们可以使用append命令进行追加，例如：set payload "nappend foo 0 0 11nSo so poor.rn"。并且因为我们注释了那两行，所以对于重新设置了的 payload ，我们需要重新启动一次 TLS Server

好了，以上就是我们关于 TLS Poison 漏洞复现的部分。

- Attack Impact

在作者的报告中指出如下的 Client 对 TLS 会话进行了缓存：

作者还给出了在内网中易受攻击的服务：

RECRUITMENT

招聘启事

END