 So thank you for coming to my talk on mobile devices. Hopefully it will be very interesting for you. My name is Michael Sosongin. I am the director of research and data at Cinec. And Cinec is a crowdsource vulnerability discovery program, so we generally have a team of people that discovers vulnerability for our customers. And so if you're interested in that, we can basically pay you for bounties for that. Occasionally we have customers that also want us to find out if there's a way to find sensitive information in their websites. So that would be more relevant for the recon crowd. So once a very sort of respectful person that I have lots of respect for has said that recon starts much earlier for many people, even though for most defenders, this is where they consider a beginning point. And so I'd like to share some of my tools and techniques that I've developed for building work ahead of the recon process in order to assist for the next step. Fundamentally, why is it that we are actually trying to do this? I mean, mobile applications are incredibly important in our lives. They provide things like privacy and freedoms and of course they give us access to our money. And so even though 20 years ago, this was really unimaginable. Today I would not even imagine losing any of those things or having them compromised is kind of scary to me. And so I'd like to sort of go through some of the ways of how we can work to protect those fundamental things that mobile devices provide for us. And so the first thing we kind of hope that there is a way to break in because if your platform is too secure then you can't really analyze the device and so jail breaks are very important for this situation. Pungu and Taig were very famous, I guess a couple of years ago and still sort of famous in a situation. However, their jail breaks are for earlier versions of iOS. Today would be more a jail break from this guy Luca Todesco from Italy. And so once you sort of get into your device, you jail break it. This first step is usually to analyze it statically. I like to use Ida Pro because it is a very good static analysis tool, it decompiles and gives you lots of inside information. Now when I started working on this, I actually did not know what ARM was and how to reverse engineer with ARM. As I was learning, I eventually built a tool called Ida Ref which provides documentation for each instruction, particularly useful for any sort of weird instructions that you might come across. Unlike other tools that give you hints, this one gives you the actual documentation that comes from the manufacturer and so even though it might not look nice, it actually provides very useful information directly from the source. Then there is dynamic analysis, that's usually the next step. So there is in process analysis using things like debuggers like Frida or LLDB and there is external analysis such as file monitor to see what sort of files the application is accessing or MITM proxy which is man in the middle of proxy that allows you to see the network activity of this device. I also built a tool called Upstee Trace which actually allows me to do sort of packet sniffing internal to the device itself. So which services does this application interface with and what messages is it passing in internally? Now the reason it works is because objective C is incredibly nice. It uses a messaging interface to execute functions and so if you can kind of hook in there and observe which messages are being passed around, you can observe what the application is doing in some abstraction layer. Next one is the Mach port messages. Those are useful for any sort of inter-process communication and so to discover what services the application is trying to interface with. In order to build this tool, I had to hook a function called abjc underscore message send. It is a central function that dispatches messages between different parts of the application and actually executes the codes internally. So it's a very much a bottleneck for logic. And so I had to patch that and I was able to actually determine what all the things it was doing. Now in order to make it work, I had to make an optimization because otherwise it slows down too much. It's a very, like I said, it's a central function. And so what I would do is if a function appears in a cache, which means that it got executed before, I don't record it and therefore I only record method functions that got executed at least once. And so that provides me coverage information to see if my testing has actually given me good sort of coverage space of the entire application. Same thing I did with the mock messages. However, it produces a lot of messages and so I needed a way to parse it. I called it mock shark. As you can see, it gives me lots of interesting information and allows me to filter things down. At that point, yeah, so I wanted to mention at that point you can start sending these messages to the cloud and start doing correlations and all kinds of services like that. So that seems very manual. I wanted to find a way to sort of automate things. One of the difficult parts with iOS applications is that all of them are pretty much user driven. There are not really many applications, at least I can't really think of any, that are fully automated or at least partially automated. Everything is pretty much starts with the user. And so I needed to find a way to trigger everything and to make the application do work so that then I can observe what it is doing. So I built a tool called chaotic march and this tool essentially injects inside of the application and will trigger various events. Why would I want to do that? Well, I mean, it's time saving. It's repeatable, which is very important to me. It's a good way to discover web API so things that the application is trying to interface with or internally which services it's trying to interface on the device itself. And like I said before, it's good for coverage information. Have I observed the entire attack space of this application? It's a chaotic march. I wrote it in March and it was kind of chaotic for me. So. And when I started sort of thinking about this problem, I had sort of two major ways I could have gone. One of them was to simulate the user, essentially get a camera or some sort of artificial intelligence pointing at the device and then clicking around, typing things in, clicking buttons, et cetera. However, that's kind of over my head and so I decided to go the easy route by injecting inside of the application and then observing what it is doing there, how the structures are connected together and then triggering on internal states. This is what the UI looks like in memory when you actually go inside of the application. It's a nice tree with well-defined objects. There are fields that have lots of interesting information and there are functions that you can execute on top of those fields. So chaotic march, it is a lower scriptable application. So you can pretty much create any type of logic that you like. It is good at finding UI components and it's very lightweight so it's very good for pretty much any type of application. This is what a basic script might look like. So if I want to run through the entire thing and I want to click all the buttons, fill in all the form fields and generally make the application do different things. This is kind of what it looks like when it all comes together. I have a little monkey, even though it's actually a chaotic march, clicking around, doing things and it's triggering the application and then there is a minimal proxy that actually manipulates any network information that goes through and it sends it back to the application upon return from the server. Now I do this because I want to trigger things on the application as much as possible so if I mutate certain responses then I can make it give up more things for me. All right, so the applications for discovery are huge. Web API is one of the big ones. Every time an application kind of reaches out somewhere even if I don't authenticate it sort of tells me what it is that it's looking for. Oh, I'm looking for this image. I'm looking for this entry in the database, et cetera and so that opens up attack surfaces for me. Local behavior is pretty big for this one so any sort of files, IPC, any sort of infrastructure that it tries to access and it's a good way for me to determine which things the app considers important, which things the vendor considers important and sort of give me sort of samples that I can work with further on in my analysis. So this is something, this is what it looks like so when I sort of run this loop, I have an application, it's a Russian, it's called Adna Klasniki which is the social networking site for famous in Russia and when I try to essentially get it to log in several times it eventually gives up a whole bunch of infrastructure and points that I can later analyze afterwards. So like you can see I highlighted four of them down there. So when I made this right, I was very hungry so there's chocolate in there. The other mechanisms that I can use for assisting with automation of this stuff is essentially trying to rewire the application. So if we look at this example, I had the private wealth management application from Goldman Sachs because I have about $10 in my account so I felt like I really needed it but I really wanted to get more so I wanted to find out what my attack surface would look like if I was gonna do more things. So when I just try to log in, I really get only about two, three, or maybe four things that I can then attack. However, what I tried to do is rewire the application internally and you can see on the bottom, maybe some people on the back can't really see it but what I did is I essentially changed the function for accepting an authentication response to always return true. And so what this means is that when I enter a username and password and I say login, the application sends the information out but then the service says oh I'm sorry that's the wrong password I can't really do anything about. However the application thinks that the login was successful and so it will go on to the next stage and reveal more things that it's trying to access. And so here I didn't highlight all of them but there's tens or so interfaces that it's trying to access. It gets an error for pretty much each and every one of them but it gives me samples that I can then use for fuzzing. It gives me more information about the vendor infrastructure and essentially I can now have a better idea of what it is that I'm facing in case I want to actually learn more about you know, whoever wrote this application I don't know who this might be. So I thought that was pretty interesting putting it together. This is the picture we get. We can start manipulating the sort of the interface from the application to the vendor and then I can start manipulating the interface inside the application itself and basically just get it to give up as much information as possible and then put it in my notebook and gather it up for my next steps. So that's pretty much it. There's lots of possibilities here. Applications obviously are important. Freedoms and such, those are great things. Automation is always useful so if I can recreate my tests as much as possible if they released a new tool, a new application then I can rerun through my tests and actually get to see what changes happen there. And of course I really like the idea of being thorough so here if I'm running it through an automated mechanical tool then it's more likely to be thorough than if I'm sitting there and clicking it on my own. So that's pretty much it. I hope you enjoyed it. If you have any questions please catch me here in the hallways online. Yeah, now if you have any questions. Thank you. If you want more low level details, debugtrap.com pretty much everything is laid out. There's lots of information there. I tend to blog before I talk. In case of DevCon I really can't because they don't allow it so I will write up the blogs and then post them online anyway. Unfortunately you do need a physical device just because Apple is so stringent about allowing people to virtualize things and so that's why jailbreak is necessary. Potentially if you are the vendor of the application you can try using the simulator so you can build the application and then run through it and then see what stuff you can get it to give up. Android is a lot easier because jailbreaking is sort of nonexistent there. You just kind of enable debug mode and then you can start plugging things in. In fact, Google actually builds, I forget what it's called, it's monkey something. Tool that you can inject and then you can script the same stuff that Karek March allows you to do. It's probably more advanced as well. Any more questions? Yes. This one? This tool is called script. Some people pronounce it as a side script. Basically it injects and gives you this interface where you can sort of live analyze the application. Cool. Well thank you for your attention. Check out Cinec.com.