Pentesting mobile apps

Pentesting mobile apps

- Do you know that over 95% of Android applicationsare vulnerable to different attack vectors?Out of these, over 70% applications have already undergonesome level of security testing.Then, why are these applications still vulnerable?Simply, because there's a lack of structured approachwhen it comes to Android app end testing.Hello everyone.

Overview of Android

Android happens to be a 30 billion-dollar industryfor its parent company Google.There are over two billion worldwide userswho are interacting with Android operating systemvia their mobile devices, tablet PCs,smartwatches or even television screens.It comprises of over 88% of the world's total mobile users.Let us go over some basic features of Android.Android OS and its entire projectis managed by Google.It is available as an open-source operating system.It is basically a modified lightweight versionof the Linux kernel where all non-essential driverslike printers, ethernet cables, USB, etc.are removed to give it a lightweight habitat.Android is versatile in its usage,as it can be seamlessly usedfor all varieties of smart devices,like mobile phones, tablet PCs, smart TVsand even your wearable devices.

Activity and services

And activity represents a single screen user interface,and any action that you perform on that screen.In simple terms, an activity is to Android,what a webpage is to a website.Whenever you go to a website, you see a pageand if you happen to click on any object on that pageyou're taken or redirected to another page.Similarly, whenever you open an Android applicationyou see something like a page.This page is called an activity.When you click anywhere on this activity,you are redirected to another activity.The flow of control between two activitiesis either controlled through a user interactionor through flow controls defined bythe application developer.Say, you are shopping on your favorite mobile application.In that case, the control flowis decided by your preferences.Like the product that you want to buy,the sizes, specifications, et cetera.But, if you are registering for a specific utility,like your favorite social media account,then the application governs the flow of the activities.There are certain taskswhich needs to be performedwithout a user interface.Here comes the rule of services.Let us see what services are.Services are the components without a user interface.They can be used to perform long-running operationswhich do not require user interface,like background activities.Once started, these services keep on runninguntil you explicitly pass a command to stop them.Hence, they are used for background tasksthat do not require constant user inputs.Services are always started by another component.If you wish to start a service,immediately after an application has started,you generally start it using the launcher activity.Some common examples include, music players,fitness trackers, location services, et cetera.Consider a scenario where you are takinga road trip with your friends.You need your mobile device to use navigation,but at the same time, the same device is usedto play your favorite songs as well.Here the music application is runningas a background service.

Content providers and receivers

Content providers is the mechanismthrough which an application shares and requests informationfrom other applications.To share any information with other applicationsyou have to provide a content providerand implement a set of API's.For example, if application one needsto share credit card details with application two,application one will publish a content provider.Application two can then access itafter proper authorization.Similarly, requests for information from other applicationsare handled by an entity named content resolvers.Let's say your application needs access to Galleryor Contacts, then your applicationwill request the content resolver for Galleryor Contact details respectively.It goes without saying that content providersare one of the easiest way to access data,stored or created by the application.Hence, they need to be protected in a mannerthat they cannot be accessed by any other applicationwithout proper authentication or authorization.Let us now discuss about the fourth componentof android applications, that is broadcast receivers.Broadcast receivers simply listenfor broadcast messages from your Android operating system,as well as other applications on your device.It can listen to system wide broadcasts,like when the battery is lowor when you receive a phone call.It can also listen to app specific broadcasts,like when you receive two factor authenticationmessages on your phone.Suppose you want your application to be notifiedwhenever your phone battery is down,or any other system event is triggered,you can simply add a broadcast receiverwithin your application.Whenever that event is initiated,the code in your broadcast receivers automaticallystarts executing.You can even program your applicationto send broadcast messages and receive itwithin the application.Hence, if exploited broadcast receiverscould be very helpful in reading inputfrom the application or even from your phones.

Web vs. Android security

Android application pen testing is a relatively new conceptas opposed to Web application pen testing,which has been there for more than a decade now.There are some significant differences between the processand approach of Web and Android application pen testing.To begin with, in case of Web application security,client-side goal comprises of HTML, JavaScript, or even CSS.Hence, client-side testing is not very significant.But in case of Android application, client-side testingor testing of client-side code becomes very significantas a considerable amount of processing occursat the client end as well.For Web applications, source code of the applicationis generally not known unless we are talkingabout white-box assessment.But in case of Android applications, the source codeis easily accessible and available, hence usually comesunder the scope of work of penetration testing.While testing for Web applications, we usually ignorethe risks associated with compromised end-user devices.But in case of Android applications,compromised end points are major risks.In the coming sections, we will look at the examplesof similar test cases.Lastly, in case of Web applications,access to the application is always secure.What I mean by that, is there is only one single sourcethat is your Web server through which users can accessthe website, but in case of Android applications,users may download the application via third-party source.Now these applications may be legitimate or may be infectedby some kind of a malware.Hence, we need to make sure that the APK is not compromised.

Domains of Android security

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Now that we have established the differencesbetween web and Android application testing,let us analyze the different domainsof Android application security.Primarily, there are three domainsof Android application security.First is code security.Under code security, we check the qualityof the code of the application file.We check if there are hard coded IP addresses,credentials, weak cryptographic libraries,insecure certificates, or any other vulnerability associatedwith poor coding practicesin the code of the Android application.Second is communication security.Under communication security,we check how the application interacts with the server.Here, we test for vulnerabilities in the authentication,authorization, session management,and other dynamic parameters used in the interactionbetween the application and the server.This portion is basically similar to what we dousing bug sweep for web applications.The third, and the last is platform interaction testing.Under this, we check how the application interactswith the Android device.Here we check for leakages in sensitive informationlike usernames, passwords or any other confidential datathat the application does to the Android deviceor any other application installed on that Android device.In the coming sessions,we will be covering each of these domains in greater detail.

Common terminologies

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Before we move further into the course,let us understand some key recurring terms.The first is automated testing.Automated testing is an activitywhere we hook our target application with a tool.This tool then runs multiple test caseson the application and records their output.Once the analysis is over, it will present its findingin a format like HTML, PDF, or even an Excel sheet.Entire process requires minimal human interaction.Manual testing on the other handis where we do these exact same activitiesbut every step, that is running the test case,recording results, and reporting is done manually.I know it sounds pretty exhaustingand to some extent you would be right,but the fact is that both those techniqueshave their own advantages as well as disadvantages.There are certain vulnerabilitiesthat you can easily find using an automated test,while others requires extensive manual efforts.White-box assessment is where we doa thorough source code analysis.For all practical purposes, we are given the source codeand we have to analyze different vulnerabilities.Black-box assessment on the other handis where only minimum informationis provided to us about the application.In certain scenarios, it might just be the place to linkoff the mobile application.We are then expected to test the applicationfrom the perspective of a real attacker,that is, analyze the application flows,test the authentication and authorization matrices,implement SQL injection,or Cross-Site Request Forgery, et cetera.Next we have dynamic application security testing, or DAST.DAST involves supplying different types of inputsto the application and record their output.It is essentially helpful in finding vulnerabilitieslike SQL injection, Cross-Site Request Forgery,insecure communication, et cetera.It can be automated or it can be manual.Static application security testinginvolves a white-box approach to finding vulnerabilitieslike hard-coded passwords, exposed URLs,insecure cryptographic implementations, et cetera.Though SAST can be done manually,there are many tools available which have automated SASTto a reasonable degree of precision.Interactive application security testinginvolves a combination of SAST and DASTwhile eliminating their drawbacks of both.It involves placing an agent inside the testing environmentthat can control how our target application works.In the coming sections, we will be coveringdynamic and static application testing proceduresin great detail.

