Author at Infinum

Why Jailbreak Detection in iOS Apps Is Pointless

Adis Mustedanagic — Wed, 20 Feb 2019 18:00:00 +0000

When developing apps that have the need for extra security, we often get requests to detect jailbroken phones. The reason for detection is to either disable some, or most of the app’s functionalities due to security concerns that come from a jailbroken system.

In my opinion, these kinds of checks don’t contribute too much to the security side, since they can be targeted and disabled, and might just alienate some of your power users.

Let’s demonstrate how.

What isn’t a jailbreak?

In order to understand what a jailbreak is, it’s best to start from what a jailbreak isn’t. By default on iOS, every app runs inside a sandbox of its own. In a nutshell, this means that every app has a very limited access to system resources, and almost no access* to other apps and their data.

Source: Apple’s Sandbox Design Guide

Interested in learning more? It’s covered in the official docs.

*sometimes there are mechanisms for exchanging data between apps, that are implemented intentionally

What is a jailbreak?

If we rename sandbox to jail, then the term jailbreak makes more sense. By definition, a jailbreak is a privilege escalation for the purpose of removing software restrictions imposed by Apple on iOS, tvOS and watchOS.

In case you didn’t understand a word from above, it means giving apps admin (root) level access, which in term allows installation of other apps, tweaks and themes not on the App Store. Think Cydia – the unofficial official jailbreak software manager.

Jailbreak detection

So, now that we’re familiar with what jailbreaking isn’t and what it is, it’s time to discuss how developers detect a jailbreak. While there’s no official way to detect a jailbreak, and false positives are possible, most methods rely on attempts to access resources that are usually inaccesible on a sandboxed app.

For example we will try to:

Try to find the presence of Cydia
Attempt to find existence of CydiaSubstrate, the framework that allows installation of third-party patches
Attempt to access directories that should not be available to an app without escalated privileges (such as /bin/bash, /etc/apt)
Try to find symbolic links to usually unavailable directories
Or, attempt to write to a directory where that usually wouldn’t be possible

The reason for having so many different methods is due to many different types of jailbreaks and iOS versions. Usually, if any of the methods above succeeds, we assume we’re dealing with a jailbroken phone.

Breaking the jailbreak

In order to demonstrate that detecting a jailbreak doesn’t pose a significant obstacle to a determined hacker, we’ll need a few things:

An app with jailbreak detection
A jailbroken device
A bit of reverse-engineering
A tweak that disables the jailbreak detection for the same app

Let’s roll up our sleeves.

1. App with jailbreak detection

For the sake of this article, I’ve developed a simple app with an elaborate name Jailbreaking Bad. Its only purpose is to detect if a device is jailbroken.

If you’re interested in the source code, you can find that here:

GitHub – Adis/jailbreaking-bad

The jailbreak detection is contained inside a class named JBChecker, which is just a wrapper for a more complicated class that does all the heavy lifting, for clarity.

This class only has one method that checks if the device is jailbroken or not, and returns the result. This is also our entry point when jailbreaking the app a few steps later.

+ (BOOL)isJailbroken
{
    // Lib used can be found at https://github.com/thii/DTTJailbreakDetection
    return [DTTJailbreakDetection isJailbroken];
}

After opening the app, you will be presented with a single button; tap it, and the app will tell you if it has detected a jailbreak or not.

2. A jailbroken device

Obviously, a major part of testing this yourself is getting your hands on a jailbroken device. I won’t be covering how to perform a jailbreak in this article as this info is widely available online.

In case you were wondering how the app looks like on a jailbroken iPhone, here’s a handy gif:

3. A bit of reverse-engineering

In order to develop a tweak for an app, you will have to figure out the behaviour you want to change.

Depending on your level of curiosity, there are plenty of tools out there which allow you to deconstruct and observe the ins and outs of a certain app.

In order to get familiar with with our own app, first, we’ll want to inspect the IPA (not the beer, the extension) file from the device on a unix machine. The tool of our choice will be class-dump.

IPA file is just an archive, so unarchive it, and take a look at its content. You’ll find icons, folders, .plist files – but we’re looking for a mach-o file that represents our app in a binary format. This file will usually have the app’s name. To dump the headers from the file, use the class dump:

./class-dump Jailbreaking\ Bad

and you will be presented with a lot of output, but the part we’re interested in is this one:

@interface JBChecker : NSObject
{
}

+ (_Bool)isJailbroken;

@end

What we can see here is the header of our checker class (the wrapper we added as described before), with the method name from which we can easily infer the usage and the return value we want to override. Gotcha.

4. A tweak that disables jailbreak detection

In a jailbreak world, a tweak is an improvement that allows you to hook into existing classes and methods of installed third-party and system apps. Tweaks are hosted on repositories or repos usually handled by Cydia. Default Cydia repos are community maintained and imply a certain level of trust and safety.

