Academics Find Crypto Bugs in 306 Popular Android Apps, None Get Patched (zdnet.com) 32
A team of academics from Columbia University has developed a custom tool to dynamically analyze Android applications and see if they're using cryptographic code in an unsafe way. From a report: Named CRYLOGGER, the tool was used to test 1,780 Android applications, representing the most popular apps across 33 different Play Store categories, in September and October 2019. Researchers say the tool, which checked for 26 basic cryptography rules (mentioned in the source story), found bugs in 306 Android applications. Some apps broke one rule, while others broke multiple.
they didn't disclose the names (Score:1)
Re: (Score:1)
Since none of the developers fixed their apps and libraries, researchers refrained from publishing the names of the vulnerable apps and libraries, citing possible exploitation attempts against the apps' users.
Useless arseholes
Re: (Score:2)
For apps? Just integrate the tool into the upload process and Google Play Protect. If it fails the next time someone tries to install the app, flag it in the store to prevent people from installing or upgrading to a version that doesn't have it fixed.
Comment removed (Score:5, Insightful)
Re: (Score:2)
More nit picking..
SHA1 while not ideal, is safe when used within HMAC, which is possibly the primary use.
IVs are either there to be unpredictable or to be unique. A PRNG that is 'safe' is entirely unable to give a uniqueness guarantee. An 'unsafe' PRNG that never repeats a value (E.G. CTR mode) is capable of making that guarantee.
Using a constant, fixed key in CBC-MAC is the only safe thing to do when you are using CBC-MAC for entropy extraction because you cannot guarantee independence from the source and
Re: (Score:2)
not knowing the difference between "Apache 2.4.18" and "Apache 2.4.18-2ubuntu3.17" (i.e. the current latest version for Ubuntu 16.04 LTS, into which all of the important security patches have been backported).
PTSD trigger warning, please, for those of us who have to deal with PCI compliance vendors.
Re: (Score:2)
not knowing the difference between "Apache 2.4.18" and "Apache 2.4.18-2ubuntu3.17" (i.e. the current latest version for Ubuntu 16.04 LTS, into which all of the important security patches have been backported).
PTSD trigger warning, please, for those of us who have to deal with PCI compliance vendors.
Amen. The entire PCI compliance industry seems to be whinging it. They don't actually understand tech or security, but they understand it better than their customers, so they put on a suit and get selling.
Re: (Score:2)
Re: (Score:1)
I agree such scanning lacks the context of the why the crypto is used. At the same time, the faulty code is most likely in a library, which is also lacking that context, and a good library should only rely on solid algorithms.
It sounds to me half of those hits are developers using outdated libraries still supporting broken crypto. I mean, I dont see any excuses for still using http without tls (rule 22, 593 hits), especially on a mobile device, and even if it is to communicate to a local server.
Re: (Score:3)
> and a good library should only rely on solid algorithms.
I guess that depends on whether or not the library know the use of the algorithm being presented through the API.
I'd be unhappy with a sha library not giving me SHA-1. I'd be unhappy with a program using that SHA-1 for a secure data integrity check outside the context of HMAC. I don't think a library can tell what the user intent is.
I don't envy people writing general purpose security libraries. It's a hard job and I generally roll my own so I can
Re: (Score:1)
Good libraries _can't_ know how they're going to be used.
The arrogance on display in this thread is staggering. And in their haste to show that _they_ know when it's fine, they answer the wrong question.
The question is not: when is it fine to use ?
It is: when is it necessary to use them?
Let's review bad reasons:
- security... Obviously not
- ease of implementation. No. Most people use libraries, as they should. And even if, newer algos are no more complicated to write than old ones, except possibly ECC. Good
Re: (Score:2)
Why are you arguing with my while agreeing on the details?
Re: (Score:1)
My apologies, that was poorly worded.
I wasn't arguing with you - except to make the point that people writing crypto libraries can't possibly know how they're going to be used.
I was arguing against all the upmoded clowns who like to believe that good developers, like themselves, or so they think, know when their use case does not require modern, secure (for the time being) crypto, when in fact good crypto comes not only at no cost, but actually with benefits, beginning with speed and simplicity (in addition
Re: (Score:2)
This. Nobody cares if after years of research you might be able to gain a 0.2% advantage in a smartphone version of a board game that rolls dice. Context is everything.
Even things that are nominally about security may not really matter. Nobody really cares if the secret decoder ring found in a box of Cap'n Crunch can be cracked in 5 minutes.
They'll need to show us that these vulnerabilities exist in apps that might actually be supposed to secure things like healthcare records or banking details. Then I'll g
About half are false positives (Score:2)
Pages 12 and 13 of the paper address what you brought up.
About half of the questionable calls found by the automated tool are actually exploitable vulnerabilities.
So the tool can be used to say "there us 50/50 chance you have a vulnerability on line #117 of your code. You should probably check that." Not bad for an automated tool. Additionally, one can narrow it down by just considering the purpose of the app - an online banking app that uses bad crypto is obviously different from a meme generator that do
Re: (Score:2)
Re: (Score:2)
Just to make sure I understand you correctly, is your pijt the following:
Using a tool that is totally unsuitable for the job (pounding a nail with with a screwdriver) can be worse than using a broken or ineffective tool (a hammer head with the handle broken off).
Don't point out the handle snapped off the hammer, because at least they aren't pounding nails with a screwdriver.
Is that pretty much your point?
Re: (Score:2)
For crypto, and even assuming an adversary with a quantum computer, HMAC is fine. Its underlying security depends on the hash function you're using with it... use a 256-bit or better hash (SHA2 or SHA3 are both fine) and you're good.
PBKDF2 is probably fine, depending again on the hash you're using, and the number of iterations you're using. I think the current suggested number of iterations is 100k... so maybe think about switching to HMAC if you're using PBKDF2 so you're not burning as much CPU.
Citation: I
...And this is why we like our Walled Garden (Score:1)
Named CRYLOGGER, the tool was used to test 1,780 Android applications, representing the most popular apps across 33 different Play Store categories, in September and October 2019. Researchers say the tool, which checked for 26 basic cryptography rules (mentioned in the source story), found bugs in 306 Android applications. Some apps broke one rule, while others broke multiple.
Just how many of these stories must one see before realizing that the illusion of freedom that allegedly makes Android such a superior Mobile Platform over iOS/iPadOS is so far outweighed by the very real statistical probability that a typical Android User, even one who only installs Apps from the "safe" Play Store, will fall victim (most often completely unknowingly) of one or more malware-infested Apps?
I know what Benjamin Franklin said; but I'll bet, he'd be rockin' an iPhone!
Only a fool shouts "freedom!
Re: (Score:1)
Re: (Score:2)
I helped someone run Malwarebytes just yesterday. Found about 7-8 malware items, but it logged a threat count of over 1500 between registry entries and Internet Explorer settings. The same tactics are still deployed today - by big name vendors.
Re: (Score:2)
The desktop OS model - Things are in layers, kernel, filesystem, applications, UI. Applications can meddle with things sideways, because they need to communicate with other things.
The Android/iPhone model - Things are in vertical silos. Applications can meddle up and down the stack to interact with the UI and the hardware, but can't meddle sideways with other application state. So apps are generally untrusted and kept in a box much more so than in a desktop OS.
One unsafe application on Android is less likel
Re: (Score:1)
One unsafe application on Android is less likely to cause problems for you than an unsafe application run in your user space on a desktop OS.
correction: one unsafe android application is less likely to cause problems to another application running on the same device than applications on a desktop OS. Also note considering: people usually grant all sorts of permissions to mobile applications without reason, so your silo is kind of falling apart already.
Re: (Score:2)
One unsafe application on Android is less likely to cause problems for you than an unsafe application run in your user space on a desktop OS.
correction: one unsafe android application is less likely to cause problems to another application running on the same device than applications on a desktop OS.
Also note considering: people usually grant all sorts of permissions to mobile applications without reason, so your silo is kind of falling apart already.
It isn't my silo. I was pointing out the security architecture differences between Android/iOS and windows/linux. It's worth understanding that to understand the threat profile. I don't assume responsibility for what privileges other people grant to other people's applications.
Misleading (Score:3)
Some rando claiming to be from a university attempts to contact me to tell me he can help me fix "security issues" with my app. It sounds just like the myriad of spam messages I get daily. Is it any wonder why most of the developers haven't responded?
Shallow Analysis is Worthless (Score:3)
Gosh, researchers find what they consider "issues", and nobody believes them. Imagine!
Most of these aren't all that serious, or even remotely so, depending on the usage. Take #22, Don't Use HTTP Connections... what's that got to do with Encryption? Did they flag any program that use HTTP-served banner ads in a frame? Or that provided a link to their online help, served by a CDN to save money? Utterly idiotic.
It's also not clear how they analyzed them. Did they really verify that any "static" was also a "constant"? (R-7, 10, 23, etc.) Because that's not what "static" means; it means class-level rather than instance-level. If the class is entirely composed of static members, i.e. treated as a singleton, but it regenerates as appropriate, their analysis is bunk. And, after vetting two or three of their spurrious idiotic claims, I would /dev/null their report also. Without a response.
/. used to be better than this. Change to "Academics claim to find flaws, more flaws found in the Academics".
"Don't use CBC" (Score:2)