RSS

BREACH Attack Explained

Back in 2012, when Juliano Rizzo and Thai Duong announced the CRIME attack, TLS / SSL Compression attack against HTTPS, the ability to recover selected parts of the traffic through side channel attacks has been proved. This attack was mitigated by disabling the TLS / SSL level compression by most of the browsers. This year at Black Hat, a new attack called BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) was announced which commanded the attention of entire industry. This presentation which came up with the title “SSL Gone in 30 seconds” is something that is not properly understood and hence there seems to be some confusion about how to mitigate this. So I felt this article would give some detailed insight into how notorious the attack is, how it works, how practical it is and what needs to be done to mitigate it. So let’s proceed and have a look at the same.

BREACH Attack:

Unlike the previously known attacks such as BEAST, LUCKY etc, BREACH is not an attack against TLS. BREACH is basically an attack against the HTTP. If you are familiar with the famous Oracle Padding attack, BREACH is somewhat easy to understand. A BREACH attack can extract login tokens, email addresses or other sensitive information from TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted). The attacker just needs to trick the victim to visit a malicious link for executing the attack. Before going into the details, let me explain a little bit more about the basic things to know. Web pages are generally compressed before the responses are sent out, which is called HTTP Compression, primarily to make better use of available bandwidth and to provide greater transmission speeds. Browser usually tells the server (through ‘Accept-Encoding’ header), what compression methods it supports and server accordingly compresses the content and sends it across. If the browser does not support any compression then the response is not compressed. The most commonly used compression algorithms are gzip and deflate.

Accept-Encoding: gzip, deflate

When the content arrives, it is uncompressed by the browser and processed. So basically with SSL enabled web sites, the content is first compressed, then encrypted and sent. But you can determine the length of this compressed content even when it’s wrapped by SSL.

How it works?

The attack primarily works by taking leverage of the ‘compressed size’ of the text when there are repetitive terms. So here is a small example which explains how deflate takes advantage of repetitive terms to reduce the compressed size of the response.

1. Consider the below search page which is present after logging into this site:

http://www.ghadiwala.com/catalogsearch/result/?q=

Breach example - search page

2. Observe that the text highlighted in red box is the username. Now enter any text (say ‘random’) and click search.

URL: http://www.ghadiwala.com/catalogsearch/result/?q=random

Breach example - search page2

3. So you can control the response through the input parameter in the URL. Now imagine what if the search term is ‘Pentesting’ (which is the username in this case).

URL:  http://www.ghadiwala.com/catalogsearch/result/?q=Pentesting

Breach example - search page3

Now when deflate algorithm is compressing the above response, it finds that the term ‘Pentesting’ is repeated more than once in the response. So instead of displaying it second time the compressor says ‘this text is found 101 characters ago’. So this reduces the size of the compressed output. In other words, by controlling the input search parameter you can guess the username. How? The compressed size would be least when the search parameter matches the username. This concept is the base for the BREACH attack.

Practical Attack:

Now let us see how an attacker would practically exploit this issue and steal any sensitive information. Consider the below site and assume a legitimate user has just signed in.

Breach Sample search page

[Before signing in to the application]

Breach Sample search after login

[Search page which is accessible after logging in]

As shown in the above figure, also assume that there is some sensitive data which is present in the Search page for example let card number be one such sensitive data in the application. When the user searches for something (say ‘test’) below is the message displayed.

Breach Sample search page2

Now an attacker, using all the social engineering techniques, could lure this currently signed in user to click on a link. The link would be simple html page that has a JavaScript in it which will request searches continuously for search terms ‘100-1000’. For example the JavaScript would request the below URL’s.

http://localhost/demo/Search?p=100

http://localhost/demo/Search?p=101

………

http://localhost/demo/Search?p=10000

Now the attacker can also get the corresponding compressed sizes of the responses for each of these requests. Can you guess why the compresses sizes for each of these responses would differ and can you guess which request would have the smallest compressed size? Below would be the request with the smallest compressed sizes.

http://localhost/demo/Search?p=4545

http://localhost/demo/Search?p=5454

http://localhost/demo/Search?p=4543

http://localhost/demo/Search?p=5433

Below is the explanation as to why the above requests have least compressed sizes. Now take the first request. Below would be the response from the server.

 URL: http://localhost/demo/Search?p=4545

Breach Sample search page3

As shown above, when the deflate algorithm encounters this, it makes an easy representation of the repetitions and thus results in a least compressed size. So by analyzing the compressed size for each of the requests from 100-10000, an attacker can simply deduce what the card number is in this case. This the beauty of this attack lies in the fact that we did not decrypt any traffic but just by analyzing the size of the responses we were able to predict the text.

To summarize in simple steps, for an application to be vulnerable to this breach attack, below are the conditions that it must fulfill:

1. The server should be using HTTP level compression.
2. A parameter which reflects the input text. (This will be controlled by the attacker).
3. The page should contain some sensitive text which would be of interest to the attacker.

Remediation:

