lcimeni / youtube

0 stars 0 forks source link

NowSecure dynamic analysis: Failure to Validate Certificate Authority Allows Data to be Exposed and Modified Remotely #448

Open lcimeni opened 3 years ago

lcimeni commented 3 years ago

Finding Description

The application does not properly validate the Certificate Authority (CA) for the implemented certificate. CAs vouch for the authenticity of a website by verifying the registration of the site's domain name and the company/organization behind it. If the certificate's CA data is not properly validated, a malicious actor could create an invalid certificate by utilizing any CA, effectively making the app susceptible to an Man-in-the-Middle attack. This type of attack gives the culprit the ability to capture, view, and modify traffic sent and received between the app and the server. Impacted URLs are listed in the table below.

Steps to Reproduce

There are several tools a developer can use to evaluate network issues from the a mobile app perspective. One tool that is useful for troubleshooting these process is Android Studio's Network Profiler: https://developer.android.com/studio/profile/network-profiler. Another option is to use Mitmproxy, a web proxy designed to help developers troubleshoot and test their apps: https://mitmproxy.org/.

Business Impact

Applications with this vulnerability will experience a substantially larger risk to data integrity and confidentiality. When certificate validation is not performed, an attacker will be able to observe the data sent by users and modify what they send and receive from the backend. This can lead to stolen user information and malicious changes to the app.

Remediation Resources

Recommended Fix

While SSL/TLS was observed protecting the application's sensitive data in transit, issues relating to improperly validating the TLS handshake were discovered due to a lack of proper certificate authority validation.

Properly validate the SSL/TLS certificate to ensure it is signed by a trusted certificate authority (CA) as well as contains the correct hostname. More details and code snippets can be found at https://developer.android.com/training/articles/security-ssl or https://developer.android.com/training/articles/security-config for Android.

For applications that must include compromised Certificate Authorities and experience complex phishing attacks against their users, additional security controls may be necessary to provide network protections. One such approach is to use certificate pinning to mitigate the possibility of SSL/TLS weaknesses. Certificate pinning ensures that the client checks the server's certificate against a known copy of that certificate. Bundling the server's certificate inside the application and ensuring any SSL/TLS requests first validate that the server's certificate exactly matches the bundle's certificate is a method of accomplishing certificate pinning.

For some apps, certificate pinning may be impossible to perform. If the app allows users to enter in their own domain names to connect to services, then no opportunity exists to embed a certificate. However, if the app is intended to connect to a known server or set of servers, all of the information is available to guarantee that the client is indeed talking directly to the server and without a man in the middle eavesdropping. Please note that certificate pinning may not be suitable for organizations who can not control the server side certificate used in TLS validation or are not able to perform the certificate rotations in a timely manner to accommodate certificate expiration requirements.

Details and code snippets can be found at https://developer.android.com/training/articles/security-ssl.

Certificate transparency is an alternative to certificate pinning that can also be used to accomplish similar security protections without the same operational work. Certificate transparency is used to audit that a certificate has been issued legitimately by a certificate authority. This method prevents scenarios where a certificate was issued to a malicious actor of a domain the attacker does not own. Additional information can be found at https://github.com/babylonhealth/certificate-transparency-android.

Code Samples

Bad Code Sample (.kotlin)

fun trustEveryone() {
try {
HttpsURLConnection.setDefaultHostnameVerifier { hostname, session -> true }
var context = SSLContext.getInstance("TLS")
context.init(null, arrayOf<X509TrustManager>(object : X509TrustManager {
@Throws(CertificateException::class)
override fun checkClientTrusted(chain: Array<X509Certificate>,
authType: String) {
}

@Throws(CertificateException::class)
override fun checkServerTrusted(chain: Array<X509Certificate>,
authType: String) {
}

override fun getAcceptedIssuers(): Array<X509Certificate> {
return arrayOf()
}
}), SecureRandom())
HttpsURLConnection.setDefaultSSLSocketFactory(
context.socketFactory)
} catch (e: Exception) {
e.printStackTrace()
}
} // call this function anywhere within the application lifecycle, such as activity's onCreate method

Good Code Sample (.kotlin)

val url = URL(""someUrl.org"")
val urlConnection: URLConnection = url.openConnection()
val inputStream: InputStream = urlConnection.getInputStream() // throws a certification error if certificate is invalid
copyInputStreamToOutputStream(inputStream, System.out)

Additional Guidance

Risk and Regulatory Information

Severity: high CVSS: 7

Application

See more detail in the NowSecure Report