标签 Fuzzing 下的文章

碎碎念之Afl-fuzz Docker实践

开篇

好久没有更新东西了,写一篇水文压压惊吧。这篇文章主要记录一点之前鼓捣Afl-fuzz的笔记,涉及的知识不深,看官们别见笑。作为程序猿周围的安全工程师,我们负责着产品线的测试。这有靠经验来做的黑盒测试,也有靠自己反编译安装包,鼓捣设备得到部会源码的进行灰盒测试,也开始引进Fuzz模糊测试-这就靠下面要说的Afl-fuzz来实现。因为众所周知的问题(搞安全的人在公司地位低),我们没有产品的代码级权限,我们用Afl-fuzz也就当黑盒一样的在玩,下面会解释到。开始吧。。少侠们。。。

初见Afl-fuzz

了解Afl-fuzz之前我们先了解一下什么是模糊测试,定义:模糊测试是一种通过自动或半自动的生成随机数据输入到一个程序中,并监视程序异常,以发现可能的安全漏洞的技术。Fuzzing技术是当前鉴别软件安全问题方面最强大测试技术, American Fuzzy Lop (简称:Afl-fuzz)是一个优秀的模糊测试工具。使用Afl-fuzz 在有源码条件下可以使用afl-gcc 或者 afl-clang-fast 编译源码,afl在编译的时候完成插桩,如果无源码条件下可以使用qemu模式进行插桩. 对于Fuzzing网络程序,可以使用persistent模式进行测试,我鼓捣的就是使用persistent模式进行Fuzzing。

服务器环境:Ubuntu14.04 4核心 8G内存
我的目的:我们用Afl-fuzz的目的很简单,实现快速的对多个样本同时进行Fuzzing。

关于Afl-fuzz的基础用法,有很多前辈写了,可以搜索一波自行学习,这里使用的是while (__AFL_LOOP(1000))写法即persistent模式,使用afl-clang-fast++编译c写的sender, 用于从文件读取Afl变异产生的payload,发起HTTP请求包,简单的可以参考@小葵师傅的https://www.jianshu.com/p/82c361c7d439

简单来说,使用persistent模式运行Afl-fuzz,需要准备这几个东西:

  1. seed 输入样本
  2. out 指定输出目录
  3. sender afl-clang-fast++编译的可执行程序
  4. case.txt 完整的请求包

过程就是: Afl-fuzz工具执行sender, 读取case.txt的基础请求包,使用基于seed进行变形产生的数据替换请求包中标记的位置,这样构造的新的请求包,再发给服务器。

我弄了一个shell脚本,方便我快速编译和运行Afl-fuzz对样本进行Fuzzing.脚本如下:

AFL-分布式模式尝试之shell脚本:

riversec@box:~/test/test/test_shell$ cat run_aflfuzz 
#./run_aflfuzz fuzz_cross_site_uri 5
cd $1
afl-clang-fast++ sender.c -o sender
screen -AmdS MasterFuzz_$1 bash
screen -S MasterFuzz_$1 -X screen afl-fuzz -M master -i seed/ -o out/ ./sender request.txt
for (( i=3; i<$(($2+3)); i++ ))
  do
   screen -AmdS ClusterFuzz$(($i-2))$1 bash
   screen -S ClusterFuzz$(($i-2))$1 -X screen afl-fuzz -S Cluster$(($i-2))$1 -i seed/ -o out/ ./sender request.txt
 done
screen -ls
echo "start over..."

上面的shell实现了afl-clang-fast++编译sender,用了screen管理挂起任务,使用AFL的 Master/Cluster模式进行分布式Fuzzing. 调用命令如下:

./run_aflfuzz fuzz_cross_site_uri 5
  • fuzz_cross_site_uri 是screen会话TAG,方便区分节点
  • request.txt 是burp抓的完整的HTTP请求包
  • seed 是输入,即从HTTP请包中,需要模糊测试的点,提取的值作为变异种子
  • out是输出,AFL的状态信息,输出文件保留在此
  • 数字5 是创建5个节点

虽然上面只对同一个样本进行Fuzzing, 但是实现了分布式Fuzzing,哪么是不是我只需要多执行几次run_aflfuzz命令,再对其他对样本进行测试,就能实现我想要的目的呢?

结果动手了才会发现,事情并不是那么简单。。。

遇到了什么问题?

发现问题1:CPU 核心限制了同时Fuzzing的样本数

因为平时工作时需要测试各种功能,就会有很多种类型的请求包需要进行Fuzzing,我们在同一台机器上想跑多个样本时,总会有遇到如下的提示:

201808231535036581290334.png

