 Good morning. This is Subbu. I am going to present the Android security use. You can see the world view of the presentation. First I will just introduce the framework. Then what are the security mechanisms involved in Android? Then introduction to web security and some of the attacks which are existing in Android. Most of the handled devices are based upon Android. So what happens is that most of the internet users are growing. They are accessing the internet with the help of mobiles and tablets. Studying the important data on these devices. So the security became major issues in these devices because there are low computing power and there are low resources like power etc. So as you know that many of you have discussed the Android framework. So it contains many lights like Android, kernel stack which contains the native mobile etc. There are runtime, native libraries, application framework, Android application layer. Then coming to security issues, what are the main issues in security? The security system should provide the following three requirements. Protect the system resources and the application solution. So to handle these issues, Android provides many features. Just like we came with a robust OS like with help of Linux kernel. It has done this sandboxing of applications. So the enterprise communication between the applications is very secure. And it requires the application signing to be installed. And the permissions which are required by the applications has to be explicitly specified. While doing the Android security mechanism. So Android is a multiprocessor system. What happens is whenever the application is installed it is given with 1.06 user ID. So as you know that if there are two users, one user cannot access the other user resources. So what happens is two applications cannot run on the same process. So it creates a sandbox. So it also has a provision to use one process resources. That is one application resources but the other application by using shared user ID feature. So this will also act as vulnerability file system. So Android just implement the Linux file system. So each file will have three tuples. One is for user group and others. So it will have read, write and ex-good permissions. So the files which are owned by an application. Whatever files it creates it is owned by the application itself. So the files created by one application cannot be used by other application. Unless there are explicitly specified. So one more thing is the system image is mounted as read mode. So if there is a malicious application which anyhow gives the chance to access the files. Even it can just access but it cannot change the critical files. Because the system drive is mounted in read mode. So we can even design attacks such that we can remount the system in read, write mode. And we can change the critical files. So the Android has many partitions like data partition, system partition, SD card. So whatever application we install and whatever files the application may create. It entirely goes into data partitions. So there may be some attacks like there is malicious application which creates many number of files. And so it creates lot of files such that the memory go. So in that case the Android has one facility like it can if you boot in safe mode. But data partition is not loaded into RAM. So while there you can check it and we can uninstall this such type of application. Now memory management is hardware component which facilitates the separation of process of different outer spaces. So that means if there is an application, if there is one process cannot access the outer spaces of other process. So there are many security issues like so if the stack is executable then we can attack, we can do somehow bower overflow attack. To avoid that it has made the stack and heap as non executable. So to check whether there is a bower flow attack or not we can use profile. We will just keep a known value at some outer space of the stack. As soon as the application is executed we will check whether that value is changed or not. If it is changed then we can conclude that it is a stack over that is a buffer overflow. Again the attas is allocated randomly then going to type safety. So you know many programming let us follow type safety like just like C and not C just like Java. So what happens is it should specifically say what data type it has to be. So if it is an integer we cannot store other values like string everything in the integer data type. So with the help of this we can have boundary checking. So this outer space belongs to variable A we should not go beyond this. If this goes then we can say our segmentation for such type of errors. So since Android follows Java so it is somewhat safe. Even Android allows the applications to have C components like native language components. So if you remain in this native components that is up to the application or up to the user to install it. Because there is a buffer overflow in this Android follows permission based model. That is there is a package manager which checks when the application is going to install it checks whether it has what are permissions it want and its grants it. The application firmware what it does is it sees whether the application is using the same permissions or not. If it wants some other permissions it is not granted at the run time. So there are some built in permissions like call phone, camera, GPS etc. All the applications the application all the permissions the application it should be specified in manifest.xml. Android classifies the permissions into four categories like normal which is not more risky, dangerous which is more risky and signature which is rarely used where two applications are came from the same vendor and they want to share the permissions. As you know that applications while installing should request the Android and Android will ask the user whether to grant or not. If it is granted then the application will take only the permissions. It is not allowed to take any extra permissions. Once it is granted it cannot be revoked until it is uninstalled. The application should be signed. Why this is signed? Because in manifest.xml the application may say I required only four permissions. That is very trivial applications like just accessing camera everything. Whereas the application may say that I need some more permissions. In that case we can check whether what it claimed is correct or not just by digital signatures. There will be a certificate in which there is a public key and the application files are just signed by the private key. Since we have public key we can check the signature while going to injection attacks. There are many types of injections like voice injection whereas SQL injections where we will embed our code into the SQL queries and price to execute malicious code. Then there is a crosscut scripting where the malicious code is executed on the client web browser. We will go into crosscut script somewhat giving kernel to execute some files. So just like buffer overflow attack is a voice scripting. So my malicious code will be stored at some memory and the written address of this stack and the function call. I will change the written address to the code which I have kept in the memory. So crosscut scripting there are three types of crosscut scripting. One is persistence and another is non-persistent which is also called as reflected. Another is down based whereas in persistent there is a web page that is like a server where there is a vulnerability. So we will write some malicious code. The script will be stored in the server itself just like forums. If there is a forum and there is no sanitizing of the inputs. So I can write some script in the forum. So in that forum the data will be stored there itself. So that is persistent. Whenever the user sees that forum so that malicious code will also be downloaded and will be executed in the browser. Whereas in reflected so the malicious code is not stored in the server and just like a reflect. Just like if you search in somewhere like it will reflect you are showing the results of so and so. If that is not sanitized so then we are reflected across the scripting. Another thing is down based. Just a new type of scripting crosscut scripting where so the script runs at the client side itself and the malicious script is kept in the client side itself. The precautions for crosscut scripting can be done at many stages like it can be done at server side, it can be done at client side, it can be done at both sides. So welcoming to Android in the web browser which is supporting they have to do some precautions. Otherwise it is vulnerable to crosscut scripting. The main efforts of crosscut scripting is loss of data. So the browser has some stored password. Everything can be sent to the attacker. Just like send the cookies, everything. Denial of service. The web browser exposes the Android users to common attacks like crosscut scripting. So in the recent attacks they show that there are bound for low attack and crosscut scripting. But that is outdated the change in the library. Since the browser has its own user ID and it has some permissions. So even though it is an attack it is only confined to browser. It cannot access some other files, some other application files. So at most you can get the passwords, form fields and created code numbers etc. Which is also very dangerous. Then it is even common for every browser. No, no, no. Even for Google Chrome it has some mechanisms to work with crosscut scripting. Even like Mozilla. Every browser has to do something, some mechanisms. No, it is a trade-off between security. It cannot be followed by the standards completely. Because for example if there is a two-hour crosscut scripting, one good thing we can do is what is crosscut scripting? We will send, so we will send a malicious link to the victim. So the victim when clicks it, it goes to the server and comes back to the victim. So the malicious code is sent in the form of parameters. So instead of sending the user name, search query, one thing is so Android browser does not download the files which is not supported by Android. Just like zip files and drag files. So how we know that whether the file it is going to download is supported or not. Because with the help of MIME type, you know in HTTP response there will be a parameter MIME which tells the worst type of file it is. If it is a zip file then it does not download. But we can even bypass it. Just after all that MIME type is set by a server right. So the server may set is a false MIME type and Android browser downloads it. Then going to SQL injection. So in the SQL injection you know, so there will be a friend form and there will be a background, in the background there will be a SQL query. So if I want to search, you have to get the data from database. That cell star from users where name is equal to user name. That user name will be supplied by the user. So it will be given in the form. So instead of giving the legitimate genuine name, I may give some SQL query. Just like delete table. I will just close it here by using a quota and then I can give delete table users. If that was the case then it can execute it and it can delete the users table. So this is the introduction to SQL injection. The primary cause for SQL injection is without sanitizing the input, without sanitizing the parameters it just adds into the query string. So that is manual embedding. Android supports both manual embedding and automatic embedding. In manual embedding it just takes the input and just place it here. Whereas in automatic embedding it is just like place holders. It just checks for any some meta characters like quota and vanishes and removes that one and just place it. If your application is developing based on automatic embedding then there is no chance of going for SQL injection. Whereas it is going for manual embedding there is vulnerable for SQL injection. So then going to resources. The main computing environment, the main resources are CPU, storage, RAM and IO. So we are going to CPU and it follows the line is completely fair sharing schedule. That is it tries to give equal share to all processors. So in some case there will be some process which required more CPU. Even that is supported but it does not go for monopolizing the CPU. Whereas going to storage, Linux supports the storage quota. That means this application can use at this time only this amount of space. Whereas in Android it is not there. So there may be some malicious application which creates a lot of files and this takes the entire memory. So this can be done by just by malicious application. And one provision given in Android is we can see the files application size. How much of size this application takes. So just by saying that we can see that this application is taking so much. So let me uninstall this. But even that can be bypassed. So the application even can store files in this private, it is not in private folder. We can store it in other folders. If that was the case the Android does not show that files in the memory occupied by that application. Usually the private folder of the application it will have some folder. Usually the applications will create for itself. So one that what does is if there is a private folder of application A then whatever the space occupied by that folder it will be given as the size of the application. Even the application can create files out of this private folder. If that was the case the files that created outside the private folder is not added to the size of the application. Another thing is in Linux when there is RAM is very less and that is more number of application processors are coming then it kills some processors. So even in Android this is implemented very very aggressively just like a raw memory killer. What happens is if there are 10 of processors in RAM and RAM is going out of memory then it kills the least recently used application. So what happens is if the last least recently application may be used only some memory. Still I kill that one. Whereas the most recently used is take more memory. I am not killing that. By killing the big application I may accommodate more number of processors. So that has to be changed in Android. That is the problem. I am blindly deleting the process of which is least recently used so which takes only 5MB. Let me say that 5MB. Yeah, LRO policy. There are these least recently used. It may take 100MB. If I delete that process, if I kill that processors then I may accommodate more number of processors. Whereas killing the least recently which takes low memory then it may be a problem. Coming to some basic attacks, there is zero application attack. Zero permission application. So what is zero of permissions? That means the application do not have any permissions. It is not specified any permissions in Manifest or XML. The package manager in the Android does not give any permissions to it. Still it can do some things in Android. So the things which it can do is it can read the SD card. So any sense written on the SD card can be read by this application. Another thing it can do is it can list all the applications which are already installed on this Android. It can get the what this SIM vendor and GSM ID and Android ID and kernel version. So one thing is if you got this data, what it can do? After all it is a zero permission application. You just get a data, wait to send. You do not have any internet connection. You do not have anything to send with no permissions. Literally there will not be any permission. No, that is the Android flaw. They can read files on the SD card. They can list all the applications which is present in it. So what can we do with this data? Yes we can do it. Because with ActionView intent in the browser we can open the browser. Without any permissions we can open the browser by just calling that ActionView. Once I open the browser I can send in the get parameters into the attacker website. So then what is the Google response on it? When they asked what about the why we are able to read files on the SD card. Then they said that it was been there but it has kept as the application terms of use. That means any application can read files on the SD card but it should not read. As terms of use you should not read. But it may be genuine danger because there may be some third party application. Then going to list of application. Then you said it is a provision. It is an option given to the user to application to view what are applications are installed. They said it is a reservation to get the list of application installed. But it is a genuine danger because by knowing the what are applications installed on the Android I may see that this application is installed on Android. So this Android device may be vulnerable to so and so attack. If an application X is installed on Android then I can see X is installed. So I can target this Android device with so and so attack. So even this is a danger. Then when going to since it can get the mobile code and the network etc. Then the Google said that it is very trivial information with help of this information we cannot get anything and it is not possible for any attacks. One precaution is do not store any information on SD card personal information. Because it is a provision given by Android we cannot change that provision that any application can blindly read the data on SD card. But it is valid in the terms of use that is a part. Another thing is so if there is an application which writes some important data on the SD card so later after knowing the developers may patch it and give us an update. So one should be install all the updates as it arrives. Explore some images. Another thing is so you know in Android the other portion of the writes it has read permission. So the images has read permission. Anyone can read any images in the Android device. So my application can read any images in the Android so I will design a malicious application which reads all the photos and send to me. This was the one. Then Google said that we are working on it and most probably in the next version we may add that it. Then they said photo accessing as a design choice. This is shared certificate explorer. That means two applications came from the same vendor. Then with the help of shared user ID feature they can share the permissions. So for example if there is one application which has internet access which comes from one vendor A which is installed onto the Android in later than the same vendor A has given some other application which can access contacts. So when these two applications have been installed onto the Android and they have shared user ID feature then one application can read the contacts and our application can send the internet the same contacts with the help of internet. So it is a subset. It is a superset of the permissions of two individual applications. So one should be careful while installing applications from same vendor. So while installing an application from the same vendor we should see whether some dangerous portion of the permissions it has asked. If that was the case it is better not going for that application. Another thing is reverse engineering. So since Android applications are developed based upon Java in Java we can know we know that class files can be converted into Java files. So the logic behind this serial code can be traced off and once it has been traced off then we can do the same logic and we can crack the licensing. So to prevent this what we can do is see that the components of an Android application even can be developed with the help of native C components. So since reverse engineering is different in such type of languages so we will do the licensing model only the licensing model in that native C component so the reverse engineering is not possible. One is a conceptual flaw in Android sandbox. The Android is well-searched in permissions but there is no transitive permissions. It does not track the transitive permissions. So I will commit in the next slide. So this results in the performance that Android sandbox is not authorized to do. So an application which is not authorized to do something even it can do it because of this fundamental flaw. I will explain it. The same thing is privileged escalation attack. That means at the installation of the application there will be only few permissions. While running it may escalate its permissions. That is privileged escalation attack. So it may range from phone calls, text messages and illegal downloads etc. So what is the flaw? See application with less privileges is not restricted to as say the components of more privileged application. So this was the problem in the Android. So if there is an application A, those components are very less privileged. Then applications I mean components in B. Still it can access that components. In Android we can share the components. Especially we can share the components. The Android has provision. So what it says is these permissions, so what Android says is it can access. But before accessing you should have some some privilege level. So the application component which has this privilege level can only access this. So this is specified in Manifest.xml. But after that application is developed in a developer who may not be aware of security. If I am developing an application if I don't want that component to be used by so and so, the application with so and so privileges then I have to expressly say it. So this application component can only be accessed by a component with such privileges. So for example if you take there are three applications A, B, C. There are three applications A, B, C and if it has two components C A1 and C A2 and B and I have no permissions. No granted permissions. Whereas B has permission P1 and consist of component C B1 and C B2. So neither of the C B1 and C B2 is not protected by permission level. That means the application developed who has developed B has not said anything that the component C B1 is accessed by so and so. So there is no restriction anyone can access the component in C B1. The application if the application does not want this component to be used then the programmer has to the developer has to expressly say in Manfors Reductic symbol. So if so C B1 and C B2 are not protected by permission labels so C B1 and C B1 can access the component which is protected by P1 because C B1 and C B2 are the components of application B. B has permission to access P1. So the components in application B can access any components which is protected by permission level P1. For example C has no permissions and consist of components C C1 and C B2. The developer of application C what is this is my component C C1 can be only accessed by an application is P1. That is it is protected by permission level whereas in the same way C2 with protected by permission level P2. See there is an application here right so that contains two components C A1 and C A2 it has no permissions there is application B which is granted with permission P1 and there is an component C B1, C B2 it has not protected by any permissions any permission labels application C it has no granted permissions and it has two components. So any components in this application can access the any components which has protected level P1 that B can access C because it is protected by level P1 and this this application has granted permission P1. Application will be granted permission and components will be even permission label that means this component can be used by so and so applications. So that means this is protected by P1 means this component can be only used by an application components which has P1 as P1 permissions granted. Now see it cannot access C A1 is there right so it cannot access it directly because because C A1 has protected level P1 C C1 has protected level P1 so what it says the components of an application who want to access this component has to be granted with P1 so A cannot access this but B has granted P1 right so it can access this so A can access B because it has not protected with permission labels it is a flaw of an it is a mistake of a developer you would have kept it as P1 protected then this may not be happened so you should not write so the less privileged system should not access me so my application is accessing P1 my application is accessing P1 if I know I do not go any permission labels to this then any application can access my component so you do have keep an P1 then you may not be using so to protect this what has to be the B has to be additional checks on the permission B there you should be some additional checks that C1 should be granted only to the application who says permission P1 but it is left to the application developer so there are many number of applications without implementing this so because of this there are many security flaws in the applications even some of the applications survey says that some of the applications which are developed by Google itself is vulnerable to this type of attacks so now we are coming with many advanced frameworks which even track this it is a collision attack the same thing which it comes from the same vendor and where there are two applications coming from the same vendor and they have same digital signature no same certificate and if they have shared secret key then one application can use the other application resources just like so one application has permission to record audio and monitor the call activity whereas the second application from cause internet permissions so one application can record this call another application can send it so these are the references thank you