Android Application Security Testing with Marko Belzetski

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe.

And welcome to another episode of the.

Test Guild Security Podcast. Today we'll be talking with Marco Belzelski, all about Android application security testing. Marco is a penetration tester and trainer at Clarified Security.

He specializes actually in Android and web application penetration testing. He also does a a big four.

Day web application security course, so he.

Has a lot of knowledge in this area. Really excited to talk to him about this topic. You don't want to miss it. Check it out.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation.

Check them out.

Head on over to micro focus.com app security.

Hey Marco, welcome to the Guild.

Hey Joe, thanks for having me.

Great to have you on the show. Before we get into it, is anything you want to tell us a little bit more about yourself that I may have missed in your intro?

Like you said, I work as a penetration tester.

I also teach a course, a four day web application security course.

And penetration testing Android applications is. It's one of my passions. I really love it. I wish I could do more of it. So that's me.

Awesome.

So why Android security? What made you drawn to this particular area of security?

Well, for one, smartphones in general, I mean nowadays pretty much everybody has them, right? Even countries where nobody really has access to personal computers, they will generally have smartphones. And smartphones are just everywhere.

Android in general, I guess it was just easier getting into.

I'm an Android user myself. Maybe we'll talk about this more in.

Depth later, but the consideration of testing Android apps versus iOS apps, for example, it's just easier to get started with.

Android because iOS I remember somebody called it like a diamond prison. You can see what's going on, but you can hardly really do anything about.

It or get in there and and break stuff.

So does Android, I guess give you better tools then to perform security type of exploits than in iOS?

It does.

Yeah, the system is much more customizable. And in that sense, I'm able to.

Have a device that I've set up.

That allows me to sort of test the security of these apps.

Whereas with iOS you're talking about finding a jailbroken device, you're about talking. Talking about keeping it jailbroken, which can.

Be a feat in itself, let me tell you. You can't even allow your phone to connect to the Internet unless they download an update or something and destroy your jailbreak.

So just make me think out loud here. Does that mean an iPhone probably has better security than an Android, or does it just make it harder to test security on an iPhone more?

The latter. I hesitate to say that iPhones have better security. They do a number of things that.

Protect the end user better.

In a sense, they sort of limit your options.

I think choice is evil sometimes. And with Android you can just, you.

Know, you can turn on developer mode.

Side load applications and things like that, whereas with iPhone that's much more difficult.

Also, I would think, I don't know if this is true, is that with Android you have vendors that come up with their own different flavors of oss. I'm just curious to know, does that create different vulnerabilities that you may not think of? Because maybe one flavor of the OS may have an exploit where another doesn't.

What you said is correct, but within the scope of penetration testing an application.

For a client, we're mainly focusing on what they provided, the code base that they've written, what their application does.

What you just said regarding the different.

Flavors of OS is that really doesn't.

Factor into the end result of a.

Penetration test, which is a report where we highlight possible vulnerabilities in our client's app as opposed to the system in general.

Okay, so that makes sense. So you wouldn't necessarily focus on that unless the actual vendor of that OS commissioned you to do a security analysis of their os.

Exactly. And interesting you just said that. I had another case just drop on.

My desk where the scope actually includes.

The device itself because they're providing their.

Employees with a device that's going to be running their applications.

So that will definitely have to broaden.

My spectrum in the sense that I.

Have to take a look at the.

System as well, not just the application.

Because I have to.

Identify what sort.

Of risks are there for the end user as well. And that encompasses the device itself in this example.

So what's your thought process then for exploiting a system vulnerability versus an application vulnerability?

Well, I mean, you do take a.

Look largely at what others have done.

Before you within the scope of a penetration test.

We don't really have time to start.

Looking for zero day vulnerabilities ourselves, so we mainly focus on what's been found before, what are the known issues, what are the known sort of threats, dangers.

Published exploits, things like that.

And I'm a total novice once again, so high level questions here. How do you know what's a known exploit? Is there like a framework that you follow or is it like a metasploit that has built in known, you know, exploits?

You can run Google, I mean the CVE database lists most of them. So what you do is you just look up the components that are in.

The system, look up their versions and then just cross reference.