For the sake of this blog post, I’ve made a repo of my own:

GitHub – Adis

I won’t go into details on how to develop a tweak or host it on a repo since there’s a lot of work involved there, but my tool of choice for tweak development was Theos.

Back to work. Now that you know which method is responsible for making jailbreak checks, you’ll want to write a tweak that will override the behavior of that method. This is just a bit more of programming. Here’s the entire content of my own tweak:

// Class used to check for jailbreaks
%hook JBChecker

// Redefine the behavior of the function that checks
// for jailbreaks
+ (BOOL)isJailbroken
{
    return NO;
}

%end

The syntax is simple – %hook %end block injects itself into a class that checks for the jailbreak, and I rewrote the method that checks for jailbreaks to simply return false in all cases and skip any other checks.

In order to get this tweak on your own device, you’ll need to add a new source in Cydia. The app will warn you that this is not a trusted repo, and that’s fine. As mentioned above, only a selected few are trusted.

When the repo is there, you’ll find a single tweak called JBBad. After you install the tweak, go back and open the Jailbreaking Bad app. The app will – regardless of device status – report that the device is not jailbroken until you uninstall the tweak.

And a handy .gif with the boring parts sped up:

Not a lack of security in iOS apps

While the process described above might seem simple, it by no means implies that iOS apps lack security. Building truly secure apps includes far more than implementing a simple jailbreak check, and a threat that would justify the effort of blocking app usage based on jailbreak detection would have to be substantial and take copious amounts of work to devise.

The purpose of the article is to demonstrate that, at best, jailbreak detections are a tiny security upgrade. Such detections might only deter a part of your user base which is most likely well aware of the security issues a jailbreak presents.

The post Why Jailbreak Detection in iOS Apps Is Pointless appeared first on Infinum.

SSL Pinning in iOS Swift Edition

Adis Mustedanagic — Thu, 26 Oct 2017 17:23:00 +0000

[Update] As of January 2021, the code samples and the article has been updated to reflect recent changes in Alamofire 5 and Firefox. Cheers!

Some time ago, we published an article regarding the benefits of SSL pinning. If you haven’t done so already, read it – it covers a lot of basics taken for granted in this follow-up article.

Since almost the entire iOS development community has moved from Objective-C to Swift, preferences in libraries and networking have also shifted.

Swift-wise, our networking library of choice is usually Alamofire. As stated in the previous article, Alamofire handles pinning differently than AFNetworking and while neither implementation is wrong, sometimes you might have a preference for a certain method.

The two pinning methods

While AFNetworking talks only to the servers whose certificates you have pinned, Alamofire does it differently – you pin a certificate per domain, so the certificate check will occur only if you talk to the list of predetermined domains. For all other domains, no check will be enforced. AFNetworking, on the other hand, will block all requests that don’t pass checks for the certificates you have pinned in your app.

While Alamofire’s implementation may seem a bit weird at first glance, this kind of pinning offers greater freedom when defining different policies for different domains, e.g., a self-signed certificate for your development environment can easily be set up separately from your production environment without any preprocessor macros or common Objective-C practices.

However, for some apps, the only endpoints you want to communicate with are those you trust and have certificates for (e.g. mobile banking applications). In that case, you will have to do some handiwork to bring back the AFNetworking-like behavior.

SSL pinning cookbook

Alright, so your app is almost ready, and you want to add that one more layer of security with SSL pinning.

Getting the certificate

If your API is live, you can easily swipe the certificate yourself using openssl:

openssl s_client -showcerts -connect www.infinum.co:443 < /dev/null | openssl x509 -outform DER > infinumco.cer

Pinning with Swift and Alamofire

An example of security policy for Alamofire and pinning might look something like this:

     let evaluators: [String: ServerTrustEvaluating] = [
         "infinum.com": PublicKeysTrustEvaluator()
         ]

     let manager = ServerTrustManager(evaluators: evaluators)

In this example, we’re pinning public keys from certificates. You can either pin the certificates themselves (in which case you do a byte per byte data comparison), or just compare the public keys in the certificates. Public keys have the advantage of being a bit more robust since the server certificate can be renewed retaining its public key, so no app update is needed on certificate change. In practice, this isn’t a typical case, but more on this issue later.

To replicate the AFNetworking behavior we had before, you’ll have to subclass the Server Trust Policy Manager and override the default implementation. An example that simply stops the app from communicating if there’s no pinned certificate will look similar to this:

import Foundation
import Alamofire

final class DenyEvaluator: ServerTrustEvaluating {
    func evaluate(_ trust: SecTrust, forHost host: String) throws {
        throw AFError.serverTrustEvaluationFailed(reason: .noPublicKeysFound)
    }
}

