>> [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]