So I think I did see on your website, or not your website, but on one of your previous sessions around this, something about OWASP ASVs.

Yeah.

What is OWASP? AVs, ASPs, and how does it help you with your security testing?

Owasp, that's an acronym for Open Web Application Security Projects.

What they do, they put together.

Different.

Cheat sheets, manuals, tools. Maybe you've heard of The OWASP top 10? That's fairly known.

But most importantly, they also put out a standard. So the ASVS is the application security verification standard. So that's something we use as a.

Basis for our web app penetration tests for mobile applications. OWASP also has a separate project for mobile, so they have the MASVs.

So that highlights different areas, different verification.

Requirements that we sort of use as a basis whenever we're looking for vulnerabilities in any system.

And.

Both the ASVS and the MASVS are actually really good tools for developers as well. So for example, if a developer is implementing, I don't know, let's say authentication.

Within their web app or their mobile.

App, they can just open up the.

Standard to the authentication category and as.

They build, they can keep an eye.

Out on the requirements for that category and make sure that whatever they're building.

Actually matches those requirements.

So curious, in your experience, how often.

Do you find an exploit that could have been prevented if a developer did just what you recommended?

Almost every time.

That's our job, right? So we discover something, a vulnerability, we.

Write it down in the report according to the appropriate standard category and the verification requirement.

And then what we also try to.

Do to really illustrate the risk is.

To come up with, with proof of.

Concept attack that will actually show what an attacker could achieve if they exploited this vulnerability.

So that's Cool. So I guess it allows them then to say, here's the risk and here's what happens if we ignore this risk.

Exactly.

So if you just write, oh, you have a vulnerability here, you miss this requirement and then nothing else, then it becomes really easy to overlook if you don't really understand what could happen.

And that's actually the, I would say, ethos of our training courses as well.

We always put the attack the participant.

In the attacker's shoes, so they get to try everything out and really feel what could happen.

What is that process of having someone walk in, like, an attacker's shoes? Do you give them a tool to use and say, okay, run this particular script to create this exploit?

We don't really go that far. These are sort of.

I hesitate to say they're introductory courses because we do go in depth, but a lot of time you don't really.

Need any specific tool. You just have to understand how it works. And we really focus on showing why.

These vulnerabilities are dangerous and how they could be exploited. Now, this is where web applications really.

Differ from mobile applications.

Because with web applications, most of the.

Times all you need really is a browser.

So that's not proprietary tool in any way. Everybody has a browser, right. And they're all available, different versions of them.

So you just need a browser, some knowledge of maybe HTML, JavaScript, and that's it.

For mobile applications, it becomes a bit different because there are different considerations. So we're talking about risks to the end user, we're talking about risks to.

The developer of the application, we're talking about risks regarding.

Personal information being leaked from the app. So it becomes much harder. And that's actually a challenge that I.

Faced when putting together my Android training as well, is how to actually let the participants carry out these attacks without using too many special tools or something.

That'S only set up in our trading environment.

So most of the times these tools are freely available that we do use.

Because, like you said, a browser, everyone has a browser. Everyone could probably do a browser exploit. Do you know that makes people have a false sense of security, that, hey, it's a mobile app, less people would be able to be able to hack it.

Absolutely, definitely. Because, well, one of the simplest things that we're sort of taught to recognize when it comes to web apps is.

The little green padlock icon right on the address bar.

That in itself is sort of a.

False sense of security.

Oh, it's green, it's a padlock.

That must mean it's secure when it.

May not necessarily mean that.

It just shows that your communication is encrypted.

If we're talking about unencrypted communications, well.

The threat's there just as a brief sort of overview.

Sorry if I'm going over something that you already aware of. But unencrypted communications, anybody on your network essentially can read the contents or even modify them. It's like sending a postcard, Right? The mainland can read what you wrote. With mobile apps, especially apps that use some sort of backend API service, you don't see that.

You can't even know for sure that the application is sending communications over an encrypted channel.

That's just one example of where mobile applications may lead you to sort of feel a false sense of security.

So do you have like a drop your chin type of demo that you can get people to show them just how vulnerable their Android app might be? I know, like with web. Someone show me Fiddler just opening up. Fiddler was able to say, hey, look, passing clear text here. And that was like, bam. You know, wow, this is something you could show any developer.