Lab setup

Selecting transcript lines in this section will navigate to timestamp in the video

- Before we start testing Android applications,let us talk about the lab setup.On the hardware front, you will need a workstationwith at least 8 gigabytes of RAMand a processor with at least 2 gigahertzof processing speed.You'll be needing a physical Android devicehaving Android version 6 or lower.In case you have a rooted Android devicethat'll be great.In case you wish to use an emulator,you may use Genymotion, MEmu, or Android Virtual Device.It's really your choice.Lastly, you'll be needing some USB cablesto connect your device to your workstation.In case you are using an emulator, this won't be necessary.On the platform requirement front,all my tests will be conducted on a Windows 10 machine.However, you can use Linux or MacBooks just as easily.You'll need Java JDK version 1.8 or above.That includes the installationand setting environment variables.You'll also need Python version 2.7 or aboveand Python version 3.6 and above.Now, running both versions of Pythonon a single machine is a bit tricky.So if you are new to this environmentI suggest installing them step by stepas I'll demonstrate in the video.Or use the link below to work your way around it.There are of course other waysof running both versions of Python simultaneouslybut the method mentioned in this link is by far the easiest.In addition to that, you'll also needthe Pip package installer.Most of the time, this comes by defaultwith your Python installation executable.But in case you're using Mac or Linux environmentyou might need to install it additionally.You'll need Git for Windows environmentand platform tools(clicking)Now let me just show you these two specific requirements.I'll just move over to my Google Chromeand you can go to Google,search "android platform tools"(clicking)open the link.Once you are on the link, you can scroll downand you can select whichever versionof operating system that you're using.I'm using Windows so I'll just go ahead and download.(clicking)(clicking)Once the download is finished, you might need to extractand set path variables on your operating system.(clicking)You can just copy this part(clicking)press the Windows keyand search for "path"(clicking)(clicking)Here you click environment variablesand under the heading System variables,you can search again specific path variable.You go to New(clicking)or you can just double-click hereclick on new(clicking)paste the part that you have already copied(clicking)This ensures that you'll be able to use all these utilitiesthroughout any folder in the system.For installing Git on your Windows system,you just have to search "git windows"(clicking)The first link that comes up(clicking)gives you the direct installerthrough which you can access Giton your Windows command prompt.

Introduction to MobSFSelecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] In this section,we will begin with Mobile Security Framework,which is used for static application security testing.MobSF is an automated, all in onemobile application pen-testing framework,capable of performing static analysis,dynamic analysis, malware analysis,and API testing of the APK file.It is developed by OpenSecurity,but we will primarily be using it for static code analysis,that is, white-box testing.It runs a comprehensive assessmenton the application components, the SSL certificatesand the manifest files,in addition to doing the basic code analysis.Though we will focus only on Android application,MobSF works for iOS and Windows applications as well.

Setting up MobSFSelecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Now let us start with the instillationof Mobile Security Framework.Before we begin, let us go over the prerequisites.For installing MobSF we will needJDK version 1.8 or above,Python version 3.6 or above.I will be using Python version 3.6.8.In addition to that,we'll also needGit Command Line interface.Lastly, since I'm going to use Windows 10,as the host operating system,I'll also need Microsoft Visual Studio 2019,Community Edition.It's your preference really, you can go forDeveloper or Enterprise Edition as well.For instillation,we will do a simple Google search of MobSF.The first link that comes up is the official Git repositoryof Mobile Security Framework.All you need to do, is to go to this repositoryandcopy the Git clone link.Now we will clone this directoryinto the Python36 route folder.Now, once we are in the Python36 route folderthe first thing that you need to dois pull up the Command Prompt.For that, we'll go to the address barand type CND hereand press enter.There's a simple trick to pull up Command Promptanywhere in the file system wherever you like.Once we are here, we simply need to coneMobSF Git repository on to this folder.The command for that isGitclone,and then you simply paste the linkof the Git repository here.If all goes well, cloning would start.Once the cloning is done,and before you start the actual instillation of MobSF,what you need to do is upgrade yourversion of the Pip package installed.The command to update Pip ispythonminus Mpipinstallminus minusupgradeand thenwhich package do you want to upgrade?That is Pip.If you are using a lower version of Pipthis will uninstall that versionand upgrade it to the latest one.If you are using the latest versionno major change would happen.As you can see, since I'm using the latest version already,it just throws a prompt sayingthat requirements is already up to date.Once the update is successfulall you need to dois to move into the MobSF directorythe command for which is cdMobSF.You can simply writeMo and press tab that'll also do.Once in the MobSF directoryyou have to run the shell script or the batch scriptdepending on which host operating system you're using.In my case it will be the batch script.That is,setupdotbatch.This will automatically check if all the basicrequirements for setting up MobSF is met.If yes, it will start installing MobSFon to your system.During the course of the installationyou just need to pay attention to the color codes.If anything comes up in red font colorthat symbolizes an error.It means something is wrong and you'll need to resolvethe issue before proceeding.Anything that comes in white, yellow, green, or bluefont color is accepted.Now as you can see, MobSF is successfullyinstalled on your system,since the command prompt has returned.So, in this way you can successfullyand easily install MobSF onto your systems.

Scanning target applications

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Now that we have set up MobSF properlylet us start the analysis of Android applications.To start MobSF we will simply run a script, run.bat.If all goes according to planyou'll see a simple URL where the MobSF server is hosted.You can copy this, go to your browser, and paste it here.This brings up the MobSF interface.Setting up MobSF is the only challenging partthat you'll come acrosswhile you're analyzing Android applications.Now that we have set up MobSF properly,what we need is a test application.To do that, we run a simple Google search: sieve drozer.The first link that comes up,let's go to that,and you scroll down,till you reach Resources.Here you will find sieve.Now sieve is an intentionally vulnerablepassword manager which you can use for testing purposes.So let's just go ahead and download this.Now all you need to do is drag and drop your APK fileonto your MobSF interface.Sieve happens to be relatively small.Depending on the size of the applicationit may take from a few minutes to even 20, 25 minutes or so.So, that's how we run a testagainst any application over MobSF.The same process can be done for Android, iOS,or Windows applications as well.

