Site icon MkS

[資訊安全] VulnHub – Kioptrix Level 1.3 (#4) Write-up

Photo by Rikki Chan on Unsplash

關於這篇 VulnHub – Kioptrix Level 1.3 (#4) ,是 VulnHub 系列的第三篇文章,越是解題就越是發現自己的不足,不論是基礎還是經驗,對於一些漏洞總是不夠直覺,而現在平均解一題要花費將近半天到一天的時間,雖然這是加上東摸摸西摸摸的時間,但真的了解如何挖掘漏洞、利用漏洞,整體下來的解題時間就不會耗費太久了。

環境設定

靶機下載: https://www.vulnhub.com/entry/kioptrix-level-13-4,25/
將 VulnHub – Kioptrix Level 1.3 載下來後解壓縮後僅有一個「Kioptrix4_vmware.vmdk」檔案,可以參考「Creating a Workstation virtual machine using existing VMDK virtual disks (2010196)」方法進行建置,環境佈署後一樣採用 NAT 的網路環境。

尋找靶機

Local: 192.168.147.133

Target: 192.168.147.129

檢查服務

首先透過瀏覽器查看 80 Port,可以發現是一個登入頁面。

並且發現可以透過簡單的 SQL-Injection,只是頁面上的資訊呈現得很奇怪。

此時頁面上的參數有 username=,嘗試輸入 ../ 出現錯誤訊息。

經過簡單的測試,猜測該頁面的寫法應該是 include($_GET['username'] . "/" . $_GET['username'] . ".php"),可能是資質不足,嘗試了一段時間便轉向其他地方。

取得 SHELL

這時候轉頭回向登入頁面,並且嘗試使用 sqlmap 工具來獲取一些資訊,並且發現兩組帳號密碼。

sqlmap -u "192.168.147.129/checklogin.php" --data "myusername=&mypassword=&Submit=submit" -p "myusername,mypassword" --level 5 --risk 3 --random-agent --dbms=mysql --dump
+----+----------+-----------------------+
| id | username | password              |
+----+----------+-----------------------+
| 1  | john     | MyNameIsJohn          |
| 2  | robert   | ADGAdsafdfwt4gadfga== |
+----+----------+-----------------------+

從一開始掃 Port 的部分有看到,該目標主機的 22 Port 是有開的,所以嘗試使用這兩組帳號進行登入,不過 robert 的密碼好像經過 base64,嘗試解卻解不出來,最後嘗試登入才發現那就是明文的密碼…。

SSH

透過 SSH 連線後,就算是拿到一個 Shell 了,但事情沒有所想的這麼單純,似乎有什麼限制,只要輸入不合規定的指令兩次,就會被迫斷線。

並且一些常用指令也都無法使用,例如:cat、whoami、pwd 等…,最後輸入 help 才發現能用的指令只有 cdclearechoexithelplllpathls 這幾個。

接著參考 「Spawning a TTY Shell」一文,以 echo os.system('/bin/bash') 取得 Shell。

最後也卡了將近一天的時間,發現不論是使用 john 還是 robert 兩個 User,權限都一樣,能做的事情並不多,其中有發現 john.bash_history 裡,有存在 os.system('bin/bash') 的紀錄,很確定這個紀錄是在我之前所產生的,所以把這個點定位成「提示」,代表應該是有其他地方可以進來讀取這個「提示」。

把腦筋動到了 SQLMAP 上,嘗試使用 --os-shell 來跑跑看,發現成功開了個 Shell 出來,並且透過 ls -lha 指令發現,SQLMAP 自動上傳上去的後門竟然是 root 權限。

提權

首先就是依照慣例的移駕到 /tmp 底下試著提權,但可怕的是這次不像「VulnHub – Kioptrix Level 1.2 (#3)」,而是直接把 gcc 給拔掉了,要提權更是困難。

到了這邊其實有很多的猜想,但問題都來自於經驗不足,首先該系統有三個使用者,除了以上從資料庫撈出來的使用者以外,還有 loneferret,而該使用者的家目錄底下有 .bash_history.mysql_history 可以參考。

嘗試了一段時間使用 SQLMAP 的 --file-read=FILE 方法讀取,但沒有結果,權限還是受限於 www-data

--file-read=FILE..  Read a file from the back-end DBMS file system
--file-write=FIL..  Write a local file on the back-end DBMS file system
--file-dest=FILE..  Back-end DBMS absolute filepath to write to

MySQL

接著在 SSH 端,發現目標主機上的 MySQL root 竟然沒有上密碼,說起來是有點後知後覺。

這時候大腦好像想通什麼了,系統的三大權限,讀、寫、執行,來分一下掌握度。

  1. MySQL 寫入是 root 權限
  2. 讀取應該是看當前使用者了
  3. 執行未知

至於要怎麼透過 MySQL CLI 執行系統指令,得到的作法是使用 \! {command},參考自「Executing shell commands from within the MySQL command line client」一文,但 User 還是自己本身…。

直到發現 UDF(User Define Function)一詞,參考自「Command execution with a MySQL UDF」一文,得到使用 sys_eval()sys_exec() 的方法,不過 sys_eval() 似乎無法使用,但還是可以透過 sys_exec() 來達成目的。

由於 sys_exec() 不會有 output,為了確定有沒有成功執行成功,嘗試執行 touch /tmp/test.txt 指令,並看看有沒有生成 test.txt 檔案。

這邊確認了兩件事情,檔案確實有產生,而產生的檔案權限為 root,代表執行指令的身分是 root 沒錯,藉此就可以寫入 sudoers

sys_exec('echo "robert ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers')

接著重新以 robert 這個使用者連上 SSH,接著輸入 sudo su,不用輸入密碼就可以取得 root,這邊補充一下,原先的 IP 為 192.168.147.129,但由於有去變更網路環境,所以 IP 位置變成了 192.168.147.131 。

隨後參考別的大大的解法,也可以透過 useradd 的方式,來產生一個 root user 出來,相關做法可以參考「HowTo: Grant Root Access to User – Root Privileges – Linux」一文。

Exit mobile version