[Seminar] [Verdedigen Achter het apparaat: Mobile Application Security] [Chris Wysopal] [Harvard University] [Dit is CS50.] [CS50.TV] Goedemiddag. Mijn naam is Chris Wysopal. Ik ben de CTO en mede-oprichter van Veracode. Veracode is een applicatie beveiligingsbedrijf. We testen allerlei verschillende toepassingen, en wat ik ga praten over vandaag is de mobiele applicatie security. Mijn achtergrond is dat ik heb gedaan veiligheidsonderzoek voor een zeer lange tijd, waarschijnlijk ongeveer even lang als het even wie. Ik ben begonnen in het midden van de jaren '90, en het was een tijd dat behoorlijk interessant was omdat hadden we een paradigma verandering in het midden van de jaren '90. Opeens ieders computer werd aangesloten op het internet, en dan hadden we het begin van webapplicaties, en dat is wat ik gefocust op een terrein van toen. Het is interessant. Nu hebben we een ander paradigma verandering gebeurt met computers, dat is de verschuiving naar mobiele toepassingen. Ik voel het is een soort van een vergelijkbare tijd dan het was in de late jaren '90 toen we onderzochten webapplicaties en het vinden van gebreken zoals sessie beheer fouten en SQL-injectie die echt niet bestond, en ineens waren ze overal in webapplicaties, en nu een groot deel van de tijd besteed ik is op zoek naar mobiele toepassingen en kijken naar wat er daar in het wild. Mobiele toepassingen zijn echt naar de dominante computing-platform, zodat we echt nodig om veel tijd door te brengen als je in de beveiligingsbranche gericht op webapplicaties. Er waren 29 miljard mobiele apps gedownload in 2011. Het is voorspeld tot 76 miljard programma's zijn in 2014. Er is 686 miljoen apparaten die zullen worden gekocht dit jaar, dus dit is waar mensen gaan doen  de meerderheid van hun cliënt computergebruik gaan vooruit. Ik was in gesprek met een vice-president bij Fidelity Investments een paar maanden geleden, en hij zei dat ze zag net meer verkeer het doen van financiële transacties van hun klantenbestand op hun mobiele applicatie dan op hun website, dus een gemeenschappelijk gebruik van het web in het verleden is het controleren van uw aandelenkoersen, het beheer van uw portefeuille, en we daadwerkelijk zien dat in 2012 overschakeling dominanter op het mobiele platform. Zeker als er gaat elke criminele activiteit, schadelijke activiteit, het gaat om te beginnen te richten op het mobiele platform na verloop van tijd als mensen over te schakelen naar dat. Als je kijkt naar het mobiele platform, te kijken naar de risico's van het platform is het handig om het te breken in de verschillende lagen, net zoals je dat zou doen op een desktop computer, en u denkt over de verschillende lagen, software, besturingssysteem, netwerklaag, hardware laag, en natuurlijk is er kwetsbaarheden op al die lagen. Hetzelfde gebeurt op mobiel. Maar mobiel, het lijkt erop dat sommige van die lagen er slechter aan toe. Voor een, de netwerklaag problematischer op mobiele omdat veel mensen hebben in hun kantoor of thuis bekabelde verbindingen of ze veilig Wi-Fi-verbindingen, en met veel mobiele apparaten ben je natuurlijk buiten het huis of buiten het kantoor veel, en als je via Wi-Fi er u zou kunnen worden met behulp van een onbeveiligde Wi-Fi-verbinding, iets dat een openbare Wi-Fi-verbinding, dus als we denken aan mobiele apps moeten we rekening houden met dat de netwerkomgeving is riskanter voor die toepassingen wanneer Wi-Fi wordt gebruikt. En als ik in meer van de mobiele applicatie risico's je zult zien waarom dat is belangrijker. Er zijn risico's op hardware niveau op mobiele apparaten. Dit is een gebied van lopend onderzoek. Mensen noemen deze breedband aanvallen of baseband aanvallen waar je aanvallen van de firmware die luistert op de radio. Dit zijn echt eng aanvallen omdat de gebruiker hoeft niets te doen. U kunt veel apparaten hit binnen RF-bereik in een keer, en het lijkt alsof wanneer dit onderzoek opborrelt het snel wordt ingedeeld waar mensen Swoop in rond en zeggen: "Hier, vertel ons over dat, en dan kunt u stoppen erover te praten." Er is wat onderzoek gaande op het gebied van breedband, maar het lijkt erg hush hush zijn. Ik denk dat het meer van een natiestaat type onderzoek dat aan de hand is. Een gebied van actief onderzoek, is echter het besturingssysteem laag, en nogmaals, dit is anders dan in de desktop computerwereld omdat in de mobiele ruimte die je hebt deze teams van mensen noemden jailbreakers, en jailbreakers zijn anders dan reguliere kwetsbaarheid onderzoekers. Ze proberen om kwetsbaarheden te vinden in het besturingssysteem, maar de reden dat ze proberen om de kwetsbaarheden te vinden is niet te breken in de machine van iemand anders en het in gevaar brengen. Het is in te breken in hun eigen computer. Ze willen breken in hun eigen mobiele, wijzigen besturingssysteem hun eigen mobiele's zodat ze de toepassingen van hun keuze kunnen lopen en dingen met volledige beheerdersrechten te veranderen, en ze willen niet de verkoper over vertellen. Ze zijn niet als een security-onderzoeker die een witte hoed security-onderzoeker die gaat op verantwoorde wijze te doen en vertel de verkoper over. Ze willen dit onderzoek te doen, en ze willen eigenlijk publiceren in een exploit of een rootkit of een jailbreak code, en ze willen om het strategisch doen, zoals direct na de verkoper schepen het nieuwe besturingssysteem. Je hebt dit vijandige relatie met OS-niveau kwetsbaarheden op de mobiele, dat vind ik heel interessant, en een plaats zien wij het is het maakt het zo dat er goede gepubliceerde exploit code die er zijn voor kernel-niveau kwetsbaarheden, en we hebben gezien die daadwerkelijk worden gebruikt door malware schrijvers. Het is een beetje anders dan de pc-wereld. En dan de laatste laag is de bovenste laag, de applicatielaag. Dat is wat ik ga om te praten over vandaag. De andere lagen bestaan, en de andere lagen te spelen in het, maar ik meestal gaan praten over wat er gaande is op de applicatielaag waarbij code wordt uitgevoerd in de sandbox. Het heeft geen beheerdersrechten. Het heeft tot de API's van het apparaat te gebruiken, maar toch, veel kwaadaardige activiteiten en veel risico kan gebeuren op die laag want dat is de laag waar alle informatie is. Apps u toegang tot alle informatie over het apparaat als ze de juiste rechten, en hebben tot de verschillende sensoren op het toestel, GPS sensor, microfoon, camera, wat je hebt. Hoewel we nu alleen nog maar over op de applicatielaag we hebben veel risico daar. Het andere ding is dat anders over de mobiele omgeving wordt al het besturingssysteem spelers, of het BlackBerry of Android of iOS of Windows mobile, ze hebben allemaal een fijnkorrelige toestemming model, en dit is een van de manieren waarop zij in het besturingssysteem ingebouwde het idee dat het niet zo riskant als je denkt. Ook al heb je al je contacten op daar, al uw persoonlijke gegevens, je hebt je foto's, heb je je locatie op daar, je bent het opslaan van uw bank pin voor auto login op daar, het is veilig, omdat apps moeten bepaalde rechten hebben op bepaalde onderdelen te krijgen van de informatie over het apparaat en de gebruiker moet worden gepresenteerd met deze machtigingen en zeggen oke. Het probleem met het is de gebruiker altijd zegt oke. Uit veiligheidsoverwegingen persoon, ik weet dat je de gebruiker gevraagd, zeggen iets heel ergs gaat gebeuren, wil je het gebeuren? En als ze in een haast of er is iets heel verleidelijk aan de andere kant van dat, als een spel zal worden geïnstalleerd dat ze hebben gewacht, ze gaan klik oke. Dat is waarom ik op mijn dia hier zeggen laat me vogels gooien bij varkens al, en je kunt zien op de foto hier is er voorbeelden van een BlackBerry toestemming doos. Het zegt "Stel de toepassing permissies BlackBerry Travel na hieronder klikken op de knop, "en eigenlijk de gebruiker wordt net gaan zeggen de permissies en op te slaan. Hier is een Android-prompt waar het toont de dingen, en het eigenlijk zet iets dat bijna lijkt op een waarschuwing. Het heeft een soort van opbrengstteken daar zeggen netwerkcommunicatie, telefoontje, maar de gebruiker zal op installeren, toch? En dan is de Apple een totaal onschadelijk. Het bevat geen enkele vorm van waarschuwing te geven. Het is gewoon Apple zou graag uw huidige locatie te gebruiken. Natuurlijk zul je klik oke. Er is deze fijnkorrelige toestemming model, en apps hebben een manifest bestand waar ze te verklaren de machtigingen die ze nodig hebben, en die krijgt weergegeven aan de gebruiker, en de gebruiker moet zeggen dat ik deze machtigingen. Maar laten we eerlijk zijn. Gebruikers gaan gewoon altijd zeggen oke. Laten we eens een snelle blik op de machtigingen die deze apps vragen om en sommige van de machtigingen die zijn er. Dit bedrijf Praetorian deden een onderzoek van vorig jaar 53.000 applicaties in de Android markt en 3rd party markten geanalyseerd, dus dit is allemaal Android. En de gemiddelde app gevraagde 3 permissies. Sommige apps gevraagde 117 machtigingen, dus uiteraard deze zijn zeer fijnkorrelig en veel te complex voor een gebruiker te begrijpen als ze gepresenteerd met deze app dat deze 117 permissies nodig. Het is net als de licentieovereenkomst voor eindgebruikers dat is 45 pagina's lang. Misschien binnenkort zullen ze een optie waarin het is alsof hebben print de permissies en stuur me een e-mail. Maar als je kijkt naar een aantal van de top interessante permissies 24% van de apps die zij uit de 53.000 gedownload gevraagde GPS informatie van het apparaat. 8% lees de contacten. 4% verzonden SMS, en 3% ontvangen SMS. 2% opgenomen audio. 1% verwerkte uitgaande oproepen. Ik weet het niet. Ik denk niet dat 4% van de apps in de app store echt nodig om SMS-tekstberichten verzenden, dus ik denk dat dat een hint dat er iets ongewenst aan de hand is. 8% van de apps nodig hebt om uw lijst met contactpersonen te lezen. Het is waarschijnlijk niet nodig. Een van de andere interessante dingen over rechten is als u een link in gedeelde bibliotheken in uw toepassing die de machtigingen van de aanvraag, dus als je app moet de lijst met contactpersonen of moet de GPS-locatie te laten functioneren en u een koppeling in een reclame-bibliotheek, bijvoorbeeld, die advertentie bibliotheek zal ook in staat zijn om toegang te krijgen tot de contacten en ook in staat om de GPS locatie, en de ontwikkelaar van de app weet niets over de code die wordt uitgevoerd in de advertentie bibliotheek. Ze zijn gewoon te koppelen dat in, want ze willen hun app geld te verdienen. Dit is waar-en ik zal praten over een aantal voorbeelden van deze met een applicatie genaamd Pandora, waar een applicatie ontwikkelaar misschien onbewust lekken informatie van hun gebruikers vanwege bibliotheken ze gekoppeld inch Landmeetkundige het landschap die er zijn, te kijken naar alle verschillende apps die zijn gemeld in het nieuws als kwaadaardig of doen iets gebruikers niet wilde en vervolgens de inspectie van een heleboel apps-we doen veel statische binaire analyse van mobiele apps, dus we hebben hen gecontroleerd en gekeken naar de code zelf- kwamen we met wat we onze top 10 lijst van riskant gedrag in toepassingen noemen. En het is onderverdeeld in 2 delen, kwaadaardige code, dus dit zijn slechte dingen die de apps zou kunnen doen dat waarschijnlijk iets dat een kwaadwillend persoon te zijn is specifiek in het verzoekschrift, maar het is een beetje wazig. Het kan iets dat een ontwikkelaar denkt dat het wel goed, maar uiteindelijk wordt gezien als kwaadwillende door de gebruiker. En dan het tweede deel is wat wij noemen codering kwetsbaarheden, en dit zijn dingen waar de ontwikkelaar in principe is het maken van fouten of gewoon niet begrijpen hoe de app veilig schrijven,  en dat is de invoering van de app gebruiker in gevaar. Ik ga om te gaan door deze in detail en geeft enkele voorbeelden. Ter referentie, ik wilde de OWASP mobiele top 10 lijst te zetten. Dit zijn de 10 punten die een groep op OWASP, het Open Web Application Security Project, ze hebben een werkgroep werkt aan een mobiele top 10 lijst. Ze hebben een zeer bekende web top 10 lijst, wat zijn de top 10 meest risicovolle dingen die je kunt hebben in een webapplicatie. Ze doen hetzelfde voor mobiele, en hun lijst is een beetje anders dan de onze. 6 van de 10 zijn hetzelfde. Ze hebben 4 die anders zijn. Ik denk dat ze een beetje een andere kijk op risico's in mobiele apps, waar veel van hun problemen zijn echt hoe de applicatie communiceert naar een back-end server of wat er gaande is op de back-end server, niet zozeer apps die risicovol gedrag dat alleen maar rechttoe rechtaan client apps hebben. Degenen rood hier zijn de verschillen tussen de 2 lijsten. En sommige van mijn onderzoeksteam heeft daadwerkelijk bijgedragen aan dit project, dus we zullen zien wat er gebeurt in de tijd, maar ik denk dat de afhaalmaaltijd hier is we niet echt weten wat de top 10 lijst is in mobiele apps, omdat ze hebben eigenlijk alleen al nu 2 of 3 jaar, en er is niet genoeg tijd om echt de besturingssystemen onderzoek geweest en wat ze in staat zijn, en er is niet genoeg tijd geweest voor de kwaadaardige gemeenschap, als je wil, hebben genoeg tijd besteed proberen om gebruikers aan te vallen door middel van mobiele apps, dus ik verwacht dat deze lijsten om een ​​beetje te veranderen. Maar voor nu, dit zijn de top 10 dingen aan de hand. Je kunt je afvragen op de mobiele kant waar komt de kwaadaardige mobiele code- hoe werkt het op het apparaat? North Carolina State heeft een project genaamd de Mobile Malware Genome Project waar ze verzamelen van zo veel mobiele malware als ze kunnen en analyseren, en ze hebben de injectie vectoren die de mobiele malware maakt gebruik afgebroken, en 86% gebruik van een techniek genaamd herverpakking, en dit is alleen op het Android-platform kan je echt doen dit ompakken. De reden is Android-code is opgebouwd met een Java-bytecode genaamd Dalvik die gemakkelijk decompilable. Wat de slechte kerel kan doen is neem een ​​Android-applicatie, decompileren het, Steek hun kwaadaardige code, opnieuw compileren, en zet het dan in de app store ogenschijnlijk een nieuwe versie van die toepassing te zijn, of heel misschien veranderen van de naam van de toepassing. Als het was een soort van spel, verander de naam iets, en dus dit herverpakking is hoe 86% van de mobiele malware wordt verspreid. Er is nog een techniek genaamd-update die is zeer vergelijkbaar met ompakken, maar je eigenlijk niet de kwaadaardige code zet inch Wat je doet is je in een kleine updatemechanisme. Je decompileren, zet je in een update-mechanisme, en je het opnieuw compileren, en dan wanneer de app loopt het naar beneden trekt de malware op het apparaat. Veruit de meerderheid zijn die 2 technieken. Er is niet echt veel te downloaden drive-by's of drive-by downloads op mobiele telefoons, die zouden kunnen worden als een poging tot phishing. Hey, dan dit echt cool website, of je moet naar deze website en vul dit formulier in te houden voortdurende iets te doen. Die worden phishing-aanvallen. Hetzelfde kan gebeuren op het mobiele platform waar ze wijzen op een mobiele app te downloaden, zeggen: "Hoi, dit is Bank of America." "We zien dat je met behulp van deze applicatie." "U moet dit andere applicatie te downloaden." Theoretisch, dat zou kunnen werken. Misschien is het gewoon niet wordt genoeg gebruikt om te bepalen of het succesvol is of niet, maar zij vonden dat minder dan 1% van de tijd die techniek wordt gebruikt. Het merendeel van de tijd is het echt een omgepakt code. Er is nog een categorie genaamd standalone waar iemand net bouwt een gloednieuwe applicatie. Ze bouwen een applicatie die beweert iets te zijn. Het is niet een herverpakking van iets anders, en dat heeft de kwaadaardige code. Dat wordt gebruikt 14% van de tijd. Nu wil ik praten over wat er de kwaadaardige code aan het doen? Een van de eerste malware die er zijn kon je een spyware beschouwen. Het spionnen in principe op de gebruiker. Het verzamelt e-mails, sms-berichten. Het blijkt op de microfoon. Het oogsten van de lijst met contactpersonen, en stuurt het uit aan iemand anders. Deze vorm van spyware bestaat op de PC, dus is het volkomen logisch voor mensen om te proberen om dit te doen op mobiele apparaten. Een van de eerste voorbeelden van een programma genaamd Secret SMS Replicator. Het was in de Android Marketplace een paar jaar geleden, en het idee was als je toegang tot iemands Android telefoon had die je wilde bespioneren, dus misschien is het je partner of uw significante andere en je wilt bespioneren hun sms, je kan deze app downloaden en installeren en configureren om een ​​SMS-bericht te sturen naar je met een kopie van elk SMS-bericht dat ze kregen. Dit is uiteraard in schendingen van de app store termen van service, en deze werd verwijderd uit de Android Marketplace binnen 18 uur dat het er is, dus een zeer klein aantal mensen aan het risico als gevolg van deze. Nu, ik denk dat als het programma iets misschien een beetje minder provocerend heette zoals Secret SMS Replicator het waarschijnlijk zou hebben gewerkt een stuk beter. Maar het was me duidelijk. Een van de dingen die we kunnen doen om te bepalen of apps hebben dit gedrag dat we niet willen is de code te inspecteren. Dit is eigenlijk heel makkelijk te doen op Android, omdat we de apps kunnen decompileren. Op iOS kunt u een disassembler zoals IDA Pro gebruiken te kijken naar wat API's de app er belt en wat het doet. We schreven onze eigen binaire static analyzer voor onze code en we dit doen, en dus wat je zou kunnen doen is je zou kunnen zeggen doet het apparaat alles wat eigenlijk bespioneert me of het bijhouden van mij doen? En ik heb hier enkele voorbeelden op de iPhone. Dit eerste voorbeeld is hoe u de UUID aan de telefoon. Dit is eigenlijk iets dat Apple net heeft verboden voor nieuwe toepassingen, maar oude toepassingen die u zou kunnen hebben uitgevoerd op uw telefoon kan nog steeds dit te doen, en zo dat unieke id kan worden gebruikt om u op te sporen over vele verschillende toepassingen. Op de Android, ik heb hier op het krijgen van de locatie van het apparaat een voorbeeld. Je kunt zien dat als die API call is daar dat app is het volgen, en je kunt zien of het wordt steeds prima locatie of grof locatie. En dan op de bodem hier, ik heb een voorbeeld van hoe op de BlackBerry Een applicatie kan toegang krijgen tot de e-mailberichten in uw inbox. Dit zijn het soort dingen die je kunt controleren om te zien Als de app die dingen doet. De tweede grote categorie van kwaadaardig gedrag, en dit is waarschijnlijk de grootste categorie nu, is ongeoorloofd bellen, onbevoegde premium SMS-tekstberichten of ongeoorloofde betalingen. Een ander ding dat is er uniek aan de telefoon wordt het apparaat is aangesloten op een betaalrekening, en wanneer de activiteiten gebeuren op de telefoon het kan kosten maken. Je kunt dingen kopen via de telefoon, en als je een premium SMS-tekstbericht verzendt je eigenlijk het geven van geld aan de rekeninghouder van het telefoonnummer op de andere kant. Deze werden opgericht om aandelenkoersen te krijgen of krijg je dagelijkse horoscoop of andere dingen, maar ze kunnen worden ingesteld om een ​​product door een SMS verzenden bestellen. Mensen geven geld aan het Rode Kruis door het sturen van een SMS-bericht. U kunt $ 10 geven op die manier. De aanvallers, wat ze hebben gedaan is dat ze opgezet rekeningen in het buitenland, en ze verankeren in de malware dat de telefoon een premium sms-bericht sturen, zeggen, een paar keer per dag, en aan het eind van de maand je beseft dat je hebt besteed tientallen of misschien zelfs honderden dollars, en ze lopen weg met het geld. Dit werd zo erg dat dit het eerste ding dat de Android Marketplace of de Google-plaats-het was de Android Marketplace op het moment, en het is nu Google Play-het eerste ding dat Google begonnen met het controleren voor. Toen Google begon de distributie van Android apps in hun app store ze zeiden dat ze waren niet van plan om te controleren op alles. We zullen apps trekken als we zijn op de hoogte hebben ze onze termen van service gebroken, maar we gaan niet om te controleren op alles. Nou, ongeveer een jaar geleden werd het zo slecht met deze premium SMS tekstbericht malware dat dit het allereerste wat ze begonnen met het controleren voor. Als een app SMS-berichten kunt verzenden ze verder handmatig onderzoeken die toepassing. Ze zoeken naar de API's die dit roepen, en nu sindsdien Google heeft uitgebreid, maar dit was het eerste ding dat ze op zoek gegaan naar. Enkele andere apps die sommige sms-berichten deed, deze Android Qicsomos, ik denk dat het heet. Er was een actuele gebeurtenis op de mobiele telefoon, waar dit CarrierIQ kwam als spyware zetten op het apparaat door de vervoerders, dus mensen wilden weten of hun telefoon was kwetsbaar voor dit, en dit was een gratis app die dat getest. Nou ja, natuurlijk, wat deze app deed was het verzond premium SMS-tekstberichten, dus door het testen om te zien of je besmet met spyware u hebt geladen malware op uw apparaat. We zagen hetzelfde gebeuren bij de laatste Super Bowl. Er was een nep-versie van de Madden voetbalwedstrijd dat premium sms-berichten verzonden. Het eigenlijk geprobeerd om een ​​botnet te maken op het apparaat. Hier heb ik een aantal voorbeelden. Interessant genoeg, Apple was behoorlijk slim, en zij niet toestaan ​​dat toepassingen van SMS-berichten versturen op alle. Geen app kan het doen. Dat is een geweldige manier van het wegwerken van een hele klasse van kwetsbaarheid, maar op Android je kunt het doen, en natuurlijk, op BlackBerry je kunt het ook doen. Het is interessant dat op de BlackBerry alles wat je nodig hebt is internet permissies om een ​​SMS-bericht te verzenden. Het andere ding echt dat we op zoek naar toen we op zoek om te zien of er iets is kwaadaardig is gewoon een soort van ongeautoriseerde netwerkactiviteit, zoals kijken naar de netwerkactiviteit de app wordt verondersteld te hebben om de functionaliteit te hebben, en kijken naar deze andere netwerkactiviteit. Misschien een app, om te werken, heeft om gegevens via HTTP, maar als het om dingen te doen via e-mail of SMS of Bluetooth of iets dergelijks nu die app kan mogelijk schadelijke zijn, dus dit is een ander ding dat je kunt inspecteren. En op deze dia hier heb ik een aantal voorbeelden van. Een ander interessant wat we zagen met malware gebeurde terug in 2009, en het gebeurde in een grote weg. Ik weet niet of het zo veel is er sindsdien gebeurd, maar het was een app dat vertolkt een andere toepassing. Er was een set van apps, en het werd de 09Droid aanval nagesynchroniseerd, en iemand besloten dat er een heleboel kleine, regionale, middelgrote banken dat niet online banking toepassingen hebben, dus wat ze deden was ze gebouwd ongeveer 50 online banking toepassingen dat alles wat ze deed was de gebruikersnaam en het wachtwoord en u naar de website. En dus zetten ze deze allemaal in de Google Marketplace, in de Android Marketplace, en wanneer iemand zocht om te zien of hun bank had een applicatie die zij zouden de valse toepassing te vinden, die hun geloofsbrieven verzameld en vervolgens doorgestuurd ze naar hun website. De manier waarop dit eigenlijk werd-de apps waren daar voor een paar weken, en er waren duizenden en duizenden downloads. De manier waarop dit aan het licht kwam was iemand had een probleem met een van de toepassingen, en ze noemden hun bank, en zij noemden hun bank customer support lijn en zei: "Ik heb een probleem met uw mobiel bankieren applicatie." "Kun je me helpen?" En ze zeiden: "Wij hebben geen mobiel bankieren applicatie." Dat begon het onderzoek. Die bank genaamd Google, en dan is Google keek en zei: "Wow, heeft dezelfde auteur 50 bankapplicaties geschreven," en nam ze allemaal neer. Maar zeker kan dit weer gebeuren. Er is de lijst van alle verschillende banken hier die deel uitmaakten van deze oplichterij. Het andere wat een app kan doen is aanwezig de UI van een andere toepassing. Terwijl het draait kan het opduiken van de Facebook-UI. Het zegt u in uw gebruikersnaam en wachtwoord in te zetten om verder te gaan of opgemaakt welke gebruikersnaam en wachtwoord UI voor een website dat misschien de gebruiker gebruikt gewoon om te proberen om de gebruiker te misleiden in zetten hun geloofsbrieven inch Dit is echt een rechte parallel van de e-mail phishing-aanvallen waar iemand stuurt u een e-mailbericht en geeft je eigenlijk een nep-UI voor een website dat heeft u toegang tot. Het andere wat we zoeken in kwaadaardige code is systeem modificatie. U kunt kijken naar alle API-aanroepen die root-rechten nodig te kunnen voeren. Het veranderen van het apparaat web proxy zou iets dat een aanvraag worden zou niet in staat zijn om te doen. Maar als de applicatie code daar om dat te doen je weet dat het waarschijnlijk een kwaadaardige toepassing of zeer zeer waarschijnlijk een kwaadaardige toepassing zijn, en dus wat er zou gebeuren, is dat app of andere manier van escalerende privilege zou hebben. Het zou wat privilegebreuk exploiteren in de aanvraag, en dan een keer het hogere privileges het zou deze systeem wijzigingen aan te doen. U kunt malware dat voorrecht escalatie is te vinden in het zelfs zonder te weten hoe het privilege escalatie exploit gaat gebeuren, en dat is een leuke, eenvoudige manier om te zoeken naar malware. DroidDream was waarschijnlijk het beroemdste stuk van de Android-malware. Ik denk dat het getroffen ongeveer 250.000 gebruikers over een paar dagen voordat het werd gevonden. Ze herverpakt 50 nep-toepassingen, zet ze in de Android app store, en in wezen het gebruikt Android jailbreak code privileges te verhogen en installeer vervolgens een commando en controle en draai alle slachtoffers in een botnet, maar je zou kunnen hebben dit ontdekt als je het scannen van de toepassing en gewoon op zoek naar API-aanroepen die vereist root rechten te kunnen voeren. En er is hier een voorbeeld heb ik dat het veranderen van de proxy, en dit ook daadwerkelijk is alleen beschikbaar op de Android. U kunt zien Ik geef je een heleboel voorbeelden op Android want dit is waar de meest actieve malware ecosysteem want het is echt makkelijk voor een aanvaller kwaadaardige code krijgen in de Android Marketplace. Het is niet zo gemakkelijk om dat te doen in de Apple App Store omdat Apple vraagt ​​ontwikkelaars om zich te identificeren en ondertekenen van de code. Zij controleren eigenlijk wie je bent, en Apple is eigenlijk het onderzoek van de aanvragen. We zien niet veel echte malware waar het apparaat wordt steeds aangetast. Ik zal praten over een aantal voorbeelden waar het echt privacy dat het krijgen is gecompromitteerd, en dat is wat er echt gebeurt op het Apple-apparaat. Een ander ding om te zoeken naar kwaadaardige code, riskant code in apparaten is logica of tijdbommen, en tijdbommen zijn waarschijnlijk veel gemakkelijker om te zoeken naar dan logische bommen. Maar met tijdbommen, wat je kunt doen is je kunt zoeken naar plaatsen in de code waar de tijd wordt getest of een absolute tijd wordt gezocht naar voor bepaalde functionaliteit in de app gebeurt. En dit kan worden gedaan om die activiteit te verbergen voor de gebruiker, dus het gebeurt 's avonds laat. DroidDream deed al haar activiteiten 11:00-08:00 lokale tijd om te proberen om het te doen, terwijl de gebruiker niet kan worden met behulp van hun apparaat. Een andere reden om dit te doen is als mensen gebruiken gedragsanalyse van een aanvraag, het uitvoeren van de app in een zandbak te zien wat het gedrag van de applicatie is, kunnen ze op tijd gebaseerde logica gebruiken om de activiteit te doen wanneer de app niet in de zandbak. Bijvoorbeeld, een app store zoals Apple loopt de applicatie, maar ze waarschijnlijk niet elke toepassing voor lopen, zeg, 30 dagen alvorens deze goed te keuren, zodat je logica in je applicatie die zei, oke, alleen de slechte zaak na 30 dagen voorbij is of na 30 dagen na de datum van publicatie van de aanvraag, en dat kan de kwaadaardige code verberg helpen van mensen die de inspectie voor. Als anti-virus bedrijven actief zijn dingen in zandbakken of de app stores zelf dit kan helpen verbergen dat van die inspectie. Nu, de keerzijde van dat is het gemakkelijk te vinden met statische analyse, dus eigenlijk het inspecteren van de code kunt u zoeken naar alle plaatsen indien de aanvraag toetst de tijd en te inspecteren op die manier. En hier heb ik een aantal voorbeelden van deze 3 verschillende platformen hoe de tijd kan worden gecontroleerd door de app maker zodat u weet wat te zoeken als je het inspecteren van de app statisch. Ik heb net een hele hoop verschillende kwaadaardige activiteiten die we hebben gezien in het wild, maar welke zijn de meest voorkomende? Diezelfde studie van de North Carolina State Mobile Genome Project publiceerde een aantal gegevens, en er waren eigenlijk 4 gebieden dat zij zagen waar er veel activiteit. 37% van de apps deden privilege escalatie, dus ze hadden een soort van jailbreak code daar waar ze probeerden hun privileges te verhogen, zodat ze konden denk API commando's uitgevoerd als het besturingssysteem. 45% van de apps die er zijn gedaan premium SMS, dus dat is een enorm percentage dat probeert om direct geld te verdienen. 93% deed afstandsbediening, dus probeerden ze het opzetten van een botnet, een mobiel botnet. En 45% geoogst identificerende informatie zoals telefoonnummers, UUID's, GPS-locatie, gebruikersaccounts, en dit komt neer op meer dan 100, omdat de meeste malware probeert om een ​​paar van deze dingen te doen. Ik ga om te schakelen naar de tweede helft en praten over de code kwetsbaarheden. Dit is de tweede helft van de risicovolle activiteit. Hier hoofdzaak de ontwikkelaar maakt fouten. Een legitieme ontwikkelaar schrijven van een legitieme app is het maken van fouten of onwetend is over de risico's van het mobiele platform. Ze weten niet precies hoe ze een veilige mobiele app te maken, of soms de ontwikkelaar niet de zorg over het zetten van de gebruiker in gevaar. Soms wordt een deel van hun business model zou kunnen zijn oogsten van persoonlijke informatie van de gebruiker. Dat is een soort van de andere categorie, en dat is waarom sommige van deze schadelijke versus legitieme begint over te bloeden omdat er verschil van mening tussen wat de gebruiker wil en wat de gebruiker risicovol beschouwt en wat de applicatie ontwikkelaar riskant acht. Natuurlijk, het is niet de gegevens van de applicatie ontwikkelaar in de meeste gevallen. En dan tot slot, een andere manier waarop dit gebeurt is een ontwikkelaar zou kunnen koppelen in een gedeelde bibliotheek die kwetsbaarheden of dit risicovol gedrag in zich heeft buiten het medeweten van hen. De eerste categorie is gevoelige gegevens lekken, en dit is wanneer de app verzamelt informatie zoals locatie, adresboek informatie, eigenaar informatie en stuurt dat het toestel uit. En als het eenmaal uit het apparaat, weten we niet wat er met die informatie. Het kan onveilig worden opgeslagen door de applicatie ontwikkelaar. We hebben gezien applicatieontwikkelaars gekraakt en de gegevens die ze opslaan krijgt genomen. Dit gebeurde een paar maanden geleden aan een ontwikkelaar in Florida waar een groot aantal van-het was iPad UUIDs en namen apparaat waren uitgelekt omdat iemand, ik denk dat het anoniem was, beweerd om dit te doen, brak in de servers van deze ontwikkelaar en stal miljoenen iPad UUID en computer namen. Niet de meest risicovolle informatie, maar wat als dat was de opslag van gebruikersnamen en wachtwoorden en prive-adressen? Er zijn veel apps die dat soort informatie op te slaan. Het risico is er. Het andere ding dat kan gebeuren is als de ontwikkelaar niet verzorgen om het datakanaal te beveiligen, en dat is nog een grote kwetsbaarheid Ik ga om te praten over, dat gegevens worden verzonden in de heldere. Als de gebruiker op een openbare Wi-Fi-netwerk of iemand snuiven internet ergens langs het pad dat gegevens worden blootgesteld. Een zeer beroemde geval van deze lekken van informatie gebeurde met Pandora, en dit is iets wat we onderzocht bij Veracode. We hoorden dat er een-ik denk dat het een Federal Trade Commission was onderzoek aan de hand met Pandora. Wij zeiden: "Wat is er aan? Laten we beginnen graven in de Pandora-toepassing." En wat we vastbesloten was de Pandora toepassing verzameld uw geslacht en uw leeftijd, en het is ook toegankelijk uw GPS-locatie, en de Pandora toepassing deed dit voor wat ze zeiden waren legitieme redenen. De muziek die ze speelden-Pandora is een muziek streaming app- de muziek die ze speelden was slechts een licentie in de Verenigde Staten, dus moesten ze controleren om te voldoen aan hun licentieovereenkomsten die ze hadden de muziek die de gebruiker was in de Verenigde Staten. Ze wilden ook voldoen aan de ouderlijke adviserende rond volwassen taal in de muziek, en dus het is een vrijwillig programma, maar ze wilden om te voldoen aan die en niet expliciete teksten spelen om kinderen van 13 jaar en jonger. Ze hadden legitieme redenen voor het verzamelen van deze gegevens. Hun app had de rechten om het te doen. Gebruikers dacht dat dit legitiem was. Maar wat is er gebeurd? Zij verbonden in 3 of 4 verschillende ad bibliotheken. Nu ineens al deze advertentie bibliotheken krijgen toegang tot dezelfde gegevens. De advertentie bibliotheken, als je kijkt naar de code in de advertentie bibliotheken wat ze doen is elke advertentie bibliotheek zegt "Heeft mijn app hebt toestemming om GPS-locatie te krijgen?" "Oh, het doet? Oke, vertel me de GPS-locatie." Elke advertentie bibliotheek doet dat, en als de app niet GPS toestemming hebben het zal niet in staat zijn om het te krijgen, maar als dat zo is, zal het krijgen. Dit is waar het business model van de advertentie bibliotheken is tegen de privacy van de gebruiker. En er is al studies die er zijn die zal zeggen als je weet dat de leeftijd van een persoon en je weet hun locatie waar ze slapen 's nachts, omdat je hun GPS coördinaten terwijl ze misschien slaapt, weet je precies wie die persoon is want je kunt bepalen welk lid van dat huishouden is die persoon. Echt dit is het identificeren aan adverteerders precies wie je bent, en het lijkt erop dat het legitiem was. Ik wil gewoon mijn streaming muziek, en dit is de enige manier om het te krijgen. Nou, we blootgesteld dit. We schreven dit op in een aantal blog posts, en het bleek dat iemand van Rolling Stone magazine lees een van onze blog posts en schreef hun eigen blog in Rolling Stone over, en de volgende dag Pandora vond het een goed idee om de advertentie bibliotheken van hun toepassing te verwijderen. Voor zover ik weet dat ze het enige dat ze moeten worden geprezen. Ik denk dat ze de enige freemium soort app die dit heeft gedaan. Alle andere freemium apps hebben dit zelfde gedrag, dus je hebt om na te denken over wat voor soort data je geeft deze freemium applicaties omdat het allemaal aan adverteerders. Praetorian deed ook een studie over gedeelde bibliotheken en zei: "Laten we eens kijken naar wat gedeelde bibliotheken zijn de top gedeelde bibliotheken," en dit was de gegevens. Zij analyseerden 53.000 apps, en de nummer 1 gedeelde bibliotheek was Admob. Het was eigenlijk in 38% van de toepassingen die er zijn, dus 38% van de applicaties die u gebruikt waarschijnlijk oogsten uw persoonlijke gegevens en op te sturen naar de advertentienetwerken. Apache en Android waren 8% en 6%, en dan zijn deze andere die op de bodem, Google Ads, Flurry, Mob City en Duizendjarige Media, dit zijn allemaal ad bedrijven, en dan, interessant genoeg, 4% gekoppeld aan de Facebook bibliotheek waarschijnlijk te doen authenticatie via Facebook zodat de app kan de Facebook authenticeren. Maar dat betekent ook dat de corporatie Facebook controleert code dat draait in 4% van de Android mobiele apps die er zijn, en hebben ze toegang tot alle gegevens die die app heeft toestemming om te komen. Facebook probeert in wezen om advertentieruimte te verkopen. Dat is hun business model. Als je kijkt naar dit hele ecosysteem met deze machtigingen en gedeelde bibliotheken je begint te zien dat je hebt een veel risico in een zogenaamd legitieme toepassing. Dezelfde vergelijkbaar wat er gebeurde met Pandora gebeurde met een applicatie genaamd Path, en Path dachten dat ze zijn behulpzaam, vriendelijk ontwikkelaars. Ze waren gewoon proberen om u een geweldige gebruikerservaring, en het bleek dat zonder dat de gebruiker of het vertellen van de gebruiker iets- en dit gebeurde op de iPhone en op Android, de Pandora app was op de iPhone en Android- dat het Pad applicatie is grijpen je hele adresboek en uploaden net wanneer je geïnstalleerd en liep de toepassing op pad, en ze je niet vertellen over deze. Ze vond het echt nuttig voor u te kunnen delen met alle mensen in uw adresboek dat u gebruikt het Pad applicatie. Nou, natuurlijk Path dacht dat dit was geweldig voor hun bedrijf. Niet zo geweldig voor de gebruiker. Je moet denken dat het een ding of misschien een tiener wordt met behulp van deze applicatie en hun tientallen vrienden zijn daar, maar wat als het de CEO van een bedrijf dat Pad installeert en dan ineens hun hele adresboek is daar? Je gaat veel potentieel waardevolle contact informatie te krijgen voor een heleboel mensen. Een verslaggever van de New York Times, kunt u mogelijk om het telefoonnummer te krijgen voor ex-presidenten uit hun adresboek, dus natuurlijk een heleboel gevoelige informatie wordt overgedragen met iets als dit. Er was zo'n grote flap over dit dat Path verontschuldigde. Ze veranderden hun app, en zelfs beïnvloed Apple. Apple zei: "We gaan naar app-leveranciers te dwingen om gebruikers vragen als ze gaan om hun hele adresboek te verzamelen. " Het lijkt erop dat wat hier gebeurt is als er een grote schending van de privacy en het maakt de pers zien we een verandering die er zijn. Maar natuurlijk, er zijn andere dingen die er zijn. De LinkedIn applicatie oogsten uw agenda-items, maar Apple maakt niet de gebruiker gevraagd over. Agenda-items kan gevoelige informatie te hebben in hen. Waar ga je de grens? Dit is echt een soort van een zich ontwikkelende plaats waar er is echt geen goede standaard die er zijn voor de gebruikers om te begrijpen wanneer hun informatie zal worden in gevaar en wanneer ze gaan om te weten dat het wordt genomen. We schreven een app op Veracode genaamd Adios, en in wezen het staat je toe om de app te wijzen op je iTunes-map en kijken naar alle toepassingen die werden oogsten uw volledige adresboek. En zoals je hier kunt zien op deze lijst, Angry Birds, AIM, AroundMe. Waarom heeft Angry Birds uw adresboek nodig? Ik weet het niet, maar het doet een of andere manier. Dit is iets dat vele, vele toepassingen doen. U kunt de code inspecteren voor. Er is goed gedefinieerde API's voor iPhone, Android en BlackBerry te krijgen op het adresboek. Je kunt echt gemakkelijk te inspecteren voor dit, en dit is wat we deden in onze Adios toepassing. De volgende categorie, Onveilige Sensitive Data Storage, is iets waar ontwikkelaars nemen iets als een pen of een rekeningnummer of een wachtwoord en bewaar het op de duidelijke op het apparaat. Erger nog, ze kunnen het op te slaan in een gebied aan de telefoon die wereldwijd toegankelijk is, net als de SD-kaart. Je ziet dit vaker op Android omdat Android zorgt voor een SD-kaart. IPhone-apparaten niet. Maar we zagen zelfs dit gebeuren in een CitiGroup toepassing. Hun online banking toepassing opgeslagen rekeningnummers onveilig, gewoon in de heldere, dus als u uw apparaat verloren, wezen u uw bankrekening verloren. Dit is de reden waarom ik persoonlijk niet bankieren op mijn iPhone. Ik denk dat het te riskant is nu om dit soort activiteiten te doen. Skype deed hetzelfde. Skype, natuurlijk, heeft een rekening van de betalingsbalans, een gebruikersnaam en wachtwoord die toegang hebben tot dat evenwicht. Ze waren al die informatie in het heldere op het mobiele apparaat op te slaan. Ik heb hier enkele voorbeelden van het creëren van bestanden dat niet de juiste machtigingen of schrijven naar schijf en niet met een of encryptie gebeuren voor dat. Dit volgende gebied, Onveilige gevoelige datatransmissie, Ik heb een paar keer gezinspeeld op deze, en vanwege openbare Wi-Fi dit is iets dat apps absoluut nodig om te doen, en dit is waarschijnlijk wat we zien mis het meest gaan. Ik zou zeggen-eigenlijk, ik denk dat ik de feitelijke gegevens, maar het is bijna de helft van de mobiele toepassingen verpesten doet SSL. Ze gewoon niet goed gebruik maken van de API's. Ik bedoel, alles wat je hebt te doen is volg de instructies en gebruik de API's, maar ze doen dingen als niet te controleren of er een ongeldig certificaat aan de andere kant, niet te controleren of de andere kant probeert een protocol downgrade aanval doen. De ontwikkelaars, ze willen hun checkbox krijgen, toch? Hun eis is om dit te gebruiken om te verkopen. Ze hebben dit gebruikt om te verkopen. De eis is niet om dit te gebruiken om veilig te verkopen, en dus dit is de reden waarom alle applicaties die SSL gebruiken om gegevens te beveiligen wanneer hij wordt overgebracht uit het apparaat echt moeten worden geïnspecteerd om ervoor te zorgen dat correct is geïmplementeerd. En hier heb ik een aantal voorbeelden waar u een aanvraag kunt zien zou kunnen worden met behulp van HTTP in plaats van HTTPS. In sommige gevallen zullen apps terugvallen op HTTP als het HTTPS niet werkt. Ik heb nog een oproep hier op Android, waar ze het certificaat controle hebt uitgeschakeld, dus een man-in-the-middle-aanval kan gebeuren. Een ongeldig certificaat worden geaccepteerd. Dit zijn alle gevallen waarin aanvallers zullen kunnen aan de slag hetzelfde Wi-Fi-verbinding als de gebruiker en de toegang van alle gegevens dat wordt verzonden via internet. En tenslotte, de laatste categorie die ik hier heb is hardcoded wachtwoord en sleutels. Zien we in feite een veel ontwikkelaars maken gebruik van dezelfde stijl van coderen dat ze deden toen ze werden het bouwen van web-server applicaties, zodat ze het bouwen van een Java-server applicatie, en ze zijn hardcoding de sleutel. Nou, als je het bouwen van een server applicatie, ja, hardcoding de sleutel is geen goed idee. Het maakt het moeilijk te veranderen. Maar het is niet zo slecht op de server omdat die toegang heeft tot de server kant heeft? Alleen de beheerders. Maar als je dezelfde code nemen en je het uitgegoten over een mobiele toepassing nu iedereen die dat mobiele app heeft toegang tot die hardcoded sleutel, en we eigenlijk zien dit een hoop tijd, en ik heb een aantal statistieken op hoe vaak we dit zien gebeuren. Het eigenlijk was in voorbeeld code die MasterCard gepubliceerd over hoe ze hun service te gebruiken. Het voorbeeld code liet zien hoe je gewoon het wachtwoord zou nemen en zet het in een hardcoded touwtje daar, en we weten hoe de ontwikkelaars graag kopiëren en plakken code snippets wanneer ze proberen om iets te doen, dus je kopieer en plak de code snippet dat zij gaven als voorbeeld code, en je een onzekere applicatie. En hier hebben we een aantal voorbeelden. Deze eerste is een zien we veel waar ze hardcoden de gegevens recht in een URL die wordt verstuurd. Soms zien we snaar password = het wachtwoord. Dat is vrij gemakkelijk op te sporen, of touwtje wachtwoord op de BlackBerry en Android. Het is eigenlijk vrij eenvoudig te controleren omdat bijna altijd de ontwikkelaar namen de variabele die houdt het wachtwoord een variant van het wachtwoord. Ik heb gezegd dat we doen statische analyse op Veracode, dus we hebben enkele honderden Android en iOS applicaties geanalyseerd. We hebben gebouwd vol modellen van hen, en we zijn in staat om ze te scannen voor verschillende kwetsbaarheden, vooral de kwetsbaarheden ik het over had, en ik heb een aantal gegevens hier. 68,5% van de Android-apps hebben we gekeken naar had cryptografische code gebroken, die voor ons, kunnen we niet ontdekken als je je eigen crypto routine gemaakt, niet dat dat een goed idee, maar dit is eigenlijk het gebruik van de gepubliceerde API die op het platform, maar doen ze zodanig dat de crypto kwetsbaar zou zijn, 68,5. En dit is voor mensen die ons daadwerkelijk sturen hun toepassingen, omdat ze denken dat het een goed idee om de beveiliging testen te doen. Deze zijn al mensen die waarschijnlijk goed zijn denken, dus het is waarschijnlijk nog erger. Ik heb het niet over controle line feed injectie. Het is iets wat we controleren voor, maar het is niet zo riskant probleem. Lekken van informatie, dit is waar gevoelige gegevens worden verzonden van het apparaat af. We vonden dat in 40% van de aanvragen. Tijd en staat, dat zijn ras staat Type kwesties, meestal vrij moeilijk te exploiteren, zodat ik niet over praten, maar we keken naar het. 23% had een SQL-injectie problemen. Veel mensen weten niet dat veel applicaties Gebruik een klein beetje SQL-database op hun back-end om gegevens op te slaan. Nou, als de gegevens die je grijpen via het netwerk heeft SQL-injectie aanval strings in het iemand kan het apparaat in gevaar brengen door die, en dus ik denk dat we ongeveer 40% van web applicaties hebben dit probleem, dat is een enorme epidemie probleem. We vinden het 23% van de tijd in mobiele apps en dat is waarschijnlijk omdat er veel meer web-applicaties te gebruiken SQL dan mobiel. En dan zien we nog steeds een aantal cross-site scripting, kwesties machtiging, en dan credential management, dat is waar je je hardcoded wachtwoord. In 5% van de aanvragen zien we dat. En dan hebben we een aantal gegevens op iOS. 81% had foutafhandeling kwesties. Dit is meer een code kwaliteitsprobleem, maar 67% had cryptografische problemen, dus het is niet zo slecht als Android. Misschien is de API's zijn een beetje makkelijker, het voorbeeld codes een beetje beter op iOS. Maar nog steeds een zeer hoog percentage. We hadden 54% met het lekken van informatie, ongeveer 30% met buffer beheer fouten. Dat is op plaatsen waar er potentieel poolbeschadiging zou kunnen zijn. Het blijkt dat dat niet zo veel van een probleem voor de exploitatie op iOS omdat alle code moet worden ondertekend, dus het is moeilijk voor een aanvaller om willekeurige code uit te voeren op iOS. Kwaliteit van de code, directory traversal, maar dan geloofsbrieven beheer hier op 14,6%, dus erger dan op de Android. We hebben mensen niet de correcte afhandeling van wachtwoorden. En dan is de numerieke fouten en buffer overflow, die zijn meer gaan code kwaliteitsproblemen op iOS zijn. Dat was het voor mijn presentatie. Ik weet niet of we hebben geen tijd of niet. Ik weet niet of er vragen zijn. [Mannelijk] Een snelle vraag rond fragmentatie en de Android market. Apple tenminste bezit patchen. Ze doen een goede baan van het krijgen van het daar terwijl minder in de Android ruimte. Je moet bijna op je telefoon jailbreaken om bij te blijven met de huidige versie van Android. Ja, dat is een groot probleem en dus als u denkt over- [Mannelijk] Waarom kan je het niet herhalen? Oh, rechts, dus de vraag was wat over fragmentatie van het besturingssysteem op het Android-platform? Hoe beïnvloedt dat de risico's van deze apparaten? En het is eigenlijk een groot probleem, want wat er gebeurt is de oudere apparaten, wanneer iemand komt met een jailbreak voor dat apparaat, wezen dat privilege escalatie, en totdat dat besturingssysteem wordt bijgewerkt alle malware kunt vervolgens dat kwetsbaarheid voor volledig afbreuk doen aan de inrichting, en wat we zien op de Android is om een ​​nieuw besturingssysteem te krijgen Google heeft het besturingssysteem uit te zetten, en vervolgens de hardwarefabrikant heeft om het aan te passen, en vervolgens de vervoerder aan te passen en leveren het. Je eigenlijk 3 bewegende delen hier, en het is draaien dat de dragers niet schelen, en de hardware fabrikanten niet schelen, en Google is ze niet genoeg porren om iets te doen, dus in wezen meer dan de helft van de apparaten die er hebben besturingssystemen die deze escalatieprobleem kwetsbaarheden in zich hebben, en dus als je malware op je Android-toestel is het veel meer een probleem. Oke, heel erg bedankt. [Applaus] [CS50.TV]