EA Games Vulnerability

 

In the last few weeks, Check Point Research has combined forces with CyberInt to identify a chain of vulnerabilities that, once exploited, could have led to the takeover of millions of player accounts within the world’s second largest gaming company, EA Games. The potential damage could have involved an attacker gaining access to a user’s credit card information and the ability to fraudulently purchase in game currency on behalf of the user.

CyberInt and Check Point immediately notified EA Games of these security gaps and together leveraged their expertise to support EA in fixing them to protect their gaming customers.

 

Origin: The EA Games Platform

With over 300 million users and revenues of around $5 billion, EA Games is the world’s second largest gaming company market capitalization and boasts household gaming titles such as FIFA, Maden NFL, NBA Live, UFC, The Sims, Battlefield, Command and Conquer and Medal of Honor in its portfolio. All these games and more rest on its self-developed Origin gaming platform that allows users to purchase and play EA’s games across PC and mobile.

Origin also contains social features such as profile management, networking with friends with chat and direct game joining along with community integration with networking sites such as Facebook, Xbox Live, PlayStation Network, and Nintendo Network.

 

Origin and the Vulnerabilities Found

In a similar manner to Check Point Research’s previous discoveries into another hugely popular online game, Fortnite, the vulnerabilities found in EA’s platform similarly did not require the user to hand over any login details whatsoever. Instead, it took advantage of EA Games’ use of authentication tokens in conjunction with the oAuth Single Sign-On (SSO) and TRUST mechanism that is built into EA Game’s user login process.

In this case, EA Games is a cloud-based company that uses Microsoft Azure to host several domain names such as ea.com and origin.com in order to provide global access to various services for their players, including creating new game accounts, connecting to the Origin social network and purchasing more games in EA’s online store.

 

Technical Details

Eaplayinvite.ea.com Subdomain Hijacking

EA games operates several domain names such as ea.com and origin.com in order to provide global access to various services for their players, including creating new Apex Legend accounts, connecting to the Origin social network, as well as purchasing new EA games in the company’s online store.

Generally, each service offered by a cloud-based company such as EA Games is registered on a unique subdomain address, for example, eaplayinvite.ea.com, and has a DNS pointer (A or CNAME record) to a specific cloud supplier host, ea-invite-reg.azurewebsites.net, which runs the desired service in the background, in this case a web application server.

 

Fig 1: The DNS pointer for eaplayinvite.ea.com points to the CNAME record, ea-invite-reg.azurewebsites.net

 

Azure is a cloud services provider solution powered by Microsoft and allows for a company to register new services (e.g. web applications, REST APIs, Virtual Machines, databases and more) in order to provide them to online customers around the world.

Each Azure user account can request to register a specific service name (Service-Name.azurewebsites.net) which will be connected to a specific domain or subdomain of the organization after successfully validating it’s CNAME records during Azure subdomain validation process.

During CyberInt’s research, though, they found that the ea-invite-reg.azurewebsites.net service was not in-use anymore within Azure cloud services, however the unique subdomain eaplayinvite.ea.com still redirect to it using the CNAME configuration.

The CNAME redirection of eaplayinvite.ea.com allows us to create a new successful registration request at our own Azure account and register ea-invite-reg.azurewebsites.net as our new web application service. This allowed us to essentially hijack the subdomain of eaplayinvite.ea.com and monitor the requests made by EA valid users 🙂

 

Fig 2: Changing the CNAME redirection of ‘eaplayinvite.ea.com’ to our own ‘ea-invite-reg.azurewebsites.net’ hosted in our own Azure account.

 

As seen from the below, the DNS Record status after the hijacking process now shows that the eaplayinvite.ea.com redirects to our new Azure cloud web service:

Fig 3: The DNS Record status after the hijacking process. ‘eaplayinvite.ea.com’ now redirects to our new Azure cloud web service

 

oAuth Invalid Redirection to Account Take-Over

