ODK Collect security audits

Hello,

Several safety points have been brought to our attention when using ODK collect:

  • MD5 hashing algorithm, too unreliable
  • TAPJACKING PROTECTION ( android:filterTouchesWhenObscured="true")

Could you please indicate whether patches (or security upgrades) are planned for this purpose or whether they will be implemented in the near future. What are your recommandations in terms of security?

thank you in advance,

Regards.

:wave: hey @Jean-Yves_Devaux. As this is your first time posting it'd be great if you could introduce yourself in this thread.

There is a write up on ODK security considerations in the docs here.

In terms of your bullet points: it would be interesting if you could clarify the "attacks" you're worried about. What would be compromised? How does someone compromise it? What could they do with it?

Thank you @seadowg for your answer.

in a few words to introduce myself :
I work for a publisher in the telecom sector.
We are located in france, vietnam, slovakia and slovakia.
We use the ODK solution to track information.

introduction :
web application firm suggesting ODK collect for visit report collection to one of our clients

In terms of your bullet points:
weak hashing algorithms (MD5) : "it can be vulnerable to collisions and other security weaknesses, and should not be used", feedback from our client security team
for tapjacking : client feedback is "When user touches the screen, application may pass the touch event to another application below its user interface layer that the user does not see, serving like a proxy to pass unintended touch activities. This attack is quite similar to clickjacking but for mobile devices." and they advise us to use android:filterTouchesWhenObscured="true"

they also alert us on temporary file creation and want to make sure it is deleted when they are no more required.
and last one is linked to raw SQL queries, "Inclusion of input into raw SQL queries can potentially lead to a local SQL injection vulnerability in the mobile application"

it is very precise feedback and we would likely get your expertise on these topics.

B. Regards

What particular us of MD5 is the team concerned about?

Seems like a valid concern. Would need some research but I could see this being added as long is it doesn't effect any existing features in the app.

Not quite clear on what this refers to. Would be great to have examples.

Makes sense as general advisory. Did the security team find any ways to inject SQL and cause problems?

I think as a general point here if you're having teams do security analysis on ODK tools it would be really helpful to share their reports and even better have them involved in discussion on this forum. That way there can be an understanding of what attacks the team is concerned about and there can be a community discussion around if that's something the app might be able to mitigate. I'd argue it's pretty much impossible for any team to guaruntee their codebase is immune to particular classes of attack but it's very possible for them to work with security teams to get to a place where everyone is confident that enough is in place that the app is "good enough" for a use case.

Bear in mind that Collect is a free, open source and available as-is/without warranty. As far as I've seen there isn't any form of ongoing security analysis or pen testing on the code base so could always use contributions from security people :grinning:

3 Likes

The concern is about using MD5 for cryptography purposes. Our team is currently checking some places in Collect app where MD5 is used, and assess that it is not used for cryptography.

In RFC 6151, the IETF suggestion is :

Where the MD5 checksum is used inline with the protocol
solely to protect against errors, an MD5 checksum is still an
acceptable use. Applications and protocols need to clearly state in
their security considerations what security services, if any, are
expected from the MD5 checksum. In fact, any application and
protocol that employs MD5 for any purpose needs to clearly state the
expected security services from their use of MD5.

1 Like

We only have a "not so much detailed" report from the security audit, probably resulting from an automated scan, but I will be happy to share it with you if there is an interest.

FYI, there is also a publicly available report on LGTM for ODK Collect : no SQL injection found there on latest check.

2 Likes

As far as I know that's correct!

Would be interesting! Are you able to share it here on the forum?

I had never seen this site before. Thanks for linking!

here are the conclusions of our team assessment :

For encryption, ODK Collect app implements the ODK XForms specification, and from the specification it's clear that MD5 is only used for computing digests for :

  • computing a seed value when building initialization vectors for AES encryption
  • computing signatures of encrypted records, which are themselves later AES encrypted before saving/sending
  • non-cryptographic checksums in other libraries

As written in specification, the sensitive content (XML file and uploaded files) are encrypted with AES/CFB/PKCS5

2 Likes

security audit.pdf (50.2 KB)

disclaimer : we don't necessarily share conclusions of this document, which is provided "as is"

3 Likes

