Testing iOS Apps Without Jailbreak in 2018

Thanks, thanks for the answer. I was dragged out of the break, almost. So, practically for the last moment. As I was already introduced, my name is Wojciech Herkula and today I will have the pleasure to present a presentation entitled "Pentests of iOS PSJ Break application in 2018". I would like this presentation to be a discussion, if not now, then after the presentation or during the Q&A. I will show you my pentesting workshop. I tried to make this presentation accessible for people who are directly connected to iOS, but also for people who are not. So, to introduce myself a bit deeper, I am a pentester in securing. By the way, my twitter email will be displayed throughout the presentation, so feel free to

comment, or contact me if you want. It's a project called Security Knowledge Framework, where I created safe code examples in Ruby, in Ruby on Rails in general. I also set up a school on Github and I'm blogging in my free time. The link is below. Okay, let's move on to the agenda. At the beginning, I would like to introduce you to the topic of pen testing in the iOS system, what it looks like. Next, we will talk about jailbreak, what is the current situation and what are the plans for the future with jailbreaking. Then we will move on to the merit of the presentation, which is what this presentation is about, i.e. testing without jailbreak. I would like you to They have a skill of

testing what I will show you and you will be able to do it at home. So I prepared an article for you at the very end, to which I will also give a link, so that you can repeat it. So in this point A we prepare the environment so that you can configure it in the simplest way possible. And then we will test it properly, as in any presentation, at the very end, summarizing. So you've learned something about me, you've learned what the presentation will be about, so now I would like to know something about you. The first question will be: who of you uses the iOS system every day? Okay, I think almost half of the room. And who of you

is directly or indirectly involved in testing mobile applications, whether Android or iOS? Okay. Now the third question, which is a combination of the previous two. Who of you uses iPhones and tests iOS applications? I see that a small part of the audience is here, so I hope you will learn something useful from this presentation. I will start with the question: why do you even deal with iOS? And here I have an economic training, so for me, charts, drawings, money are talking to me. Here we will show you what the IOS market looks like. And as you can see, in May 2016, In Poland, 5.2% of users used to use iOS devices. In May 2017, it

was 5.6%, so the trend is growing. By the way, look at Turkey, because here, in general, 19.4%, almost 20% of people have iOS, which is also a very interesting phenomenon. And listen, this is... You know what? Probably yes, it was done by Jimmy. So I think these are official data. Ok, and this is economic statistics, but not everyone knows it. That's why I prepared another statistic, which tells me even more. If anyone has any questions, there's a man with a microphone behind us, we raise our hands and ask questions like in school. So that the stream can hear the question, because later it's like that, you can only hear the question, you can only hear the answer from the prolegent, okay?

You've just entered the joke, but I can look at the chart here, regarding sexual activity between iPhones and other users of other operating systems. I have to say that it's an unquestionable height as a fanboy. So, do we really have to check the security of the application in iOS? We all hear that the iPhone is the safest, or that in general, compared to other operating systems, everything is super done here. We hear about these different bypasses, about magical amounts for finding some liability. So, a user who is not directly connected to iOS may have the impression that there is nothing to do here. We even heard recently, in 2015, there was a push-over between Apple and FBI, where a terrorist was caught with an iPhone

and FBI had to get to the iPhone and see what was inside, in the file system, but every disk in the iPhone is currently encrypted. And here was a push because FBI wanted to get back the encryption key from Apple. Apple was like: "No, guys, we are entering the key into the stiff and we don't have access to it, we don't store it anywhere on our servers, so there is no way to decrypt it." So, if American services had this problem, we can think that it is safe here. But not every application in iOS Apple developers wrote, or rather most of them wrote, which sometimes made mistakes too. But programmers and a very wide range of

applications in App Store caused a wide range of errors. I wanted to show you a few mistakes that I hope they are not unsticked, because the security is already very high, but I wanted to show you three problems that are currently occurring and that have a very big impact on the risk. So, a question for you: who is familiar with this logo? Please. Exactly, this is Cordoba. Cordoba is a framework which allows us to write multi-platform applications using web languages, so in HTML, CSS, JavaScript we write an application that will be run on our mobile devices. And now the question arises: how can an application written in HTML have access to system resources, such as photos, contacts, a microphone? After all, the language of HTML or