Turning off the HTTP Compression would save the day but that cannot be a possible solution since all the servers rely on it to effectively manage the bandwidth. Here are some of the other solutions that can be tried:

  1. Protect the vulnerable pages with a CSRF token
  2. Adding random bytes to the response so as to hide the actual compressed length.
  3. Separating the sensitive data from pages where input text is displayed.

 

 

Posted by on November 30, 2013 in web application hacking

Leave a comment

Tags: , ,

Android Master Key Vulnerability POC

A few weeks back, a vulnerability dubbed as ‘Android Master key vulnerability’ was revealed. This vulnerability allows attackers to inject malicious code into legitimate Android applications without invalidating the digital signature. It’s very easy for hackers and attackers to take leverage of this vulnerability and exploit it. The news is already out that there are apps currently in the market which are taking advantage of this vulnerability.  So let’s find out  what the issue is, how hackers can exploit it and what needs to be done to fix it.

How Android apps work?

Android applications are .APK files (Android Packages) which are nothing but a collection of ZIP archives. For easy understanding let us try to open an APK file for an application and find out the same. Consider the application MyFirstApp.apk application which is signed by own my certificate. Before we go ahead, let us spend some time on android’s signing process.

It is mandatory that all installed applications in android be digitally signed with a certificate whose private key is held by the application’s developer. The Android system uses this certificate as a means of identifying the author of an application and establishing trust relationships between applications. The Android system will not install or run an application that is not signed. Hence after building an application and signing it with a certificate, you have an apk file at the end.

MyFirstApp.apk

Assume that MyFirstApp.apk is any random application and looks like this when installed on the emulator.

Sample Android app

APK files are nothing but collection of zip files. So if you rename an .apk extension with .zip you will be able to see the contents of the file.

apk file contents

As shown in the above figure, the APK file consists of subdirectory called META-INF, which contains signed checksums for all the other files in the package. Now if you modify any of the files in this package, Android will block the package to prevent the users from harmful activities. Android does this by verifying the checksum. Now in order to verify the checksum of each of these files, android has to extract each of these files from the APK archive. This is accomplished using the Java unzipping library which will parse the ZIP-format APK file, extracts each file object and matches it up with the corresponding checksum mentioned in the manifest file in META-INF:

Android app meta-inf folder

Now try to modify any of these files, for example, try to modify  the launch image file present inside MyFirstApp.zip\res\drawable-hdpi , rebuild it and try to install it on the device using the adb and you will find that android rightly notices that and shows the below message.

Android app signature mismatch

How the attack is accomplished?

The attack successfully bypasses this verification process and installs the application with any changes the hacker embeds in the code. The attack is based on the concept of placing two different files in the APK archive with the same name. Regular ZIP software generally do not allow you to have two files with the same name in one archive. But the ZIP format itself doesn’t prevent duplicated filenames, and you can take advantage of this to create an archive with repeated file names as shown below. The ic_launcher.png file is something that I have added to the existing file and created a new apk file named HackedFile.zip.

zip with duplicated filenames

Now rename this file to HackedFile.apk and try to install it and observe that android accepts it this time. It runs successfully without any complaints. Observe that I was able to replace the launch image successfully without using any certificate and android happily accepts the same.

Android app with modified image

How is this even possible?

This is possible because Android verifies the first version of any file in archive but the installer verifies and extracts the last version of the file. Thus the legitimate file is checked by the cryptographic verifier and the one added by the hacker is installed by the installer. In simple words, what gets installed is a fake but what gets verified for signature is legitimate part.

What are the implications?

The implications are huge. Most important thing to note is almost all version of Android are vulnerable to this attack. The impact of this vulnerability and its exploitation is only limited by imagination of an hacker. For instance he can spy on your communication or he can go a step further and send premium rate sms without the users knowledge, make background calls,  take pictures and forward to mails etc.

Some of the built in apps which come along with the phone have higher privileges than the other applications which are installed from the play store. So an attacker can take leverage of this and create apps which would have system level privileges. Bluebox team has successfully demonstrated this and changed the name of the kernel etc.

Pic7

Google has already released patches for this but as everyone knows it will certainly take some time for the handset makers to update all of their models. Google is now verifying all the applications in the play store to check for the master key vulnerability. But the other third party stores and the side loading of apps aren’t going to help the cause.

References:
http://www.saurik.com/id/17

 

Posted by on October 28, 2013 in Android

1 Comment

Tags: ,

Penetration testing of iPhone Applications – Part 6

In the First part of the article, we have discussed about the iPhone application traffic analysis. Second partThird part and Fourth part of the article covered in-depth analysis of insecure data storage locations on the iPhone. Part 5 covered runtime analysis basics with Cycript. In this part we will take a look at in-depth analysis of application runtime using cycript and GNU debugger.

Runtime analysis with Cycript:

With cycript we can hook into the application runtime, access & modify the instance variables, invoke the instance methods and override the existing methods. In the previous article we have discussed on how to access instance variables from the application runtime. In this article we will take a look at how to invoke & override the application instance methods. 

