Retrieving Crypto Keys via iOS Runtime Hooking

[Nytro]

Retrieving Crypto Keys via iOS Runtime Hooking

Tuesday, March 5, 2013 at 8:45AM

I am going to walk you through a testing technique that can be used at runtime to uncover security flaws in an iOS application when source code is not available, and without having to dive too deeply into assembly. I am going to use a recent example of an iOS application I reviewed, which performed its own encryption when storing data onto the device. These types of applications are a lot of fun to look at due to the variety of insecure ways people implement their own crypto. In this example the application required authentication, and then pulled down some data and stored it encrypted on the device for caching. The data was presented to the user where they could “act” upon it. Sounds pretty generic, but hopefully the scenario is familiar enough to those who assess mobile apps.

Upon analyzing the application traffic, it was obvious that no crypto keys were being returned from the server. After sweeping the iOS Keychain and the entire Application container, I could make the educated assumption that the key is either a hardcoded value or derived using device specific information.

Using the Hopper Disassembler (Available on the Mac App Store), I was able to see that the application was leveraging the Common Crypto library for its encryption. I checked the cross-references for calls to the CCCryptorCreate function in order find the code areas which perform encryption. The following screenshot shows getSymmetricKeyBytes being called right before the CCCryptorCreate function. I felt pretty confident that the purpose of the getSymmetricKeyBytes method was going to be to return the symmetric key used for encryption.

I decided to create a Mobile Substrate tweak in order to hook into getSymmetricKeyBytes and read the return value. I used the class-dump-z tool to get a listing of all the exposed Objective-C interfaces. From here it is easy to get more detailed information about the method, such as the class name, return type and any required parameters. The following is a short snippet retrieved from the class-dump-z results.

    @interface SecKeyWrapper : XXUnknownSuperclass {

                      NSData* publicTag;

                      NSData* privateTag;

                      NSData* symmetricTag;

                      unsigned typeOfSymmetricOpts;

                      SecKey* publicKeyRef;

                      SecKey* privateKeyRef;

                      NSData* symmetricKeyRef;

    }

    [..snip..]

    -(id)getSymmetricKeyBytes;

    -(id)doCipher:(id)cipher key:(id)key context:(unsigned)context padding:(unsigned*)padding;

     [..snip..]

We can quickly create a tweak by using the Theos framework. The tweak in this case looked as follows:

    %hook SecKeyWrapper

    - (id)getSymmetricKeyBytes {

        NSLog(@”HOOKED getSymmetricKey”);

        id theKey = %orig;

        NSLog(@”KEY: %@”, theKey);

        return theKey;

    }

    %end



    %ctor {

        NSLog(@”SecKeyWrapper is created.”);

        %init;

    }

It doesn’t do much more then read the return value of the original method call and write it out to the console. It was possible to confirm that a static key was being used by running the tweak on another iPad, and observing that the same symmetric key was returned. The next step was to decrypt the files. We could hook into the doCipher:key:context:padding method and just print out the first parameter to get the plaintext data. That would work, but that wouldn’t be reproducible since the Tweak code would only execute when the doCipher:key:context:padding method is actually run by the application. A quick Google search on the SecWrapper class turned up the following sample code from Apple.

Sursa: GDS Blog - GDS Blog - Retrieving Crypto Keys via iOS Runtime Hooking