记一次奇葩的应急响应

发表于 |
字数统计 1,313 | 阅读时长 5

上上上周末真是个不平凡的周末，周六公司举办“脉搏涌动”沙龙，虽然忙点，但是也是学到很多，况且还是自己第一次参加安全相关的会议。然后周末上午赶忙完成四爷安排的安全脉搏上的任务，写了个文章发到“安全脉搏”上。下午刚要出去吃饭，工作来了。。。

先说下自己在沙龙上学到的

  1. URL跳转的时候可以用\@绕过，\是利用浏览器和后端解析差异，@这个之前在ssrf上绕过用
  2. /%0a/这种形式可绕过一些目录限制以便进行其他操作，之前都用到crlf，waf等上
  3. 搜索敏感信息听说bing更强大，小伙伴还给我推荐了DuckDuckGo

总结起来就是：太年轻，年轻，轻。。。[捂脸][捂脸][捂脸]

好了，说下这次的应急响应及自己的思考。感谢加菲猫、四爷带我，跪拜啊！

0x00 事件描述

客户反馈从6月23日开始，网站访问延迟很大，重启服务之后会越来越慢，直至502。网站使用LNMP集成环境，服务器及数据库不是弱口令。6月25号客户买了相关安全产品，未发现明显的恶意攻击行为，同时服务器性能良好。

0x01 事件处理过程

首先我的第一反应是被D了，使用top发现服务器性能正常。

然后客户也买了产品，产品上也未出现异常。

然后使用了下自己做的信息收集的linux_信息收集.sh，搜集了下相关信息，查看也并没发现什么异常。

使用了Python版的webshell查杀，也TM没发现啥，各种看日志也并没发现什么卵用，这TM我就崩溃了。。。

然后我又考虑是不是Slow HTTP DDos，但是没办法验证啊。

本地复现的话客户肯定不让啊，无助啊。。。

没办法只能继续分析，然后事件出现了转机：

服务会呈现两种情况：

http资源未被占尽的情况下，可以访问静态资源以及直接查sql的路由链接，如：

1
2
http://xxx/wap/test.css?v=1
http://xxx/phpmyadmin/index.php

http资源完全被占满，导致静态资源都不能访问，查询进程会发现最大50个httpd进程全启动了。

由于最大只允许50个进程，所以导致这个时候静态和动态的资源都无法进行访问了。
检查nginx日志，log中有大量的499状态码，这个是由于客户端等待超时，关闭了链接导致。

暂且在proxy.conf中新增了proxy_ignore_client_abort on;

重启后，不在有客户端主动关闭链接的情况。

检查部分链接源代码函数，如在资源未占满情况下，访问此phpmyadmin/index.php请求是没问题的：

http://xxx/xxx/ajax.php

定位到/data/wwwroot/xxx/ajax.action.php文件，查看后发现就是一个简单的sql查询，然后打印了json。

然后访问 “找回密码链接” 每次延迟时间都在28.19秒左右，如下：

http://xxx/finduser/findpassword

于是定位到该方法的源代码函数位置，在渲染模版前，尝试die('111111');发现很快能显示111111

1
2
3
4
5
vi ./xxx/finduser.action.php
$title = "找回密码";
die('1111111');
include templates("mobile/user", "findpassword");

这说明模版在渲染前是没有问题的。

上边两步也就说明了：

  1. 不会是攻击的造成的。
  2. sql查询没问题。

之后猜测两种情况：

  1. 可能是缓存超时
  2. 也可能是连接某个第三方接口超时出现的问题

重新刷新页面，并同时查看端口syn_send情况，果然发现了问题：

netstat -anp|grep -i syn_sent|awk '{print $5}'|sort|uniq

1
2
140.207.119.12:443
58.246.220.31:443

每访问加载慢的页面，就会多一个这个ip的链接出来。
浏览器访问后，发现ssl标识是微信的接口。

api.weixin.qq.com -> 58.246.220.31
上边这个在服务器上是ping不通的。查看了下服务器上调用该api的文件。

find ./ -type f -name "*.php"|xargs grep "api.weixin.qq.com"

注释掉/xxx/jssdk.class.php等页面中的api.weixin.qq.com访问不在慢了。

至此，事件问题定位成功。

0x02 安全建议

  1. 最简单的，修改/etc/hosts。
  2. 和微信方取得联系，解封对api.weixin.qq.com的ip限制。
  3. 定位所有调用的api接口，看看还有哪些在服务器上是不能访问的，并进行替换。

0x03 事件思考

事后我们和客户交流，客户反馈：由于不可描述的原因，可能用户举报了他们，所以可能是这样导致他们微信API被封。

事后想了想，这TM思路真是猥琐啊！！！

然后联想到之前猪猪侠小密圈说的

所以，我们就可以利用这点，比如系统需要请求第三方API，那我们就可以构造恶意payload让服务器发送恶意的包或者频繁请求相关API，那么此接口就会被封掉，那么业务就崩了！

大爷，赏个铜板呗！