August 4, 2025 • 19 mins
Mobile-First Security: The Urgent Lessons from the Tea App Breach
In this focused segment of Upwardly Mobile, we unpack the recent Tea app breach, a sobering case study that highlights the critical need for a robust mobile-first cybersecurity strategy and proper API security. The Tea app, a women's dating safety application that rapidly climbed to the top of the free iOS App Store listings and reached the No. 1 spot on Apple's US App Store, claiming over 1.6 million users, was designed to allow women to exchange information about men to enhance safety. A key feature involved new users verifying their identity by uploading a selfie. The company confirmed a major security breach, stating they had "identified authorized access to one of our systems". Preliminary findings revealed access to approximately 72,000 user images. This alarming exposure included:
This content was created in partnership and with the help of Artificial Intelligence AI
In this focused segment of Upwardly Mobile, we unpack the recent Tea app breach, a sobering case study that highlights the critical need for a robust mobile-first cybersecurity strategy and proper API security. The Tea app, a women's dating safety application that rapidly climbed to the top of the free iOS App Store listings and reached the No. 1 spot on Apple's US App Store, claiming over 1.6 million users, was designed to allow women to exchange information about men to enhance safety. A key feature involved new users verifying their identity by uploading a selfie. The company confirmed a major security breach, stating they had "identified authorized access to one of our systems". Preliminary findings revealed access to approximately 72,000 user images. This alarming exposure included:
- 13,000 images of selfies and photo identification documents, such as driver's licenses, which users had submitted during the account verification process.
- 59,000 publicly viewable images from posts, comments, and direct messages within the app.
- Broken access controls. (BOLA)
- Weak authentication.
- Missing transport protections.
- Absent runtime safeguards.
This content was created in partnership and with the help of Artificial Intelligence AI
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome to Upwardly Mobile API and App Security. I'm George and.
Speaker 2 (00:03):
I'm sky great to be here.
Speaker 1 (00:05):
So in this segment, we're really going to unpack the
recent t app breach. It's quite a sobering case study.
Speaker 2 (00:12):
Actually, yeah, absolutely.
Speaker 3 (00:13):
It really highlights this this critical need for you know,
robust mobile first cybersecurity strategy and crucially proper API security exactly.
Speaker 1 (00:24):
And we've looked at quite a few sources for this,
analyst guides on mobile app security, detailed reports on the
TA incident itself, trying to get a full picture for you.
Speaker 3 (00:32):
It's such an important topic, George, because you know, mobile
apps are so central now right everyone talks about mobile
first thinking for digital transformation, oh yeah, everywhere, but the
security piece it often feels like it lags behind it.
It's like building this amazing, super modern house, but forgetting
to put a decent lock on the front door.
Speaker 1 (00:51):
That's a really good way to put it. So, why
is that if mobile is the main way customers interact,
why isn't security front and center? It feels like I'm
major disconnect, it really is.
Speaker 3 (01:01):
It's kind of a paradox, isn't it. Companies invest so
much in making these great mobile experiences, slick interfaces, smooth functionality,
whether it's native iOS, Android, Harmon Aos or you know,
cross platform with Flutter or React Native.
Speaker 1 (01:18):
Right, the user experience is paramount exactly.
Speaker 3 (01:20):
These apps drive business, they engage users, but the security
thinking hasn't quite caught up. Mobile isn't just another channel
often it is the main channel, the main entry point,
and that needs to change how we fundamentally approach securing things.
Speaker 1 (01:36):
And it's not just like one single vulnerability we need
to worry about, is it. Yea, sounds like the potential
attack surface is actually much wider than maybe a lot
of developers think.
Speaker 3 (01:45):
Oh, definitely, that's spot on. It's not just the app
code itself. You've got to think bigger. I usually break
it down into like five key areas, five potential holes
bad actors are looking at. Okay, so first, yeah, there's
the app itself, the code, how it's built. But then
the second there's the device that's running on is that compromise.
Third's the network channel, the connection back to the servers.
That's another vector, right. Fourth, you've got the security credentials, API, keys, tokens,
(02:08):
that kind of thing stored on that device, and fifth,
and this is huge. The APIs the app talks to
Every single app is basically a front door to your
back end, and attackers are actively poking at all five
of those areas, hoping one.
Speaker 1 (02:22):
Is unlocked and complicating things even more. The attackers, the
bad actors, They have a pretty big advantage, don't they.
They actually control their own devices. What does that lift
them do?
Speaker 2 (02:33):
Yeah, that's a game changer. Honestly.
Speaker 3 (02:34):
When an attacker controls the device physically, they control everything, hardware,
the OS, the network connection, everything everything, So they can
do things like jail braking on iOS or rooting on Android.
Speaker 2 (02:46):
And that's not just a technical term.
Speaker 3 (02:47):
It fundamentally bypasses the security controls built in by Apple
or Google.
Speaker 1 (02:52):
Okay, so all the platform security is just gone very much.
Speaker 3 (02:54):
Yeah, it gives them free rain. They can install whatever
tools they want, tools specifically designed to analyzeipulate, or attack
your app running on their phone. They're operating in what
we call an untrusted environment, so your app really becomes
the last line of defense.
Speaker 1 (03:08):
So if companies can't really control user devices, I mean,
you can't police what everyone does with their phone, what
can developers and security teams actually control effectively.
Speaker 3 (03:20):
Right, that's the key question. Since you don't own the device,
the most effective protection, really, the only reliable protection, has
to be inside the app itself.
Speaker 1 (03:29):
Oh okay.
Speaker 2 (03:29):
This leads to the idea of app self protection.
Speaker 3 (03:32):
It needs to become a core priority, not just for security,
but for the whole digital strategy. You build the app
to be its own defender, basically able to protect itself
no matter what state the device is in, because that's
the piece you actually control once it's out there.
Speaker 1 (03:47):
That makes a lot of sense, especially when you look
at real world incidents, which brings us back to the
t app breach.
Speaker 2 (03:53):
Yeah. A perfect example, unfortunately for.
Speaker 1 (03:56):
Listeners who aren't familiar tea was positioned is this women's
safety dating app app. The idea was for women to
share info about men they dated or encountered. Ye.
Speaker 2 (04:05):
It got popular fast, right, extremely popular.
Speaker 1 (04:07):
It shot up to number one on the iOS app
Store for a time, and part of its whole premise
kind of ironically now involved identity verification. Users had to
submit selfies and photo IDs.
Speaker 2 (04:18):
Right for safety and verification exactly.
Speaker 1 (04:21):
But then the company confirmed a breach. They stated they
identified authorized access to one of our systems A bit vague,
but clearly something went wrong and.
Speaker 2 (04:30):
The data that got out it was incredibly sensitive.
Speaker 3 (04:33):
We're talking about approximately seventy two thousand images compromise.
Speaker 1 (04:36):
Wow.
Speaker 3 (04:37):
Yeah, and breaking that down, it was around thirteen thousand
selfies and photo IDs, things like driver's licenses, the very
faces people submitted to verify their accounts, plus another fifty
nine thousand images that were let's say, publicly viewable within
the app from posts, comments, dms.
Speaker 1 (04:53):
Really personal stuff.
Speaker 2 (04:54):
Extremely personal.
Speaker 3 (04:56):
Now, the company did say this data came from a
legacy data system, apparently from over two years prior, and
they claimed no current user data was hit. But still
the fact that this data existed and was accessible, that's
the core issue.
Speaker 1 (05:08):
How did this even come out? It wasn't the company
initially was it?
Speaker 3 (05:11):
No, it actually surfaced through posts on Reddit and reporting
by four or four media they found user data, these
images being posted on four chan, the anonymous message board.
Speaker 1 (05:22):
Oh wow, so it's just out there.
Speaker 3 (05:24):
Out there, and users on these forums are claiming they
found an exposed database hosted on Google's firebase with and
this is a quote from reports, no authentication, no nothing,
just wide open.
Speaker 1 (05:37):
No authentication on a database with IDs and.
Speaker 3 (05:40):
Selfies apparently so t later did confirm that some direct
messages were also impacted.
Speaker 2 (05:46):
It just throws fuel on this whole debate.
Speaker 3 (05:48):
You know, does asking users for this level of online
identity verification, especially with things like driver's licenses, create risks
that many companies just aren't prepared to manage securely.
Speaker 1 (05:58):
It certainly seems like in this case, and it brings
us right back to API security. I saw a quote
from Ted Morocco, he's a CEO in mobile security.
Speaker 2 (06:05):
Oh yeah, I saw that too.
Speaker 1 (06:06):
You put it really bluntly, he said. The exposure of
verified selfies in ID images in the t app breach
underscores a systemic failure in API security rooted in broken
access controls, weak authentication, missing transport protections, and absent runtime.
Speaker 2 (06:23):
Safeguards that hits the nail on the head.
Speaker 1 (06:25):
He goes on, too often companies rush apps to market,
driven by subscriber growth and churn metrics, while privacy and
security are sidelined. But these failures aren't inevitable. They're preventable.
That's the key part. Preventable with discipline engineering, proper API defenses,
and a real commitment to protecting user trust.
Speaker 3 (06:45):
Preventable that's the word. It is preventable, George. But it
requires a different mindset, a real shift. It's kind of ironic, actually,
Hu So.
Speaker 2 (06:53):
Well, companies spend fortunes locking down.
Speaker 3 (06:55):
Their back end databases, right, they're crown jewels. They treat
database secrets gold.
Speaker 1 (07:00):
Of course standard practice.
Speaker 3 (07:02):
But then they often overlook the keys that their mobile
apps use, the keys to the front door essentially, So.
Speaker 1 (07:07):
When you say secret keys to the front door in
the mobile context, you're talking.
Speaker 3 (07:11):
About API keys, primarily API keys and similar secrets like tokens.
These are what unlock access to the server side APIs,
which in turn access the data. They are arguably the
most important secrets on mobile device holds, and the irony
is the same security teams who have a fit if
a database password leaked might not think twice about how
(07:34):
API keys are handled in the mobile app itself. It's
like putting Fort Knox locks on your vault, but leaving
the key under the doormat.
Speaker 1 (07:41):
That really undermines all the back end security doesn't.
Speaker 2 (07:43):
Act completely, it negates it.
Speaker 1 (07:45):
So why is API security so critical and why does
it get overlooked? What makes that mobile front door so vulnerable?
Speaker 3 (07:52):
Well, part of it is just the sheer explosion of APIs.
The attack surface on the mobile device is constantly growing
because apps talk to more and more back and services
via APIs over the Internet.
Speaker 1 (08:02):
Right, Everything's connected everything, And a lot.
Speaker 3 (08:05):
Of these APIs might not even be protected by traditional
username password logins. They rely on these keys. But the
keys themselves, they can often be stolen relatively easily from
insecure storage on the device itself, maybe from configuration files
left on a server somewhere, or and this is very common.
By decompiling the mobile apps code, a hacker can just
(08:26):
pull your app apart, find the hard coded apikey, and bingo.
Speaker 1 (08:29):
They don't even need the app anymore at that point.
Speaker 3 (08:31):
Nope, they can use that key directly to hammer your
API bypass the app entirely, and access your back end systems.
It's a direct line in that. Protecting those API keys
is yeah, yeah, leaving the front door wide open while
locking the internal rooms.
Speaker 1 (08:45):
That sounds like a massive problem, especially with how many
apps are out there. So what are the actual practical
steps developers and security teams listening right now can take.
How do you protect these keys?
Speaker 3 (08:56):
Okay, yeah, there are definitely concrete things you can do first,
and this is fundamental. Manage your apiit is completely independently
from the mobile app code. Don't bake them in, treat
them like server side secrets.
Speaker 1 (09:08):
Don't hardcode, absolutely not.
Speaker 3 (09:10):
Second, store those keys securely, ideally in a dedicated secret's
fault in the cloud. Get them out of the app
package entirely.
Speaker 1 (09:17):
Okay, So they live in the cloud. How does the
app get them when it needs them?
Speaker 3 (09:21):
That's the third step, Access them dynamically, just in time.
The app should only fetch the key right when it's
about to make an API call, and this is critical,
only after the app and its runtime environment have passed
something called attestation attestation.
Speaker 1 (09:35):
Can you explain that a bit for our listeners.
Speaker 3 (09:37):
Sure. Attestation is basically a strong check of verification process.
It proves that your app is the genuine, untampered version
you released, and that it's running on a device that
hasn't been compromised like rooted or jail broken, and isn't
running instrumentation frameworks like FREEDA.
Speaker 1 (09:54):
So it checks the app in the environment exactly.
Speaker 3 (09:57):
Only if both checks pass prove trustworthiness does the app
get temporary access to the API key from the cloud
vault to make its call. There are solutions out there
like approve runtime secrets specifically designed to manage.
Speaker 2 (10:10):
This whole process.
Speaker 3 (10:11):
And finally, you need solid governance around these keys. Maintain them,
update them, cycle them regularly and safely, and crucially, if
a key is compromised, you need the ability to revoke
and rotate it immediately without disrupting service for legitimate users
and without having to force everyone to update their app.
Speaker 1 (10:31):
That sounds much more robust. Moving beyond just the keys, though,
it feels like hackers just generally target phones a lot.
You hear about it all the time. How easy is
it really for them to compromise corporate assets or user
data via smartphones? And what kind of tricks are they using?
Speaker 3 (10:47):
Yeah, it's well, surprisingly easy in many cases. Unfortunately, again
it comes back to the attack or controlling their own device.
We mentioned jail breaking and rooting.
Speaker 1 (10:55):
That's often step one, right bypassing the basic security exactly.
Speaker 3 (10:59):
Once they have that level of control, they can deploy
all sorts of tools. They might use something like MIT
proxy that stands for Man in the middle proxy. It
lets them sit between the app and your server, intercepting all.
Speaker 1 (11:09):
The traffic, even encrypted traffic.
Speaker 3 (11:10):
They can often bypass TLS encryption yet, especially if the
app isn't doing proper checks like certificate pinning, which we
can talk about, so they can see data, modify data.
It's like a perfect eavesdropping tool.
Speaker 1 (11:22):
Okay, that's scary.
Speaker 3 (11:23):
What else, Well, they can reverse engineer the app, like
we discussed for finding API keys, but also just to
understand how it works, find logical flaws, figure out where
the sensitive operations happen. They use powerful security testing tools,
things like burp suite or Freeda, not for testing their
code but maliciously against your app.
Speaker 1 (11:42):
Freeda what's that?
Speaker 3 (11:43):
Freta is a dynamic instrumentation toolkit. It lets attackers inject
their own code into your running.
Speaker 1 (11:50):
App process while it's running.
Speaker 3 (11:51):
While it's running, so they can hook into functions, modify behavior,
extract data in real time. It bypasses almost any kind
of check you might do before the app launches. It's
incredibly powerful in the wrong hands.
Speaker 1 (12:03):
So given all that the common security practices we hear about,
like sasd dassed, maybe code obfuscation, there's just not enough
on their own when the attacker has this much control.
Speaker 3 (12:13):
Precisely, let's break those down quickly. SAAST Static Application security
testing scans your source code before it's compiled or run.
It's like a spell checker for security bugs in the code.
Itself useful, but it can't see runtime threats.
Speaker 1 (12:27):
Okay.
Speaker 3 (12:28):
DAS Dynamic application security testing tests the app while it's running,
trying to find vulnerabilities by interacting with it like a
user or an attacker would again useful, but typically done
in a controlled test environment, not the hostile environment of
an attacker's device. Neither SaaS nor DAST is really designed
for the scenario where the attacker fully controls the device
(12:48):
and the runtime environment obfustation, making the code harder to read.
It's a hurdle maybe, but determined attackers can usually deobfuscate it.
It slows them down, it doesn't stop.
Speaker 1 (12:59):
Them relying on the OS security iOS or Android.
Speaker 3 (13:03):
That's not enough either, because, as we said, jail breaking
or rooting blows right past those OS level controls. The
fundamental problem remains the bad actor owns the device they're
using for the attack. Your app is running in their playground.
Speaker 1 (13:16):
So if those traditional methods have significant gaps in this
mobile context, what is the solution? How do you actually
maintain integrity and protect sensitive communications when you can't trust
the device.
Speaker 3 (13:29):
The answer really lies in shifting protection to the runtime continuously.
It's about continuous end to end runtime checking starting right there.
Speaker 1 (13:38):
On the device. Okay, tell me more about that.
Speaker 3 (13:40):
This is where technology is like RASP, runtime application self
protection becomes so important. Think of RASP, especially dynamic RASP,
as embedding a security guard inside your application. This guard
is constantly active while the app is running. It verifies
the integrity of the app itself, has it been tampled
with It checks the environment as the device jail rooted,
(14:00):
is freeda attached. It monitors the app's behavior for anything suspicious,
and it can react in real time to mitigate threats.
Speaker 1 (14:08):
How does it react.
Speaker 3 (14:09):
It can take various actions, maybe alert the back end,
shut down the app, or prevents specific sensitive operations. It
also involves continuously monitoring the connections that APIs, the app
is calling, and the network channel itself. It's an active,
ongoing defense.
Speaker 1 (14:23):
And can you adjust how aggressive it is? Yeah?
Speaker 3 (14:26):
Absolutely good. RASP solutions are configurable. You might want stricter
controls for a banking app compared to say a simple game.
You can tailor the level of protection.
Speaker 1 (14:37):
Okay, that makes sense for protecting the app itself. What
about the communication channel you mentioned man in the middle
attacks earlier. They seem like a huge threat for stealing
data in transit logins, bank details, all that sensitive stuff.
Speaker 3 (14:51):
MITTIL is definitely one of the most significant threats to
mobile communication. And while HTTPS using TLS is the standard
and provides essential encryption, it's not fool proof, especially against
sophisticated attackers.
Speaker 1 (15:04):
What are the limitations.
Speaker 3 (15:05):
Well, attackers can sometimes trick users into trusting fake certificates,
they might steal the server's private keys, or sometimes the
validation process just isn't strong enough to be sure you're
really talking to the legitimate server and not an impostor.
Standard TLS confirms the server has a valid certificate for
the domain, but not necessarily that it's your specific expected server.
Speaker 1 (15:26):
So how do you add that extual layer of trust
you mentioned pinning?
Speaker 3 (15:29):
Exactly certificate pinning it's an additional layer of security on
top of standard tlshttps. The basic idea is you embed
information about the specific certificate or its public key or
a hash that your app expects the server to use
directly into the mobile app itself.
Speaker 1 (15:47):
You hardcode the certificate details sort of.
Speaker 2 (15:50):
You pin that information.
Speaker 3 (15:52):
Then when the app connects, it doesn't just check if
the server's certificate is valid. In general, it checks if
it matches the specific pinned information. If there's no match,
the app refuses to connect, preventing a potential midem attack.
Speaker 1 (16:05):
Ah, I see, But what happens when certificates expire or
need to be changed If the pin is hard coded?
Wouldn't you have to push out a new app update
to potentially millions of users every time. That sounds like
a logistical nightmare.
Speaker 3 (16:18):
You've hit on the big challenge of static pinning. Where
the pin is baked into the card. It can be
very brittle and lead to exactly that update nightmare, or worse,
your app stops working if the server certificate changes unexpectedly.
Speaker 1 (16:30):
So how do you get around that?
Speaker 3 (16:31):
The solution is dynamic certificate pinning updates. Instead of hard
coding the pin, the app can securely fetch the latest
valid pin information, usually over the air, perhaps managed by
the same system doing the runtime checks or apikey delivery.
Speaker 2 (16:45):
We talked about.
Speaker 1 (16:46):
Huh, So it can adapt exactly.
Speaker 3 (16:48):
It allows the back end team to rotate certificates as
netted without breaking the mobile app or forcing immediate updates.
The app always checks against the current correct pin value.
Mobile apps are actually well suited for this because the
app stores provide a relatively secure channel for initially distributing
the app. With a dynamic pinning logic. It makes pinning
(17:08):
practical and manageable. It ensures your app only talks to
your verified server, cutting off those midimim attacks effectively, SKY.
Speaker 1 (17:16):
This has been incredibly insightful. We've covered a lot, from
the strategic disconnect and mobile security to the specifics of
the t app, breach apike protection, run time defense, and
secure communication. The scale of the challenge is clear, but
also the potential solutions if you had to boil it down.
What's the single most crucial takeaway for our listeners, especially
(17:36):
the developers working on these platforms every day.
Speaker 3 (17:39):
I think the core message is that mobile security can't
be a bolton or an afterthought anymore. It has to
be woven into the entire development life cycle right from
the start. The t app is just one example, a
really stark one of what happens when crucial elements like
API security and runtime integrity aren't prioritized. We've seen traditional
(18:00):
approaches just don't cut it when the attacker controls the device,
So you need that multi layered strategy. Secure your API
keys properly, ideally managing them dynamically from the cloud, Implement
continuous run time protection like RASP to defend the app
in hostile environments, and lock down your communication channels with
dynamic certificate pinning. It's about building security in, not trying
(18:22):
to add it on later.
Speaker 1 (18:23):
Makes sense.
Speaker 3 (18:23):
So maybe the question for everyone listening is looking at
your current or next mobile project, what's the one thing
you'll do differently today.
Speaker 2 (18:29):
Or this week to raise the bar on security?
Speaker 3 (18:32):
Because it really is a constant arms race out there,
and taking proactive steps is the only way to stay
ahead and prevent your app from becoming the next cautionary tale.
Speaker 2 (18:41):
Knowledge is only valuable when you apply it right.
Speaker 1 (18:43):
A really powerful point to end on, build it in,
don't bolt it on, and take that one step today. Sky.
Thank you so much for sharing your expertise, my pleasure, George,
and thank you all for joining us for this focused
segment of upwardly mobile API and AB security. Just a note,
this discuss was put together using human sources and research
with some assistance from AI in structuring our conversation. Catch
(19:05):
you next time.
Welcome to Upwardly Mobile API and App Security. I'm George and.
Speaker 2 (00:03):
I'm sky great to be here.
Speaker 1 (00:05):
So in this segment, we're really going to unpack the
recent t app breach. It's quite a sobering case study.
Speaker 2 (00:12):
Actually, yeah, absolutely.
Speaker 3 (00:13):
It really highlights this this critical need for you know,
robust mobile first cybersecurity strategy and crucially proper API security exactly.
Speaker 1 (00:24):
And we've looked at quite a few sources for this,
analyst guides on mobile app security, detailed reports on the
TA incident itself, trying to get a full picture for you.
Speaker 3 (00:32):
It's such an important topic, George, because you know, mobile
apps are so central now right everyone talks about mobile
first thinking for digital transformation, oh yeah, everywhere, but the
security piece it often feels like it lags behind it.
It's like building this amazing, super modern house, but forgetting
to put a decent lock on the front door.
Speaker 1 (00:51):
That's a really good way to put it. So, why
is that if mobile is the main way customers interact,
why isn't security front and center? It feels like I'm
major disconnect, it really is.
Speaker 3 (01:01):
It's kind of a paradox, isn't it. Companies invest so
much in making these great mobile experiences, slick interfaces, smooth functionality,
whether it's native iOS, Android, Harmon Aos or you know,
cross platform with Flutter or React Native.
Speaker 1 (01:18):
Right, the user experience is paramount exactly.
Speaker 3 (01:20):
These apps drive business, they engage users, but the security
thinking hasn't quite caught up. Mobile isn't just another channel
often it is the main channel, the main entry point,
and that needs to change how we fundamentally approach securing things.
Speaker 1 (01:36):
And it's not just like one single vulnerability we need
to worry about, is it. Yea, sounds like the potential
attack surface is actually much wider than maybe a lot
of developers think.
Speaker 3 (01:45):
Oh, definitely, that's spot on. It's not just the app
code itself. You've got to think bigger. I usually break
it down into like five key areas, five potential holes
bad actors are looking at. Okay, so first, yeah, there's
the app itself, the code, how it's built. But then
the second there's the device that's running on is that compromise.
Third's the network channel, the connection back to the servers.
That's another vector, right. Fourth, you've got the security credentials, API, keys, tokens,
(02:08):
that kind of thing stored on that device, and fifth,
and this is huge. The APIs the app talks to
Every single app is basically a front door to your
back end, and attackers are actively poking at all five
of those areas, hoping one.
Speaker 1 (02:22):
Is unlocked and complicating things even more. The attackers, the
bad actors, They have a pretty big advantage, don't they.
They actually control their own devices. What does that lift
them do?
Speaker 2 (02:33):
Yeah, that's a game changer. Honestly.
Speaker 3 (02:34):
When an attacker controls the device physically, they control everything, hardware,
the OS, the network connection, everything everything, So they can
do things like jail braking on iOS or rooting on Android.
Speaker 2 (02:46):
And that's not just a technical term.
Speaker 3 (02:47):
It fundamentally bypasses the security controls built in by Apple
or Google.
Speaker 1 (02:52):
Okay, so all the platform security is just gone very much.
Speaker 3 (02:54):
Yeah, it gives them free rain. They can install whatever
tools they want, tools specifically designed to analyzeipulate, or attack
your app running on their phone. They're operating in what
we call an untrusted environment, so your app really becomes
the last line of defense.
Speaker 1 (03:08):
So if companies can't really control user devices, I mean,
you can't police what everyone does with their phone, what
can developers and security teams actually control effectively.
Speaker 3 (03:20):
Right, that's the key question. Since you don't own the device,
the most effective protection, really, the only reliable protection, has
to be inside the app itself.
Speaker 1 (03:29):
Oh okay.
Speaker 2 (03:29):
This leads to the idea of app self protection.
Speaker 3 (03:32):
It needs to become a core priority, not just for security,
but for the whole digital strategy. You build the app
to be its own defender, basically able to protect itself
no matter what state the device is in, because that's
the piece you actually control once it's out there.
Speaker 1 (03:47):
That makes a lot of sense, especially when you look
at real world incidents, which brings us back to the
t app breach.
Speaker 2 (03:53):
Yeah. A perfect example, unfortunately for.
Speaker 1 (03:56):
Listeners who aren't familiar tea was positioned is this women's
safety dating app app. The idea was for women to
share info about men they dated or encountered. Ye.
Speaker 2 (04:05):
It got popular fast, right, extremely popular.
Speaker 1 (04:07):
It shot up to number one on the iOS app
Store for a time, and part of its whole premise
kind of ironically now involved identity verification. Users had to
submit selfies and photo IDs.
Speaker 2 (04:18):
Right for safety and verification exactly.
Speaker 1 (04:21):
But then the company confirmed a breach. They stated they
identified authorized access to one of our systems A bit vague,
but clearly something went wrong and.
Speaker 2 (04:30):
The data that got out it was incredibly sensitive.
Speaker 3 (04:33):
We're talking about approximately seventy two thousand images compromise.
Speaker 1 (04:36):
Wow.
Speaker 3 (04:37):
Yeah, and breaking that down, it was around thirteen thousand
selfies and photo IDs, things like driver's licenses, the very
faces people submitted to verify their accounts, plus another fifty
nine thousand images that were let's say, publicly viewable within
the app from posts, comments, dms.
Speaker 1 (04:53):
Really personal stuff.
Speaker 2 (04:54):
Extremely personal.
Speaker 3 (04:56):
Now, the company did say this data came from a
legacy data system, apparently from over two years prior, and
they claimed no current user data was hit. But still
the fact that this data existed and was accessible, that's
the core issue.
Speaker 1 (05:08):
How did this even come out? It wasn't the company
initially was it?
Speaker 3 (05:11):
No, it actually surfaced through posts on Reddit and reporting
by four or four media they found user data, these
images being posted on four chan, the anonymous message board.
Speaker 1 (05:22):
Oh wow, so it's just out there.
Speaker 3 (05:24):
Out there, and users on these forums are claiming they
found an exposed database hosted on Google's firebase with and
this is a quote from reports, no authentication, no nothing,
just wide open.
Speaker 1 (05:37):
No authentication on a database with IDs and.
Speaker 3 (05:40):
Selfies apparently so t later did confirm that some direct
messages were also impacted.
Speaker 2 (05:46):
It just throws fuel on this whole debate.
Speaker 3 (05:48):
You know, does asking users for this level of online
identity verification, especially with things like driver's licenses, create risks
that many companies just aren't prepared to manage securely.
Speaker 1 (05:58):
It certainly seems like in this case, and it brings
us right back to API security. I saw a quote
from Ted Morocco, he's a CEO in mobile security.
Speaker 2 (06:05):
Oh yeah, I saw that too.
Speaker 1 (06:06):
You put it really bluntly, he said. The exposure of
verified selfies in ID images in the t app breach
underscores a systemic failure in API security rooted in broken
access controls, weak authentication, missing transport protections, and absent runtime.
Speaker 2 (06:23):
Safeguards that hits the nail on the head.
Speaker 1 (06:25):
He goes on, too often companies rush apps to market,
driven by subscriber growth and churn metrics, while privacy and
security are sidelined. But these failures aren't inevitable. They're preventable.
That's the key part. Preventable with discipline engineering, proper API defenses,
and a real commitment to protecting user trust.
Speaker 3 (06:45):
Preventable that's the word. It is preventable, George. But it
requires a different mindset, a real shift. It's kind of ironic, actually,
Hu So.
Speaker 2 (06:53):
Well, companies spend fortunes locking down.
Speaker 3 (06:55):
Their back end databases, right, they're crown jewels. They treat
database secrets gold.
Speaker 1 (07:00):
Of course standard practice.
Speaker 3 (07:02):
But then they often overlook the keys that their mobile
apps use, the keys to the front door essentially, So.
Speaker 1 (07:07):
When you say secret keys to the front door in
the mobile context, you're talking.
Speaker 3 (07:11):
About API keys, primarily API keys and similar secrets like tokens.
These are what unlock access to the server side APIs,
which in turn access the data. They are arguably the
most important secrets on mobile device holds, and the irony
is the same security teams who have a fit if
a database password leaked might not think twice about how
(07:34):
API keys are handled in the mobile app itself. It's
like putting Fort Knox locks on your vault, but leaving
the key under the doormat.
Speaker 1 (07:41):
That really undermines all the back end security doesn't.
Speaker 2 (07:43):
Act completely, it negates it.
Speaker 1 (07:45):
So why is API security so critical and why does
it get overlooked? What makes that mobile front door so vulnerable?
Speaker 3 (07:52):
Well, part of it is just the sheer explosion of APIs.
The attack surface on the mobile device is constantly growing
because apps talk to more and more back and services
via APIs over the Internet.
Speaker 1 (08:02):
Right, Everything's connected everything, And a lot.
Speaker 3 (08:05):
Of these APIs might not even be protected by traditional
username password logins. They rely on these keys. But the
keys themselves, they can often be stolen relatively easily from
insecure storage on the device itself, maybe from configuration files
left on a server somewhere, or and this is very common.
By decompiling the mobile apps code, a hacker can just
(08:26):
pull your app apart, find the hard coded apikey, and bingo.
Speaker 1 (08:29):
They don't even need the app anymore at that point.
Speaker 3 (08:31):
Nope, they can use that key directly to hammer your
API bypass the app entirely, and access your back end systems.
It's a direct line in that. Protecting those API keys
is yeah, yeah, leaving the front door wide open while
locking the internal rooms.
Speaker 1 (08:45):
That sounds like a massive problem, especially with how many
apps are out there. So what are the actual practical
steps developers and security teams listening right now can take.
How do you protect these keys?
Speaker 3 (08:56):
Okay, yeah, there are definitely concrete things you can do first,
and this is fundamental. Manage your apiit is completely independently
from the mobile app code. Don't bake them in, treat
them like server side secrets.
Speaker 1 (09:08):
Don't hardcode, absolutely not.
Speaker 3 (09:10):
Second, store those keys securely, ideally in a dedicated secret's
fault in the cloud. Get them out of the app
package entirely.
Speaker 1 (09:17):
Okay, So they live in the cloud. How does the
app get them when it needs them?
Speaker 3 (09:21):
That's the third step, Access them dynamically, just in time.
The app should only fetch the key right when it's
about to make an API call, and this is critical,
only after the app and its runtime environment have passed
something called attestation attestation.
Speaker 1 (09:35):
Can you explain that a bit for our listeners.
Speaker 3 (09:37):
Sure. Attestation is basically a strong check of verification process.
It proves that your app is the genuine, untampered version
you released, and that it's running on a device that
hasn't been compromised like rooted or jail broken, and isn't
running instrumentation frameworks like FREEDA.
Speaker 1 (09:54):
So it checks the app in the environment exactly.
Speaker 3 (09:57):
Only if both checks pass prove trustworthiness does the app
get temporary access to the API key from the cloud
vault to make its call. There are solutions out there
like approve runtime secrets specifically designed to manage.
Speaker 2 (10:10):
This whole process.
Speaker 3 (10:11):
And finally, you need solid governance around these keys. Maintain them,
update them, cycle them regularly and safely, and crucially, if
a key is compromised, you need the ability to revoke
and rotate it immediately without disrupting service for legitimate users
and without having to force everyone to update their app.
Speaker 1 (10:31):
That sounds much more robust. Moving beyond just the keys, though,
it feels like hackers just generally target phones a lot.
You hear about it all the time. How easy is
it really for them to compromise corporate assets or user
data via smartphones? And what kind of tricks are they using?
Speaker 3 (10:47):
Yeah, it's well, surprisingly easy in many cases. Unfortunately, again
it comes back to the attack or controlling their own device.
We mentioned jail breaking and rooting.
Speaker 1 (10:55):
That's often step one, right bypassing the basic security exactly.
Speaker 3 (10:59):
Once they have that level of control, they can deploy
all sorts of tools. They might use something like MIT
proxy that stands for Man in the middle proxy. It
lets them sit between the app and your server, intercepting all.
Speaker 1 (11:09):
The traffic, even encrypted traffic.
Speaker 3 (11:10):
They can often bypass TLS encryption yet, especially if the
app isn't doing proper checks like certificate pinning, which we
can talk about, so they can see data, modify data.
It's like a perfect eavesdropping tool.
Speaker 1 (11:22):
Okay, that's scary.
Speaker 3 (11:23):
What else, Well, they can reverse engineer the app, like
we discussed for finding API keys, but also just to
understand how it works, find logical flaws, figure out where
the sensitive operations happen. They use powerful security testing tools,
things like burp suite or Freeda, not for testing their
code but maliciously against your app.
Speaker 1 (11:42):
Freeda what's that?
Speaker 3 (11:43):
Freta is a dynamic instrumentation toolkit. It lets attackers inject
their own code into your running.
Speaker 1 (11:50):
App process while it's running.
Speaker 3 (11:51):
While it's running, so they can hook into functions, modify behavior,
extract data in real time. It bypasses almost any kind
of check you might do before the app launches. It's
incredibly powerful in the wrong hands.
Speaker 1 (12:03):
So given all that the common security practices we hear about,
like sasd dassed, maybe code obfuscation, there's just not enough
on their own when the attacker has this much control.
Speaker 3 (12:13):
Precisely, let's break those down quickly. SAAST Static Application security
testing scans your source code before it's compiled or run.
It's like a spell checker for security bugs in the code.
Itself useful, but it can't see runtime threats.
Speaker 1 (12:27):
Okay.
Speaker 3 (12:28):
DAS Dynamic application security testing tests the app while it's running,
trying to find vulnerabilities by interacting with it like a
user or an attacker would again useful, but typically done
in a controlled test environment, not the hostile environment of
an attacker's device. Neither SaaS nor DAST is really designed
for the scenario where the attacker fully controls the device
(12:48):
and the runtime environment obfustation, making the code harder to read.
It's a hurdle maybe, but determined attackers can usually deobfuscate it.
It slows them down, it doesn't stop.
Speaker 1 (12:59):
Them relying on the OS security iOS or Android.
Speaker 3 (13:03):
That's not enough either, because, as we said, jail breaking
or rooting blows right past those OS level controls. The
fundamental problem remains the bad actor owns the device they're
using for the attack. Your app is running in their playground.
Speaker 1 (13:16):
So if those traditional methods have significant gaps in this
mobile context, what is the solution? How do you actually
maintain integrity and protect sensitive communications when you can't trust
the device.
Speaker 3 (13:29):
The answer really lies in shifting protection to the runtime continuously.
It's about continuous end to end runtime checking starting right there.
Speaker 1 (13:38):
On the device. Okay, tell me more about that.
Speaker 3 (13:40):
This is where technology is like RASP, runtime application self
protection becomes so important. Think of RASP, especially dynamic RASP,
as embedding a security guard inside your application. This guard
is constantly active while the app is running. It verifies
the integrity of the app itself, has it been tampled
with It checks the environment as the device jail rooted,
(14:00):
is freeda attached. It monitors the app's behavior for anything suspicious,
and it can react in real time to mitigate threats.
Speaker 1 (14:08):
How does it react.
Speaker 3 (14:09):
It can take various actions, maybe alert the back end,
shut down the app, or prevents specific sensitive operations. It
also involves continuously monitoring the connections that APIs, the app
is calling, and the network channel itself. It's an active,
ongoing defense.
Speaker 1 (14:23):
And can you adjust how aggressive it is? Yeah?
Speaker 3 (14:26):
Absolutely good. RASP solutions are configurable. You might want stricter
controls for a banking app compared to say a simple game.
You can tailor the level of protection.
Speaker 1 (14:37):
Okay, that makes sense for protecting the app itself. What
about the communication channel you mentioned man in the middle
attacks earlier. They seem like a huge threat for stealing
data in transit logins, bank details, all that sensitive stuff.
Speaker 3 (14:51):
MITTIL is definitely one of the most significant threats to
mobile communication. And while HTTPS using TLS is the standard
and provides essential encryption, it's not fool proof, especially against
sophisticated attackers.
Speaker 1 (15:04):
What are the limitations.
Speaker 3 (15:05):
Well, attackers can sometimes trick users into trusting fake certificates,
they might steal the server's private keys, or sometimes the
validation process just isn't strong enough to be sure you're
really talking to the legitimate server and not an impostor.
Standard TLS confirms the server has a valid certificate for
the domain, but not necessarily that it's your specific expected server.
Speaker 1 (15:26):
So how do you add that extual layer of trust
you mentioned pinning?
Speaker 3 (15:29):
Exactly certificate pinning it's an additional layer of security on
top of standard tlshttps. The basic idea is you embed
information about the specific certificate or its public key or
a hash that your app expects the server to use
directly into the mobile app itself.
Speaker 1 (15:47):
You hardcode the certificate details sort of.
Speaker 2 (15:50):
You pin that information.
Speaker 3 (15:52):
Then when the app connects, it doesn't just check if
the server's certificate is valid. In general, it checks if
it matches the specific pinned information. If there's no match,
the app refuses to connect, preventing a potential midem attack.
Speaker 1 (16:05):
Ah, I see, But what happens when certificates expire or
need to be changed If the pin is hard coded?
Wouldn't you have to push out a new app update
to potentially millions of users every time. That sounds like
a logistical nightmare.
Speaker 3 (16:18):
You've hit on the big challenge of static pinning. Where
the pin is baked into the card. It can be
very brittle and lead to exactly that update nightmare, or worse,
your app stops working if the server certificate changes unexpectedly.
Speaker 1 (16:30):
So how do you get around that?
Speaker 3 (16:31):
The solution is dynamic certificate pinning updates. Instead of hard
coding the pin, the app can securely fetch the latest
valid pin information, usually over the air, perhaps managed by
the same system doing the runtime checks or apikey delivery.
Speaker 2 (16:45):
We talked about.
Speaker 1 (16:46):
Huh, So it can adapt exactly.
Speaker 3 (16:48):
It allows the back end team to rotate certificates as
netted without breaking the mobile app or forcing immediate updates.
The app always checks against the current correct pin value.
Mobile apps are actually well suited for this because the
app stores provide a relatively secure channel for initially distributing
the app. With a dynamic pinning logic. It makes pinning
(17:08):
practical and manageable. It ensures your app only talks to
your verified server, cutting off those midimim attacks effectively, SKY.
Speaker 1 (17:16):
This has been incredibly insightful. We've covered a lot, from
the strategic disconnect and mobile security to the specifics of
the t app, breach apike protection, run time defense, and
secure communication. The scale of the challenge is clear, but
also the potential solutions if you had to boil it down.
What's the single most crucial takeaway for our listeners, especially
(17:36):
the developers working on these platforms every day.
Speaker 3 (17:39):
I think the core message is that mobile security can't
be a bolton or an afterthought anymore. It has to
be woven into the entire development life cycle right from
the start. The t app is just one example, a
really stark one of what happens when crucial elements like
API security and runtime integrity aren't prioritized. We've seen traditional
(18:00):
approaches just don't cut it when the attacker controls the device,
So you need that multi layered strategy. Secure your API
keys properly, ideally managing them dynamically from the cloud, Implement
continuous run time protection like RASP to defend the app
in hostile environments, and lock down your communication channels with
dynamic certificate pinning. It's about building security in, not trying
(18:22):
to add it on later.
Speaker 1 (18:23):
Makes sense.
Speaker 3 (18:23):
So maybe the question for everyone listening is looking at
your current or next mobile project, what's the one thing
you'll do differently today.
Speaker 2 (18:29):
Or this week to raise the bar on security?
Speaker 3 (18:32):
Because it really is a constant arms race out there,
and taking proactive steps is the only way to stay
ahead and prevent your app from becoming the next cautionary tale.
Speaker 2 (18:41):
Knowledge is only valuable when you apply it right.
Speaker 1 (18:43):
A really powerful point to end on, build it in,
don't bolt it on, and take that one step today. Sky.
Thank you so much for sharing your expertise, my pleasure, George,
and thank you all for joining us for this focused
segment of upwardly mobile API and AB security. Just a note,
this discuss was put together using human sources and research
with some assistance from AI in structuring our conversation. Catch
(19:05):
you next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.
What Are We Even Doing? with Kyle MacLachlan
Join award-winning actor and social media madman Kyle MacLachlan on “What Are We Even Doing,” where he sits down with Millennial and Gen Z actors, musicians, artists, and content creators to share stories about the entertainment industry past, present, and future. Kyle and his guests will talk shop, compare notes on life, and generally be weird together. In a good way. Their conversations will resonate with listeners of any age whose interests lie in television & film, music, art, or pop culture.