我是如何繞過Uber的CSP防禦成功XSS的?
大家好!在開始正式的內容之前,請允許我做個簡單的自我介紹。首先,我要說明的是我不是什麼安全研究人員/安全工程師,確切的來說我是一名安全的愛好者,這始於兩年前的Uber。我喜歡接觸新的事物,並且每天都在努力提高自己。我也很樂意與分享我學到的東西(每週都會更新哦),因為我確信“分享即是關懷”。雖然,現在在賞金計劃中我已不是新人了,但在安全面前我永遠是新手。好了,話不多說讓我們步入正題吧!
背景
這次,我打算在Uber的子域上挖掘一些“開放重定向”漏洞。雖然,我知道Uber並不將“開放重定向(Open Redirect)”視為漏洞。但我想,如果將它與其它漏洞聯絡起來,也許能導致帳戶接管或其它什麼更嚴重的安全問題呢?我立刻將想法付諸於了行動。當我在partners.uber.com上尋找端點時,以下URL引起了我的注意:
https://partners.uber.com/carrier-discounts/att/redirect?href=http://www.wireless.att.com/
這個URL是我在一個論壇中看到的,之後我使用Google dorks也找到了一個類似的URL。那麼,它是否受開放重定向漏洞的影響呢?答案是肯定的!接下來我要做的就是,在登入部分找到一個漏洞來組合利用它們。但很不幸,我找了很長的一段時間都沒有任何的發現。對於開放重定向的問題Uber方面迴應如下:
“99%的開放重定向具有低安全性影響, 對於影響較大的罕見情況,例如竊取oauth令牌,我們仍希望能再見到它們。”
一週後當我再次檢查了這個URL時我發現,它已無法正常工作。就像現在一樣,無論你輸入什麼http引數,它都會將你重定向到 ofollow,noindex" target="_blank">https://www.wireless.att.com
so,他們修好了吧。是他們自己發現的還是有人報告的?我不知道,也不想知道。這讓我感到非常的沮喪,但我很快從沮喪當中走了出來。既然這個點被堵死了,那讓我們來找找XSS。
如果我問你“Uber的哪個URL你最眼熟”,你的答案可能是邀請連結。你可以在任何地方看到這些連結,例如論壇帖子,Twitter,Facebook,Instagram等。
以下是一個邀請連結:
https://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue
我嘗試檢查了XSS,但並沒有成功:(
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue
上面這個連結具有相同的邀請碼,如果你點選它它將重定向到其他URL,但這裡它為什麼不檢查其他引數呢?我決定再次使用dorks進行搜尋。
site:partners.uber.com
通過dorks搜尋我找到了一個數量龐大的邀請連結列表。我要做的就是找到另一個引數,很幸運我找到了一個!
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1
看起來很酷,但XSS在哪裡呢?“v”引數顯示的是他/她作為優步司機工作的年限。我嘗試在這個引數注入一些XSS payload,但並沒有XSS彈窗,接著我檢查了原始碼。
原始程式碼:
content=”static/images/milestones/anniversary/anniversary_1.png” />
注入payload後:
content=”static/images/milestones/anniversary/anniversary_1 “><img src=x onerror=alert(document.cookie)>.png” />
正如你所看到的,我們的payload並未被過濾,但同時也沒有發生XSS彈窗。根據我以往的經驗,這種情況是因為啟用了內容安全策略(CSP)。什麼是CSP? 正如Netsparker部落格當中所描述的那樣:
內容安全策略(CSP)標準,是一種有選擇地指定應在Web應用程式中載入哪些內容的方法。這可以通過使用隨機數或雜湊將特定來源列入白名單來完成“。
因此,只要找到處在白名單之中的域,我們就可以繞過CSP。我們來檢查下Uber的partner.uber.com的CSP標頭。這裡的內容有點長,因此我只向大家展示了“script-src”之後的部分:
script-src ‘self’ ‘unsafe-inline’ ‘nonce-9f4b94bf-a195–4d8c-b474–879ae6d1d471’ ‘self’ ‘unsafe-inline’ https://pullo.uberinternal.com https://apis.google.com https://www.google.com https://d1a3f4spazzrp4.cloudfront.net https://*.uber.com https://rules.quantcount.com https://www.google-analytics.com https://ssl.google-analytics.com https://d3i4yxtzktqr9n.cloudfront.net https://d1a3f4spazzrp4.cloudfront.net;
首先,我檢查了rules.quantcount.com並找到了json端點,但沒有太多關於它的資訊。但他們將* uber.com的域名均列為了白名單,因此只要我們能夠找到任何帶有回撥或類似內容的JSON端點,那麼我們就能夠執行XSS。這裡我推薦大家一個名為“DOM XSS — auth.uber.com”的部落格,大家有空可以去翻翻他的文章:
http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html
在他的這篇文章中他成功繞過了CSP,並且CSP允許他從* .marketo.com獲得一些他想要的東西。
在這當中他藉助dorks找到了一個回撥引數,並且你可以看到效果不錯!
看完這篇文章後,我訪問了Virustotal並檢查了Uber的子域。其中一個以mkto開頭的子域引起了我的注意。“mkto”會是marketo的簡稱嗎?
是的,果然沒錯!
當我訪問mkto.uber.com,它將我重定向到了“ https://app-ab19.marketo.com/index.php ”,這也驗證了我的猜測。現在我們嘗試用它來繞過CSP。我使用payload建立了以下連結:
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1"><script src=”https://mkto.uber.com/index.php/form/getKnownLead?callback=alert(document.domain);"></script>
可以看到,成功繞過CSP並觸發了XSS彈窗!
時間線
2018.8.3 向優步提交漏洞報告 2018.8.7 將狀態改為“Triaged” 2018.8.22 傳送並詢問有關流程的其他資訊 2018.8.23 優步回覆:“謝謝@mefkan!我們已將該資訊傳遞給內部團隊。” 2018.8.27 漏洞已修復 2018.8.30 獎勵$2,000 2018.4.3 在Hackerone有限披露
經驗總結
1.不要覺得一個URL非常常用就不可能存在漏洞,我敢肯定你因此已經錯過了很多bug。
2.多翻看其他一些技術牛人的文章,在其中你可能會得到你想要的答案或新的靈感。
3.不要因為一次的失敗就放棄,可能答案就在你的下一步。
*參考來源: medium ,FB小編secist編譯,轉載請註明來自FreeBuf.COM