前言

在上一篇文章中，大致介绍了一些关于Web Cache的攻击方式及CTF中的一些出现。而本篇文章则会聚焦于Web Cache在学术前沿的一些攻击利用方式的探究。

本篇文章介绍的是发表在网络安全顶会2019 CCS的文章《Your Cache Has Fallen: Cache-Poisoned Denial-of-Service Attack》，主要介绍关于Server Cache Poisoning在真实世界的利用，以及所带来的Dos攻击。

背景介绍

关于什么是Server Cache Poisoning，还不知道的同学可以在之前的文章中做一些了解。

由于Server Cache的存在，第一个访问者的request显得尤为重要，稍有不慎，那么就可能缓存下一个恶意的response，使后来的访问者受到威胁：

那么本篇文章研究的就是这个问题，即利用恶意的request，使Cache缓存恶意的response，让访问者受到拒绝服务攻击：

通过特定的request，可以使目标网站缓存不同的response，例如使静态资源，甚至网站不可用：

方法实现

那么应该发送怎样的request，才会使Server Cache缓存恶意的request，从而导致拒绝服务攻击呢？

我们可以看到，攻击者可以发送一个带有恶意值(X-Malicious-Header)的request请求，而由于该请求是第一次请求，因此其不存在于Cache中，于是交由Origin Server进行处理，但是由于http header中存在非法值，导致Origin Server解析时出现400的错误，并进行response，而此时由于Cache服务器的设置问题，其错误的将请求example.org/index.html的请求，判定为response为400，从而导致以后的访问者再次访问该页面时，只能得到页面400错误的response，从而达成Dos攻击。

那么具体上，我们可以发送哪些恶意value使网站出现解析异常呢？

作者在此提出3种攻击方式：

· HTTP Method Override (HMO) Attack

· HTTP Header Oversize (HHO) Attack

· HTTP Meta Character (HMC) Attack

HTTP Method Override (HMO) Attack

对于HMO攻击，作者发现存在一些http header可以更改请求方式，例如如下几种：

X-HTTP-Method-Override
X-HTTP-Method
X-Method-Override

假设请求发送形式为：

GET /index.html HTTP/1.1
Host: example.org
X-HTTP-Method-Override: POST

此时服务器则会认为该请求为POST请求，于是会返回：

HTTP/1.1 404 Not Found
Content-Length: 29
Content-Type: text/plain
POST on /index.html not found

从而导致请求资源方式的错误，以至于Cache服务器缓存404页面，而以后的用户，如果正常通过GET访问该网址，则会导致DOS攻击，回显404 Not Found:

HTTP Header Oversize (HHO) Attack

对于HHO攻击，作者发现，如果request请求中某个http header属性值异常长，那么会导致目标服务器解析出现400 Bad Request问题。

那么假设攻击者请求：

GET /index.html HTTP/1.1
Host: example.org
X-Oversized-Header: Big value

则目标服务器将返回:

HTTP/1.1 400 Bad Request
Content-Length: 20
Content-Type: text/plain
Header size exceeded

那么当普通用户请求该网址时，就会访问到Cache中所记录的400 Bad Request页面，从而导致拒绝服务攻击。

但该攻击为什么会发生呢？我们知道例如CDN，是会对过长的request进行拦截的，并不会进行缓存或者发送至源服务器。

但对于一个request请求，其header长度通常被限制在8000 bytes以下，而例如Amazon CloudFront CDN允许的header长度却为24,713 bytes。因此如果攻击者发送的header长度为10000bytes，是可以通过CDN的拦截，并产生危害的。

HTTP Meta Character (HMC) Attack 

对于HMC攻击，作者发现为了防止CRLF攻击，通常http会禁止value中带有\n或\r等符号，但由于Cache对此可能并不做过滤，那么就会产生语义上的gap，假设攻击者发送请求：

GET /index.html HTTP/1.1
Host: example.org
X-Metachar-Header: \n

由于该请求为第一次请求，Cache服务器将其转发给源服务器，而源服务器解析由于遇到危险字符，将会返回：

HTTP/1.1 400 Bad Request
Content-Length: 21
Content-Type: text/plain
Character not allowed

但由于Cache服务器对这些字符未必有过滤，于是将其对应缓存下来，那么当正常用户访问该页面时，将受到400 Bad Request的回显，从而产生Dos攻击。

实验测试

作者为了验证自己的3种攻击方式的可用性，其选择5个较为出名的proxies caches以及10个CDN：

Apache HTTP Server (Apache HTTPD) v2.4.18
Nginx v1.10.3,
Varnish v6.0.1
Apache Traffic Server (Apache TS) v8.0.2 
Squid v3.5.12 
Akamai
CloudFront
Cloudflare
Stackpath
Azure
CDN77
CDNSun
Fastly
KeyCDN
G-Score Labs

首先，为了达成Dos攻击，那么要求上述缓存服务器必须可以缓存400 / 500等http状态的页面，于是作者先对其做了测试：

我们可以发现，只有Varnish, Apache TS, Akamai, Azure, CDN77, Cloudflare, CloudFront可以缓存400 / 500的页面,那么后面的攻击测试也将聚焦于此。

首先是HMO攻击，对于请求方式覆盖的http属性，作者先测试了一下哪些后端框架是可以接受的：

不难发现，Play1、Symfony、Lavarel框架都是默认支持这一方式的，那么如果后端使用上述框架之一，都可能遭受HMO攻击的影响。

对于HHO攻击，由于其关键点在于header限制长度语义不对等的问题，于是作者测试了一些现有web框架，CDN等header限制的长度：

从图中不难看出，假设目标网站使用Play2作为网站后端框架，使用Azure作为缓存，那么即可能遭受HHO攻击，产生Dos攻击，因为Play2的header长度限制为8319bytes，而Azure为24567bytes，如果攻击者发送10000bytes的header进行request，那么就可能被缓存下400 Bad Request的状态。

对于HMC攻击，由于其依赖于服务端对http header中关键字符的过滤，而缓存服务器则无视的语义差异，于是作者也做了相应的测试：

我们可以看到，当http header属性中带有\t，对于Play2后端框架会发生400 Bad Request，而对于CDN Azure，可以正常放行，那么如此一来，攻击即可用\t来攻击Play2+Azure的组合，产生Dos攻击。

综上所述，可以发现不同CDN和不同后端的组合可能都会引入安全隐患，以下是总结列表：

我们发现对于使用CDN CloudFront的网站，非常容易受到HMO / HHO / HMC的攻击。而对于Varnish, Akamai, CDN77, Cloudflare或是Fastly则相对安全。

与此同时，作者还对真实世界的网站做了测试，查看有多少网站使用较为危险的CDN或中间件：

发现1200万的urls是使用CloudFront，证明HMO / HHO / HMC攻击的可用度比较高。

总结

本篇文章基于Server Cache Poisoning的攻击原理，提出了CPDos攻击，可使用三种不同的攻击方式，使一些敏感CDN与web后端组合使用的网站出现DOS攻击，个人认为还是非常不错的。

本文为 一叶飘零 原创稿件，授权嘶吼独家发布，如若转载，请注明原文地址