信息收集
拿到手的目標是一個 ip 加端口的站點，
復制鏈接到瀏覽器打開，可以看到重定向至一個登錄頁，在觀察登錄入口時，發現驗證碼可復用，之后使用 burp 重發幾次請求，得知同一賬號，密碼可無限錯誤，這里由于登錄認證的缺陷，導致可進行賬號密碼爆破，運氣好的話可以進入后臺；但是，爆破動靜太大了，會產生大量日志，容易被察覺，況且爆破后臺需要一定的時間，目前處于收集資產階段，簡單測試幾個弱口令失敗后，轉而去尋找其它的有用信息。
使用 fofa 簡單探測了下端口，發現這個 ip 開放了很多端口，如 3306，27017，6379，22 等等
這里簡單思考了一下，能利用的端口有 MySQL，redis，mongodb，ssh 還有一些 http 服務，這其中 mysql 版本為 8.0.17，在這個版本，漏洞多多少少都修復的差不多了，接下來嘗試 mongodb 未授權漏洞，不出所料，漏洞修復了；再嘗試弱口令連接，也不存在~~，之后經過其它的信息收集手法，暫時對目標業務信息有了一個比較簡單的認知，隨后還是回到 http 服務，嘗試從 web 端入手。
漏洞探測
之前在測試這些站點的時候，發現這個項目的運維特喜歡使用站點名稱加年份的組合口令；根據這個有用信息，結合以前收集到的歷史賬號密碼和目標站點的有用信息來生成一個小組合口令字典，隨后再結合 burp 進行爆破，果然不一會，賬號密碼出來了~~
記錄下賬號密碼，重新登陸時，卻發現后臺出現了這個情況，如下：
這時候的第一反應是，站點是不是部署了 waf，ip 被 ban 了？隨后使用手機網絡打開也同樣如此，后來找業務方了解了下情況，說是不能用 admin 登陸，不然會出現錯誤~~
之后客戶直接給出了個測試賬號，我這邊也懶得爆破了，就湊合著用了~~
一波操作進到后臺，隨便點點點，發現了個上傳的位置，準備好一個馬兒，上傳截包分析，經過幾次實驗后，發現 uploadFormat 上傳參數可控，只需要增加后綴即可上傳 .Jsp
原本以為到此就結束了，沒想到事情并不簡單，復制得到的鏈接進行訪問，發現全都是 404，之后再次在后臺尋找其它上傳點，發現仍舊如此，不單單是上傳的文件會 404，就連站點原本存在的其它文件，復制鏈接打卡也同樣會 404；經過幾次嘗試后，初步判斷這個站點的上傳和文件查看功能出現了問題，既然上傳用不了，那就轉而去尋找其它可利用漏洞，簡單搜尋了一波，卻也只發現了一堆 xss~~
回想了下剛剛收集端口的時候，發現目標還開放了 redis 服務，前段時間搞內網的時候，就遇到了很多 redis 未授權，后臺既然沒有收獲了，那就轉向 redis 等服務入手吧。
這里簡述一下 redis 未授權漏洞：
Redis 默認情況下，會綁定在 0.0.0.0:6379，如果沒有進行采用相關的策略，比如添加防火墻規則避免其他非信任來源 ip 訪問等，這樣將會將 Redis 服務暴露到公網上，如果在沒有設置密碼認證（一般為空）的情況下，會導致任意用戶在可以訪問目標服務器的情況下未授權訪問 Redis 以及讀取 Redis 的數據。
攻擊者在未授權訪問 Redis 的情況下，利用 Redis 自身的提供的 config 命令，可以進行寫文件操作，攻擊者可以成功將自己的 ssh 公鑰寫入目標服務器的 /root/.ssh 文件夾的 authotrized_keys 文件中，進而可以使用對應私鑰直接使用 ssh 服務登錄目標服務器
使用 redis-cli 鏈接時提示 (NOAUTH Authentication required) 即需要輸入密碼鏈接，而非未授權。
之后利用 msf 進行枚舉 redis 密碼，通過短暫的枚舉得到 redis 口令，下一步利用枚舉到的口令進行登錄驗證，可知 redis 服務為弱口令，如下：
漏洞利用
關于 redis 漏洞的利用有很多種，比如主從復制 rce，定時任務寫 shell 等，但我個人還是比較喜歡直接往服務器寫入公鑰去登錄；既然想法有了，那就要行動起來；因為 msf 有現成的漏洞利用模塊，所以就直接用它進行公鑰的寫入啦。
這里簡單介紹下 msf 下幾個 redis 模塊的用處：
auxiliary/scanner/redis/file_upload #此模塊功能為上傳本地的文件到目標服務器。
auxiliary/scanner/redis/redis_login #此模塊功能是對 redis 的密碼進行枚舉，親測速度很快。
auxiliary/scanner/redis/redis_server #此模塊功能是驗證枚舉或者其他手段得到的 redis 密碼是否正確，該功能會執行一個 info 命令并返回執行結果。
接下我們需要利用的模塊為 auxiliary/scanner/redis/file_upload，先在本地生成一個公鑰，需要注意的是，生成的公鑰要改名為：authorized_keys，并且要在文件內容的前面和后面都加上 nnn 換行符才行，否則會導致利用失敗。
一切準備就緒后，設置好 options，run 可以看到公鑰上傳成功；成功上傳后，使用公鑰進行連接，由于服務器采用了 root 權限運行 redis 服務，所以這里連提權都不需要了~~
獲取 root 權限后，發現目標處于內網環境，之后簡單的收集了下內網信息，發現開放的服務還挺多的
正準備進行下一步的內網滲透時，卻被業務方叫停，說是超出了測試范圍，由于授權單上只標明了 web 滲透，并未涉及到內網，到此，本次滲透也就不得已結束了。
注：發布該文章時，所有漏洞均已修復，因為知道各位師傅的厲害，所有打碼嚴重一點~~；文章如有錯誤，請第一時間指出，讓萌新我學習一下，謝謝各位~
小結
此次滲透最核心的問題還是 redis 弱口令，如果口令稍微復雜一點，可能漏洞利用就失敗；其實本次滲透毫無波瀾，甚至還有點無聊，這讓我一度認為這是不是為 HW 而部署的一個蜜罐系統，雖然后來跟業務方確認了這是真實業務系統來著；廢話不多說，花了一個下午的時間去測試，結果也出來了，得回去分析日志了。
制作不易點個贊再走吧
