Thursday 19 September 2013

[Solved] "Your device has been modified. Software updates are not available" error on non rooted Android device

Yesterday when I was updating my new Galaxy S4 I faced a really weird issue. I started getting an error "Your device has been modified. Software updates are not available" whenever I tried updating the device.



I know that I have this bad habit of tinkering with all the devices I get my hands on which made me wonder if I had rooted the wrong android device yesterday night during my random research :-o. I then checked my other device which was a Android S3 and noticed that it was rooted which kind of assured me that I did nothing that could cause this error on the S4. Googling this error showed me "N" number of pages mentioning that this error means I had goofed up the kernel and I can no longer update my phone and its warranty stands VOID.  (yea.. a serious WTF moment). Not that I care about  the stupid warranty, but I had resisted messing around with the device for 4 days already just to be sure that I had used it properly before it dies :D

Then, after reading 100+ random posts and spending some hours trying to figure out what could have possibly gone wrong, I came across this post. The reply on the thread by "vferrari" solved the problem for me with a little tweak.
Below are the steps I had to do to get the phone back to a condition where OTA updates are again functional:
  1. Un-mounted the inserted SD card.
  2. Restart the device.
  3. Go to Android recovery mode by pressing the Power + Volume down button.
  4. Select the "Wipe cache partition".
  5. Restart the device after successful wipe.
  6. Continue the normal steps for OTA android update.
After the above steps, I was able to successfully solve the problem and update my device. I re-inserted the SDcard, but did not face the error again.

References:

Sunday 15 September 2013

QuickStart iOS Security Assessment

Introduction:

So, I am gearing up to taking up yet another Mobile Application security training for a customer. This one is different than the one's than I normally take because its totally up to me to decide the duration of the course. Additionally it is planned to be a complete practical one with 80% demo and hands-on for the team.

Since I had taken a break from the actual Mobile PenTest scene for some time now, I had to literally start from scratch so as to make sure I included anything that has come up in the last few months (which has been a lot :-o). During the prep-work, I created a short list of topics I would be covering for the course and turns out, this looks like a pretty neat iOS Security Assessment QuickStart guide. Hence the share.

The Guide:

This diagram covers all the focus points when testing an iOS application. Considering I am jam packed at the moment with multiple projects am not sure when I would be able to make a detailed post for each of the components, but just one line "Google is your friend". :)

References:

Friday 19 July 2013

[Solved] sbt.ResolveException: download failed: org.slf4j#slf4j-api;1.6.6!slf4j-api.jar

So, I was working on Scala with Play Framework for some time now. I have to compile the source code provided by the client from time to time and I have faced this issue nearly everytime whenever I use a new developer machine.

When I run the "play clean", "play update", "play compile" or the "play run" command on the provided project, I get the error as sbt.ResolveException: download failed: org.slf4j#slf4j-api;1.6.6!slf4j-api.jar.

Below is a screenshot of this error message:



I tried a bunch of ways to solve this issue, but only one method seems to work.

The first thing you need to do is edit the /project/plugins.sbt file and add the latest version of sbt-plugin in the addSbtPlugin section.

Now, delete the ivy directory present at ~/.ivy2
Then, go ahead and delete the below mentioned files:

  • <path to Play Framework home directory>/.sbt.ivy.lock
  • <path to Play Framework home directory>/cache/org.slf4j
  • <path to Play Framework home directory>/local/org.slf4j
Then, run the same play command which you ran earlier.
As shown in the below screenshots, this time the command ran successfully without any sort of error.



References:




Tuesday 23 April 2013

Installing latest nodejs on Linux


Introduction:

According to its site, Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Basically, it is a server side software system that can be used to design and write scalable Internet applications. It can be used to create a web server on its own, thus removing the need of using a web server software like Apache. Due to the asynchronous I/O mode, there is minimum overhead(computation time).

I have a machine running Ubuntu 12.10, so I normally use my package manager (apt-get) to install applications which are present in the repository. However, even though I did apt-get multiple times, the installed version seemed to an outdated v0.6.* where-as, the latest version as per their site was v0.10.4 (Huhhh!!!)

Detailed Steps:

Below are the steps which I had to perform, to get the latest nodejs up and running:

Step 1: We will start off, by installing the "software-properties-common" package for the "apt-get" repository. This can be done using the command:
"sudo apt-get install software-properties-common"

