Failed to identify source code vulnerabilities about qark HOT 5 CLOSED

We intentionally did not add this functionality to QARK, largely due to the high likelihood of false positives.

Lack of certificate pinning is not a vulnerability by itself, since it does not directly result in an exploitable condition. It should be considered as more of a best practice.

If you would like to submit a pull request we'd be happy to review it. Otherwise, if you feel you have a list of particularly interesting strings to search for, which are not likely to result in a high false positive rate, we'd happily review it for possible inclusion in an upcoming version.

from qark.

Of course no exploitation is possiblebut no cert pinning makes possible mitm and it brings to a confidentiality loss (that's important for a mobile device). imho qark should have plugins to let people add checks at runtime like this one. What do you think?

from qark.

We have recently added a feature to allow for running custom plug-ins. If you would like to create a plug-in for checking for certificate pinning, or any other types of custom check, I would suggest starting here: https://github.com/linkedin/qark/wiki/Plugins

Lack of certificate pinning does not make MitM possible and therefore, is not a vulnerability. It just changes who/where an attacker has to steal/forge the crypto from.

Certificate pinning is designed to protect against CA compromises and/or rogue CAs. No matter how you pin, you are simply shifting the burden of protecting the certificate signing infrastructure and crypto from one party to another. This generally entails removing trust for one or more CAs and relying solely on your organization's internal security.

from qark.

Certificate pinning is a countermeasure for MitM.

from qark.

We have a method for running custom plug-ins, so if you want to write something to check for it, feel free.

You can call pinning whatever you'd like, but if an app doesn't implement certificate pinning, there is still no way to perform a MitM attack, against someone else, without stealing the associated crypto or creating new, valid crypto, in an otherwise secure system.

This is a well established opinion, supported by numerous parties, including Google:
https://www.nowsecure.com/blog/2014/07/17/when-a-vulnerability-is-not-really-a-vulnerability/

https://threatpost.com/lack-of-certificate-pinning-exposes-encrypted-ios-gmail-app-communication/107154/

https://developer.android.com/training/articles/security-ssl.html#Pinning

Perhaps reviewing the OWASP documentation will help clear up any misconceptions about what pinning actually does: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

from qark.