使用过Afl-fuzz的同学可能会很熟悉,这都是穷惹的祸啊。。4核心难道就只能跑4个样本了吗??

发现问题2:手动抓样本,制作seed,标记Fuzzing位置

目前条件下,每当我要Fuzzing一个样本,我需要重复做几件事:

  1. burp抓取HTTP包
  2. 使用$替换要Fuzzing的位置,比如tid=888,标记为tid=$
  3. 将888作为seed
  4. 使用afl-fuzz命令开启Fuzzing.

每一个样本都需要做这些操作,虽然没有几步,但是让人很不耐烦。。

一步一步实现

遇到上面的问题后,就开始思索怎么解决。首先解决第一个CPU核心数限制问题,我这里首先想到使用docker虚拟化技术来做,经过验证后发现是可行的。

下面具体说说如何实现。

1.安装docker

第一步安装docker,安装过程这里就不说了。

2.搜索images

搜索仓库里是否有前辈做好的afl的images,直接拿来使用。

docker search afl

搜出来的第一个,就可以直接拿来用,我用的就是这个。如图所示:

201808241535091650456788.png

pull下来做一些自己的定制化后,再docker commint 创建一个自己的新images.

3.创建container

创建容器就很讲究了,我们想要的是用docker来跑多个Fuzzing任务,我们不仅要让他跑起来,还得为后面查看其状态,了解任务信息做准备。Afl-fuzz运行起来后,会将状态信息实时更新在out目录下的文件里。

为了了解任务状态,宿主机就需要能够实时访问到这些记录任务状态的文件,我们就需要通过文件共享来,访问宿主机查看这些文件,所以创建命令如下:

docker run -td --privileged -v /var/docker_afl/share/case1:/case --name "fuzz_node1" -h "fuzz_node1" moflow/afl-tools /bin/bash

宿主机的/var/docker_afl/share/目录下创建case1文件,对应容器的/case目录如下截图:

201808241535093063259488.png

上图的case.txt,是一个准备好之后,创建的节点,里面包括了如下:case.txt文件:完整的HTTP包,out是输出目录,seed是输入目录,sender是用afl-clang-fast++编译的persistent模式写的发包程序,tool.py是写的辅助自动程序后面会说到。

4.准备数据

准备Afl-fuzz程序运行需要的数据,先Burp抓一请求包如下:

