Skip to content

Latest commit

 

History

History
208 lines (130 loc) · 13.3 KB

0x06e-Testing-Cryptography.md

File metadata and controls

208 lines (130 loc) · 13.3 KB
Raw

Testing Cryptography

Verifying Cryptographic Key Management

Overview

Proper cryptographic key management is often one of pitfalls of mobile applications. Although, the platform provides standard system APIs like Keychain, sometimes developers seem to either not use it at all, or use it improperly.

Static Analysis

During static analysis, the most important part is to understand how the application is using cryptographic algorithms. Let us divide applications into three main categories:

  1. An application is a pure online application, where authentication, authorization is done online with application server and no information is stored locally.
  2. An application is mainly an offline application, where authentication and authorization is done purely locally. Application information is stored also locally.
  3. An application is a mixture of the first two, i.e. it supports both: online and offline authentication, some information may be stored locally and some or all actions that are performed online may be performed offline.
    • A good example of such an app, may be point of sale (POS), where seller may sell products. The app requires connection to the internet, so that it can communicate with backend and update information on products that were sold, cash amount, etc. However, there might be a business requirement that this app must also work in offline mode and would synchronize all information once it connects back to the internet. This will be a mixed app type, i.e. online and offline.

The following checks would be performed in the last two app categories:

  • Ensure that no keys/passwords are hardcoded and stored within the source code. Pay special attention to any 'administrative' or backdoor accounts enabled in the source code. Storing fixed salt within application or password hashes may cause problems too.
  • Ensure that no obfuscated keys or passwords are in the source code. Obfuscation is easily bypassed by dynamic instrumentation and in principle does not differ from hardcoded keys.
  • If the application is using two-way SSL (i.e. there is both server and client certificate validated) check if:
    • the password to the client certificate is not stored locally, it should be in the Keychain
    • the client certificate is not shared among all installations (e.g. hardcoded in the app)

A proper way would be to generate the client certificate upon user registration/first login and then store it in the Keychain.

  • Ensure that the keys/passwords/logins are not stored in application data. This can be included in the iTunes backup and increase attack surface. Keychain is the only appropriate place to store credentials of any type (password, certificate, etc.).
  • Ensure that keychain entries have appropriate protection class. The most rigorous being kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly which translates to: entry unlocked only if passcode on the device is set and device is unlocked; the entry is not exportable in backups or by any other means.

The following checks would be performed in the offline application:

  • if the app relies on an additional encrypted container stored in app data, ensure how the encryption key is used;
    • if key wrapping scheme is used, ensure that the master secret is initialized for each user, or container is re-encrypted with new key;
    • check how password change is handled and specifically, if you can use master secret or previous password to decrypt the container.

Dynamic Analysis

-- TODO [Describe how to test for this issue "Verifying Cryptographic Key Management" by running and interacting with the app. This can include everything from simply monitoring network traffic or aspects of the app’s behavior to code injection, debugging, instrumentation, etc.] --

Remediation

-- TODO [Describe the best practices that developers should follow to prevent this issue "Verifying Cryptographic Key Management".] --

References

OWASP Mobile Top 10 2016
OWASP MASVS
  • V3.1: "The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption."
  • V3.5: "The app doesn't re-use the same cryptographic key for multiple purposes."
CWE
  • CWE-320: Key Management Errors
  • CWE-321: Use of Hard-coded Cryptographic Key
Info
Tools

-- TODO [Add link to relevant tools for "Verifying Cryptographic Key Management"] --

Testing for Custom Implementations of Cryptography

Overview

The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has been protected. Well-known techniques may exist to break the algorithm.

Static Analysis

Carefully inspect all the cryptographic methods used within the source code, especially those which are directly applied to sensitive data. Pay close attention to seemingly standard but modified algorithms. Remember that encoding is not encryption! Any appearance of bit shift operators like exclusive OR operations might be a good sign to start digging deeper.

Dynamic Analysis

Although fuzzing of the custom algorithm might work in case of very weak crypto, the recommended approach would be to decompile the IPA and inspect the algorithm to see if custom encryption schemes is really the case (see "Static Analysis").

Remediation

Do not develop custom cryptographic algorithms, as it is likely they are prone to attacks that are already well-understood by cryptographers.

