Day 04｜看到 Port 不要急著打：從服務枚舉開始建立攻擊面－下篇

昨天我們已經從 2222 Port 的回應中辨識出 SSH 服務，接下來繼續看我們還有哪幾個 port 上面的服務要驗證。

剩下的服務我們先送一個 HTTP GET 封包來看看有沒有 HTTP 的服務

for p in 80 3306 8080 8443; do
  echo "--- $p ---"
  printf 'GET / HTTP/1.0\r\n\r\n' | timeout 3 nc 172.16.12.182 $p 2>/dev/null | head -2
done

下面是我們的執行結果：

從這張圖來看我們得知了 80 跟 8443 的服務上面都是跑 Nginx，版本看不到可能是因為 nginx 設定了 server_tokens off

我們看到 8080 雖然沒有顯示 http response 但是卻出現一個錯誤訊息：-ERR wrong number of arguments for 'get' command

將錯誤訊息放到 google search 尋找發現 redis 的錯誤訊息跟我們在 lab 上面看到的格式雷同，我們可以先猜測它是 redis 的服務

所以我們先用下面這個指令去測試是不是 redis，在 Redis 6.0 以上的版本有提供 hello 的指令，可以協助驗證是不是 Redis 的服務。

printf 'HELLO 2\r\n' | timeout 3 nc 172.16.12.182 8080

剩下一個 3306 都不回應我們的測試方式，這樣慢慢找根本大海撈針，所幸 nmap 有 -sV 這個參數可以幫我們判斷這個 port 上面到底跑什麼服務？

nmap -Pn -sV -p 3306 172.16.12.182

從結果來看，3306 上面跑的其實是 PostgreSQL。它屬於 Client-first 的服務，會安靜地等客戶端先送出符合格式的封包，所以我們用 HTTP GET 去戳它才會完全沒有回應，這也給我們一個新的觀點——沉默不代表沒服務，只是我們還沒用它聽得懂的協定開口。

有趣的是，昨天 nmap 沒加 -sV 時把 3306 標成 mysql，實際上卻是 PostgreSQL。這也說明，如果掃完只憑 port 號就直接暴力開打，很可能整個方向都打錯，白白浪費大量時間。

這邊說明一下為什麼 nmap 加不加 -sV 會差這麼多？首先可以先用以下指令來看一下這個檔案：

less /usr/share/nmap/nmap-services

這邊記錄了大部分服務的預設 port ，在沒有使用 -sV時，nmap 會依照檔案裡面的表格初步判斷上面的服務是什麼？速度會比 -sV 還要快。那 -sV 這個參數會幹嘛？我們可以看一下官方的解釋

The Nmap version scanning subsystem obtains all of this data by connecting to open ports and interrogating them for further information using probes that the specific services understand. This allows Nmap to give a detailed assessment of what is really running, rather than just what port numbers are open. Example 7.1 shows the actual output.
網址說明：https://nmap.org/book/vscan.html

Nmap 的版本掃描機制會連線至已開放的 Port，並透過目標服務能理解的 Probe 進行進一步探測，藉由分析服務的回應，Nmap 可以判斷實際運行的服務內容，這就是 nmap 至今仍是許多滲透測試人員愛用工具的原因之一。

總結

從這兩天的實驗都可以看到其實 port 的號碼真的沒有一定要跟某個服務綁在一起，如果盲目用背的方式去開始攻擊會很浪費時間，一個好的滲透測試人員第一步必須要把服務確認好後才會開始進行下一步的計畫。