Having control over the eaplayinvite.ea.com subdomain led our research team to a new goal of figuring out how we can abuse the TRUST mechanism. The TRUST mechanism exists between ea.com and origin.com domains and their subdomains. Successfully abusing the mechanism enabled our research team to manipulate the oAuth protocol implementation for full account take-over exploitation.

We began by identifying how EA games had configured the oAuth protocol and provides its users a Single Sign-on (SSO) mechanism. The SSO mechanism exchanges the user credentials (user & password) by unique SSO Token and then uses the token to authenticate with any platform (for ex. accounts.origin.com) of EA networks without having to enter their credentials again.

Analyzing the EA games oAuth SSO implementation within several EA services such as answers.ea.com, help.ea.com and accounts.ea.com helped us to review the EA authentication process and learn more about the TRUST mechanism that had been implemented.

As part of a successful authentication process with EA global services via answers.ea.com, an oAauth HTTP request is sent to accounts.ea.com in order to get a new user SSO token, then the application should redirect it through signin.ea.com to the final EA service called answers.ea.com to identify the user.

 

Fig 4: An oAuth SSO request for authenticating with answers.ea.com

 

 

Fig 5: The oAuth authentication SSO token is redirected through signin.ea.com to EA answers.ea.com server

 

We found, however, that it was actually possible to determine the EA service address which the oAuth token is generated for  by modifying the returnURI parameter within the HTTP request to our hijacked sub-domain of EA, eaplayinvite.ea.com.

 

Fig 6: oAuth requests to generate a new user token for eaplayinvite.ea.com

 

Fig 7: The server generates valid token without validation of the fake EA service

 

However, generating the above-mentioned request to redirect the generated SSO token into our hands was not sufficient since several limitations took place on EA’s side.

The following items represent the limitations introduced by EA and how we successfully bypassed them in order to weaponize our attack:

 

Limitation 1 – A Missing Valid Referer

In order to compromise EA accounts, the research teams needed to send the previously mentioned request to accounts.ea.com including the modified parameters on behalf of the victim.

However, the backend server of accounts.ea.com validates if the request originally came from a trusted Origin domain by checking the HTTP Referer header.

 

 

To overcome this limitation we needed to start the request on behalf of our victim from an EA trusted domain or subdomain. So we coded a new Iframe onto the index page of our hijacked subdomain so the request would be initiated from the Iframe and bypass the server validation.

 

Fig 8: eaplayinvite.ea.com malicious index page

 

Fig 9: Attacker’s generates iframe on eaplayinvite.ea.com to bypass http Referer validation

 

Limitation 2 – The Origin Problem

After sending the request to signin.ea.com to complete our malicious authentication process and get the victim’s token to our hijacked subdomain at eaplayinvite.ea.com, a new jQuery function is generated and returned to the client for redirecting the token.

 

However, the jQuery $.postMessage function will fail from executing this time since the destination server (eaplayinvite.ea.com) is not part of the current Origin (signin.ea.com). Therefore the function will send an error to the browser console and stop itself from sending the token to us.

 

To overcome this issue, we had to look for a new token redirection method on signin.ea.com since the jQuery function stopped them from getting the victim’s token as part of the malicious flow.

After several attempts, we captured one different request to signin.ea.com that contained the redirectback parameter. This parameter guided the server to use the returnuri value and redirect the page to it directly, without attaching to it the victim’s access token.

Fig 10: Sending redirectback parameter to bypass jQuery origin issue

 

Fig 11: The server responded with a simple redirection to the target server

 

At this point we managed to redirect an authenticated EA player to our servers. We were able to do this after they visited the oAuth SSO authentication iframe and so were then able to log the incoming request within our servers.

 

 

The token was sent to our servers within the HTTP Referer header since the player was redirected through severaloAuth SSO URLs using our malicious Iframes. The last redirection on signin.ea.com redirected the player to our server using window.location JavaScript function. It contained the SSO token of the player and allowed us to take control over it.

 

Fig 12: Logging the incoming Referer value and searching for the victim’s Access-Token

 

Fig 12: The victim oAuth SSO token logged on the attacker’s PC