Invoking the instance methods with Cycript:

Cycript allows invoking the application instance methods directly from runtime. This helps in bypassing the validation mechanisms implemented in applications. For the demo, I am using a photovault application and you can download the IPA here. Photovault application will help to keep the photos securely by protecting with a passcode. When the application is launched for the first time, it prompts the user to set a passcode. Later on, the user has to enter the correct passcode to view the private photos. Below steps explains how to bypass the photovault passcode protection using cycript.

1. Launch the photovault application and it prompts for a passcode.

photovault login screen

2. Connect to the iPhone over SSH and find the application process id using ps ax command.

photovault ps id

3. Hook into the application process using cycript –p [PID] command.

hook with cycript

4. On the cycript prompt, grab the application delegate instance using UIApp.delegate command.

photovault UIAppdelegate

5. Obtain the photovault class dump using class_dump_z. Search the class dump for AppDelegate & look for the @interface of it.

photovault classdump

6. Looking at the class dump reveals an interesting method called – pinLockControllerDidFinishUnlocking. The method does not take any arguments. So we can invoke it directly using [UIApp.delegate pinLockControllerDidFinishUnlocking] command. 

method invocation with cycript

7. Bingo!. It logs you into the application without entering the passcode and gives access to the private photos.

photovault passcode bypass

Overriding the instance methods with Cycript:

The objective-C runtime allows modification & replacement of the existing methods code dynamically. This technique is known as method swizzling. For this exercise, I have created a demo application called HackTest and you can download the IPA here. HackTest application prompts the user for a password and displays the welcome screen upon entering the correct password. Below steps explains how to bypass the HackTest password validation mechanism by overriding the existing methods using cycript.

1. Launch the HackTest application and it prompts for a password.

hacktest password

2. Enter any value (ex: abcd) and click on Enter button. It displays invalid passcode message.

hacktest invalid passcode

3. Connect to the iPhone over SSH and grab the application process id using ps ax command.

hacktest ps id

4. Hook into the application process using cycript –p [PID] command.

hacktest-hooke with cycript

5. On the cycript prompt, grab the application delegate instance using UIApp.delegate command.

hacktest UIAppdelegate

6. Obtain the HackTest class dump using class_dump_z. Looking at the class dump of HackTest application reveals an interesting method called validatePasscode. The method takes no arguments and returns a Boolean value. The application probably uses this method to check for a valid passcode and takes the authentication decision based on its return value. Now using the method swizzling technique we will modify the validatePasscode method to always return true.

hacktest classdump

7. validatePasscode method is declared in the ViewController interface and the ViewController instance is present in the AppDelegate interface. So grab the ViewController instance using UIApp.delegate.viewController command.

hacktest viewcontroller

8. To override the validatePasscode method, run the below command.

UIApp.delegate.viewController->isa.messages[‘validatePasscode’]=function (){return 1;}.

It overrides the function to always return 1. isa is a pointer to the class structure and gives access to the method implementation.

cycript metod override

9. Bingo!. It logs you into the application without entering the password and displays the welcome screen.

hacktest passcode bypass

The above examples shows how one can easily manipulate the runtime and circumvent the security checks implemented in iOS applications using cycript.

Runtime analysis with gdb:

Gdb – gnu debugger is a powerful tool to analyze and alter the runtime behaviour of iOS applications. Debugging is an interactive process and allows setting breakpoints in the application execution which in turn gives more control on the application. For this exercise, I am using a photovault application and you can download the IPA here. The photovault application keeps the private photos securely by protecting with a password. When the application is launched for the first time, it prompts the user to set a password. Later on, the user has to enter the correct password to access the private photos. Below steps explains how to grab the photovault password from runtime using gdb.

1. Launch the photovault application and it prompts for a password.

photovault-3 password

2. Connect to the iPhone over SSH and find the application process id using ps ax command.

photovaut-3 ps id

3.  Attach gdb to the application process using gdb –p [pid] command.

photovault-3 gdb hook

gdb attaches to the process and reads the symbols for shared libraries.

photovault-3 gdb

4.  Obtain the photovault class dump using class_dump_z.  Looking at the class dump reveals an interesting method called btnLoginClicked. This method takes no arguments and probably gets invoked upon pressing the login button. Let’s inspect the method by setting a breakpoint.

photovault-3 classdump

5. Set a breakpoint for the btnLoginClicked method using b or break command. A breakpoint pauses the program execution whenever a certain point in the program is reached.

gdb breakpoint1

6. At this point the application gets freezed and does not accept any input. In order to continue the execution type c in the gdb prompt.

gdb continue execution 1

7. Enter some value in the photovault password and click on login button.

photovault-3 enter password

8. As expected it hits the breakpoint in gdb and the application execution is paused.

photovault-3 breakpoint

9. At this point, disassemble the btnLoginClicked method to look at the next executable instructions using disas or disassemble command. As iPhone binaries are compiled for ARM processors, gdb displays the ARM based assembly instructions.

gdb disassemble

