我是如何挖掘Uber的XSS漏洞並繞過CSP的
原文: ofollow,noindex">https://medium.com/@efkan162/how-i-xssed-uber-and-bypassed-csp-9ae52404f4c5
前奏
我曾經在Uber的子域上尋找過開放式重定向漏洞,雖然他們並不把“Open Redirect”當作漏洞,但我想“為什麼不把它與其他漏洞聯合起來?也許可能導致帳戶接管或其他什麼威脅呢?”在這種想法的激勵下,我幹勁十足。在partners.uber.com上尋找相關端點時,下面這個URL引起了我的興趣:
https://partners.uber.com/carrier-discounts/att/redirect?href=http://www.wireless.att.com/
這個URL是在一個論壇中看到的,之後,藉助Google Dork搜尋語法,我又找到了一個類似的URL。那麼,它是否含有開放式重定向漏洞呢?是的!接下來,還有一項工作要做:在登入介面尋找另一個漏洞,以便將兩種組合起來使用。為此,我鼓搗了好幾個小時,不幸的是,官方認為這並沒有報告的必要,按照他們的說法:
“對於開放式重定向漏洞,99%的情況下影響都不大。不過,對於影響較大的那些罕見情況,例如竊取oauth令牌,還是具有提交價值的。”
一週後,我再次檢查了這個URL,發現它已經無法正常工作了,就像現在一樣,無論你輸入什麼http引數,它都會將你重定向到 https://www.wireless.att.com
。
由此來看,他們已經修復好了,問題是,這是他們自己發現的,還是有人報告的呢?我不知道,也不在乎。不過,最初我可是奔著一個大目標去的,最終卻敗興而歸,心裡確實有點不爽。好在哥是個樂天派,沒過多久我的鬥志很快又燃燒起來了,於是決定再次搞點事情,這次要搞的是XSS,而不是自我陶醉!
漏洞分析
如果我問你“在Uber的連結中,最知名的URL是什麼”,你的答案可能是邀請連結。這些連結幾乎無處不在,例如,論壇帖子、Twitter、Facebook、Instagram ......
邀請連結具有不同的URL:
https://www.uber.com/a/join?exp_hvp=1&invite_code=bq6ew1w9ue
我在其中檢測XSS漏洞,但毫無發現:(
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue
這個怎麼樣? 它有相同的邀請程式碼,如果點選它,它將重定向到其他URL,但為什麼不檢查其他引數呢?
在基本的Google Dork搜尋語法的幫助下,我開始對這個子域進行全面的搜尋。
site:partners.uber.com
利用上面的搜素語句,可以找到一個非常龐大的邀請連結列表。我的目標是尋找其他引數,並且真的找到了一個!
https://partners.uber.com/p3/referrals/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1
看起來的確很酷,但XSS在哪裡呢? “v”引數顯示的是他/她作為Uber司機工作了多少年,看起來有點像週年慶典。發現這個引數後,我就試圖注入一些XSS有效載荷,但沒有出現XSS彈窗,於是我查看了一下相關的原始碼。
原始程式碼:
content=”static/images/milestones/anniversary/anniversary_1.png” />
注入有效載荷後:
content=”static/images/milestones/anniversary/anniversary_1 “><img src=x onerror=alert(document.cookie)>.png” />
正如您所看到的,這裡並沒有過濾措施,但同時也沒有彈出XSS視窗,這就是說,我們需要考察相關的內容安全策略。什麼是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”的部落格,博主“stamone”活不錯,讀者不妨讀一讀!
http://stamone-bug-bounty.blogspot.com/2017/10/dom-xss-auth14.html
看看他的文章,他也繞過了CSP,怎麼樣? 在他的報告中,CSP允許他從* .marketo.com提取一些東東。
實際上,他也是藉助了一些基本的Google Dork搜尋語法,並找到了一個回撥引數,正如您看到的那樣,效果的確不錯。
看完這篇文章後,我訪問了Virustotal網站,並檢查了Uber的子域名,其中一個引起了我的注意! 什麼,mkto? “mkto”是marketo的簡稱嗎?
是的!的確如此。
導航至mkto.uber.com的時候,它會將我們重定向到
https://app-ab19.marketo.com/index.php
這絕對就是marketo。所以,接下來我們就可以用它來對抗CSP了。利用一個簡單的有效載荷,我建立瞭如下所示的連結,一旦訪問該連線,就會出現盼望已久的彈窗。
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>
這次,我觸發的是XSS漏洞!
時間線
[03-08-2018]向優步提交漏洞報告
[07-08-2018]將狀態改為“Triaged”
[22-08-2018]傳送並詢問有關流程的其他資訊
[23-08-2018]優步的回覆:“謝謝@mefkan!我們已將該資訊傳遞給內部團隊。”
[27-08-2018]漏洞已修復
[30-08-2018] 獎勵2,000美元
[03-04-2018]有限披露給Hackerone
小結
1 - 千萬不要說“這是一個非常有名的URL,別指望在這裡找到漏洞”。我可以保證,如果這麼想的話,肯定會錯過很多漏洞。
2 - 經常閱讀其他人的文章,特別是正在尋找一些特別的或詳細的資訊的時候。不妨多花些時間用於閱讀和理解文章背後的邏輯。
3 - 永不放棄,努力努力再努力,最終就會如願以償。