vhosts.conf配置不当引发的血案

说起来这个问题比较有意思,是一次偶然的意外发现,经过一系列追踪,最后发现vhosts.conf配置的锅,所以分享一波给大家,相信不少的人也会遇到和我同样的问题。

起因

本文源于一日我测试公司的安全产品,便对自己的网站做了一个反向代理,大概就是下图的样子。

proxy ip:172.12.16.118

myweb ip:www.stardustsky.net / 115.28.85.23

当我通过proxy访问myweb时,本人的网站目录清晰地展示在页面上。

image

作为一个搞安全的,当时就吓尿了,这是什么情况,为什么列目录了,而且phpinfo.php也可以直接访问?

遂又去使用网站本身ip 115.28.85.23和域名www.stardustsky.net进行了访问,直接定向到了网站首页,以115.28.85.23/phpinfo.php这样的方式也是无法访问的。

image

image

那这是什么问题呢?为什么做了一次反向代理之后,就可以列目录了?带着好奇本人开始探索起了原因。

追溯

首先是列目录的问题,这个很有可能是我的网站配置的锅,允许了列目录,上服务器一看,果然开启了这个选项,遂将允许列目录关闭

image

但这样利用反向代理访问虽然无法直接列目录,回显了403 forbidden,但任然可以访问phpinfo.php文件,说明其定位依旧在根目录下,依然可以对我的根目录下的文件进行爆破。

这里就需要介绍一下我的网站配置了,web根路径位于www目录,然后网站地址就如之前图中所示,位于hyx这个目录下面,然后有了一个解析配置

image

也就是说无论你是通过ip还是通过域名访问我的网站,都会被解析到hyx这个目录下面,正常来说是无法访问到我的根目录的,那为什么反向代理之后就可以?

继续寻找原因,为了知道网站到底出了什么毛病,登录到了反向代理服务进行抓包操作,看经过反向代理服务器后,数据包是否发生了某些变形,导致该问题的产生。

利用tcpdump抓包后一看,数据包变成了如下

GET / HTTP/1.1
Host: 172.12.16.118
X-Real-IP: 172.12.16.233 
X-Forwarded-For: 172.12.16.233 
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: Hm_lvt_08d50008e85b426e16ba278e344a5c3b=1508750770; Hm_lpvt_08d50008e85b426e16ba278e344a5c3b=1508751331; Hm_lvt_7ac440db71cd07501fb9cc6b28745fd6=1508750770; Hm_lpvt_7ac440db71cd07501fb9cc6b28745fd6=1508751331
Connection: close

相比于一个普通的数据包,有两个地方值得注意

Host: 172.12.16.118
X-Real-IP: 172.12.16.233 
X-Forwarded-For: 172.12.16.233 
  • hostip是172.12.16.118,这是代理服务器ip而非webip 115.28.85.23
  • 多了X-Real-IP和X-Forwarded-For字段,而这两个ip不知是哪来的,有什么作用

经过测试发现,X-Real-IP和X-Forwarded-For并没有什么实际影响,主要的影响来自于host,测试结果为:

  • 如果host值为115.28.85.23或 www.stardustsky.net,网站正常解析
  • 如果host值为其它任何值,均会被解析到根路径下,出现列目录情况

由此我们可以看出来,如果host值命中我们前面的解析规则中的ip或域名,那就会按解析规则定向到对应的目录下,如若没有命中,则会解析到根路径下,进一步可以推测,服务器对域名解析的目标判断来源是数据包的host值。

分析

这样一来就找到了造成服务器端列目录的原因,我们继续分析一下为什么host值不在解析列表中就会造成列目录。

这也就到本文的重点了,服务器对域名解析的配置文件被独立出来,名字就叫vhosts.conf,位于Apache\conf\目录下,打开一看,服务器的解析配置如下

<VirtualHost _default_:80>
DocumentRoot "C:/WWW/"
</VirtualHost>
<Directory "C:/WWW/">
    Options -Indexes +FollowSymLinks +ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

<VirtualHost *:80>
    DocumentRoot "C:\WWW\hyx"
    ServerName www.stardustsky.net
    ServerAlias 
</VirtualHost>
<Directory "C:\WWW\hyx">
    Options FollowSymLinks ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>
<VirtualHost *:80>
    DocumentRoot "C:\WWW\hyx"
    ServerName stardustsky.net
    ServerAlias 
</VirtualHost>
<Directory "C:\WWW\hyx">
    Options FollowSymLinks ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>
<VirtualHost *:80>
    DocumentRoot "C:\WWW\hyx"
    ServerName test.stardustsky.net
    ServerAlias 
</VirtualHost>
<Directory "C:\WWW\hyx">
    Options FollowSymLinks ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>
<VirtualHost *:80>
    DocumentRoot "C:\WWW\hyx"
    ServerName 115.28.85.23
    ServerAlias 
</VirtualHost>
<Directory "C:\WWW\hyx">
    Options FollowSymLinks ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

可以看到,除第一条外,下面的所有配置,都明确指向了那个domain对应于那个目录,而第一个默认的配置却指向了C:/www/ 目录,这很可能就是我们列目录的原因,将其改为C:/www/hyx后重启服务器。

果然,访问反向代理ip 172.12.16.118被直接定向到了我们网站目录,和直接访问ip或域名效果相同,而phpinfo.php也无法再访问。

总结

这里还原一下整个问题产生的过程

  1. 服务器端做了反向代理
  2. 反向代理后客户端向服务器端发送的数据报host值被修改
  3. 服务器域名解析规则中未发现改host
  4. 由默认配置解析到了根路径\www\下
  5. 列目录未关闭
  6. 列目录问题产生

由于我是使用的phpstudy架设服务器,直接在UI界面中配置了域名解析,所以没有预料到会出现这个问题。当然这个问题的出现也需要以下条件:

  • 网站不位于服务器配置的web根目录
  • vhosts.conf文件配置错误,默认都是坑啊,还是要自己检查
  • 列目录权限开启,这个问题不应该,关闭这个选项,403 forbidden虽然依然存在爆破风险风险,总比直接看到强,我就是太自信,以为别人不可能列目录

    <Directory "D:/Apache/blog.phpha.com">
    Options Indexes FollowSymLinks # 修改为: Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all

    去掉Indexes即可

由于是默认配置,我想,利用这种host trick应该能搞到不少存在该问题的主机。

最后,安全无小事,不能在任何地方有疏忽。

本站部分资源收集于网络,纯个人收藏,无商业用途,如有侵权请及时告知!