RSS

SSL Attacks

In the last few years, we have witnessed a wide range of attacks on the SSL/TLS mechanism. In this article, we will try to cover various attacks that were prominent in the field of cryptography. Transport layer security (TLS) ensures integrity of data transmitted between two parties (server and client) and also provides strong authentication for both parties. The attacks launched in the last few years have exploited various features in the TLS mechanism. We are going to discuss these attacks one by one.

Browser Exploit Against SSL/TLS Attack (BEAST)

This attack was revealed at the Ekoparty Security Conference in 2011. BEAST is based on a type of cryptographic attack called the “chosen plain text attack”. Before I jump into explaining the details of this attack, let us take a look at some of the basic concepts to be understood.

Background

There are two types of encryption schemes:
1. Symmetric key encryption: Encryption and decryption keys are the same.
2. Asymmetric key encryption: Encryption and decryption keys are not the same.

Symmetric-key encryption can use either stream ciphers or block ciphers. A stream cipher encrypts one bit at a time, while a block cipher encrypts plaintext in chunks. Let’s talk about block cipher. How is a message encrypted using block cipher? You don’t use the block cipher on the message directly but instead you first need to choose the “mode of operation” CBC (cipher block chaining) is one such mode used by the block ciphers.

In CBC mode, to make each message unique, an initialization vector (IV) is used in the first block. An IV is a random string that is XORed with the plaintext message prior to encryption. Each block of plaintext is XORed with the previous cipher text block before being encrypted. In other words, each cipher text block depends on all plaintext blocks processed up to that point as shown in the figure below. It’s important to note that here IV is not a secret; it only adds randomness to the output. IV is sent along with the message in clear text format. With this background information, let us know focus on how the BEAST attack is accomplished.

cbc mode

How Is the Attack Accomplished?

It was noticed that TLS 1.0, when dealing with multiple packets, allows the following packets to use an IV that is the last cipher text block of the previous packet. In other words, an attacker who can see the encrypted traffic can note the IV used for session cookie (Why? Because the cookie’s location is predictable). Simply put, an active attacker will be able to gather the IVs for each record just by sniffing the network. So if the attacker can “guess” a plaintext message, he can make a guess at the session cookie and see if the cipher text matches. [Note that, since this is a MITM attack, the attacker can mix his traffic with the victim traffic to see the results].

Practical Example

Now let us consider the message: JSESSIONID=Gxs36NepewqeMI763Hej31pkl.

This is a plaintext and will have to be XORed with the IV (which is cipher text of the previous block). The attacker has this IV value in his hands. Now if he can “predict” this plaintext value and XOR with IV, he can check whether it corresponds to the cipher text value. Understandably, it’s not easy to predict such a random value, but he can guess it a single character at a time. For example “JSESSIONID=G” can be guessed by trying different characters. Once the first character is recovered, he can shift the attack to the next character. This way he can guess one character at a time and accomplish the attack. This attack is not so straightforward and has some limitations:

  1. The attacker has to be in the same network and play a MITM attack.
  2. The attacker has to modify the traffic to see if the results match; as a result, multiple requests have to be sent in this process.
  3. The attacker can guess only one block at a time.

Solution

This is a vulnerability in block ciphers that use the CBC mode of operation. It was identified in TLS 1.0. However it was addressed in TLS 1.1 and TLS 1.2 by the use of “explicit IVs” for each block. Hence, TLS 1.1 and TLS 1.2 are not exposed to this attack. Some of the browsers have attempted to implement a solution to address the vulnerability while still remaining compatible with the SSL 3.0/TLS 1.0 protocol. Apple’s Safari, even though it has released a mitigation, has chosen to keep it disabled by default.

Google: Update to Chrome 16 or later.
Microsoft: Apply the patch MS12-006.
Mozilla: Update to Firefox 10 or later.

SSL Renegotiation Attack