Manifest analysis

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] MobSF runs a complete analysiswhich includes static application security testingthat is sassed, certain aspects of dust, malware scansand some test cases related to reverse engineering as well.The beauty of MobSF is that it pretty much does60 to 70 percent of the tasks that you need to performunder Android application penetration testing.If you scroll down a bit,you will see that it tells us aboutthe full application components,that is the activities, services, broadcast receiversand content providers.If you scroll further down you can view or downloadthe reverse engineer Java code for this application.You can also check out the Android manifest fileand find out which settings are incorrectly configured.But MobSF does that for us as well.If you just go to the site menu under security analysis,it has an option named manifest analysis.Here it gives me all the information that I needto understand what types of permissions are definedand exported by this application.Not only that.It tells me which activities, services, content providersor broadcast receivers are not safe.For example, this activity password list is not protected.Since we know that seal is a password manager.We can make a pretty safe assumption that the activityPW list corresponds to pass word lists directly,which means that somewhere or the otherthis application is exposing the passwords storedby the users to other applications.It also tells me that the database content provideris not protected,thus implementing adequate security controlson these components would be our recommendation.Another fact that you should keep in mind is to separatethe false positives.For example, here it tells me that the debug modeis enabled for this particular application.Now debug mode is usually enabled for applicationsthat are in QA stage, u witty or even staging environment,hence if you are testing an application,which is either of these three phasesthis would be considered as a false positive.But if you are testing the production application,this would be a very valid recommendationthat the debug mode has to be disabled.

Code analysis

Selecting transcript lines in this section will navigate to timestamp in the video

- [Educator] MobSF handle static code analysis pretty well,you just need to go down the side menuunder security analysis and just click on code analysis.Code analysis will tell youabout hard coded usernames and passwords,cryptographic keys or even possible exposurein IP addresses.All you need to do, is just go to the links providedadjacent to these discoveries and browse them yourself.Because there is a good chance that some of themmay turn out to be false positives.It can also tell you about errors in SQL query parsingthat may lead to SQL injection.MobSF has several other fantastic featureslike performing a basic malware analysis on the APK fileusing YARA rules by Virus total.It can also do basic reconnaissance on the URLs,Firebase DB, Email Ids and Trackersdiscovered within the application.It'll also tell you a list of stringsthat are discovered in the application.Which could give you some idea aboutthe nature of informationthat the application processes, stores and transmits.It also has features for Dynamic Analysis, Binary Analysisand doing other analysis based on your manual test cases.A word of caution though,once you have done all the analysis using MobSF,you need to eliminate false positives particularly fromstatic code analysis before sending your final report.MobSf is a comprehensive tool, you can use it forDynamic Analysis, Static Analysisand other different types of analysis.But, don't forget to conduct manual testing as well.Because several vulnerabilities are discoveredusing manual testing only, details of on all manual testswill be discussed in the coming sections.Many a times app uses third-party APIs,frameworks and libraries.In General we call them third-party integrations,there is a possibility that MobSF discovers certainvulnerabilities in these third-party integrations.You may need to inform the owner about the risks thatthese third-party integration cause to the main application.But, there is a good chance thathe'll not be able to mitigate the same.Simply because he doesn't have controlover these third-party integrations.Last but not the least, not every vulnerability reported byany method of testing can be fixed.But, you can always work with the development teamto reduce the likelihood or impact of these vulnerabilitiesdown to a much acceptable level.

Introduction to Burp Suite

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor]] Let us start with the second domainof Android application pen testing,that is communication security.In this entire section, we will be using Burp Suiteas our tool of choice.So let us understand how Burp Suite works.Burp Suite happens to be one of the mostfamous penetration testing tool.It is basically the bread and butterof every pen tester out there.So, if you dream to be a pen tester,you need to learn how Burp Suite works.Using Burp Suite, we'll test the securityof the network communication that happensbetween the Android applicationand the application server.What Burp Suite basically does,is creates a proxy between the applicationand the application server.We will also use a custom SSL certificateto enable the interception of SSL-encrypted requests.What we will do is perform a man-in-the-middle attackto intercept, monitor, modify,and retransmit the data travelingbetween the application and the server.Using Burp Suite, we will be able to testfor common vulnerabilities,like SQL injection, authenticationand authorization flaws, flaws in session management,and password recovery mechanisms.

Burp Suite setup on workstation

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Before we start the testing,let us understand how our lab setup will work.First, let us go over the changesthat we need to do on our work station.We need to download and install Burp Suiteand set up the proxy listener.Then, we are going to downloadan intentionally vulnerable target applicationand start the application server for that application.So let's start the download and install of Burp Suite.For that, you can go to your browserand search for Burp Suite on Google.You'll end up on this page.I'll be going ahead with the Community Edition,but you are free to choose the Professionalor Enterprise Editions of the same tool.The primary requirement for Burp Suite,in terms of platform,is Java version 1.8.Since we already have that,you can go ahead and download the JAR fileor the Windows exe.Once you have downloaded it,all you need you do is start.Go ahead with the temporary project,but if you are doing a full-fledged pen testingand not using Community Edition,you can always create and store a new project.Let's start with defaults.I've just zoomed in a bit so that you guys can see better.On the Burp Suite interface,we go to Proxy and create a proxy listener.Under Options, here,usually when we do web application pen testing,we set this up on the local host IP.But since we are doing a mobile application pen testing,if we set local host IP as the proxy listeneron our mobile device,any packet that exits the mobile devicewill end up back on the device itself.That's just how the loopback IP address works.So we're going to uncheck this,add a new listener to the port, say 5656.You can choose any port that you want,except for any of the standard ports and 8888.You cannot use 8888.I'll tell you the reason in a moment.Here, when it comes to binding the address,you can go for all interfaces or a specific address.Specific address is just my personal preference.There is no compulsion behind doing it.Just click on OK.Now if you are using internet of an organizationwhich already is behind a proxy,you can go to User Optionsand set up your upstream proxy server.That just takes care of setting up Burp Suiteon your system.Now let us download and installan intentionally vulnerable target application.As the target application,I'll be using Android Insecure Bank, version 2.This application runs on a Python 2 server.You can just download,clone this repository onto your directory,and get started.Once you have cloned this directory,you can go to this Andro Lab Server folder.Pull up the command prompt hereand start with installing the requirements.The command for that would bepip install -r requirements.txt .Once the installation is complete,you can start the application serverusing the command python app.py.If you remember, I told you not to use 8888as the binding port for your proxy listener,and this is one of the reasons,because your server for insecure bank also runs on 8888.So if you use the same for your proxy listener,one of the two things won't work.

Burp Suite setup on test device

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Now let us set up our test devicewhich is our emulator to work in synchronization withthe Burp suit proxy listener.For that, the first step that we'll do isconfigure the device proxy.There are multiple ways of configuring the device proxyFirst and the easiest one is to set up thedevice proxy over wifi itself.For this you need to ensure that your mobile deviceand your workstation are on the same network.The second option is to buy third party or VPN applicationsand direct them to transfer all the traffic to theBurp suit proxy listener.The next step that we can do is to root our deviceand install a device level proxy.In terms of set up the next thing that we need to dois install the certificates on the deviceso that we are able to intercept SSL encrypted traffic.So let us start with the first step.We go to our deviceWe go to Settings, go over to the wifi settings.A long press over wifi networkClick on modify networkSelect advanced options and set the proxy from noneto manual.Here you can enter the same proxy host name and porton which your Burp proxy listener is working.In my scenario it is 10.35.3.71The port is 5656Once this is done you can test whether the proxylistener has been configured correctly or not.In order to do that you can go to a browserand open the link http://burpIf this burp configuration page comes up it meansthat the proxy listener has been correctly configuredon your device. If not, then maybe you need tocheck some settings.Once this is done we need to install the CA certificateso that we are able to intercept SSL traffic.For that you can just click herethis will download the CA certificate on your deviceGo to your file managerDownloadsand here you have the CA certificate filedepending on the version of the Android that youare using you may need to rename this fromcacert.der to cacert.cerand save. Now the last step is to install this onyour device you can just click on itit'll prompt up the installation, give any nameand install it both for VPN and applications, and wifi.So, we are just going to use the same name, itreally doesn't matterand install it for wifi as well.Now our mobile device is currently configured totransfer all its traffic onto the Burp suite proxylistener.

