It would be reasonably safe to say that these bugs are not limited to the google app store.
1780 apps were tested.
Glad to see the project is open source and available for others to use.
1 Like
You can look at the comments on this at Academics Find Crypto Bugs in 306 Popular Android Apps, None Get Patched - Slashdot to see that this was a very poorly designed âstudyâ and the results are mostly bunk.
I skimmed the paper. Iâm more impressed by its content than the /. comments. Itâs interesting 3/4 co-authors are from Italy, and 3/4 of their columbia edu sites are now 404 or emptied (but still in archive org). Made me get APKTool and JADX, and wonder why they werenât afraid to reverse engineer media-related apps. 
Who doesnât like a dynamic approach with inter-app analysis, to compliment static scanners? Maybe weâll get lucky and @droidX , PhD will weigh in.
The following is an example of one of the Slashdot comments that I found compelling:
Letâs look at the three top rules.
PRNGs are not used solely for cryptography. Even shuffling a slideshow will use a PRNG. God forbid I used a crypt-safe PRNG to shuffle a slideshow!
SHA1 and MD5 have their place when they are not used to protect any secrets. For example, they might be consistency checks for non-critical data, e.g. as used with the Amazon S3 API. They are also perfectly fine if used with PBKDF2 or HMAC, even MD5, as long as a practical quantum computer is not invented yet (itâs not, yet).
As for using CBC, again, it depends on how you are using it. If you use a static IV and a weak key expansion or relatively short static key itâs fairly easy to break the encryption via basic cryptanalysis. Been there, done that, egg in my face. If you use a crypto-safe PRNG to generate a new IV for each small block of data being encrypted, do not communicate the actual encryption key and use a good, proven key expansion algorithm itâs safe from cryptanalysis unless someone breaks Rijndael-128 itself (which nobody has, yet).
If I had received an email from them with this kind of pathetic inferences I wouldnât reply back either. Those who were suckered into replying figured out sooner or later that the researchers were making blanket assumptions and gave up. No wonder nothing got fixed. There was nothing to fix, most likely.
I hate overly generalised âresearchâ which only produces sensationalist headlines. It is a disservice to developers and users. It conditions developers to ignore any security reports unless they come with a POC, thereby possibly missing some legitimate security issues. It conditions users to the notion that everything is insecure so why care if I run outdated software, it is all broken anyway. Well done, âresearchersâ. Well done.
Letâs look at the three top rules.
They had 26 rules.
If I had received an email âŚ
âStarting from the apps that violate 18 rules (the highest number of violations in our dataset), we contacted all the apps with >= 9 rule violations.â
sensationalist headlines.
Donât blame the researchers. Their title was:
âCRYLOGGER: Detecting Crypto Misuses Dynamicallyâ
including for their brief youtube video (2 minutes:48 seconds), which is relatively dry but informative.
I read over the article. Overall it was better written than I expected.
As the authors point out, the core of the problem is that developers often do not understand crypto, use default values for crypto libraries that are no longer considered secure, import third-party code that they either do not understand or do not audit, or use third-party libraries that perform cryptographic functions that they do not audit themselves. This is a difficult and thorny issue that will never be resolved as long as the majority of developers and the companies they work for are OK with grabbing any piece of code they can find online or in a repository as long as it appears to work.
The biggest complaint with the article is that their method is prone to a lot of false positives, and, more seriously, they pretend it isnât, either because they are foolish or because they have their heads stuck in the ground. They readily admit that other methods have a lot of false positives, like this sentence from the second page: âUsing a dynamic tool on a large number of apps is hard, but CRYLOGGER can refine the misuses identified with static analysis because, typically, many of them are false positives that cannot be discarded manually on such a large number of apps.â Again, on the third page, âAs discussed in [27], the main problem with static analysis is the high number of false positives, which requires the users to manually examine the results and determine the true positives.â
On page 11 they make this stunning claim: âCRYLOGGER cannot produce any false positives, but it produces 19 false negatives, all for the tests that are argument sensitive.â
Oh, really? As was pointed out by the Slashdot comment I referenced earlier, there are a lot of scenarios where MD5 or SHA1 can be used in an app that do not relate to cryptographic security. But their analysis would flag all of these as false positives.
When they contacted app developers that is what they were told. âApps A-01, A-04, and A-07 violate rule R-01. Their developers told us that MD5 or SHA1 are used for hashing non-sensitive values.â
Then, even though they have previously stated that CRYLOGGER cannot produce false positives, when they reverse engineered 28 of the apps, they admitted the following, âThe other violations can be considered false positives. Some are caused by âimpreciseâ rules. For example, on 3 apps each, rules R-01 and R-18 flag secure uses of hash algorithms
and random number generators for non-sensitive data. Similarly, R-04 flags 3 apps that use CBC encryption for scenarios different from client/server.â These are all cases that were pointed out by the Slashdot comment, specifically that PRNGs do not needs to be secure random when not used for secure data (doing so needlessly slows down the app and uses excess battery power), that MD5 and SHA1 donât cause problems when used for non-sensitive data (and again, increase speed and save battery power when used in these scenarios), and that CBC can be used in certain scenarios without problem (although in this case I do not agree with the entirety of the Slashdot comment about when it should be considered safe).
If they had just been a little more realistic about the limitations of CRYLOGGER in regards to false positives I wouldnât have much negative to say about the article. It is definitely an improvement on the previous state of automatic scanning.
On a personal note, I used their article to review the encryption implementation used in Privacy Browser to encrypt exported settings files. You can see this at the following URL beginning with line 869:
It was a good review of code. I didnât find any problems, but then again, I was very careful when I wrote the algorithm and I did a lot of research to make sure I understood all the configuration parameters.
However, if you ran CRYLOGGER on Privacy Browser it would probably generate a number of false positives. For example, it would complain about the ability for HTTP access, despite the fact that everything default to HTTPS and visibly warns the user whenever HTTP is used. And the ability to access HTTP pages is a core functionality of the browser that should not be removed. It isnât a bug, it is a feature.
If I had a recommendation for them it would be to consider the PRNG and hashing tests as informational warnings instead of failures, because they are the most likely to produce false positives. The other tests are likely to indicate real problems most of the time.
Thanks for your comments!
Your recommendation is probably a good one. Overall the authors were honest and accurate, IMO. Itâs one of those technical and semantic interpretation things needing better AI for the software to handle with deeper understanding of the code being analyzed. Technically, they are right; the rule was violated. Deeper analysis says, nah, itâs OK.
Itâs like the example of the link you gave above. For my browser itâs a âbadâ link, giving a 404 if I click it or if I manually copy/paste the link to reduce tracking. However, the âhoverâ on the link displays a âgoodâ link. So, with minor editing: â%3Bâ => â;â and â%2Fâ => â/â the link becomes âgood.â So, my simple ruleset flags it as âbad linkâ but my deeper understanding says, nah, itâs OK even if it broke the rule. Not the best example, but it makes a similar point.
Technically, they are right; the rule was violated. Deeper analysis says, nah, itâs OK.
Their rule identified behavior that was not bad and claimed that it was bad. Therefore, technically, their rule was incorrect. That is their whole problem. Anytime you start bugging developers with emails claiming their apps have security flaws, when their apps do not have security flaws and it is your scanner that is incorrect, you need to immediately stop what you are redoing and rethink your approach.
Regarding the link, Discourse, this forum software, has issues mangling links. I think it has to do with how they attempt to track the number of people who click on the link. If I put it in a code segment it doesnât get modified, but it is no longer a hyperlink.
https://git.stoutner.com/?p=PrivacyBrowser.git;a=blob;f=app/src/main/java/com/stoutner/privacybrowser/activities/ImportExportActivity.java;h=53c1109c726c7c520c56d35aa83b5bad32c6b550;hb=HEAD
It also looks like I can manually specify a hyperlink that works correctly.
I like the idea of testing for more security problems. This seems to generate false positives. But it also looks like it misses potentially serious security problems.
I havenât looked at the article, only the list of 26 rules. But it looks like they donât check if apps accepts insecure cipher suites or obsolete protocols (like SSLv3 and the soon obsolete TLSv1.0 and TLSv1.1), and if they support modern protocols and cipher suites. This is a particularly big problem for apps from f-droid (and also on devices without googleâs services), because the Security Provider included by the OS doesnât get updated.
The only solution right now is to bundle the conscrypt security provider directly with the app, which is thankfully quite easy (see my example/tutorial), but it means every app needs to bundle it and also grows in size (for example an upcoming F-Droid version of Antennapod will be a few MB:s larger than the Play version from bundling conscrypt). Hopefully itâll be possible to package conscrypt through f-droid and provide it to all apps in the future (ByteHamster wrote a good summary on this idea here).
2 Likes
Github just made their âscannerâ tool available for others to use.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.