A vulnerability was discovered in the SSL renegotiation procedure that allows an attacker to inject plaintext into the victim’s requests. For instance, it allows an attacker who can hijack an HTTPS connection to add their own requests to the conversation the client has with the web server. Note that the attacker cannot decrypt the client-server communication.

Background

SSL renegotiation is helpful when the routine SSL session is already established and the client authentication has to take place. For example, say you are browsing an online shopping site which uses SSL, i.e., HTTPS. Initially, you browse through the site anonymously, add items to the cart, etc. But when you decide to purchase you will be asked to log in to the site, so now the SSL connection needs to be adjusted to allow the authentication. Whatever information is gathered prior to this authentication (e.g., items added to the cart) has to be maintained even after the authentication. So the new SSL session that has to be established uses the already existing connection. Note that renegotiation can be requested either by the client or by the server at any time. For the client to request renegotiation the client sends a “Client Hello” message in the already-established encrypted channel and the server responds with a “Server Hello” and then the negotiation follows the normal handshake process. The server can initiate the renegotiation by sending the client a “Hello Request” message. When the client receives the request, the client sends the “Client Hello” message and the handshake process takes place. This explains the basic SSL renegotiation process.

How Is the Attack Accomplished?

Using the renegotiation attack, an attacker can inject commands into an HTTPS session, downgrade a HTTPS connection to a HTTP connection, inject custom responses, perform denial of service, etc. That explains to some extent how serious the problem is. It is easier to understand how the attack is accomplished through the following example.

Practical Example

The action corresponding to each of the numbers present in the below figure are explained in the order below:

SSL renegotiation attack

  1. Assume that a client wants to connect to a online banking site. He initiates the routine TLS handshake process
  2. The client blocks the request and holds the packets.
  3. The attacker initiates a new session and completes a full TLS handshake.
  4. The attacker sends a GET request (asking to send money to his account) to the bank application.
  5. Server asks for renegotiation.
  6. The TLS handshake initiated at step 1 and blocked by the attacker will now be forwarded to the server, which a new TLS handshake over the previously established encrypted TLS session 2. So the client now is authenticated and has a valid cookie.
  7. Due to this renegotiation, the server now assumes that the previously sent request in step 4 was actually sent by the client. Hence the request which goes to the server is as follows; it will be interpreted by the server as a legitimate request and then executed.

    GET /bank/sendmoney.asp?acct=attacker&amount=100000
    Ignore the rest: GET /ebanking
    Cookie: validcookie 

Solution

One way to fix the renegotiation vulnerability for SSLv3 is to completely disable renegotiation on the server side. As a permanent fix for the vulnerability, a renegotiation indication extension was proposed for TLS that will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.

Compression Ratio Info-leak Made Easy Attack (CRIME)

This is a side-channel attack on SSL/TLS that can be used to predict sensitive information, such as the session tokens, etc. This is done based on the compressed size of the requests. This attack is known to work against SSL compression and SPDY, which use deflate/gzip data compression techniques. SPDY is not widely used, but SSL compression is one technique which is very much in use.

Background 

Before we see the details of the actual attack, let me explain a few things about “compression.” Web pages are generally compressed before the responses are sent out (this is called HTTP compression), primarily to make efficient use of available bandwidth and to provide greater transmission speeds. With compressed data, we can send the same amount of data to the destination but using fewer bits. The browser usually tells the server (through “accept-encoding” header), what compression methods it supports and the 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 Is the Attack Accomplished?

A CRIME attack is based on observing how the compressed length changes for different input values. Initially the attacker observes the size of cipher text sent by the browser and then makes multiple requests to the target website to observe the compressed response sizes. The attack primarily works by taking leverage of the “compressed size” of the text when there are repetitive terms. The attack can be best understood by following the below example, which demonstrates how an attacker can exploit it in real time.

Practical Example

Consider the below POST request made by a valid user.

Request:
POST / HTTP /1.1
Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

