In this small article, we will look at a very handful utility named Xconfor bypassing Jailbreak detection. As per the wiki page …
xCon is a collaborative project by n00neimp0rtant and Lunatik that aims to be an all-in-one solution for hooking every known method and function responsible for informing an application of a jailbroken device. At first, the project aimed to patch applications on a per-app basis, but now it uses lower-level hooks to cover any apps that attempt to use the same procedure, even patching apps not explicitly reversed by the developers. Originally an open-source project, it remains closed-source now to discourage App Store developers from working around xCon’s hooks.
A very handful resource for detecting jailbroken devices can be found here. Here is a screenshot from the page. The purpose of Xcon is to make sure all these checks fail.
In this article, we will talk about FAT binaries and see more usage of LLDB.
Fat binaries are single binaries that are compiled for different architectures. They are done so because it is easier to ship a single binary for different architectures. Apple has been changing the architecture in the last three versions of it’s iPhones, armv7, armv7s, and arm64. The good thing is that new iOS devices can run applications compiled for older architectures as well. However it is recommended to upgrade the architecture of the application for enhanced performance.
You can see the architecture for your project by going to the Project in Xcode and looking under Build Settings.
In this article, we will look at some of the most important commands in LLDB to debug applications.
If you have been following this blog series, you would have noticed that we have been using GDB until now for debugging applications, but the support for GDB has been disabled by Apple. Apple has compiled a very useful list of GDB to LLDB commands to get you up to date with debugging via LLDB that can be found here.
We will look at some of the most important commands after hooking into an application. In this case, lets start debugging the Twitter app. So make sure that the Twitter app is running in the foreground on the device and start a listener for the Twitter app.
In this article we will learn about the LLDB debugger used by Apple’s Xcode for debugging applications, understand why it is better for security testing, and then learn how to use it to debug iOS applications.
The following excerpt is from Apple’s documentation.
LLDB is Apple’s from the ground up replacement for GDB, developed in close coordination with the LLVM compilers to bring you state-of-the-art debugging with extensive capabilities in flow control and data inspection. Starting with Xcode 5, all new and preexisting development projects are automatically reconfigured to use LLDB. The standard LLDB installation provides you with an extensive set of commands designed to be compatible with familiar GDB commands. In addition to using the standard configuration, you can easily customize LLDB to suit your needs
A good way to start leaning about the LLDB debugger is to watch this video from WWDC 2014.
But the question that remains is, why is LLDB better than GDB ?
To sum it up, there are a few reasons for that.
It works well for iOS 8
LLDB is much faster, has support for multithread programming, and is scriptable.
LLDB understands the dot syntax. You can use something like po self.propertyName or even po instanceVariable to find any value of a property or instance variable while debugging applications.
It has plug-in support for functionality and extensions.
In this article, we will discuss the extent to which you can test applications on your Mac rather than the. This could be useful for many reasons, sometimes you may not have a jailbroken but want to get a POC for a vulnerability. We will discuss what are the things you can and cannot do. To test the application on your system, you will need to have Xcode installed on your system and you will run the applications on the iOS simulator.
Installing ipa files from iTunes on your simulator
Sadly, there is no way you can do that. This is because the iTunes applications are compiled for the ARM platform whereas the applications that run on your simulator are compiled for the x86/x64 platform. So, to test any application properly on your Mac, you must have the source code of the application to run it on the simulator.
I have decided to give away the solutions for DVIA for free. The reason for this has been too many people coming up with queries for the solutions and i believed giving away the solutions for free would really benefit the infosec community.
It has taken me a lot of nights and hard work to create this project and specially the solutions.
If you think this project has been useful to you and your organization, please consider making a donation to this project.
You can donate to this project and download the solutions for free from here.
In this article, we will look at a very handy framework for analysis of android applications named Drozer. Drozer is a very useful tool as it eliminates the need for having seperate tools for performing different security checks in an android application. It has a list of modules that you can use to interact with the application using Android’s Inter-Process communication. Additionally, you can also install exploits and use it to exploit an android device.
The main purpose of this article is to make sure you are familiar with drozer so we can use it in the future articles.
The first thing to do is to install the drozer community edition from this link. You need to install both the drozer installer and the Agent.apk file which is the application that needs to be deployed on the device/emulator and acts as a communicator between the system and the application to be audited.
Once drozer has been installed on your system, install the agent.apk on your device/emulator.
In this article, we will look at attacking components in Android applications, starting with activities. But first, it is essential to understand what Android application components are. Android application components are the essential building blocks of an Android application. The behaviour and interaction between these components is defined in the manifest.xml file in the application. Mainly there are 4 types of components and it is important to understand their purpose and function.
The description of the 4 components given below has been taken from this link.
They dictate the UI and handle the user interaction to the smartphone screen
They handle background processing associated with an application.
They handle communication between Android OS and applications.
In the previous article, we looked at setting up a mobile pentesting platform for Android applications. By now, you must have set up an emulator using genymotion and installed all the android command line tools along with some other additonal tools (drozer, dex2jar, apktool). In this article, we will look at some information gathering techniques. We will see how we can decompile an application to its java source, analyze the signature of the application and many more things.
In this article, we will look at analyzing the memory contents of an iOS application. iOS applications may store sensitive information like passwords, session IDs etc in the memory of the application without releasing them. In some cases, releasing these variables may not be an option. For e.g, it might be required for the application to send an authentication token with every request and hence there has to be a reference to it in the memory somewhere. Even though these variables might be encrypted when stored locally in the application, these variables will be in their unencryped format while the application is running. Hence, analyzing the contents of the memory is an important thing while pentesting an iOS application. If there are some important properties or instance variables that are not required, they should be released from the memory.
This is a guest lecture by Egor Tolstoy. Egor is a full-time iOS developer working at Rambler&Co and living with his lovely wife in Moscow, Russia. In his spare time he investigate iOS applications for different vulnerabilities and blogs about my research.
Parse is a wonderful BaaS which helps with setting up backend infrastructure for your mobile application as fast as possible. Maybe just because of this simplicity many developers forget about a number of new security issues and vulnerabilities.
For those who don’t know what this service is, let’s make a brief introduction. Parse provides a lot of useful capabilities to mobile developer: cloud data storage, push notifications, usage statistics and crash logs gathering, code hosting, background jobs and a many other things. Within the boundaries of thes research we are interested in the cloud data storage, named Cloud Core.
All the data in Cloud Core is stored in so called custom classes (ordinary database tables).
In this article we will look at all the things you need to do to set up a pentesting platform on iOS 8 and be comfortable with using all the tools.
Jailbreaking your device
If your device is running iOS 8.1 or earlier, you can use pangu to jailbreak your device. The process is prerry straightforward. We will not be covering jailbreaking your device in this article but if you want to know how it is done, you can read this article.
Note: I was getting an error with Pangu saying that there was not enough space on my device even though there was enough space. I tried by putting my device into Airplane mode and by turning off Wifi on my laptop and it worked for me.
In this article series, we will learn at various concepts of Android application security while exploiting a vulnerable app InsecureBankv2. We will be looking at all the concepts from a noob’s perspective and hence i would recommend this blog series to beginners as well.
However, the first thing to do is set up a proper mobile pentesting platform for android application testing.
The first thing to do is download the Eclipse ADT bundle. You can then follow the instructions here to install the ADT bundle. Once this is done, make sure you install the necessary sdk packages and libraries by following the instructions here.
In this article, we will look at how we can analyze network traffic for applications that use certificate pinning. One of the best definitions i found of certificate pinning is mentioned below. It is taken directly from this url.
By default, when making an SSL connection, the client checks that the server’s certificate:
has a verifiable chain of trust back to a trusted (root) certificate
matches the requested hostname
What it doesn’t do is check if the certificate in question is a specific certificate, namely the one you know your server is using.
In this article, we will look at cracking access points using WPA-PSK or WPA2-PSK using Wifite.
If you have used tools like airodump-ng, aircrack-ng etc to crack WPA access points before, you would know that the required thing to successfully crack a WPA-PSK network is a captured WPA four-way handshake. More details about the WPA four-way handshake can be found on this wikipedia page.
As mentioned in the previous article, there is a bug in Wifite that may or may not be there in your particular version of Wifite. The bug basically doesn’t aireplay-ng to function properly and displays an error like aireplay-ng exited unexpectedly . In order to fix this, you will have to make slight modifications in the code of wifite. You can install gedit (apt-get install gedit) which is a text editor and then edit the wifite python script (found in /usr/bin/wifite) using the steps mentioned here. To open wifite, use the command gedit /usr/bin/wifite. This will open up the source code of wifite. Then replace every occurence of cmd = [‘aireplay-ng’, with cmd = [‘aireplay-ng’,’–ignore-negative-one’,
In this article series, we will look at a tool named Wifite suitable for automated auditing of wireless networks. Most of you who have experience in wireless pentesting would use tools like airmon-ng, aireplay-ng, airodump-ng, aircrack-ng to crack wireless networks. This would involve a sequence of steps, like capturing a specific numbers of IV’s in case of WEP, capturing the WPA handshake in case of WPA etc, and then subsequently using aircrack-ng to crack the password required for authentication to the network. Wifite aims to ease this process by using a wrapper over all these tools and thus making it super easy to crack Wifi networks.
Here is a list of features of Wifite as per its official homepage.
sorts targets by signal strength (in dB); cracks closest access points first
automatically de-authenticates clients of hidden networks to reveal SSIDs
numerous filters to specify exactly what to attack (wep/wpa/both, above certain signal strengths, channels, etc)
In this article, we will look at another cool utility named iDB for pentesting iOS applications.
Before that, i would like to apologize for coming up late with this article. A lot of you have been requesting articles on different topics and i promise that i will write on them soon :). So since we are best friends again, let’s dive into this tool.
iDB is open source and you can download it from its Github page. You can then follow the tutorial here to know how to install it. Installation might take some time as there might be some dependencies you will have to install, so have some patience. Also, please note that it works with ruby versions 1.9 and 2.1 so make sure you set that version of ruby. You can use rvm list to list the versions of ruby installed on your system and then use rvm use followed by the version of ruby that you want to use.
In the previous articles, we have seen how applications like Snoop-it can trace method calls specific to the application at runtime. This is very important in deducing the flow of the application. The same process can be performed by using a perl script named Logify.pl that comes installed with Theos. The script takes input as a header file and generates the hooking code that we can add in our tweak. We can also specify the classes we want to check. Once the tweak is installed on the device, whenever a method for that particular class is called, the tweak logs out the method along with the arguments to syslog. The first step here is to get the header files for a particular application. You can get the header files by using the -H option in class-dump-z. Once the headers folder is generated, you can copy it to your system.
In some of the previous articles in this series, we have looked at how we can modify the behaviour of an application by patching it using IDA Pro, Hopper etc. However, doing this hasn’t been quite straightforward always. We can also use Cycript to modify the behaviour of an application by changing some of the method implementations, but the change isn’t permanent. This is where writing tweaks for an application comes in handy. A tweak is nothing but a run-time patch to an application using the Cydia Substrate framework. Cydia Substrate consists of 3 major components: MobileHooker, MobileLoader and safe mode. You can read about these 3 major components here. Saurik has also written a complete series of documentation here. Our main focus here would be not to go in depth and learn how to write tweaks for jailbroken devices but to understand there relevance to application security so we can quickly write our own tweaks when necessary.
While doing security audit of iOS apps, there are a lot of tasks that we have to repeat every time. This includes finding out the class information for the app, checking if the application stores any important data in plist files, analyzing the content in the database files etc. These tasks can be a little time consuming every time and so it doesn’t make quite a lot of sense to repeat them over and over again for every app. We have also looked at some tools like Snoop-it and iNalyzer that make our job easier by automating some of these tasks. In this article, we will talk about a new tool named iOS Reverse Engineering Toolkit (iRET) that has just been released to assist penetration testers in automating most of the tasks involved in a iOS penetration test. The project is developed and maintained by @S3Jensen.
In the author’s own words, here is what the toolkit does.
It’s a toolkit that allows you to automate many of the manual tasks an iOS penetration tester would need to perform in order to analyze and reverse engineering iOS applications. And the bonus is this can all be performed right on the device.
In this article, we will talk about why we shouldn’t completely rely on using third party libraries for securing our apps. Usually, some of the things we try to do in our application are adding checks to detect piracy, jailbroken device etc. It is such a pain to write all the code from scratch which is why we usually resort to using third party libraries that can get the job done for us. In this example, we will be looking at a library named AntiPiracy which can be found on this url that aims to solve our problem.
On a first glance, it looks amazing .. here is a snippet of the description from it’s github page
The Full Shmoopi Anti-Piracy Library utilizes over a dozen algorithms to detect piracy, (not just four) including:
So i have been getting a few queries on how to create an IPA file from Xcode and distribute it for jailbroken devices. Here is how i did it for Damn Vulnerable iOS App.
First we need to run the application using Xcode on the device. This requires a valid provisioning profile. I am doing this on Xcode 5.x but on the previous versions of Xcode, it was possible to run the application on the device without a valid provisioning profile.
Once the application is installed on the device, copy the .app folder from the device on your system.
In this article, we will look at how we can use a feature in iOS named url schemes to exploit an application. URL schemes are used by applications to communicate with each other. Every application can register for a particular url scheme. For e.g, the Damn Vulnerable iOS application registers for the url scheme dvia. This means that any url starting with dvia:// protocol will open up the dvia application. Depending on the parameters and the endpoint in this url, the dvia application can decide what to do it. Another example is the phone application in iOS. It registers for the url scheme tel and a url like tel://1-393-222-2222 will invoke the phone application and call a number. The problem arises when the url is not validated or the user is not prompted for confirmation in the application before making a particular decision.
The first step is to find the actual url scheme an application is registered to. This information can be found by looking at the info.plist file in the application sandbox folder using any file explorer utility like iExplorer.
If you have been experiencing segmentation fault issues with GDB while attaching to a process on a jailbroken iOS device, it is because the GDB that comes with Cydia is broken and you need to install a proper version.
You can download a proper working version of GDB from here.
You need to copy this executable into /usr/bin on your jailbroken iOS device and give it executable permissions.
If it still doesn’t work, let me know what issue you are facing by writing a comment below.
In this article we will look at an example of Insecure or Broken Cryptography which is a common vulnerability found in most iOS applications. This vulnerability occurs when the data stored on the device is not encrypted properly thereby allowing a malicious user to gain access to that information. There could be many reasons for an improper implementaion of encrytption, using hardcoded keys for encryption, bad algorithms etc can all be the cause for an implementation that is not secure.
In this article, we will look at an example of how we can spot and break an incorrectly implemented encrytion technique. For this article, we will be testing on the application InsecureCryptography-Demo that you can download from my Github profile. Download it and run on the simulator or on the device. Let’s look at what this application does. Once you start the application for the first time, it asks you to set up a new password to get started.
In Part 26 of this series, we looked at how we can use IDA Pro and Hex Fiend to patch an iOS application and modify its implementation. Patching an application has the specific advantage that once a change has been made, it is permanent. However, if you look back at the article on IDA Pro, you will realize that the process of patching the application was a bit tedious, mainly because we didn’t have a licensed version of IDA Pro which costs a lot. In this article, we will look at a utility named Hopper which we can use as an alternative to IDA Pro. It is less costly than IDA Pro and also provides a sleek interface to work with.
According to Hopperapp.com ..
Hopper is a reverse engineering tool for OS X, Linux and Windows, that lets you disassemble, decompile and debug (OS X only) your 32/64bits Intel Mac, Windows and iOS (ARM) executables! Take a look at the feature list below!
In this article we will look at how we can set up a mobile pentesting platform on our device with the new iOS 7 jailbreak. There has been quite a lot of discussion on the web about whether it is safe for a user to jailbreak their devices yet. However, if you are really interested in iOS pentesting then there is no absolutely no reason now why you shouldn’t jailbreak your device. Since this jailbreak was launched by the evasi0n team without any prior notice to the developers, most of the tweaks didn’t work with iOS 7 when the jailbreak was first made public. One of the most critical pieces of software Mobile Substrate which is used in many tweaks initially didn’t work on iOS 7. However, things have settled down since then. An update for Mobile Substrate (named Cydia Substrate) was released a few weeks back and many tweaks were also updated for iOS 7. Some things however don’t work well on iOS 7 devices. In this article, we will look at all those things which we need to do to set up a proper pentesting platform on a device running iOS 7.
In the previous applications we have looked at how we can hijack method implementations during runtime using Cycript, and even change the logic of the code rather than changing the complete implementation using GDB. All of these things have been done to serve a purpose, which is to make the application do what we want. However, using Cycript or GDB is a bit of a pain as one has to do repeat the same process everytime after you restart the application. This is where patching the application is useful. Once a change has been made in the application’s binary, its permanent. So you don’t have to repeat the same process over and over again. Once the binary is patched, you can then run it on a jailbroken device with the changed logic.
In this article, we will be using the same application GDB-Demo that we had used in Part 22 of this series. If you remember, we had found a way to change the logic of the method that gets called when Login was tapped and hence bypassed the login authentication check. In this article, we are going to permanently patch this check so we are always authenticated.
In this article, we will look at some of the best practices an iOS developer should follow in order to make sure that their application is not easily exploitable by hackers.
Local Data Storage
It is extremely important for developers to know what kind of data they should be storing locally in their application. Frankly speaking, no data is secure when stored locally in the application. In part 20 of this series, we have looked at Local Data Storage in great detail.
In this article, we will look at the checks a developer can incorporate in his application to check whether the device on which the application is running is jailbroken or not. Checking whether a device is jailbroken or not can have many advantages for your application. As we have already seen, an attacker can run tools like Cycript, GDB, Snoop-it etc to perform runtime analysis and steal sensitive data from within your application. If you are really looking to add an extra layer of security for your application, you should not allow your application to be run on a jailbroken device. Please note that millions of users jailbreak their devices and hence not allowing an application to be run on a jailbroken device could have a significant impact on your user base. Another thing you can do is instead block some of the features in your application rather than disabing it entirely. We will also look at how hackers can bypass the check for jailbreak detection in your application using Cycript.
Once a device is jailbroken, a lot of other files and applications are installed on the devcice. Checking for these files in the filesystem can help us identify whether the device is jailbroken or not. For e.g, most of the jailbreak softwares install Cydia on the device after jailbreaking. Hence just a simple check for the file path of Cydia can determine whether the device is jailbroken or not.
In the previous articles, we have looked at how we can use debuggers and tools like Cycript to do runtime analysis and manipulation of iOS Applications. We have looked at how we can modify the actual implementation of a method during runtime by changing the values in the registers using GDB, and also looked at how we can completely swizzle method implementations using tools like Cycript. With tools like Cycript and GDB in his arsenal and with a copy of your application’s binary, the attacker is is complete control. However, there are certain techniques a developer can use to make the job of the hacker much more difficult. In this article, we will look at the techniques a developer can use in his application to defend it against runtime analysis and manipulation.
In Xcode, there are certain checks that an attacker can use to determine whether an application is being debugged or not. In Xcode, use the following piece of code wherever you want to put a check for a debugger.
In this article, we will look at how we can use GDB to perform runtime analysis of iOS applications. In the previous articles, we have looked at how we can use Cycript to analyze and manipulate the runtime behaviour of iOS applications. We have learnt how we can perform method swizzling and have our own methods being called instead of the original implementations. So why we do need GDB ? Well, what Cycript doesn’t allow us to do yet is set breakpoints and alter the values of variables and registers after a particular instruction. With GDB, we can dive deep into the application, observe the low level assembly instructions, manipulate the values in the registers and hence change the application flow completely.
All the iOS devices released uptil now are based on the ARM architecture. All the Objective-C code that we write while developing iOS applications is first converted into ARM assembly before being converted to machine code (1s and 0s). With good understanding of the ARM assembly language and with good knowledge of debugging using GDB, it is possible for a hacker to decipher the Objective-C code during runtime and even modify it.
For this article, we will be using a sample application GDB-Demo from my github account. Make sure to install and run it on your iOS device. If you don’t have a registered developer account to run this on your device, you can follow the instructions mentioned here
In this article, we will look at the different ways in which applicatons can store data locally on the device and look at how secure these methods are.
We will be performing some of these demonstrations in a sample app that you can download from my github account. For the CoreData example, you can download the sample app from here
One of the other things that we will doing different in this example is that we will be running the application on the iOS simulator using Xcode rather than on the device and hence will be analyzing the application on our computer rather than on the device. This is just to demonstrate that you can perform all the steps performed before in previous articles on your system as well by running the application via Xcode. Optionally, you can simply run the application on your device using the steps mentioned here.
One of the most common ways of saving user preferences and properties in an application is by using NSUserDefaults.
Read on →
In this article, we will look at how we can Introspy as a python module in our scripts.
The first thing to do is to import the introspy module and Namespace from argparse module.
We then create an instance of the Introspy class. The arguments that we need to provide are the database name,
the group name, the subgroup name and the list. Now, for this case, lets provide all the parameters as None except the database path. Introspy will hence include all the groups rather than just including a particular group.
In the previous article, we looked at how we can use Introspy for Black-box assessment of iOS applications. In this article, we will look at how we can use Introspy to set up our own custom signatures and detect them in an application trace. Setting up our own predefined signatures could be useful for cases where you have a found a method in a particular application that seems of particular interest to you and you want to know when it is being called. Introspy already has a list of predefined signatures that it uses to flag vulnerabilities or insecure configurations. However, it also allows us to add our own signatures.
You can find the predefined signatures in Introspy in the signatures.py file inside the analyzer folder.
In this article, we will look at how we can use Introspy for Black-box assessment of iOS applications. Introspy is developed by ISEC partners and its github page can be found here. Introspy consists of two seperate modules, a tracer and an analyzer. It is undoubtedly one of the most powerful tools for analyzing the security of iOS applications.
The first step is to install the Introspy tracer on your device. You can download the debian package from here. Once it is downloaded, just upload it and install on your device. The image below shows how to perform all the above mentioned steps.
In the previous article, we looked at how we can perform static analysis of iOS Applications using iNalyzer. In this article, we will look at how we can use iNalyzer to perform runtime analysis of iOS applications. We can invoke methods during runtime, find the value of a particular instance variable at a particular time in the app, and basically do anything that we can do with Cycript.
In the last article, we were successfully able to generate the html files via Doxygen and open it up to view class information and other information about the app. For runtime analysis, we will be using the Firefox browser. The developer of this tool has personally recommended me to use Firefox as this may not work on other browsers. However, it seemed to be working fine for me on Chrome as well.
In the previous article, we looked at how we can use Sogeti Data protection tools to boot an iDevice using a custom ramdisk with the help of a bootrom exploit. In this article, we will look at a tool named iNalyzer than we can use for black box assessment of iOS applications. iNalyzer allows us to view the class information, perform runtime analysis and many other things. Basically it automates the efforts of decrypting the application, dumping class information and presents it in a much more presentable way. We can also hook into a running process just like Cycript and invoke methods during runtime. iNalyzer is developed and maintained by AppSec Labs and its offical page can be found here. iNalyzer is also made available open source and its github page can be found here.
In the previous article, we looked at how we can boot a device using a custom ramdisk using Sogeti Data protection tools. In this article, we will look at how we can use some of their tools to gather information from the device like fetching the keychain information, dumping the entire filesystem or even bruteforcing the passcode.
Until the previous article, we had successfully set up a connection to the device using usbmux, ssh’ed into the device and had mounted the partitions. Here is what these partitions contain.
In the previous article, we looked at how we can use Keychain-Dumper and Snoop-it to analyze and dump the contents of the Keychain from an iOS device. In this article, we will look at how we can boot a non-jailbroken device using a custom ramdisk and analyze the contents of the device.
So what is the need of booting a device using a custom ramdisk ? Imagine a scenario where you only have temporary access to a device and you can’t jailbreak it. You just have access to the device for say like 30 minutes. In that time, you can boot the device using a custom ramdisk, brute force the passcode, and dump all the information for later analysis. The best thing is that the device does not need to be jailbroken in order for you to carry out this attack. Ofcouse, if the device is using a alphanumeric passcode, then it might take even more time to bruteforce the passcode. You can imagine this as similar to booting a windows machine with a Linux live CD, and then mounting the windows partition and then using the Linux OS to access the contents of the hard drive.
Read on →
In the previous article, we looked at the different ways in which we could analyze the network traffic and the api calls being made through an iOS application. In this article, we will look at how we can dump the contents of the Keychain from an iOS device.
According to Apple, a Keychain in an iOS device is a secure storage container that can be used to store sensitive infromation like usernames, passwords,network passwords, authentication tokens for different applications. Apple itself uses the Keychain to store Wi-fi network passwords, VPN credentials etc. It’s a sqlite database file located at /private/var/Keychains/keychain-2.db and all the data stored in it is encrypted. Developers usually want to leverage this feature of the operating system to store credentials rather than storing it themseleves in NSUserDefaults, plist files etc. The reason for this could be that the developer may not want the user to log in everytime and hence store the authentication information somewhere in the device and use it to log in the user automatically whenver the user opens up the app again. The keychain information for every app is stored outside of its sandbox.
In the previous article, we looked at iOS filesystem and forensics. In this article, we will be looking at how we can analyze the network traffic flowing across an iOS device. Analyzing the network traffic for an application could be helpful in many ways. It could help us deduce how the application is managing the session of its users, the endpoints to which the application makes the call, how the application works internally etc. We will also look at how we can analyze network traffic over SSL.
There are both active and passive ways of sniffing traffic on a network. In case you are interested in analyzing the traffic for a particular device over a network remotely, wireshark is the tool to go for. Just open up Wireshark, start sniffing over the network and add a filter (for e.g ip.addr == 192.168.1.2) so that it shows only the traffic sent or received from your iOS device. It is possible that you may lose some packets if you don’t have a good wireless card.
In this article, we will be looking at the iOS filesystem, understand how the directories are organized, look at some important files, and look at how we can extract data from database and plist files. We will look at how applications store their data in their specific directories (sandbox) and how we can extract them.
One of the important things to note is that in all the previous articles, we have been logging in to the device as the user root. There is another kind of user with the username mobile. A mobile user has less privileges than a root user. All the applications run with the user mobile, with the exception of Cydia and some other applications which run with root privileges. Some of Apple’s internal daemons or services also run with root privileges. A quick ps aux will make this very clear. On the extreme left, you will see the USER column. We can see that Cydia runs with root privileges, whereas all other applications run with mobile user, for e.g /Applications/AppStore.app/AppStore while some of the daemons for e.g /usr/sbin/wifid run with root privileges. Some other applications that you install via Cydia may also run with root privileges. By default, once you jailbreak the device, the password for both root and mobile user is alpine.
In some of the previous articles, we have looked at how we can dump class information of iOS apps using class-dump-z, hook into the runtime using Cycript and perform runtime manipulation and method swizzling, analyze the flow of the app using gdb etc. However, there could be a much better way of doing these things. We shouldn’t be using seperate tools for all these tasks. It would be great if a tool could perform all these tasks and at the same time display the information in a much more presentable way.
Snoop-it is a tool that solves these problems. It allows for runtime analysis and blackbox security assessment of iOS apps by retrofitting existing apps with debugging and runtime tracing capabilities. It also provides a very neat web interface. At the time of writing of this article, Snoop-it is not released yet but is a couple of weeks away from launch. I mailed the authors and they were nice enough to provide me with a beta version for testing. You can check out its official page here or you can follow the author on Twitter
In the previous article, we looked at how we can install custom apps on our device without a developer certificate. In this article, we will look at how we can perform method Swizzling using Cycript on a sample application.
The first thing is to download the sample Xcode project. You can download the Xcode project from here. Or you can also just download the binary file on your device from here. If you have installed the Xcode project, you will have to build the Xcode project using a self signed certificate.The previous article talks about this in great detail. If you have downloaded the binary, you can directly run it on a jailbroken device without any issues but to get a look at the source code, it is recommended to download the Xcode project.
Usually, to test apps on a device, you need to be a registered developer which costs about $99/year. For people who want to learn iOS Application security, it is very important that they should be able to run applications on device so that they can perfom tests on them. For some people who do not want to publish any apps on the app store, it may not be worth it to pay the $99/year fees. In this article we will be looking at how we can build and install an application on a jailbroken idevice without having a registered developer account. Then in the next article we will look at how we can run our own applications on the device and use Cycript to perform method swizzling and other techniques.
In the previous article, we learnt how to setup Cycript on your idevice, hook into a running process and obtain information about its properties in runtime. In this article, we will look at some advanced runtime analysis techniques. We will look at how we can obtain information about a particular class (methods, instance variables) and modify them at runtime.
Finding methods for a particular class
First of all, lets make sure we are hooked into the running process.
In the previous article, we learnt about the runtime capabilities of an iOS App written in Objective-C which uses the Cocoa framework. In this article, we will look at how we can use a very essential tool named Cycript to analyze and modify the runtime of an iOS application. In this article, we will be performing our analysis on the Yahoo Weather iOS app.
We can hook into a running process and find the names of all classes being used, i.e the view controllers, the internal and third party libraries being used and even the name of the Application delegate.
Burpsuite is one of the best tools available for web application testing. Its wide variety of features helps us perform various tasks, from intercepting a request and modifying it on the fly, to scanning a web application for vulnerabilities, to brute forcing login forms, to perfoming a check for the randomness of session tokens and many other functions. In this article we will be doing a complete walkthrough of Burpsuite discussing all its major features.
Burpsuite (free edition) is available by default in Backtrack 5. The professional edition can be downloaded from here. Some of the features that are not available in the free edition are Burp Scanner, Task Scheduler, Target Analyzer etc. Overall it has the following features.
Almost all the native iOS applications are written in Objective-C. All these apps use Cocoa which is a library that sits on top on Objc-C and provides high level APIs that make development for Mac and iOS much easier. Cocoa also adds a runtime environment for the applications. In this article, we will focus on understanding the Objective-C runtime and all the intricate details about how the language functions internally. This will help us get a much deeper understanding of its applications to iOS application security.
Objective-C is a runtime oriented language. Now the questions that arises is, what is a runtime language ? Well, a runtime language is a language that decides what to implement in a function and other decisions during the runtime of the applications.
Read on →
Have you ever checked out an iOS app and thought it was cool, and wondered if you could find some information about the source code of the app, the third-party libraries it uses, or how the code is designed internally ? Have you ever wondered if it was possible to dump all the images, plist files used in any app either preinstalled on your device or downloaded from the App store? If the answer is Yes, then you have come to the right place.
In this article, we will look at how we can analyze any preinstalled app on your device or any other app downloaded from App store and discover things about the source code of the app like the classes that it uses, the names of the view controllers it uses, the internal libraries, and even intricate details like the variables and methods names used in any particular class or view controller. We will then look at how we can decrypt the applications downloaded from the App store and dump all the images, plist files that the app uses.
In this article series, we will be learning about the tools and techniques required to perform penetration testing and Vulnerability assessment on iOS Applications.
Jailbreaking your device
If you are serious about iOS security, then having a jailbroken device is a must. In this section, we will look at how we can jailbreak an iOS device. Jailbreaking a device has many advantages. You can install tools like nmap, metasploit and even run your own custom python code on the device. Imagine having the power to run a vulnerability scan on a website from the palm of your hand. To know more about jailbreaking and the advantages of doing it, i recommend you have a look at this article.
Jailbreaking your device is as simple as downloading a jailbreaking software and clicking on jailbreak.
Read on →
This article is in continuation of Part 1 of the series on Ghost USB Honeypot. Malware threats have become very common these days and hence the need of honeypots to detect those malwares have become equally important. In the last few years, we have seen how USB based malwares can be used to target highly protected machines that are not connected to the internet. In order to detect malwares that spread over USB devices, the Ghost USB Honeypot project was started. Ghost is a honeypot for detecting malware that spreads via USB devices. The honeypot currently supports Windows XP and Windows 7. The way Ghost works is that it first tries to emulate a USB thumb drive. If the malware identifies the emulated device as a USB thumb drive, it will try to infect it. Ghost then looks for write requests to the drive, which is an indication of a malware.
Malware threats have become very common these days. In the past, many honeypots have been created to detect malware propagation over the network. These honeypots trick the malware into believing that they are a part of the network. These honeypots are however isolated and once they have been infected, they can be used to study the behaviour of the malware. Network based malware have always been more successful, given the large number of systems they can affect in a short period of time.
DHCPig is a very nice and handy little tool used to carry out an advanced DHCP exhaustion attack. It does this by grabbing all the IP addresses in its subnet by sending different DHCP requests for those IP addresses. It also finds out its neighbour’s IP addresses in its vicinity and releases their IP addresses by sending DHCP releases to the server. It then waits for a specific timeout on its sent packets, and if the timeout is reached, it means all the IP addresses in the network are now used up.However, some neighbours may still have IP addresses on the network that will have IP addresses conflicting with the IP addresses taken up the attacking machine. In this case, DHCpig can also knock all the windows systems offline by sending gratuitous ARP requests from all the IP address in the network. A gratuitous ARP request is used to check for duplicate IP addresses. If there is another device on the network using the same IP address (our attacking machine), the windows machine will receive an ARP reply from the attacker’s machine. This way, the Window’s machine will know that it has an IP address conflict with another system on the network. As a result, it will try to obtain another IP address but since all the IP addresses are now exhausted, it wont be able to get a new IP address.
This article is in continuation to part 2 of the Backtrack 5 r3 walkthrough series. In this article we will we looking at some of the other new tools that were added into Backtrack 5 with the release of its latest version R3.
This article is in continuation to part 1 of the Backtrack Walkthrough Series. In the previous articles we discussed some of the most important new tools that were added in the most recent revision of Backtrack 5 like Dnmap, Fern-Wifi-Cracker etc. In this article we will look at some of the other main tools added in Backtrack 5 R3.
Backtrack is one of the most popular Linux distributions used for Penetration testing and Security Auditing. The Backtrack development team is sponsored by Offensive Security. On 13th August 2012, Backtrack 5 R3 was released. This included the addition of about 60 new tools, most of which were released during the Defcon and Blackhat conference held in Las Vegas in July 2012. In this series of articles, we will look at most of the new tools that were introduced with Backtrack 5 R3 and look at their usage. Some of the notable changes included tools for mobile penetration testing, GUI tools for Wi-fi cracking and a whole new category of tools called Physical Exploitation.
Defcon day 3 started with one of the most awaited talks of Defcon 20. It was the talk “Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2” by Moxie Marlinspike, David Hulton and Marsh Ray. Moxie marlinspike has been one of the most popular speakers at Defcon for the past few years and as expected, the hall was full of people.
The talks on Defcon day 2 were scheduled to begin from 10 am. I reached the venue at 8:30 am and decided to use the time to buy some Defcon merchandise. The lines for the merchandise are usually very long but it wasn’t at that time of the day.
DNS is a naming system which coverts human readable domain names into computer readable IP addresses. Whenever there is a query for a domain which is not in the resolver’s cache, the process happens by traversing through the entire DNS hierarchy from the root servers to the top level domain (for e.g .com). The top level domain then gives us the information about the nameserver that has been delegated the responsibility of the domain whose IP address we are looking for. We then get the information about that domain from it’s nameserver. The results are then cached by the DNS resolver with a particular value of TTL(time to live) after which the entry in the cache expires. In some cases a domain may be identified as malicious and needs to be removed. This could be because of various reasons like malware propogation, phishing etc. One of the steps to prevent users from accessing this domain is by deleting the domain from its TLD (top level domain) servers. However this does not completely remove the threat because the domain will still be resolved by the resolver until the TTL expires. In this article we will discuss about a recent DNS exploit discovered by researchers which is present in most of the DNS servers which exploits a weakness in the cache update logic of some of the DNS servers. This allows their cache to be overwritten in such a way that it is possible to continuously extend the TTL for the delegation data of a particular domain and prevent it from expiring. Hence the domain will be completely resolvable even though it has been deleted from the TLD servers. These types of domains have been named as Ghost Domain Names.
A lot of the networks use NAT (Network Address Translation) these days. This allows the systems on the same network to have a single global IP address. This also assures enhanced security but at the same time adds complications specially while connecting to P2P (Peer to Peer) networks. This is because at the time of initiating a connection in a Peer to Peer network, it is not possible to determine which packet coming from the peer is intended for which host on the network simply because they have one global IP address. Also, most of the networks with NAT may drop incoming packets simply because it cannot figure out which client on the NAT the packet is directed to, or may recognize it as an unauthorized packet etc. Some of the common Peer to Peer applications are Skype, Spotify etc.
Ammonite is a Fiddler extension used to scan web application for common vulnerabilities like verbose and blind SQL injection, OS commanding, local file inclusion, buffer overflows, format string vulnerabilities etc. Ammonite can also scan responses for important information like credit card numbers. Some of the unique features of Ammonite is its ability to test all sections of an HTTP Request for which includes headers (ever heard of SQL injection through HTTP headers ? ), cookies etc. One of the other features which is particularly interesting about Ammonite is the ability to pause, cancel and resume individual test cases. This is different than the conventional web scanners where the tests are executed in a particular order and we can just wait and watch if some test is taking a long time. Ammonite also has features for exporting requests in Python which aids in exploit development. We can also generate our own customised HTML report.
In this article we will look at how we can insert vulnerabilities in web applications. Why? There are basically two reasons. Firstly, because it allows us to see the application from the eyes of a web developer and not a hacker. Secondly, because it allows us to create a platform where we can create a set of vulnerable web applications, and fuse them all together in a Virtual machine. So now, several people can test their web application security skills on the VM and learn from it. Some of the other reasons might be to leave a backdoor onto the server once the attacker has got access. Some of the backdoors could be very easily found out as they stand apart from the rest of the applications, but if the web application itself has been made vulnerable instead, then its a bit tough to detect it.
In the previous articles in this series, we looked at all the plugins available in w3af and looked at their applications in different scenarios. In this article, we will look at some of the other tools present in w3af which allow us to send Manual Requests, perform Fuzzing, Encode and Decode requests and responses, use a Proxy to intercept and modify requests and responses, and allow us to perform a comparison between different HTTP requests and responses. We will also look at how we can write our own w3af scripts to automate the task of Web Application Penetration Testing. We will then look at the various profiles present in w3af.
In the previous article w3af walkthrough and tutorial part 2 - Discovery and Audit plugins we looked at the various discovery and audit plugins used by w3af to identify vulnerabilities in a web application. We also looked at how we can exploit these vulnerabilities by using the exploit plugins present in w3af. In this article, we will look at the remaining plugins present in w3af which are bruteforce, grep, mangle, output, auth and evasion plugins and look at their applications in web application penetration testing.
In the previous article w3af walkthrough and tutorial Part 1 we looked at how to use the w3af console. We also learnt about the different plugins in w3af and how they interact with each other to perform various tasks. In this article we will look at how to use the discovery and audit plugins in w3af to perform a vulnerability scan of the web applications and consequently exploit the vulnerabilities present. We will also look at the various techniques used by w3af to identify these vulnerabilities. In this article we will be working with the w3af GUI version.
w3af (Web Application audit and attack framework) is a framework for auditing and exploitation of web applications. In this series of articles we will be looking at almost all the features that w3af has to offer and discuss how to use them for Web application Penetration testing. In the first part of this series we will be working with w3af console and getting ourselves familiar with the commands. We will also be looking at the different types of plugins that w3af has to offer and discuss how to use them for optimal performance.
Topics related to Internet censorship have been over much debate in the last few years. The main purpose of such
internet censorship acts is to deny access to certain information on the internet. This information can be censored
throughout the world, or in some cases could be limited to certain countries. Some countries even have their own censorship
policies. One of the many examples of such acts is the very famous SOPA (Stop Online Piracy Act), which had provisions to protect the
publication of copyright intellectual property on the internet. There are many ways to censor information on the
internet like IP address blocking, DNS Filtering, URL Filtering etc.
Anonymous systems are used to allow users to surf the web, communicate with servers anonymously. Some of the popular Anonymity service providers are TOR, GTunnel etc. The basic idea is to hide the identity of the user. However it is important to ensure that the efficiency of the anonymous system in not decreased in the process which could depend on numerous factors like latency, degree of anonymity etc. The communication between the sender and the receiver happens through a set of routers, often referred to as a mix or node, whose job is to hide the relation between the incoming and the outgoing packets through it by using various techniques like using encryption, adding delays, adding cover traffic etc. In Timing analysis attacks we assume that the attacker has access to a particular set of mixes, i.e the attacker is a part of the network.
Read on →
In the first part of this article we looked at some of the common authentication types used in Web Applications these days and discussed their pros and cons. In this article we take it one step further and discuss some of the advanced authentication methods used these days. We will also discuss the various techniques for bypassing web based authentication, and discuss the steps needed to avoid such kinds of vulnerabilities.
Read on →
Authentication is the process of validating something as authentic. When a client makes a request to a web server for accessing a resource, sometimes the web server has to verify the user’s identity. For that the user will have to supply some credentials and the web server validates it. All subsequent decisions are then taken on the basis of the credentials supplied by the client. This process is called Authentication. Once the user is authenticated, the web server sets up the appropriate permissions for the user on it’s resources. Whenever the user tries to access a resource, the server will check if the user has appropriate permissions to access the resource or not. This process is called Authorization.In this article we will look at some of the common types of authentication used these days, discuss the vulnerabilities in them, and then move on to some attacks against these authentication types.
Wireless networks have become very common in today’s world, people are used to be connected to wireless networks in office, home, coffee shops etc. In order to facilitate the process of connecting to the wireless network, most of the operating systems often remember the previous networks connected to (often stored in Preferred Networks List) and send continuous probes looking for these networks. Once the network is found, the system automatically connects to the network. If more than one of the probed networks is found, it connects to the network with the highest signal strength (though it may vary sometimes on the operating system used).Since these clients send continuous probes, any hacker within the radio frequency range can listen passively and see the networks the client is probing for. Because of the vulnerabilities in the implementation of the algorithms for connecting to previous networks, it is possible for an attacker to set up a custom station (Access point) and have the victim connect to it. Once the victim is connected to the Fake AP the attacker has IP-level connectivity to the victim and can launch a bunch of attacks against the victim.
This article will talk about the maintaining access step in a penetration test. After an attacker has broken into the system and got access, escalated privileges etc, it is important for him to maintain his authority on the system so that he can access it at a later time. The exploited system could be a web server (directly accessible from the internet), or a system running inside a network with NAT, hence not directly accessible from the internet. The system could also be running in a network with a firewall that monitors incoming and outgoing packets, having filters set for different types of packets, protocols etc. There could be a number of different scenarios, and it is important from the attacker’s perspective to maintain his access on the compromised host. In this article we will discuss all these cases, take up different real world scenarios and see all the different methods of bypassing those restrictions.
Read on →
DNS is a naming system for computers that converts human readable domain names e.g. (infosecinstitute.com) into computer readable Ip-addresses. However some security vulnerabilites exist due to misconfigured DNS nameservers that can lead to information disclosure about the domain. This forms an important step of the Information stage during a Penetration test or Vulnerability assessment. In this article we will look at the following areas..