 So, just to introduce like we are conducting an event called APSECO application security clinic. So, there are like security communities out there with their own conferences and you know lot of beat ups and all these things and there are so many dev dev communities out there with conferences and all, but currently there are like no you know continuous discussion and you know the information and knowledge sharing among among these two places like from a security perspective when you are looking at an application or infrastructure from a security perspective there are certain objectives and as security consultants or you know security researchers we come up with certain solutions. Many of the solutions while are solve the security problem, but may not be practically feasible always when you look at it from a developers perspective right. So, the objective of doing an application security clinic you know is to try to start bridging this gap where we will try to initiate a conversation from both the aspects like from a developers perspective as well as from a you know security consultants or a pen testers perspective someone who is doing security on a daily basis and try to come up with approach solutions tools and tricks tools and techniques which helps us build more secure software come up with solutions which are practically feasible and which are you know which are in line with the various constraints that are there from a developers perspective. So, this is what we are going to do we will start off with a primer talk which will kind of set the context around mobile app tech and after that we will move on to the banquet hall where we will have a Q and A session followed by an open discussion talking about you know various security challenges that you may be facing you can also discuss how what kind of security vulnerabilities we find in mobile apps or web apps in general. Just to give you an overview introduce myself my name is Abhishek Dutta I am the head of technology at a company called AppSecco. So, we are an information security consulting company it is a startup actually and we believe we offer pragmatic and practically useful security advice to our clients as well as our friends who reach out to us. So, as I said why this app application security clinic we want to set the stage for a Q and A and open discussion around particularly on mobile app tech but as we all know that you know web is also an important aspect of the overall mobile infrastructure we will also talk about web application security also in general. Objective is you know seeking clear and pragmatic answers for various security challenges that you may face while you know designing or developing or maintaining an application real life or real world security challenges or what can be a pragmatic solution for these challenges and this is how we have kind of structured the overall event like we will start off with this talk then we will move down to the banquet hall where we are open for a Q and A session as well as we will have an open discussion. The purpose of this open discussion you know is to hear from both the sides like and try to come up with practically feasible practically feasible security solutions to various problems that you need to face. Okay to start off with the talk or it is fine I think you get the idea. The most common question that we face always almost always is how do we secure stuff. I guess if anyone like whenever you are asked about security this is the first thing that you think of how do we secure stuff. Now there are various practices or common ways of doing it like you know that you have to keep your frameworks, libraries, software components up to date patch again known vulnerabilities. There are secure programming guidelines, secure practices that you follow in order to avoid common vulnerabilities, common flaws to write more secure stuff but over the time we have seen that an application or infrastructure no matter how much security practices you follow may have flaws. This is a continuous thing. It is not that you can totally make something secure. So by that understanding we think that an appropriate answer for how to secure something is by creating trust. This idea of trust is something which will allow you to do or identify what is necessary to create secure software or secure applications or secure application infrastructure. Now what do we mean by trust? As devs no matter what you are doing whenever you are building an application or whatever your software component library or framework whatever you are building you are not building everything from scratch. You are using an ID, you are using a compiler, you are using languages like C++ or Java or something like that. So you are implicitly trusting various components. You are trusting a platform where your application will run. You are trusting a run time that enables your application to run. You are trusting frameworks, libraries that you are using for your application. So at any given point in time you are trusting a bunch of things. Those of you who follow secure programming guidelines or who are conscious about security maybe you will spend more time reading the library or framework documentation on how to correctly and securely use a particular library. Now all these things together is responsible for creating security in an application or in its infrastructure. As long as this trust is reserved you can say that the application is secure. If the trust is somehow broken in your code or any of its dependent environment or infrastructure be it the platform or the libraries then we say that there is a security issue. Just to give you an example like when you write code which is saved in Java or C++ or even the php or any interpreted language you are expecting the run time or the infrastructure to behave in a certain way. However because of some flaw I mean that run time infrastructure is also a software written by someone just like your code can have bugs that particular component can also have bugs. If because of some flaw it is possible if it is possible to make that component or infrastructure do something which is which it was not meant to do which results in an unintended side effect and that unintended side effect results in loss of say either confidentiality or integrity or availability of your application infrastructure then we usually say that there is a security issue in that. Now if you have to think about trust fundamentally just think from this perspective how applications or software components have been secured over time. Trust is created to controls or mitigations. What is a control? Just from a fundamental point of view the Linux kernel has been implementing say file system permissions like ever always forever. This simple control allows you to use this particular feature for a whole lot of security use cases. From the earliest days where you have to have you are using a Linux server with multiple user your basic use case was ensuring that one user's data is protected from another user's activity one user should not be able to tamper with another user's data. So this fundamental control allowed you to fulfill a lot of different security use cases. However think of this as a control that creates trust. However over time it was found that because of software flaws while this control is there establishing trust there can be times or cases when because of some flaw there can be bypasses. People might be able to break this trust you know bypass the permissions or the security model that has been implemented. If it makes sense if that particular component is really important to you you want to increase trust you want to even assume that this particular component may have flaws even if it is matured it does not it is known to be secured today you think of it that it may have flaws that is when you think of something called mitigation. Mitigations are you know approaches where you reduce a potential they reduce the impact of a potential risk. So if you look at in this exact Linux example what is the potential risk if the file system permission model is broken one user may be able to access other user's file tamper with it read with it all these things. The earliest Linux developers or actually these ideas comes from the traditional unique space system itself they realize that only the permission is not enough they have to build some mitigations as well they came up with CH route jails of privilege separation and a bunch of things in the earliest days of Linux or unique space system. Over time this has matured significantly this ASLR which stands for address space layout randomization NX NX is now the few feature for almost a decade hardened tool chain these are all mitigations right someone who designed the security of the system assumed or accepted the fact that there will always be software flaws not just software flaws there can be hardware flaws itself. But how can we increase the trust in our system irrespective of a future potential flaw you do that by building these mitigations as an example this ASLR NX hardened tool chain these are mitigation against memory corruption based exploits memory based exploits. One of the most common flaws in native software are worker overflows integer overflows format swing vulnerabilities there are a bunch of flaws like that. So these are mitigations against exploitation of those flaws. Now if I have these mitigations in my system and I have a bunch of software component third party software component which I do not know is secure or not but because of this mitigation my trust is increased I know that even if there is a flaw exploitation of that flaw will be prevented like someone will probably if someone tries to exploit or take advantage of that flaw to compromise my system I have defenses in place that prevents that. So this increases the trust and overall security of a system so this is how this is like the fundamental approach towards building more secure system you try to identify the components or I mean you are talking about things like create models you create models you understand what is important to you in your solution and accordingly you build controls and mitigation in order to increase the trust and fundamentally build a more secure system. Now over time the same this thing has been in the security features of linux has evolved significantly into android sandbox this and that like you know that android and own sandbox to prevent one application from trying to tamper with another application similarly the some of these new scandals feature are also there in android these are like the evolution of trust now modern mobile operating systems knows that there can be flaws there can be flaws in third party applications to make the platform more secure they have come up with sandboxing which allows them contain the flaws of a particular app within itself so that the platform as a whole becomes more secure. So can you trust the platform obviously you have to trust the platform because that is where your apps and everything is going to run but if you look at past example there have been a lot of flaws in the platform itself like this is an example of a security vulnerability in android's web view component where it was possible to use you know the web view component provided a feature where you can transparently build java and javascript bridges you can expose your java objects for invocation from javascript if you like load a html and javascript in a web view with a javascript error so the vulnerability was that it was possible for a malicious javascript to use javas reflection api to do more than what you intended like if you would have exposed one of your class which has which had a simple method of doing something say logging some information or storing some information in a local storage but however irrespective of that because of some law in the implementation of web view it was possible to use javas reflection api to get a reference to the runtime object and execute system commands. This was exploited extensively in the web by the android web browser was also exploited using this particular vulnerability. So this is an example where you know even the platform trust can be broken as well but because of android unboxing mechanism the impact or the damage that a potential attacker can do is limited to that particular app. So this particular issue was fixed in android api level 17 onwards so this is not there they have made it more secure that we have to explicitly mention which methods are exposed by default the method will not be available to the javascript interface. So there is another interesting example of vulnerabilities that happens in mobile apps or web applications due to lack of enforcement of trust. So facebook had this password reset vulnerability where the main facebook website implemented the password reset flow in a pretty secure way like when you go for password reset it will give you a code you cannot brute force that code the main www.facebook.com implemented appropriate anti automation mechanism to prevent brute forcing of that code but it was found the exact same feature in mbasic.beta.facebook.com which is not a staging environment the production application at the exact same feature but the anti automation was not implemented. So someone managed to figure out a way to brute force a six digit six digit is not much you can easily brute force. So someone figured out a way to you know reset anyone facebook account just by brute forcing this. So how does how how does this particular issue come from it comes that main site had created mitigations against a particular attack which was missed in this particular the mobile site because of that this particular issue happened. So the impact was an attacker could reset password of any facebook account identified by email address mobile number just by brute forcing a six digit number. The vulnerability is although excuse me if you are like chatting can you please like so what does an attacker do? So when we have to when we think from an attacker's perspective fundamentally while we look for security vulnerabilities in the app so what do we do? Fundamentally we try to break the trust. We go through the various parts of an application and its infrastructure. We try to see the places where business logic or important components that various controls are implemented and we try to work around that. We see whether the trust created by the application is enough or if there is a way to break it. A simple example of control is you want some parts of your application to be accessible only to a registered user. So you implement authentication. As a contestor when we look at it from a security testing perspective we challenge this trust like we try to find out a way whether it is possible to bypass this control whether it is possible to access those parts of an application without authentication whether it is possible to spoof the authentication without actually having credentials a bunch of things are there. So fundamentally what an attacker what attackers do they challenge or try to break the trust that you have created in your application. It is not that the attackers will always do for very complex ways of doing it in practice in practice most of the time you know very simple vulnerabilities are found. Real life attackers mostly focus on low hanging fruits. It might happen that someone on the internet some malicious attacker is looking for some particular flaws like weak password is the most common thing. You expose your SSH server on the internet within a few hours you will probably see failed SSH login. This is the most common thing if you just you just you know expose your SSH server on the default port within a few hours you will start seeing that someone is trying to login to your SSH server with default credential default or come here weak passwords. So many a times it might happen actually it happens many a time is that your app or application infrastructure may be compromised as a side effect of someone trying to find out random targets on the internet. Some malicious attacker wants to compromise some server they do not they do not specifically know you or they are not specifically targeting them but they just want some access. So they will just look for easy to exploit or commonly occurring vulnerabilities and scan the internet or some range if your app or app infrastructure is vulnerable to any of this low hanging fruit or easy to exploit vulnerabilities you will get exploited. Most of the time most of the time it is very simple things like public exploit open system this and that which are found rarely there are times when a motivated attacker may look for new vulnerabilities in your application that is when it is called zero day. A zero day is like a vulnerability which is known it is not known to the public which is known only to the attacker or his group. So as an example of the kind of flaws we find in mobile apps any idea what is this this is the decompiled version of a mobile app sorry yeah. So this is just a decompiled version of a android app which is publicly available in the play store. We have removed the URLs and some of the names here. So what this particular app does you will see that there is a API token also in token some hard coded API token also. So this app actually is using a service web service for doing some identity verification. This is a restricted operation this is not supposed to be open to the public this is doing some kind of identity verification the organization who owns the app they have the privilege to do that they wanted their app to be some have this functionality of identity verification for that they created a web service which in the back end actually does the verification. They created some token it is good that they wanted to have some basic authentication they see the identity check so that no one can call the web service on the internet directly. But they assumed that if some token or some credential some identity information is hard coded in the app no one will be able to figure out. But just by looking into the decompiled source code even though it is not perfect these variable namings and all these things are not perfect it was possible to reuse this restricted functionality like just understand the SOAP packet which the app is creating the endpoint where it is sending the web service request and the token which was there which is required to authenticate with the back end service. So what happened here? This is a very common flaw in mobile app. Many a time when you develop mobile apps you assume that whatever is there inside your app is cannot be seen no one can see if you hard code some password if you hard code some token if you hard code private keys this is not common this is not uncommon we have seen cases where people have hard coded private keys in the app. So the trust or assumption is that no one will look inside a compiled app. Although in this example this is APK this is definitely possible for other mobile platforms as well for iOS app or Windows mobile app just that the complexity may be different but definitely possible in this case what happened is that it was possible to violate this trust that if an app is doing a privileged operation no one will be able to figure out how it is doing what was the impact some privileged operation which is supposed to be restricted to the organization because of their insecure app and insecure web service it was possible for anyone to do that particular privileged operation. Protip security by ob-security is usually a bad idea like one of the common things like if you believe that you want to store you want to protect the web directory you give a random name to that particular directory and expect that it will not be discovered while practically it may work but there are ways for an attacker to enumerate those or even if you visit you know your browser may also mirror those things so usually security by ob-security is not a good idea you should not assume that if you hide something it will stay hidden there are ways to discover that right sometimes however it is not so easy like so far we have only shown very easy cases where anyone can take an app to compile it look inside it and you know find security flaws sometimes it not so easy there is there is some time back there has been a vulnerability in Broadcom's Wi-Fi chipset almost all devices most of the high-end android devices like samsung even Motorola devices also i think iphone and all these devices they use this Broadcom's Wi-Fi chipset so there is a vulnerability in the in the firmware of this chipset which allows remote compromise of android and iOS devices it was demonstrated that someone in the same in your vicinity who can respond to Wi-Fi probes from your device will be able to compromise your phone compromise means in this case not a sandboxed access like in previous that web view example if someone exploited that web view vulnerability they will get a restricted access to your phone which is whatever privilege that particular vulnerable application that is using the web view has like in this in the public case it's a browser but in this case someone will get full access to your phone this is a very complex vulnerability you can read about it it's publicly known all the technical details is public but one of the interesting aspects of this vulnerability is that the attackers specifically focus on the Broadcom Wi-Fi chipset there are many other attack surfaces like SMS or MMS or image parsing image is a complex operation there can be flaws in image parsing there are so many attack surface to the core android or iOS or Windows mobile system why do you think the attackers targeted Broadcom's Wi-Fi chipset specifically the reason being if you remember that slide previous slide from Linux mitigation most of the modern operating systems like android or even windows linux android iOS they implement a bunch of exploit mitigation if someone finds the flaw in the way say iOS parses SMS messages or MMS or some image it's not uncommon for someone to find such a flaw but exploiting that that taking advantage of that to get access to the phone is extremely difficult because of multiple layers of security mitigation implemented by the platform itself implemented by iOS and android case the linux kernel itself linux kernel and the runtime so but these attackers they kind of did a threat model the evaluated what are the weak links in the system they figured out that in a phone in a say iron phone there are not just one processor there are multiple co-processors there there is a baseband chip which has its own processor which is responsible for your gsm network or CDMA network and all this thing and there is a Wi-Fi chip set which has its own processor and their preliminary research reveals that all the security mitigation all the hardening all the exploit mitigations is available only for the primary processor the Wi-Fi chip set processor or the code which is executed on that Wi-Fi chip set is totally totally unrestricted there is no security mitigation protecting the firmware in the dot com chip set so this is like this is the that is why the attackers targeted this specifically this is like attacking the component which has minimum trust the core iOS system its libraries apps they run on a more trusted environment more secure environment even if you find flaw exploiting that is very difficult okay that is why this is one of the after this is exactly how real-life attackers will work they will try to find out the component they will not attack your authentication directly they will not attack the your you know the main activity of your mobile app or your applications main page or the pages which are easily navigator they will try to figure out the part that component which has minimum trust minimum mitigation and they will try to attack that so this particular vulnerability was so cool that it has a very nice name it is called broadpond okay and the researchers who found this they demonstrated the Wi-Fi warm also like they can write a program that self replicate across vulnerable devices this can be patched if you upgrade your OS it will upgrade the firmware in that particular chip set and it will be patched if you have updated the OS I think June or June I think then it should be patched now mobile app attackers are similar like when you have to talk about mobile app specifically mobile app security like what all tools and techniques does a potential attacker uses you know the most useful and important tool when you look at it from an attacker's perspective is an interception property okay as an attacker we love to look into how your application is communicating with the external world how is it communicating with the backend services how what kind of data is it sending what kind of data is it receiving is the link secure like is there SSL verification and those kind of things are there this gives a tremendous insight like when we are looking into an app which communicates with the backend with over HTTP this this although even though the app but may not transfer anything confidential these kind of gives an attacker a feel that this particular app may not be developed by people who are really security conscious although it doesn't mean that if you use HTTP that you know you're not security conscious you might have taken a conscious decision that your app does not transfer anything confidential and you don't need it but from an attacker's perspective these kind of small things is an idea then looking at things like if additional response are coming what kind of the back discovering the backend infrastructure many other many of the times the mobile app is basically a client it doesn't really have much business logic most of the times the business logic lies on the backend infrastructure so our objective is to you know figure out those things so the proxy the interception proxy is immensely helpful what attackers do usually they will run the app in a in a emulator or in a real device physical device and they will try to intercept all the communication which is going on the backend server so as developers you should know that someone will do that so you cannot really trust or assume that the network communication no one can see what is going on okay so as I said like the ability to intercept the communication between app and its backend infrastructure it's tremendous inside from an attacker's perspective it's like the ability to see what's up what the app is doing and how is it doing okay like whether it is sending some like like for example in most apps which has registration login this and that forward passwords like forward password is a favorite use case or for attackers like the way they are implemented how how does it work like how does the registration work does it send some device identifier does it tie the registered account with the device how does the authentication work does it uses you know gwt or does it uses simple api keys or does it uses what those what kind of things like that and accordingly you know discover what kind of functionality can be attacked there is no point like when a real life end test is going on it is not possible to attack everything an attacker also or a security researcher also have to prioritize his stuff okay now when you look at it from a app security specifically it is actually very easy to do basic static analysis on mobile apps especially android apps because of the ability to decompile it into approximate java code i won't say the exact java code from where it was compiled because of various kind of source code obfuscation tools and technique that approximate if it's possible to obtain approximate code says udocode or whatever it gives the ability to you know figure out what the app is doing the most common thing that people look for attackers look for is hard coded credentials as i gave you an example previously as well hard coded credentials with username password api keys token private keys this and that is very common and another very interesting thing which an attacker will look at in apps or api of the url if the app is dependent on a back end web service or its business logic how well the back end web service enforces authentication authorization we have seen so many times that people will quickly develop some web service to publish their apps like we have seen a large consumer services company in india who had a fairly matured portal for delivering their services for doing some kind of service management but it's a monolith it does not have any apis or anything now probably this company was wanted to come up with an app very quickly so they created a bunch of apis for doing similar operations which are possible in their website and that app would use those apis to do various kind of service management it was found during security testing those apis does not implement any kind of authentication and authorization the app the mobile app was calling it get get information from the back end services like user user records and not even payment information which was going on so it was evident that the back end web service was developed just to support that particular app and the assumption there was no security implemented as such the assumption was that this particular apis will not be made public and only the app will use it this is a wrong assumption the trust was broken here as it is very easily possible to perform some simple static analysis to figure out what all activities that app can then request and response data model like what kind of information is going to the back end and what kind of information is coming from the back end this also has a lot of security security concerns like is any sensitive information is being returned by the back end service if this password is stored in plain takes or if payment information is stored in plain takes this kind of things are something which an attacker will immediately look at from a static analysis perspective when he is like doing some kind of analysis on an app then decompile source code the most obvious thing like if hard-ported this and that is not found then an attacker will look into the decompiled source code of the app on you know figure out how it works and what can be a potential area for attacking that particular app in android for android apps this is actually very easy to decompile an app a bunch of publicly available free tools are there using which you can take an apk and get a java source code from it as I said that the decompiled source code will not be exact it will be approximate and many a times it may be only pseudocode or representation because of android as this pro guard and other source code protection system obtaining the exact thing may not be possible always but you can very easily decompile into an approximate code which can which you can read actually it is much better than reading assembly or low level netting platform specific netting code okay there is also a very nice tool called mobile mobile security framework you can available you can get this in a docker container you can serve just submit an app it will do a bunch of static analysis and give you the result like instead of running those commands manually mob is as automated this thing this works both for android as well as ios you can submit android and ios app and you know figure out what kind of vulnerabilities are there from a static analysis perfect you should try it out like if you have concerns about your app you can like start by using more passive to figure out like what all information is visible in your app from a static analysis perspective okay one more thing about more passive is that this is an example of only static analysis but more passive can also do dynamic analysis as well like you set it up properly if you set it up with an emulator then it can run the app and look into the runtime behavior of the app like if the app communicates with some external service it will record that network communication and provide it will allow you to interact with the app also okay so before we like talk about mitigations or like the way forward how to secure stuff one of the things that i wanted to talk about is that this is probably the most common infrastructure when you look at it a mobile application and an infrastructure as a whole you have your mobile apps which most of the time are basically very light apps not proof or games and all these things but for most of the time like shopping cart shopping apps and social media apps most of the time these are very light apps which entirely depends on backend infrastructure if you are a mobile if you are thinking for mobile app security only from the perspective of app securing your app it's not enough actually when an attacker looks at something like this he will try to identify something called attack services like what are the components that can be attacked it's not that as i said previously attacker will always attack what is immediately visible an attacker can be smart enough not to do that because there is a simple assumption that most of most of the features which are actively used or actively seen by the user they may be well tested or maybe security controls lot of security controls the mitigation has been instrumented there but what about the other invisible part of the overall infrastructure there are various components which are not immediately visible so and potential attacker would usually prefer enumerating the various components in not just the app but it's backend infrastructure as well and then look for what are the weaknesses in any of this component the objective is not to compromise the app only itself the objective is to see as and when as the infrastructure grows as and when you add more software components more components in the system the attack surface increases because that gives an attacker the more ways of trying to find flaws or break into a system so the attack surface analysis is something that as devs or you know the software architects you should do if you have to start thinking in terms of securing your infrastructure you should first do a kind of an attack surface analysis like what all things are there which are exposed directly or indirectly and may face a potential attack so as I discussed previously also like an attacker will have to target this kind of infrastructure they will first start off with the app probably look for common insecurities vulnerabilities in app and discover the apis or backend infrastructure URLs the request response which are sent to the backend and then it will definitely target the backend infrastructure the common web vulnerabilities which are applicable for normal web applications or web services those are also definitely at play here so the overall infrastructure security comes not just from the app but all the various components involved to service or deliver the app so how to secure every component which is as I said every component that is involved in the operation or delivery of a particular service is a potential target for an attacker it has an attack surface and by implementing the control security control ways of verifying whether particular request is valid or involved in valid by implementing security controls and mitigations on important components of your system is how you secure the overall infrastructure I am really sorry to have to cut this short just last okay okay so where do you go from here we will take this to the q and a and then open discussion as a continuation of this but top but however this is something that you should look at for application security one of the great resort is the OAuth project it is a non-profit organization which has multiple projects related to application security you should definitely start with OAuth A is VS project the application security verification standard it will give you a bunch of control security control using which you can evaluate whether you have built or considered those security control as a part of your app or overall app infrastructure apart from that you can look at WASP top 10 which talks about most commonly occurring web vulnerabilities and mobile top 10 which talks about commonly occurring mobile app vulnerabilities and if you have to secure stuff or you know evaluate what all potential components can be attacked think of from an attack surface analytics perspective and challenge the assumption that creates trust in your system okay thank you so we will move on to the banquet all below as a continuation of this session we would like love to hear from you like what all security challenges that you face if you have ever seen a security if someone has reported a vulnerability to you in your app or your application how you have responded or like what kind of security what kind of constraints you face while implementing security control thank you