reader comments

94

Israeli security firms Check Point and CyberInt partnered up this week to find, exploit, and demonstrate a nasty security flaw that allows attackers to hijack player accounts in EA/Origin’s online games. The exploit chains together several classic types of attacks—phishing, session hijacking, and cross-site scripting—but the key flaw that makes the entire attack work is poorly maintained DNS.

This short video clip walks you through the entire process: phish a victim, steal their account token, access their account, and even buy in-game stuff with their saved credit card. (You might want to mute before you press play—the background music is loud and obnoxious.)

If you have a reasonably good eye for infosec, most of the video speaks for itself. The attacker phishes a victim over WhatsApp into clicking a dodgy link, the victim clicks the shiny and gets owned, and the stolen credentials are used to wreak havoc on the victim’s account.

What makes this attack different—and considerably more dangerous—is the attacker’s possession of a site hosted at a valid, working subdomain of ea.com. Without a real subdomain in their possession, the attack would have required the victim to log in to a fake EA portal to allow the attacker to harvest a password. This would have immensely increased the likelihood of the victim becoming alert to a scam. With the working subdomain, the attacker was able to harvest the authentication token from an existing active EA session before exploiting it directly and in real time.

When I spoke to CyberInt’s Alex Peleg and Check Point’s Oded Vanunu in a conference call today, that was really all I wanted to know—how’d you guys get control of that EA subdomain in the first place? According to the two researchers, it’s a pretty common screwup. A big company starts a new marketing campaign, sets up a devops team to do the coding work necessary, and gives the team a new subdomain—like eaplayinvite.ea.com—to run the campaign on. The devops team spins up new instances on AWS, Google Cloud, or a similar provider, then uses a CNAME record to connect the company subdomain to a provider-internal A record at the host. When the marketing campaign is over, the AWS or other cloud instance gets shut down… but nobody tells the team managing the company’s main domain to get rid of the CNAME record. That’s where things go sideways.

dig to find out all sorts of interesting things about an FQDN.’ >You can use the DNS command-line tool <code>dig</code> to find out all sorts of interesting things about an FQDN.’ src=”https://cdn.arstechnica.net/wp-content/uploads/2019/06/Screenshot-from-2019-06-25-18-30-18-640×222.png” width=”640″ height=”222″ ‘youcan use the dns command-line tool <code>dig< code>to find out all sorts of interesting things about an fqdn.
Enlarge / You can use the DNS command-line tool dig to find out all sorts of interesting things about an FQDN.
Jim Salter

An attacker interested in the company can see that it launched a new subdomain and then use the tool dig to see how it's hosted. If the attacker sees that the company has used a CNAME record to redirect to a cloud provider's internal DNS, the next step is to wait for the marketing campaign to complete and the URLs involved in the campaign to stop working. Now we dig the subdomain name again—if the original CNAME is intact, we're in business. Next, the attacker uses an account of their own at the same cloud provider and requests the same provider-internal DNS name originally used by the campaign.

At this point, the original CNAME is now pointing to the attacker's website, not one controlled by the actual company. Armed with a working subdomain of the company's real domain, cookies belonging to the company's users can be captured (and embedded!). This makes instant attacks versus victims using that company's services possible.

In this case, Alex and Oded opened with a phishing attack over WhatsApp, but a more enterprising attacker might instead have begun with a watering-hole attack. Imagine a serious attacker had bought HTML-enabled ads from a banner farm, specifically targeting EA gamers—their ad might open an invisible iframe to their hijacked subdomain. Such an iframe could automatically harvest any logged-in gamers' auth tokens without any need for interaction from the users at all.

Scary possibilities abound.

According to Alex and Oded, the kind of oversight made here by EA/Origin is depressingly common in large companies. Devops teams don't talk to infosec teams, neither of them talks to more traditional ops teams that manage core services like company-wide DNS, and mistakes get made. The researchers—and their companies—hope that public demonstrations like this will wake large companies up, break down the silos, and ultimately make end-user accounts less vulnerable to hacking.

Listing image by Yosa Buson