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

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

看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。例如这里我随便找个网站,我们手工测试一下:

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

试试刚才说的那个方法

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

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

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

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

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

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

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

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

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

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

原文地址

时间: 2024-10-07 22:28:32

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

CDN下nginx获取用户真实IP地址

随着nginx的迅速崛起,越来越多公司将apache更换成nginx. 同时也越来越多人使用nginx作为负载均衡, 并且代理前面可能还加上了CDN加速,但是随之也遇到一个问题:nginx如何获取用户的真实IP地址,如果后端是apache,请跳转到,如果是后端真实服务器是nginx,那么继续往下看. 实例环境: 用户IP 120.22.11.11 CDN前端 61.22.22.22 CDN中转 121.207.33.33 公司NGINX前端代理 192.168.50.121(外网121.207.

【知识学习】如何寻找真实IP

1.多地点ping查询IP,如果都一样可能没有使用cdn,如果有cdn,尝试海外地点ping查询IP 2.ping一下没有WWW的域名,可能存在真实IP.比如www.baidu.com设置了cdn,那么baidu.com可能没有设置 3.网站存在cdn可以在子域名的C段验证 4.找phpinfo 探针之类的探测消息 5.ddos,把它打到溯源(网上流传,但是这个方法一直没使用过) 6.发送邮件,利用网站的某些功能给自己发邮件,在邮件头可能存在真实IP 7.查询网站历史IP,有的网站一开始没有使用

PHP 获取真实IP地址

function getClientIp($type = 0) { $type = $type ? 1 : 0; static $ip = NULL; if ($ip !== NULL) return $ip[$type]; if($_SERVER['HTTP_X_REAL_IP']){//nginx 代理模式下,获取客户端真实IP $ip=$_SERVER['HTTP_X_REAL_IP']; }elseif (isset($_SERVER['HTTP_CLIENT_IP'])) {//客户端

多级反向代理下,Java获取请求客户端的真实IP地址多中方法整合

在JSP里,获取客户端的IP地址的方法是:request.getRemoteAddr(),这种方法在大部分情况下都是有效的.但是在通过了Apache,Squid等反向代理软件就不能获取到客户端的真实IP地址了. 如果使用了反向代理软件,将http://192.168.1.110:2046/ 的URL反向代理为 http://www.javapeixun.com.cn / 的URL时,用request.getRemoteAddr()方法获取的IP地址是:127.0.0.1 或 192.168.1.

hatcloud 绕过Cloudflare节点寻找源ip

hatcloud,由ruby语言所写,概率查询目标cloudflare节点的真实ip.下图是一张使用演示动态图. #安装 git clone https://github.com/HatBashBR/HatCloud #使用方法 ruby hatcloud.rb -h or --help #帮助 ruby hatcloud.rb -b 域名 或 ruby hatcloud.rb --byp 域名 #查询接口 http://www.crimeflare.com:82/cfs.html #离线下载

多级代理下获取客户端真实IP

1 /** 2 * 获取当前网络ip 3 * @param request 4 * @return 5 */ 6 public String getIpAddr(HttpServletRequest request){ 7 String ipAddress = request.getHeader("x-forwarded-for"); 8 if(ipAddress == null || ipAddress.length() == 0 || "unknown".equ

11种绕过CDN查找真实IP方法

0x01 验证是否存在CDN 方法1: 很简单,使用各种多地 ping 的服务,查看对应 IP 地址是否唯一,如果不唯一多半是使用了CDN, 多地 Ping 网站有: http://ping.chinaz.com/ http://ping.aizhan.com/ http://ce.cloud.360.cn/ 方法2: 使用 nslookup 进行检测,原理同上,如果返回域名解析对应多个 IP 地址多半是使用了 CDN.有 CDN 的示例: www.163.com 服务器: public1.11

浅谈个人博客网站or屌丝vps服务器暴露真实IP的危险性

经常关注张戈博客的朋友应该注意到,张戈在以往的文章中多次提到要隐藏我们网站服务器的真实IP,比如最近分享的<阿里云盾网站安全防御(WAF)的正确使用方法>,肯定有不少人心怀疑问,这是为什么呢? 一.为啥隐藏真实IP? 今天,抛出这样一个话题,也是为了提醒那些还懵懵懂懂,毫无设防的屌丝站长们!我们是小网站,我们用的也是屌丝服务器,不像腾讯.网易那些大站用的是价格昂贵.性能卓越的高性能.高可用集群.我们这种屌丝服务器一旦被人恶意攻击基本玩完! 也许,大部分人和我有一样的想法:这有啥,开启高防CDN

使用BurpSuite的Collaborator查找.Onion隐藏服务的真实IP地址

本文转载!!! 原文地址:http://www.4hou.com/technology/10367.html 翻译来自:http://digitalforensicstips.com/2017/11/using-burp-suites-collaborator-to-find-the-true-ip-address-for-a-onion-hidden-service/ (原文发自2017感恩节) 在这个感恩节,我想要写一些关于我们所有人都喜欢的东西:馅儿.我不是在谈论今天下午你将要买到的美味面