Seven Ways to Hang Yourself with Google Android

Video thumbnail (Frame 0) Video thumbnail (Frame 1907) Video thumbnail (Frame 3135) Video thumbnail (Frame 4103) Video thumbnail (Frame 6175) Video thumbnail (Frame 9185) Video thumbnail (Frame 10624) Video thumbnail (Frame 13242) Video thumbnail (Frame 14154) Video thumbnail (Frame 15397) Video thumbnail (Frame 17111) Video thumbnail (Frame 18075) Video thumbnail (Frame 19003) Video thumbnail (Frame 20694) Video thumbnail (Frame 21705) Video thumbnail (Frame 22630) Video thumbnail (Frame 24265) Video thumbnail (Frame 25219) Video thumbnail (Frame 27780) Video thumbnail (Frame 28799) Video thumbnail (Frame 30319) Video thumbnail (Frame 31328) Video thumbnail (Frame 32248) Video thumbnail (Frame 33502) Video thumbnail (Frame 34718) Video thumbnail (Frame 35958) Video thumbnail (Frame 36907) Video thumbnail (Frame 38591) Video thumbnail (Frame 41100) Video thumbnail (Frame 43365) Video thumbnail (Frame 44552) Video thumbnail (Frame 45633) Video thumbnail (Frame 46515) Video thumbnail (Frame 49468) Video thumbnail (Frame 50736) Video thumbnail (Frame 53345) Video thumbnail (Frame 54495) Video thumbnail (Frame 56640) Video thumbnail (Frame 59635) Video thumbnail (Frame 60971) Video thumbnail (Frame 62424) Video thumbnail (Frame 64827) Video thumbnail (Frame 66347) Video thumbnail (Frame 67316)
Video in TIB AV-Portal: Seven Ways to Hang Yourself with Google Android

Formal Metadata