JavaScript does not provide such functionality. That is why something called JavaScript Objective C Bridge was created. That is, JavaScript is able to call native methods. It works more or less like this, without getting too much into this drawing. Generally, we have here our HTML engine, plugins that we install in Cordoba, and these plugins already call in native methods, which allow them to access system resources. And now, listen, we are finally security guards, and when we hear that JavaScript can produce native methods and have access to system resources, then such a lamp should light up in your brain. Well, imagine XSS, which appears in a mobile application, because we connect with some backend, and through such an attacking XSS it is able to detect our

contacts, photos that we would not want to leak into the daylight. Everything that the application has access to, so we agreed that the application will simply gain access to it. So the attack scenario is as follows: we take one JavaScript, for example, and we can interact with the system resources. Another problem may be ATS, i.e. App Transport Security, introduced in iOS 9. It is a mechanism that was supposed to force developers to use encrypted connection I'm sorry, using cryptographic-related strong-willed passwords. But each of us has some experience in programming. I realize that sometimes we deal with servers that are not able to fulfill the latest sets of passwords for various reasons. Or the latest TLS,

right? That's why we had to turn off this mechanism by adding a special flag to the info.plist file. And what did it allow us to do? We had no control over our SSL connection at all, which of course enabled us to set up a so-called MITMA on iOS applications. And here, afterNix did some research. He researched 200 applications and it turned out that 166 of them had ATS off. So these applications were also vulnerable to men in the middle attacks. As you can see, it's a pretty big percentage of applications. Another vulnerability can be zipper down. Zip-R-Down is a feature that I have mixed feelings about. I'll show you why in a moment. But it's a path traversal in a

zip. So when the application downloads something that is zipped, it is unpacked. we have a file with a name, including the path, and it is able to write something in our container. Now imagine this example with Cordova, where writing a JavaScript file allows us to steal photos in the phone. So, the severity seems serious. I started googling it because it didn't give me peace of mind. We've heard about this kind of privacy in ZIP a long time ago. So I checked it on the website. It is 1991, so this privacy was already discovered before my birth. As we read here in the article, I marked it in red, you could work from there doing dot dot slash etc. or whatever. So it's a

very old application that has come back after years and it has become a big hype. Dark Reading even wrote an article that over 10% of iOS applications are subject to the fact that we are able to write any file within the application container. Of course, I remember that every application in the game is sandboxed and it has no access to containers of other applications. So directly. So I think we've answered the question whether iOS security is as everyone says and whether these applications are safe by default. As you can see, it's not. So now we have to decide what we have to check. And here we have OWAZ, which created MESVS. Here are 7 points and one additional one

with protection against reverse engineering. So as pentesters we have a list here. It is very convenient for us and therefore these tests in various companies can meet the appropriate standards if we all stick to this standard. Ok, so we know what to do. Now I would like to divide our penetration test into two stages. We move to a poker scenario, we start a game in poker and the moment we get the cards, but we do not observe our opponents at all, we just look and analyze, in pen tests I call it static analysis. Then, when the game starts, we look at the faces of our teammates, whether they are twisted or if someone is starting to get nervous. At this point,

we are dealing with dynamic analysis. A few examples. Of course, there are not all examples, only for the outline. We have excessive data in the package. So, before installing the application on our iPhone, we just check if there is something in this excessive package. Are there keys, for example, AWS? It can be some things, some encrypted passwords. or encoded somewhere in the application's package. We check for binary security, i.e. whether the application has been compiled with the appropriate flags. We check for omission of source code, or the mentioned ATS or iTunes file sharing, or something excessive, if it does not display. Now let's move on to dynamic analysis, where we check the files saved when the application starts. It sometimes saves something, often

excessive, what data is in the keychain, i.e. in the safest place in iOS. sorry, the "custom-to-buy" URL, that is, the inter-process communication in iOS, how it looks, whether it sends something sensitive or dangerous in a safe way. Logs of the application. I saw a few people here in the room connected to iOS, and now think about what we need to have to check the logs in the application. We need to connect the phone to the computer, enter the password, We need to trust our machine to connect with it, run Xcode or any other program that has access to our logs, and then log in and see if something is stored in these logs. So the conditions for using this vulnerability are currently very

high. As for security, it's not just about the typical technical risk, but also about the risk of image. For example, Starbucks had a big drop here. As you can see, the article is for "independence", let's say for serious business. a serious information portal, where Starbucks supposedly had "Leaves password unencrypted" and users are in danger. So you see, despite the fact that the tax is absurd, I think that anyone who is in the security department would not want to be on such an information portal. So even though the taxes sometimes have absurd conditions for use, So we have to deal with them. We have Certificate Pinning, we have Cache applications, sensitive data even in Snapshot. This is also something