Application testing: Brute force

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Now that we have startedour Android labs server, setup our deviceand our workstation to work in synchronizationwith each other, let's start with bank testing.The first thing that we will dois open the command prompt hereand push the APK file onto the emulator.The command is adb install;just type the first few words of the application,press the tab, and press enter.Installation successful.Now we can go ahead and close this.Now all you need to do is open your emulatorand the Burp Suite interface.Just turn the intercept onand open your application.Now the first time you open your application,you need to set the server credentials,which happens to be the IP address of your host device.10.35.3.71, and save.Now the first and the most common vulnerability that we finda web application or in a mobile applicationis brute forcing of the login form.Let us try and attempt a brute forceof this login form.So let me generate a pristine request.Admin, admin.Press on login.And as you can see, the request comes up here.Now we simply send this request to the intruder.Under the intruder, I'm going to use the sniper mode.For this demonstration, I'm going to assumethat I know the user name, which is Jack,and I'm going to add the password fieldas my payload position.Now here you can set the payload as a simple list;for the payload list, you can go to Google,download the password list of 10,000 or 100,000 passwords,paste it here, and start your attack.But, that will be a bit time-consuming,so I've prepared a separate list beforehand.This is the password list that we are going to use.We just copy this, go back to our Burp Suite interface,and paste it here.Now there are a couple of different tricksthat you can use to check which of the passwordshas actually returned a correct response,because for seven requests you can goand manually check each and every response,but say if you have 10,000 or 100,000 requests,it becomes a tedious task.So, one thing you can do, is scroll down hereand add custom filters to ensurethat the payload is processed accordingly.Another thing that you can do,you can head to Optionsand set up pattern matching hereto ensure that, if any of these patternscome up in your response, it gets flagged.So let's say a successful authentication happens.Generally what you come across is welcome,or correct credentials, or credentials right,something like this, so we can set upflags accordingly and any one of those phrases,if it comes up, you'll get a response there.Once we have done that, we just start an attack.Here it gives me an error on how the community editionhas certain limitations with respect to performance.Just click okay, and the attack starts.Talking about the tricks of howto identify the correct passwordout of these responses, one of it isto use the response length.Whichever password has returned the correct responsewill have a different length size.I'm not saying that it will be the longestor the shortest, but it'll be differentand, very often than not, it will be unique.So I can see that there is only one unique entry here.This was the request that was generated.If you go to the response, you will seethat the credentials were correct,so this tells me that the username Jackand the password Jack@123$,happens to be the correct set of credentials.

Application testing: Password change

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Now that we have successfully attempteda brute force attack on this application,let's see what other tests we can run on this applicationusing Burp Suite.So let us begin by logging into this application first.(typing noises)Before pressing login, let's turn the intercept off,and log in.Now, I can see that we have three options here:make a transfer, view account statement,and change the password.Let's see what we can do with the change password request.Here, it is directly prompting me to enterthe new password, which in itselfis a vulnerability because if the account is compromisedor the device is compromised with an active session,the attacker can directly go ahead and change the password.So let's generate a request.Let me change the password to (typing noises)password at 123.Click on change password.And now I can see that the password is here.Let me just send this to Repeater,move one to Repeater.And here I can make any number of changesto this password because A, it is not asking mefor the previous password, B, there are no authenticationor authorization headers.Now it is also possible that if I changedthis username to any other legitimate usernameof this application, I'll be able to change their passwordwithout compromising their credentialsor having access to their device,simply because there is an absence of authenticationor authorization headers within this request.In addition to these, if you want, you can go aheadto the root folder.In case you want to go a bit further,you can go to this Walkthroughs folder,where there are several other vulnerabilitiesthat you can practice and dig deeper on.In case you feel some difficulty,these documents contain step-by-step walkthroughsof each of these vulnerabilities with proper screenshots.In case you have further difficulty,you can always go toSpoilers,andwrite to this gentleman,and seek more clarificationon how to test out these vulnerabilities.

Introduction to Android Debug Bridge

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Let us startwith the third domain of Android application pen testing,that is platform interaction testing.Under this, let's first understand what is a ADBor Android Debug Bridge.Android Debug Bridge is a useful toolto perform platform interactionand it has been used quite extensively by developersand testers to understand the runtime behaviorof any Android application.Basically, it comes as a bundle with platform tools,the utility that we downloaded previously during lab setupand had set the environment variables for that as well.ADB basically enables us to check the application behaviorduring staging environmentto see how it reacts to different types of inputsor stimuli within the Android OSor from internal system calls.In addition to ADB,we will also need to set up a physical deviceor in my case an emulator.The emulator that I'll be using is MEmu.So the steps are very simple and straightforward,you need to download it, install.Once the installation is complete,you need to go to the installation directoryand delete the file adb.exe.Lastly, you need to launch the MEmo emulatorand set the root mode to yes.Now, let me just go aheadand show you the steps quickly.Now the first thing that we want to do is download MEmo play,you can use the online downloador it may take some time,or you can use the offline installer as well.Once the installation is complete,I want you to go to the installation directoryand delete the file adb.exe.You can rename it, delete it,it's entirely up to you.The reason why we are doing this is MEmo quitely comeswith an ADB of its own.But since we have already downloaded that from toolsand set the environment variables for that,let us use thatbecause that will be globally accessiblewhile this ADB will be limitedto this particular installation only.So I've just renamed it rather than deleting it.Now what I want you to do is download a test application.The test application that I'll be using this time is calleddamn insecure and vulnerable application, short diva.The reason why we are using diva is becauseit has some specific vulnerabilitiesthat we can exploitand perform the tests that we intend to doin this particular assessment.So if you quickly scroll down,these are the different challenges available under diva,the ones that will be focusing are insecured loggingand insecure data storage.Again, there are a couple of challengesthat you can follow through.It's a good application for learningby all means go aheadand try all these challenges.But for the purpose of this demowe'll be focusing on the challenge number oneand challenge number three.If you scroll further down,you'll find the direct linkfor downloading the APK file.From here, so what I've done is I've gone aheaddownloaded and extractedand collected all the different testing applicationsthat we have used so far in a single directory.So this is the applicationthat we'll be using this time.Now the last thing that I need to do is launch MEmo.Once the emulator powers up,I want you to go to settings,the settings of the emulator not settings of the Android,here you have couple of different functionsthat you can use and check.You can assign specific RAMor specific memory that you want.Basically an emulator is nothing elsethan a virtual machine running an Android operating system.So it needs to have a RAM,it needs to be assigned CPU,it needs to have specific graphics.So here are the settingsthat you can play around with.The ones that I'm really focused on are present in others,well you can set the root mode to enabled.Now we discussed this earlier also,if you have a physical rooter device,it is always better.If not, we can still work aroundbut do a test cases for be limited.So I'm just going to change this to enabled and save.Now depending on your settings,it might ask you to restart.Go ahead restart itand we'll be all set for the next phase of the lab.