Seven Ways to Hang Yourself with Google Android
Alternative Title
7 Ways to Hang Yourself with Google Android
Title of Series
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
According to Google, Android was designed to give mobile developers "an excellent software platform for everyday users" on which to build rich applications for the growing mobile device market. The power and flexibility of the Android platform are undeniable, but where does it leave developers when it comes to security? In this talk we discuss seven of the most interesting code--level security mistakes we've seen developers make in Android applications. We cover common errors ranging from the promiscuous or incorrect use of Android permissions to lax input validation that enables a host of exploits, such as query string injection. We discuss the root cause of each vulnerability, describe how attackers might exploit it, and share the results of our research applying static analysis to identify the issue. Specifically, we will show our successes and failures using static analysis to identify each type of vulnerability in real-world Android applications. Yekaterina Tsipenyuk O'Neil is the founding member of the Security Research Group at Fortify Software, where she is responsible for performing code audits, identifying and analyzing insecure coding patterns, providing security content for Fortify's software security products, and researching ways to improve the quality of the tools. Outside of the office, Yekaterina spends time working with customers and speaking at conferences. Yekaterina has a B.S. and an M.S. in computer science from the University of California, San Diego. Her thesis work focused on mobile agent security. Erika Chin is a Ph.D. student in Computer Science at the University of California, Berkeley. She is in the security research group, and her current research interest is improving mobile phone security. In particular, she is interested in addressing developer confusion and difficulty that lead to vulnerabilities in mobile phone applications. She recently presented at MobiSys on vulnerabilities stemming from inter-application communication in Android.
Android (robot) Group action Code Student's t-test Content (media) Mereology Hypothesis Fluid statics Different (Kate Ryan album) String (computer science) Software Information security Social class Vulnerability (computing) Software developer Mathematical analysis Code Group action Cartesian coordinate system Computer Product (business) Data mining Type theory Coding theory Software Figurate number Information security
Ocean current Android (robot) State observer Group action Real number Sheaf (mathematics) Student's t-test Computer Telecommunication Term (mathematics) Googol Information security Computing platform Vulnerability (computing) Collaborationism Enterprise architecture Android (robot) Mathematical analysis Student's t-test Cartesian coordinate system Degree (graph theory) Telecommunication Mixed reality Universe (mathematics) Computer science Information security Resultant
Android (robot) Service (economics) Computer file Java applet Virtual machine Maxima and minima Device driver Database Web browser Architecture Data model Component-based software engineering Telecommunication Googol Kernel (computing) Memory management Endliche Modelltheorie Digital rights management Information security Computing platform Computer architecture Software development kit Physical system Social class Interface (computing) Computer file Android (robot) Java applet Memory management Code Database Device driver Cartesian coordinate system Virtual machine Component-based software engineering Digital rights management Googol Kernel (computing) Telecommunication Interface (computing) Configuration space Information security Library (computing)
Sensitivity analysis Android (robot) Run time (program lifecycle phase) Service (economics) Computer file Multiplication sign Content (media) Information privacy Event horizon Broadcasting (networking) Latent heat Component-based software engineering Telecommunication Different (Kate Ryan album) Uniqueness quantification Process (computing) Computing platform Physical system Installation art Execution unit Service (economics) Touchscreen Content (media) Interactive television Code Menu (computing) Database Cartesian coordinate system Flow separation Component-based software engineering Type theory Uniform resource locator Message passing Process (computing) Broadcasting (networking) Software Internet service provider Mixed reality Telecommunication Order (biology) Right angle Game theory Musical ensemble Information security
Multiplication sign Event horizon Revision control Latent heat Mechanism design Component-based software engineering Telecommunication Internetworking Different (Kate Ryan album) Computer hardware Message passing Computing platform Physical system Default (computer science) Software developer Android (robot) Maxima and minima Cartesian coordinate system Electronic signature Component-based software engineering Message passing Internetworking Event horizon Computer hardware Mixed reality Telecommunication output Configuration space Physical system
Group action Mapping View (database) Cartesian coordinate system Type theory Message passing Component-based software engineering Personal digital assistant String (computer science) Computing platform Message passing Address space Physical system
Type theory Group action Component-based software engineering Personal digital assistant Computing platform Web browser Cartesian coordinate system Physical system
Group action Component-based software engineering Code Cartesian coordinate system Social class 2 (number) Task (computing)
Component-based software engineering Default (computer science) Group action Component-based software engineering Ferry Corsten Telecommunication Information retrieval Electronic visual display Cartesian coordinate system Default (computer science)
Injektivität Android (robot) Sequel Android (robot) Data storage device Computer network Data storage device Cartesian coordinate system Message passing Software Telecommunication Googol Telecommunication Authorization Authorization Message passing Vulnerability (computing)
User interface Area Greatest element Game controller Group action Touchscreen Information Code Nuclear space Mathematical analysis Control flow Set (mathematics) Control flow Cartesian coordinate system Leak Component-based software engineering Component-based software engineering Password Authorization Electronic visual display Intercept theorem Resultant Physical system
Touchscreen Component-based software engineering Multiplication sign Electronic visual display
Sensitivity analysis Group action Information Cartesian coordinate system Information privacy Broadcasting (networking) Uniform resource locator Component-based software engineering Telecommunication Personal digital assistant Bus (computing) Physical system Vulnerability (computing) Social class
Injektivität Component-based software engineering Group action Injektivität Component-based software engineering Telecommunication Code State of matter Cartesian coordinate system Vulnerability (computing)
Injektivität Hoax Information Multiplication sign Electronic mailing list Denial-of-service attack Cartesian coordinate system Exploit (computer security) Component-based software engineering Uniform resource locator Component-based software engineering Bus (computing) Lie group Local ring Error message Resultant Vulnerability (computing)
Interface (computing) Component-based software engineering Broadcasting (networking) Type theory Message passing Component-based software engineering Broadcasting (networking) Personal digital assistant Operator (mathematics) Telecommunication Authorization Flag Permian Message passing
Expected value Type theory Broadcasting (networking) Default (computer science) Computer-generated imagery Authorization Electronic mailing list Set (mathematics) Limit (category theory) Cartesian coordinate system Resultant Leak
Sensitivity analysis Information Computer file Computer file Data storage device Password Plastikkarte Plastikkarte Computer Cartesian coordinate system Broadcasting (networking) Uniform resource locator Password Message passing Vulnerability (computing)
Covering space Context awareness E-book Information Computer file Key (cryptography) Structural load Covering space Mathematical analysis Data storage device Plastikkarte Database Database Data storage device Plastikkarte Cartesian coordinate system Information privacy Information privacy Writing Digital rights management Encryption Digital rights management Reading (process)
Android (robot) Addition Information Software developer Data storage device Plastikkarte Parameter (computer programming) Regular graph Cartesian coordinate system Twitter Number Twitter Web application Latent heat Uniform resource locator Software Personal digital assistant Telecommunication Vulnerability (computing)
Android (robot) Sensitivity analysis Email Mobile app View (database) View (database) Password Planning Mereology Cartesian coordinate system Regular graph Leak Web 2.0 Web application Facebook Uniform resource locator Computer configuration Facebook Personal digital assistant Computer configuration Password
Android (robot) Mobile app Game controller Injektivität Sequel Open source Link (knot theory) Multiplication sign Database Regular graph Mereology Number Subset Web 2.0 Goodness of fit Latent heat Different (Kate Ryan album) Term (mathematics) Query language Summierbarkeit Social class Vulnerability (computing) Injektivität User interface Touchscreen View (database) Constructor (object-oriented programming) Open source Database Cartesian coordinate system Type theory Query language Personal digital assistant String (computer science) output Quicksort Table (information)
Injektivität Code System call Product (business) Product (business) Category of being Latent heat Query language Order (biology) Quicksort Abelian category Row (database) Vulnerability (computing)
Sequel Query language Order (biology) Query language Mereology Cartesian coordinate system Vulnerability (computing)
Statistical hypothesis testing Vulnerability (computing) Game controller Service (economics) Information Software developer Mathematical analysis Cartesian coordinate system Statistical hypothesis testing Number 2 (number) Type theory Googol Error message Internet forum Causality Whiteboard Different (Kate Ryan album) Term (mathematics) Authorization Message passing Information security Error message Task (computing)
Mathematics Android (robot) Internet forum State of matter Weight Phase transition State of matter Amsterdam Ordnance Datum Cartesian coordinate system
Android (robot) Sensitivity analysis Sequel 40 (number) Set (mathematics) Data storage device Fluid statics Broadcasting (networking) Goodness of fit Different (Kate Ryan album) Googol String (computer science) Square number Message passing Information security Injektivität Mathematical analysis Data storage device Plastikkarte Cartesian coordinate system Software Telecommunication Right angle Quicksort Table (information) Resultant
System call Java applet Software developer Reflection (mathematics) Android (robot) Mathematical analysis Reflection (mathematics) Division (mathematics) Mathematical analysis Cartesian coordinate system Fluid statics Term (mathematics) Googol Form (programming)
Slide rule Vulnerability (computing) Broadcasting (networking) Error message Software developer Mathematical analysis Information Category of being Vulnerability (computing) Number Side channel attack Leak
Android (robot) Enterprise architecture Software developer Android (robot) Mathematical analysis Set (mathematics) Mathematical analysis Fluid statics Fluid statics Software Commodore VIC-20 Information security Information security
um so thanks a lot today we'll be talking about seven ways to hang yourself with Google Android namely we'll be discussing the seven most common security mistakes that we think developers can make while writing android applications few words about
ourselves my name is Katrina and I'm the founding member security research group at 425 software now we're part of HP I primarily work on static analysis tools so I'm trying to figure out how they can detect security vulnerabilities in the code automatically and I'm always trying to improve the tools and figure out how to detect more different types of vulnerabilities so now we're looking at android you know I got interested in security when I was a student at UCSD I took computer the computer security class and got fascinated with a subject and stayed around and you know actually managed to do my master's thesis and and security and so here I am I have a pleasure of co-presenting the stock with a colleague of mine from UC Berkeley Erica Chan she is gonna introduce herself hi I'm Erica Chan I'm a PhD
student in computer science at UC Berkeley I'm in the security research group i received my undergrad degree at university of virginia my current research interest is in improving mobile phone security and my most recent work was on vulnerable ADIZ in inter application communication in android before we proceed I want to emphasize emphasize that this talk is a is a great example of collaboration between the industry and academia and we're very very very excited to be working with each other because we get to incorporate all the analysis techniques that we both are working on in to fortify stools and these tools are used by you know enterprises all over the world so let's
begin which divided the talk into four sections first we're going to briefly introduce android platform we're basically not sure how many of you are familiar with it and to what extent so we're going to just give you a brief intro enough so you'll be able to follow the rest of the talk then we're going to talk about the seven security vulnerabilities that we think it can be very very common in real world android applications then we'll talk about the results of empirical analysis and will conclude with some observations and lessons learned in terms of introduction
to Google Android we're going to discuss architecture security model and also application breakdown basically you know android manifest which is a configuration file that comes with every android application components of android application and also enter component communication so android is
built on top of linux kernel so basically it provides know things like device drivers and memory management on top of the colonel will have some native libraries or in c in c++ and they provide things like graphics and database management and your browser engine WebKit for example these can be accessed by a Java interfaces on top of the native libraries there is a modified virtual machine which is called dalvik virtual machine which runs that Dex rather than that class files let's see Android applications are written in Java and they're written using the google android sdk which is basically a gentle interface that allows you to access systems and services of the android platform so the whole idea behind mobile
platform is the fact that you're going to running lots and lots of different applications on your system and so you might be you know installing and downloading a banking application that's going to be dealing with some sense data and on the other hand you might be installing a game application right next to it and run it on the same system and you obviously don't want your game application to be able to access the sensitive data that your banking applications operating on so in order to achieve this Android platform make sure that every application is isolated from each other so basically whenever you download and install an application every application is given a unique UID and therefore an application each application runs as a separate process in separate vm and typically applications cannot talk to each other and see each other's they can talk to each other but I can't see each other's private data unless you do something funny because the platform is built on top of linux linux style file permissions apply but what specific to Android platform is this whole system of permissions so provided by Google permissions allow you to protect access to things like sensitive IP is so advanced that allow you to access in a location services network Wi-Fi bluetooth etc permission system also allows you to protect access to content providers which are basically databases and it also protects inter and intra application communication permissions are requested by an application at install time and so they're also granted once or denied at install time and then at runtime they're enforced and now
let's talk about the different components of android applications so applications are divided into components there are four types of components the first type of component is an activity and activities is there basically the user interfaces so each screen you see on your Android application that's its own activity services are our components they run in the background and they don't interact with the user so these are well-suited for long running processes so like if you wanted to implement a music player things that run in the background that's what a service would be before broadcast receivers receive messages from other components so this can be like for things like system event notifications or messages from third party applications and finally we have component content providers and content providers are basically you can think of them as databases so each application
contains a manifest and the manifest does a couple things first of all it declares application components so as you can see here we have an example of an Android manifest and here it's declared there's a my activity and a my receiver so the components are declared here and if the developer doesn't declare the components here then the system would not know about them the manifest also specifies application requirements so this can be things like platform versions or input configurations or specific hardware requirements so in this example you can see here that the developer is requesting the camera feature it's using the camera feature and it's also requiring that the minimum SDK version be 8 so most importantly the manifest is where permissions are requested so as Katrina said these are things that are denied or granted at install time and so here we have this application is requesting the internet and camera permission and finally developers can also create their own permissions and these will be applied to the global system so here we have a new permission being created and the developer can also set how that permissions to be obtained so they can say that it's a normal permission and will be granted automatically uninstall they can say that it it needs the approval of the user or it can require that the an application requesting this permission has the same signature as the application that defined this permission so diff I
despite the default isolation that Katrina had mentioned applications can communicate between one another through the use of intense and you can basically think of intense as messages they're sent between components of applications furthermore applications can be sent between components within the application and also components in different applications so you're using the same mechanism for both inter and intra application communication and as said before notify can also be used for event notifications from the system so
there are two types of intents explicit intents and implicit intents so explicit intents are intense where the sender specifies the recipient by name so in this example we have the Yelp application and I'm sure all of you are familiar with Yelp you can pick a restaurant and then there's a there's a feature where it will show you where that restaurants located on a map and so suppose the Yelp application had a particular map application that they wanted to use so to do this Yelp simply creates an explicit intent address it to that particular map application and then sending the intent will launch that map application so in this example with explicit intents it's important to note that only the specified destination will receive this message so the other type
of intents are implicit intents and these are intense without a specific destination so instead the developer specifies this thing called an action in the message and then it leaves it up to the system to determine which component is most suited to handle that particular action so actions are meant to describe the general requirements of the intent and this is so that the sending application the Yale application doesn't need to know what other applications are installed on the phone so ash actions should specify what the receiving component should do so some common actions include the view action the edit action but really the action can be any any string created by the developer so going back to the Yelp application they could have sent an implicit intent with the view action and then the system will then look at the receiving components and look at what actions can be handled and in this case there's only one component that can handle the view action so the system will deliver this intent to that map
application so in a couple cases there
may be more than one application that can handle this action so depending on the type of the request requesting component either the user will be prompted to choose what the receiving application should be or the system might decide what that application should be or the system will deliver it to all possible recipients that can receive that particular action so in this example let's say the system will deliver this intent to the browser
application instead so just to give you
an example of the code snippets for these intense in the first example you see the explicit intent and you can see that this intent is the class name is being set so that's the destination that's being said and this intent should be used when the developer has a specific recipient in mind and in the second code snippets you can see the implicit intent so this the class name is not being set instead an action is being said and this should be used when the developer just needs some component to handle a specific task so we have all
this intent communication how can components protect themselves so components can limit their exposure to intense in two ways first components can be made accessible to other applications so explicitly exported so visible to all applications or they can be made private so only visible to other components within the same application so the good news is that by default when you declare components there they're set to being private however when a component is registered to receive that it can receive an action so it's registered to receive implicit intents this component is automatically changed to being a public component and this can be pretty dangerous because it's not something that the developer is explicitly setting just the status is changing from private to public and the second way to protect a protect component is through permissions so receiving component can require that a sender has a permission to send to that component so an example of the second
exit requirement is so on the right side we have application to this has to public components one retrieves a picture and it requires the retrieve permission the other one takes a picture and it requires the camera permission and then on the left-hand side we have an application and it has the retrieved permission so in this example the displays picture component in application one can send an intent to the retrieves permit picture component because it has a retreat permission it can't send the intent to the takes picture component because it doesn't have the camera permission so now that
I've given you an introduction of Google Android let's get into the seven ways to hang yourself with Android so the most common developer mistakes that will make your application vulnerable so I'll be
talking about unauthorized intent receipt intent spoofing and persistent messages and these are all related to their all communication related vulnerabilities and then I'll also be talking about insecure storage and then Katrina is going to be talking about insecure network communication sequel injection and over privileged applications
so the first attack we have here is unauthorized intent receipt so in this attack a malicious application intercepts and intent or steals an intent so this will occur when the intent this being said is implicit so it's public to the system and it doesn't require that any receiving components have any particularly strong permissions so what happens in this as a result like any basically if this intent is stolen any data in that intent will you know the attacker will get that data and it can also change the control flow of the application so if the intent was to request a specific display the user interface and activity then and if an attacker provides that display now the attacker has you know control of the screen and if the user gets prompted to put in their password then the attacker will steal that information so as a reminder on the bottom we have a code snippet of the implicit intent here's the set action is being called and so
one of the examples that we found in our analysis is from the IMDb application so this application has a feature where the user can request to get showtimes listed for movies in the area and so to do this the application has a component Showtime search and it sends information it sends a request to the results UI which then we'll update the user screen so the user
display the the display will either update the screen with the latest showtimes available or it will say that no showtimes are available at all so
this is an example of what the user might see here you can see that there is a couple movies listed and it'll have times so the problem with this exam with
this scenario is that instead of sending and a direct explicit intent between these these components the developer chose to use an implicit intent so it made both the tent and also the receiver public so in
this just as a reminder remember implicit intents means it's going to the system the system is resolving where that destination should be so all a malicious application needs to do is register another component say that it can handle the same actions as the legitimate receiving component and then when this intent is sent implicitly the system may deliver the intent to the eavesdropping application so in the case of the IMDb application the attacker finds out a couple things the attacker knows that the IMDb application is being used by the user they know that the user is looking for showtimes and then any intent any data in that intent can also be stolen by the attacker we've seen this vulnerability in other applications as well there's another bus a bus application that where the user can get information on where buses and when it will next arrive and in that application the attacker can eavesdrop on the bus request and determine what the user's location is so as you can imagine this is very clear privacy violation so our
recommended fix for this problem is to use explicit intents whenever possible so set the class name and if you're using a broadcast and you want it to go to multiple recipients then you can also consider adding permissions to that request so require that the recipients have a permission and in any case regardless of whether the intent is holding any sensitive data don't unnecessarily expose the data in that intent so if you're only communicating in within that an application you don't need it to go out to the system you know what the recipient components names are
so what just happened okay so the second
the second vulnerability we have is intense spoofing so in this this is the attack is that the malicious application is sending an intent into a legitimate application so if the legitimate application just trust the data trust the intent then you know and it uses the data in the tent then that would result in data injection if it receiving that intent will change the state of the application that can also occur and so this problem arises when components are public and they don't require the sender's to have any strong permissions so here we have a reminder of the code this is a receiver being declared in a manifest and as you can see here it's declaring that it can receive this action my intent action so it's being it's being made a public component so
this attack exploits of vulnerability on the receiving side so let's go back to the IMDb example we had the receiving component that updates with showtimes or says that there's no location error so if you recall it was receiving an implicit intent which made that component public and so as a result a malicious application can simply send send and intent to that component so we can either send it explicitly or implicitly and if an act attacker does this then if the attacker in particular is sending the know location error then then the user will get informed that there are no movie showtimes available
so instead of what you would see on the left which is a list of all the showtimes the user would basically it would be a denial of service so the user would see that there are no location no movies available and then going back to another example in the same bus application as before an attacker can inject fake bus information into a component so the user with CEO this bus is arriving at X time potentially a lie so the user could basically wait for a bus that never arrives so our recommended fix for this
problem is to use the exported flag when declaring components and explicitly make the component public or private so always always make it like even if you don't need to always make it explicitly stated and you know make it private when whenever possible if the situation is that the component is supposed to be a public component then consider limiting the interface by requiring that the sender has a permission so in the second example you can see that even though the exporter flag is true it also has a permission so it's limiting the types of intense that can be sent to this component so in any case make sure that public components aren't performing any sensitive operations so our third phone
available nur ability type is persistent messages and an Android these are called sticky broadcasts and this is a particular attack it's a special case of the unauthorized intent receipt which is the first attack we presented to give you a little background first broadcast intents there instead of the typical one-to-one communication it's a one-to-many communication so one message is being sent to any components that can require receive potentially receive this message and then a sticky broadcast is a broadcast intent that persists so it's expected to stay around and they're accessible after they've been delivered already and the rebroadcast to any future new receivers so there are couple
problems with this new type of intent so like the typical unauthorized intent receipt problem any malicious attacker could basically steal data any data contained in the intent but this is a special a special type of intent so there are two other things that can happen so first of all sticky broadcasts can't be restricted to a certain set of recipients so you can't require that the recipient has a permission so there's no limitation on that and also the this intent is expected to stay around and so the problem here is there's this expectation but anyone with a broadcast sticky permission can steal that intent and remove it permanently so here's an
example that illustrates that we have on the Left we have stick a list of sticky broadcasts and and then we have a malicious receiver and this receiver has the broadcast sticky permission which is a normal permission it gets granted by default when you install an application so the user doesn't see it and what the attacker can do is basically remove this sticky broadcast and so as a result this new receiver the victim application that appears later won't get this data in the sticky broadcast so our recommendations
for this vulnerability is that regular broadcasts should be used whenever possible and and these broadcast should be used with the requirement of having the recipients have a permission and also regardless don't put any sensitive data in a sticky broadcast anyone can read it our fourth vulnerability is on
in secure storage so what can happen when you have insecure storage so people will save their passwords location contact information all sensitive data and if storage is insecure then this can be stolen so we're looking at specifically at the SD card so the SD card has files and these are all world readable so anyone can read it users can read it it can be synced to your computer so your computer will have those files and then also the files will persist even after after the application that created that pile gets uninstalled these files will remain on the SD card
so an example that we founded in our analysis is in the kindle application so the Kindle application stay saves a bunch of data on the SD card first of all it saves the ebooks on the SD card and this can be a problem because third party party applications can read the SD card which means they can get access to the ebooks so an attacker can have free ebooks whether they can read it or not depends on the drm so some some are not protected another issue is that the covers of the books are also saved to the SD card and so this is a privacy violation some people are sensitive about others knowing what books they read so this information should not be leaked and finally the folder after you uninstall the Kindle application the folder that contains all of this data retains on the SD card so an example that you can think of is common situation is you know users want to move on to the next cool phone so they sell their old phone and even if the old owner or the new owner does a factory reset on the phone it you know they're clearing the data on the phone it's not clearing the data on the SD card so what happens is when the new owner well one the new owner has access to the SD card can just look at it they can also install the Kindle application and the Kindle application will automatically look in this folder and load the books in that folder so again this is another privacy violation because we don't want other people to have access to our reading material and now the recommended
fixes for this problem include so you could do a couple things you could write to the applications database you could write to the devices internal storage for the application and make sure to make that file non readable to other applications and finally if you have to store your data on the SD card then make sure you encrypt that data if it's sense at all sensitive and of course don't put the key on the SD card people can read it ok and now Katrina's going to talk about
the remaining three ways so the security vulnerability number five that we think developers can make is insecure network communication and basically just like in the case of insecure storage what we're worried about is leaking sensitive data only in the case of insecure storage we're leaking sensitive data onto an SD card in the case of insecure network communication we're looking at over HTTP and now obviously this is not anything new this is not vulnerable a specific to mobile world or specific to Android this vulnerability existed in regular web applications and you think that we learned some from our mistakes and we know that sensitive data needs to be sent over HTTPS but no turns out that's not the case and here are some of the examples so we use wireshark to sniff
packets coming from the phone and here's an example here's a screenshot of what the mobile twitter application sends over HTTP and as you can see here it sends the twit which is basically the value of the status parameter in the clear and in addition to that it sends things like latitude and longitude of the person who's twitting alon also in the clear obviously both of these pieces of information are sensitive because no one is that when another is the person's location so the fact that anybody can access that is bad here's another
example Facebook application for Android as you can see from the screenshot it sends planes like contact email first name last name also in the clear over HTTP and the most alarming part is that the regular web application allows you to set preferences as to how you want your data sent over HTTP or over HTTPS but in the case of the mobile application for facebook this option doesn't exist and everything is just automatically sent over HTTP so that's that's pretty bad too so what's the
recommended fix obviously don't do it don't leak sensitive data such as passwords on location contacts use HTTPS when you use web web views whenever possible and just in general think about your mobile obligation in the same way you would think about the regular web application because in on a lot of in a lot of cases they're very similar and most of the attacks that apply to regular web applications will probably apply to mobile applications as well
problem number 6 is the good old sequel injection I probably don't have to explain what this is but just basically the idea is that you know untrusted and validated data is used to dynamically construct sequel queries and that could lead to bad things such as you know deleting tables and injecting something into the database and all sorts of other things again this is not new this vulnerability is not specific to mobile world or Android unfortunately still can it still happens even though again we've known about it for a long long time and here are some of them api is in the Google SDK that are susceptible to the regular sequel injection so here is some methods from sequel I'd database class that you should be aware of so in the case of the regular publications when we think about untrusted input we basically mean you know into that comes from outside of the application so things like you know something that comes from a user interface or HTTP request in the case of mobile world you know a mobile application it probably doesn't really make sense to think about user interfaces untrusted data because it's probably unlikely that you're going to be attacking yourself but you know all other types of untrusted sources still apply so anything that comes from outside applications such as know if if the data comes from a different application should be treated as an untrusted because that application could be malicious or you know if your user you're browsing the web you're clicking on some malicious link and then all of that also needs to be trusted it needs to be treated as untrusted a subset of a
sequel injection vulnerability that we call query screen injection vulnerability is something that doesn't allow you to modify the database but allows you to view more records than you're supposed to which basically you know makes it sort of an access control type vulnerability and just like in the case of sequel injection and also happens because untrusted invalidated data is dynamically concatenated into a part of a sequel query so basically in terms of Android the difference between the two is the api's that are exposed to some API has allow you to specify the entire query as a strange sound okay so allow you to specify parts of the query and so that's how to differentiate between the two here is a specific
example here is a call to a query API basically lots that basically returns invoice records for a product category for a particular customer with a specific customer ID sorted by the sort column so if you supply fax machines is
the value of product category and one two three six seven eight is the value of customer ID and price is the value of sort column then here is what your query is going to look like and basically the returns you invoice records for one customer which customers I ID is Monty three four five six seven eight however if you have some piece of untrusted data come in and that and because of that the product category is set to something like fax machines or product category pulls back /quote customer ID is one two three four five six seven eight and South column is back /quote order by price then your see your query looks very very different and if you stare at it long enough you'll see that basically we're able to get around the check against the customer ID and what that means is you know are able to see return you see invoice records for all of the customers rather than the customer then just one customer with customer ID 1234 5678 which was the intent behind the code so I hope I it's not surprised anybody what the you know fix the heights equal in queer Street injection vulnerability is parameterized
queries make sure you use those and don't just simply concatenate untrusted data into a sequel query make sure that you know you make it very very clear which part of the query is the command and which part of the query is the data and that's what parameterize queries do for you the last and probably the most
interesting and exciting security vulnerability we want to talk about is over privileged applications so over privileged applications are applications that request more permissions than they really need to in order to run successfully and correctly so what's that bad well first of all it violates
the principle of least privilege again the probably familiar with it but basically the idea is that you shouldn't have more authority than you really need to perform a task and so why is it bad if you do well then if your application has a different type of nura bility then an attacker is able to exploit it and an attacker has control over over your application on their floor has control has all the permissions that the application requested them was probably granted even though the application didn't actually need all of those permissions another reason why it's bad is because basically people are getting used to these permission checks pop up and you know some users they're not that security savvy are going to just click okay okay no I accept and it's very possible that are going to be downloading some malicious application that request some scary permission because it needs to steal your data but on the other hand you know if you're me if you know what security is all about then you might be scared away and you don't want to download an application that's actually benign and just you know requests a scary permission that it doesn't need so what are y-you know over
privileged applications happen what causes those and our colleagues at Berkeley did some analysis and came up with a number of causes and basically all of these causes stem from the fact that there is a very very little documentation provided by google for the developers in terms of which api's require which permissions and I'll come back to that discussion in a few slides but because of that developers are left with either you know doing figuring this information out by trial and error or guessing or turn into message boards and so here some of the common causes one of them is the confusing permission names and i'll show you an example in the second others is testing artifact so there's a number of permissions that are used for testing such as mock type permissions and so you're supposed to remove them after you're done testing and if you do not remove them then you end up with an over privileged application there's also confusion between accessing a protected API versus invoking an application that accesses a protective API and again I'll have a an example in a second also there's something like something we call related methods so suppose you're a developer and you're accessing this service that has both getters and setters and only the setters require the permission but you're only accessing getters so you actually don't need the permission but just because you're accessing the service and there's no documentation provided you might think that you know you need the permission and so you request it and end up with an over privileged application and finally message boards and forums actually suggest wrong things so let's look at
some examples here's an example that illustrates the confusion between you know accessing a protected API versus invoking an application that access is a protected ipi so here we have two applications a camera application which actually takes a picture and you know access as a camera which obviously means she it does need a camera permission but then there's also a nap one and all it does is that it asks the camera application for picture it doesn't actually take it doesn't access the camera so it doesn't need a camera permission but the developer might think that you know well my application has something to do with the camera said probably he's the camera permission so and end up with an overprivileged application
and here's an example of that illustrates both the confusing naming and also the you know Ron suggestions given by forums and message boards so for example if you're registering for an Android net Wi-Fi state change intent then it suggested that you need an access Wi-Fi state permission but in reality you don't so what's the
recommended fix well the fix is pretty clear just didn't know don't request more permissions then you really need to of course it's easier said than done and we think that the first thing that needs to happen is for Google to improve their documentation but in the meantime you can use automatic tools that identify over privileged few words about
empirical results so now that we talked about the seven security mistakes that we think people can make right in android applications you're probably wondering are these mistakes actually no real do they happen in real applications and this table should convince you that they are indeed real so we looked at a bunch of different applications we scan them with our tools with many different tools because we have several tools that we use and we did some manual investigation and so you can see that for example an authorized intend receipts happen and fifty percent of applications that we've looked at in 10 spoofing happens in forty percent of applications in six percent of applications we've seen the usage of sticky broadcasts twenty percent twenty eight percent of applications right some sensitive some sort of sensitive data too insecure storage and two SD card seventeen percent have sequel or square string injection and thirty-one percent of all applications will look turned out to be over privileged good question so the question is what happened to secure insecure network communication we don't unfortunately have good set of data for that way so we've talked about the two examples that we've seen and we thought that it's important to mention them but we don't actually have the data because it's not that easy to find these things with with static analysis tools which is what we've been using so some challenges that
we had to overcome coding conventions are in the in the form of callbacks and the java reflection are pretty difficult to handle by traditional static analysis tools and another big challenge is the documentation and I was personally shocked to see how little of it is documented and somehow we're expecting developers to write secure Android
applications and in fact my clicks of Berkeley while they were doing analysis over privileged applications they did analysis of the documentation and they realized that android 2.2 documents permissions for only seventy eight out of twelve hundred and seven api's that the team found and in fact six out of these 78 api's were documented incorrectly so for example one permission that was mentioned it didn't even exist in terms of which tools
identify which will nur abilities fortify stool currently can identify five out of the presented vulnerabilities in Berkeley tools identify four and after we collaborate and combine the two analysis we plan to be able to identify six out of the seven automatically with the tools our work
and research and the stock were inspired by a number of other researchers and some of their names names of some of them are on the slide so if you want to learn more go beat those people's work
and just in conclusion we'd like to say that well it's clear that Android has a set of security pitfalls itself and we think that static analysis tools can help developers of with a lot of these problems and again we're very very excited for 25 software and Berkeley to be working together and incorporating the state-of-the-art analysis into fortifies tools that are going to be used and are used by a lot of enterprises all over the world and that this is the end of our talk thanks very much and we're open to questions or you can come