Many developers still embed sensitive access tokens and API keys into their mobile applications, putting data and other assets stored on various third-party services at risk.
A new study performed by cybersecurity firm Fallible on 16,000 Android applications revealed that about 2,500 had some type of secret credential hard-coded into them. The apps were scanned with an online tool released by the company in November.
Hard-coding access keys for third-party services into apps can be justified when the access they provide is limited in scope. However, in some cases, developers include keys that unlock access to sensitive data or systems that can be abused.
This was the case for 304 apps found by Fallible that contained access tokens and API keys for services like Twitter, Dropbox, Flickr, Instagram, Slack, or Amazon Web Services (AWS).
Three hundred apps out of 16,000 might not seem like a lot, but, depending on its type and the privileges associated with it, a single leaked credential can lead to a massive data breach.
Slack tokens, for example, can provide access to chat logs used by development teams, and these can contain additional credentials for databases, continuous integration platforms, and other internal services, not to mention shared files and documents.
Last year, researchers from website security firm Detectify found more than 1,500 Slack access tokens that had been hard-coded into open source projects hosted on GitHub.
[...] This is not the first time when API keys, access tokens, and other secret credentials were found inside mobile apps. In 2015, researchers from Technical University in Darmstadt, Germany, uncovered more than 1,000 access credentials for Backend-as-a-Service (BaaS) frameworks stored inside Android and iOS applications. Those credentials unlocked access to more than 18.5 million database records containing 56 million data items that app developers stored on BaaS providers like Facebook-owned Parse, CloudMine, or AWS.
[Continues...]
Some 2500 apps contained either secrets or third party keys, with most such as those found in Uber's app being safe and necessary for the platforms to function on Google play or with other services.
Others contained Amazon Web Services keys that granted extensive access to accounts.
"Some keys are harmless and are required to be there in the app for example Google's API key but there were lots of API secrets as well which definitely shouldn't have been in the apps," researchers at the company say.
"Then there were AWS secrets too hardcoded in the apps. Some of them had full privilege of creating and deleting instances."
Twitter keys were the most common to be found in the studied apps, along with Urban Airship and a scattering of other services.
"For app developers reading this, whenever you hardcode any API key or token into your app, think hard if you really need to hardcode this, [and] understand the API usage and the read and write scope of the tokens," Fallible researchers say.
-- submitted from IRC
(Score: 0) by Anonymous Coward on Thursday January 19 2017, @02:06AM
It's been this way ever since the first LAMP stacks. One key to the entire database, because devs don't know shit about databases, and devs don't know shit about access control. Why expect the app stacks to be used any better. The fucking moron devs are the problem.
(Score: 0) by Anonymous Coward on Thursday January 19 2017, @03:00AM
Oh I agree it is an egregious mistake. But how do they find out it is wrong? Maybe if we call them 'fucking morons' they will learn?
(Score: 1, Funny) by Anonymous Coward on Thursday January 19 2017, @03:01AM
They wake up with a bill and wonder why the stupid tax is so high.
(Score: 0) by Anonymous Coward on Thursday January 19 2017, @03:06AM
I know maybe we can call them stupid too that should totally work!
(Score: 0) by Anonymous Coward on Saturday January 21 2017, @12:38AM
Well, clearly you feel addressed by this...
(Score: 4, Insightful) by tekk on Thursday January 19 2017, @03:09AM
This is totally something I've done before for my personal projects. It always bothered me, but when I asked other devs about it the stance was more or less "if someone starts abusing it you can just revoke the key."
Like, what's your alternative? The app has to query a server of mine for the api key? I need some way to verify that it's my app trying to get the api key, not some random person wanting to use my credentials, so now I need an api key for the api key. Do I hardcode that in my app? Is it turtles all the way down?
I guess I could just throw the api key in a text file and encrypt it, except now I need to put the encryption string in my app, and I probably shouldn't roll my own crypto so really all you need to know is 1: which crypto library I'm using, and 2: how I'm calling it. If you have the executable you can just disassemble and find all of that out.
I'm genuinely interested in what best practice here is, if anyone actually knows.
(Score: 2) by Nerdfest on Thursday January 19 2017, @04:45AM
Public/private key encrypted API key perhaps? I've done something like that to obfuscate database passwords in server property files. A dedicated person can always get them of course as all the information you need is there it's just finding it and figuring out what to do with it. You can always just grab it in the clear from memory if it comes down to it.
(Score: 2) by tekk on Thursday January 19 2017, @05:46AM
You can always just grab it in the clear from memory if it comes down to it.
Yeah, that's my big problem with it. Nothing's keeping me from just running wireshark or reading the process memory. Public key encrypted api key could work. The only reasonable solution I can think of is that you just force the app to proxy through your server, so that you can implement the access controls you need yourself if the api you're using doesn't provide them.
(Score: 2) by Nerdfest on Thursday January 19 2017, @10:54AM
That's what I was thinking as well, and it would need to be a credential based auth that was set up with the specific user .... otherwise you just moved the problem again.
(Score: 2) by jmorris on Thursday January 19 2017, @05:42AM
A determined opponent will get the key if it is distributed to the users in the app. And now we apparently have automated tools to extract keys so it doesn't even require some 3rd world kid with a low enough value on his time to make disassembling code looking for keys to sell practical. I think real the point here is that a key should be carefully restricted as to what it can do. The example of an AWS key with full rights is one that should have not been distributed in the Play Store.
(Score: 2, Informative) by Anonymous Coward on Thursday January 19 2017, @09:01AM
The way you are supposed to do it, is to put the security in the server, and not care about whether or not people use the official app.
Authenticate the user, not the app. As long as the user has a valid account, you should care about whether he's using Pidgin or the official ICQ app (to use a real world example). Or, you should care, but only in the sense that people using the alternative means that your app isn't good enough.
(Score: 0) by Anonymous Coward on Thursday January 19 2017, @12:12PM
In your post, one "should" should be "shouldn't", shouldn't it?
(Score: 2) by Pino P on Thursday January 19 2017, @03:12PM
The way you are supposed to do it, is to put the security in the server
Then how can the server ensure that messages from the service's sponsors are displayed? Or should all Internet services be run by a charity and supported through donations, like Wikimedia wikis are?
(Score: 0) by Anonymous Coward on Thursday January 19 2017, @03:31PM
Precisely my thoughts. At some level there will always be something like this done by companies that care about that level of user-as-commodity trading. It is not a security flaw, it is merely the same practice that often results in security flaws - a code smell, if you will.
(Score: 0) by Anonymous Coward on Thursday January 19 2017, @06:06PM
And this is why I want to go back ten years, when people wrote code without fear of offending their advertising network or third party sponsor entirely unrelated to the product they are trying to get me to use.
Google may or may not have ruined a great thing, but they greatly contributed to its demise with premise behind Android. It's success was inevitable since the cost was low and the actual violations that took place were silent and not shown to the users.
My first few websites were run exactly as you describe, but I wouldn't call funding my own hobby a chartiable expense. And as my hobby grew, my business paid for the hosting as well -- and I saved money by doing a lot of the work myself.
Third party ads were never once included in the equation. Why is it included today? Is it because developers can't host their own websites anymore because of the "???" in the 4 steps to profit? Paypal and ebay make for great payment processors, provided one is OK with either handling their money. Not everything has to be centralized around an advertising ID and delivery of ads to it.
Is it that they rely on an app store to reach people, and the app store has to only have applications with adverstiving networks and wrappers embedded into what is otherwise a program entirely unrelated to it? And this is all because new programmers were never taught how to do these other parts of running a business or publishing their own applications?
Christ, I'd rather have restrictve DRM than ensured delivery of sponsor placed ads. It's just as much of a foul tasting poison, but at least I am getting what I paid for and not ads to buy something else. And if the product is free, I guess I can't argue, but I probably wouldn't rely on business model to give away something for free and expect people to value it.
I really hope you were speaking facetiously. That is 100% pointy haired bossspeak.
(Score: 2) by Pino P on Thursday January 19 2017, @10:03PM
And as my hobby grew, my business paid for the hosting as well
By "my business", do you refer to a business that you own, or just a business that employs you?
Third party ads were never once included in the equation. Why is it included today? Is it because developers can't host their own websites anymore because of the "???" in the 4 steps to profit? Paypal and ebay make for great payment processors, provided one is OK with either handling their money.
Unless your articles are expensive as those of closed-access scholarly journals published by Elsevier or Springer, paying per article doesn't work when PayPal and other payment processors skim off a substantial fee per transaction (currently 0.30 USD) in addition to a 3 percent cut. Nor does a monthly subscription work for people who arrive at your site through a search engine result or an article URL shared by one of your readers. Most readers would click the back button instead of creating an account, waiting for the confirmation email to arrive, and paying $4 for a month's access just to read one article, especially if there are 20 different sites to which they'd need to subscribe to read 20 different articles.
Is it that they rely on an app store to reach people, and the app store has to only have applications with adverstiving networks and wrappers embedded into what is otherwise a program entirely unrelated to it?
Here's how I've heard it: It's because smartphone manufacturers and carriers began to sell Android devices in countries where Google had not yet begun to offer Google Checkout. In those countries, Android Market (now Google Play Store) listed only free (as in beer) applications. Therefore, to reach users in those countries, developers had to make their Android applications available without charge. This expectation that applications shall be ad-supported rather than paid up front eventually leaked to the rest of the world, even countries where Google was offering paid applications.
And this is all because new programmers were never taught how to do these other parts of running a business
Correct. Universities aren't trade schools, despite persistent efforts to pass them off as such, and many undergraduate engineering curricula don't include self-employment as a required or even strongly recommended course.
(Score: 0) by Anonymous Coward on Thursday January 19 2017, @02:00PM
or just "girlfriend"?