Tue 26 July 2016
A massive success, a staggered worldwide release, ravening hordes of eager adults (and children) with an obsessive urge to catch ’em all. I am of course talking about Pokémon GO from Niantic.
People eager to get their hands on the game in territories where it is unavailable, have resorted to downloading from non-official sources. Some people have even taken to reverse engineering the API, just so they can pretend to be in the USA and start playing.
Even though they must be delighted at the response their game has produced, the developers at Niantic have faced a few unexpected headaches. Although somewhat opportunistic I thought it would be instructive to talk a little about some of the events surrounding the game’s release.
The first thing to note is that with a staggered release and a massive hit on their hands, Niantic ended up with large demand for the game in territories where it was not yet released. This inevitably leads to some smart and motivated people finding ways of getting their hands on the game, and making it available to others. It is also a window of opportunity for less scrupulous people who might take advantage and flood app stores with repackaged versions of the app, or even totally bogus apps claiming to let you play the game. This opens up more people to the risk of installing malware of varying kinds.
Once you have the game you have another problem, it won’t spawn any pokémon in areas where the game is not yet released. This leads to people abusing the communication with the API and modifying it to spoof locations. This means people looking at, reverse engineering and generally hacking around with your private API. They then publish this information to help others. This can have the side effect of giving a helping hand to those who might want to launch a DDOS attack for fun or profit. This impacts legitimate users of the game, and with DDOS attacks becoming more sophisticated and moving into the realm of layer 7 attacks, can be expensive and difficult to detect and protect against.
So if you are a Niantic, or another developer writing the next big thing, how do you stop all of these problems from happening?
There are a number of things you would like to do:
Stop people getting a hold of the game before it is launched in their territory Make the game code more obfuscated so it is harder to reverse engineer Make it harder to examine the traffic between the server and the app Identify and block modified versions of the app connecting to your servers Prevent a DDOS attack impacting your customers It is practically impossible to prevent people from getting a hold of your executable, you have to give it to them so they can play the game. So you have already lost that battle. The next thing to do is to ensure that the code is hard to understand or reverse engineer. Using tools like Proguard can help to make life a little harder for those who want to look at the code, but you really want to avoid people snooping the traffic you send across the network. The standard method of doing that is pinning the connection which involves checking that you are connected to the genuine server by examining some aspect of the secure communication, for example the certificate. This depends upon the client checking the server’s credentials but this is vulnerable to being disabled in the client code. You can use mutual authentication to make things even more secure but you are still dependant upon information that the client needs to know to communicate with the server and this can always be extracted from the app.
If you have some kind of verification of your software, you can try and ensure that only the genuine app can access your servers, but this is easier said than done. The simplest approach is to use a secret key stored in the app and used to sign your traffic, but if it is not well hidden it can be laughably easy to extract. If it can be stolen, then you are back to the same problem of not knowing whether your API is being accessed by an unofficial app.
There have been rumours of DDOS attacks on Niantic’s game and threats of more to come, so how do you prevent users from being kicked out of their game if there is a required online component? If you can provide a mechanism to attest to the authenticity of a particular game client connecting to your API then you can begin to prioritise traffic you are certain comes from genuine apps. This allows you to do more than just wait out the attack, instead you can quickly reject fraudulent connections from DDOS botnets and maintain the user experience for your real players.
And right at the end is where my little bit of opportunism comes in. At CriticalBlue we have developed a product called Approov that helps to protect your mobile app API. We do that, not by authenticating a user, there are many ways to do that, but by authenticating the app itself. It includes mechanisms based on our experience of low level optimisation and binary analysis to check if the app has been modified in any way. It also includes anti-tamper checks that prevent those protections being disabled.
By examining some of the problems Niantic have faced when releasing Pokémon GO we can begin to appreciate the challenges app developers face in making a new mobile product. We should aim to protect ourselves from app repackaging and DDOS attacks by embedding self-protection checks within our software (I would say use Approov, but I am biased). But the most important thing is to think about these problems beforehand so you can concentrate on enjoying a successful release without worrying about hackers spoiling everyone’s fun.