CloudFlare防护下的破绽:寻找真实IP的几条途径

  • A+
所属分类:网络安全

本文仅代表作者独立观点,本文提及的技术仅供安全研究和渗透测试用途

看Twitter发现CloudFlare总裁什么的最近很高调,北京、香港的跑着参加会议、发表演说什么的,CloudFlare似乎也没那么牛逼吧。前段就关注过比较火热的CloudFlare如何抵御住大流量的攻击。政治跟咱没毛线关系,但你说你那么牛,这就有点不太合适了吧。

目前大部分的网站都基于虚拟化部署,说的高大上一点就是云技术和CDN技术。在闲暇之余也关注过这个事情,毕竟是比较先进的技术,以前传统的入侵渗透都是基于单主机,最多就是作一下负载均衡和反向代理。所以在寻找网站的真实IP上,不用费太多的力气,对真实主机进行信息探测和其他的操作。就不多废话,大家都懂,说多了有装逼之嫌。

现在很多网站都使用CloudFlare提供的服务,大家可能以往也都遇到过,如何绕过CloudFlare的防护,找到真是的网站IP,估计大家都比较蛋疼,肯定不止我一个人蛋疼。其实就前段时间CloudFlare被DDoS的事件,直接点说就是那个投票网站被DDoS,没搞死的重点不是CloudFlare的防护牛逼,而是木有找到网站服务器的真是IP,那么多攻击方式,那么大的流量,我想搞死一个小网站是分分钟的事情。扯淡扯远了,咱讨论的是如何找到经过CloudFlare防护的主机真实IP。在Wooyun里面有过关于CDN找真实IP的讨论,我在这里也说一下我个人的一些经验,就拿CloudFlare的客户做例子。

找真实IP是个体力活,需要各种耐心和运气成分。

常规的方式一,找子站和子域名,看看有没有子站没有经过CDN的防护,二级,三级甚至四级域名。

二、查找看看有没有邮件系统,一般的邮件系统很多都是在内部,没有经过CDN的解析,这样通过查看原始的邮件头部,可以看到真实的IP。第三就是通过查询域名历史信息,一般的域名的历史信息,还是可以查询到真实IP的,CloudFlare有个比较弱智的硬伤,这是通过一段时间观察分析所得出的结果,这个也可能是一个设计的缺陷,也可能是为了管理识别。大部分通过CloudFlare保护的网站都有一个direct-xxx(xxx对应网站域名)的子站,通过这个子站我们可以获得该网站的真是IP。例如这里我随便找个网站,我们手工测试一下:

CloudFlare防护下的破绽:寻找真实IP的几条途径

CloudFlare防护下的破绽:寻找真实IP的几条途径

CloudFlare防护下的破绽:寻找真实IP的几条途径

我们不做DDOS,没必要去较真网站的真实IP是什么,但如果渗透过程中需要从Web入手,而暂时又找不到可利用的漏洞,需要通过其他弱智的方式来进行入侵,如各种C段的渗透等,那样真实的网站IP就显得比较重要了。OK,先ping一下,看看, 141.101.122.201,美国。

CloudFlare防护下的破绽:寻找真实IP的几条途径

试试刚才说的那个方法

CloudFlare防护下的破绽:寻找真实IP的几条途径

蛋疼了,被CloudFlare隐藏的那是相当的深了,这果然是特殊照顾的客户啊。这里就不得不祭出神站了,提到一个比较叼的网站,www.crimeflare.com,网站有个DomainSearchBox,可以对CloudFlare客户网站进行真实IP查询。这个估计是哪个哥们跟CloudFlare网站过不去建立的吧。 

CloudFlare防护下的破绽:寻找真实IP的几条途径

果断发现真实IP,147开头,香港大学的,具体地址就不透露了,免得顺丰快递上门服务。如何验证真实性呢,最简单的办法就是修改本地的Host文件,真实的IP对应与之对应的域名即可。但是验证了一下,发现不对,这只是曾经用过的一台服务器IP地址,应该是这鸟网站扛不住的时候CF帮忙搬家了,这里只能呵呵一下。看了下C段,全是香港大学的机器,没啥兴趣,搞来意义不大,就不浪费时间了。然后各种抓包分析,后来还是没突破,最终拿到了个CDN的小工具,类似于核总写的CDN终结者一样吧(某大牛,具体名字就不方便透露了),配和工具倒腾了会,竟然还真让我找到了一个在美国的IP地址(54.xxx.xxx.xx),查一下地址看看。

CloudFlare防护下的破绽:寻找真实IP的几条途径

CloudFlare防护下的破绽:寻找真实IP的几条途径

验证后果然为真实服务器,果然是AWS地址上,也验证了之前所有的想法,原来躲在了在亚马逊云上面,又是用的EC2产品,对ec2不太了解,注册了个aws看了看,对于EC2这种产品没有0Day是基本直接渗透没希望的。

不过写这个文章的时候手贱又看了下,发现真实的IP又变回了香港大学,具体的地址自己查都可以验证的,不能说太多,当心顺丰快递和那啥。

好不容易挖出这个站,当然也不想轻易放过,继续,各种扫描器一并带出,端口、路径、AWVS纷纷上去,果然让我找到一个复杂一点的注入点(估计现在没了额),就是HTTP头部的延迟注入,抓个POST包,构造如下:

CloudFlare防护下的破绽:寻找真实IP的几条途径

好了,那就丢SQLMap里去跑吧:

CloudFlare防护下的破绽:寻找真实IP的几条途径

MySQL的数据库,Web还是和数据库分离,好吧,就不考虑导出Shell了,看看数据走人吧。一个个字母的出来,果然好慢啊。耐心等待吧,爆出版本、路径了,继续爆爆数据库、数据表、列名什么的。不过这破数据就电话和身份证号有用点吧,连个名字都没有,指定下列名什么的,就开始Dump了,一列身份证号,一列手机号,香港人和咱又扯不上什么关系,尽管社吧。

CloudFlare防护下的破绽:寻找真实IP的几条途径

漏洞验证完毕,其他数据就不在话下了。多的就不说了,已打包在附件中,为保护自己的水表,害怕警察蜀黍啊,所以特意加密。解压密码可以私聊,仅作技术交流吧,这次也算是赶上了一次潮流,分析了分析。

补充一:花了一定时间,也翻遍了核总、鬼仔等大牛的博客,更是多亏算是0Day级的针对CDN的分析、抓包工具吧,所以才有这次针对CloudFlare公司的产品和客户的一次全面分析。有人质疑CloudFlare不能代表所有CDN公司,其实我觉得这个是一通百通的道理,并且关键是在于积累,人家技术也确实牛逼,这点不得不承认,亚马逊云主机EC2不谁都没漏洞利用工具么,所以绕过不容易,搞定也不容易,贵在坚持。

补充二:关于数据的问题,作为搞技术的,尤其是白帽子而言这些数据对我没有任何意义,漏洞证明需要才会稍微注入一下,最终也是利用Sqlmap完整脱裤,网盘地址:http://1drv.ms/1vcg96F。目前仅限于私底下交流,密码私信,JC请绕道。

原文地址

  • 我的微信
  • 这是我的微信扫一扫
  • weinxin
  • 我的微信公众号
  • 我的微信公众号扫一扫
  • weinxin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: