Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome curious minds to another deep dive. Today, we're tackling
something really vital. It hits almost everyone with a smartphone.
We're talking about mobile app security, and specifically those often
kind of hidden vulnerabilities in the APIs, you know, the
things that make the apps actually work. To help us
understand this, we've been looking at some great material, including
insights from the Upwardly Mobile API and App Security podcast
(00:22):
thatwun's hosted by George McGregor and Sky McIntyre to people
who really know their stuff in this field. It's sponsored
by Approved Mobile Security who focus on app attestation.
Speaker 2 (00:32):
Indeed, and their insights are well spot on. We're going
to unpack why the old ways of protecting apps often
fall short now, especially with AI getting involved in the tacks.
We'll explore some of the more advanced dynamic techniques that
are becoming frankly essential for securing mobile apps and their ecosystems.
We're talking directly to you. If you're a mobile developer,
(00:53):
maybe iOS, Android, HarmonyOS, flutter REAC Native, or if you're
a security pro yeah, or even if you just want
to stay ahead of the curve on cyber threats. The
goal here is to give you the knowledge to you know,
really protect your apps and your users.
Speaker 1 (01:06):
Okay, so let's jump right in. There's this startling gap
right between what companies think about their mobile security and
what's actually happening. The research points to a huge misalignment
at this Ninety three percent of organizations feel pretty good.
They think their protections are enough.
Speaker 2 (01:21):
Ninety three percent. Yeah, sounds confident.
Speaker 1 (01:23):
Exactly, but then the reality check. Sixty two percent have
had at least one mobile app security incident in the
past year, and.
Speaker 2 (01:30):
Not just one, right, The average was nine incidents per organization.
Speaker 1 (01:34):
And Hine's that's a lot, it.
Speaker 2 (01:37):
Is, and the financial hit is significant. We're looking at
projections of nearly seven million dollars on average per organization
by twenty twenty five because of these incidents. But you know,
it's not just the money. That's maybe the headline figure,
but the ripples go much further.
Speaker 1 (01:50):
Like what kind of ripples.
Speaker 2 (01:51):
Well, application downtime that happens in over half the cases
sensitive data leaks. That's almost half forty eight percent.
Speaker 1 (01:58):
Wow.
Speaker 2 (01:59):
And then there's the trust factor. Forty one percent report
losing consumer trust and thirty eight percent see a worse
user experience. It really damages the whole relationship with the user.
Speaker 1 (02:09):
And things aren't slowing down, are they. Development speed is
a big factor here.
Speaker 2 (02:12):
Not at all. The number of unique apps organizations are
releasing is climbing from ten a year in twenty twenty
three up to thirteen projected for twenty twenty five.
Speaker 1 (02:21):
So more apps faster, right.
Speaker 2 (02:23):
And while seventy four percent feel that pressure to speed
up development really concerning, seventy one percent admit that speed
is directly hurting their mobile app security efforts.
Speaker 1 (02:32):
It's like they know there's a problem, but the pressure
to release overrides it.
Speaker 2 (02:36):
It certainly seems that way sometimes, and it points to
some fundamental gaps in how security is approached. Think about this.
Nearly forty percent are still just relying on security measures
they built themselves in house, or maybe what's included in
the OS you know, from Apple, Google, Samsung, Huawei, and
only about a third thirty one percent are using obfuscation,
(02:57):
which you know, leaves apps quite vulnerable to static analysis
and maybe even more worrying, sixty percent, sixty percent have
an implemented runtime application self protection. To you priends at
rask okay.
Speaker 1 (03:10):
RASP sixty percent haven't implemented it. That feels low.
Speaker 2 (03:13):
It is low considering the threats.
Speaker 1 (03:14):
So let's talk about code affuscation then, because I think
a lot of people, maybe de developers included, see that
as a decent starting point. Why isn't it enough anymore?
Has the game changed that much? Oh?
Speaker 2 (03:23):
It absolutely has code obfuscation. Look, it makes things harder
for a casual looker. It raises the bar for reverse engineering, sure,
but it's fundamentally a deterrent. It's not really a preventative lock.
Determined attackers, especially those using advanced tools things like dynamic
analysis frameworks, tools like FREEDA, they can often systematically dealfuscate
(03:46):
the code.
Speaker 1 (03:47):
So it stops the script kitties maybe, but not the
serious threats pretty much.
Speaker 2 (03:52):
And crucially, it mainly hardens the code when it's just
sitting there at rest. It does very little against threats
that happen while the app is actually running. Plus, it's
not a good replacement for managing your secrets properly. Apikeys credentials.
They eventually have to be loaded into memory in plaintexts
for the app to use them. Obcustation doesn't stop.
Speaker 1 (04:11):
That, right, So it can create this false sense of security.
Teams think they've checked the box, but they might be
ignoring more fundamental risk.
Speaker 2 (04:17):
That's a real danger. It becomes security theater.
Speaker 1 (04:20):
And now now AI comes along. How is AI sort
of turbocharging these attacks? What's it doing differently?
Speaker 2 (04:26):
Yeah, AI is really throwing a wrench into the works.
It's being weaponized across the board. Attackers are using it
to automate finding targets, creating malware that adapts and hides
itself much better, smarter malware, much smarter. It's accelerating how
quickly they find vulnerabilities even zero days, and they're building
botnets that are way better at pretending to be real
(04:48):
human users. Wow. Even the AI models inside mobile apps
can become targets now, things like prompt injection attacks or
data poisoning to mess up the AI's results. Whole new dimension.
Speaker 1 (05:01):
Okay, so the attacks are getting way more sophisticated thanks
to AI. We've talked a lot about protecting the app
itself on the phone, but given everything you've said, especially
about secrets and run time, is the app always the
main target or is it just a doorway.
Speaker 2 (05:15):
That's exactly the connection we need to make It's becoming
super clear that the real prize isn't usually the app
code itself, it's the back end APIs that the app
talks to.
Speaker 1 (05:24):
Ah.
Speaker 2 (05:24):
The mobile app is often just the easiest way in
attackers use it to hammer the APIs with things like
credential stuffing, scraping sensitive data, abusing business logic.
Speaker 1 (05:33):
And static defenses like obfuscation don't.
Speaker 2 (05:36):
Help there, almost not at all, because those API vulnerabilities
are usually on the server side. Hiding the app code
doesn't stop someone hitting your API directly with stolen credentials
or automated scripts. So what you really need are defenses
that can tell the difference. Is this request coming from
a genuine, untampered app on a safe device or is
it coming from a bot or a hacked client. That's
(05:58):
the key.
Speaker 1 (05:59):
Question, which sounds like it leads us towards zero trust,
that whole never trust, always verify idea.
Speaker 2 (06:05):
Precisely, that's the fundamental shift needed. We have to move
to a dynamic, run time focused security model based on
zero trust principles. It means constantly checking and verifying, not
just doing checks before deployment, protecting the app while it's
actually running.
Speaker 1 (06:20):
So applying never trust, always verify to every single transaction
in the app makes What does that look like in practice?
For mobile? What are the key pieces we need?
Speaker 2 (06:28):
You really need a few critical components working together, four
main ones. I'd say first you need mobile RASP. Remember
pronounce RASP right. RASP the internal bodyguard exactly, it's inside
the app watching for runtime threads. Is someone trying to
attach a debugger? Is the app being campered with? Is
the phone rooted or jailbroken? Is someone using hooking frameworks
(06:50):
like freedam. RASP detects that stuff and can react in
real time. It gives you deep insight into what's happening
inside the app environment.
Speaker 1 (06:58):
Okay, so that's step one, make the app environment aware.
What's next for checking requests?
Speaker 2 (07:03):
Next is app adas station and API request validation. This
is huge for protecting your back end APIs. The core
idea here is to make absolutely sure that API requests
are only coming from your official app and unmodified version
running on a device that hasn't been compromised.
Speaker 1 (07:19):
So it's validating the source really strongly.
Speaker 2 (07:21):
Yes, it's incredibly effective at blocking automated threats, bots, scripts
and also apps that someone is downloaded tampered with and reuploaded.
It verifies the what the app itself, not just the
who the user?
Speaker 1 (07:33):
Makes sense? And what about those API keys and secrets
we talked about, the ones obfuscation doesn't really protect.
Speaker 2 (07:39):
That brings us to the third piece, run time secrets protection.
This is critical. You take sensitive secrets completely out of
the app's.
Speaker 1 (07:48):
Code, out entirely so they can't be found by reverse engineering.
Speaker 2 (07:51):
Exactly, instead of embedding them, the secrets are delivered securely
only when needed, just in time, and only to app
set of pass that ADAS station check we just talkdalked about.
Speaker 1 (08:00):
Ah, So attestation acts as the gatekeeper for the secrets
too precisely.
Speaker 2 (08:04):
It stops attackers from just grabbing your secrets from the code.
It tackles that improper credential usage problem head on.
Speaker 1 (08:11):
Okay, that covers the app environment, the request source, and
the secrets. What about the actual communication channel man in
the middle? Attacks are still a thing, right, They.
Speaker 2 (08:21):
Definitely are, which leads to the fourth component, dynamic channel protection.
You might hear it called dynamic.
Speaker 1 (08:26):
Pinning pinning like certificate pinning. I thought that was kind
of brittle and difficult to manage.
Speaker 2 (08:31):
Static certificate pinning is brittle. You pin to a specific
certificate in your app, and when that certificate on your
back end changes, which it does regularly, you have to
push out a whole new app update through the store.
It's a major pain.
Speaker 1 (08:46):
Yeah, that sounds like a recipe for outages or delays.
Speaker 2 (08:49):
It often is. Dynamic pinning solves this. It allows you
to update the pins securely over the air without needing
an app update. Oh interesting, So you get continuous protection
against man in the middle attack where someone tries to
intercept or change the communication, but without forcing users to
update constantly, much more resilient, much less risk of downtime.
Speaker 1 (09:08):
So, putting it all together, RASP, app attestation, runtime secrets,
dynamic pinning. They're not really separate tools, are they. They
sound like they rely on each other.
Speaker 2 (09:18):
They absolutely do. They're deeply interconnected, synergistic. RASP provides a
lot of the intelligence that the attestation check uses. Attestation
then acts as that crucial gatekeeper. It verifies the app
and device are trustworthy before those runtime secrets get delivered
or before sensitive API calls are allowed through.
Speaker 1 (09:36):
So it's a layered system, exactly.
Speaker 2 (09:38):
A cohesive layered runtime defense. It's just fundamentally much stronger
and more resilient than relying only on those static defenses
we talked about earlier.
Speaker 1 (09:49):
This kind of brings up a distinction you sometimes see
in the security market right between solutions that focus heavily
on hardening the app code on the device and those
that focus more on validating things remote in the cloud,
especially for API access like you might see guard Square products,
Dexcard and ix Guard really strong on that client side
(10:09):
hardening and RASP right.
Speaker 2 (10:11):
They excel at making the app itself incredibly tough to
crack locally on the device code obfuscation, hardening, RASP features.
That's their strong suit.
Speaker 1 (10:20):
And then you have solutions like a Proof, which, as
we mentioned, sponsors the upwardly Mobile podcast. Their focus seems
more on that remote attestation piece.
Speaker 2 (10:28):
That's a good way to put it. Approve really emphasizes
the remote mobile app attestation. It does deep, continuous checks
of the app and the device environment. But crucially, the
decision is this app trustworthy is made server side in
the cloud.
Speaker 1 (10:41):
Why is that server side decision important.
Speaker 2 (10:43):
Because it makes it significantly harder for an attacker to
tamper with or bypass the check itself. If the logic
is all in the app, a skilled attacker might find
ways around it. Making the decision remotely adds a huge
layer of security, So approve insurers only genuinely attested apps
can talk to your APIs. Ideally, you want both.
Speaker 1 (11:02):
Aspects covered like a combination.
Speaker 2 (11:04):
Yes, a truly comprehensive strategy often uses both. Maybe guard
square for strong in app on device protection and approve
for that critical API integrity check and preventing abuse through
at testation, defense in depth.
Speaker 1 (11:17):
Defense in depth. That seems to be the recurring theme here.
So if you had to give one key piece of
advice to organizations listening, what would it be.
Speaker 2 (11:23):
I think the main takeaway is this static analysis looking
for coding errors early on. That's still valuable, but it's
not enough, not nearly enough anymore. It must be complemented
by strong dynamic run time defenses, especially if your app
handles anything sensitive data, transactions, critical functions. These dynamic measures
RASP at testation, runtime secrets, dynamic pinning. They aren't just
(11:48):
nice to have as anymore, they are fundamental requirements to
be resilient against today's threats.
Speaker 1 (11:53):
And code opustation. Where does that fit in the final picture?
Speaker 2 (11:57):
Honestly, if you use it, think of it as a
minor supplement entry layer. Maybe it slows down the lease
sophisticated attackers a tiny bit, but it should never be
the foundation, the cornerstone of your security strategy. Relying on
it is asking for trouble.
Speaker 1 (12:10):
This has been really eye opening. It definitely feels like
the mobile threat landscape has fundamentally shifted. Relying on the
old static methods just isn't viable.
Speaker 2 (12:17):
It really isn't. Organizations have to make that pivot, a
decisive pivot to dynamic run time security. It's about constantly
verifying the integrity of everything in real time, especially where
those APIs are involved. That's not just ticking a compliance box,
it's basic risk management. Now you have to do it
to protect your users, protect your data, and frankly, maintain trust.
(12:39):
It's essential in this digital world.
Speaker 1 (12:42):
So for everyone listening, maybe take a moment to think
about this. How does this change how you view the
security of the apps you build or even the apps
you use every day? Are you thinking enough about protecting
not just the app on the phone, but those critical
communication lines back to the servers. That distinction seems key.
This has been a fascinating look into mobile app and
API security. We drew heavily on excellent insights, including those
(13:05):
from the Upperably Mobile Api and App Security podcast and
just a note for transparency. This particular analysis was put
together using valuable human expertise and research, and we also
had some assistance from AI in its production