Certificate Pinning

Applications put constraints on the certificates used for verification (Trusted Roots).

  • They fix (Pin) a certificate/ pub key/ hash to a hostname.

  • Validation of the host authenticity (in TLS) will also include this additional constraint.

Impact

A Trusted Root can be injected but it will be ignored.

  • The application will simply not use it, or the application will have additional checks to detect the injection.

Approaches

Applications extend the X509TrustManager, overriding the checkServerTrusted method, with custom checks.

  • E.g the Certificate/ Public Key/ hash is hard coded, and this value is used to validate the certificate.

Using a KeyStore with a predefined list of certificates, ignoring other sources.

  • Pins the host certificate.

  • Pins an intermediate Certification Authority.

  • Pins a Root Certification Authority.

Pinning may create issues for developers as changes to certificates or PKI must be reflected in the applications.

  • Soft Fail: just let the application work, even if with limited functionality.

  • Hard Fail: an update is forced for the application to work.

Circumvention

If restricted KeyStores are used, use an emulator or rooted device.

  • Enables free manipulation of the keystores, injecting custom certificates.

  • Inject certificates into the system keystores.

If Pinned with hard-coded information, modify the application.

  • Unpack the application.

  • Edit the code, change the Pin or remove it.

    • smali maybe enough and full decompilation to Java is not required.

  • Repack and install the application.

Last updated