挖洞經驗 | 看我如何發現影響20多個Uber子域名的XSS漏洞
大家好，今天我要分享的是一個影響20多個Uber子域名的XSS漏洞，該漏洞存在於uberinternal.com身份驗證時向uber.onelogin.com的跳轉過程中，漏洞最終獲得了Uber官方$2500美金獎勵。
先導概念
文章開始前，我們需要先來了解一下安全斷言標記語言SAML（Security Assertion Markup Language）。
SAML是一種基於XML的開源標準資料格式，它在當事方之間交換身份驗證和授權資料，尤其是在身份提供者和服務提供者之間交換。SAML規範定義了三個角色：委託人（通常為一名使用者）、身份提供者（IdP），服務提供者（SP）。在用SAML解決的使用案例中，委託人從服務提供者那裡請求一項服務。服務提供者請求身份提供者並從那裡並獲得一個身份斷言。服務提供者可以基於這一斷言進行訪問控制的判斷——即決定委託人是否有權執行某些服務。
在將身份斷言傳送給服務提供者之前，身份提供者也可能向委託人要求一些資訊——例如使用者名稱和密碼，以驗證委託人的身份。SAML規範了三方之間的斷言，尤其是斷言身份訊息是由身份提供者傳遞給服務提供者。在SAML中，一個身份提供者可能提供SAML斷言給許多服務提供者。同樣的，一個服務提供者可以依賴並信任許多獨立的身份提供者的斷言。更多資訊參考 ofollow,noindex" target="_blank">SAML說明 。
資訊收集
在資訊收集階段，我發現Uber的內部系統網站uberinternal.com也在測試範圍之內，於是，我就開始對它執行子域名列舉，該過程，我用到了子域名列舉神器aquatone，它發現了一堆子域名網站並作了截圖。
值得注意的是，uberinternal.com的大多數子域名網站在身份驗證階段，都會跳轉到uber.onelogin.com，而onelogin就是使用SAML驗證的一個Uber服務。有意思的是，在SAML的應用中，存在很多驗證被繞過的例項，這其中就包括了影響Uber自身服務的一些漏洞，如 例項1 和 例項2 。
首先，我計劃來找找是否存在SAML身份驗證繞過的情況，一開始我選的目標是Uchat系統，但是有人已經早我一步發現了這個漏洞，接下來，我只有改變目標了。
在登入uberinternal.com相關服務的過程中，會涉及到SAML驗證，首先，SAML機制會向uber.onelogin.com後端驗證服務傳送一個請求，成功登入uberinternal.com服務後，uber.onelogin.com會返回一個有效響應。在此互動中，我感興趣的是用來接收uber.onelogin.com響應的頁面。
由此，可以來看看uberinternal.com在身份驗證時發生頁面跳轉的情況，在下圖中，可以看到，它向uber.onelogin.com傳遞了一個base64編碼的SAMLRequest引數：
為了解碼這個base64請求引數，我們可以用 samltool 這個線上工具中的SAML Decoder功能，解碼後，可以看到，其中包含了一個用來接收uber.onelogin.com響應的連結，也可稱之為 SAML consume URL：
https://carbon-prototype.uberinternal.com:443/oidauth/saml_consume
如果你還想深入測試一下這種跳轉過程中發生的SAML互動，BurpSuite中就有一個專門用來測試SAML的外掛，非常適合用來測試SAML。不過，最終我還是自己寫了一個小工具 SAMLExtractor ，可以用它來解碼提取出跳轉發生時，用來接收響應的那個SAML consume URL。
接下來，我們要來嘗試的就是繞過上述SAML consume URL連結的SAML身份驗證了，因為我不是太瞭解這種機制，所以我決定用以下 dirsearch 命令，來看看其oidauth目錄下是否還有其它存在的子目錄或檔案：
./dirsearch.py -u https://carbon-prototype.uberinternal.com:443/oidauth/ -ejson
漏洞發現
在經過一番暴力列舉之後，我發現oidauth目錄下存在的以下這個頁面：
https://carbon-prototype.uberinternal.com:443/oidauth/logout
這是一個登入退出頁面，為什麼我覺得它有意思呢，因為很多web開發者會把這種退出頁面用來實現重定向跳轉，而且，有時候這種頁面中可能會存在XSS漏洞。為此，當我在瀏覽器中開啟上述頁面連結之後，其又跳轉到了以下這個頁面：
URL解碼之後的連結如下：
注意其中的base引數，它是用於獲取另一個URL“carbon-prototype.uberinternal.com:443”的，但是，當我把它置換為經典的 javascript:alert(123) 之後，XSS出現了！不僅如此，這個頁面還存在點選劫持漏洞（Clickjacking），在利用場景中，可以把XSS和Clickjacking一起配合，可更為方便地實現攻擊。
延伸發現
利用之前我編寫的小工具SAMLExtractor中批量發現SAML consume URL的功能，我把所有uberinternal.com的子域名網站都測試了一遍，看看是否還有其它子域名網站具備這種相同的呼叫機制。在我的改裝指令碼中，我會在驗證方式中去呼叫存在XSS漏洞的頁面 oidauth/prompt ，然後嘗試javascript:alert(123) 的XSS漏洞，如果存在XSS，那麼就會完美地跳出javascript:alert(123)內容了！
import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
from colorama import init ,Fore, Back, Style
init()
with open("/home/fady/uberSAMLOIDAUTH") as urlList:
for url in urlList:
url2 = url.strip().split("oidauth")[0] + "oidauth/prompt?base=javascript%3Aalert(123)%3B%2F%2FFady&return_to=%2F%3Fopenid_c%3D1520758585.42StPDwQ%3D%3D&splash_disabled=1"
request = requests.get(url2, allow_redirects=True,verify=False)
doesit = Fore.RED + "no"
if ("Fady" in request.content):
doesit = Fore.GREEN + "yes"
print(Fore.WHITE + url2)
print(Fore.WHITE + "Len : " + str(len(request.content)) + "Vulnerable : " + doesit)
最終，我先發現了 https://eng.uberinternal.com 這個網站存在上述XSS漏洞 作了上報 ，之後，我又用這種方式發現了uberinternal.com下 20多個子域名網站存在上述XSS漏洞 ，兩次漏洞報告先後分別獲得了Uber官方獎勵的$500和$2000美金。
更多資訊，請參考原漏洞報告- report 1 / report 2
*參考來源：fady，clouds編譯，轉載請註明來自FreeBuf.COM