10. In the disassembled code you will see a lot of dyld_stub_objc_msgSend instructions. Objective-c is based on the messaging framework, hence methods aren’t invoked or called, instead messages are passed between objects using objc_msgsend method. An attacker can tap into these messages and look for sensitive information. On gdb terminal, we can setup breakpoints for all the objc_msgsend calls and inspect for the important information. As there are too many objc_msgsend calls in the disassembly, it would be difficult & time taking process to inspect each and every call. In the btnLoginClicked disassembled code, dyld_stub_objc_msgSend located at 0x0000618a is followed by a cmp instruction (conditional execution) which probably means it checks for a login state. So let’s set a breakpoint at 0*0000618a and inspect the objc_msgsend call.

photovault-3 breakpoint2

11. Continue the application execution and it hits the breakpoint.

gdb continue execution2

We can inspect the breakpoint by looking at the register values. To see register values at the breakpoint use info reg command. iPhone uses ARM based processors which contain 15 general purpose registers (r0 – r14), program counter (r15) and current program status register (flags). The standard ARM calling conventions allocates the 16 ARM registers as:

r0 to r3 – holds argument values passed to a method (r0 is also used to store the return result from a method)
r4 to r11 – holds local variables
r12  ( ip) – Intra-Procedure-call scratch register
r13  ( sp) – stack pointer
r14  (lp) – link register
r15  (pc) – program counter

ios - gdb registers

objc_msgsend method contains 3 arguments –

Receiver (r0): A pointer to the called object. That is, the object on which the method should get invoked. x/a $r0 command is used to examine the address located at r0 and po $r0 command is used to print the object located at r0.

photovault-3 r0 reg

Selector (r1): String representation of the method that handles the message. x/s $r1 command is used to examine the string value stored in r1 register.

photovault-3 r1 reg

First argument passed to the objc_msgsend is stored in r2. Po $r2 command is used to print the r2 register value.

photovault-3 r2 reg

Looking at the register values explains that r0 contains the original password and the application is trying to compare it with the user entered value in r2. Bingo ! Now we know the password and can log into the application directly.

photovault-3 password bypass

The above example shows how one can easily manipulate the application runtime using gdb. The application security can be improved further by adding anti-debugging techniques which would prevent malicious users from using a debugger. Though they won’t provide 100% security, it works as an additional layer of security and delays the attacker attempts.

Penetration Testing For iPhone Applications is going to be covered in a series of articles. In the Part 7, we will take a look at push notifications, URL schemes and few automation tools.

 

Posted by on September 12, 2013 in iPhone

4 Comments

Tags: , , , ,

Google Play Store on Android Emulator

Most of you must have noticed that the Google Play Store is not available in the Android Emulator. But having Play store on the emulator would be very handy when you want to access different applications and test them. So here are the steps to add Google Play Store to your android emulator.

  1. Download the 3 files  – GoogleLoginService.apk, GoogleServicesFramework.apk and Vending.apk.
  2. Launch your emulator.
  3. Remount the adb.
  4. Change the permission of file /system/app to read, write and execute (777).
  5. Push the files GoogleLoginService.apk, GoogleServicesFramework.apk and Vending.apk to /system/app location.
  6. Remove the directory /system/app/SdkSetup.*

PlayStoreEmulator

If the above steps are properly done, play store will appear on your emulator. Give your Google account credentials to sign in and then it would ask about Google +, Back-up and restore options. After that it would show the below screen and click continue and you are done! Here is a screenshot for your reference that play store works on emulator.

GooglePlayEmulatorWorking

With this you are done! Now you can download and run any application directly on the emulator. PlayWorking

 

Video:

 

Posted by on August 31, 2013 in Android

34 Comments

Tags: , ,

Mobile Security Basic Challenges

Data stored on the device is worth more than the device

Introduction:

The above quote might well apply to desktops and laptops as well. But it’s highly probable that your mobile device might be used by someone or lost, compared to your laptop/desktop. This fact changes the entire scenario. With the advent of mobile phones and smart phones, the game has enormously changed in the last few years with respect to the ease with which tasks are accomplished. This article focuses on various security related aspects which are involved with increased use of mobiles. Before jumping into the security concerns here is a small introduction about how the mobile technology has slowly taken over the whole world.

The first hand-held mobile device was demonstrated by two Motorola employees in 1973. After 10 years i.e. in 1983, the first mobile was commercially made available. From 1990 to early 2000’s, mobile phones spread rapidly and people used it mainly for the purpose of communication. In the last 10 years, with the rapid increase in internet usage, mobiles started accommodating the features of personal computers and finally took a new shape with the introduction of ‘smart phones’. Today mobiles have penetrated into each and every corner of this world, serving variety of tasks including mobile applications, GPS navigation, storage, entertainment etc. In this article we will mainly focus on mobile applications and their security concerns.

Mobile applications:

Mobile phone applications extend the functionality of mobile phones.  Everything is readily available and the tasks which were previously accomplished in a desktop world are now available on mobile just with a single click. People now use mobile applications to assist them in several day to day activities and enterprises are in a mad rush to develop the mobile apps to reach out to the users in a better way.

