 Today, I am going to present some of the details of the Android security. The agenda for today's session is cross-call scripting. What is cross-call scripting? What are the types of cross-call scripting? I will demonstrate one of the attack in reflected cross-call scripting. Then I will go to the privilege escalation attack and Android, then we will conclude it. What is XSS? XSS means cross-call scripting. It is a vulnerability found in web application. What it does is with this vulnerability, the attacker can execute his own code onto the victim PC and steals the private data from his victim PC and sends to the attacker. Like you can log in it, you can steal the cookies, you can get the details of his private data. What are the cost of this? The cost of this is improper invalidation of the input of the user by the server. Usually, the people who are developing the websites are not aware of the security. What happens is that they does not validate the input. These are such as a vulnerability for the cross-call scripting. There are three types of cross-call scripting, reflected XSS, persistent XSS and DOM-based cross-call scripting. We can view the diagram here. So it clearly shows that this is the attacker, you will design a URL with an malicious code in it in one or more parameters of the URL and sends it to the victim through mail or some other source. When he receives this URL, you just click on it, the request will be sent to the some legitimate site. The legitimate site may not be designed by a security of their developers. So because of this improper validation of input, it process the request and sends back the response. In response, the malicious code will be embedded by the server which they got from the request and the malicious code will be executed onto the browser and it steals the private data and sends to the attacker. What is the main cause of reflected XSS? Again the improper validation of input is the main cause of reflected XSS. So the attacker embeds the malicious code in the parameters of the request. The server reflects the parameter value in the response without invalidating it. Now just go through the, we can go through this URL. See, there is a web page in cac.id.ac.in which is developed by us. So there is a vulnerability. What this page does is, it takes one parameter called as name. It does not validate the parameter value and just reflect back into the, reflect back to the user. Now just see, the attacker has sent a mail to us saying that please click on this link. See, this is a web page, when they send a request, when they click on it, it sends a request to cac website, there is a page called as test.php with a name, with a parameter name as name and there is some parameter value. So if I click on it, what happens is a request is sent to test.php. See, for example, if I send the same request with the parameter as a books, what happens is the results for books are came here. Here the request now, the parameter is a malicious code, the parameter value is a malicious code. Now you can see here, you can find here, refused of execution a JavaScript source code of script found within request. That means what happens is, this malicious code is sent to the server, server is not validating their input and it sends back to the client. But the Chrome has a defensive mechanism, which does not exclude this type of scripts. We just view the source, we can view the source of this page. See, it clearly shows the, in response, there is a script, script, which is alerting saying hi. If I demonstrate the same thing in the Akash browser, that is Android native browser, we will see what will happen. See, I got a mail, I am just clicking on it, when I click on it, a request is sent to the same site and the script is executed. That means the Android native browser does not avoid this type of accesses. It is vulnerable to this type of accesses, whereas when request is sent from this Chrome browser, it gets the same response, but it finds one, the script, it finds the script in one of its parameter and stops execution. That means, that means Android Chrome has a defensive mechanism called as accesses auditor, which avoids some type of, sometimes some type of cross call scripting. It sits between HTML parser and JavaScript engine and interrupts all the JavaScript, all the JavaScript request and see whether it is found in one or more of the parameters. If it is found in the parameters, it stops executing it. Now, there is a very native, there is a very navy attack, that is it does not steal any of the private data. Now, you can find this URL, where a sent to data is stored. See, there is a legitimate.com, that means it is a genuine site, but it is developed by the, developed by a developers who are not aware of security, which take one parameter. They are not invalidating the parameter. So, the attacker may write script tag, where you want to write something, that is document dot, that means in the response, when this script is executed, it is trying to write some data, in what they want to write, they are, they want to write an image whose source is attacker.com, that means they want, they will fetch a data from attacker.com side and write on to the browser, browser window, but, but while sending a request to the attacker.com, they are even sending the cookie value, see they are even sending the cookie value. That is the reason with the help of this type of vulnerabilities, that attacker can view the victim, I mean they can get the private data of the victim. Then what is persistent accesses? In persistent accesses, the, what are the malicious codes, which you are sending by the attacker will be stored on the server pages itself, that is the web page is, the web page is not developed such a way that, like, just like discussion forums, where they are not invalidating the input the user is giving, with the help of this, the attacker will write a malicious code in the discussion forum pages and it, and it sends a request, that means it will be stored in the server itself, whenever a victim, whenever a victim view that pages, he can, he downloads the malicious code and execute it, yeah, this is the persistent access. That means, he is the, he is the attacker, he is sending, he is filling some form something like in discussion forums and sending a request to the server, the server is not validating the input. So, it will be, it will be stored in the server itself and in response, whenever a legitimate user like 15 views that pages, the malicious code will be downloaded and it will be executed in the server and the sensitive beta may send it to the attacker. Then the third part, third part of, third type of Costco scripting is DOM-based Costco scripting. That means, the web pages are nowadays are developed in such a way that, some default parameters of the page are taken, say, say, you just go through, we will go through the script. See, this is a legitimate page where what is doing is, it taking a default parameter from the user and taking the value of it and in the response, this script will be executed in the client side itself. This script will be sending in the response and in the client side, the user, the victim browser, execute the script. What it does is, it takes the default value of the, default value of the request and embed that into the response. See, if this default value is some, say, some English, then it does not matter. But if this is script, this itself is a script, then the script executes of the client and embeds the script again. Again, when the script is executed, it may malicious script. So, it may still sensitive data. So, there is different between, difference between reflected accesses and DOM-based accesses. Here, what happens is, the legitimate script from the server executes and embeds the, another script from in the, in the response. Now, I will go to the second part of the presentation. That is, privileged escalation attack. That is, Android does not deal with transitive privilege users. For example, 100 applications of components, right? One component can talk to another component through inter-component communication, right? So, each component can be used by some other components. There is the, even there is a, we can give the privilege of saying that, this component can be used by only some type of components. Say, for example, if there is a application C and it has one component called as C1, C1, if it is protected by label P1, what it means is, this C1 component can be only used by applications whose privileges are, have P1, right? Once again, I am repeating, if there is application called as C and it has a component called as C1 and if that component C1 is protected by label C1, what it means is, any application can use these components C1, if and only if that application have a privilege called as P1. For example, if that component is protected by P1, P2, then it means is, this application, this component can be only used by any application whose privileges is P1 and P2. Yeah, this is the, Android contains separate models called as components, components communicate through a mechanism called as inter-component communication ICC and Android has a, it is borrowed, Android isolates applications, it can only access the files only it, only it owns and it cannot access the files of other thing, each will have an application ID just like UID in user ID in the Linux, okay. What happens in privilege escalation at that? The permissions of an application get escalated at random. What usually means in Android, whenever you want to install an application at, before installation it will ask for set of permissions. In the set of permission, it will say that I need internet permission, I need to access condors, I need to access email something like that. At the time of installation, whatever you was, whatever if you select all the permissions and install that is the only thing they are using. But with the privilege escalation attack, the privileges which are not granted at the run time can be escalated. The type of, the type of attacks ranges from unauthorized phone calls, SMSs, illegal donors of malicious files and executing it. What is the vulnerability in privilege escalation attack? That is an application with less privileges, that is a non-privileged caller is not restrictive access components of a more privileged caller, I will more explain it in the next slide. I just see, we will go through this diagram. There are three applications in it, application A, B and C. And there are two components in each application, C A 1, C A 2 in application A and C B 1 and C B 2 in application B. In the same way, C C 1 and C C 2 in application C. Application has no granted permissions, that is the granted permission for application A is null. In the same way, the granted permission for application B is only P 1. In the same way, the granted permission for application C is null. You can here, you can see that component C 1 is protected by label called as P 1. That means, this component can be used, can be called by any component of another application provided that application has privileged P 1. With the help of this statement, can C A 1 use it C C C 1? No, because the protection label says that it can be only used by a component, whose each application have a privileged P 1, but A does not have privileged P 1. So, whenever C A 1 want to access C C 2, it is denied. In the same way, for example, if C B 1 want to access C C 1 as it is granted, the reason is it is for the protected label is P 1. This application B has a protected label, granted permission has P 1 and this can use it this. Under works well in this manner, that is it deals with the direct dependencies, but whereas, in indirect calling say, if C A 1 wants to will call C B 1 as it is valid, the reason is it is not it is protected by null, that is it can be accessed by any component. So, C A 1 can access C B 1, but C B 1 in turn can access C C 1. In this way, C A 1 can indirectly call C C 1, whereas, it directly cannot call C C 1. That means, Android does not bother about it tends to dependencies. In this way, we can use this vulnerability and we can make unauthorized calls SMS and we can use all the contacts and may send it to the send to the attacker. What is the conclusion? No, there should be a support from the client side to prevent Costco scripting. All Costco scripting cannot be avoided with only server validation. There are some type of attacks where they need a need of client side to prevent accesses. As we have discussed in the Chrome, there is an accesses auditor which sits between HTML parser and JavaScript engine and interrupts all the requests, interrupts all the requests, all these JavaScript requests and see whether it is part of any parameter of the request and if so, it denies it to execute. Whereas, it executes, if it phones, it is a legitimate request. So, you can see here, the request is JavaScript request is denied by the accesses auditor in Chrome whereas in that Android native browser, it is executed, the script is executed even if it is found in the one of the parameter value and to avoid the privilege escalation attack in Android, there should be a centralized model where all the request for the interrupts ICC should go through this and this should monitor indirect dependencies so that we can avoid the privilege escalation attack at runtime and these are the references