Thanks so much for sharing! I'll have a look through and see if there is anything that we should raise as an issue on the Collect repo

1 Like

You're welcome.

We've also found an article that explores security and privacy attitudes, practices, and needs within organizations that use Open Data Kit (ODK) :

Cobb, Camille et al. 2016. “Computer Security for Data Collection Technologies.” In Proceedings of the Eighth International Conference on Information and Communication Technologies and Development - ICTD ’16, Ann Arbor, MI, USA: ACM Press, 1–11. http://dl.acm.org/citation.cfm?doid=2909609.2909660 (April 9, 2020).

Hello @seadowg ,
Do you have any updates on the matter?

I am currently in the same situation and would like to know if any conclusions were made regarding security best practices.
In particular:

  • set android:allowBackup to false
  • disable JS in webviews
  • use prepared SQL queries

Please find attached a recent MobSF analysis (05/07/2022) of the latest version of the ODK Collect APK: mobsf_odk_report.pdf (229.0 KB)
Note that the MD5 issue is still reported but is a false positive as stated in this thread.

Best regards,

I'm not sure exactly what you're asking here. Security issues are seen as features (we need to add another of level of security for those who need it like form encryption for example) or bugs (there's a way to use something in Collect maliciously and that needs fixed/changed - no recent examples come to mind) just like any other changes that might need made. When they come up they'd be prioritized alongside everything else.

Thanks for sharing the report! I'm assuming you're asking if these changes can be made. Removing ADB backups (by setting allowBackup to false) and disabling JS in webviews would both cause behaviour changes to the app that might be problematic for some users. I'd suggest creating discussions for these feature changes in the Features section if they're something you require.

As far as solving SQL injection vulnerabilities go (assuming that's what you mean by "use prepared SQL queries") I think we'd need something more specific around an actual potential attack. If you have found ways in which Collect's SQL can be exploited to cause harm in some way then it'd be best to create an issue on Github.

1 Like

Hello, thanks for your reply.

I'm not sure exactly what you're asking here

My post refers mainly to one of your last answers where you state:
"I'll have a look through and see if there is anything that we should raise as an issue on the Collect repo"
Since I am in the same situation as the OP, I was wondering if you had analyzed the security issues highlighted back then, and what were your conclusions.

You answer this question, I think, in the second part of your reply:

Removing ADB backups (by setting allowBackup to false) and disabling JS in webviews would both cause behaviour changes to the app that might be problematic for some users

I definitely get your point given the wide range of ODK Collect custom use cases.
If I may add, this is not a required feature, but part of common security best practices: it will increase end-user overall security (modulo the cases where it is not applicable).

Wouldn't be best for ODK Collect users to customize their application if they need to lower the security level, instead of customizing it to increase it? In any cases I will consider creating a discussion as you suggested.

As for SQL injections, I believe it is a false positive in all of the cases : I looked for every usage of the rawQuery() function, and it uses argument arrays to construct the selection string in almost every cases which effectively prevents from SQL Injection (https://developer.android.com/training/data-storage/sqlite#ReadDbRow). I had one doubt on the org.odk.collect.android.geo.OsmMBTileSource.getInt() function because it takes only the selection query, without arguments, but it is only called with a hardcoded select statement that does not accept parameters.
For the record and to highlight the differences between vulnerable and secure code snipets, you can find an example of code fix on SQLite injections in this osmdroid commit https://github.com/osmdroid/osmdroid/commit/579eda956d83b17bca4e5fe7de7355baeb69f84a.

I hope you can concur with my analysis of the SQL injection issues so that other may refer to it to answer ODK Collect security audits (at least with the current APK release).

Kind regards,

1 Like

It's always good to remember that pretty much any use case of Collect is "custom" seeing as any the main point of interaction, form entry, will have a workflow designed by a form designer who is as much a user as the person filling out the form. I do agree that setting allowBackup to false and disabling JS in webviews might be sensible defaults, however. As you state below, these would be good to start specific discussions about. For both of those, it would need to be considered how disruptive the changes would be to active programmes, and whether the security gains would be worth it (considering the attack vectors that are possible in given the way these are currently set up in ODK Collect).

I concur! As far as I've seen, Collect's SQL all uses standard the SQLite query builders that should give us protection, other than some hardcoded queries (as you point out).