that we are taking our dynamic analysis against. This is key for example in relation to banking applications, which can, for example, store some data about our account in Snapshot and the attacker can get access to reliable data. Ok, so I've talked about jailbreak. This presentation is about penetration tests without jailbreak. So I'll answer the question: what is jailbreak? In a nutshell, jailbreak is the ability to create a code that is not signed by Apple, which breaks the sandbox. And generally, we have access to what iPhone normally does not give us access to. We can create our own application, modify iPhone, etc. So what do we need it for? For most of the dynamic analysis, and this

is also a bit weird, because not everything is dynamic, but it's more difficult. I'll give you an example: keyboard and checking the cache of the keyboard. In case of jailbreak device, we run the script and see everything that is cached, so there is no problem here. In case of a device without jailbreak, it has to cache the entire cache in the keyboard at the beginning, go to the application with our dedicated field, enter something, click OK, go to another application, start writing the same row of characters and see if it is not submitted. But you see, it is time-consuming, it is more difficult. So some things are possible. Some things, such as the typical access

to Keychain, we will not do without Jailbreak, that's why we need it. I'm sure we will do it, but not certain things. And to the static analysis, if we don't have a package, the so-called IP, Generally, with IPAM, every iOS package is encrypted with the key of our device, corresponding to a mechanism called Apple DRM, also known as Fair Play. So, generally, if we have a jailbreak device, we will not get access to the package, at least the encrypted one. That's why the solution I'm going to try to offer you today is not ideal for people who deal with bug bounty. Because most often we don't have this package in bug bounty. We have to download and decrypt it ourselves. In

the case of pentests, which is what I do, we get a normal package from our clients and we can try it. Of course, we can install it and see what's in this package. Let's see how the situation with jailbreak looks like. It looks like this. Currently, this is a screen from two days ago. iOS 11.4 and above is not jailbreak. Previously, it was even more problematic. This year was really optimistic for us, especially with regard to jailbreak, because there were enough jailbreakers to cover all devices with them. But in the past, these jailbreakers are coming out less and less. Generally, there are a lot of problems with jailbreaking such devices. Here's a small update. I had to update the presentation

and of course refer to what happened at the last Apple conference. So, if you followed, you know that the new iPhone XS, XS Max and XR has come out. But what is important for us as pentesters is that they have a chip, a processor called A12. Apple boasted that AI needs to get funds for startups. What is important for us as pen-testers? This processor is implemented by ARM in version 8.3, and there is something called Pointer Authentication Code. Here you have a detailed link if anyone of you would like to get acquainted with it. The presentation will of course be available, so you don't have to write it down now. But generally for us, as pentesters and for people who sometimes want to create a jailbreak,

it means the end of return-oriented programming and jump-oriented programming. So something that allows us to exploit it further when detecting a vulnerability. However, for example, errors such as useAfterFree and typeconfusion are still possible. Here is another update from September 27. I think that the well-known person from the jailbreak world has just shown the omission of this package. Technical details are not yet known, however, as we can see, it may be possible to omit this package and not be a problem for us. However, it is not public yet. Another question, as we are used to it in this presentation. If I am a security guy, why wouldn't I do the jailbreak myself? I have already developed a bit, I have

been telling you about it for more than 15 minutes, and you still don't see why it is so problematic for me. And here is another financial example. Well, almost a million dollars, exactly a million dollars for a remote jailbreak on iOS 9 with Iriodium paid. Generally, the whole Mendeleev's app looks more or less like this. Here you can see zero click for 1.5 million dollars on iPhone Remote Jailbreak. So this may be an argument why we are not able to create this jailbreak. So we know that we rather have to jailbreak our device to conduct a penetration test. So we jailbreak iPhones in Pentester company, because we have to do it. It turns out that it's not that easy, not that fast. And now

we change the mood a bit, we enter a more risky one, I would say. We take part in the lottery. Unfortunately, we didn't manage to jailbreak for the first time. Why? Jailbreak is on our iOS version, but on 32-bit processors. For example, I have an iPhone 7 and it was on iPhone 5. So it didn't work. Another attempt. Unfortunately, again a fail. Here, Jailbreak was very hardware-based, because it would use a bug in the controllers only in iPhone 7. We failed again. Another attempt. Jailbreak from iOS X 3.9 and we have X 3.8. So, listen, it started to get boring, generally, all the time fails and it's boring to me, but imagine our situation now when we have to conduct such a test,

