【由淺入深_打牢基礎】HOST頭攻擊
前幾天一直準備別的事情，然后用了2/3天時間去挖了補天某廠的SRC，還是太菜了，最后提交了一個低危（還沒出結果，還有點敏感資訊泄露，感覺略雞肋也沒交），不過偶然發現之前提的一個公益SRC被收了（當時快半個月都沒人處理）不過沒money，等過幾天有時間再看吧，還是得虛心學技術，慢慢的進步，
1. HOST頭的作用
微信公眾號：小惜滲透，歡迎大佬一起交流進步
1.1 文字原理講解
首先我們需要了解一個概念叫虛擬主機，也就是一臺服務器上存在多個網站，你會想這還不簡單，每個站點分一個埠即可，但是我說的是一個埠，
既然如此，那么我們不管它是怎么實作的，我們要關注的是為什么如此，為什么我們訪問這些網站均是正常的呢？這就是HOST頭的作用了，當我們去訪問一個url的時候，這個域名只會被DNS決議為IP，但是因為這些虛擬主機的IP是同一個，所以會看我們的HOST頭，它的值是誰，那么服務器就去交給那個站去回應，（如下圖）
image-20220608134349633
1.2 實際演示
我這里用小皮面板再來演示一下它的奇妙之處，首先我先創建兩個站點，分別是pikachu和dvwa，配置如下圖，
image-20220608135012232 
image-20220608135031215
可以看到，這時候我給它們不同的域名，而且埠均為本機的80，好，接下來我去訪問，
image-20220608135147488 
image-20220608135153094
兩個站點沒有任何問題，緊接著我重新訪問dvwa并抓包
image-20220608144116741
再來看一下頁面
image-20220608144151455
OK相信到這里就了解了，HOST頭的作用了，接下來，圍繞著Burp Suite官方實驗室，演示下會發生的安全問題
2. 漏洞利用
2.1 基本密碼重置中毒
要求如下：
image-20220608145041353
我們需要登錄到Carlos才可以完成，登錄時點擊忘記密碼
image-20220608145206659
可以看到是根據我們的賬戶名或郵箱地址，發一封重置密碼的郵件給我們
image-20220608145241705
我們先用自己的賬戶，也就是wiener來試試，ok，點擊后去漏洞利用服務器試試
image-20220608145617649
往下翻有個Email client，點進去查看剛剛的郵件內容
image-20220608145609138
看到有個修改密碼連接，ok，我們打開它，并隨便修改成123
image-20220619163246817 
image-20220608145900506
接下來我們去Burp看下剛剛的資料包，如下，可以看到里面存在一個temp-forgot-password-token值，所以我們現在需要搞到它，
POST /forgot-password?temp-forgot-password-token=F7vqHnRQVDFVZwEfG8CjqPOx4gwgMGr2 HTTP/1.1
Host: ac3d1fxxxxxx060.web-security-academy.net
Cookie: _lab=46%7cMasdCwCFAiRGPkiVdxxxNhS8mYDOMvkk3CWJakAhR0wUzpasdGqNbbKzMESDTwqnN4%2bmfnDv415Yp1OeYCQWOHaYTqDhOeWLYsbDczuZvkT8kfY2yqQxeqN9CdAsyGMC7FUxTGUuUMjnXEJlyJaZ1ArCyi5xbmznovOWg2psOzMjkzQnGNekasdzgthyY%3d; session=jcqZVUOp3gtGaRpFeBD7r577ERV38AkV7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 135
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close
csrf=KmpFXtDQMQuzxEkE0t8LRYxfT698ibN1&temp-forgot-password-token=F7vqHnRQVDFVZwEfG8CjqPOx4gwgMGr2&new-password-1=123&new-password-2=123
接下來我的猜想就來了，既然我們知道漏洞肯定跟HOST頭注入有關，那么我猜我們剛剛點擊忘記密碼，發包的時候肯定是抓不到這個token的，而是網站后端服務器發送到我們的郵箱，但是這個時候如果我們將HOST頭改成我們自己利用服務器，那么流量會不會就會到我們這里，然后根據這個token值構造重置密碼鏈接，ok，說干就干，
image-20220619163138663
緊接著去我們漏洞利用服務器查一下token
image-20220608151427869
構造重置密碼鏈接，直接將我們重置密碼的包里面的csrf （值在上上個圖中）和temp-forgot-password-token值改成對應的，然后成功了
image-202206081525315002.2 主機標頭身份驗證繞過
要求如下：
image-20220608161747546
既然要進入管理面板，那么首先我們應該找到路徑，隨手加一個admin，演示僅對本地用戶可用
image-20220619163056154
一般我們搭建靶場用的最多的就是localhost，同理這里將HOST頭改為localhost
image-20220608162732093
直接洗掉，同樣還得抓包改HOST
image-202206081629121472.3 通過模糊請求導致 Web 快取中毒
要求如下：
image-20220619163031177
利用程序：
這個我盲猜可能就就是web快取投毒并且非快取建是HOST，相信看到我之前那篇文章的兄弟一下就懂了，就是web快取投毒，投到HOST鍵上
首先重繪一下觀察歷史包，發現加載了兩個js
image-20220619163858150
存在快取機制
image-20220619163938866
那我現在漏洞利用服務器構造一下js檔案
image-20220619164331866
ok，改一下HOST，投毒吧
image-20220619165421749
改了發現不可以，那么也就不能在原來基礎上修改，那就嘗試在原來基礎上增加，雙寫HOST
image-20220619165540252
可以看到加載我們利用服務器的js了，這個時候正常如何訪問就會中毒了
image-202206191738203862.4 基于路由的 SSRF
要求如下：
image-20220619173951042
利用程序：
首先這里提示了，必須使用Burp Collaborator來進行測驗，如果不知道它是什么，可以百度，我暫時沒找到好文章，后續打算就其使用寫個帖子，這里先簡單理解成dnslog就好了，資料由Burp->靶機，靶機回應到Burp Collaborator再到Burp，也就是說它的內網靶機不會出網，除非是Burp自帶Burp Collaborator地址，所以我們需要配置一下
點擊Burp->Burp Collaborator client出現下圖界面，點擊Copy to clipboard來獲取一個隨機地址
image-20220619215636812
然后可以在Project options里面查看一下，我們這里使用默認的Collaborator的server就好
image-20220619221018445
嘗試SSRF漏洞，將訪問實驗室主頁的包的HOST頭改成我們的Collaborator server地址，然后發包，然后就可以看到Collaborator server存在流量，然后就可以關掉Collaborator了
image-20220619221233374
證明存在SSRF漏洞，可通過HOST值訪問內部敏感系統，但是不知道IP，所以直接爆破，如下圖設定
image-20220619174730976
別忘了關掉自動更新Header功能
image-20220619221528007
Payload設定如下
image-20220619174835235
這里因為沒特殊字符，所以paylaod Encoding勾不勾沒關系，直接爆破，130被爆破成功
image-20220619221621267
然后我們訪問主頁并抓包將HOST改成192.168.0.130然后放出去，同樣的洗掉用戶的這個POST包也需要將HOST改為192.168.0.130
image-20220619221949746
成功了
image-202206192220228112.5 SSRF 通過有缺陷的請求決議
要求：
image-20220619222536993
利用程序：
這題拿到手很懵圈，感覺跟上一個一樣，于是按照上一個的做法將HOST先改成Collaborator Server的地址，發現回傳403，并且Collaborator Server無決議
image-20220619222925187
既然如此，再看一下要求，基于路由的這幾個大字出現在眼前的時候，就應該意識到是路由地址的問題，于是嘗試將GET / 改成絕對的
image-20220619223244507
非常nice，然后就跟上邊一樣了，爆破，251
image-20220619223436312
洗掉用戶，像下邊這樣改包（請求admin目錄的和洗掉用戶的都類似）
image-20220619224113256
成功
image-20220619224124325
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/494483.html
標籤：其他
上一篇：SQL注入漏洞篇