Hey, folks, this is mobile app. Sec one a one. A cyber recourse on mobile application security testing. I'm Tony Ramirez. I'm a senior application security analyst. That now secure today is our last video video, five of the mobile app sec one on one, Siri's and we're covering everyone's favorite topic tools for testing.
So we have a couple learning objectives today. We're gonna talk about common tools that you might be using for dealing mobile application, security testing, but only that we're gonna talk about some methodologies behind that testing. When you first start using those tools and what you really should be doing, we're gonna cover network forensics and code quality.
And really, this is really just the start of getting into the testing and kind of using these tools and kind of figure out which tools you like the most, because that is an important part
of security testing.
So let's actually get into our tools of the trade for a lot of us. We know what tools we like to use. So what I will recommend is if you have a preferred terminal, a preferred network interception tool, and we're other tools that you know you can rely on because you've known them for a long time. Use them. You should use what you're comfortable with.
But there are some tools and mobile that a really mobile specific. And if you've never encountered
them, it's likely you haven't heard their names. And it's really important to kind of dig in and learn those tools because they are widely accepted by the industry and they're super useful. So, you know, figuring out what those are is important and really having rooted in jail. Broken devices, as we said before, are crucial to doing this. Testing.
Having developer tools is really important to
that. Could be things like using Andrew Debug Bridge or using part of X code to, you know, install lapse on your IOS device. Really, these tools air Super crucial to perform a lot of these testing, and I will say this you're not gonna be able to install a nap without them, and that's the first step to testing.
Not only that, but there's a lot of crucial reverse engineering tools. I kind of mentioned this earlier, but there are tools that are specific to mobile. Frieda and Radar er really useful for Mobile. They aren't specific, but they're so widely adopted for mobile application security testing that I almost always recommend them to anyone who's doing any mobile security testing. Finally,
the one thing that's really important across all of security is having that patience and creativity and just having it like attention to detail.
Because a lot of what you're gonna be doing when you're testing APS isn't really a formula. It's kind of looking at things. Looking back, seeing if that changes, seeing if small things come up later and how they're affected across this whole testing thing. So
remember that there is no right order.
Let's start off by talking a little bit about network interactions.
We're talking about man in the middle in your device, seeing those network calls, seeing what's being sent and received and how they're being sent and received. We want to test before and after logging because some applications will implement security protections or certificate validation hosting verification on the application. But they won't do it
on certain requests after log in.
So it's important for us to kind of get that full coverage. Make sure that we're able to see what happens after lug and see if those protections are in place. But not only that. We also want to exercise the gap. I said this in the previous video, but exercising the act is so incredibly important when doing security testing.
It's a crucial task because really, we want to see how all those flows interact, how certain endpoints
happen and how certain interactions happen. And really, it adds more data toe what you're collecting, and, you know, if you miss something and because he didn't exercise the app in a certain way, you're gonna miss out on some security issues and you know, they could be a big issue down the line.
You know, we're also looking for sensitive data were also looking toe bypass a lot of these controls and see what actually is being sent by the APP because it's really gonna help us do Web ap. I testing when we get further down the line, And for those of you who are already like Web security experts, it's likely
that you've come into mobile and the first thing you've done is tried to intercept traffic and right away realized you can't,
you know, a lot of the time that could be because you're not able to intercept that traffic because of pinning.
And, you know, getting past those controls is super important because that's really the first step to doing a lot of that type of testing.
So one thing I find that's really helpful for people who are first doing that work testing and mobile is kind of understanding the architecture of what you're actually setting up and how you're doing that. And, you know, for me it helps to kind of see that, um, you know, the network logic here is basically we're intercepting traffic
via a proxy. In this case, we're showing Madam Proxy we have a C A certain stalled on that device,
and that helps us because now we're in the trust door of that device, and now we're intercepting those calls between the server. We want to see what's being sent. We want to see how it's being sent. Maybe it's being sent over. Port 80 otherwise known as a cheeky P.
Hopefully it's being sent over 443 and maybe it's easing some controls to kind of protect itself from being man in the middle. Those air important to keep in mind because, you know, down the line,
I actually said before, we're gonna want to bypass those.
The next common attack surface area we're going to talk about is data at rest or forensics testing. We're testing the data that's being stored on that device, and we want to see how it's being stored where it's being stored. And not only that, but if proper procedures are being used to store that data.
So the one thing I will recommend to you is that you kind of are dealing testing. You probably have a log in. You have a password. You want to look for those terms stored on the device, but you actually don't want to just look for those terms.
You want to look for variations on those terms. I kind of like to say, like, take a rainbow table approach, consider your user name. Consider your password.
They're likely not going to only be stored in plain text across a nap. It might be starting base 64. They might be hashed. They might be encrypted, but we really want to find it when it's in that reversible format, so kind of creating ways to look at that data in different ways is really helpful because,
you know, if we're storing a password on base 64
that's a reversible format, and that's a big no no. The other thing I'll say is get really comfortable with terminal tools because you'll want to grab for these terms, and it will make your life so much easier if you get good at using those tools.
The other end of that is the jail broken and re a device thing. We talked about it before, but really, if we want full access to that device and you know being able to see certain locations on IOS and Android are really only possible through jail broken android devices,
they really do make security testing easier. So there are some locations on your device that can be viewed without jail broken rooted devices. And one of the most common that comes to mind is the SD card on Android. IOS doesn't have an SD card, but Andrey does,
and the SD card actually isn't a physical SD card. What it actually is a convention that state
When devices started getting kind of old and they wanted to expand storage. And, you know, maybe there wasn't enough storage for at some of those devices they had to come up with a mechanism that allowed people to expand their storage. So why did Andrew do that? Create the SD card. That convention stayed, and now it's called Emulated Storage
or external storage or just public storage. There's a bunch of names for it. Just be aware of somebody's talking to you. And they're like, Oh, you're storing at and emulate storage. That's not good.
They're referring to the SD card.
But here's the thing. App, skin right there, bacon store sensitive data their users can access it. And other APS can read the data that's been written by users and other APS there.
It's a really insecure location to write sensitive data. So if you're writing something like run time
variables or sensitive values,
you know that's a big no no, and you want to make sure you're not doing that again. This is an android specific thing, but it's something that can be accessed without a real device. Another example would be back up in system logs on Android and IOS. So, you know, storing that type of data. There is not a good thing.
But on top of that, you know, we're also interested in things like hardware, back storage, like key store key chain, which again are only accessible through jail broken rooted devices. But we really want to understand the logic of habitat works. Maybe there's a JWT stored. There may be user name and password, maybe something else. And really, the only way we're really gonna understand the APP is
using that information. We really want to get as much context. It's possible
that kind of leads to the next point.
I'm going to repeat myself again,
exercise the gap. If we don't exercise the app, you know you're not going to get the full picture.
This is not meant to be an exercise infomercial. I am not Richard Simmons, but you want to exercise the app