What is a mobile app anyway?

Mobile app is a software application developed to run on mobiles. Each mobile operating system has a corresponding distribution platform from where these mobile apps can be downloaded. For example, Android app can be downloaded from Google Play and iPhone apps can be downloaded from Apple App Store.  So an individual or a company can develop a mobile application and upload it to the distribution platform and advertise it so that users can download and use the same. The general demand and the ease of development of these mobile apps have resulted in their enormous growth. So these days we have a mobile app for everything – for example mobile banking, online shopping, ticket purchases, games etc. The real question is how secure are these mobile apps which deal with sensitive information. So let’s have a look at general mobile security related issues which are common to all the platforms.

Mobile Security:

Mobile security is increasingly playing a crucial role as more sensitive and personal information is now stored in the mobile phones. Security is now considered as crucial and central aspect these days during the unveiling function of any Smartphone. Moreover with the corporate world embracing the mobiles in a big way the focus is very much on the security of these devices. Attacks which are seen on PC’s are now slowly making their way on to the mobiles. At a higher level mobile related attacks can be classified into below categories:

Attacks based on OS – Exploiting the loopholes present at OS level. So the concerned vendor has to release a patch to fix the issue.

Attacks based on Mobile apps – Exploiting the security holes present in mobile application which is a result of poor coding/development.

Attacks based on Communication networks – Attacks on GSM, Wi-Fi, Bluetooth etc.

Malware related attacks – Malware attacks on mobiles have been rising continuously. A successful attack can steal the photos on your mobile, hijack the camera click, hack the emails, and delete the files on the mobile.

Let’s now move on and talk a little bit more about the current issues related to mobile security. The following is a list of main issues in the field of mobile security. Please note that this is not the complete list and not in any particular order. Let’s have brief look into the security issues which revolve around the mobile devices currently.

Physical Security:

Physical security is one of the biggest challenges to the designers of mobile phones and their applications. Mobile phones are lost, stolen and borrowed (many times by others to make a call or view the photos). When a mobile device is lost, the real concern is not about the cost of the mobile but the amount of sensitive data that is present on that mobile. Imagine the personal phone which is provided by your employer for enterprise activities falls into the hands of wrong persons and he tweaks with the data present in it. Imagine a situation where your neighbor asks your mobile for a quick call and then downloads a malware on to that phone (by the way it just takes a few seconds to do that). These issues are rather less when you are dealing with a desktop world because it is unusual that you lose your desktop machine. So the bottom line is mobile applications & systems are to be designed assuming that untrusted parties would be granted access to the phone.

No such thing as ‘logging’ into mobile:

In a desktop world, each user supplies his username and password and logs into the system where he gets access to his environment. So each user has a different environment and thus the privileges and data that each user has are separated. This ensures that one account doesn’t have access to the data of other account. But this concept is not valid in a mobile world as there is nothing like logging into a mobile for each user. So sharing and accessing of data between applications is a big concern.

Secure storage of data on the phone:

In addition to the sensitive files present on your mobile (photos, contacts, documents etc.), mobile applications also store sensitive information like authentication tokens, password related files etc. It’s very important that these files are to be protected. One way is by storing them securely on the mobile so that they are not accessible or usable. For instance password files must be stored in encrypted fashion so that even after accessing those files they are of not much use.

Mobile Browsing Environment:

In a mobile browser, it is not possible to see the entire url or sometimes see any url at all. This paves the way for hackers to unleash the phishing related attacks. So the display space on a mobile device increases the possibility of phishing attacks by manifold. The fact that people are more inclined to follow links on mobile blindly adds to this problem. So in this mobile browsing environment it’s an impossible task to expect a normal user to verify every link before following it.

Isolating the applications:

The range of mobile applications that we install today are diverse – social applications to connect to family and friends, enterprise applications to manage your work, banking applications to transfer funds, gaming applications for entertainment and many more. So it’s very important that a social networking app does not gain access to your corporate app or a gaming app does not gain access to the banking app. In short, application isolation is crucial. This would depend on the factors like OS permissions in different platforms and how these permissions are granted. Exploiting the existing mechanisms to gain unauthorised access is one area where hackers are actively targeting.

Update Process:

Operating systems require patches/updates to resolve any security issues that are discovered. OS like Windows look continuously for updates and install them. But when it comes to mobile OS the patching process is not as simple as that. When a bug is reported in a particular OS, the OS vendor comes with a patch. He then publishes this information to all the carriers (like AT&T, Sprint, and Airtel etc.). Now these carriers will not be proactive in installing these updates because there is every chance that during patching processes other applications might break down. Hence if these carriers find such cases with the patching, they hold it on for some time without applying the patch/update immediately.

Proper Authentication:

Authentication process is very important in mobile phones because as explained earlier it just a matter of seconds before someone asks your phone and does something malicious and you have no idea about it. In the cases where a company offers extranet access to its corporate network through mobiles, there should be a means of Multifactor authentication because if that mobile falls into the hands of wrong guys it would expose the internal network of the company. Multifactor authentication needs to be implemented and improved in order to solve many issues.

Poor coding of mobile apps:

Poor coding or development practises of the developers could lead to severe consequences. For example: hard coding of sensitive data like passwords, transmission of information in unencrypted channel, weak server side controls, improper session handling etc. Many of the vulnerabilities that apply to web will apply to mobile applications as well.

Bluetooth & other Attacks:

Bluetooth and other drivers pose as a security threat to the overall security posture of the mobiles. We have seen in the past about the vulnerabilities reported on Bluetooth and other third party drivers. Since these have system access, by exploiting a critical vulnerability an attacker might even get access to everything on a mobile. So even if the underlying operating system has excellent built in mechanisms which does not easily grant system access, these vulnerable third party drivers would be a set back at any time.

Malware Attacks:

Many surveys point out that malware attacks on mobile phones is on the rise. If you are someone who browses through tech news every now and then you must have seen some news about android phones getting infected by malware in a big way. Malware is something which harms the system in which in resides. With new computing environment new class of threats in new forms arise. It is very important that these issues are addressed proactively leveraging from our experiences of 90’s. Reports have also been published which forecast the situation to be worse in the coming year and some quote 2013 will be the ‘year of mobile malware!’.

Jail breaking the phones:

Many users jailbreak the phone in order to run applications for free or to run applications which are not authorized by the vendor. Jail breaking a phone would remove the restrictions imposed on a device by its vendor. Hence jailbroken devices are more susceptible to computer viruses and malware. Downloading the apps from an unauthorised third party store would only put your mobile at risk.

New features like NFC pose a serious threat:

NFC – Near Field Communication is a technology that allows you to beam the content to nearby devices and lets you use your mobile as a wallet to purchase items. It has been demonstrated in Black hat conference that by brushing a tag with an embedded NFC chip over an android phone, it is possible to take over the control of the phone. So with increase in technology, you will need to address more complex attack scenarios. In future, many more advanced technologies like these are expected to come and they bring a whole lot of new issues to address.

User awareness:

User awareness is major factor in controlling many of the attacks and when it comes to mobiles it’s even more important. There are many things from the user end which he should be careful about – Having passcode for the device, look out for the permissions granted to application. A gaming application may not need access to dialling), not following the links sent by unknown persons.

As the time progresses, the industry has more challenges to face and answer. For instance new ideas pose a security threat like BYOD – Bring Your Own Device where employees bring their personally owned mobiles devices to their work place. Since there are huge number of devices out there, each having its own security issues, it’s a huge task for any organisation to guarantee corporate equivalent of privacy on these devices. These are some of the basic issues that are involved in current mobile security. If anyone of you has more points to make, I sincerely request you to comment and share with the community.

 

Posted by on July 21, 2013 in Android, iPhone

2 Comments

Tags: , , ,

Penetration testing of iPhone Applications – Part 5

In the First part of the article, we have discussed about the iPhone application traffic analysis. Second part, Third part and Fourth part of the article covered in-depth analysis of insecure data storage locations on the iPhone. In this part we will take a look at runtime analysis of iOS applications. Runtime analysis allows an attacker to manipulate the application’s behaviour at runtime to bypass the security locks and access the sensitive information from memory. Before getting into runtime analysis first we will take a look at the iOS application architecture and its runtime protection features.

iOS Application Architecture:

iOS application is a zip archive with .ipa file extension. The zip file contains the executable binary and the iTunesArtwork which is used by the iTunes to manage the application. Typical structure of an iOS application is shown in the image below.

ios application arcitecture

The .app folder within the Payload directory contains the application binary, all the resources of the application like images & audio, provisioning profile that specifies application permissions and code signature.

iOS application binary is ARM compiled and uses Mach-O (mach object) file format. Mach-O format consists of 3 main regions – header, load commands and segments/sections. The picture below illustrates the Mach-O file basic structure.

mach-o file format

Mach-O structure of an iOS application can be viewed using otool on a jailbroken device. Otool is available in Darwin CC Tools package on Cydia.

Header:
It identifies the Mach-O file and contains basic file type information like target architecture and flags that affect the interpretation of rest of the file. To view the Mach-O header of an iOS application connect the iPhone over SSH and execute the below command.

otool –h ApplicationBinary

Below is the Mach-O header of Facebook iOS application.

ios app header

cputype and subtype values in the Mach-O header indicates the application’s target architecture. The above image shows that the Facebook application is built for ARM7 processor.

ARM7s (iPhone 5) = cputype 12/ subtype 11
ARM7 (iPhone 4 & 4S) = cputype 12/ subtype 9
ARM6 (iPhone 3GS) = cputype 12/ subtype 6

Applications that are built for multiple architectures contain more than one Mach-O file. These binaries are called fat binaries or universal binaries. To view the Mach-O header of a fat binary, run the below command on SSH terminal.