As mentioned earlier, this content is first compressed and then encrypted and sent. But note that the size of this encrypted piece can still be found out just by sniffing the network traffic. Now the attacker’s target is to get the value of “secretcookie.” The attacker now can make the victim click on a link and, using JavaScript, he can trigger the below request.

Request triggered by the attacker:

POST /secretcookie =0 HTTP /1.1
Host: testing.com
User -Agent: Mozilla /5.0 (Windows NT 6.1; WOW64; rv :14.0) Gecko /20100101 Firefox /14.0.1
Cookie: secretcookie =5db98j64wa23pq1cb4cb0031ln481nx1
Accept -Language: en -US ,en;

<—–body——–>

In the above request, “secretcookie =0″ is the attacker-controlled input. When repetitive terms are encountered during the compression, instead of displaying it a second time the compressor says “This text is found 67 characters ago.” So this reduces the overall size of the compressed output. In the above request, since the word “secretcookie” is repeated, the compression is done accordingly by taking note of it. Now the attacker sends the below POST requests and observes the compressed sizes.

POST /secretcookie =0….
POST /secretcookie =1…
POST /secretcookie =2…
POST /secretcookie =3…
POST /secretcookie =4…
POST /secretcookie =5…

Now can you guess which POST request would be best compressed, i.e., which POST request would have the smallest compressed size? The one with “secretcookie =5″ would compress the best. This is because it has more repetitive characters. In other words, “secretcookie =5″ is repeated twice and hence the compressed size is less. Thus the attacker can confirm that 5 is the first character of the secretcookie. Going ahead with this logic, he can brute-force the other characters as well and extract the entire cookie value.

Solution

CRIME can be remediated by preventing the use of compression at the server end. It can also be prevented at the client end by disabling the compression of HTTPS requests. This is because, in TLS 1.2, the client sends the server a list of compression algorithms that are supported by it and the server picks one of them. If the client sends no compression algorithm, then the data cannot be compressed.

Timing Info-leak Made Easy Attack

In spite of being a very interesting attack, CRIME majorly suffers from two drawbacks:

  1. The attacker must be the man in the middle (to be able to read the messages) and he must also control the plaintext (which is sent as input to the application).
  2. CRIME was very soon mitigated by disabling the TLS compression.

The TIME attack overcomes both of these problems. So this attack doesn’t need an attacker to sniff the network. Instead of focusing on the HTTP request, it focuses on the HTTPS responses. To explain this attack in simple terms, all an attacker needs to do is redirect a user to a malicious website that will run some JavaScript to get the encrypted secret data.

Background

The basic concept here is that, in order to find out if there is difference in the length of two messages, we can observer the time it takes to send these messages across the network. The larger the difference, the more time it’s going to take.

How Is the Attack Accomplished?

The basic goal of the attacker is to force the length of compressed data to overflow into an additional TCP packet. The attacker then pads the remaining data. When the maximum size is crossed, any additional packet created (due to wrong guess), introduces an additional full round trip with a significant delay. Consider a simple user input (say “secret = data”). Assume that the value is reflected in the response along with the “secret.” In other words, whatever the user inputs is reflected in the response. Let us say in the first request, the user sends “secret = anything” and receives a response with a size of 1024 bytes. If the user input is “secret=a” in the second request, the response size will be less and hence it will take less time to reach than the first request. Likewise, it is possible to predict the every character in every position of our payload by observing the response times (to be precise by observing the “shortest response times”). This attack is little difficult to comprehend and so I have mentioned a video link here which could give you a better insight for the folks who are interested.

Black hat video link: http://www.youtube.com/watch?v=rTIpFfTp3-w&noredirect=1

Solution

Including CSRF, CAPTCHA tokens in the request could avoid the multiple requests that an attacker makes using the JavaScript. Adding random timing delays to the decryption for any timing attack can be reasonable to disrupt this attack, but it may not be completely helpful. The application should take care of the reflection of user input in the response.

 

Posted by on December 31, 2013 in web application hacking

1 Comment

Tags: , , ,

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

36 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: , , ,