Yes and yes. Check out the sole GIF we've provided. It should show you an example of camelQA navigating user sign up MFA by navigating to the email app through a deep link, verifying the email, navigating back to the app and confirming sign up.
Actually there has been more, e.g. LoanDepot, Inc [1], and then various amended 8-Ks. I’ve been hacking on a side project to parse the 8-K data which is all over the place, including some companies still reporting under old “items” like 8.01 vs the new 1.05 material cybersecurity incident item.
If folks are interested in this space, I just got the mailing list [2] running last night and you can see a list of all the current incidents on my Incident Tracker [3].
I have many more data points I plan on tracking as well as adding 10-K GRC items to the list (potentially helpful for CISOs, other risk managers and investors to eval a companies risk management maturity).
I decided to review SBOMs from about 3,800 popular mobile apps to see if any included vulnerable versions of OpenSSL v3.0.x. No mobile apps did (not surprised) but what did surprise me was 98% of the OpenSSL versions included in these apps were vulnerable to older CVEs. About 16% of the apps included OpenSSL, mostly as a transitive dependency.
> No mobile apps did (not surprised) but what did surprise me was 98% of the OpenSSL versions included in these apps were vulnerable to older CVEs.
Just the openssl version is not enough, since it could be patched to fix vulnerabilities without increasing the version (this is very common on Linux distributions, which often apply security patches instead of migrating to a new version; for instance, Fedora released a patched 3.0.5 instead of going to 3.0.7).
And using an older openssl version does not necessarily mean it's using vulnerable code; according to your blog post, the most common use is SQLCipher, which from a quick look at its README.md seems to use openssl only for the encryption algorithms. Unless the vulnerability was on the basic algorithms used (AES, HMAC, etc), it won't affect this usage.
Static binary analysis looks for the version string but doesn’t currently do deeper analysis of reversed code to see if it’s patched. Could go either way.
And determining if the code is triggered and exploitable is quite challenging. Dynamic analysis can help here, provided you have the coverage.
More generally tho, istm that there will be instances when the version is unpatched and there is some exploitable vector (even if it’s just crashing the app). My hope is to raise awareness for developers (and security) about 1) transitive dependencies and 2) some really old OpenSSL versions in very popular mobile apps. I don’t believe most folks think about this and awareness can lead to shipping safer apps.
We're Chicago-based startup [1] that helps secure mobile apps and devices and recently completed a 12.5m Series A.
If you're interested in mobile security, you can get an idea about our work in a recently vulnerability we helped Samsung patch impacting 200m+ devices. [2]
Over 50% of our company is remote and we're hiring 30+ people this year. If you're interested in mobile and/or security, would love to hear from you. [3]
If you want to easily do traffic inspection and forensic analysis of stored data for iOS and Android, you can check out the free Community Edition of our mobile app testing lab [1].
