Hi. I’m Prateek Gianchandani.
Om Mani Padme Hum
I am glad to release a completely new version of Damn Vulnerable iOS App written in Swift 4. With developers now migrating to Swift for developing apps, it is important to have a testbed app for iOS in Swift. Though I have added some sections in Objective-C too which the users can test to learn Objective-C related vulns.
The following vulnerabilities are covered in this version.
Read on →
- Local Data Storage - Data Storage in Plist, UserDefaults, Keychain, CoreData, Webkit Cache, Realm, Couchbase and YapDatabase.
- Jailbreak Detection - 5 challenges in this section. Apart from the usual checks where you can use runtime manipulation and attach debuggers to bypass Jailbreak detection, users will have to mitigate scenarios where there is added runtime protection, use of inline functions, string obfuscation, and certain edge cases, for e.g the exiting of an app when a jailbroken device is detected.
- Excessive Permissions - A demo on how app permissions can be misused, as demonstrated by Krause originally.
- Runtime Manipulation - Use runtime manipulation to modify instance variables, bypass local login checks, and brute force pin codes. In some cases, you might have to attach a debugger.
- Anti Anti Hooking/Debugging - Enabling these will detect when a debugger or a runtime analysis tool such as Cycript is attached to the app. There is also detection for MobileSubstrate, SSLKillSwitch2 etc. Try and work your way around it and see if you can still solve other challenges with these limitations. Reverse & Patch, Patch, Patch !
- Binary Protection - Do some binary analysis to identify whether ARC, PIE, Stack smashing is enabled. Find the signature used to sign the binary and the entitlements it has. Also check if the app is stripped of its symbols or not.
- Touch/Face ID Bypass - Bypass Touch ID authentication when insecure APIs (LAContext) are being used.
- Phishing - Demonstration of alerts generated by app that look like the ones generated from App Store, which can potentially be used for conducting phishing attacks. Original idea by Krause.
- Side Channel Data Leakage - Understand the different kinds of Side Channel Data leakage such as Device Logs, Pasteboard, App Screenshot, Keystroke Logging, Insecure APIs used for HTTP Cookies etc.
- IPC Issues - Solve this challenge to understand what can happen when an app is receiving requests via URL schemes from untrusted sources and doesn’t validate it properly.
- Broken Cryptography - Bypass 2 encryption and hashing implementations, one with AES and the other one with PBKDF2 with only few rounds of hashing.
- Webview Issues - Understand injections in Webviews.
- Network Layer Security - Capture traffic over HTTP and HTTPs. Bypass Certificate and Public Key Pinning. Also understand what is ATS (App Transport Security) and check whether it is implemented or not.
- Application Patching - Patch login checks, jailbreak detection methods, and in specific certain specific instructions used in the app.
- Sensitive Information in Memory - Dump the information from the memory to look at the sensitive data.
- Data leakage to third parties - Identify and Capture the data being leaked to third parties.
One of the most common misconfiguration issues that i find during testing iOS apps is the bypass of the App Transport Security feature introduced by Apple in iOS 9. Here’s an excerpt from Apple’s documentation about ATS.
“Starting in iOS 9.0 and OS X v10.11, a new security feature called App Transport Security (ATS) is available to apps and is enabled by default. It improves the privacy and data integrity of connections between an app and web services by enforcing additional security requirements for HTTP-based networking requests. Specifically, with ATS enabled, HTTP connections must use HTTPS (RFC 2818). Attempts to connect using insecure HTTP fail. Furthermore, HTTPS requests must use best practices for secure communications.”
Read on →
In this article, i would like to give a quick walkthrough of the new vulnerabilities and challenges that we have added in version 1.5 of Damn Vulnerable iOS app.
In the Insecure Data storage section, we have added challenges for the following databases.
Read on →
- Realm Database
- Couchbase Lite
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.
Read on →
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.
Read on →
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.
Read on →
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.
Read on →
p>In this article, we will discuss the extent to which you can test applications on your Mac rather than the device. This could be useful for many reasons, sometimes you may not have a jailbroken device 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.
In this case, we are going to perform our testing on Damn Vulnerable iOS app
Read on →
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.
Read on →
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.
Read on →
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.
Basically, the memory of the application will contain a lot of information, most of which we will not be interested in. These things might include instantiated UIViews and other UI elements. We will definitely be interested in instantiated view controllers and their properties though. It is important to understand and focus on only the relevant information in the memory. For a penetration tester, you should mainly be interested in all the values of the properties and instance variable in an application.
Read on →
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.
At this point, i would also like to mention that if you are looking for a VM that contains all the tools to cater to your android application pentesting needs, have a look at Android Tamer.
Read on →
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.
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.
Read on →
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 pretty 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.
Read on →
I am so excited to release the latest version of Damn Vulnerable iOS app for iOS 8. Up till now, DVIA has been downloaded more than 75000 times and i can’t wait for the count to reach 6 digits :–)
Following vulnerabilities and challenges have been added in the latest version.
- Sensitive information in memory
- Webkit Caching (Insecure data storage)
- Certificate pinning bypass
You can download the latest version from here.
The source code is available on the project’s github page here.
The easiest way is to install the application from Cydia. Add the source repo.kylelevin.com and search for DamnVulnerableiOSApp.
Read on →
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.
Read on →
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:
Read on →
- 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’,
Read on →
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.
Read on →
- 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)
- customizable settings (timeouts, packets/sec, etc)
- “anonymous” feature; changes MAC to a random address before attacking, then changes back when attacks are complete
- all captured WPA handshakes are backed up to wifite.py’s current directory
- smart WPA de-authentication; cycles between all clients and broadcast deauths
- stop any attack with Ctrl+C, with options to continue, move onto next target, skip to cracking, or exit
- displays session summary at exit; shows any cracked keys
- all passwords saved to cracked.txt
- built-in updater: ./wifite.py -upgrade