Basic adb commands

Selecting transcript lines in this section will navigate to timestamp in the video

- [Man] Now that we have setup the emulator,the workstation, and collected all the test applicationsonto a single location.Let us begin by understanding a few basic commands ofAndroid Debug Bridge, and get ourselves familiar with those.So we'll just launch a command prompt at this location,and here is my emulator.The first command that we need to run is to check whether myADB is able to communicate with my device or not.Now you can have multiple physical or virtual devices,or you can have a combination of both.In any scenario, the command would be ADB, space, devices.This'll tell you how many devices are currently attached toyour ADB.The next command that we are going to use is ADB,space, install.This command is used to push any APK file which is presenton your workstation, to your emulator.After that you'll just provide the file name with theabsolute part of that APK file, but since I'm running thecommand prompt on the same location where the APK filesare located, I need not provide the location.I can simply write diva, and press enter.It'll get pushed onto your device.Now if you are using a physical device, some specific modelsyou'll need to enable USB debugging.You'll also need to enable installation of APK files fromuntrusted sources for this to work.Once the installation is over, you can verify that theinstallation is done.We have the diva application here, and we are done.The next command that we are going to cover is ADB logcat.Now, log files are basically records of any system event.With an android device also, there are literally thousandsand thousands of events happening right from you accessinga specific folder, some other application accessing yourgallery, your system settings changing,your network coverage changing,your Wi-Fi settings changing, every single activity isrecorded onto the android device log file.Now there are literally thousands and thousands of entriesin a log file, so any system event happening,there is a log entry generated.Logcat is a utility that helps us read thatparticular log entry.Now we have to be smart about it because if you were to runthis command ADB, space, logcat without any switches,you'll have lots and lots of events here.So what we do is, we limit our scope of reading the log fileto specific log entries only.How we can do that?We can define specific switches like, "Hey, logcat just giveme the last 10 entries.", and the command for that would beADB logcat -t.This will just give me the last 10 log entries,within the log file.Or what I could do is specify the last 10 seconds for whichI need the log entry, by using ADB logcat -T,and then specify the time frame.Or what we generally do, is specify the package name of theapplication for which we have to read the log entries.So what we do is, we essentially tell logcat that out of allthe logs that are present in the log file,I'm interested in only one specific application which hasgenerated maybe 10, 20, or 30 odd log entries.The command for that would be ADB logcat,followed by a switch -d or -e,in case you are using an emulator it would be -e,if you are using a physical device it will be -d.So mine will be -e, then you have the android package name.Now package name is the generic name of the application,it's not like freezeball.com, it has to be something like,com.xyz.something.It could be long, but it usually starts with com, dot.So lets say it is com.example.test, and then we specify thesource, that is I, that'll get I'm interested in listeningto the log events of only thisparticular application package,and you can go ahead and silent everything else.So, this switch basically denotes,for all practical purposes, that everything elsewould be silent, only this package will be read.If I were to run this command with an actual package,it'll give me log entries for a specific package only.The last command that we are going to study here is,ADB shell.Now this one is very simple, this command gives me a shell,or a terminal level access, or a command line access to thephysical device or the emulator connected to my ADB console.Now depending on whether your device is rooted,or a normal user device, you'll have a root level access,or you'll have a normal level access.If you remember, in the previous videowe had set the emulator to rooted mode.Now I'll have root level access.

Testing platform: Insecure logging

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Now that we have set upour emulator, ADB, and installed atest application on to our emulator,let's start by solving the challenges.The first challenge in DIVA is ofinsecure logging.As the name itself suggests, it hassomething to do with the way this applicationcreates entries into its log files.If we just explore the functionality,it tells me to enter my credit card number.So let me just go ahead and entera random 16 digit number.Now, in order to view this log entry,what we will be needing is ADB logcat.But since we have to be smart about it,let's just restrict our outputto the last 20 lines, right?Now, I'm just going to go aheadand press checkout here.There is an error.Now by and large, whenever an applicationencounters an error, a log entry is createdand just pushed into the Android log file.Let's see what it is.So, if you go through this log entry,you'll see that DIVA applicationhas created a log, which says,"Error while processing transaction"with the credit card number."Now, this could very well have beenyour social security number,your username, email ID, password,or any other sensitively identifiable information.So, the suggestion here would bethat though it is a best practice to create a logevery time the application encounters an error,sensitive information like credit card numbers,bank account details, personally identifiableinformation, et cetera, should not be logged.

Testing platform: Insecure data storage

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] The next challenge that we'llbe taking up is insecure data storage.Now within this application,this particular challenge correspondsto how this application stores data onto the device.If you look at the functionality,it is asking me to enter username or password.Let me just go ahead and create something simple.Create and save it.Now let us see how this applicationis saving my credentials onto the device.Coming back to the command prompt,what I would need is a way to accessthe file system of the emulator.And the best way to do that is a d b shell,because this gives me a shell access to the emulator.Not only that, since my device is rooted,I'll have a root-level access.Now, as a matter of fact,every application that is installedon your device creates an entry,and stores all their data in this directory.Data and data.So if you go to this directoryand list down all the entitiesof this particular directory,you will find a long list of all the applicationsthat are installed onto this device.Starting from your stock devices,to your custom applications,third-party applications,and intrinsic applications.But the one that I'm very concerned about isthe one that we are testing right now.Let's just open this application.The command would be cd, space,few words of the name,and press tab.Now within this directory,let us see what all files are present.Again I'll create a long list,which will tell me the distinction,which file is a directory,and which file is a normal file.So I can see that there are three directories here.One,two,and three.Cache, as you know, is for the applicationto store cache data.Databases is the directory where applicationis actually supposed to store yoursensitive information, processed information,and any other information that the application is storing.Lastly, we have shared preferences.Shared preferences folder is used to storethat versions of data which is not sensitivebut may be required for frequent processingby the application, particularly personal settingslike your nationality, your age, your gender, etc.So let us look what data is stored here.We go to shared preferences.Again, list down the contents of this directory.There is just one XML file here.Let us see the content of this file.Here, it tells me that the content of this XML fileis my username and my password,which goes to show that this applicationis not following the standard guidelinesof how applications should store and encrypt datawithin an Android file structure.

Introduction to drozerSelecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] In this section, we will coversome additional techniques correspondingto dynamic application testing.For that, we will be using Drozer.Drozer is an open source tool by NWR Labs.Although Drozer can be used for multiple activitiesincluding defensive as well as offensive.We shall be primarily using itfor testing how the target applicationinteracts with other applicationson the same device.Drozer uses client-server modelin terms of its architecture.It exploits the interprocess communicationof the Android OS to exploit the target application.Drozer has two components, the Drozer Consolethat runs on the work station and the Drozer Agent,which is an apk filethat interacts with the target applicationand is installed on the same deviceas out target application.As you might have already guessed this is an example of,Interactive Application Security testing or IAST.Using Drozer, we can test vulnerabilitiespresent in the application components likecontent providers, services, activities andbroadcast receivers.We can additionally conform the vulnerabilitiesthat we have discovered using Morebesethin the components of the application.Before we move on,let us understand how Drozer actually works.