Step 2: Chris Lea's repository includes the latest npm and nodejs-dev that is required to install nodejs v0.10.4
Below command helps you add thoseto your local repository list:
"sudo add-apt-repository ppa:chris-lea/node.js"

Step 3: Update the local package index with the changes made in the repository using the command:
"sudo apt-get update"

Step 4: Now, install nodejs as you normally would, using apt-get command as shown below:
"sudo apt-get install nodejs"

You can run #nodejs --version on terminal to see the version of the currently installed nodejs.




Above screenshot shows that we have updated nodejs to the latest available version: v0.10.4

References:



Saturday 2 February 2013

Mobile Client Side Certificate Pinning


I just completed giving a training on Secure Mobile application development and Code reviews and one of the attendees asked me query whether we can limit a Mobile application to allow only the servers certificate to be a trusted one rather than relying on the Mobile's own Trusted Certificate Store?

Well... there is a way actually. Its called as "Certificate Pinning". Rather than relying on the device trusted store, set the application to trust only the servers SSL certificate. This way, when you are connecting to your specific SSL server, you don’t need anyone else to tell you the server’s identity. Compromises of any of the CA in the device trusted store too does not matter as the connection does not rely on it any more. 

There are ways to implement it on both Android and iOS. Twitter for example; implements certificate pinning and i was not able to intercept traffic even after forcing my certificate on to the OS level trusted certificate list.

Good Reads:

Certificate Pinning on iOS:

Certificate Pinning in Android:

Way to achieve this can be seen here, which is a OWASP page explaining the various details on Certificate Pinning.

However, like all other good things, this too can be bypassed :D .. This link will tell you how you can bypass it on iOS using Mobile Substrate and on Android using JDWP.

Understandably this would not be of much use against remote attacks but atleast would help in cases where attacker tries to fuzz for local vulnebilities in the application right? 

I wonder why none of the other applications are not using it and whether there would be any drawback of suggesting it to the client. 
Open for discussion :)

Monday 28 January 2013

[Solved] W: GPG error: http://coredev.nl iphone Release


Many times when i was installing "Theos" on my iOS device everything went well till the last step which is "apt-get update". When i ran the command, it would always give me an error "W: GPG error: http://coredev.nl iphone Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY" as shown in the below screenshot.










After much googling, i found this link which explains the solution to this issue. Though the scenario in the link is different than mine, however it seemed to work well for me :)
The solution was, navigate to the sources.list.d folder and add the "public key" to that folder. This can be done wither by using "lynx" or by using "wget".



A shown in the above screenshot, apt-get works well after the above steps were followed.

References:

iOS SSH over USB


Introduction:

Many a times, at client side we are not provided with Wifi access and connecting to our iOS device to read local data can be a real pain. At such a period, we can use a tool called as “usbmuxd” to connect to the Jailbroken iOS device running OpenSSH over the USB.

Detailed Steps:

Step 1: Make sure you have python installed on your machine. Download latest copy of “usbmuxd” using the command “git clone http://git.sukimashita.com/usbmuxd.git”.


Step 2: Navigate to the “python-client” folder and run the command “chmod +x tcprelay.py” and then run the tool using the command “./tcprelay.py -t 22:2222”


The “t” basically allows multiple threads to run so that multiple simultaneous ssh connections can be established.

Step 3: Now, once the tcprelay starts its work, we use the command “ssh root@localhost -p 2222” to forward the local port 2222 to remote port 22. Use the credentials “root/alpine” to connect to the OpenSSH server running on the device.


Now, all the commands which can be used over SSH can be run on the prompt provided. 

References:




Adding custom certificate to Android Trusted certificate store

Introduction

Android maintains a list of trusted certificates any deviance in the certificate would result in a error in connection. Below screenshot shows how the browser gives a popup when we set the Android device to forward the traffic to Burp Proxy instead of the actual server.


Once, the user clicks on “Continue”, the user can continue to use the application as per his requirement. However, in case of native applications there is no “popup” and the connection is directly rejected.
Solution: Add the proxy certificate to android trusted store.
How:
Step 1: Download the latest copy of bouncycastle lib from http://www.bouncycastle.org/latest_releases.html into a folder called “lib”. During the making of this document, the latest version of the lib was v1.47.

