Hackers Steal Facebook User Access Tokens from Epic Games

Hackers this week stole 800,000 user tokens from Epic Games. Much of that was Facebook data.  

When you go to a website that lets you login with your Google or Facebook credentials, that site exchanges data with Google or Facebook. Those social media sites issues some kind of token, which you can think of as a session ticket. That is what lets you log in.

Obviously that data exchange point is a good spot for hackers to lurk as those tokens can be used to spoof user credentials. In other words, they can pretend to be that user if they have those session tickets.

This is not usually a concern with, for example, SSL web session tokens. That is because those are set to timeout. Also because of the certificate chain-of-authority, those cannot be used by a third party. This is because the hacker cannot fake being a valid person at the end of the chain.

What does this mean for Facebook?
If you read Facebook’s API documentation you see that there are various types of API tokens.  Of those, the User Access type fall into two categories: long term and short term. The short term ones expire after a few hours. The long term ones expire after a long 60 days. Ouch.

A token is the normal mechanism that programmers use to call APIs. They are also called API Keys. This is how the programmer authenticates, meaning login, to the target application.

Facebook's documentation says, “This kind of access token is needed any time the app calls an API to read, modify or write a specific person's Facebook data on their behalf."

epic games hack

That very clearly says that a hacker could use these tokens to update people’s Facebook data. Unlike SSL tokens, these contain no certificate to tie them to a specific user session.

Facebook has not publicly said what it has done to invalidate these tokens. But they could obviously see which Facebook users have given Epic Games access to their Facebook data and then revoke all of those.

How they Did It
The hackers used SQL injection to cause the Epic Games database to dump all of its data.  That is where a hacker enters SQL code (i.e. database instructions) into a data field that is supposed to contain only data. Good web and application security is supposed to block this.  But it does not always work.

In other words, the hacker instead of entering, for sample, a name in the name field, enters something like this code taken, from Oracle’s website showing how to dump data:

“expdp scott/tiger@db10g tables=EMP,DEPT directory=TEST_DIR dumpfile=EMP_DEPT.dmp logfile=expdpEMP_DEPT.log”

A program works with a database using different techniques. For example, there is the ODBC technique that uses a vendor-specific database driver. That is common on Microsoft platforms. The programmer makes a connection to a database (db) and then uses ODBC database techniques like db.update, db.insert, etc to make changes to the data.

If the program were to do something like db.update(read-hacker-SQL-data-from-screen) then the ODBC driver would run those SQL commands that as commands and not plain data. That would dump the whole database which the hackers could then send back to themselves. They can send this data to themselves because SQL commands also let the hacker open up a command line shell. So that they can do things like ftp data back to their command and control center.

How to Prevent this Type of Attack
Intrusion detection hardware and software is supposed to use regular express and other filters to look for the combination of special characters, like <,[, !, and >, that a hacker would type into a place it should not go, like the name field. That level of protection has to exist at the TCP level. It also needs to work on an unencrypted segment of the network, meaning no SSL. Such data is only decrypted when it is actually read by the program.

In the case of SSL, a check could be programmed into the code (which would make for messy code) or put into the link between the application server and the database, as long as that is not encrypted too. (That is a common configuration. For example, Amazon AWS tells customers it is not necessary to encrypt the connection to the database on their platform because they guarantee the security of that.)