2019HW行动防守总结
原创： 瓦都剋
从五月19日到六月底一直在参与HW行动，第一次参与从甲方角度的攻防对抗的团队当中，总体来说感触很大，谨此记录下。
0x00 前言
首先强调下，下文所有的思路均是"因地制宜"，根据客户业务实际情况开展。这次HW是跟某国企合作一块进行安全防御，之前一直是做的乙方的安全服务，第一次切换到防护角。
首先，整个项目分为两个阶段：
1. 护网前
2. 护网中
0x01 护网前
护网前的工作相当重要，国企的安全工作想必各位都有所了解这里就不多说了，如何在这么多的时间内
尽量做到全面安全覆盖实在是太考验防守团队了。
前期的准备工作主要分为两个部分：
1、自检
2、加固
自检是最快发现问题的手段，本次项目我们负责的是云平台安全，云主机总数量达14000多台，任务还是蛮重的。
1.1 自检
主要分为外网渗透测试和内网渗透测试两部分，外网和内网渗透测试还不一样，外网需要结合客户相关业务来，比如政企客户你使用WordPress、Drupal的payload去打，不能说百分之百没有，但是成功的概率相当低，要有针对性去测试，因为时间不允许去这么做。
1.1.1 外网渗透测试
外网不是我们的重点，根据实际情况主要关注那些能直接获取主机权限的漏洞和泄漏大量数据的漏洞即可，比如：
弱口令：数据库、SSH、RDP、后台
命令执行：Solr、Jenkins、Weblogic、Struts2、RMI、JBoss、Tomcat、Spring、ActiveMQ、Zabbix
文件操作：文件上传、文件读取
未授权访问：Redis、Hadoop、Docker、K8S
1.1.2 内网渗透测试
内网渗透和外网渗透区别很大，因为外网不仅有我们，还有其他合作伙伴，各种WAF、防火墙、APT、IDS、IPS、以及办公网的EDR、杀毒什么的各种安全设备一顿操作，所以我们此次的重心就是在内网云平台中，我们的靶标当然也在内网云平台中。
由于内网云平台有很多微服务集，所以根据这个特性，主要分以下几个步骤：
1、资产发现
因为云平台都是在专有云上，所以写个脚本爬了下资产就可以全部获取到了。
这里需要注意下爬的字段，因为后期涉及到漏洞修复、安全事件等问题的对接。
| IP | 项目 | 部门 | 状态 |
2、资产指纹梳理
因为主机数量太大，如果每个资产单独去测试的话，时间代价太大，所以很有必要进行资产指纹梳理，这样如果发现某个漏洞，直接就可以为后面的批量漏洞利用提供条件了。
资产指纹根据业务情况进行有针对性的收集，主要搜集的有：
21、22、23、1090、1099、2049、2181、3000、3306、4848、5000、5900、5901、6379、7000-9999、11211、12181、27017、10050、50000、50080
3、漏洞发现
漏洞发现就是常规的渗透测试了，但是内网的渗透有别与外网，内网主要是快速的，尽可能的发现更多的漏洞，所以不需要进行进一步利用，比如发现了Redis未授权访问，就不要去浪费时间反弹shell、写密钥这些。
这里举了个两个简单的例子
Example1
192.168.2.11:8888/PS：前期资产发现阶段发现8888端口对应的主机有1800多台1、直接访
问提示4032、Fuzz目录发现存在taskFile，192.168.2.11:8888/taskFile3、访问
192.168.2.11:8888/taskFile提示参数不对4、Fuzz参数发现参数tId，
192.168.2.11:8888/taskFile?tId=5、输入值，访问
192.168.2.11:8888/taskFile?tId=1发现提示tId-1不存在6、删除值访问
192.168.2.11:8888/taskFile?tId=发现提示/root/xxx/xxx任务不存在7、Fuzz漏洞，成功
发现本地文件包含192.168.2.11:8888/taskFile?tId=../../../../etc/passwd
Example2
192.168.2.11:8006/PS：前期资产发现阶段发现8006端口对应的主机有180多台1、直接访问192.168.2.11:8006/env，发现存在SpringBoot Actuator信息泄
漏/autoconfig/beans/env/configprop/dump/health/info/mappings/metrics/shutdown/trace/env2、访问192.168.2.11:8006/trace，发现存在访问URL：/application.wadl3、直接访问发现信息泄漏，
可直接看到整站的目录结构/war/4、一层一层访问目录接口发现/war/WEB-
INF/classes目录下存在redis.properties文件，直接访问提示4035、根据前期漏洞信息、收集信息
关联分析，发现在对应文件下加入content即可进行文件读取：/war/WEB-
INF/classes/redis.properties/content这样就可以直接导致web目录下任意文件读取了，批量利用
发发现8006端口全部主机均存在此漏洞6、访问192.168.2.11:8006/war/WEB-
INF/classes/redis.properties/content读取到redis密码，为弱口令：Nb1234567、根据整理的资产指纹信息编写批量利用脚本，发现60多台Redis存在此弱口令
4、批量漏洞利用
这部分就是批量发现涉及的问题主机了，大部分是需要写脚本的，如果有相关工具那最好。
比如，我们在上面的发现的漏洞，利用收集的资产指纹信息直接编写脚本批量跑一下就行了
当然其他漏洞也一样，这里我主要以我们测试的几个典型批量为例：微服务在哪里
SSH、FTP、MySQL、Zoomkeeper、MongoDB、Hadoop、Redis、Struts2、Weblogic、Docker、OpenSSL、Werkzeug、Jboss、ActiveMQ、Zabbix、K8S、Druid等。
├── IP.txt├── Zookeeper│  ├── │  └──
zookeeper_unauth_access.py├── bash├── ftp├── memcache├── mongodb├── mssql├── openssl├── postgresql├── redis├── smb├── ssh├── st2├── weblogic├── druid├── zabbix├── └── all_poc.py
这里是我们之前做基线检查的相关脚本，然后根据需求改了下，也可以用POC-T、Pocsuite等这些框
架，反正能用就行了。
整个内网渗透下来战果还是很大的，拿下了我们护航的两个靶标系统、两个统一运维平台、数据管理平台、热更新管理平台、多个Master、大量SSH等弱口令。
这就为后面安全加固打了个好基础。
1.2 加固

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。