Step 2: Extract a copy of the current certificate file ie. “cacerts.bks” from the android device using:
adb pull /system/etc/security/cacerts.bks




Step 3:Download a copy of the Charles Proxy certificate from the Charles website http://charlesproxy.com/charles.crt

Step 4: Add the BouncyCastle library to your machines existing Java. Once that is complete, use the below command to add Charles certificate to the certificate store downloaded from the device and sign it using the BouncyCastle library jar 
sudo keytool --keystore cacerts.bks --storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "bcprov-jdk15on-147.jar" --storepass "" --importcert --trustcacerts --alias newalias --file charles.crt


Step 5: Now, adb into the device and run the “mount” command to see where the “system” directory is mounted.
In our case, it was found to be mounted at “/dev/block/stl9”. Knowing this, remount the system directory in read/write mode so as to push the certificate store back on to the device. Then, run the command as “mount -o remount,rw -t yaffs2 /dev/block/stl9 /system” inside adb shell as root user.

Step 6: Then, change the permissions set on the certicate store to world writeable using “chmod 777 /system/etc/security/cacerts.bks” as root user and the push the new cacerts.bks into the device using “adb push cacerts.bks /system/etc/security/cacerts.bks

Step 7: Now, change the permissions back on the cacerts.bks file using “chmod 644 /system/etc/security/cacerts.bks” as root user.

Now, restart the device and after that you can see that all the traffic from the Android device can be intercepted on charles proxy without any issue.
Similar method can be applied to add Burp certificate on Android trusted certificate store.

References:

Sunday 27 January 2013

Decompiling Encrypted iOS binaries

Introduction:

In my previous article, i had described how you would normally go about decompiling an iOS application. That method would be working for a majority of applications. However, many a times the developers push in security feature to prevent the attackers from decompiling/debugging the application.

In our case, though we are the developers friends and are testing the application, it would be good if we actually follow the same route as an attacker would. That way, we can understand what exact information is disclosed and how the application can be compromised.


Requirements:
  • iOS device must be jailbroken.
  • OpenSSH should be installed on the iOS device.
  • SSH Client on your machine.
  • "Class Dump" should be installed on the iOS device via "Cydia"
  • "Cycript" should be installed on the iOS device via "Cydia".
Detailed Steps:

First we will try and use the same step as used in our previous post to dump the class file information via "class dump".
Below screenshot shows one of such an instances when we use classdump to decompile an application. The command run is of the same syntax as used earlier but the content is unreadable.


In such a case, using class dump alone would not be fruitful. We have to use a tool called as "Cycript" along with “weak_classdump” by Elias Limneos which is Cycript script that generates a header file for the class passed to the function.

It can be used as follows.

Step 1: Get the process id of the running application to be decryped and decompiled using the command "ps -ax | grep "App"".


The above screenshot shows that the process id was "3785".

Step 2: Download the latest copy of "weak_classdump.cy" from "weak_classdump" on to the working folder.

Then, use the below command to inject weak_classdump into the application to be decrypted and decompiled:
cycript -p 3785 weak_classdump.cy; cycript -p 3785

If, the injection was successfull, you will get the message as 'Added weak_classdump to "TWCTV" (3785)' where "TWCTV" is the application to be decrypted and decompiled.


Step 3: Now, you will get cy# where you will have to enter the below command to do the actual decompilation and to dump the required info.
weak_classdump_bundle([NSBundle mainBundle],"/tmp/3847_decrypted_application")

This step takes a lot of time and you would get somthing like the screenbelow when the process is complete.


Step 4: Now, exit cycript and you can access the complete decompiled cleartext source at "/tmp/3847_decrypted_application".



The above screenshot shows that the source code is in cleartext and can be easily analysed and the function names and values can be hooked in the runtime using Mobile Substrate or Cycript to force the application to perform various malicious activities.

References:

Reverse Engineering an iOS application

Introduction:

When you are PenTesting an iOS application, you would want to read the code of the provided application and understand the backend classes and hidden information. Using this, you can try and exploit the application to gain access to sensitive information or to redirect the flow of the application in an malicious manner.

Reverse Engineering an iOS application is completely different as compared to an Android apk. The complete original source code cannot be revivied from an existing iOS application. Only, declarations for the classes, categories and protocols can be decompiled from an given application.

