[Seminar] [Defending Bag Device: Mobile Application Security] [Chris Wysopal] [Harvard University] [Dette er CS50.] [CS50.TV] God eftermiddag. Mit navn er Chris Wysopal. Jeg er CTO og medstifter af Veracode. Veracode er et program vagtselskab. Vi tester alle mulige forskellige applikationer, og hvad jeg har tænkt mig at tale om i dag, er mobil anvendelse sikkerhed. Min baggrund er jeg har gjort sikkerhedsforskning for en meget lang tid, sandsynligvis omkring så længe nogen. Jeg startede i midten af ​​90'erne, og det var en tid, der var temmelig interessant, fordi vi havde et paradigmeskift i midten af ​​90'erne. Pludselig alles computer blev hooked op til internettet, og derefter havde vi begyndelsen af ​​web-applikationer, og det er hvad jeg fokuserer på en masse derefter. Det er interessant. Nu har vi en anden paradigmeskift sker med computing, der er skiftet til mobile applikationer. Jeg føler, det er lidt af en lignende tid, så det var i slutningen af ​​90'erne når vi undersøger web-applikationer og finde fejl som session management fejl og SQL injection som virkelig ikke eksisterede før, og pludselig var de overalt i web-applikationer, og nu en masse af den tid, jeg tilbringer ser på mobile applikationer og ser på, hvad der foregår derude i naturen. Mobile applikationer er virkelig kommer til at være den dominerende computing-platform, så vi har virkelig brug for at bruge en masse tid, hvis du er i sikkerhed industrien med fokus på web-applikationer. Der var 29 mia mobile apps hentet i 2011. Det er forudsagt til at være 76 mia apps i 2014. Der er 686 millioner enheder, der vil blive købt i år, så dette er, hvor folk kommer til at gøre  størstedelen af ​​deres klient computing går fremad. Jeg talte med en vicedirektør hos Fidelity Investments et par måneder siden, og han sagde, at de så bare mere trafik gøre finansielle transaktioner fra deres kundegrundlag på deres mobil applikation end på deres hjemmeside, så en fælles brug for internettet i fortiden har været kontrollere dine aktiekurser, styre din portefølje, og vi faktisk se, at i 2012 skifte over at være mere dominerende på den mobile platform. Bestemt, hvis der kommer til at være nogen kriminel aktivitet, ondsindet aktivitet, går det til at begynde at være fokuseret på den mobile platform over tid, da folk skifte over til det. Hvis man ser på den mobile platform, til at se på de risici af platformen er det nyttigt at bryde det ned i de forskellige lag, ligesom du ville gøre det på en stationær computer, og du synes om de forskellige lag, software, operativsystem, netværksdel, hardware lag, og selvfølgelig er der sårbarheder på alle disse lag. Det samme sker på mobilen. Men mobil, ser det ud til, at nogle af disse lag er værre. For én, netværkslaget er mere problematisk på mobil fordi en masse mennesker har i deres kontor eller derhjemme kablede forbindelser, eller de har sikre Wi-Fi-forbindelser, og med en masse af mobile enheder, du er tydeligvis uden for hjemmet eller uden for kontoret en masse, og hvis du bruger Wi-Fi der du bruger måske en usikker Wi-Fi-forbindelse, noget, der er et offentligt Wi-Fi-forbindelse, så når vi tænker på mobile apps, vi er nødt til at tage hensyn til at netværket miljø er mere risikofyldte for de anvendelser når Wi-Fi bliver brugt. Og når jeg kommer ind i flere af de mobile applikationsudviklere risici du vil se, hvorfor det er mere vigtigt. Der er risici på hardware-niveau på mobile enheder. Dette er et område af igangværende forskning. Folk kalder disse bredbånd angreb eller baseband-angreb hvor du angribe firmware, der lytter på radioen. Det er virkelig skræmmende angreb, fordi brugeren behøver ikke at gøre noget. Du kan ramme masser af enheder inden for RF-dækningsområde på én gang, og det ser ud som, når denne forskning bobler op det hurtigt bliver klassificeret hvor folk razzia i rundt og sige: "Her, fortæl os om det, og du stoppe med at tale om det." Der er nogle forskning foregår på bredbåndsområdet, men det synes at være meget tys tys. Jeg synes det er mere af en nationalstat type forskning, der foregår. Et område af aktiv forskning, selv om, er operativsystemet lag, og igen, dette er anderledes end i desktopteknologien verden fordi i det mobile rum du har disse hold af mennesker kaldet jailbreakers, og jailbreakers er anderledes end almindelige sårbarhed forskere. De prøver at finde sårbarheder i operativsystemet, men grunden til at de prøver at finde sårbarhederne er ikke at bryde ind i en andens maskine og kompromittere den. Det er at bryde ind i deres egen computer. De ønsker at bryde ind i deres egen mobil, ændre deres egen mobil operativsystem så de kan køre applikationer i deres valg og ændre tingene med fuld administratorrettigheder, og de ønsker ikke at fortælle sælgeren om dette. De er ikke som en sikkerhedsekspert, der er en hvid hat sikkerhed forsker som kommer til at gøre ansvarlig afsløring og fortælle sælgeren om det. De ønsker at gøre denne forskning, og de ønsker at rent faktisk udgive det i en udnytte eller et rootkit eller en jailbreak kode, og de ønsker at gøre det strategisk, ligesom lige efter de sælger skibe nye operativsystem. Du har denne modsætningsforhold med OS-niveau sårbarheder på mobile, som jeg synes er ganske interessant, og ét sted, vi ser det Det gør det så, at der er god offentliggjort exploit-kode derude for kernel-niveau sårbarheder, og vi har set dem, der faktisk bruges af malware-forfattere. Det er en lille smule anderledes end pc-verdenen. Og derefter sidste lag er det øverste lag, applikationslaget. Det er hvad jeg har tænkt mig at tale om i dag. De andre lag findes, og de andre lag spiller ind i det, men jeg for det meste kommer til at snakke om, hvad der foregår i applikationslaget hvor koden kører i sandkassen. Det har ikke administratorrettigheder. Det at anvende API af anordningen, men alligevel kan en masse ondsindet aktivitet og en masse risiko sker på dette lag fordi det er det lag, hvor alle oplysninger er. Apps kan få adgang til alle oplysninger om enheden hvis de har de rette tilladelser, og de kan få adgang til de forskellige sensorer på enheden, GPS-sensor, mikrofon, kamera, hvad har du. Selvom vi kun taler om i applikationslaget vi har en masse risiko der. Den anden ting, der er anderledes ved det mobile miljø er alle operativsystemet spillere, det være sig BlackBerry eller Android eller iOS eller Windows mobile, de alle har en finkornet tilladelse model, og dette er en af ​​de måder, som de er indbygget i operativsystemet tanken om, at det ikke er så risikabelt, som du tror. Selvom du har alle dine kontakter på der, alle dine personlige oplysninger, du har dine billeder, du har din placering på der, du opbevare din bank pin for auto login på der, er det sikkert, fordi apps er nødt til at have visse tilladelser til at få ram på visse dele af oplysningerne på enheden, og brugeren har til at blive præsenteret for disse tilladelser og sige okay. Problemet med det er brugerens siger altid okay. Som en sikkerhed person, jeg ved, du kan bede brugeren, sige noget virkelig slemt kommer til at ske, vil du have det til at ske? Og hvis de er i et kapløb, eller der er noget virkelig lokkende på den anden side af det, ligesom et spil vil blive installeret, at de har ventet på, de kommer til at klikke okay. Det er derfor, jeg siger på min slide her bare lad mig slynge fugle på svin, som allerede, og du kan se på diaset her er der eksempler på en BlackBerry tilladelse kassen. Det siger "Indtast venligst ansøgning tilladelser BlackBerry rejse efter at have klikket på knappen nedenfor ", og dybest set brugeren er bare at sige indstille tilladelser og gemme. Her er en Android prompt, hvor det viser tingene, og det faktisk sætter noget, der næsten ligner en advarsel. Det har fået en slags udbytte skilt der siger netværkskommunikation, telefonopkald men brugeren vil klikke installere, right? Og så Apple ene er helt uskadeligt. Det giver ikke nogen form for advarsel. Det er bare Apple gerne vil bruge din aktuelle placering. Selvfølgelig du kommer til at klikke okay. Der er denne finkornet tilladelse model, og apps er nødt til at have en manifest-fil, hvor de erklærer de tilladelser, de har brug for, og som vil blive vist for brugeren, og brugeren bliver nødt til at sige, at jeg give disse tilladelser. Men lad os være ærlige. Brugerne er bare altid at sige okay. Lad os tage et hurtigt kig på de tilladelser, disse apps beder om og nogle af de tilladelser, der er der. Dette selskab Praetorian lavede en undersøgelse sidste år 53.000 ansøgninger analyseret i Android Market og 3. parts markeder, så det er alt Android. Og den gennemsnitlige app anmodet 3 tilladelser. Nogle apps anmodede 117 tilladelser, så selvfølgelig disse er meget finkornet og alt for kompliceret for en bruger at forstå hvis de er præsenteret med denne app, der har brug for disse 117 tilladelser. Det er ligesom den slutbrugerlicensaftale, der er 45 sider lang. Måske snart de vil have en løsning, hvor det er ligesom udskrive tilladelser, og send mig en mail. Men hvis man ser på nogle af de øverste interessante tilladelser 24% af de apps, de hentet ud af 53.000 ønskede GPS-oplysninger fra enheden. 8% læser kontakterne. 4% sendt SMS, og 3% har modtaget SMS. 2% optaget lyd. 1% behandlet udgående opkald. Det ved jeg ikke. Jeg tror ikke 4% af apps i app store virkelig brug for at sende SMS-beskeder, så jeg tror, ​​det er en antydning af, at noget uheldige der foregår. 8% af de apps brug for at læse din kontaktliste. Det er nok ikke nødvendigt. En af de andre interessante ting om tilladelser er hvis du linker i delte biblioteker i din ansøgning de arver tilladelserne til programmet, så hvis din app behov kontaktlisten eller har brug for GPS-position til at fungere og du linker i en reklame bibliotek, for eksempel, pågældende annonce bibliotek vil også kunne få adgang til de kontakter, og også være i stand til at få adgang til GPS-placering, og udvikleren af ​​app kender intet om den kode, der kører i annoncen biblioteket. De er bare forbinder det i, fordi de ønsker at tjene penge på deres app. Det er her, og jeg vil tale om nogle eksempler på dette med et program kaldet Pandora, hvor en ansøgning udvikler måske uforvarende kan lække oplysninger fra deres brugere på grund af bibliotekerne, de har knyttet i. Opmåling landskabet derude, ser på alle de forskellige apps der er blevet rapporteret i nyhederne som ondsindede eller laver noget brugere ikke ønskede og derefter inspicere en masse apps-vi gør en masse statisk binær analyse på mobile apps, så vi har inspiceret dem og kiggede på selve koden- vi kom op med det, vi kalder vores top 10 liste over risikable adfærd i applikationer. Og det er opdelt i 2 sektioner, skadelig kode, så disse er dårlige ting, de apps kan gøre, at sandsynligvis vil være noget, som en ondsindet person har specielt lagt i ansøgningen, men det er en lille smule fuzzy. Det kunne være noget, som en udvikler mener er fint, men det ender med at blive tænkt på som skadeligt af brugeren. Og så det andet afsnit er, hvad vi kalder kodning sårbarheder, og disse er ting, hvor bygherren er dybest set lave fejl eller bare ikke forstår, hvordan man skriver app forsvarligt,  og det er at sætte den app brugeren i fare. Jeg har tænkt mig at gå gennem disse i detaljer og give nogle eksempler. For reference, jeg ønskede at sætte op OWASP mobil top 10 liste. Disse er de 10 spørgsmål, som en gruppe på OWASP, Open Web Application Security Project, at de har en arbejdsgruppe arbejder på en mobil top 10 liste. De har en meget berømt web top 10 liste, som er top 10 farligste ting, du kan have i en webapplikation. De laver de samme ting til mobil, og deres liste er lidt anderledes end vores. 6 ud af 10 er de samme. De har 4, som er forskellige. Jeg tror, ​​de har en lille smule af en anden tage på risiko i mobile apps, hvor en masse af deres problemer virkelig, hvordan programmet er at kommunikere til en back-end server eller hvad der foregår på back-end server, ikke så meget apps, der har risikoadfærd, der er bare ligetil klientprogrammer. Dem i rødt her er forskellene mellem de 2 lister. Og nogle af min forskning team har faktisk bidraget til dette projekt, så vi vil se, hvad der sker over tid, men jeg tror, ​​at takeaway her er vi ved ikke rigtig, hvad top 10 listen er i mobile apps, fordi de har virkelig kun eksisteret i 2 eller 3 år nu, og der har ikke været tid nok til virkelig at udforske de operativsystemer og hvad de er i stand til, og der har ikke været tid nok for det ondsindede samfund, hvis du vil, for at have brugt tid nok forsøger at angribe brugere via mobile apps, så jeg forventer, at disse lister til at ændre en lille smule. Men for nu, det er de top 10 ting at bekymre sig om. Du vil måske undre sig på den mobile side, hvor gør det ondsindede mobil kode- hvordan ser det komme på enheden? North Carolina State har et projekt kaldet Mobile Malware Genome Project hvor de indsamler så meget mobil malware, som de kan og analysere det, og de har brudt ned injektion vektorer, at den mobile malware bruger, og 86% bruger en teknik kaldet ompakning, og det er kun på Android-platformen kan du virkelig gøre dette ompakning. Årsagen er Android kode er bygget med en Java byte kode kaldet Dalvik, som er let decompilable. Hvad den dårlige fyr kan gøre, er tage en Android-applikation, dekompilere det, indsætte deres ondsindede kode, rekompilere det, og derefter sætte den op i App Store, der påstås at være en ny version af denne ansøgning, eller bare måske ændre navnet på programmet. Hvis det var en slags spil, ændre navnet en smule, og så dette ompakningen er hvordan 86% af mobil malware bliver fordelt. Der er en anden teknik kaldet opdatering, som er meget lig ompakning, men du faktisk ikke sætte den skadelige kode i. Hvad du gør er du putter i en lille opdatering mekanisme. Du dekompilere, du lægger i en opdatering mekanisme, og du rekompilere det, og derefter, når app kører det trækker ned malware på enheden. Ved langt er de fleste disse 2 teknikker. Der er egentlig ikke meget downloade drive-bys eller drive-by downloads på mobiltelefoner, som kunne være som et phishing-angreb. Hey, så tjek denne virkelig cool hjemmeside, eller du har brug for at gå til denne hjemmeside og udfylde denne formular at holde fortsat gøre noget. De er phishing-angreb. Det samme kan ske på den mobile platform, hvor de pege på en mobil app til at hente, siger "Hej, det er Bank of America." "Vi ser du bruger dette program." "Du skal hente denne anden anvendelse." Teoretisk set kunne det fungere. Måske er det bare ikke bliver brugt nok til at afgøre, om det er en succes eller ej, men de fandt, at mindre end 1% af den tid, teknik anvendes. Størstedelen af ​​den tid, det er virkelig et ompakket kode. Der er en anden kategori kaldet standalone hvor nogen bare bygger en helt ny ansøgning. De bygger et program, der foregiver at være noget. Det er ikke en ompakning af noget andet, og det har den skadelige kode. Der bruges 14% af tiden. Nu vil jeg tale om, hvad der er den skadelige kode gør? En af de første malware derude du kunne overveje en spyware. Det dybest set spioner på brugeren. Den indsamler e-mails, SMS-beskeder. Det tænder mikrofonen. Det høster kontakt bogen, og det sender den ud til en anden. Denne form for spyware findes på pc'en, så det giver god mening for folk at forsøge at gøre dette på mobile enheder. Et af de første eksempler på dette var et program kaldet Secret SMS Replicator. Det var i Android Marketplace for et par år siden, og idéen var, hvis du havde adgang til en andens Android-telefon at man ønskede at udspionere, så måske er det din ægtefælle eller din betydelige andre, og du ønsker at udspionere deres tekstbeskeder, du kan downloade denne app og installere det og konfigurere den at sende en SMS til dig med en kopi af hver SMS-besked, de fik. Dette er naturligvis i krænkelser af App Store hensyn til service, og dette blev fjernet fra Android Marketplace senest 18 timer efter at det er der, så et meget lille antal mennesker var i fare på grund af dette. Nu tror jeg, hvis programmet blev kaldt noget måske lidt mindre provokerende ligesom Secret SMS Replicator det sandsynligvis ville have fungeret meget bedre. Men det var slags indlysende. En af de ting, vi kan gøre for at afgøre, om apps har denne adfærd, som vi ikke ønsker er at inspicere koden. Dette er faktisk virkelig nemt at gøre på Android, fordi vi kan dekompilere apps. På iOS kan du bruge en disassembler ligesom IDA Pro at se på, hvad API'er app der ringer, og hvad det gør. Vi skrev vores egen binær statisk analysator til vores kode og vi gør det, og så hvad du kan gøre, er du kunne sige gør enheden gøre noget, der er dybest set udspionerer mig eller sporing mig? Og jeg har nogle eksempler her på iPhone. Dette første eksempel er, hvordan adgang til UUID på telefonen. Dette er faktisk noget, som Apple netop har forbudt for nye ansøgninger, men gamle programmer, som du måske har kørende på din telefon kan stadig gøre dette, og så entydig identifikator kan bruges til at spore dig på tværs af mange forskellige applikationer. På Android, jeg har et eksempel her for at få enhedens placering. Du kan se, at hvis at API opkald er der for, at app er tracking, og du kan se, om det bliver fint sted eller grove placering. Og så på bunden her, jeg har et eksempel på, hvordan på BlackBerry et program kan få adgang til e-mails i din indbakke. Det er den slags ting, du kan inspicere at se hvis den app gør disse ting. Den anden store kategori af ondsindet adfærd, og det er formentlig den største kategori nu, er uautoriseret opkald, uautoriseret premium SMS-beskeder eller uautoriserede betalinger. En anden ting der er unikt ved telefonen er, at enheden er tilsluttet til en faktureringskonto, og når aktiviteterne sker på telefonen det kan skabe afgifter. Du kan købe ting over telefonen, og når du sender en præmie SMS-besked du faktisk give penge til kontohaver i telefonnummeret på den anden side. Disse blev sat op for at få aktiekurser eller få din daglige horoskop eller andet men de kan sættes op til at bestille et produkt ved at sende en SMS. Folk give penge til Røde Kors ved at sende en SMS-besked. Du kan give 10 dollar på den måde. Angriberne, hvad de har gjort, er de oprettet konti i udlandet, og de integrere i malware at telefonen vil sende en præmie SMS, sige, et par gange om dagen, og i slutningen af ​​måneden, du indser du har brugt snesevis eller måske endda hundredvis af dollars, og de går væk med pengene. Det blev så slemt, at dette var det allerførste, at Android Marketplace eller Google sted, det var Android Marketplace på det tidspunkt, og det er nu Google Play-den første ting, at Google begyndte at kontrollere for. Når Google begyndte at distribuere Android apps i deres app store de sagde, de ikke kommer til at tjekke for noget. Vi vil trække apps, når vi er blevet meddelt, at de har brudt vores betingelser for service, men vi kommer ikke til at tjekke for noget. Nå, omkring et år siden fik det så dårligt med denne præmie SMS malware at dette er den allerførste ting, de begyndte at kontrollere for. Hvis en app kan sende SMS-beskeder de videre manuelt undersøge ansøgningen. De ser for de API'er, der kalder denne, og nu siden da Google har udvidet, men dette var den første ting, at de begyndte at lede efter. Nogle andre apps, der gjorde nogle SMS-beskeder, denne Android Qicsomos, tror jeg det hedder. Der var denne aktuelle begivenhed på mobilen, hvor denne CarrierIQ kom ud som spyware sat på enheden ved de luftfartsselskaber, så folk ville vide, om deres telefon var sårbare over for denne, og dette var en gratis app, der testede det. Nå, selvfølgelig, hvad denne app gjorde, var det sendt premium SMS-beskeder, så ved at teste for at se, hvis du er inficeret med spyware du har lagt malware på din enhed. Vi så det samme ske i sidste Super Bowl. Der var en falsk version af Madden fodboldkamp der sendte premium SMS-beskeder. Det faktisk forsøgt at skabe en bot-netværk også på enheden. Her har jeg nogle eksempler. Interessant nok, var Apple temmelig smart, og de tillader ikke programmer til at sende SMS-beskeder på alle. Ingen app kan gøre det. Det er en fantastisk måde at slippe af med en hel klasse af sårbarhed, men på Android kan du gøre det, og selvfølgelig på BlackBerry kan du gøre det også. Det er interessant, at på BlackBerry alt du behøver, er tilladelser internet at sende en SMS-besked. Den anden ting virkelig, at vi kigger efter når vi søger at se, om noget er skadeligt, er bare nogen form for uautoriseret netværksaktivitet, ligesom se på netværksaktivitet app formodes at have sin funktionalitet, og se på denne anden netværksaktivitet. Måske en app, til at arbejde, har for at få data over HTTP, men hvis det er at gøre ting via e-mail eller sms eller Bluetooth eller noget lignende nu, at app potentielt kunne være skadelig, så det er en anden ting du kan inspicere for. Og på dette dias her har jeg nogle eksempler på det. En anden interessant ting, vi oplevede med malware skete tilbage i 2009, og det skete i en stor måde. Jeg ved ikke, om det er sket så meget siden da, men det var en app der efterlignede et andet program. Der var et sæt af apps, og det blev døbt 09Droid angreb, og nogen har besluttet, at der var en masse små, regionale og mellemstore banker der ikke har netbank-applikationer, så hvad de gjorde, var de bygget omkring 50 online banking at alle de gjorde var at tage brugernavn og password og omdirigere dig til hjemmesiden. Og så de sætte disse alle op i Google Marketplace, i Android Marketplace, og når nogen søgte at se, om deres bank havde et program, de ville finde den falske ansøgning, som har indsamlet deres legitimationsoplysninger og derefter omdirigeret dem til deres hjemmeside. Den måde, at dette rent faktisk blev-apps var deroppe for et par uger, og der var tusinder og atter tusinder af downloads. Den måde dette kom frem i lyset var en person havde et problem med et af programmerne, og de kaldte deres bank, og de kaldte deres banks kundesupport linje og sagde, "Jeg har et problem med din mobilbank applikation." "Kan du hjælpe mig?" Og de sagde: "Vi har ikke en mobilbank applikation." Det startede undersøgelsen. At banken hedder Google, og så Google kiggede og sagde, "Wow, har samme forfatter skrevet 50 bank applikationer," og tog dem alle ned. Men helt sikkert det kunne ske igen. Der er en liste over alle de forskellige banker her der var en del af denne fidus. Den anden ting en app kan gøre, er til stede UI af et andet program. Mens det kører det kunne poppe op Facebook UI. Det siger, at du nødt til at sætte dit brugernavn og adgangskode for at fortsætte eller sætte op i ethvert brugernavn og adgangskode UI for et websted at måske brugeren anvender blot at forsøge at narre brugeren til at sætte deres legitimationsoplysninger i. Dette er virkelig en lige parallel af de e-mail-phishing-angreb hvor en person sender dig en e-mail og giver dig dybest set en falsk UI for et websted at du har adgang til. Den anden ting, vi ser i ondsindet kode er system modifikation. Du kan søge efter alle de API-kald, der kræver root privilegium at udføre korrekt. Ændring af enhedens web proxy ville være noget at en ansøgning bør ikke være i stand til at gøre. Men hvis programmet har koden i der for at gøre det du ved, at det sandsynligvis er en ondsindet program eller meget stor sandsynlighed for at være et skadeligt program, og så hvad der ville ske, er, at app ville have nogle måde eskalerende privilegium. Det ville have nogle privilegium optrapning udnytte i ansøgningen, og derefter når det eskalerede privilegier det ville gøre disse systemændringer. Du kan finde malware, der har privilegium optrapning i det endda uden at vide hvordan det privilegium optrapning udnytte kommer til at ske, og det er et rart, let måde at kigge efter malware. DroidDream var sandsynligvis den mest berømte stykke af Android malware. Jeg tror, ​​det påvirkede omkring 250.000 brugere i løbet af et par dage før det blev fundet. De ompakket 50 falske applikationer, sætte dem i Android App Store, og i det væsentlige det plejede Android jailbreak kode at eskalere privilegier og derefter installere en kommando, kontrol og slå alle ofrene ind i et bot net, men du kunne have opdaget dette hvis du var at scanne programmet og bare på udkig efter API-kald, der krævede root tilladelse til at udføre korrekt. Og der er et eksempel her har jeg som ændrer proxy, og det faktisk kun er tilgængelig på Android. Du kan se, jeg giver dig en masse eksempler på Android fordi det er her den mest aktive malware økosystem er fordi det er virkelig nemt for en hacker at få skadelig kode i Android Marketplace. Det er ikke så let at gøre det i Apple App Store fordi Apple kræver udviklere til at identificere sig selv og underskrive koden. De faktisk kontrollere, hvem du er, og Apple er faktisk granske ansøgningerne. Vi ser ikke en masse sand malware, hvor enheden bliver kompromitteret. Jeg vil tale om nogle eksempler, hvor det er virkelig privatlivets fred, som er ved at blive kompromitteret, og det er, hvad der virkelig sker på Apple-enhed. En anden ting at kigge efter skadelig kode, risikabel kode i enheder er logik eller tidsindstillede bomber, og tidsindstillede bomber er formentlig meget lettere at søge end logiske bomber. Men med tidsindstillede bomber, hvad du kan gøre, er at du kan søge efter steder i koden, hvor tiden er testet, eller en absolut tid ledt efter før visse funktioner i app sker. Og dette kunne gøres for at skjule denne aktivitet fra brugeren, så det sker sent om natten. DroidDream gjorde alt dens aktivitet fra 23:00 til 08:00 lokal tid at forsøge at gøre det, mens brugeren ikke bruger måske deres enhed. En anden grund til at gøre dette er, hvis folk bruger adfærdsmæssige analyse af en ansøgning, kører app i en sandkasse at se, hvad adfærd ansøgningen er, de kan bruge tidsbaserede logik at gøre aktiviteten når app ikke er i sandkassen. For eksempel en app butik som Apple kører programmet, men de sandsynligvis ikke køre hver ansøgning for, siger 30 dage før de godkender det, så du kan sætte logik i din ansøgning, der sagde, okay, kun gøre de dårlige ting efter 30 dage er gået, eller efter 30 dage efter den dato offentliggøre ansøgningen, og som kan hjælpe den skadelige kode skjul fra folk inspicere for det. Hvis anti-virus firmaer kører tingene i sandkasser eller app stores selv er dette kan hjælpe skjule, at fra denne inspektion. Nu, bagsiden af ​​det er det er nemt at finde med statisk analyse, så faktisk inspicere den kode, du kan søge efter alle de steder hvor ansøgningen tester tiden og inspicere den måde. Og her har jeg nogle eksempler på disse 3 forskellige platforme hvordan tiden kan kontrolleres for den app maker så du ved, hvad man skal kigge efter, hvis du inspicere app statisk. Jeg gik bare igennem en hel masse forskellige ondsindede aktiviteter at vi har set i naturen, men hvilke er de mest udbredte? Samme undersøgelse fra North Carolina State Mobile Genome Project offentliggjort nogle data, og der var stort set 4 områder at de så, hvor der var en masse aktivitet. 37% af de apps gjorde privilegium optrapning, så de havde en vis form for jailbreak kode derinde hvor de forsøgte at eskalere privilegier, så de kunne behøver API kommandoer kører som operativsystemet. 45% af de apps derude gjorde sms, så det er en stor procentdel, der forsøger at direkte tjene penge. 93% gjorde fjernbetjening, så de forsøgte at etablere et bot net, en mobil bot net. Og 45% høstet identificerende oplysninger ligesom telefonnumre, UUID'er, GPS-position, brugerkonti, og dette tilføjer op til mere end 100, fordi de fleste malware forsøger at gøre et par af disse ting. Jeg har tænkt mig at skifte til den anden halvdel, og snakke om den kode sårbarheder. Dette er den anden halvdel af risikabel aktivitet. Det er her væsentligt udvikleren gør fejl. En legitim udvikler skrive en legitim app gør fejl eller er uvidende om risikoen for den mobile platform. De ved bare ikke, hvordan man laver en sikker mobil app, eller nogle gange udvikleren ikke bekymrer sig om at sætte brugeren i fare. Sommetider en del af deres forretningsmodel kunne være høst af brugerens personlige oplysninger. Det er slags i den anden kategori, og det er derfor nogle af denne ondsindede versus legitime begynder at bløde i løbet, fordi der er forskel på meninger mellem, hvad brugeren ønsker, og hvad brugeren finder risikabelt og hvad applikationsudvikler finder risikabelt. Selvfølgelig er det ikke anvendelsen udviklerens data i de fleste tilfælde. Og så endelig, en anden måde dette sker, er en udvikler kan linke i et delt bibliotek, der har sårbarheder eller denne risikabel adfærd i det unbeknownst til dem. Den første kategori er følsomme data lækage, og det er, når den app indsamler oplysninger ligesom placering, adressebog information, ejeroplysninger og sender det fra enheden. Og når det er slået fra enheden, ved vi ikke, hvad der sker med disse oplysninger. Det kunne gemmes usikkert ved anvendelse udvikler. Vi har set applikationsudviklere få kompromitteret, og de data, de er lagring bliver taget. Det skete et par måneder siden til en udvikler ned i Florida hvor et stort antal af-det var iPad UUID'er og enhedsnavne blev lækket fordi nogen, jeg tror det var anonym, hævdede at gøre dette, brød ind i denne udvikler servere og stjal millioner af iPad UUID'er og edb-navne. Ikke den mest risikable information, men hvad hvis det var opbevaring af brugernavne og adgangskoder og privatadresser? Der er masser af apps, der lagrer den slags oplysninger. Risikoen er der. Den anden ting, der kan ske, er, hvis bygherren ikke tager sig til at sikre data-kanal, og det er en anden stor sårbarhed jeg har tænkt mig at tale om, at data bliver sendt i det klare. Hvis brugeren er på et offentligt Wi-Fi-netværk eller nogen er sniffing internettet eller andet sted ad den vej, at data bliver udsat. En meget berømt sag af denne information lækage skete med Pandora, og det er noget vi forsket på Veracode. Vi hørte, at der var en-jeg tror det var en Federal Trade Commission undersøgelse foregår med Pandora. Vi sagde, "Hvad sker der? Lad os begynde at grave ind i Pandora program." Og hvad vi bestemt var Pandora ansøgning indsamlede dit køn og din alder, og det også adgang til din GPS-position, og Pandora ansøgning gjorde det for, hvad de sagde var legitime årsager. Den musik, de legede-Pandora er en musik-streaming app- den musik, de spillede kun blev godkendt i USA, så de havde til at kontrollere at overholde deres licensaftaler, som de havde for musikken at brugeren var i Amerikas Forenede Stater. De ønskede også at overholde Parental Advisory omkring voksen sprog i musik, og så det er et frivilligt program, men de ønskede at efterkomme og ikke spille eksplicitte tekster til børn 13 og under. De havde rimelig grund til at indsamle disse data. Deres app havde de tilladelser til at gøre det. Brugere troede, det var legitimt. Men hvad skete der? De er forbundet i 3 eller 4 forskellige ad biblioteker. Nu er alle pludselig alle disse ad biblioteker får adgang til den samme information. Ad biblioteker, hvis man ser på koden i annoncen biblioteker hvad de gør, er hver annonce bibliotek siger "Har min app har tilladelse til at få GPS-position?" "Åh, det gør? Okay, fortæl mig det GPS-placering." Hver enkelt annonce bibliotek gør det, og hvis den app ikke har GPS-tilladelse vil det ikke være i stand til at få det, men hvis det gør, vil det få det. Dette er, hvor forretningsmodellen i ad bibliotekerne er imod, at brugerens privatliv. Og der har været undersøgelser derude, der vil sige, hvis du kender den alder af en person, og du kender deres placering hvor de sover om natten, fordi du har deres GPS-koordinater mens de måske sover, du ved præcis, hvem denne person er fordi du kan bestemme, hvilke medlem af husstanden er denne person. Virkelig dette er at identificere til annoncører præcis, hvem du er, og det ser ud som det var legitimt. Jeg vil bare have min streaming af musik, og det er den eneste måde at få det. Nå, vi udsat dette. Vi skrev det op i flere blogindlæg og det viste sig, at en person fra Rolling Stone magazine læse en af ​​vores blogindlæg og skrev deres egen blog i Rolling Stone om det, og den næste dag Pandora troede, det var en god idé at fjerne annoncen biblioteker fra deres ansøgning. Så vidt jeg ved, de er det eneste, de skal roses. Jeg tror, ​​de er den eneste Freemium type app, der har gjort dette. Alle de andre Freemium apps har denne samme adfærd, så du har fået til at tænke over, hvad slags data du giver disse Freemium applikationer, fordi det hele kommer til annoncører. Praetorian gjorde også en undersøgelse om delte biblioteker og sagde, "Lad os se på, hvad delte biblioteker er de øverste delte biblioteker", og dette var dataene. De analyserede 53.000 apps, og antallet 1 delt bibliotek var AdMob. Det var faktisk i 38% af de programmer derude, så 38% af de programmer, du bruger sandsynligvis høste dine personlige oplysninger og sende den til annoncenetværk. Apache og Android var 8% og 6%, og så disse andre dem nede i bunden, Google Ads, Flurry, Mob City og tusindårsrige Medier, disse er alle ad selskaber, og så interessant nok, 4% forbundet i Facebook-biblioteket sandsynligvis til at gøre godkendelse via Facebook så den app kunne autentificere Facebook. Men det betyder også selskabet Facebook styrer kode der kører i 4% af Android mobile apps derude, og de har adgang til alle de data, der app har tilladelse til at få ram på. Facebook hovedsageligt forsøger at sælge reklameplads. Det er deres forretningsmodel. Hvis man ser på hele dette økosystem med disse tilladelser og delte biblioteker, du begynder at se, at du har en masse af risiko i en angiveligt legitimt program. Det samme lignende ting, der skete med Pandora skete med et program kaldet Path, og sti troede, at de var ved at blive nyttige, venlige udviklere. De var bare forsøger at give dig en fantastisk brugeroplevelse, og det viste sig, at uden at spørge brugeren eller fortæller brugeren noget- og dette skete på iPhone og på Android, Pandora app var på iPhone og Android- at Sti ansøgning blev snuppe hele din adressebog og uploade det til Path lige når du har installeret og løb ansøgningen, og de ikke fortælle dig om dette. De troede, det var virkelig nyttige for dig at være i stand til at dele med alle de mennesker i din adressebog at du bruger Sti ansøgning. Nå, selvfølgelig Sti troede, det var stor for deres virksomhed. Ikke så stor for brugeren. Du er nødt til at tænke, at det er én ting, hvis måske en teenager bruger dette program, og deres snesevis af venner er derinde, men hvad nu hvis det er den administrerende direktør for en virksomhed, der installerer Path og så lige pludselig hele deres adressekartotek er deroppe? Du kommer til at få en masse af potentielt værdifulde kontaktoplysninger for en masse mennesker. En journalist fra New York Times, kan du være i stand til at få telefonnummeret for tidligere præsidenter fra deres adressebog, så naturligvis en masse følsomme oplysninger bliver overført med noget som dette. Der var sådan en stor klap om det, at Sti undskyldt. De ændrede deres app, og det endda påvirket Apple. Apple sagde, "Vi kommer til at tvinge app leverandører til at bede brugere hvis de kommer til at samle hele deres adressebog. " Det ligner, hvad der sker her er når der er en stor krænkelse af personlige oplysninger, og det gør pressen vi se en ændring derude. Men selvfølgelig er der andre ting derude. LinkedIn ansøgning høster dine kalenderposter, men Apple gør ikke brugeren bedt om det. Kalenderposter kan have følsomme oplysninger i dem også. Hvor vil du trække grænsen? Det er virkelig sådan en udvikling sted hvor der er virkelig ingen god standard derude for brugerne at forstå, når deres oplysninger kommer til at være i fare og når de kommer til at kende det bliver taget. Vi skrev en app på Veracode kaldet Adios, og hovedsagelig det tilladt du pege app på iTunes bibliotek og se på alle de programmer, der var høst din fulde adresse bog. Og som du kan se på denne liste her, Angry Birds, AIM, AroundMe. Hvorfor Angry Birds har brug for din adressebog? Jeg ved det ikke, men det gør en eller anden måde. Det er noget, mange, mange applikationer gør. Du kan inspicere koden til dette. Der er veldefinerede API'er til iPhone, Android og BlackBerry at komme på adressebogen. Du kan virkelig nemt inspicere for dette, og det er, hvad vi gjorde i vores Adios ansøgning. Den næste kategori, Usikker Sensitive Datalagring, er noget, hvor udviklerne tage noget som en nål eller et kontonummer eller en adgangskode og opbevar den i klar på enheden. Endnu værre, kan de gemme det i et område på telefonen som er globalt tilgængelige, ligesom SD-kortet. Du kan se dette oftere på Android fordi Android giver mulighed for et SD-kort. IPhone-enheder ikke. Men vi oplevede selv dette ske i en CitiGroup ansøgning. Deres netbank ansøgning lagret kontonumre usikker, bare i den klare, så hvis du har mistet din enhed, hovedsagelig du mistet din bankkonto. Derfor er jeg personligt ikke gøre bankforretninger på min iPhone. Jeg synes, det er for risikabelt lige nu til at gøre disse former for aktiviteter. Skype gjorde det samme. Skype, selvfølgelig, har en konto balance, et brugernavn og en adgangskode at adgang denne balance. De var lagring af alle disse oplysninger i den klare på den mobile enhed. Jeg har nogle eksempler her for oprette filer der ikke har de rigtige tilladelser eller skrive til disk og ikke have nogen kryptering ske for. Denne næste område, Usikker følsomme data transmission, Jeg har hentydet til dette et par gange, og på grund af offentlig Wi-Fi det er noget, apps absolut nødt til at gøre, og det er nok det, vi ser gå galt mest. Jeg vil sige, faktisk, jeg tror, ​​jeg har de faktiske data, men det er tæt på halvdelen af ​​de mobile applikationer skrue op laver SSL. De har bare ikke bruge API'er korrekt. Jeg mener, alt hvad du har at gøre, er at følge instruktionerne og bruge API'er men de ting som ikke tjekke, om der er et ugyldigt certifikat i den anden ende, ikke kontrollere, om den anden ende forsøger at gøre en protokol nedjustering angreb. Udviklerne, de ønsker at få deres afkrydsningsfelt, right? Deres krav er at bruge dette til at sælge. De har brugt dette til at sælge. Kravet er ikke at bruge denne til at sælge sikkert, og så dette er grunden til alle programmer, der bruger SSL til at sikre data som det er at blive overført fra enheden virkelig skal inspiceres at sørge for, der blev gennemført korrekt. Og her har jeg nogle eksempler, hvor du kan se et program bruger måske HTTP i stedet for HTTPS. I nogle tilfælde apps vil falde tilbage til HTTP hvis HTTPS ikke fungerer. Jeg har et andet opkald her på Android, hvor de har slået check certifikat, så en man-in-the-middle-angreb kan ske. Et ugyldigt certifikat vil blive accepteret. Disse er alle tilfælde, hvor angriberne kommer til at være i stand til at komme videre det samme Wi-Fi-forbindelse som bruger og få adgang til alle de data, , der bliver sendt over internettet. Og endelig den sidste kategori, jeg har her, er hardcodede kodeord og nøgler. Vi har faktisk se en masse udviklere bruger den samme kodning stil at de gjorde, da de var ved at bygge web-server applikationer, så de opbygger en Java server-program, og de er hardcoding nøglen. Nå, når du bygger en server applikation, ja, hardcoding nøglen er ikke en god idé. Det gør det vanskeligt at ændre. Men det er ikke så slemt på serveren side, fordi der har adgang til serveren side? Kun administratorer. Men hvis du tager den samme kode, og du hældte det over til en mobil applikation nu alle, der har at mobil Applikationen har adgang til at hardcodede nøgle, og vi faktisk ser dette en masse gange, og jeg har nogle statistikker på, hvor ofte vi ser dette ske. Det var faktisk i eksempel kode, som MasterCard offentliggjort om, hvordan du bruger deres service. Eksemplet kode viste, hvordan du bare ville tage adgangskode og sætte det i en hardcodede snor lige der, og vi ved, hvordan udviklerne elsker at kopiere og indsætte kodestumper når de forsøger at gøre noget, så du kopiere og indsætte kodestykket at de gav som eksempel kode, og du har en usikker program. Og her har vi nogle eksempler. Denne første er en vi ser en masse, hvor de hardcode data lige ind i en URL-adresse, der bliver sendt. Nogle gange ser vi string password = password. Det er temmelig let at opdage, eller snor password på BlackBerry og Android. Det er faktisk temmelig nemt at kontrollere, fordi næsten altid udvikleren navne den variabel, der holder adgangskoden nogle variation af password. Jeg nævnte, at vi gør statisk analyse på Veracode, så vi har analyseret flere hundrede Android og iOS-applikationer. Vi har bygget komplette modeller for dem, og vi er i stand til at scanne dem for forskellige sårbarheder, især de sårbarheder jeg talte om, og jeg har nogle data her. 68,5% af de Android apps vi kiggede på havde brudt kryptografisk kode, som for os, kan vi ikke opdage, hvis du har lavet din egen krypto rutine, ikke, at det er en god ide, men det er faktisk at bruge de offentliggjorte API'er der er på platformen, men gør dem på en sådan måde, at krypto vil være sårbare, 68,5. Og det er for folk, der sender os deres ansøgninger faktisk fordi de tror det er en god ide at gøre sikkerhedstest. Disse er allerede folk, der tænker sikkert sikkert, så det er nok endnu værre. Jeg talte ikke om kontrol linjeskift injektion. Det er noget, vi søger efter, men det er ikke så risikabelt et problem. Information lækage, dette er, hvor følsomme data bliver sendt fra enheden. Vi fandt, at i 40% af ansøgningerne. Tid og stat, de er race condition typen spørgsmål, typisk temmelig svært at udnytte, så jeg ikke tale om det, men vi kiggede på det. 23% havde SQL-injektion spørgsmål. En masse mennesker ikke ved, at en masse ansøgninger bruge en lille smule SQL database på ryggen ende til at gemme data. Tja, hvis de data, du snuppe over netværket har SQL-injektion angreb strenge i det nogen kan kompromittere enheden gennem det, og så tror jeg, vi finder omkring 40% af web-applikationer har dette problem, der er et stort epidemi problem. Vi finder det 23% af tiden i mobile apps og det er sandsynligvis fordi mange flere web-applikationer bruger SQL end mobil. Og så har vi stadig se nogle cross-site scripting, spørgsmål om godkendelse, og derefter administration af legitimationsoplysninger, det er hvor du har din hardcodede adgangskode. I 5% af ansøgningerne vi se, at. Og så har vi nogle data på iOS. 81% havde fejlhåndtering spørgsmål. Dette er mere af en kode kvalitet problem, men 67% havde kryptografiske problemer, så ikke helt så slemt som Android. Måske API'er er en lille smule lettere, eksemplet koder lidt bedre på iOS. Men stadig en meget høj procentdel. Vi havde 54% med information lækage, omkring 30% med buffer management fejl. Det er steder, hvor der potentielt kan være et problem med beskadiget hukommelse. Det viser sig, der er ikke så meget af et problem for udnyttelse på iOS fordi al koden skal underskrives, så det er svært for en angriber at udføre vilkårlig kode på iOS. Kode kvalitet, mappegennemløb, men så legitimationsoplysninger ledelse her på 14,6%, så værre end på Android. Vi har folk ikke håndtere passwords korrekt. Og så de numeriske fejl og buffer overflow, de er mere kommer til at være problemer kode kvalitet på iOS. Det var det for min præsentation. Jeg ved ikke, om vi er ude af tid eller ej. Jeg ved ikke, om der er nogen spørgsmål. [Mand] En hurtig spørgsmål omkring fragmentering og Android Market. Apple mindst ejer patching. De gør et godt stykke arbejde for at få det derude mens mindre så i Android rum. Du næsten nødt til at jailbreake din telefon til at holde dig opdateret med den aktuelle version af Android. Ja, det er et kæmpe problem, og så hvis du tænker over- [Mand] Hvorfor kan du ikke gentage det? Åh, til højre, så spørgsmålet var, hvad omkring fragmentering af operativsystemet på Android-platformen? Hvordan kan det påvirke risikoen i disse enheder? Og det er faktisk et stort problem, fordi hvad der sker, er de ældre enheder, når nogen kommer op med et jailbreak for denne enhed, væsentlige, det er privilegium optrapning, og indtil det operativsystem er opdateret enhver malware kan derefter bruge denne sårbarhed til helt kompromittere enheden og hvad vi ser på Android er i orden at få et nyt operativsystem Google har til at sætte ud operativsystemet, og derefter hardwareproducenten har til at tilpasse det, og derefter transportøren har for at tilpasse det og levere det. Du har grundlæggende 3 bevægelige dele her, og det er at dreje ud af, at de luftfartsselskaber, ligeglad, og hardwareproducenter ligeglade, og Google er ikke puffede dem nok at gøre noget, så det væsentlige over halvdelen af ​​enhederne derude har operativsystemer, der har disse rettighedsforøgelse sårbarheder i dem, og så hvis du får malware på din Android-enhed er det meget mere af et problem. Okay, mange tak. [Bifald] [CS50.TV]