When there is a need to store sensitive data, use strong, up-to-date cryptographic algorithms. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. The Keychain is suitable for storing sensitive information locally[1].

References

OWASP Mobile Top 10 2016
OWASP MASVS
  • V3.2: "The app uses proven implementations of cryptographic primitives"
CWE
  • CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Info

Verifying the Configuration of Cryptographic Standard Algorithms

Overview

Apple provides libraries with implementations of most commonly used cryptographic algorithms. A good point of reference is Apple's Cryptographic Services Guide [1]. It contains broad documentation on how to use standard libraries to initialize and use cryptographic primitives, which is also useful when performing source code analysis. For dynamic testing, more useful is native C API, for instance CommonCryptor, that is most frequently used when performing cryptographic operations. Source code is partially available at the Apple open source repository[2].

Static Analysis

The main goal of static analysis is to ensure the following:

  • Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
  • Key lengths are in-line with industry standards and provide protection for sufficient amount of time. An online comparison of different key lengths and protection they provide taking into account Moore's law is available online[3].
  • Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.

If the app is using standard cryptographic implementations provided by Apple, the easiest way is to decompile the application and check for calls to functions from CommonCryptor, such as CCCrypt, CCCryptorCreate, etc. The source code[5] contains signatures of all functions. For instance, CCCryptorCreate has following signature:

CCCryptorStatus CCCryptorCreate(
	CCOperation op,             /* kCCEncrypt, etc. */
	CCAlgorithm alg,            /* kCCAlgorithmDES, etc. */
	CCOptions options,          /* kCCOptionPKCS7Padding, etc. */
	const void *key,            /* raw key material */
	size_t keyLength,
	const void *iv,             /* optional initialization vector */
	CCCryptorRef *cryptorRef);  /* RETURNED */

You can then compare all the enum types to understand which algorithm, padding and key material is being used. Pay attention to the keying material, if it's coming directly from a password (which is bad), or if it's coming from Key Generation Function (e.g. PBKDF2). Obviously, there are other non-standard libraries that your application might be using (for instance openssl), so you should check for these too.

Dynamic Analysis

-- TODO [Describe how to test for this issue "Verifying the Configuration of Cryptographic Standard Algorithms" by running and interacting with the app. This can include everything from simply monitoring network traffic or aspects of the app’s behavior to code injection, debugging, instrumentation, etc.] --

Remediation

-- TODO [Describe the best practices that developers should follow to prevent this issue "Verifying the Configuration of Cryptographic Standard Algorithms".] --

References

OWASP Mobile Top 10 2016
OWASP MASVS
  • V3.3: "The app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices."
  • V3.4: "The app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes."
CWE

-- TODO [Add relevant CWE for "Verifying the Configuration of Cryptographic Standard Algorithms"] --

  • CWE-312 - Cleartext Storage of Sensitive Information
Info
Tools

-- TODO [Add links to relevant tools for "Verifying the Configuration of Cryptographic Standard Algorithms"] --

Testing Random Number Generation

Overview

-- TODO [Provide a general description of the issue "Testing Random Number Generation".] --

Static Analysis

-- TODO [Describe how to assess this given either the source code or installer package (APK/IPA/etc.), but without running the app. Tailor this to the general situation (e.g., in some situations, having the decompiled classes is just as good as having the original source, in others it might make a bigger difference). If required, include a subsection about how to test with or without the original sources.] --

-- [Confirm purpose of remark "Use the <sup> tag to reference external sources, e.g. Meyer's recipe for tomato soup[1]."] --

-- TODO [Add content for "Testing Random Number Generation" with source code] --

Dynamic Analysis

-- TODO [Describe how to test for this issue "Testing Random Number Generation" by running and interacting with the app. This can include everything from simply monitoring network traffic or aspects of the app’s behavior to code injection, debugging, instrumentation, etc.] --

Remediation

-- TODO [Describe the best practices that developers should follow to prevent this issue "Testing Random Number Generation".] --

References

OWASP Mobile Top 10 2016
OWASP MASVS
  • V3.6: "All random values are generated using a sufficiently secure random number generator."
CWE

-- TODO [Add relevant CWE for "Testing Random Number Generation"] --

  • CWE-312 - Cleartext Storage of Sensitive Information
Info
Tools

-- TODO [Add links to relavant tools for "Testing Random Number Generation"] --