drozer architecture

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Before starting the assessment using Drozer,let us understand how Drozer actually works.In the Drozer architecture, over our work stationwe will have the Drozer Console, which acts as a client.On the emulator, we will have a Drozer Agent APKin addition to our target application.The Agent APK acts as a RAT, or Remote Administrative Tool.Whatever commands that we type will be sentthrough the Drozer Console to the Drozer Agent APK over ADB.Drozer Agent will then run these commandsover the target application usingthe interprocess communication facilitatedby Android operating system.Lastly, whatever the response of that command is,we will be able to see it over our Drozer Consoleor on our emulator.

drozer architecture

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Before starting the assessment using Drozer,let us understand how Drozer actually works.In the Drozer architecture, over our work stationwe will have the Drozer Console, which acts as a client.On the emulator, we will have a Drozer Agent APKin addition to our target application.The Agent APK acts as a RAT, or Remote Administrative Tool.Whatever commands that we type will be sentthrough the Drozer Console to the Drozer Agent APK over ADB.Drozer Agent will then run these commandsover the target application usingthe interprocess communication facilitatedby Android operating system.Lastly, whatever the response of that command is,we will be able to see it over our Drozer Consoleor on our emulator.

drozer setup

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Now that we have understood how Drozer works,let us start setting Drozer up for our system.The first thing that you need to do is downloadand extract the exercise file along with this lecture.Although you can download Drozerfrom the official website of MWR Labs, also,the version that I have provided is much more stable.In addition to that, it has theagent and sieve APKs already present in the archive.The next thing that we'll do isopen up the command prompt and the emulator.There are a couple of steps that we will be doingon the command prompt and some steps on the emulator.So the first step would be to installthe agent and the target application.The next step would be to create a TCP connectionbetween the terminal and the emulator.The command for that would beThis will create a TCP connectionbetween my ADP console, which is on the command prompt,and the emulator or your physical device.Next, we move on to the emulator.Launch the agent APK and start embedded server.Then, we move back to the ADB consoleand use the command "Drozer console connect"to start the Drozer session.If all goes well, you'll receive a Drozer consolesymbolizing that the connection is successful,and now you are ready with your lab set up.So here I have the Drozer exercise file.I've extracted it to this location.Once I open this file, I'll come across something like this.Now I have to pull up the command promptand start my emulator.Now the first thing that we usually dois check whether my emulator and the command promptare talking to each other or not.So the command for that is very simple,we have gone over it a couple of times, now.The connection is successful.Next command is to install the agentand the target application on to the emulator.(keyboard tapping sounds)- First, let's install agent.As you can see, install successful.Next you can install the target application,the application we are going to test.Sieve, as you know, we have used in (mumbles).It's a password manager, it happens to befrom MWR Labs, itself, the makers of Drozer.The next command is to create a TCP tunnel.This specifies the source and the destination ports,both of which happen to be 31415.Pulled forward complete, the next step is on the emulator.We start the agent applicationand start the embedded server.If you click here you'll be able to see the server details.Now the server is start,and it is waiting for some connection.So let's establish a Drozer session, the command for thatis also very simple.If you have set up your environmentand all the dependencies correctly,you'll come across a Drozer console like this.Now a couple of steps here. First, if you areusing a physical device, make surethe connections between your workstationand your physical device are secure,that is the USB cable is not very loose.Because every time your connection breaks,you'll have to start directly from ADB Forward,all those three steps you'll have torepeat again and again every time your console stops,or your emulator crashes, or your cable disconnects.So that way, it is easier to use emulator,than to use a physical device.

Sieve application overview

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Now that we have createda successful drozer session, let us understandhow Sieve actually works before we start the assessment.Sieve is an intentionally vulnerable password manager,that you can use to practice Android pen testing.Let us understand the functionalities and features.When you open Sieve for the very first time,it asks you to create a password.Let me just go ahead and create one.Now it is asking me for a PIN,let me go ahead and create a simple one.Submit.Now, this is the first time that I'll be signing in,so it is asking me for the password again,every one of these screens that I'm encounteringis an activity, so.Now my password manager is set up.I've done the registration, I've entered a password,and a PIN, for anyone to access.Now anyone who happens to have my phoneand starts the Sieve password manager,needs to enter either the PIN or the passwordto gain access to my stored credentials.Let me just go ahead and add some credentials here.Service could be, let's say, shopping,user name could be abcd,email, abc@shopping.com,password again, something small and complex,Saved.Next service could be travel.Wonderful. So now we have added two dummy credentials here,just for the sake of testing.Now if I exit, and again start Sieve,it'll ask me for a PIN.So that's the general walkthrough of how Sieve works,going forward, if you have a understandingof how Sieve works, it'll basically help usin testing the application in a better manner.And in general, also, if you have a understandingof how the application works, it'll help you identifythe crown jewels, or the most critical components,of that particular application,and improve your testing prowess.

Basic commands

Selecting transcript lines in this section will navigate to timestamp in the video

- Now that we have done a successfulwalkthrough of the applicationand established a successful chosen connection.Let us start by gaining some basic informationabout the application.And understand and familiarize ourselveswith some basic commandsof Druzo.But before we begin our activitywe need to know the package name of this application.Sieve.Package name is the official name through whichit is listed on the Applisto.It is kind of the scientific namefor a mobile application.The command to find the applicationpackage nameisapp.package.listis basically modemrun is the commandand together they make this package run.The argument given to this commandwould be the common name of the application letterssievethis will return the package name of this application.Now, if you were to be a bit craftyand run this command without any argumentsit will basically return the list of allpackage names of all the applicationsinstalled on your system.Now that we know the package name.We will be using this package nameas an input to most of our commandsso I might as well keep this copiedand handy.Let us did a bit deeperto find more details like the package detailwhich will give us the permissions used bythis applicationthe user IDthe group IDetc.So the model that we will be usingis app.package.infoand the command would berunspacethe module that is appdot packagedot infohyphen or minus apackage name.this gives us information about the common nameof the application labelSieve.The package nameor the process name thiscom.mwr.example.sievethe directory of this applicationis storing its data.The directory where the application base.apkThe user ID.Group ID.And most importantlythe permissions defined by this application.So it has permissions to readand write on the external storage,access the internet.And it gives other applications the rightto read and write the keys of this application.The last command that we will be usingis to find the potential waysthat this application can be hacked.In other wordswe will try to find its attack surface.So the module name for that isapp.package.attack surfaceand the command would be.RunappdotpackagedotattacksurfaceFollowed by the package name of the application.As you can seeit tells us that there are three activitiesthat are exported.In other wordsthere are three activitieswhich can be accessed externally.There are not any broadcast receivers,there are two content providers.And there are two background serviceswhich are exportedand can be used by other applications.In addition to thatit tells us that this applicationis in de-bug mode.Which means that if I can connect this applicationto a de-bugger.Ill be able to extract much more informationthan originally intended.Keep in mind that these are the attack surfacesthat is potential areas of vulnerabilities.It doesn't mean that these are the sure waysthrough which it can be hacked.

