背景介绍
08sec 团队在 2019 年起每个月将会举行内部攻防对抗, 并分享技术总结, 为初, 中级技术爱好者提供良好的学习环境, 提升网络信息安全水平, 这是首次活动, 为期 7 天的红蓝对抗, 攻防网络环境相对复杂, 蓝方准备时间仅有 1 天, 完全模拟了真实的攻防环境, 并对采用的开源 cms 程序成功挖掘了漏洞.
一, 准备阶段
初步讨论
Linux+CMS+MySQL+tomcat 关卡设计 (时间原因无法实现)
1. 服务搭建
拉取源码:
Git clone https://github.com/ming-soft/MCMS
因为之前运行该项目缺少库, 所以将项目导入 IDEA:
重新编译添加 pom.xml, 配置 Maven:
同步 Maven 库, 测试:
然后生成 war 包, ms-mcms.war(这边我使用的是我自己服务器的 MySQL 服务器, 编译的时候已经写进配置文件了, 所以后续没有关于 MySQL 的部分).
切换 o0p 低权用户, 下载 tomcat7 的 java web 运行环境, 删除 tomcat 自带的项目录:
将该 war 包部署到服务器上上. 重启 tomcat 服务器:
2. 下载并部署 openrasp
3. 网站效果:
主机加固
1. 系统加固
1) 除 root 外的用户无法登陆 touch /etc/nologin;
2) 密码文件用户权限等:
- chmod 644 /etc/passwd
- chmod 600 /etc/shadow
- chmod 644 /etc/group
3) 创建文件权限 umask=027;
4) 日志等加固:
chattr +a /var/log/messages (只能追加数据) chattr +i /var/log/messages.* (不能被删除) chattr +i /etc/shadow
chattr +i /etc/passwd chattr +i /etc/group 5) 权限加固
chmod -R 700 /etc/rc.d/init.d/*
仅仅 root 可以读, 写, 执行上述所有 script file.
6) 屏蔽登录 banner 信息:
vi /etc/SSH/sshd_config banner NONE
7) 秘钥增强:
authconfig --passalgo=sha512 --update 启用 SHA512 替代 MD5
8) 限制登录次数:
auth required pam_tally2.so deny=3 unlock_time=5 even_deny_root root_unlock_time=120
登录 3 次锁定账号 2 分钟;
9) 设置 Bash 保留历史命令的条数
vi /etc/profile
修改 HISTSIZE=5 和 HISTFILESIZE=20, 即保留最新执行的 20 条命令.
2.Web 服务加固
1) 隐藏 tomcat 版本信息
修改 conf/server.xml, 在 Connector 节点添加 server 字段:
2) 关闭自动部署:
修改 / conf/server.xml 中的 host 字段, 修改 unpackWARs="false" autoDeploy="false";
3) 自定义错误页面:
修改 Web.xml, 自定义 40x,50x 等容错页面, 防止信息泄露.
4) 禁止列目录
修改 Web.xml false;
5) 服务权限控制;
tomcat 以非 root 权限启动, 应用部署目录权限和 tomcat 服务启动用户分离, 比如 tomcat 以 tomcat 用户启动, 而部署应用的目录设置为 nobody 用户 750.
6) 启动 cookie 的 httponly, 修改 / conf/context.xml,usehttponly="true"
3. 数据库加固
1) 禁用 MySQL 历史命令 Rm ~/.mysql_history;
2) 运行 mysql_secure_installation 执行相关安全设置;
3) 使用 validate_password.so 插件, 进行安全加固;
4) 重命名 ROOT 账户;
Update user set user="新用户名"where user="root"
5) 控制最高权限只有管理员
- SELECT user, host FROM MySQL.user WHERE (Select_priv = 'Y') OR (Insert_priv = 'Y') OR (Update_priv = 'Y') OR (Delete_priv = 'Y') OR (Create_priv = 'Y') OR (Drop_priv = 'Y');
- SELECT user, host FROM MySQL.db WHERE db = 'mysql' AND ((Select_priv = 'Y') OR (Insert_priv = 'Y') OR (Update_priv = 'Y')OR (Delete_priv = 'Y') OR (Create_priv = 'Y') OR (Drop_priv = 'Y'));
6) 删除默认 test 数据库, 测试帐号, 空密码, 匿名帐号:
- bash drop database if exists ${
- dbname
- };
- bash drop user ''
- select user,host from MySQL.user
7) 关闭 Old_Passwords:
show variables like '%password%';
8) 确保所有用户都要求使用非空密码登录:
- SELECT User,host FROM MySQL.user WHERE (plugin IN('mysql_native_password', 'mysql_old_password') AND (LENGTH(Password)
- = 0 OR Password IS NULL)) OR (plugin='sha256_password' AND LENGTH(authentication_string) = 0);
9) 禁止 MySQL 对本地文件存取 Less /etc/my.cnf.
4. 自我检测: AWVS,nessus, 测试
1) 多线程扫描服务器均直接 DOWN;
2) 测试后得出如下:
a) 首页搜索 SQL 注入, openrasp 有拦截, 注意拦截日志, openrasp 绕过可能性大;
添加 openrasp 规则:
b) 任意文件上传, 目前 openrasp 有拦截 jsp jspx 拦截, 增加 xml 后缀拦 截, 防止替换配置文件,
增加拦截规则:
c) 后台解压模板功能, zip 文件直接解压获得 shell, 后台防护注意, 模板路径禁止脚本执行权限:
取消执行权限.
二, 对抗阶段
1. 开始阶段: 通过日志观察红方扫描信息收集, 跑 sqlmap:
2. 上传文件突破
查看日志, 发现有个非系统 url, 访问发现是个 SHELL.
初步判断入侵路径: 用户上传头像或者前台其他上传的地方, 调用 file/upload.do, 上传 war 包, 穿透目录到 webapps 下, 自动解压 war 包, 得到 shell:
3. 应对方案
1) 修改文件执行权限;
2) 上文件监控.
4.RASP 规则
修改 302 重定向至福利网站吸引宅男红方注意力.
三, 收尾阶段
通过日志发现红方还是致力于上传漏洞和注入绕过 rasp 均无效.
四, 总结
(一) 前期业务部署由于不熟悉的缘故耽误太久, 导致加固时间不足, 仓促开始;
(二) 网络结构复杂成功拖延了红方进攻步伐和思路;
(三)RASP 意外的好用基本防住了注入否则开源 CMS 的注入点还是很多的;
(四) 上传漏洞其实开始注意到了但是加固组员没能及时修补导致被 get shell, 否则我们一分不失;
(五) 队员们都很给力, 团队合作很重要.
来源: http://www.tuicool.com/articles/2MFrY3f