final class CustomServerTrustPolicyManager: ServerTrustManager {
    init() {
        super.init(evaluators: [:])
    }

    override func serverTrustEvaluator(forHost host: String) throws -> ServerTrustEvaluating? {
        var policy: ServerTrustEvaluating?

        /// Smarter check would be beneficial here, theoretically, MITM attack can have an URL containing this string
        if host.contains("stackoverflow.com") {
            /// You could dig even deeper and write your own evaluator
            policy = PublicKeysTrustEvaluator()
        } else {
            /// Deny all other connections
            policy = DenyEvaluator()
        }

        return policy
    }
}

Everything is exactly the same as the default pinning implementation, except now this class needs to be used instead.

If your project uses the default networking, you have the option of not using AFNetworking or Alamofire at all, and just implementing the pinning on NSURLSession level. This is probably the cleaner way to do it than messing around with Alamofire since it allows more flexibility, and will not break in case the Alamofire API changes in the future.

You can either pin a certificate:

// Compare the server certificate with our own stored
if let serverCertificate = SecTrustGetCertificateAtIndex(trust, 0) {
    let serverCertificateData = SecCertificateCopyData(serverCertificate) as Data

    if pinnedCertificates().contains(serverCertificateData) {
        completionHandler(.useCredential, URLCredential(trust: trust))
        return
    }
}

Or a public key:

// Or, compare the public keys
if let serverCertificate = SecTrustGetCertificateAtIndex(trust, 0), let serverCertificateKey = publicKey(for: serverCertificate) {
    if pinnedKeys().contains(serverCertificateKey) {
        completionHandler(.useCredential, URLCredential(trust: trust))
        return
    }
}

Find the full code example in the repo here:

https://github.com/Adis/swift-ssl-pin-examples

Common pitfalls

Testing your pin

Unlike most types of software testing where the important part is to check whether something works, for pinning, you want to test that something fails as well. Specifically, you need to test that your app cancels potentially compromised connections. While setting up a man-in-the-middle attack might be a bit of an overkill, there’s a simpler way to test, depending on which of the two versions of the pin are implemented.

If your app allows communication with only one endpoint, then testing is as simple as making a GET request to an arbitrary site (just make sure it also has a certificate). The app should cancel the connection and the request should fail. Additionally, just make sure your API works as expected and you’re set to go.

Testing the case above might be a bit more tricky if your app is pinning a certificate per domain since making an arbitrary request to another domain will succeed as expected. In this case, you might want to pin a certificate from a different domain and attempt to communicate with your API – which, again, should fail. This, in combination with a successful test with the proper certificate and successful communication with your API will usually be enough.

Handling the certificate change/update

Although renewing a certificate for a domain can retain the private/public key pair (meaning your app will continue working), this is usually not the case. Fortunately, if you plan your update cycle right, you can avoid any downtime for the end users.

Before the new certificate becomes active on the website, you should pin it in your application, along with the currently active certificate, and release an update. Pinning more than one certificate is possible and works with the code samples above. In this scenario, be mindful that you convert the certificate to a proper binary DER format.

If possible, perform a quick test of the app with the new certificate. For this test, the developers handling the certificate on the API should temporarily use the new certificate and test your app with both certificates pinned. Everything should work, and if it does, they should revert to the old certificate until the app update is ready.

Parting words

This is where I nail the last argument and entirely convince you to use SSL pinning wherever possible, but that’s almost certainly unnecessary. Some apps won’t benefit from additional security measures, but for apps involving sensitive data, an additional layer of protection is never a bad idea. In that case, I hope the article was of some use.

The post SSL Pinning in iOS Swift Edition appeared first on Infinum.

How Two Men Delivered a Baby in 4.5 Months

Adis Mustedanagic — Thu, 06 Mar 2014 09:00:00 +0000

Every once in a while, we get a request out of the ordinary, and just sometimes we take the challenge. This is a story about one of those times when two men delivered a baby in 4.5 months. Figuratively.

Almost everyone working in software development eventually gets familiar with Brooks’s law. Another way of putting it is

Nine women can’t deliver a baby in one month.

Hence the figure of speech above. There are exceptions, of course, and this is one of them.

The quest

To conquer the unknown, of course. Long story short, we were given an opportunity to help out on a project that was late before we even started. The details were scarce, the job was on-site with the client at the other end of Europe, and the deadlines were just around the corner. After a quick round of negotiations, the deal was set: two men for four days, working on a big app that was yet to be released to the public.

The resolution

Skipping ahead to the end – well, it worked. We gave the project a much needed push in the right direction and set the grounds for working on it from back home. Looking back, I don’t think I ever doubted we would pull it off, despite the odds looking grim on paper.

Programmers in action