POST /ajax/login/backend/?b0QHe3bMd9fNm57=$$$K17GUKsYaGNxIHiFehHlOhNfyy_B9944oJJ8DW_2tsQgytxlxiHVKrGP362pXExTBoA0VwdqYDkheIat1EeiQymXPjk6ZNRPTkjyIo2W63tdF$$$ HTTP/1.1
Host: 10.10.66.132
Content-Length: 25
Accept: */*
Origin: http://10.10.66.132
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://10.10.66.132/ajax/login/
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7
Cookie: csrftoken=fVYWMCFUG6gW4ONjm48179CsKAiamipA; send_log_path=%2Ftmp%2Flog%2Fnew%2Faccess.log.1; FSSBBIl2UgzbN7NCSRF=qDWzcpd3KP1mAw5r0gbsg06pu4TSyuYU; b0QHe3bMd9fNm57=K17GUKsYaGNxIHiFehHlOhNfyy_B9944oJJ8DW_2tsQgytxlxiHVKrGP362pXExTBoA0VwdqYDkheIat1EeiQymXPjk6ZNRPTkjyIo2W63tdF
Connection: close
username=1e&password=1212

这个请求包就是我们需要进行Fuzzing的case1,上面里我使用了$$$来标记需要Fuzz的点(和Sqlmap的引导注入相似)。标记后,其中的原始的参数:

K17GUKsYaGNxIHiFehHlOhNfyy_B9944oJJ8DW_2tsQgytxlxiHVKrGP362pXExTBoA0VwdqYDkheIat1EeiQymXPjk6ZNRPTkjyIo2W63tdF

应当作为seed做样本变异使用,Afl-fuzz工具根据其内部的变异算法产生新的值,然后替换这个,进行发包测试。编写一个辅助脚本tool.py帮助完成,提取标记的值,保存seed的工作,脚本实现如下:

import re
import sys
import os

def alter(inf, ouf):
    with open(inf, "r") as f1, open("%s.bak" % inf, "w") as f2:
        for line in f1:
            flg = re.findall('\$\$\$.+\$\$\$',line)
            if len(flg)>0 and len(flg[0])>1:
                flag = flg[0]
                print "[*] Found:\n\t", flag
                print "[*] seed: ", os.getcwd() + os.sep + "seed"
                with open(ouf, "w") as of:
                    of.write(flag.replace("$$$", ""))
                f2.write(line.replace(flg[0],'$'))
            else:
                f2.write(line)
    os.rename("%s.bak" % inf, inf)
print "[*] run checking...."
alter(sys.argv[1], sys.argv[2])
print "[*] run over...."

上面准备好后,编写sender.c,这个程序实现几个操作 1. 加载case.txt内容 2. 从输入流读取数据替换$case.txt标记的位置即:将Afl产生的变异数据结合成新的请求包,然后使用socket发送给Server.

部分代码如下:

while (__AFL_LOOP(1000)) { 
        memset(copy_file, 0, sizeof(copy_file));
               memcpy(copy_file,request.data(),numread);
                per_req.assign( copy_file );
            memset(target, 0, sizeof(target));
        read( STDIN_FILENO, target, 10240 );
        TrimSpace(target);
        per_req.replace(per_req.find("$"),1,target); 

               // printf( "%s\r\n", per_req.data() );
                
        sockfd                = socket( AF_INET, SOCK_STREAM, 0 );
        dest_addr.sin_family        = AF_INET;
        dest_addr.sin_port        = htons( destport );
        dest_addr.sin_addr.s_addr    = inet_addr( "10.10.66.138" );
        memset( &dest_addr.sin_zero, 0, 8 );


        connect( sockfd, (struct sockaddr *) &dest_addr, sizeof(struct sockaddr) );
        send( sockfd, per_req.data(), strlen( per_req.data() ), 0 );
        //recv( sockfd, buffer, 1024, 0 );
        //printf( "%s", buffer );
        close( sockfd );
    }

地址10.10.66.138就是被Fuzz的服务器地址。

5.初始化Afl-fuzz环境

上面的准备工作做好后,我们现在就可以在宿主机上完成容器里的Afl-fuzz程序运行的准备了。

  • 拷贝case,sender到,tool.py容器里
cp /var/docker_afl/cases/request.txt /var/docker_afl/share/node1/case.txt
cp /var/docker_afl/share/sender.c /var/docker_afl/share/node1/sender.c
cp /var/docker_afl/share/tool.py /var/docker_afl/share/node1/tool.py

这里的node1文件夹对应容器node1的/case目录。将必要的文件拷贝进去。

手动启用节点:(首次默认启用)

docker start fuzz_node1
  • 处理case为sender能处理的格式

在docker里执行命令完成创建环境,执行tool.py辅助脚本,完成提取$$$标记的值做为seed输入值. 创建seed目录

docker exec -it fuzz_node2 bash -c 'python /case/tool.py /case/case.txt /case/1'
docker exec -it fuzz_node2 bash -c 'mkdir /case/seed'
docker exec -it fuzz_node2 bash -c 'mv /case/1 /case/seed/1'

6.开始Fuzzing

现在准备好了环境后我们可以进入到容器开始跑Fuzzing了,有两种方式运行,第一种是进入到容器里,另外一种就是通过bash -c执行命令,让其内部运行起来。如:

docker exec -it $1 bash -c 'afl-fuzz -M master -i /case/seed/ -o /case/out/ /case/sender /case/case.txt'

实践中发现Afl-fuzz的需要保持在终端打开下,上面的方式都不是很妥当,这还得借助screen来实现。实践证明是可行的,命令如下:

screen -AmdS node1 bash
screen -S node1 -X screen docker exec -it fuzz_node1 bash -c 'afl-fuzz -M master -i /case/seed/ -o /case/out/ /case/sender /case/case.txt'

这两条命令执行以后,背后的Afl-fuzz就开始在工作了,可以使用screen -r node1切换进去,就可以看到亲切的Afl-fuzz的界面了。

201808241535098560494608.png

7.写一个shell吧

偷个懒,写一个shell吧,取名就叫:create.sh,内容如下:

docker run -td --privileged -v /var/docker_afl/share/$1:/case --name "$1" -h "$1" komi/afl-fuzz-v2.0 /bin/bash

cp /var/docker_afl/cases/request.txt /var/docker_afl/share/$1/case.txt
cp /var/docker_afl/share/sender.c /var/docker_afl/share/$1/sender.c
cp /var/docker_afl/share/tool.py /var/docker_afl/share/$1/tool.py

docker exec -it $1 bash -c 'python /case/tool.py /case/case.txt /case/1'
docker exec -it $1 bash -c 'mkdir /case/seed'
docker exec -it $1 bash -c 'mv /case/1 /case/seed/1'
docker exec -it $1 bash -c 'afl-clang-fast++ /case/sender.c -o /case/sender'

screen -AmdS $1 bash

效果如下:

201808241535098509748627.png

到这里,一个请求包的FUZZ工作就已经开始了,这是利用AFL生成大量的样本,发起网络请求的黑盒的FUZZ。

8.查看状态

如何查看FUZZ任务状态?文件夹/var/docker_afl/share下的node*, 表示一个独立的Fuzz任务。比如下面存在node0、node1、node2、node3、node9任务。

201808241535101012719458.png

AFL的FUZZ任务状态可以通过查看文件而知,

比如:

我们想要查看刚创建的node1任务的进度信息,需要切换到/var/docker_afl/share/node1/out/master路径,打开fuzzer_stats文件如下:

我们关注测试的速度,1834.11次/s,这表示基于标记的

201808241535101044432478.png

其他:

  1. 查看当前任务的seed

    cat /var/docker_afl/share/node1/seed/1

  2. 查看当前任务的请求case

    cat /var/docker_afl/share/node1/case.txt

  3. 查看AFL运行信息

    screen -r node1

201808241535101415242588.png

  1. 查看138的网络请求

命令:sudo tcpdump -s 1024 -l -A -n -i eth0 src 10.10.66.131

可以确认AFL正在工作...

201808241535101448357785.png

后记

暂无

参考

一个Fuzzing服务器端模板注入漏洞的半自动化工具

  1. 背景

乌云还在的时候,猪猪侠爆一个XX银行的OGNL表达式注入漏洞,拿到了第一滴血。然后,唐朝实验室爆了个Spring-Boot的SPEL注入漏洞,虽然不是第一滴血,但是让我有了一个想法。因为看到过曾经黑帽大会有国外研究者写的一个很好的Paper:名字:us-15-Kettle-Server-Side-Template-Injection-RCE-For-The-Modern-Web-App-wp.pdf 里面提到了服务器端模板注入导致的远程命令执行类型漏洞产生。

  1. 萌芽

我对远程命令执行漏洞的理解就是以各种方式直接或间接的导致远程服务器执行成功了你想要让它执行的系统命令的一类漏洞,英文叫:Remote Command Execute Vulnerability(简称RCE漏洞),这是一种很简单暴力的漏洞,一种一言不合就可以rm -rf /或者 format /fs C: 的致命漏洞。哪么都有些什么类型的命令执行漏洞,可以看看exploit-db上关于RCE漏洞的exp有哪些。点击查看

下面是我简单的归了一下类别,RCE漏洞包括但不限于下面提到的。

- 应用程序开发框架里的RCE

这里的框架包括但不仅限于:Struts2框架/xwork框架,ThinkPhp框架,Spring框架 ,IOSurface编程框架类

- 中间件平台/服务应用平台的RCE

这里的代表就举例之前火的JAVA反序列化漏洞影响下的:WebLogic/Jboss/WebSphere/Jenkins、还有比如IIS,nginx,apache因文件名解析,路径解析问题导致的命令执行类,还有Elasticsearch,Redis,Zabbix ,mongodb等各种为业务应用,为数据存储提供服务的软件的命令执行类。

- 应用程序里的RCE

应用程序编写中调用系统API接口,调用系统命令执行函数,程序中系统命令执行相关方法的不恰当使用等导致的一类。

- 第三方应用里的RCE

最喜闻乐见的就是各种CMS被曝SQL注入,命令执行漏洞,代码执行漏洞,这类CMS共同特点就是支持第三方插件,支持用户对原cms程序框架结构进行改造。当然还有之前火了的ImageImagick图形处理库的RCE,和 fffmep导致的RCE等等。

- 等等等

穷尽脑汁就想到了上面这些,有遗漏的典型分类还望大牛多多留言不吝赐教。

然后我好奇的上乌云搜了搜公开的漏洞里(PS: 打开虚拟机搜了搜)关键字:命令执行 的案例。

1-16.png

公开的有2373个案例,119页,我翻了很多页案例,其中以刷Struts2的S2-xxx的最多。命令执行漏洞案例里我看到了下面几类:

- OGNL表达式|程序代码注入导致的RCE

1.Struts2的S2-xxx系列,

2.参数里注入或直接传值OGNL表达式,

3.变量名里或参数里注入编程语言基本语法代码

- 系统命令注入|模板代码注入导致的RCE:

1.变量名里或参数里注入系统命令,

2.变量名里或参数里注入框架模板代码,

- 配置或业务设计不当导致的RCE

1.RMI对外匿名开放或服务未授权导致

2.文件解析执行绕过

3.缓存模板,日志记录,请求信息等被带入奇葩业务执行的

4.业务应用接口,系统接口等权限不当导致的

- 等等。。。

我的重点放在了参数中被带入了系统命令,程序代码,OGNL表达式,模板代码之类导致的RCE漏洞发生的情况。这类情况,有个共同点,大都是通过HTTP/HTTPS请求出现。之前,顺着之前流行的sqlmapapi的思路,我想是否可以同样实现一个, 你上着网就把漏洞给挖出来了呢?萌生了这个想法,于是就有了这么个小脚本。

  1. 实现.

基于sqlmapapi的实现思路,同样用到了代理正常流量,提取Fuzzing点,带入测试payload进行Fuzzing测试。

实现环境:

  • Python 2.7.8 ,Win8.1 x64

第三方模块(版本):

  • requests (2.9.1)、tornado (4.3)

先用Tornado实现代理正常上网,定义SSTIF_Fuzz类用于进行测试,SSTIF_Fuzz类里面定义了下面的函数:

  1. _init_payloads_: 初始化各种测试payload的函数,里面现在已经具备了一些测试payload,包括通用的,PHP基础代码,JAVA语法的,OGNL表达式,EL表达式,SPEL表达式,Groovy测试payload,鸟哥爆的CA
    technologies存在远程命令执行漏洞poc.(暂时就这么多,会不断补充,除非证明此思路此脚本不可行。)
  2. HttpHelper
    :发出带有payload的构造好的请求,根据规则(响应数据包括字符串:10516*61501的结果:646744516,或者在自己配置的cloudeye里面手工确认)判定是否存在RCE漏洞。
  3. Fuzzing_GET
    :分析GET请求中的变量-值(key-value)组合,目前是对每一个value进行测试,未实现对key即变量名进行测试。
  4. Fuzzing_HEADER:未实现,因为在乌云的案例中,发现有在Referer中,注入命令导致的RCE的案例,所以未来会考虑对这里的参数进行测试。
  5. FileHelper:将测试可能存在RCE漏洞的记录在rce_success_result.txt文件里,格式例如:

    +==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==+
    +=+URL: http://202.111.222.333/index.jsp?id=1111&page=222&count=123
    +=+method: GET
    +=+param: id
    +=+payload: java.lang.Runtime.getRuntime().exec('cat</etc/passwd;$BASH')
    +==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==+

记录上面的一条,就可以比较清晰的看出要表达的意思了。

  1. 使用.

1、安装第三方模块

pip install requests
pip install tornado

2、修改SSTIF_Fuzz类中配置文件:

大概在第49行:

self.my_cloudeye = “xxxx.dnslog.info” 这里配置为你的dnslog的域名地址。

3、然后找到一个没有使用的端口,命令:

python ssitf.py 8081 启用代理监听8081端口

4、和设置burpsuite一样,浏览器设置通过8081代理端口上网,然后后面就像使用Sqli半自动化工具那样安心上你的网吧。

注意:

ProxyHandler类中定义了黑名单请求后缀,域名黑名单,这是为了避免带来麻烦的,可以自己添加:大概在246-250行代码处:

url_ext_black = ['ico','flv','css','jpg','png','jpeg','gif','pdf','ss3','txt','rar','zip','avi','mp4','swf','wmi','exe','mpeg']
domain_black = ['gov.cn','gov.com','mil.cn','police.cn','127.0.0.1','localhost','doubleclick','cnzz.com','baidu.com','40017.cn','google-analytics.com','googlesyndication','gstatic.com','bing.com','google.com','sina.com','weibo.com']
  1. 总结.

这个脚本做了什么:

  • 从乌云上,从国外的研究者paper上拔下来了一些payload,作为fuzzing的依据。
  • 实现了代理,从正常上网流量中提取GET和POST请求中的提取有效的参数作为Fuzzing测试点。
  • 实现了个初级版本。

反思不足:

  • payload是固定死的,这是一大弊端。
  • 无法支持HTTPS流量的处理,这是技术盲点。
  • Fuzzing太慢,目前是单线程的。
  • Fuzzing情况考虑不全,应该是思路和认知盲点。
  • 没有考虑狗,软硬防护产品的拦截绕过问题。

最后,看了很多案例,RCE其实就是插入那些东西进去,带入那些东西进去就可以简单初步判断是否存在该漏洞了,我感觉这是一种不错的思路,只是要实现自己的自动化挖掘漏洞神器还是长路漫漫~

Github地址:

SSTIF

欢迎测试,提出意见~

国外的一个自动化服务端模板注入检测和利用工具:https://github.com/epinna/tplmap http://www.mottoin.com/91727.html