I do. I've actually done it at a conference called TalentSec, which one of my colleagues.

Hosts and puts together and organizes. I'm not sure if the video of it is out there somewhere. I was planning on putting it on our homepage.

But just to summarize. So what I like to do is I like to go on the Google Play Store and download any app like a game. And it could be even a game.

Or an app that you have to pay for.

Then I simply extract the application from my phone and I put a backdoor.

In it, like a Trojan, or it's sometimes also called a rat.

Remote Activated Trojan, I think it was. Yeah, just using freely available tools. They're all out there.

Everybody can download them.

So I put this in the application, I package it back together, and then I install it, or I sideload it on another Android device. So you can imagine how these applications.

Might end up being sideloaded.

So if it's a paid game or.

Something, somebody downloads it, trojans it, puts.

It back together, and then, I don't.

Know, puts it on a torrent website or something.

And then people will download it, sideload.

It with the promise of, hey, you're.

Getting this application for free.

But as soon as they open the.

Application, I get a nice little callback to my whatever, Metasploit console, and I essentially have complete control over the device.

Not only that, if they take their.

Device, for example, into their home network.

I now have a backdoor into their home network as well. So from there I can start pivoting.

See what else they have in their.

Home network, PCs, routers, things like that.

So that's what I like to show people.

I can see how that's effective. That's kind of scary what you could do.

It is.

I think the biggest reaction you get from this demo is when I use the backdoor application to take pictures or.

Video with cameras on the phone.

So that's interesting then. So it seems like, I guess, is this something people should be aware of, just downloading apps from the store, a general Android store? Is it just torrent sites?

Well, there have been cases where applications on the Play Store have contained malware. As far as I know, Google is trying to stop it. They have their own scanners that try to verify the intentions of applications in the store.

And there have been several news items.

As well, like Google has removed X.

Amount of applications from the store that contain malware.

So it's not 100% safe.

It is safer than if you would sideload applications or use some other application store.

Like, I'm not saying they have issues, but for example, before you can use the Amazon Application Store, they have a.

Very neat little guide that shows you how to enable sideloading of applications on your device.

Now, a user that has already done.

That, all they need to do to become infected is to, let's say, click.

A link that has an APK file, download the apk, open it, install it on the device and they're already infected. So that's something to definitely avoid is.

Side loading, unless you know what you're doing.

So you do have a four day training. Is there anything, a common theme that comes up over and over again that you find folks struggle with to understand with security?

Whenever we do a training, at the end we usually do a round of feedback. And within this feedback round I always ask, so did you have like a.

Wow moment or a WTF moment?

And I'm not lying when I say I think every topic on the course has been mentioned for these wow or WTF moments. So even if you have seasoned developers that come in, if they haven't heard about something before and they've just been.

Exposed to this during our training, then.

I mean, for them that becomes an issue, right? They're gonna have to go back and.

Review all the code that they've written. So it's hard to sort of point.

At one specific thing because they're all equally important and they can all really have dire Consequences if, if they're ignored.

Or overlooked the principles you teach in that web application security cost, then are there any attacks that are more common with the web than Android that folks need to know about?

Sure.

Some attacks are only possible on web.

As opposed to Android.

For example, cross site scripting, maybe you've heard of this is not so prevalent on Android because context is different. Unless we're talking about some sort of embedded web frame and the application literally is a website within an app, that's something. Cross site request forgery is a particularly nasty one that is prevalent mostly on web. It doesn't really apply to mobile, so there are examples. But to answer your question, if there's something to avoid when. Well, I mean, don't click on suspicious links, that's really golden sort of recommendation.

Good advice. So Marco, is there also after someone takes your training or goes to one of your sessions, when you're speaking about security, Android security, any type of security, is there anything they could do when they go back to their companies to actually, is there like a, like a security plan they could put into place to help them actually start implementing this throughout the company?

Absolutely. One thing to take into consideration, especially.

With our web trainings, the target, well.

Not the target audience, but it's mostly attended by developers. So my recommendation always is that after.

The training they go back to work and they take a day, maybe even two days to try everything out they've learned on their own applications.

