想哪儿说哪儿:入侵事件处置的思路

congtou 2016-10-8 黑客入侵 0 6

一般入侵者的流程是这样的:

03912
简单说,入侵者最终留下的攻击是一条线(无论是在动作还是在时间上)。当然,其中会有很多尝试的过程,每次尝试都会留下痕迹(如果不清除的话),然后在这些尝试中选择最好的一个点继续走下去,走完这条线。

所以,按照理想的状态下,分析者得到的结果应该是这样的:

4044

也就是说,把那些入侵者的所有痕迹都找到并联系在一起,同时将试错排除掉,最终得到的就是一条清晰的入侵路径,这条路径就清晰的说明了怎么来的、从哪儿来的、到哪儿去了 等等。

不过,一般我们看到的分析结果都是这样的:

4144
我见过很多入侵分析报告,里面给出了非常具体的一些点,比如:后门在哪里、怎么清除后门、漏洞在哪里、怎么修补漏洞。更见过很多套路是这样的,入侵分析上来不找证据不跟用户聊背景,而是先做一次渗透测试,把渗透测试的结果当作入侵者的攻击漏洞来放到最终的报告里说事儿。我完全看不懂其中的逻辑所在。

针对入侵事件的分析在于,将事件本身的起点、过程和终点通过证据链接到一起来回溯整个事件,这些与目标存在什么样的漏洞、缺陷本质上相关性并不大。

在入侵分析中,有很多标准化的检查流程,但我认为,标准检查流程只能应对标准hacking流程 —— 也就是说,正好对方是看教程出来的,而你也是拿着教程跟他对抗的 —— 你俩加起来就是一本教科书。

而对于有些技术基础的入侵者所实施的稍复杂的入侵,就只能说,大逻辑胜过小逻辑:

250

大逻辑是入侵者的意图、技术思路、并且结合目标特性而产生的一些其他东西。

而小逻辑就是很多标准流程里所描述的那样 —— 入侵者应该先外部采集、再扫描、再利用 ……

如果不能突破对大逻辑和小逻辑这两个区别的认知,一旦遇到稍复杂的入侵,就很难完整回溯整个事件。

*************************************

下面看两个案例说一下逻辑问题。

*************************************

案例一

  • 世界杯期间,被挂与世界杯无关的博彩
  • 被挂服务器只是全国几百台服务器中的一个
  • 被挂的服务器与其他服务器的后台用的系统为同一套系统

当然,处理博彩的案例相信很多人都有经验,甚至应该很多人比我更熟悉博彩那套自动挂页面的玩意。

但这里说的是一个利益逻辑问题 —— 明明可以挂世界杯,为什么还要挂传统的那些玩意;明明可以挂全国,为什么只挂了一个。

当然我们可以假设,这群家伙是为了低调奋进谋发展,但利益面前一比对这话就扯的有点不堪一击了。

所以看到这些条件的时候,我给出的基本判断就是 —— 这次被入侵者拿下的服务器,一定就简单的好像白捡的一样,才会这么不珍惜。

所以综合这些因素来看,有几个猜想点:可能用了简单的弱口令或已知漏洞,可能是自动化行为,可能利用了某些不在备案之中的服务器。

从后期沟通发现,已知漏洞概率比较小(具体原因不说了,反正不是没概率,只是相对来说概率较低)。所以转向清查资产和弱口令。

最终结果就是,一台没有在案的服务器,有个弱口令。而且有证据表明,入侵者从扫描到入侵甚至到后期发布页面,整个流程的自动化程度非常之高。

这里的大逻辑在于,通过利益和表现出来的结果进行分析,入侵者方是以薄利多销、多快好省为基本原则,这样的话,一定是最快、最简单的快速完成一次入侵和控制,而不是费时费力的上人、上设备、上资源。因此才有了上面的一些判断。

而传统的小逻辑(标准流程)其实也不是不成立,但一定是很难在其中发挥功效的。否则那些现场排查的人们,也不会毫无发现。

*************************************

案例二

  • 数据库被清空
  • 数据库仅能本地访问(B/S,Web和DB同服务器)
  • Web可从互联网访问
  • Web日志完整且无入侵痕迹

      登录后除了发现Web日志没有入侵痕迹外,还发现其他大量日志残留以及一个后门,通过这些线索,大概推理出一个删库的路径:

  • 远程控制控制服务器
  • SQL控制台添加用户、赋权、开放数据库远程访问
  • 出现一段没有任何操作的空白时间
  • 远程连接数据库删除数据库

乍看之下没有章法,但没有章法就是最大的章法,而且里面存在很多操作上的冲突,也是最大的疑问:

  • 远程控制和开放远程数据库访问乍看之下,存在先有远控后有开放数据库远程访问的合理顺序。但实际上,Web和DB同服务器,通过Web配置文件发现本地操作的用户就是sa,如果有了远控直接从这里下手根本无需添加用户、赋权、开放远程访问这么多操作
  • 有时间上的空白,明明已经得手,却要等待
  • 整个过程残留痕迹多到令人发指,不只是日志没有清除,包括数据库中新增用户都明晃晃的摆在那里,更不用说清除后门了

这个案例里面,实际上因为章法混乱,所以想要完全复原过程其实是比较难的。但也不是没有办法,毕竟日志是完整的,只要把各个操作节点和日志上的时间拼凑到一起,外加精力和体力,还是可以恢复的。

但是,至此我当时没有走回溯事件过程这条路,因为这些章法上的冲突和暴露出来的问题,已经将嫌疑人锁定的很清晰了:

  • 内部人
  • 不懂开发
  • 不懂安全
  • 与服务器有物理接触的机会
  • 很可能事发前后那段时间离职

最后事件的发生过程是这个“入侵者”坐在会议室里低着头讲给我们听的。

*************************************

为什么小逻辑很容易将其标准化,而大逻辑却没有办法说清楚。

回顾这两个案例就可以发现,大逻辑与特定场景相关性极大,第一个案例中,至少你要清楚博彩这件事里的利益问题,而且要知道世界杯期间的博彩行情,当然,我也不知道具体价格,但我还是很明白这类价格差异有多大的,这足以帮助我进行判断了。

而第二个案例更奇了,如果用常规标准化流程去推断第二个案例的话,一定是处处碰壁,如果是用远程渗透挖漏洞的套路来证明入侵途径的话,也很有可能会遇到死路。但是,如果以人的行为去推断的话,里面的逻辑就非常简单了。

所以,这里才是我说的大逻辑问题。

完成一次入侵,各种奇技淫巧都是有可能出现并因目标不同而产生千万种变化,但一定有某些技术之外、难以随意改变的东西是能抓住的。

最后,要记得多跟受害方直接相关人多聊天、多沟通,有些时候,他们说一句比你登录服务器查一个月还要来的有效。

转载请注明来自华盟网,本文标题:《想哪儿说哪儿:入侵事件处置的思路》

喜欢 (6) 发布评论