Gotta Block ‘Em All – Observations on Controlling Access to Mobile APIs using the Pokemon Go Example (David Stewart)
•Download as PPTX, PDF•
1 like•241 views
This is a session given by David Stewart at Nordic APIs 2016 Platform Summit on October 25th, in Stockholm Sweden. Description: If you publish a mobile app that uses an API then you may have just inadvertently opened that API to the world. Pokemon Go grabbed headlines as hackers rapidly reverse engineered its private API and built an army of unapproved bots and mapping tools. There is a lesson for us all here. Exposing rich APIs which may attract the attention of bots designed with the intention of scraping valuable data from your backend servers or abusing your API in a myriad of different ways. Using Pokemon Go as an example, this presentation will explain the cat and mouse games with bots that can emerge when you deploy a successful app, and what steps you should take to protect your mobile API in those circumstances.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Gotta Block ‘Em All – Observations on Controlling Access to Mobile APIs using the Pokemon Go Example (David Stewart)
Similar to Gotta Block ‘Em All – Observations on Controlling Access to Mobile APIs using the Pokemon Go Example (David Stewart) (20)
More from Nordic APIs
More from Nordic APIs (20)
Recently uploaded
Recently uploaded (20)
Gotta Block ‘Em All – Observations on Controlling Access to Mobile APIs using the Pokemon Go Example (David Stewart)
- 1. – Observations on Controlling Access to Mobile APIs Using the Pokemon Go Example Block
- 2. KEY PRESENTATION MESSAGE • Your next app or API service may be a brilliant idea! • Why not? • Consider success: • MAU (monthly active users) numbers from your dreams • Traffic beyond your scale tests • Revenue to die for • Will you capitalize on it?
- 3. BOTs AND MOBILE APIs • What is a bot? • We’re talking about bad bots here • Definition: Automated software using your API against your desires • What: Extraction, degradation, cheating • Why: Make money or mischief • And why should you care? • Increased client functionality & API richness • Traffic migrating from web to mobile • No mobile protection solutions
- 4. POKEMON GO: THE LAUNCH • Mobile game first released 6th July 2016 • Staggered geo release over 3 months • After 8 weeks: • >100 countries • >500M downloads • >4.6B miles walked (7.3B km) • Not bad, eh? • (First mistake: No GPS spoofing protection) Image: Reddit user Inkblob
- 5. POKEMON GO: REVERSING THE API • Action - • Simple man-in-the-middle approach revealed API protocol • First game release used (unpinned)TLS secured communication to prevent people looking at traffic • Enthusiasts were keen to know what they could do through automation, e.g. geolocation spoofing • Reaction - • Niantic implemented certificate pinning • However a lot of useful information had already been extracted • Pokemon proximity functionality disabled
- 6. POKEMON GO: DISABLING CERTIFICATE PINNING • Action - • Enthusiasts disabled certificate pinning • For example using a Xposed module • Recovered Pokemon proximity functionality • Reaction - • Niantic enables the ‘unknown6’ pre-built checksum mechanism • Effect is to block IP addresses of mobile API abusers
- 7. POKEMON: UNRAVELLING CHECKSUMS • Action - • The community mobilized itself and cracked ‘unknown6’ in 4 days • This circumvents the checksum protection in the app • This effectively returns API access to to the enthusiasts • Reaction - • Legal action • Root checks • CAPTCHAs
- 8. POKEMON GO: THE IMPACT • Brand image • Unhappy players • Significant unplanned engineering effort • Revenue • Would the chart have been different if the engineering resources focused on new feature development instead?
- 10. KEY TAKEAWAYS • When it’s easy to do, it pays to plan for success • Control use of your server resources and APIs • Keep your development focused on delivering your roadmap • Software authentication delivers this peace of mind • Consumers are fickle and easily spooked • Is it worth the risk? • Prepare for the bot onslaught when you win! (28.3g) (454 g)
- 11. Tack så mycket! info@approov.io @critblue
Editor's Notes
- If you are exposing mobile APIs, you *must* plan for success (ie this isn't a doom and gloom presentation from the department of no, this is all about ensuring that you maximize the monetization of your success!).
- This is the summary of presentation. The case that will be made: it's much better to bake in invisible API protection rather than have to retro-fit it in the field. Intel’s statement regarding working with startups – they never plan for success. Don’t imagine that your company, your app or your APIs are not ‘interesting’ to be targeted. If you are successful, the bots will come.
- Bad Bot: Piece of automated software that uses your API in a way you didn't intend and don't want What do: Extract data from your servers, degrade performance (DDoS), give people an unfair advantage Why: Curiosity to see what can be done, Extract data to make Money, Mischief Mobile vs Web: Sometimes(not everyone treats mobile apps differently to web) Richer interface Perhaps worth mentioning an emerging attack vector as traffic moves away from web where some techniques exist to block them Bot behaviour: Examples of API probing, cloning game players, exfiltration of sensitive data. Mobile APIs: comparison to web APIs. Increased richness, increased client functionality, lots of API calls to be targeted, increased risks to business Don’t assume that it is only businesses which suffers from fraud that get hacked
- Pokemon Go definition: location based gaming, Pokemon cards coming to life. Pokemon Go: tell the story: launch statistics, staged geographic release, describe the phenomenon Note that the first slip up was not providing any GPS spoofing protection - so people outside of the launch countries were getting access and GPS spoofing to the areas where the game was lauched, so unexpected and uncontrolled load
- Let’s not forget that the people doing were not really bad guys. A bit over-zealous maybe, but not bad guys. Let’s call them enthusiasts! Man In The Middle: Insert yourself into a secure connection to observe secret traffic, good way of examining the API By MITMing the connection, and reverse engineering the API and data structures, it was possible to rapidly understand and use the API. Later Niantic implemented pinning of the connection to protect it, but a lot of information had already been gained at that point, and it is possible to circumvent certificate pinning because it is implemented in the client. 30/07/2016: Niantic Releases patch disabling “three footprints” functionality for finding nearby Pokemon – due to data and power issues. Enthusiasts not best pleased.
- Once the API was accessed, it was possible to use it to play the game without moving around. It was also possible to generate maps of where pokemon were. This allowed players to get back and improve upon the functionality disabled by Niantic. A side effect of this was that apps and sites appeared which showed maps of pokemon near to players. This introduces a vector for malicious apps to trick their way into being installed on devices. Even for apps which provide the expected functionality, there is the side effect of increased server traffic. This has implications for the costs of Niantic and appeared to delay the release of the game in Brazil. Certificate Pinning can be disabled using a framework like Xposed which allows apps and the system to be easily modified on a rooted device. It can also be done by directly modifying the app and repackaging it. Pinning: Allows the app to check the server certificate is the one it expects. It stops MITM because if you are the man in the middle, you don't have the correct certificate because the correct cert is a signed by Niantic. It is significant that it is in the client because you have little control over the client code once it is out in the wild and can't prevent people from trying to circumvent stuff. As an aside, pinning also has problems if you have to change your certificate on the server because you then need to update your app. Not terrible, but can be annoying during the transition as you may have clients which don't update and expect the old cert. Geolocation spoofing started when the API was uncovered as it allowed people in areas with few pokemon to play in more populated areas. It also let people play in countries where the game wasn't released yet. They blocked IPs based on incorrect checksums. If you were using the API outside an app the checksum would be wrong and you could be identified. As a response, Niantic enabled a checksum for messages that was already present in the app. This disabled any unauthorized access. By using the unknown6 checksum, Niantic were able to identify genuine app users vs those using the API to make mapping websites and apps. When they turned on those checks, so only authentic app users could access the API, they saw a massive dropin load on their servers. That is what the graph shows. Pinning is a way for the client to ensure it is talking to the correct server. It is a security mechanism to make it more difficult to snoop on traffic. For pinning, each client stores the expected certificate they should be seeing from the server (the certificate is used to set up the https connection). The client then compares what it gets when it tries to connect vs this known good value. If the values are different, it means someone with a different certificate is pretending to be the server and mounting a MITM attack. You can't do it on the server very easily because there is no way for the server to know what the client certificate is. The client certificate is also different for every client. You could retrieve the certificate for the server and send it back ot the server to check, which is what we do, but I think that is not a standard thing at all. Yes, unknown6 is the checksum. Cracked in 4 days once checks were turned on server side. Pinning prevents MITM attacks. It stops people inspecting your API which makes it more difficult to reverse engineer. Reverse engineering the API is what allowed people to use the API, if pinning had been enabled, it would have been much harder to do that to begin with.
- Action: Hackers circumvent HMAC protection present in Unknown 6 Reaction: Legal measures to take down sites abusing the API, Root checks enabled(v0.37) It took around 4 days for the combined efforts of the Unknown6 team to reverse-engineer and bypass the Niantic protection mechanism. A collection of enthusiasts examined and reverse engineered the protection mechanisms placed in side the app. Niantic responded to this by enabling root/jailbreak checks in side the app. This included using the google SafetyNet API to detect rooting. In addition I have seen some articles that suggest that pokemon go has added but not enabled captchas: It is also worth mentioning that the game currently still supports v0.35 of the API but normally forces you to upgrade to the latest. Not sure if unknown6 is an HMAC actually or something custom By breaking the checksum it enables people to use the API like before CAPTCHAS have now been enabled for suspicious traffic
- Pokemon Go: impact: brand image, unhappy users (normal ones as well as enthusiasts), unplanned engineering effort, panic At it’s peak, Pokemon was earning $10M/day for Niantic.
- Who is CriticalBlue? >150 man years of low level binary dynamic tracing and analysis Many mobile software performance and cryptography optimization projects completed Recent focus on software attestation and mobile API protection
- User authentication is not bad, or wrong, it’s just not enough, and is sometimes not needed at all. Equip yourself with the revolutionary “fire and forget” anti-bot weapon for mobile security: authenticate incoming requests to your mobile-facing API, drop illegitimate ones on the spot, forget about the problem, keep building your future. Hey, maybe there is a business opportunity for a bot proximity detector for mobile APIs