because the client paid for it and the client doesn't care that we have something wrong with the environment, that we don't have an iPhone to conduct this test on. If the client pays, the client demands it. We are in a situation where we have iPhones, we cannot downgrade our iOS and that's it. We are not able to handle it in any way. That's why we still have to participate in this lottery.

We failed again. Why? Because Jailbreak is somewhere. Someone made it for our version, but it's not public. Okay, so once again. I can see the irritation in the room. We lost again. Here again the situation is the other way around. So Jailbreak is for version Y3.9 and we have 4.0 and that's it. But listen. Sometimes we managed to jailbreak, sometimes someone wins at the lottery. But as you can see, it's not a good solution. We wasted a lot of time, we have to have a lot of phones, we have to rotate the versions, we have to keep some versions, because maybe something will appear in the future. So for us, as pentesters, it's not a good solution. Let's face it.

We have dealt with it in the following way, which we come to the merit of the presentation. Now it will be more technical, not the narrative part. Let's start with explaining the concept of Dylip. Dylip is something like DLL on Windows, i.e. Dynamic Library. What is the whole idea? We have a package of applications, we draw a binary from it. We connect our library to this binary, which we have control over, which will communicate with us. We of course install the application on the device. And at this point, because it is a library that is in the process memory, it has access to the entire process memory and can do everything the same as this

application. So, for example, we have access to the keychain, we have access to photos, to everything that this application has access to within this sandbox, our container. So that's the idea. We will try to go through it together so that you can repeat it at home. In our case, we will be injecting Dairieb Freed, such technical for people who deal with iOS. I have chosen the Etsy application. Etsy is a cool e-shop, it has Bug Bounty, so I can use their package publicly. So we have IP. We behave as if we had a typical penetration test. We have to prepare two things. The embedded mobile provision file and the certificate for which we will sign the application.

Embedded mobile provision contains information such as app ID, team ID, ID, sorry, the rights that the application has, certificates. or Provisioned Devices, which are our iPhones that can be used in this application. However, Signing Certificate has... I had to darken it a bit, but just so you know how to get to it on Mac, we write such a command and see our certificate IDs. How to do it? The easiest way is to open Xcode, which is a programming environment on Mac. We create a simple project. an empty project and click here "Automatically manage signing" and everything that is left is done for us. We choose our iPhone here, which we have currently connected to the cable, click "Build and run", everything is included and

Generally, we have applications and these two things I mentioned earlier on the iPhone. As I said before, I wanted it to be easy for you to repeat, so that you don't have to spend $100 on a developer certificate. So you still have one additional step, you have to go to the settings and trust this application, because it is an application that comes from outside the Apple Store, so we have to trust this certificate by hand. It is a free certificate that anyone can make. Step 2: connecting your own library and modifying the file. IPA is generally a zip. When we unpack and go to the payload catalog, there will be a framework catalog where all

our DLIBs are listed. I will show it theoretically, because I will show you the tool that automates it. But so that we all theoretically know what we are standing on and what it all looks like. You have to add a DLIB here. But we also need to modify something similar to the import table. So we need to add a command lcloaddelip and add our own delip. Here, for example, I showed that Etsy uses AWS. It is AWS delip, I don't know if you can see it marked here. So, at this point we use a tool that will automate the second and third steps, i.e. it will add a delivery, repackage and sign the application. We select

our certificate and use Objection to patch it. We select it in the IP source and we have a prepared application package. Next, we enter the debugging mode on our device, i.e. at the beginning we unzip this signed package.

Then we use a software called IS Deploy with proper flags. We will do it all in a moment. This step is for the live demo. We will repeat it on purpose, because I want to show you one more thing on the way. We have to wait. The application is now installed. As you can see, it has already appeared here, on our iPhone. Now we wait for our debugger to come, i.e. LLDB, the standard Mac one. It will take a while. It's just connected, the application has started and it is now in a state of holding. We want to know what this application does when it starts for the first time. If we started it and only then connected, we

could lose some key activities that it creates. In this case, when it is configured so that when we connect our tool, the application will only start fully. We have the application. installed on our device, which has our Dylip, which listens to the appropriate IP and port. And now we have to connect somehow to it. We have a few options here, I have mentioned four. In this presentation we will use Passionfruit, so kudos to the creators mentioned below. As I said, I would like this presentation to be a discussion, so if you have any better solutions, if you have any better software that can communicate with our Dlib, then of course I invite you to discuss and exchange knowledge.

