自动化渗透之路

自动化渗透之路

前言

自从创业后,很久没有做渗透相关的项目了,沉迷与写代码中。
枯燥的手工测试,并不是我喜欢的。打造一款自动化渗透工具一直都是我的目标。

需求

  • 多人协作
    渗透过程中存在信息不对称,共享不及时的问题。人多的时候很多时候都是在做很多重复的测试,因此需要一个协作平台来共享项目信息。
  • 报告生成
    除了渗透中花费的时间,在项目结尾编写报告也是很累人的工作,所以需要一个自动化生成报告的功能。
  • 扫描插件规范
    一款强大的工具需要多人来维护提供插件,我需要把框架搭建完毕,攻防人员提供检测payload即可,降低他们对写代码能力的要求。
  • 渗透工具云化
    渗透的时候经常在硬盘中翻找各类工具,对于windows下的工具,还要去打开个虚拟机。

    应该很多人遇到过下面几种情况:
    要打xss了,去打开个xss平台,建立项目。
    xss的cookie被httponly了,再去搭建个beef,进一步利用。
    要生成钓鱼页面了,自己还要去写个钓鱼页面。(set工具生成的有很多问题)
    需要metasploit去打exp了,因为要反弹shell,去外网搭建个msf。
    传一句话木马了,特么自己硬盘躺着的菜刀可能存在后门。
    … …. 此处省略1000字

    所以决定把这些工具都云化了。

改造之路

几年前写过dnslog跟被动式扫描,借此机会重新改造一番。

bugscan的扫描模式是运行py -> 请求服务端 -> 建立RPC连接
网上出现了几个版本的bugscan扫描模式,都是存在问题的。他们的做法是通过rpc通信,然后从服务器端拉取扫描插件,这么做就会使插件泄露。


总共1461个插件,直接全部dump下来。

首先这种模式,把消耗资源的放在本地,减轻服务器负担。并且能够访问内网资源,只是把扫描结果返回到服务器端显示。

他们经常会去客户现场干活,所以内网扫描的功能还是需要的。

粗糙的画了一张图:

把非核心的数据请求放在客户端,主要的核心判断逻辑放在服务端判断。

dnslog迁移中发生了个小插曲,因为迁移了服务器,所以我更改了指向的ip,但是等了2天还不生效。
最终让我吐血的是原因aliyun服务器默认安全策略把ip的端口都封了,配置下策略,开放下53端口即可。

万事具备 只差前端

ui早早的把产品设计好了,但是由于项目进度问题,迟迟不能开发渗透协作平台。

添加项目

信息聚合

看设计图就能很好理解我具体要做的东西,前端不够怎么办?
作为一个励志于德智体美劳全面发展的人来说,那就自己来。

前端之路

几年前用过django的template,后来又试过了Angularjs。这次换换口味,采用react。
找来一圈阿里的antd用着还行,现在出来antd pro,对于后台页面来说,写起来非常的快,对于我这种不怎么会css的人来说,直接用框架的组件,当拼积木一样拼起来挺好的。

截几张目前的作出来的功能
因为暂时先从扫描功能开始着手,做完后再合并到大项目,所以取名现在是passive_scanner。

  • dnslog
  • 扫描管理
    随便点了几个链接,测试了下界面效果

这几天写前端最深的感受是,后端半小时,前端写半天

插件之路

插件写的好不好,注定了这东西好不好用

讲讲我是怎么写命令执行插件的吧。命令执行有个特点,就是不一定立即执行。
比如可能是当初打过去并没有触发漏洞,但是在收集log日志,对log进行处理的时候,由于不安全的编码导致执行了log中的命令。

所以我们的命令执行首先会对每条payload进行个标签,并且存上对应的taskid,用来标识是那一条语句触发的。
当某天dnslog回来触发create的时候,进行signal重新把该条payload,漏洞类型,漏洞参数等存入报告。

不光命令执行,对于很多没有回显的漏洞都能利用dnslog来操作。
如存储型xss,imagemagic等等。

云化之路

项目刚开始几周,很多功能都是待上线中,但是后续的开发有了大概的构思

  • 云菜刀
  • 常见编码
  • metasploit的rpc调用
  • xss平台 吸纳set、beef的优点
  • 对接各类扫描器
  • 自主扫描插件完善
  • 内网代理
  • 反弹shell
  • …等等

这条路才刚刚开始,不多说了,继续写代码。

想要一起来共同打造一款神器的,欢迎发简历到huakai@intuq.com

下篇文章准备写
不懂运维的不是好黑客
不懂代码的不是好黑客