So thank you for coming to my talk on mobile devices.
Hopefully it will be very interesting for you.
My name is Michael Sosonkin.
I am the Director of Research and Data at SYNAC.
And SYNAC is a crowdsourced 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...
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 jailbreaks are very important for this situation.
Pangu and Taig were very famous, I guess, a couple of years ago, and still sort of famous in this situation.
However, their jailbreaks are for earlier versions of iOS.
Today it would be more a jailbreak from this guy Luca Tedesco from Italy.
And so once you sort of get into your device, you jailbreak it,
the first step is usually to analyze it statically.
I like to use IdaPro,
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 IDRF, which provides documentation for each instruction. It's 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's in-process analysis using things like debuggers like Frida or
LLDB. And there's external analysis, such as file monitor to see what sort of files
the application is accessing, or MITM.
proxy, which is man-in-the-mill proxy, that allows you to see the network activity of
this device. I also built a tool called Objective-C 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 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 Mac 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.
It is a central function that dispatches messages between different parts of the application
and actually executes the codes internally. So it's 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's not going to work.
It slows down too much. It's a very, like I said essential function.
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 functions that got executed at
least once.
So that provides me coverage information to see if my testing has actually given me good
coverage space of the entire application.
Ah...
Yes?
with the mock messages. However, it produces a lot of messages, and so I needed a way to
parse it. I called it Mockshark. 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. You know, one of the difficult parts with iOS applications
is that all of them are pretty much user-driven, right? There's no ‑‑ 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 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 ‑‑
It's basically 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 APIs or 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?
So what's the name of the app?
It's 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, 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.
So Chaotic March, it is a LUA 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. So, this is what a basic script might look like. So,
you can pretty much create any type of logic that you like. So, if I want to run through
the entire thing and I want to find all the things that are missing, I can pretty much
This is kind of what it looks like when it all comes together, you know. I have a little
monkey, even though it's actually Chaotic March, clicking around, doing things, and
it's triggering the application. And then there is a man in the middle proxy that actually
manipulates any network information that goes through, and it sends it back to the application
upon the 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 server, I want to trigger the application
certain responses, then I can make it give up more things for me.
All right. So the applications for discovery are huge. You know, Web API is one of the
big ones. You know, 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. You know, 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 an AdWords application.
AdWords 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 endpoints
that I can later analyze afterwards. So, like, you can see I highlighted four of them
down there. So when I made this ride, I was very hungry. So there's chocolate in there.
And 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 going to do more things.
So when I just tried 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 user name and password
and I say log in, 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 it.
However, the application thinks that the log in 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, you know, 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. You know, 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, you know, gather it up for my next steps.
So that's pretty much it. You know, there's lots of possibilities here.
You know, applications obviously are important, you know, freedoms and such.
Those are great things. Automation is always useful.
So if I can recreate my tests as much as possible, you know, if they released a new
tool, a new application, then I can rerun through my tests and actually get to see what
changed.
Changes happen there. Now, 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, if you have any questions.
Thank you.
Pretty high level. There's a lot of stuff going on.
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 DEF CON, I really can't because they don't allow it.
So I will write up the blogs and then post them online anyway.
So do you need a physical device to do this, or is it part of the process?
Are there any, like, virtualization or simulation techniques that you can do this with?
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. So that seems pretty good.
That's a good question. But how does it apply to Android devices?
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 a tool that you can inject and then you can script the
same stuff that chaotic march allows you to do. It's probably more advanced as well.
Thank you.
Thank you.
Any more questions? Yes?
During your rewire, what tools ?
This one?
You need to force the logging to be true.
This tool is called Script. Some people pronounce it as SciScript. Basically,
it injects and gives you this interface where you can sort of live analyze the application.
Okay.
Thank you.
Cool. Well, thank you for your attention. Check out synag.com.