Okay, so I think we can now move on to the live demo. I'm curious if it will work, because you know how it is with live demo. I'm going to connect the iPhone. It just hung up. So maybe it's safe, but not without problems. In the meantime, we can prepare what we will do next. I'm going to run the terminal. I'm going to cheat here. I'm going to copy the command. Is the text visible to you? Not yet? Now it's okay, right? So let's start QuickTime. Of course, we take the iPhone. Let's hope it will start. If not, then of course I have backups, taught by experience. But it started, so it's good. OK, let's split the screen

like this. So listen, we do it again. What we wanted, i.e. iOS DeepLoy. Something just didn't work. We give our application here. flag -w, so that we do not use the wifi and debug mode. We are entering. I have already installed the sim, but let's run it again to show you that it actually works. I'm on a train today, so I hope it works. Once I had a situation that I checked 5 minutes before the presentation, of course, it did not work for the demo. Some Python errors have fallen, but it should be run further. Okay. And we got to the point where we were before. So let's turn on Passion Fruit. Let's turn on

Safari. Let's type Passion Fruit. OK. As you can see, our iPhone appeared in Passion Fruit. Let's try to zoom in. I think so. OK, so we have our free gadget. The application should start now. We don't have internet connection, but it's not the key for us. This exciting moment has just come because we have access to all the application resources where it was never possible without Jbrake. So you can see, we have information about all flags, we have an infopelist, we have Entitlements, we have URL schemes that we can test. We have everything that our application normally contains, so for example, let's go to the library, we can check the cache. Shared preferences, everything that we normally check during the traditional penetration test. We

can list the modules of the application, classes. This is not a presentation that is to discuss the program, I just want to show you everything that is possible. We can look at all the hooks, what exactly is happening with our application. There are so many of them that it's a bit too much. That's why I want to exchange knowledge, because as you can see, it's not the perfect program. So if any of you know better, I'll be happy to find out about it. OK. Hello. Let's go to the UA Dump. And now, the cream of this presentation, so without jailbreak, we'll get to the Keychain. It's not possible in this case. I'll show you how to do it in

a moment. We see all cookies because here we have a webkit, user defaults, everything you want. So when it comes to live demo, I think that's it. Now let's go through my backup. This is what happened to us a moment ago, sometimes there are crashes. As open testers, we have to deal with it in some way. Using such a tool, for example, Objection, we can dump the whole keychain with all the flags, etc. We have violated the safest component of the iOS system on a device that is not jailbreakable. Let's go to the summary. As I mentioned, the situation with Jailbreak is currently very unstable. It is getting better, but as you can see, it is quite problematic. I told you about this lottery and so on.

That's why we came up with some methods to carry out these tests effectively. It's a bit time consuming, we had to work a bit to set it up, it doesn't always work. So there is a method that we have to use now, because there is DGS with jailbreak, but But let's hope that one day we'll have a better one and that the jailbreaks will be running regularly. So, there are two problems with this method. The first problem I mentioned was that it's not a good method for the participants of bug bounty programs. Forget about that, because we don't have access to the application packs. It's not feasible and that's how I need to use the jailbreak. This method doesn't make sense in this case. The second thing

is to remove the pinning. In case of jailbreak device, we install kill switch, which works in most cases. We turn on the kill switch and our application has the pinning removed. There is no problem here. In this case, we have to use our freed methods, prepared earlier. It is more time-consuming than in the case of this classic method. Here is an article I prepared for you, for all those who would be interested in repeating it at home. Here is exactly what I said, only written in points and with commands. I'll give you a moment, because I see that there are quite a few people here who are taking pictures of this QR code. Yes, probably everyone. And if you are generally interested

in the security of mobile applications, but this topic If you don't want to go into the technical part, we have prepared another article with securing colleagues, which is more general, about how to secure your mobile applications. I will also give you a moment to take pictures. Everyone? I think everyone. And I'm ending my presentation with a question: how do you deal with a problem? Maybe you have better solutions? Meanwhile, thank you for your attention and I invite you to contact me. I have one question before I give you a diploma. Tell me, how often does it happen to you, because you have an iPhone, I understand, your private one, how often does it happen to you, I don't know, to buy an

iPhone and take it in your hand and wow, it hacks it. Very often. Generally, I'm doing research on Apple. So, apart from conducting penetration tests, I'm now getting deeper and deeper into iOS and Mac internals. I already have a few bugs in my account in Apple. So, quite often. Any more questions? Okay, Wojtek, thank you for being with us. I hope you'll stay until the end, so you won't run away. I have a diploma for you. Here you go. Thank you very much. A big round of applause now.