That's really the sort of, that's the best way to. Well, for one, to really make what.

You'Ve learned or to integrate it rather to sort of go over it, try it out, see if something works, see if we've done something that's already good, maybe we missed something, maybe our framework has missed something. So that's our sort of main recommendation, is that you actively try these things out on your own applications as well. You don't have to be a pen tester to do it.

Great. Now I do love tools, automation tools in general.

So for security tools, what's part of.

Your, like your toolkit that you always go to, that helps you with? I know you said it's not necessarily about the tools, but are there any essential tools you think people should know about when performing any type of, type of security session?

Our sort of bread and butter are.

Intercepting proxies that allow us to intercept.

Requests and responses to, to a web server. I can see where this question is.

Sort of leading regarding automated security assessment tools.

In my opinion, in our opinion from everybody in my company is that.

There are some okay ones out there, but they can only get you so far. They most likely will only be able to pick out what we call the low hanging fruit. So maybe issues with output encoding, things like that that are just immediately apparent and can be sort of made into an algorithm. But as soon as we go further.

Than that we start getting more complicated. Things like multi step forms, business logic, authorization controls.

There is no automated tool that can do that. I mean at least until we have, I don't know, AI. Because security is simply not automate. What's that a word? Automatable.

It does require a hands on approach.

And that's actually tuning my own horn here.

Whenever we compete for tenders, we come.

Out miles ahead over companies that only use automated tools because we do everything manually, we review everything, we look for these vulnerabilities, we qualities of our reports, like I mentioned before, we go through the vulnerability, we go through the proof.

Of concept attacks and we really highlight.

What the risks can be.

So this is a great point because with typical software development activities, people are trying to push it earlier and earlier in the software development life cycle. So that's why they try to automate everything. But is security then essentially something that can only be manually done? Is it after everything's done baked in or how do you implement then security? When people try and deliver software faster.

And faster, it's not something you can.

Just add on later. It has to be a part of the software development life cycle. So with every iteration, with every sprint, whatever functionality you're building. I mentioned the ASVS before that it.

Can also be used as a development tool. That is our recommendation. Just keep a copy of the standard.

Keep it next to your desk. Whenever you're building something, take a look.

See what requirements apply and just refer to that. If it's used in such a way.

Then in the end during our pen.

Tests we've had cases where well, we.

Don'T have all that much to write up.

So I know one thing, it sounds kind of low tech but helps a lot of teams.

Checklists.

Are there any checklists out there that folks can go to to help them with the security efforts?

I think OWASP actually has some. Well, they have cheat sheets.

I'm not sure if they have checklists.

You can certainly take the standard and.

Make a checklist out of it, but.

That'S probably the closest thing.

I mean essentially it kind of is a checklist. So for example, off the top of.

My head, verification requirement 3.11 I think it is Session tokens should never be visible in URLs. That's a very easy thing to check.

Right. So if you see a session token.

Somewhere in a URL or visible in any other place, that's an automatic fail. And that should be remedied as soon as possible before the application even comes across our desks.

Cool. So Marco, is this training online or is it just in person?

It's in person.

It really requires.

The trainer to be.

In there with you to answer any questions to help you with labs if you get stuck. We've considered creating an online course, but it would just reduce the quality of.

The course, of the training that the.

Participants get in the end. So we're firm believers that we actually have to be there.

And we do trainings abroad as well, where we go on site and we.

Bring our gear with us and we set everything up there.

Okay, Marco, before we go, is there one piece of actionable advice you can give someone to help them with their security testing efforts? And what's the best way to find or contact you?

Definitely, it's to print out the standard. Read through the standard.

Doesn't matter if it's web applications or mobile applications. So the OWASP Application Security Verification Standard is a great tool. I think all developers should refer to.

It for testers as well. Even if security testing is sort of.

Not your main goal, it wouldn't hurt to maybe include some of those test cases in there. Yeah, the OWASP project is a great place to start.

Thank you, Marco, for your security testing awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com.

And while you're there, make.

Sure to click on the Try it Today link under the exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. So that's it for this episode of the Test Guild Security Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack testing awesomeness. As always, test everything and keep the good.

Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.