Check if Android/iOS Apps are implementing SSL properly

[Nikhil Chopra]

My motive is to debug phone apps(iOS/Android) and find out if they are implementing SSL/TLS properly.

I want Fiddler to provide fake certificate to the phone app on the fly, and check if the app is properly implementing SSL (hostname verification and certificate validation).

Fake certificate can be similar to original certificate but signed from a untrusted CA.

I do Not want phone to install trusted root CAs in this process, because if the fake CA is made trusted, then app would be doing its job of certificate checking i.e. if the certificate is signed by a Trusted Root CA, properly.

So if the app accepts any fake certificate, fiddler should be able to decrypt HTTPS messages without installing fiddler root certificate in the client (phone).

Presently, Fiddler does not even show HTTPS messages without installing root certificate on the phone.

Please let me know how fiddler can help me to this and what steps I should follow.

[Eric Lawrence]

> Presently, Fiddler does not even show HTTPS messages without 

> installing root certificate on the phone.

Nah. What actually happens is that the phone tries to establish a connection through Fiddler using a CONNECT tunnel. 

Fiddler returns its certificate that chains to the FiddlerRoot, and the application (which properly checks the trust chain for the certificate) closes the connection. Look at Fiddler's LOG tab to see whether it closes the connection with a formal HTTPS Error Fatal Alert code, or whether it simply closes the connection without issuing any requests.

If the application isn't validating certificates correctly, the CONNECT tunnel will be followed with one or more HTTPS requests.

[Nikhil Chopra]

So I followed these steps:

Routed the phone traffic to fiddler

No fiddler root certificate installed on phone

Run target app on my phone

Observed the logs in the LOGS tab

This is the output:

14:50:09:1173 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < An unknown error occurred while processing the certificate for pipe (CN=*.cvs.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).

14:50:09:2267 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < An unknown error occurred while processing the certificate for pipe (CN=*.cvs.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).

14:50:10:2737 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < An unknown error occurred while processing the certificate for pipe (CN=*.cvs.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).

My obeservation is that the packets are being dropped, and connection is not being established with original server.

So, we can say that app is correctly checking if the certificate is signed by root CA or not because in this case, fiddler Ca is NOT trusted by the app and app drops the connection. Please Correct me if I am wrong.

So, now I want to check if the app is verifying Hostname properly. So, what I want is to generate a certificate signed by fiddler CA with random Common Name, and now I can add fiddler certificate to the trusted list of CAs in the phone.Then use that generated Certifcate to decrypt HTTPS messages. How can I go ahead with this.

[Eric Lawrence]

>  fiddler Ca is NOT trusted by the app and app drops the connection.

