- When it comes to investigating iOS applications,
there's four primary areas of focus.
Data storage, network communications,
platform communications
and then finally reverse engineering.
Trying to get to the operation of that code.
Starting with data storage, files on disk.
So iOS applications execute and are installed in a sandbox.
These applications cannot interact with other applications.
Whenever you create your native application
and you create some data and you say, "I wanna save it."
There is something called a secure storage API.
It is available for developers to use if they choose.
And that's a key point there.
What would be faster, taking a blob of binary data
and simply writing it to disk
or dealing with encryption, et cetera
and having to set the protection class on the data?
The first option is quite a bit easier.
Second option takes some work.
However,
if it is used, it is very secure.
If it's not used
then maybe you can get access to that data.
So secure storage API, it is hardware-based encryption.
So there's a chip inside the iOS
that accelerates the encryption of data.
Data flows through it,
comes out encrypted on the other side.
The key for this data is derived from that device UID.
That's a unique identifier
that I talked about in the previous lesson
as well as the user specific passcode.
So if you type in, you know,
085632, that's not my passcode, by the way,
but that's your passcode.
That plus the device UID becomes
or are used as input to derive a key
for the encryption of this data.
It's four different protection classes available
for use.
Protection complete,
what this does is when you lock the device,
the data is no longer accessible.
Once the user unlocks the device,
then they can open the application, get access to the data.
And then we have further protection classes
that become less secure,
all the way down to NSFileProtectionNone.
So that there is no protection here.
You can also, or developers can store data in the keychain.
However, it's only for small data.
You can see here, we have a four kilobyte soft limit.
Also the keychain that's built
into iOS is mostly open source published by Apple.
You can go take a look at it, try to find a vulnerability.
If you do find a vulnerability
in Apple's published keychain, good for you.
You might want to get in touch with Apple and let them know.
So there was a question.
Someone was trying to store megabytes
of data in the keychain.
And I found a forum post
where I got this particular information from
and someone dug into the source code
and this particular definition right here.
Reasonable secret data size of four kilobytes,
written by Apple many years ago,
they found that there's your limit.
If you go over 16, it's gonna kill it.
But the definition in the code is four kilobytes.
For databases on disks,
so databases are not necessarily only used
in web applications to store data.
We can also have databases in our device, in our iOS iPhone.
The SQLite databases are what is available for iOS.
There is a library written in C++,
it's a wrapper to SQLite 3
and allows you to store data in a database
in a file inside that sandbox.
Also Firebase databases are available.
Actually let me go back a second.
So these SQLite databases, they are an actual file.
That's one of the cool features
of SQLite is that the entire contents
of the database is stored within a single file.
So SQLite's available to you.
If you can get access to the disk,
that sandbox where the application is stored
and you can get access to that file, extract that file,
then you can actually read that database.
Next up is Firebase.
So Firebase is a service from Google,
it's available for iOS and Android.
It provides frameworks or libraries to integrate
with your applications to give you a local database
that is synchronized with the cloud.
So whatever changes happen in the local database,
they're reflected in the cloud
and vice versa, stays synchronized
whenever internet access is available.
Now, back in 2018, this person right here, Shiv Sahni,
discovered a misconfiguration vulnerability
in the Firebase service.
It's called the hospital gown vulnerability.
And at the time, this was 2018,
one in 11 applications was vulnerable to this.
This particular Python script here,
Firebase scanner, scans for that vulnerability
against Firebase instances.
For the network, we talked a lot about sniffing
earlier on in this course.
Same concepts apply here.
These iOS applications are most likely going to need
to talk to the internet, either to a backend cloud service
or simply to a public service
in order to grab data, to display to the user.
What information can we get
from those network communications?
There's a couple applications listed here, Burp Suite, ZAP,
as well as Bettercap in order to capture network traffic
as it is flowing across the local network.
So if you have an iPhone, you install an application on it
and then you want to analyze that application
and its network traffic.
You join it to a wifi network that you control
or maybe using the tools
that we talked about in the previous lessons,
you stand up a soft access point on your laptop.
You join the iPhone to that soft access point
and start sending the data through your laptop.
From that point, you can get access to all the data
that's flowing through there.
Burp Suite as well as Zed Attack Proxy will allow you
to see that data as it's flowing in real time.
Now I mentioned Bettercap here.
So Bettercap is an improved version
of Ettercap which we talked about
in the the previous lesson,
had machine in the middle for ARP type stuff.
Better cap is a, it's an application.
You install it on your computer.
You surf to local host
and interact with the Bettercap application.
It's very pretty, does the same job as Ettercap and more.
So take a look at Bettercap.
For platform communications,
remember that our applications are sandboxed.
And in order to get out of that sandbox,
the application needs to declare that it wants to do things
like this application wants to interact with the camera.
The application needs to specifically
tell the iOS operating system
that this application needs to interact with the camera.
Those are declared in an entitlements file.
Whenever an application wants
to use these actual entitlements,
the user is going to be presented
with a permit or deny question.
Do you want to allow this application to access the camera,
for example, and the user would have to say yes
before the operating system grants the camera
to the application.
For reverse engineering iOS applications,
these iOS apps are compiled.
So that means you need to decompile
and disassemble them in order to see what they're doing.
And that's a pretty complicated process.
However, it is possible
but you need to understand where you're going
to get the actual binary from.
IPA is iOS App Store Package.
That's what IPA stands for.
Not exactly sure why the P and A are swapped,
but regardless, it's a zip file
that contains all the information needed
for the App Store to publish that application.
If you have that, that IPA file, unzip it
and you have the binary, it's right there for you.
If you don't have the IPA,
you need to extract the binary and that's complicated.
See here, Jailbreak, install the app,
extract the app binary, and then rebuild the IPA.
So apps are encrypted on disk.
So you can't just copy the application binary off disk.
These two programs here, Clutch and Frida iOS Dump
will actually extract the running application from memory.
So you launch or you launch the application
and then you execute these applications and they will go
and interrogate the, I'm talking about random access memory,
RAM here, to extract the running application
and then bring it back together for you.
It is somewhat intense to get to this point.
Once we have the information
that's contained within that IPA, by using something
like Clutch or Frida, to extract that information,
what files are included in that IPA distribution by default?
Before the user opens the application
and maybe logs in or configures the application.
And then once they open the application,
how have those files changed?
What frameworks are in use by the application
and what vulnerabilities might exist in those frameworks?
Take a look at that.
The platform capabilities declared.
We touched on the entitlements that can be declared
as part of an application.
The user has to say yes or no, I permit that.
What sort of information might change on disk
that is derived from one of those entitlements?
Any additional permissions requested to the user.
For network communications encrypted,
on this previous slide here, I didn't touch on this point
and I just realized it as I was talking about it.
So we're gonna come back and talk about this real quick.
App transport security or ATS.
This is a feature built into iOS
that enforces secure communication across the internet.
By default, it will not allow insecure HTTP.
The developer must manually declare its intent
to speak insecure HTTP.
It enforces it on these three calls here, CFURL,
NSURL and NSURL connection,
excuse me, session and connection.
So a developer must comply with secure HTTP
unless they specify manually an exemption
to this policy within their application.
So those network communications, are they encrypted?
If not, sniff it, grab the data, decode it,
figure out what it's doing.
And then finally does the app store data on the device.
So I touched on that in the first bullet point here.
After the user has launched the application,
what changed on disk?
We needed to take a look at that
'cause that can reveal some really good information.
For dissembling applications,
IDA Pro is kind of the gold standard
for disassembling the actual executable binary
of the application.
Cisco Talos has released a plugin for IDA Pro called GhIDA
or G-H-I-D-A that integrates the Ghidra decompiler.
And then finally I mentioned Frida when we were talking
about Clutch a little bit ago,
dynamic code instrumentation toolkit available here
at this URL at the bottom of your screen.