Activity testing

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] In activities testing,we will find, what activitiesthis application is exportingand if those applications can be accessedby bypassing the controls of this application.In general, activities are screensthat a user interacts with.The flow of control between these activitiesis either decided by the user preferenceor by the application needs.Let us see if there are any activities off C,which are vulnerable.The module for finding the activities is, app.activity.infoThis'll tell us all the activities that are presentin this applicationand what are the permissions associated therein.So what we'll do is, we'll quickly run this module.- a followed by the package name.As you can see, there are three activitieswhich are exported by this applicationand there are no permissions requiredto access these activities.Now, granted, main login activity, is the first activitythat the user interacts with,a registered user, interacts with.That is where it prompts the pin or the password.But the other two activities, without permission,should not be ideally accessible.Let us see what these activities are.So what I'm going to do is I'm going to tryand access these activities,without actually accessing the application.So the command for that would be, run app.activityand I'm going to start these activities.Now, I need to define which activitiesand which package I need to access.So first,- -componentso that Drozer knows that I'm trying to accessone specific component off a specific applications package.Followed by the package name,followed by the activity that I'm trying to access.So let us start with, password list.I'll paste it here.So if you see at the emulator,the moment I started this activity, the password listsare directly accessible to me.Which means that the basic login screenthat I used to encounter while starting this applicationis now bypassed.The reason this happens, is that these activitiesare not protected and are exported without any permissions.There are two ways of protecting it.First is to define specific permissions,what permissions are needed,for this activity to be exported.Second, is to use intent filters.Intents are basically, messages through which differentapplication components, that is your activities, services,content providers and broadcast receivers,speak with each other.So if you define proper intent filtersand it has been defined in a foolproof manner,this vulnerability can be avoided.Now let us see the next activity which is exported.That is, file select activity.If you look at the emulator,it gives me access to the file system,where C is storing its' files.Which again, should not be accessible to a normal user.

Content provider testing

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Now that we have covered activities,let's test the content providers of this application.To get the basic information of content providers,we will use app.provider.info.For getting the basic informationabout the content providers,the Drozer module that we will be usingis app.provider.info.The command would be,hyphen a followed by the package name,that is com.mwr.example.sieve.Let me just go ahead and copy thisbecause again we'll be using it again and again.Some oversight, wonderful.So this tells me that we have two content providers here.First is the DBContentProvider,and the second is FileBackupProvider.For the DBContentProviderthere are no read or write permissions needed.In addition to that there are no permissionsto access the URI.URIs are basically the links or the resources indicatorsto specific information within the content providerswithin the database.As it so happens if there are no permissionsdefined for your URIs,any application which is present on your phonecan access these URIs off your target application.Now let us see if using Drozer,or rather the agent APK that we have installed,can we access the URIs for this application.The query for that is very simple.The module that we will be usingwill be scanner.provider.finduris,and the command would be scanner.provider.finduris,hyphen a, followed by the name of the package.So this will find all the URIsassociated with this application.It'll query every single one of them.Some of them will be accessiblesome might not be accessible.Ideally none of them should be accessible, but let's see.So as you can see there were about eight of these,from which three are accessible.Now let us see what are the informationstored within these URIs.My best guess would be the URI corresponding to /Keysis storing the authentication credentialsthat I am using to authenticate into the app,and the URI corresponding to /Passwordsis storing the passwords that I have stored in sievecorresponding to different services, but let's find out.The module that we'll be using to access these URIswould be app.provider.query followed by the URI.So run space app.provider.query,followed by the URI.Make sure there are no additional spaces.My guess was correct,it is the same password I had stored, PrashantPrashant,and the pin that I had stored.Now let us see what is in store with the password URI.As you can see, that by directly accessing these URIsI'm able to see the authentication for sieve,and the passwords stored in sievefor different services,for shopping as well as for travel.So what's the problem here?The problem here is that these URIs,though are externally accessible,they don't have specific permissions.Had they defined specific permissionsother applications, like my agent APK,would not have been able to queryand search for them directly.

Content provider testing: SQL injection

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Another common testfor Android applications is local SQL injection.As you know, that in case of web applications,you'll find SQL injection is a server-side vulnerability,but, in case of Android applications,depending on the application functionality,you can also have a local database,which is the SQLite database.This database typically sits on your Android device.Now, if your application is complex enough,you can have two database instances.One, the SQLite database, which sits on your device,another could be any other version of SQL,or no-SQL database, which sits at the server end.Here, we are going to talk about the local SQL injection,which happens on the SQLite database.To test for SQL injections in the content provider,Drozer has a module,which is scanner.provider.injection.Let's just go ahead and run that.Run scanner.provider.injectionfollowed by the package name,which is com.mwr.example.sieve.Now, this module will automatically scanall the URIs for potential SQL injection vulnerabilities.As you can see, the scanner tells methat there are three content providerswhich are vulnerable to both projectionand selection level of vulnerabilities.Just as a quick refresher,if you see a query like this,Select name comma class From student,which can be a table name,Where age equal to 21,selection is basically the criteriaon which the tuples are selected.So age equal to 21 becomes my selection.Projection are the values that are returnedas a result of this query,so name and class becomes my projection.So moving back.Now that we have understood the basic difference,let us see how projection and selection vulnerabilitiesfor SQL injection work.So the module that we'll be usingto verify the presence of SQL injectionis the same that we used in the previous video,that is, run app.provider.queryfollowed by the name of the URI,that is, let's say, Passwords.Now, in relation to this,I'll also specify whether I want to inject my parameterin the projection or the selection part.Let's try with projection,hyphen hyphen projection,and as goes with any SQL injection video,let's put a single code.Now, this tells me that my single codehas somewhere messed with the intrinsic query,and the error was thrown.So it tells me that, while selecting,this error or this particular statement created this error.To resolve this, let's select,instead of a single code, provide email.Now, remember, projection selects the columnswhich have to be displayed.So if I select email, only the email IDs of the valueswhich match this particular query will be displayed.So we have two emails,abc@shopping.com, abcd@travel.com.Similarly, if I were to check for selection,I can just change here.And now, instead of the name of the column,I'll have to specify one specific identifier.So let's just go aheadand say email equal to and specifyabcd@travel.com,single quote in,and it'll give me all the detailscorresponding to that value,where email ID is equal to abcd@travel.com.So this way, we can verifythe presence of SQL injectionin the application within the content provider.

