1 摘要
2015年11月10日中午12點左右，我們發(fā)現(xiàn)了某不知名團體利用redis設(shè)計缺陷，針對國內(nèi)互聯(lián)網(wǎng)進行了全網(wǎng)性的入侵事件。這次大規(guī)模的攻擊事件主要針對Linux服務器，如果redis服務器使用root權(quán)限啟動，并且沒有配置認證，就可能能夠?qū)е聄edis數(shù)據(jù)丟失，服務器被添加賬號用于ssh遠程登錄。
經(jīng)過白帽匯安全團隊的進一步分析，此次攻擊事件已經(jīng)導致至少10000家暴露redis服務器被成功入侵，我們會在后續(xù)持續(xù)更新進一步動態(tài)。
2 入侵事件
2015年11月10日中午12點左右，我們在公網(wǎng)部署的多臺安全探針服務器陸續(xù)觸發(fā)了異常告警，有多臺redis數(shù)據(jù)被突然清空。通過分析發(fā)現(xiàn)：
執(zhí)行了flushall清空數(shù)據(jù)的操作
在redis數(shù)據(jù)中新建了一個名為crackit的key鍵值，內(nèi)容為ssh-rsa AAAAB3Nza<此處省略若干字母>mo6BLZV4/ crack@redis.io， 如下圖
在/root/.ssh文件夾下新建了一個authorized_keys文件，內(nèi)容很明顯是redis生成的db二進制文件，里面清晰的看到crackit對應內(nèi)容，也就是入侵者嘗試通過配置一個ssh的key來進行登錄。內(nèi)容如下圖：
3 事件回溯
到目前為止，我們還無法明確的對此次入侵過程定義為漏洞入侵，因為redis官方網(wǎng)站并未對此提供補丁，至少目前為止看到利用的過程都是基于redis提供的正常功能。而且這個問題在2014年9月就被作為遠程代碼執(zhí)行RCE的技術(shù)問題作了公開發(fā)布，并得到了小范圍的傳播。
經(jīng)過crackit的關(guān)鍵字查詢，在2015年11月4日，安全研究人員Antirez(他本人就是Redis的作者)的blog()公布了一個redis提權(quán)的技巧，事實上今年上半年利用redis寫文件的方法被大量應用，通常都是寫入webshell作為網(wǎng)站后門程序。而這次作者屬于老技術(shù)新的利用思路，文件位置的變化讓利用場景一下被放大。大致意思是利用redis在用戶目錄寫入一個ssh私鑰文件，從而建立一個信任關(guān)系，這樣不需要輸入ssh密碼就可以登入。
在技術(shù)文檔被公布以后，開始有一批地下產(chǎn)業(yè)進行了分析驗證和實際利用的，在11月7日左右網(wǎng)上已經(jīng)能找到一些網(wǎng)站站長發(fā)現(xiàn)通過redis被入侵的案例，但是當時還是小范圍的利用。直到今天，這個漏洞被用于實際的大規(guī)模掃描和入侵，這次的掃描非常粗暴，破壞性大，范圍廣，會直接刪除服務器上的數(shù)據(jù)，并且添加免密碼登錄的賬號。
4 技術(shù)還原
為了更好的理解防護方法，我們對其進行了完整的技術(shù)還原。
環(huán)境要求：以root啟動的redis，可以遠程登入到redis console
首先在你的連接機器上輸入：
來生成一個公鑰。
生成到txt (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
然后：redis-cli -h xxxx flushall 清空redis(非常暴力，請務必在測試環(huán)境執(zhí)行)
執(zhí)行：cat foo.txt | redis-cli -h xxxx -x set pwn
然后登錄redis，執(zhí)行如下命令：
上面命令是調(diào)用config set命令對redis的備份文件路徑進行修改，然后執(zhí)行save進行生成備份文件(這里是生成了authorized_keys文件)。這樣就可以使用本地的私鑰去登入被植入公鑰的ssh服務器了。
5 影響危害
易攻擊對象：
Redis服務器
Linux環(huán)境
對公網(wǎng)開放
未啟用認證
以root方式啟動(非必需)
現(xiàn)象：
redis都被執(zhí)行過flushall命令進行清空
redis內(nèi)新建crackit的key
redis的dir參數(shù)被指向了/root/.ssh文件夾
/root/.ssh目錄下會生成一個authorized_keys文件(或者覆蓋現(xiàn)有的)
6 修補加固建議
臨時修復建議，通過配置rename-command CONFIG ""，禁用一些命令。(某些必須以高權(quán)限運行的，可以借鑒該方案)
修改redis.conf文件
增加
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command EVAL ""
以低權(quán)限啟動redis
切換到其他用戶su xxx，然后再啟動server(切換是否注意之前文件權(quán)限，也需要相應修改)。
給redis增加驗證。
修改redis.conf文件
禁止對公網(wǎng)開放。
修改redis.conf文件
檢查用戶.ssh目錄下是否已經(jīng)存在非法的authorized_keys文件
鑒于redis并不提供其他賬號啟動服務的腳本，導致現(xiàn)網(wǎng)大量redis服務器是通過root的權(quán)限來啟動init.d下的服務腳本。但是官方明確寫到為了安全，切記勿使用root身份啟動。
除了基本的基線加固措施和漏洞修補外，我們認為最后一道防線依然是傳統(tǒng)的備份方案，定期備份重要的業(yè)務數(shù)據(jù)。建議部署一些必要的備份災備方案，行業(yè)內(nèi)有一些可用的產(chǎn)品可用于處理此類問題，比如可以利用類似于多備份工具來對redis數(shù)據(jù)庫進行快速的備份和恢復。
7 常見問題FAQ
什么叫redis crackit?
此次針對redis進行大規(guī)模掃描和入侵的事件，會在redis服務器上生成存在一個crackit的key，所以我們以redis crackit來命名此次事件
這次事件有什么危害?
成功的入侵能夠?qū)е聄edis數(shù)據(jù)丟失，服務器被完全控制。
影響范圍有多大?
中國互聯(lián)網(wǎng)有至少超過10000臺服務器被入侵，占比達到開放redis服務器的67%，也就是說每100臺對公網(wǎng)開放的服務器就有67臺被掃描入侵過。
到哪下載補丁?
很遺憾，沒有補丁，官網(wǎng)認為不是漏洞而是正常功能，所以在官網(wǎng)改變主意之前，請參考我們提供的修復建議。
我應該怎么做?
參考修復建議，簡單介紹：進行防火墻配置禁止非業(yè)務網(wǎng)絡訪問;修改配置文件bind的IP;降低運行權(quán)限;臨時禁用一些危險命令;定期備份數(shù)據(jù)。
如果發(fā)現(xiàn)了入侵痕跡，還要將已經(jīng)入侵成功的后門進行清除。
進行如上操作是否就一定安全?
Redis功能過于強大，有很多特性可能導致新的問題，比如有安全研究人員發(fā)現(xiàn)可以反彈shell的方式來獲取控制權(quán)，也就是說：即時6379端口沒有對外網(wǎng)開放，但是利用SSRF等漏洞就能夠觸發(fā)，或者在低權(quán)限的webshell來用于權(quán)限提升。
由于攻擊方法的多樣性， 還請大家對redis進行長期的監(jiān)控，時刻關(guān)注這方面的安全資訊，同時我們也會不斷補充新的知識
8 補充材料
截至目前為止，通過我們進一輪的抽樣調(diào)查，我們提取了15萬臺對公網(wǎng)開放的redis服務器跟進分析，發(fā)現(xiàn)其中有15238臺未進行驗證配置，也就是說有超過10%的服務器不需要密碼就能夠連接;其中又有10312臺服務器有入侵痕跡，總比例超過67%的開放服務器被入侵。
9 參考
A few things about Redis security
Trying to hack Redis via HTTP requests
Redis Security
10 關(guān)于我們
北京白帽匯科技有限公司是一家專注于安全大數(shù)據(jù)、企業(yè)威脅情報，為企業(yè)提供尖端安全產(chǎn)品和服務的一家高科技互聯(lián)網(wǎng)企業(yè)。
NOSEC大數(shù)據(jù)安全協(xié)作平臺(NOSEC.ORG)是其旗下的一款線上安全產(chǎn)品，也是全球第一款站在黑客思維角度研發(fā)的安全大數(shù)據(jù)信息共享平臺。定位為信息安全從業(yè)者的“瑞士軍刀”，為用戶提供安全大數(shù)據(jù)信息及高級安全工具等。使用對象主要為白帽子、信息安全從業(yè)者、及企業(yè)用戶。
如有任何意見和建議，歡迎通過如下方式與我們聯(lián)系：
聯(lián)系郵箱：support@nosec.org
客服電話：400-650-2031
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