Requirements:
  • iOS device must be jailbroken.
  • OpenSSH should be installed on the iOS device.
  • SSH Client on your machine.
  • "Class Dump" should be installed on the iOS device via "Cydia"
Detailed Steps:

Step 1: SSH in to your iOS device using credentials as root:alpine.
 

Step 2: Launch the application on your device and note down the application location on your device using the "ps -ax | grep "App"" command.


As shown in the above diagram, the application is running from location “ /Applications/Stocks.app/Stocks”

Step 3: Navigate to that location “/Applications/Stocks.app/” via the shell.
We will use “Class dump” to reverse engineer this application. It is a command-line utility for examining the Objective-C runtime information stored in Mach-O files. It generates declarations for the classes, categories and protocols. We will do this using the command
class-dump Stocks > /tmp/dinesh/Stockreversed.txt

As shown in the below screenshot, the application was decompiled properly and the header and implementation files are copied to location /tmp/dinesh/ in the file Stockreversed.txt


Below screenshot shows the contents of the file “Stockreversed.txt” is clearly readable and all kinds of hidden secrets and logical flaws can be understood from here.


The above screenshot shows that the source code is in cleartext and can be easily analysed.
Now that you have the declarations of the classes and the protocols you can go ahead an debug the application using GDB or, hook on to the functions present in the application via MobileSubstrate and try to change its behavior.

However, many a times this process is not so straight forward and the developers put in additional security feature to prevent the attackers from reversing the applications by using debugging techniques. The ways by which, we can bypass this restrictions and try and dump the class declarations in an encrypted iOS application would be explained in the next blog post. 

References:

Reverse Engineering an Android application


Introduction:

The Android compiler suite compiles the developer's Java files into class files, and then the class files are converted into dex files. Dex files are bytecode for the DalvikVM which is a non-standard JVM that runs on Android applications. The XML files are converted into a binary format that is optimized to create small files. The dex files, binary XML files, and other resources, which are required to run an application, are packaged into an Android package file. These files have the .apk extension, but they are just ZIP files. Once the APK package is generated, it is signed with a developer's key and uploaded onto the Androidmarket via Google's website from where the user can download these APK files and install them on the Android device.

Requirements:

  • Tool to unpack the .apk file : 7zip
  • Tool to convert the .dex to a .jar file : dex2jar
  • GUI tool for Java decompilation : JD-GUI
  • The android apk file.

Detailed Steps:

Step 1: You can get the apk file matching your application to be reversed from the location /data/app/<application-name>. If you want, you can even use the tool AppSender from GooglePlay on your device which allows you to export any apk mapped to your application on your device as per your choice.
Step 2: Extract the apk file using 7zip to view the contents of the .apk file. The .dex and the .xml files that were discussed earlier in the article are shown in below figure.




Step 3: The next step will render a better view of the code using the 'dex2jar' tool. A dex2jar tool kit converts the Dalvik executable .dex files into Java .class files.

The 'classes.dex' file from our application is dropped into the dex2jar's directory and converted using the command, dex2jar.bat classes.dex.

This creates the 'classes.dex.dex2jar.jar' file in the same directory as shown in below figure.




Step 4: To view the readable format of the class files, we use the tool, JD-GUI. Open the 'classes.dex.dex2jar.jar' file using JD-GUI.


This depicts a systematic view of the complete source code of the Android application.

Step 5: After obtaining the complete source of the application, you can perform the actual analysis of the source and check whether something is amiss.


References and Good Reads:



Sunday 20 January 2013

Back to Life

So I've been quite busy with work lately and could not complete the actual task which i had started this blog for. I had many long random posts on Kernel Exploitation here on this blog for some time before i finally decided to delete all of them.

I could not see myself making much progress on the topic and the cycle mentioned in my first blog post was failing miserably so i've moved on to better topics which i would actually be using in my day to day life :)

I've worked on a huge number of topics ranging from xmlhttp scripts, python codes, mobile testing methodologies to blah blah blah so it would not be possible to blog all of them but i'll try and keep this blog updated from now on.

Chao guys and hope i do not have to delete my blog again coz of some stoopid decisions :D

Ohh btw i am a fan of Dilbert and i just noticed that we both share some similar thoughts ;)