Selected Areas in Security & Privacy: Building Secure Mobile Applica:ons (SMA)

Transcription

1 Selected Areas in Security & Privacy: Building Secure Mobile Applica:ons (SMA) Prof. Dr. rer. nat. Dogan Kesdogan Dipl.- Inform. Mohamed Bourimi University of Siegen, Chair for IT Security, Germany

2 Overview ios PlaGorm Security Development Best Prac:ces Summary

3 Where we are now? Cross-cutting concerns such as Usability/User experience, Performance, Integration, Inter-operability, Group Awareness, etc. Application Layer Design of Privacy App Architecture Emulation Rendering Virtual Machines Android ios OS Layer Compiler & language capabilities Network Access File System Access HW

4 The iphone Mobile Pla3orm (Dwivedi et al. 2010) Perhaps the most influencal mobile device to enter the market in recent years is Apple s iphone. Because of its use of ObjecCve- C, development on the iphone carries the risk of security flaws tradiconally associated with C sooware (classic C vulnerabilices).

5 The iphone Mobile Pla3orm (Dwivedi et al. 2010) However, some of these are masked by the high- level Cocoa Touch APIs, and therefore require special ajen:on (Apple has rela:vely lijle documenta:on available on security best prac:ces in comparaison to HCI guidelines)!

6 The iphone Mobile Pla3orm (Dwivedi et al. 2010) Both the iphone and Mac OS X share the usage of ObjecCve- C and a large part of the Cocoa API. However, a number of components worth nocng are missing or have been changed on the iphone s Cocoa implementacon (Cocoa Touch). Although complete support of Core Data API and Garbage Collec:on are scll absent in the mobile ios (Security!) Some C vulnerabilices: Buffer Overflows and Integer Overflows Format String AYacks

7 C vulnerabilices: Buffer Overflows The buffer overflow is one of the oldest and most well- known exploitable bugs in C. At their most basic level, buffer overflows occur when data is wriyen into a fixed- size memory space, overflowing into the memory around the descnacon buffer (gives an ayacker control over the contents of process memory, potencally allowing for the insercon of hoscle code).

8 C vulnerabilices: Buffer Overflows Although the iphone has some built- in preventacve measures to prevent buffer overflow exploitacon (avoid manual memory management en:rely, and use Cocoa objects such as NSString for string manipula:on), exploits resulcng in code execucon are scll possible (see hyp:// europe- 09/Miller_Iozzo/ BlackHat- Europe Miller- Iozzo- OSX- IPhone- Payloads- whitepaper.pdf).

9 C vulnerabilices: Integer Overflows An integer overflow occurs when a computed value is larger than the storage space it s assigned to. This ooen happens in expressions used to compute the allocacon size for an array of objects because the expression is of the form object_size x object_count. If n is larger than 1 billion (when sizeof(int) is 4), the computed value of sizeof (*x) * n will be larger than 4 billion and will result in a smaller value than intended. This means the allocacon size will be unexpectedly small. When the buffer is later accessed, some reads and writes will be performed past the end of the allocated length, even though they are within the expected limits of the array.

10 C vulnerabilices: Format String AYacks and Double Frees Format string vulnerabilices are caused when the programmer fails to specify how user- supplied input should be formayed, thus allowing an ayacker to specify their own format string. Apple s NSString class does not have support for the %n format string, which allows for wricng to the stack of the running program. C and C++ applicacons can suffer from double- free bugs, where a segment of memory is already freed from use and an ayempt is made to deallocate it again. Typically, this occurs by an extra use of the free() funccon, aoer a previously freed memory segment has been overwriyen with ayacker- supplied data. This results in ayacker control of process execucon. In its most benign form, this can simply result in a crash.

11 Review: iphone Devlopment Develop Test Distribute

12 ios Development VulnerabiliCes Development for the iphone/ios is performed with Xcode and the ios SDK. Code can be run either within the emulator or on a development device (restriccon!). Developing encrypcon funcconality or such funcconality using so- called Keychains or cercficates needs a real device for debugging! ObjecCve- C applicacons decompile fairly cleanly, if you have the right tools (Many Apple developers may be familiar with otool (also proted to ARM), which comes with the OS X developer tools).

13 Further ios Development VulnerabiliCes Example: For versions of the iphone OS 3.x/4.x), you can use the class- dump or class- dump- x tools ( hyp://iphone.freecoder.org/classdump_en.html; also available in Cydia and in MacPorts for OS X) to get very readable informacon on class declaracons and structs from ObjecCve- C object code. For most cases, you ll want to use a jailbroken phone and then ssh into the device to use the iphone version of class- dump- x and/or otool. Another tool that expands on the output of class- dump by resolving addiconal symbols is otx (hyp://otx.osxninja.com).

14 Further ios Development VulnerabiliCes How to prevent reverse engineering of ios Apps? The answer is quite simply: You can t do much. L If someone is mocvated to crack or reverse- engineer your applicacon, they can use far more powerful commercial tools than these to make doing so even easier. But you could make it harder J 1. The development effort required to prevent reverse- engineering costs money, especially if you have to revise your proteccon or obfusca:on mechanisms. 2. Try to hide from some of the aforemenconed mechanisms such as class- dump by pulng your logic into plain C or C++ and ensuring that you strip your binaries.

15 Further ios Security VulnerabiliCes IMEI forwarding can not be easy disabled in ios! Many arccles affirm that ios Apps send IMEI and other sensicve data to CuperCno L (Apple, however, restricted the access to the IMEI in recent ios versions). Apple s Privacy Policy has to be accepted (periodically updated) and Credit Card data have to be communicated to Apple in order to be able to use the App Store (SoluCon for Germany by using third- party payment provider now possible)! Apple has implemented nocficacon services for third- party apps as well as opened up formerly proprietary funcconality (such as the ipod library access) to third- party developers.

16 Summary More generally, it has been speculated that the iphone OS and Mac OS X will gradually merge in the future, as mobile hardware becomes more capable. Under pressure from new contenders such as Android, Apple s Development Agreements will become flexible (and perhaps the followed restriccve philosophy) Many vulnerabilices of the ios mobile pla3orm are due to the underlying C language. Some issues can be solved some not! However, there are many best praccces ;- )