So, why the lack of concern, and even more important, why did things work out well?

For starters, a lot of mobile apps are in the scope of 1-2 developers to handle. Usually a single developer should be competent enough to handle an average app by himself, not including the API or other components outside of the application. This was the case here as well, with most of the work being done by a single developer, so initial project assessment took a negligible amount of time.

There was also the pressure to do what we were hired to do. Some people don’t respond well to increased pressure and lack of time, but in our case this probably added the much needed sense of urgency.

Isolation and focus can boost productivity drastically. Working on-site, with very little to worry about other than the project at hand, we could afford to concentrate completely on a single task that needed to be done at that moment.

Experience was also a key factor. This wasn’t our first rodeo, so we knew exactly how to handle certain situations. It was just a matter of coding the right solution and not wasting time on figuring it out.

The challenges and lessons

After working on the project on-site with the client, I brought it back home to work on it full time. There were quite a few hurdles to overcome with the combination of working on-site and working remotely, but it essentially boiled down to these:

Working with other people can be challenging if they’re not a regular member of your team. Get to know them and find common ground and a good way to work together.
Every company has its own development processes and prefers different tools. It takes a bit of time to fit into a different workflow (or even help someone ditch their workflow in favor of a better one). Switching to a newer or more suitable technology is often a short-term pain that proves to be worthwhile in the long run.
Sometimes, perseverance is the key. More than once, the issues kept piling up, but working through them was just a matter of persistence and systematic problem solving.
Developing a location based app while not being at the location turned out to be a lesser challenge than expected. A bike is a really versatile transportation method for simulating different conditions.
Skype meetings are mostly fine, but in-person meetings every now and then can give you a positive boost.
In certain scenarios, pair programming is a very effective technique. For example when a new programmer needs to be quickly introduced into an existing project at a later stage of development.
Always check the weather before traveling and dress accordingly.

The last one is probably the least significant for this article, but sometimes the simplest advice is the best advice.

The post How Two Men Delivered a Baby in 4.5 Months appeared first on Infinum.

iOS 7 SDK Is Mandatory. Upgrade Your Apps Now!

Adis Mustedanagic — Fri, 03 Jan 2014 11:00:00 +0000

Apple has recently announced that, starting from February 1st, all iOS apps and updates need to work seamlessly with iOS 7.

Link to the relevant announcement.

Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7.

In technical terms, starting February 1st, all apps submitted to the App Store need to be built with iOS 7 SDK and XCode 5. Anything that does not conform to these terms will be rejected.

In less technical terms, this means that your apps need to make use of the new iOS 7 design and interface.

What is the difference between iOS 7 SDK and the other ones?

The difference is mostly visual. For example, compare the two screenshots below; the left one is the Elements example app back in iOS 6 and before, and the right one is the same app in iOS 7.

This is also the fastest way to determine visually whether an app needs an update. If your app looks like the left one on iOS 7, you will most likely have to update your app to the new SDK.

Do I need to update my app?

There are quite a few ways to answer this question, and they all depend on what the future plans for your app are. The nifty flowchart below should answer most of your questions.

In a nutshell, if you are still not using the new SDK and have an actively developed app, updating is imminent, but you have a small time frame to push critical updates if you have to.

Does this mean that my app won’t work on older versions of iOS?

No. The SDK and the minimal supported versions of iOS are not the same thing, and your app will still work on old versions of iOS you want to support.

Is changing the SDK a lot of work?

It depends. Just switching the SDK is done in a jiffy. However, you still need to make sure there are no wayward visual elements. The design of every app is at least a bit customized and will probably need some tweaking. Adjusting visual elements might also be needed to complement the new flat design if your app looks odd in the new environment.

iOS 7 also brings new gestures, notably, the swipe-to-go-back, so if your app takes advantage of different gestures, another part of upgrading is making sure there is no unwanted interaction between the two.

To put it shortly – it depends on the size of your app and the amount of work you want done.

What will be the consequences of this announcement?

At the time of writing this article, the iOS 7 market share is at 78% percent and rising. Presumably, this is one of the decisions made to push the percentages up and make the development for previous versions of iOS obsolete. Apple is pushing hard to keep the users up to date with their release cycle, but there will always be a minor percentage of users who do not update, whatever reason there might be for not doing so.

For developers, this is a welcome change. Having to support more than the latest SDK is a rather complicated development process, and this will make things much simpler.

On the other hand, this decision also means more work for apps that have not yet been converted to iOS 7 SDK, and are planning an update soon, possibly pushing the date of the update a bit further. It also means that if you are targeting a significant number of users still using iOS 6, there will be some extra work to make sure everything looks as intended.

The post iOS 7 SDK Is Mandatory. Upgrade Your Apps Now! appeared first on Infinum.