otool –arch all -h ApplicationBinary

fat binary header

The above image shows that CardInfo application is compiled for ARM7 and ARM7s processors.

Load commands:
Load commands specify the layout and linkage characteristics of the file. It includes initial layout of the file in virtual memory, location of symbol table, execution state of main thread of the program and shared library details. Load commands (LC_ENCRYPTION_INFO) also define whether the application binary is encrypted or not. To view the load commands of an application, run the below command on SSH terminal.

otool –Vl ApplicationBinary

Data:
Mach-O file contains the actual data in one or more segments. Each segment contains zero or more sections. Each section of a segment contains code or data of some particular type. The exact number and layout of segments and sections is specified by the load commands. 

iOS Application Runtime Protection Features:

The iOS platform provides a lot of runtime security features like ASLR, stack smashing protection and ARC. Understanding the runtime protection features is important for reversing & analyzing iOS applications.

Address Space Layout Randomization:

ASLR is an important exploit mitigation technique introduced in iOS 4.3. ASLR makes the remote exploitation of memory corruption vulnerabilities significantly more difficult by randomizing the application objects location in the memory. By default iOS applications uses limited ASLR and only randomizes part of the objects in the memory. In order to take full advantage of the ASLR the application has to compile with -fPIE -pie flag (“Generate Position-Dependent Code” build option in Xcode). In the latest version of the XCode this flag is automatically checked by default. The image below compares the different memory sections for partial and full ASLR applications.

ios partial vs full aslr

To find out whether the application is compiled with PIE flag or not, connect the iPhone over SSH and execute the below command.

otool –Vh ApplicaitonBinary

 ios PIE enabled binary

The above image shows PIE at the end of the output. It indicates that the Facebook application is compiled with PIE flag.

Stack Smashing Protection:

Stack smashing protection is an exploit mitigation technique that protects against stack overflow attacks by placing a random value known as stack canary before local variables on stack. The stack canary is checked upon return of the function. Incase of an overflow the canary is corrupted, and the application is able to detect and protect against the overflow. In order to take advantage of the stack smashing protection the application has to compile with –fstack-protector-all flag.

iOS applications which are using the stack canaries will contain _stack_chk_fail and _stack_chk_guard symbols in the binary. To find out whether the application is protected with stack smashing protection or not, connect the iPhone over SSH and execute the below command.

otool –I –v ApplicationBinary | grep stack

iOS app stack smashing protectionResult shown in the above image indicates that the Facebook application is using the stack smashing protection.

Automatic Reference Counting:

ARC is another exploit mitigation technique introduced in iOS 5. It protects the applications from memory corruption vulnerabilities by moving the responsibility of memory management from the developer to the compiler. ARC can be enabled in an application within XCode by setting the compiler option “Objective-C Automatic Reference Counting” to “yes”. By default it is marked as “yes”.

iOS applications with ARC enabled will contain _objc_release symbols in the binary. To find out whether the application is using ARC or not, execute the below command on SSH terminal.

otool –I –v ApplicationBinary | grep _objc_release

iOS - ARC enabled binary

Result shown in the above image indicates that the Facebook application is compiled with ARC flag.

Runtime protection features add an additional layer of security to the application. So during a pentest it’s always a best practice to recommend the application to implement the runtime protection features.

Reversing iOS Applications:

Objective-C is the primary language used to develop native iOS applications. Objective-C is a dynamic language based on the principles of message passing. As it is a dynamic language, all the classes, methods and any other components are stored in the binary itself. This information can be extracted using the class-dump-z tool written by kennytm.

class-dump-z setup:

1. On a JailBroken iPhone, install wget and unzip from Cydia.
2. Connect to the iPhone over ssh and run the below commands.

wget -U Mozilla/5.0 http://www.securitylearn.net/wp-content/uploads/tools/iOS/class-dump-z.zip
unzip class-dump-z.zip
mv class-dump-z /usr/bin

class dump z setup

3. To dump the class information from an iOS application navigate to the application’s .app folder and run the below command.

class-dump-z ApplicationBinary

Below image shows the class dump of Gmail iOS application. The class dump does not reveal any useful data as the Gmail binary is encrypted. Applications downloaded from the AppStore are encrypted using FairPlay DRM to protect the piracy.

class-dump-z encrypted iOS app

To find out whether the application is encrypted or not, run the below command on the SSH terminal.

otool –l ApplicationBinary | grep crypt

iOS app encryption

cryptid 1 indicates that the application is encrypted. For unencrypted applications cryptid value is 0.

So in case of reversing iOS applications often the first step includes removing the AppStore encryption. Removing this encryption allows an attacker to get a greater understanding of how the application binary works, the internal class structure and to get the binary in a suitable state for reverse engineering. The applications which are in-house distributed and self signed are not encrypted.

Decrypting iOS applications:

