Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : 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 pourcentshook SecKeyWrapper - id getSymmetricKeyBytes NSLog HOOKED getSymmetricKey id theKey pourcentsorig NSLog KEY pourcents , theKey return theKey pourcentsend pourcentsctor NSLog SecKeyWrapper is created. pourcentsinit 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. http developer.apple.com library ios samplecode CryptoExercise Listings Classes_SecKeyWrapper_m.html By leveraging the wrapper it was possible to create an offline script to decrypt the application contents. While looking at sample code I noticed two things. The app developer chose to change Apple s implementation of the getSymmetricKeyBytes method and return a static key. The other interesting discovery was bad practices in Apple s sample code for the doCipher key context padding method. The following code snippet shows that it will use a static IV of 16 bytes of 0x0 s. Initialization vector dummy in this case 0 s. uint8_t iv kChosenCipherBlockSize memset void iv, 0x0, size_t sizeof iv An alternative method to achieve the same result would be to use cycript, which provides a Javascript interpreter to hook run arbitrary objective-c code and also hook into iOS applications at runtime without having to go through the whole Mobile Substrate Tweak creation. The following example shows how cycript could be used to retrieve the symmetric crypto key. rgutie01s-iPad root cycript -p 290cy var sharedwrapper SecKeyWrapper sharedWrapper cy sharedwrapper getSymmetricKeyBytes To recap 1. Runtime analysis can be leveraged to easily break custom encryption when source code is not available and without having to dive into assembly. 2. Developers need to beware of using sample code downloaded from the web, especially crypto code as it s really hard to get right as shown by the sample from Apple .

Les videos sur SecuObs pour les mots clés : runtime hooking





Les derniers articles du site "GDS Blog" :

- When Domain Admin Is Not Enough
- AlienVault OSSIM 4.2 - Enabling Custom Install
- Porting Existing Security Tools to IronWASP Modules
- Avoiding Residual SSH Keys on Ubuntu AMIs
- Using Nessus to Audit VMware vSphere Configurations
- Retrofitting Code for Content Security Policy
- Writing an XSS Worm
- Network Testing 101 If Your Name's Not Down, You're Not Getting In
- Retrieving Crypto Keys via iOS Runtime Hooking
- Exploiting the Pizza Thief

---

S'abonner au fil RSS global de la revue de presse

---