Yup. You could trust the CA temporarily and verify that the connection succeeds (or continues to fail, meaning that the app is using certificate pinning or you're on Android 7 ). Related: https://textslashplain.com/2015/06/27/testing-https-in-native-apps/

After trusting the certificate, you can get Fiddler to return a certificate with a mismatched hostname by clicking Rules > Customize Rules and scrolling to the OnBeforeRequest handler:

    static function OnBeforeRequest(oSession: Session) {

       if (oSession.HostnameIs("server.app.example.com"))

        oSession["X-overridecertCN"]= "some.fake.thing";

[Nikhil Chopra]

Thank you for suggesting this solution. This worked for me. I can observe this in the logs that certificate with CN=com.fake.thing is being used.

My concern is that how can I manually verify if Fiddler is using a certificate with CN=com.fake.thing for each packet, just to be sure. 

Is this feature incorporated in Fiddler that we can see the certificate used to decrypt each packet?

Please let me know your inputs.

Thanks

[Eric Lawrence]

> can see the certificate used to decrypt each packet?

HTTPS doesn't quite work like that. Certificates are used only in the initial handshake to negotiate a shared (symmetric) secret that is used for encryption by a bulk cipher (e.g. AES). By the time you're at the point of encrypting raw packets, the certificates are no longer involved at all.

The simplest thing you can do to verify that your interception certificates have the wrong hostname is to use the browser (e.g. Chrome) to visit sites through Fiddler in the configuration where you're overriding the hostname. Chrome will warn you about the certificate error if Fiddler is correctly mangling the hostnames.

Beyond that, the only thing you could really do is watch all traffic with a lower-level monitor (e.g. Wireshark) and painstakingly examine every handshake to verify that all of them are using the Fiddler-generated certificates containing the bogus hostname.

[Nikhil Chopra]

I am facing some issues with this approach to test bad hostname verification. I am testing the apps with no hostname verification implementation, still by adding the line: 

oSession["X-overridecertCN"]= "some.fake.thing";

still I am not able to decrypt the SSL connection.

My main target is to test the apps if they are implementing certificate validation and hostname verification.

Let me know if there is way, fiddler can help me with this.

[Eric Lawrence]

It's not clear what you're asking. If you return a fake CN (e.g. "some.fake.thing") any properly-functioning client application will detect that invalid certificate and refuse to send any requests over the connection. As a consequence, there's nothing to decrypt, because the client doesn't send a request, and the server (in the absence of a request) doesn't send a reply.

You'll only ever see decrypted traffic on a connection with the wrong certificate if a buggy client fails to properly validate the certificate and sends its request anyway.

[Nikhil Chopra]

My situation is:

I am aware of the fact that my client application is not validating hostname. so, in that case, When I am giving it some.fake.thing as the hostname, Ideally it should accept the request (since its not doing hostname verification) and fiddler should decrypt the request.

But, fiddler is not showing any request. We are 100% sure of that .

[Eric Lawrence]

Let's step back: If you don't set the Session Flag to override the hostname with something mismatched, what happens?

[Nikhil Chopra]

Then I am able to establish the connection, and decrypt the packets in Fiddler

[Eric Lawrence]

It then sounds like your client is performing hostname validation, whether you expected it to or not. Why are you so sure it does not?

[Nikhil Chopra]

I am sure of this because I developed a dummy app with bad hostname verification implementation.

Is it possible for the device(or the android OS) on which the app is running to add these security features to packets going out. Recently, in my Nexus 5X after Nougat upgrade I have noticed that I am not able to decrpyt the packets without even setting the Session flag to override the hostname, whereas for others phones its working fine.

[Eric Lawrence]

On most mobile platforms, yes, you have to go out of your way to avoid using the system implementation of certificate validation, which can apply its own checks.

Android 7.0 no longer trusts user-installed certificate roots by default; you have to edit your application manifest to allow such roots. See: https://textslashplain.com/2016/07/27/using-fiddler-with-ios-10-and-android-7/

[Nikhil Chopra]

Is SSL renegotiation attack possible using Fiddler?

[Eric Lawrence]

Not really, no. Fiddler may have the necessary primitives (it offers byte-level control of the sockets) but it doesn't offer any straightforward means to execute the attack.

[Nikhil Chopra]

Can you tell me how to override SubjectAltName extension of type dNSName in the certificate presented by fiddler.

Since till now we were overriding the CommonName by writing overrideCertCN = "some.fake.thing", I came to know that checking common name for server verification is deprecated. Most of the apps now check subjectAltName in the server certificate.

please let me know how to do it. 

Regards,

Nikhil Chopra 

[EricLaw]

The makecert generator for Fiddler cannot set the subjectAltName field and thus it sets only the SubjectCN field.

The other Fiddler certificate generators (CertEnroll and BouncyCastle) set both the SubjectCN and the subjectAltName to the same value (either the default correct value, or whatever override you specify via the session flag).

[Nikhil Chopra]

Thanks for the quick revert Eric.

I would appreciate if you can let me know from where I can set subjectAltName in the certEnroll Engine.

As far as I have checked, I am generating certificates using cert Enroll Engine only as in the Certifcate Creation Preferences screen - Engine : CertEnroll is selected and use Wildcards is selected. Please see the image.

So, please let me know what I have to write in Rules in addition to overrideCertCN , to override subjectAltName also. Thanks.

[Eric Lawrence]

The point is that you don't have to do anything differently if you're using CertEnroll or BouncyCastle. Any value you set for oSession["X-overridecertCN"] gets used for both the SubjectCN and the SubjectAltName. You can easily verify this in your browser-- just enable Fiddler, go to https://example.com, and click the lock icon in IE and choose "View Certificate". Go to the second tab and scroll down to view the Subject Alternative Name field.

[Nikhil Chopra]

Okay Thanks. 

How to change the expiration date of the certificates generated by CertEnroll. I want to present expired certificates via Fiddler to the apps, so that I can check if the apps are checking expiration dates of the certificates. Please let me know how to do this.

[Eric Lawrence]

If you're using the default certificate generator, you use QuickExec as follows:

   prefs set fiddler.certmaker.GraceDays 366

(Sets the certificate's ValidFrom date to 366 days ago)

   prefs set fiddler.certmaker.ValidDays -10

(Sets the certificate's ValidTo date to 10 days ago)