Content provider testing: SQL injection

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Another common testfor Android applications is local SQL injection.As you know, that in case of web applications,you'll find SQL injection is a server-side vulnerability,but, in case of Android applications,depending on the application functionality,you can also have a local database,which is the SQLite database.This database typically sits on your Android device.Now, if your application is complex enough,you can have two database instances.One, the SQLite database, which sits on your device,another could be any other version of SQL,or no-SQL database, which sits at the server end.Here, we are going to talk about the local SQL injection,which happens on the SQLite database.To test for SQL injections in the content provider,Drozer has a module,which is scanner.provider.injection.Let's just go ahead and run that.Run scanner.provider.injectionfollowed by the package name,which is com.mwr.example.sieve.Now, this module will automatically scanall the URIs for potential SQL injection vulnerabilities.As you can see, the scanner tells methat there are three content providerswhich are vulnerable to both projectionand selection level of vulnerabilities.Just as a quick refresher,if you see a query like this,Select name comma class From student,which can be a table name,Where age equal to 21,selection is basically the criteriaon which the tuples are selected.So age equal to 21 becomes my selection.Projection are the values that are returnedas a result of this query,so name and class becomes my projection.So moving back.Now that we have understood the basic difference,let us see how projection and selection vulnerabilitiesfor SQL injection work.So the module that we'll be usingto verify the presence of SQL injectionis the same that we used in the previous video,that is, run app.provider.queryfollowed by the name of the URI,that is, let's say, Passwords.Now, in relation to this,I'll also specify whether I want to inject my parameterin the projection or the selection part.Let's try with projection,hyphen hyphen projection,and as goes with any SQL injection video,let's put a single code.Now, this tells me that my single codehas somewhere messed with the intrinsic query,and the error was thrown.So it tells me that, while selecting,this error or this particular statement created this error.To resolve this, let's select,instead of a single code, provide email.Now, remember, projection selects the columnswhich have to be displayed.So if I select email, only the email IDs of the valueswhich match this particular query will be displayed.So we have two emails,abc@shopping.com, abcd@travel.com.Similarly, if I were to check for selection,I can just change here.And now, instead of the name of the column,I'll have to specify one specific identifier.So let's just go aheadand say email equal to and specifyabcd@travel.com,single quote in,and it'll give me all the detailscorresponding to that value,where email ID is equal to abcd@travel.com.So this way, we can verifythe presence of SQL injectionin the application within the content provider.

Mobile OWASP Top 10

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] In the final section of this course,we will map all our learning from the previous sectionsto the OWASP Top 10 test cases.But before we begin, let us understand what OWASPand OWASP Top 10 is all about.OWASP stands for Open Web Application Security Project.Although they started as a web application security project,they have now started maintain projectson mobile application security, IoT security,and many other domains.The Top 10 list takes a lot of data analytics,extensive surveys, and a considerable amount of funding,thus, there is no defined frequencyof when the list is to be revised, reviewed, or republished.The previous two versions of this list were publishedin 2011, 2014, respectively.The Top 10 list is based on the frequency of detectionof a particular vulnerability rather than its severity.Several top industry vendors participate in the survey.A detailed methodology of how OWASP gathersthe OWASP Top 10 is published on the OWASP website.OWASP Top 10 is equally applicable for Android, iOS,and mobile applications, but we will be studying themwith respect to Android applications only.The first on the list is Improper Platform Usage.This happens when an application developer deviatesfrom standard security practices of the Android platform.For example, while practicing with ADB over DIVA,we had seen that the application stored usernamesand passwords in the SharedPreferences directory.Ideally, all such credentials should be storedin SQLite databases.For testing these vulnerabilities,we can use Drozer and ADB.The second on this list is Insecure Data Storage.This happens when the application doesn't securelystore data.For example, storing confidential data in directorieswhich are accessible by a normal user.We can, again, test it using Drozer or ADB.Third is Insecure Communication.Insecure communication happens when the communicationbetween the Android applicationand the application server is not secure.Using vGuesses and certificates, poor handshake,incorrect SSL versions, weak CipherSpec negotiation,clear text communication, et cetera,are examples of this vulnerability.For testing them, we can use Burp Suite.Fourth in our list is Insecure Authentication.As the name itself tells us, insecure authentication refersto weak authentication mechanisms,which could be due to authenticationthrough alternate channels, brute forcing,or insecure password recovery mechanisms.For authentication that happens at the server end,Burp Suite can be used, but if the app is locallyauthenticating at the device level,you can use ADB or Drozer, whichever is applicable.The fifth vulnerability in our listis Insufficient Cryptography.This refers to misconfigurations in cryptographic attempts.The difference between the second, third,and fourth vulnerabilities of OWASP Top 10 2016 list is,if cryptography's completely absent,it will fall into M2.That is, Insecure Data Storage.If any errors are related to SSL or TLS,it will fall into M3, Insecure Communication.If and only if the cryptography was appliedbut not sufficient, it will fall under M5,that is, Insufficient Cryptography.For this, we can use Burp Suite or MobSF.Sixth vulnerability is Insecure Authorization.It captures any failure in the authorization mechanism,like failure to distinguish two different sessions,two distinct devices, two different user roles, et cetera.We can test it using Burp Suite.Seventh, and one of the most frequently observedmobile vulnerability, is related to Client Code Quality.It is a general category that covers any problem associatedwith client-side code, like hardcoded usernames, passwords,verbose commands, exposed secret keys, et cetera.MobSF can check for these vulnerabilitieswith relative ease, however, if you want,you can do a manual analysis also.Eighth in our list is vulnerabilities relatedto Code Tampering.Any vulnerability that can be introducedby repackaged applications, binary modification,certificate pinning bypass, et cetera,come under this category.Ninth OWASP Top 10 vulnerability is relatedto Reverse Engineering.It includes analysis of the final core binaryto determine its source code, libraries,algorithms, logic, and other assets.MobSF can reverse engineer most of the APK files,however, you can choose to use tools like IDA Pro,Hopper, otool, and Ghidra.The last entry in our list is of Extraneous Functionality.These functionalities are that which are not meantto be in the production apps.They can be scenarios where developers have returnedusernames or passwords as commentswithin the application during the development stageof the software development lifecycle.Other examples include enablingof app debug mode in the manifest files,disabling two-factor authentications,hardcoding credentials, et cetera.MobSF can be easily used to find such vulnerabilitiesto some extent, however, you can also do a manualsource code review for finding the same.The best way to remove such vulnerabilities isto follow a checklist-based deploymentand development approach during the CI and CD phases.

Next steps

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Congratulations on the successfulcompletion of this course.Now you must be wondering what's next?Learning is a never ending journey,and to help you along the wayI have created a list of specific linksand blogs that you can refer,and take your knowledge to the next level.First is the mobile app Pentest Cheatsheet on GitHub.Not only does it have an excel sheetof numerous test cases that you can referwhile pentesting mobile applications,it also has a list of all the commands,tools, and techniquesthat you can use for advancing your knowledge.Next, is the OWASP mobile security testing guide.It has amazing resources on how to approachmobile app security pentesting,including Android pentesting.They have the mobile security testing guide.Mobile app security requirements and verification standard.And the mobile application security checklist.In case you wish to practice more,this blog has a list of many intentionallyvulnerable Android applications,along with a list of the vulnerabilities present in them.Some of them even have walkthroughsthat can help you in case you face any difficulties.If you're confident about your skills,you can go to bugcrowd.comand participate in the different bug bounty programsthey have on their website.And while you're at it earn sweet bounties.And lastly, if you wish to get in touch with me,just go to my website www.edlabz.com,fill out this form,and I'll get in touch with you.If you want to get in touch with meover LinkedIn or Facebook,you can hit up these links.Thank you, and have an amazing career out there.

https://www.linkedin.com/learning/android-app-penetration-testing/pentesting-android-apps?autoplay=true&resume=false&u=56744289