When an iOS application is launched, the loader decrypts it and loads it into memory.  So a pretty well established process exists to take advantage of this process and remove the FairPlay copy protection of an iOS application. iOS application decryption process includes the below steps-

  1. Finding the starting offset and the size of the encrypted data in the application binary.
  2. Finding the memory loading address of the application (changes every time if the app is compiled with PIE).
  3. Dumping the decrypted portion of the application from memory using a debugger (ex: gdb).
  4. Overwriting the applications encrypted area with the dumped binary data.
  5. Changing the cryptid value to 0.

The complete decryption process has been automated by Cydia applications namely Clutch and Rasticrac.

Decrypting the Gmail iOS applications with Clutch:

1. On a JailBroken iPhone, go to Cydia and add the repo http://AppAddict.org/repo by navigating to Manage->Sources.
2. 
Download ClutchPatched, ZIP and IPA Installer from Cydia.
3.  
Connect to the iPhone over SSH and type the ‘Clutch’ command. It lists out all the applications installed on the iPhone.

clutch

4. Supplying the application name to the Clutch will decrypt it and stores the decrypted ipa file under /var/root/Documents/Cracked/ folder. The below image shows that Clutch cracked the Gmail application and stored the decrypted file as /var/root/Documents/Cracked/Gmail-v2.2.0.8921.ipa.

decyrpting ios app with clutch

5. The cracked ipa file can be installed on the iPhone directly from SSH using the below command.

installipa –c [iPAPath]

install ipa from ssh

The below image shows the class dump of the decrypted Gmail application.

class-dump-z on decyrpted ios app

A full class dump of a decrypted application maps to the classes, methods and provides an insight into what’s going on inside an application. Once the class dump is obtained, we can look into it for interesting classes, methods, properties and perform a runtime analysis.

Runtime Analysis With Cycript:

Runtime analysis involves reversing and analyzing the application work flow to bypass security locks, performing authentication bypass attacks, access sensitive information from memory, breaking logical checks and accessing restricted areas of the application. As Objective C is a reflective language, it allows to modification of its own behaviour at runtime. On the iPhone, iOS application runtime can be modified easily using the CyCript. Cycript is available in Cydia packages.

Cycript is a programming language designed to blend the barrier between Objetive-C and Javascript. Cycript allows hooking into a process, thus giving access to all of the classes and instance variables & methods within the application.

Before getting into the runtime analysis, it is necessary to understand the execution flow of an iOS application.

ios app execution flow

Objective C is a superset of C, so its execution also begins with main() function. When a user touches the application icon on the springboard, it calls main() function. Main() function in turn invokes UIApplicationMain method. UIApplicationMain instantiates the UIApplication object, displays the GUI (windows, views), creates the application delegate and set up the events cycle. Application delegate monitors the high level actions/events in the application. With Cycript we can connect to the running process and get access to the UIApplication object. UIApplication is a singleton object that represents the application and acts as a central control. So gaining access to the UIApplication object in turn gives access to the application internals.

The power of the cycript is demonstrated in below examples. For demonstration, I’ve used an older version of photo vault application. Before hooking into the application process with cycript first grab the class dump of the application using class-dump-z.

Accessing the instance variables with Cycript:

The photo vault application keeps the private photos securely by protecting with a password. When we launch the photo vault application for the first time, it prompts the user to set a password. Later, the user has to enter the correct password in order to access the private photos. Below steps explains how to grab the password from runtime using cycript.

1. Launch the photo vault application and it prompts for password.

photovault login

2. Connect to the iPhone over SSH and grab the process id using ps ax command.

iPhone running process

3. Hook into the application process using cycript –p [PID] command.
Note: If you know the application name you can attach the cycript using cycript –p [ApplicationName] command.

cycript

4. On the cycript prompt, we can get the instance of the application either by invoking [UIApplication sharedApplication] method or using the UIApp variable.

cycript UIApp

5. To find out the application delegate run UIApp.delegate command.

cycript UIApp delegate

6. Search the class dump for the application delegate PhotoVaultAppDelegate and look for the @interface of it (class dump will have @interface & @protocol directives). An interface contains the declaration of all the methods and the properties. Whereas the protocol contains a group of related methods, which an object might call on its delegate.

class dump of photovault

7. Looking at the properties of the application delegate, shows an interesting property strPass. Access the value stored in the strPass using UIApp.delegate.strPass command. 

photovault password reveal

8. Bingo!. It reveals the password to unlock the private photos. Type the password in the application and you will get access to the users private photos.

photovault auth bypass

Cycript also allows to modify the instance variables, invoke instance methods and overwrite the existing methods directly from the runtime.

Penetration Testing For iPhone Applications is going to be covered in a series of articles. In the Part 6, we will take a look at method swizzling techniques with cycript and runtime analysis with GNU Debugger (gdb).

References:

  1. Debunking NSLog Misconceptions
    http://oleb.net/blog/2011/06/app-launch-sequence-ios/
  2. Hacking and Securing iOS Applications by Jonathan Zdziarski
  3. “Apple iOS 4 Security Evaulation” by Dino Dai Zovi
 

Posted by on June 26, 2013 in iPhone

9 Comments

Tags: , , , ,