[Seminar] [Defending Behind the Device: Mobile Application Security] [Chris Wysopal] [Harvard University] [Dette er CS50.] [CS50.TV] God ettermiddag. Mitt navn er Chris Wysopal. Jeg er CTO og co-grunnlegger av Veracode. Veracode er et program sikkerhetsselskap. Vi tester alle slags forskjellige applikasjoner, og hva jeg skal snakke om i dag er mobile applikasjonssikkerhet. Min bakgrunn er at jeg har drevet med sikkerhetsforskning for en veldig lang tid, sannsynligvis omtrent like lenge som noen. Jeg startet på midten av 90-tallet, og det var en tid som var ganske interessant fordi vi hadde et paradigmeskifte på midten av 90-tallet. Plutselig alles datamaskin ble koblet opp til internett, og da hadde vi begynnelsen på web-applikasjoner, og det er det jeg fokuserer på mye da. Det er interessant. Nå har vi en annen paradigmeskifte skjer med databehandling, som er overgangen til mobile applikasjoner. Jeg føler det er litt av en lignende tid da det var i slutten av 90-tallet når vi undersøker webapplikasjoner og finne feil som økt styringsfeil og SQL-injeksjon som egentlig ikke eksisterte før, og plutselig var de overalt i web-applikasjoner, og nå mye av tiden jeg tilbringer ser på mobile applikasjoner, og ser på hva som skjer der ute i naturen. Mobile applikasjoner er virkelig kommer til å være den dominerende dataplattform, slik at vi virkelig trenger å bruke mye tid hvis du er i sikkerhetsbransjen med fokus på web-applikasjoner. Det var 29000 millioner mobile apps lastet ned i 2011. Det er spådd til å være sammen 76 milliarder apps innen 2014. Det er 686 millioner enheter som kommer til å bli kjøpt i år, så dette er hvor folk kommer til å være å gjøre  mesteparten av sin klient databehandling fremover. Jeg snakket med en visepresident i Fidelity Investments et par måneder siden, og han sa at de bare fikk mer trafikk gjør finansielle transaksjoner fra deres kundebase på deres mobilapplikasjon enn på deres hjemmeside, så en vanlig bruk for nettet i det siste har vært sjekke aksjekurser, administrere din portefølje, og vi er faktisk å se at i 2012 bytte over å være mer dominerende på den mobile plattform. Gjerne om det kommer til å være noen kriminell aktivitet, noen ondsinnet aktivitet, det kommer til å begynne å være fokusert på den mobile plattformen over tid som folk bytte over til det. Hvis du ser på den mobile plattformen, å se på risikoen for plattformen er det nyttig å bryte det ned i de forskjellige lag, akkurat som du ville gjort det på en stasjonær datamaskin, og du tenker på de forskjellige lagene, programvare, operativsystem, nettverkslaget, hardware lag, og selvfølgelig, det er sårbarheter på alle disse lagene. Det samme skjer på mobil. Men mobil, virker det som om noen av disse lagene er verre stilt. For en, er mer problematisk på mobil nettverkslaget fordi mange mennesker har i sitt kontor eller hjemme kablet tilkobling eller de har sikre Wi-Fi-tilkoblinger, og med mye av mobile enheter du er åpenbart utenfor hjemmet eller utenfor kontoret mye, og hvis du bruker Wi-Fi der du kanskje bruker en usikker Wi-Fi-tilkobling, noe som er en offentlig Wi-Fi-tilkobling, så når vi tenker på mobile apps må vi ta hensyn at nettverksmiljøet er mer risikofylt for de programmene når Wi-Fi blir brukt. Og når jeg får inn mer av den mobile applikasjonen risiko vil du se hvorfor det er mer viktig. Det er risiko på hardware nivå på mobile enheter. Dette er et område med pågående forskning. Folk kaller disse bredbånds angrep eller baseband-angrep Ønsker du å angripe firmware som lytter på radio. Dette er virkelig skremmende angrep fordi brukeren trenger ikke å gjøre noe. Du kan treffe mange enheter innenfor RF-området på en gang, og det virker som når denne forskningen bobler opp det raskt blir klassifisert der folk slå inn rundt og si: "Her, fortell oss om det, og kan du slutte å snakke om det." Det er noen undersøkelser som skjer i bredbåndsområdet, men det ser ut til å være veldig hysj hysj. Jeg tror det er mer av en nasjonalstat type forskning som skjer. Et område med aktiv forskning, skjønt, er operativsystemet lag, og igjen, dette er annerledes enn i den stasjonære dataverdenen fordi i mobilen du har disse lagene av mennesker kalt Jailbreakers, og Jailbreakers er annerledes enn vanlige sårbarhetsforskere. De prøver å finne sårbarheter i operativsystemet, men grunnen til at de prøver å finne sårbarheter er ikke å bryte seg inn i en annens maskin og kompromiss. Det er å bryte seg inn i sin egen datamaskin. De ønsker å bryte seg inn i sin egen mobil, endre sin egen mobile operativsystem slik at de kan kjøre applikasjoner etter eget ønske og endre ting med fulle administrative rettigheter, og de ønsker ikke å fortelle leverandøren om dette. De er ikke som en sikkerhetsforsker som er en hvit lue sikkerhetsforsker som kommer til å gjøre begrenset offentliggjøring og fortelle leverandøren om det. De ønsker å gjøre denne forskningen, og de ønsker å faktisk publisere det i en utnytte eller et rootkit eller en jailbreak-kode, og de ønsker å gjøre det strategisk, som rett etter leverandør skip det nye operativsystemet. Du har denne motstandere forholdet med OS-nivå sårbarheter på mobil, som jeg synes er ganske interessant, og ett sted vi ser det er det som gjør det slik at det er godt publisert skadelig kode der ute for kernel-nivå sårbarheter, og vi har sett dem som faktisk brukes av malware forfattere. Det er litt annerledes enn PC-verdenen. Og da det endelige laget er det øverste laget, applikasjonslaget. Det er det jeg skal snakke om i dag. De andre lagene finnes, og de andre lagene spille inn i det, men jeg er stort sett kommer til å snakke om hva som skjer i applikasjonslaget der koden kjøres i sandkassen. Det har ikke administratorrettigheter. Det har å bruke API-er av enheten, men fortsatt kan mye av ondsinnet aktivitet og mye risiko skje ved at lag fordi det er det laget der all informasjon er. Apps kan få tilgang til all informasjon på enheten hvis de har de riktige tillatelsene, og de får tilgang til de ulike sensorene på enheten, GPS sensor, mikrofon, kamera, hva har du. Selv om vi bare snakker om i applikasjonslaget vi har mye risiko der. Den andre tingen som er annerledes med det mobile miljøet er alle operativsystem spillere, det være seg Blackberry eller Android eller iOS eller Windows mobile, de har alle en finkornet tillatelse modell, og dette er en av måtene som de bygget inn i operativsystemet ideen om at det er ikke så risikabelt som du tror. Selv om du har alle dine kontakter på det, all din personlige informasjon, du har bildene dine, har du din posisjon på det, du lagrer din bank pin for automatisk innlogging på det, er det trygt fordi apps må ha visse rettigheter til å få på visse deler av informasjonen på enheten, og brukeren må bli presentert med disse tillatelsene og si greit. Problemet med det er at brukeren alltid sier greit. Som en sikkerhet person, jeg vet at du kan spørre brukeren, si noe ille kommer til å skje, vil du at det skal skje? Og hvis de er i et rush eller det er noe virkelig fristende på den andre siden av det, som et spill kommer til å bli installert på at de har ventet på, de kommer til å klikke OK. Det er derfor jeg sier på min lysbildet her bare la meg slenge fugler på griser allerede, og du kan se på lysbildet her er det eksempler på en Blackberry tillatelse boks. Det står "Vennligst angi Blackberry reisesøknads tillatelser etter å ha klikket knappen nedenfor, "og i utgangspunktet brukeren er bare kommer til å si sette rettighetene og lagre. Her er en Android teksten der det viser ting, og det faktisk setter noe som ser nesten ut som en advarsel. Det fikk en slags avkastning skilt der sier nettverkskommunikasjon, telefonsamtale, men brukeren skal klikke installere, ikke sant? Og da Apple man er helt ufarlige. Den gir ikke noen form for advarsel. Det er bare Apple ønsker å bruke din nåværende plassering. Selvfølgelig er du kommer til å klikke OK. Det er dette finkornet tillatelse modell, og apps må ha et manifest fil hvor de erklærer tillatelsene de trenger, og som vil bli vist til brukeren, og brukeren må si jeg gi disse tillatelsene. Men la oss være ærlige. Brukerne er bare kommer til å alltid si okay. La oss ta en rask titt på de tillatelsene som disse programmene ber om og noen av de tillatelser som er der. Dette selskapet Praetorian gjorde en undersøkelse i fjor 53.000 søknader analysert i Android Market og tredje parts markeder, så dette er alle Android. Og den gjennomsnittlige app ba tre tillatelser. Noen apps bedt 117 tillatelser, så åpenbart disse er svært finkornet og altfor komplisert for en bruker å forstå hvis de er presentert med denne app som trenger disse 117 tillatelser. Det er som den lisensavtalen for sluttbrukere som er 45 sider lang. Kanskje snart de vil ha et alternativ der det er som skrive ut tillatelser og send meg en e-post. Men hvis du ser på noen av de beste interessante tillatelser 24% av apps som de lastet ned ut av 53000 bedt om GPS-informasjon fra enheten. 8% lese kontakter. 4% sendte SMS, og 3% mottatt SMS. 2% innspilt lyd. 1% behandlet utgående samtaler. Jeg vet ikke. Jeg tror ikke 4% av apps i App Store virkelig trenger å sende SMS-meldinger, så jeg tror det er et hint om at noe uheldig skjer. 8% av apps trenger å lese i kontaktlisten. Det er sannsynligvis ikke nødvendig. En av de andre interessante ting om tillatelser er hvis du kobler i delte biblioteker i din søknad de som arver tillatelsene til søknaden, så hvis din app trenger kontaktlisten eller trenger GPS-posisjonen for å fungere og du kobler i en reklame bibliotek, for eksempel, at annonsen bibliotek vil også være i stand til å få tilgang til kontaktene og også være i stand til å få tilgang til GPS-posisjon, og utvikleren av programmet vet ingenting om den koden som kjører i annonsen biblioteket. De er bare å koble det inn fordi de ønsker å tjene penger på deres app. Det er her-og jeg skal snakke om noen eksempler på dette med et program som heter Pandora, hvor en programutvikler kan uforvarende bli lekker informasjon fra sine brukere på grunn av bibliotekene de har knyttet i. Kartlegging av landskapet der ute, ser på alle de forskjellige apps som har blitt rapportert i nyhetene som ondsinnede eller gjøre noe brukerne ikke ønsket og deretter inspisere en rekke apps-vi gjør en mye statisk binære analyse på mobile apps, så vi har inspisert dem og så på selve koden- vi kom opp med det vi kaller vår topp ti liste over risikofylt atferd i applikasjoner. Og det er brutt ned i to seksjoner, ondsinnet kode, så disse er dårlige ting at apps kan være å gjøre som er sannsynlig å være noe som en ondsinnet individ har spesielt satt i søknaden, men det er litt uklar. Det kan være noe som en utbygger mener er greit, men det ender opp med å bli tenkt på som ondsinnet av brukeren. Og så den andre delen er det vi kaller koding sårbarheter, og dette er ting der utbygger i utgangspunktet er å gjøre feil eller bare ikke forstår hvordan å skrive app sikkert,  og det er å sette app brukeren i fare. Jeg kommer til å gå gjennom disse i detalj og gi noen eksempler. For referanse, ønsket jeg å sette opp OWASP mobile topp 10-listen. Dette er de 10 spørsmålene som en gruppe på OWASP, Open Web Application Security Project, har de en arbeidsgruppe jobber med en mobil topp 10-listen. De har en veldig berømt web topp 10 liste, som er topp 10 risikable ting du kan ha i en web-applikasjon. De gjør det samme for mobil, og deres liste er litt annerledes enn vår. 6 ut av det 10 er de samme. De har fire som er forskjellige. Jeg tror de har en liten bit av en annen ta på risiko i mobile apps der mye av sine problemer er egentlig hvordan programmet kommuniserer til en back-end server eller hva som skjer på back-end server, ikke så mye apps som har risikoatferd som er like enkle klient apps. De i rødt her er forskjellene mellom de to listene. Og noen av mine forskerteam har faktisk bidratt til dette prosjektet, så vi får se hva som skjer over tid, men jeg tror det takeaway her er Vi vet egentlig ikke hva topp 10-listen er i mobile apps fordi de har egentlig bare eksistert i to eller tre år nå, og det har ikke vært nok tid til å virkelig forskning operativsystemene og hva de er i stand til, og det har ikke vært nok tid for den skadelige samfunnet, om du vil, å ha tilbrakt nok tid prøver å angripe brukere gjennom mobile apps, så jeg forventer at disse listene til å endre litt. Men for nå, disse er de beste 10 ting å bekymre seg for. Du lurer kanskje på mobilsiden hvor kommer den ondsinnede mobil kode- hvordan det kommer til enheten? North Carolina State har et prosjekt kalt Mobile Malware Genome Project hvor de er å samle så mye mobil malware som de kan, og analysere det, og de har brutt ned injeksjons vektorer at den mobile malware bruker, og 86% bruker en teknikk som kalles ompakking, og dette er bare på Android-plattformen kan du virkelig gjøre dette ompakking. Årsaken er Android kode er bygget med en Java bytekode som kalles Dalvik som er lett decompilable. Hva skurken kan gjøre er ta en Android-applikasjon, dekompilere det, setter sin ondsinnet kode, rekompilere det, og deretter sette den opp i App Store påstås å være en ny versjon av programmet, eller bare kanskje endre navnet på programmet. Hvis det var en slags lek, endre navnet litt, og så dette ompakking er hvordan 86% av mobile malware blir distribuert. Det er en annen teknikk som kalles oppdatering som er svært lik ompakking, men du faktisk ikke sette den ondsinnede koden i. Det du gjør er at du satt i et lite oppdateringsmekanismen. Du dekompilere, sette deg i en oppdatering mekanisme, og du rekompilere det, og deretter når programmet kjører det trekker ned malware på enheten. Langt de fleste er de to teknikkene. Det er egentlig ikke mye nedlasting drive-bys eller drive-by downloads på mobiler, som kan være som et phishing-angrep. Hei, sjekk ut dette virkelig kul nettside, eller må du gå til denne nettsiden og fylle ut dette skjemaet å holde fortsetter å gjøre noe. De er phishing-angrep. Det samme kan skje på den mobile plattformen der de peke på en mobil app å laste ned, si "Hei, dette er Bank of America." "Vi ser at du bruker dette programmet." "Du bør laste ned denne annen applikasjon." Teoretisk sett, som kunne jobbe. Kanskje det bare ikke blir brukt nok til å avgjøre om det er vellykket eller ikke, men de har funnet at mindre enn 1% av den tid som teknikken er brukt. Flertallet av tiden det er virkelig en ompakket kode. Det er en annen kategori som heter stående der noen bare bygger en helt ny søknad. De bygger et program som gir seg ut for å være noe. Det er ikke en ompakking av noe annet, og som har den ondsinnede koden. Det er brukt 14% av tiden. Nå ønsker jeg å snakke om hva som er den ondsinnede koden gjør? En av de første malware der ute du kan vurdere en spyware. Det spioner utgangspunktet på brukeren. Den samler e-postmeldinger, SMS-meldinger. Det viser på mikrofonen. Det høster kontakten boken, og det sender det til noen andre. Denne typen spyware finnes på PC, så det gir mening for folk å prøve å gjøre dette på mobile enheter. En av de første eksemplene på dette var et program som heter Secret SMS Replicator. Det var i Android Marketplace for et par år siden, og ideen var hvis du hadde tilgang til noens Android-telefon at du ønsket å spionere på, så kanskje det er din ektefelle eller signifikante andre, og du ønsker å spionere på sine tekstmeldinger, du kan laste ned dette programmet og installere det og konfigurere den å sende en SMS-melding til deg med en kopi av hver SMS-melding de fikk. Dette er åpenbart i brudd av App Store når det gjelder service, og dette ble fjernet fra Android Marketplace innen 18 timer av det å være der, så et svært lite antall personer var i fare på grunn av dette. Nå tror jeg, dersom programmet ble kalt noe kanskje litt mindre provoserende som Secret SMS Replicator det sannsynligvis ville ha fungert mye bedre. Men det var litt opplagt. En av de tingene vi kan gjøre for å finne ut om apps har dette atferd som vi ikke vil ha er å inspisere koden. Dette er faktisk veldig lett å gjøre på Android fordi vi kan dekompilere apps. På iOS kan du bruke en disassembler som IDA Pro å se på hva APIer app som ringer og hva det gjør. Vi skrev vår egen binær statisk analysator for vår kode og vi gjør dette, og så hva du kan gjøre er at du kan si vil enheten gjør noe som er utgangspunktet spionere på meg eller sporer meg? Og jeg har noen eksempler her på iPhone. Denne første eksempel er hvordan man skal få tilgang til UUID på telefonen. Dette er faktisk noe som Apple har nettopp utestengt for nye applikasjoner, men gamle programmer som du kan ha som kjører på telefonen kan fortsatt gjøre dette, og slik at unike identifikatoren kan brukes til å spore dere på tvers av mange ulike programmer. På Android, har jeg et eksempel her for å få enhetens plassering. Du kan se at hvis at API-kall er det at app er sporing, og du kan se om det blir fint sted eller grov plassering. Og så på bunnen her, har jeg et eksempel på hvordan på Blackberry en søknad kan få tilgang til e-postmeldinger i innboksen din. Dette er den type ting du kan inspisere å se hvis programmet er å gjøre disse tingene. Den andre store kategorien av ondsinnet atferd, og dette er trolig den største kategorien nå, er uautorisert oppringing, uautorisert premium SMS tekstmeldinger eller uautoriserte betalinger. En annen ting som er unikt med telefonen er at enheten er koblet til en faktureringskonto, og når aktiviteter skjer på telefonen det kan skape kostnader. Du kan kjøpe ting over telefon, og når du sender en premium SMS tekstmelding du faktisk gir penger til konto innehaveren av telefonnummeret på den andre siden. Disse ble satt opp for å få aksjekurser eller få din daglige horoskop eller andre ting, men de kan settes opp til å bestille et produkt ved å sende en SMS. Folk gir penger til Røde Kors ved å sende en tekstmelding. Du kan gi $ 10 på den måten. Angriperne, hva de har gjort er de satt opp kontoer i utlandet, og de bygger inn i malware at telefonen vil sende en premium SMS tekstmelding, si, et par ganger om dagen, og på slutten av den måneden du oppdager at du har brukt titalls eller kanskje hundrevis av dollar, og de går unna med pengene. Dette ble så ille at dette var den aller første som Android Market eller Google sted-det var Android Marketplace på den tiden, og det er nå Google Play-det første som Google begynte å sjekke etter. Da Google startet med å distribuere Android-apps i sin App Store de sa de ikke skulle se etter noe. Vi vil trekke apps når vi har fått beskjed om at de har brutt våre vilkår for tjenesten, men vi kommer ikke til å se etter noe. Vel, om et år siden det ble så ille med denne premium SMS malware at dette er den aller første de begynte å sjekke etter. Hvis en app kan sende SMS-meldinger de videre manuelt granske det programmet. De ser for APIer som kaller dette, og nå siden da Google har utvidet, men dette var den første tingen som de begynte å se etter. Noen andre apps som gjorde noen SMS-tekstmeldinger, denne Android Qicsomos, tror jeg det kalles. Det var denne aktuelle hendelsen på mobilen hvor dette CarrierIQ kom ut som spyware satt på enheten ved bærere, slik at folk ville vite om deres telefon ble utsatt for dette, og dette var en gratis app som testet det. Vel, selvfølgelig, hva dette programmet gjorde var det sendt premium SMS tekstmeldinger, så ved å teste for å se om du er infisert med spyware du lastet malware på enheten din. Vi så det samme skje i siste Super Bowl. Det var en falsk versjon av Madden fotballkamp som sendte premium SMS tekstmeldinger. Det faktisk forsøkt å lage en bot nettverk også på enheten. Her har jeg noen eksempler. Interessant nok, Apple var ganske smart, og de ikke tillater programmer å sende SMS-meldinger i det hele tatt. Ingen app kan gjøre det. Det er en flott måte å bli kvitt en hel klasse av sårbarhet, men på Android kan du gjøre det, og selvfølgelig, på Blackberry kan du gjøre det også. Det er interessant at på Blackberry alt du trenger er internett-tillatelser å sende en SMS-melding. Den andre tingen virkelig at vi ser etter når vi er ute etter å se om noe er skadelig er bare noen form for uautorisert nettverksaktivitet, som ser på nettverksaktivitet app er ment til å ha sin funksjonalitet, og se på denne annen nettverksaktivitet. Kanskje en app, for å jobbe, må få data over HTTP, men hvis det gjør ting via e-post eller SMS eller Bluetooth eller noe sånt nå som app kan potensielt være skadelig, så dette er en annen ting du kan inspisere for. Og på dette lysbildet her jeg har noen eksempler på det. En annen interessant ting vi så med malware som skjedde tilbake i 2009, og det skjedde på en ny måte. Jeg vet ikke om det har skjedd så mye siden den gang, men det var en app som etterlignet en annen applikasjon. Det var et sett med programmer, og det ble kalt 09Droid angrep, og noen bestemte seg for at det var mange små, regionale, mellomstore banker som ikke har nettbank-applikasjoner, så hva de gjorde var at de bygget ca 50 nettbankapplikasjoner at alt de gjorde var å ta inn brukernavn og passord og omdirigere deg til nettsiden. Og så satte de alle disse opp i Google Marketplace, i Android Marketplace, og når noen søkte for å se om deres bank hadde et program de ville finne den falske applikasjonen, som samlet sine akkreditiver og deretter omdirigert dem til deres hjemmeside. Måten dette faktisk ble-apps var der oppe for et par uker, og det var tusenvis av nedlastinger. Måten dette kom frem i lyset var noen hadde et problem med ett av programmene, og de kalte sin bank, og de kalte sin banks kundeservice linje og sa, "Jeg har et problem med mobilbankapplikasjon." "Kan du hjelpe meg?" Og de sa: "Vi har en mobilbankapplikasjon." Det startet etterforskningen. At banken heter Google, og deretter Google så og sa, "Wow, har samme forfatter skrevet 50 bankapplikasjoner," og tok dem alle ned. Men sikkert dette kunne skje igjen. Det er en liste over alle de forskjellige bankene her som var en del av denne svindelen. Den andre tingen en app kan gjøre er å presentere UI av et annet program. Mens det kjører det kunne dukke opp på Facebook-UI. Det står at du må sette inn ditt brukernavn og passord for å fortsette eller sette opp noe brukernavn og passord UI for et nettsted at kanskje brukeren benytter bare for å prøve å lure brukeren til å sette sine akkreditiver i. Dette er virkelig en rett parallell av e-phishing-angrep der noen sender deg en e-postmelding og gir deg i utgangspunktet en falsk UI for et nettsted at du har tilgang til. Den andre tingen vi ser etter i ondsinnet kode er system modifikasjon. Du kan se etter alle API-kall som krever root privilegium å utføre riktig. Endre enhetens web proxy ville være noe som en søknad bør ikke være i stand til å gjøre. Men hvis programmet har kode i det å gjøre det du vet at det er nok en ondsinnet applikasjon eller svært stor sannsynlighet for å være et skadelig program, og så hva som ville skje er at app ville ha noen måte å eskalere privilegium. Det ville ha noen opptrapping av privilegier utnytte i søknaden, og deretter når det eskalerte privilegier det ville gjøre disse system modifikasjoner. Du kan finne malware som har privilegieopptrapping i det selv uten å vite hvordan det privilegium opptrapping utnytte kommer til å skje, og det er en fin og enkel måte å lete etter malware. DroidDream var trolig den mest berømte stykke Android malware. Jeg tror det påvirket om lag 250.000 brukere i løpet av noen få dager før den ble funnet. De pakket 50 falske søknader, sette dem i Android app store, og i hovedsak er det brukt Android jailbreak-kode for å eskalere rettigheter og deretter installere en kommando og kontroll og slå alle ofrene inn i en bot net, men du kunne ha oppdaget dette hvis du skannet søknaden og bare leter etter API-kall som krevde root tillatelse til å utføre riktig. Og det er et eksempel her jeg har som er å endre proxy, og dette faktisk er kun tilgjengelig på Android. Du kan se jeg gir deg en masse eksempler på Android fordi det er der de mest aktive malware økosystem er fordi det er veldig lett for en angriper å få ondsinnet kode inn i Android Marketplace. Det er ikke så lett å gjøre det i Apple App Store fordi Apple krever utviklere å identifisere seg og registrere koden. De faktisk sjekke hvem du er, og Apple er faktisk saumfarer søknadene. Vi ser ikke mye ekte malware der enheten blir kompromittert. Jeg vil snakke om noen eksempler der det er virkelig personvern som begynner å bli kompromittert, og det er det som egentlig skjer på Apple-enheten. En annen ting å se etter ondsinnet kode, risikabelt kode i enheter er logiske eller tidsinnstilte bomber, og tidsinnstilte bomber er trolig mye lettere å se etter enn logiske bomber. Men med tidsinnstilte bomber, hva du kan gjøre er at du kan se etter stedene i koden hvor tiden blir testet eller en absolutt tid er sett for før visse funksjoner i appen som skjer. Og dette kan gjøres for å skjule at aktivitet fra brukeren, så det skjer sent på kvelden. DroidDream gjorde all sin aktivitet mellom 23:00 og 8 AM lokal tid å prøve å gjøre det mens brukeren ikke kan bruke sin enhet. En annen grunn til å gjøre dette på er hvis folk bruker atferdsanalyse av et program, kjører programmet i en sandkasse for å se hva den virkemåten til programmet er, de kan bruke tidsbasert logikk for å gjøre aktiviteten når programmet er ikke i sandkassen. For eksempel, en App Store som Apple kjører programmet, men de sannsynligvis ikke kjøre hver applikasjon for, si, 30 dager før godkjenne det, slik at du kan sette logikken i applikasjonen som sa, ok, bare gjør det dårlig ting etter 30 dager har gått av eller etter 30 dager etter publiseringsdato av søknaden, og som kan bidra til at ondsinnet kode skjul fra folk inspeksjon for det. Hvis anti-virus selskaper kjører ting i sandkasser eller app butikker selv er dette kan hjelpe skjule at fra det inspeksjon. Nå, baksiden av det er det er lett å finne med statisk analyse, så faktisk inspisere koden du kan se etter alle steder der programmet tester tid og inspisere den måten. Og her har jeg noen eksempler på disse tre forskjellige plattformer hvordan tiden kan bli sjekket for av app maker slik at du vet hva du skal se etter hvis du inspisere app statisk. Jeg bare gikk gjennom en hel haug med forskjellige ondsinnede aktiviteter som vi har sett i naturen, men hvilke som er mest utbredt? Samme studie fra North Carolina State Mobile Genome Project publisert noen data, og det var i utgangspunktet fire områder at de så hvor det var mye aktivitet. 37% av apps gjorde opptrapping av privilegier, så de hadde noen form for jailbreak-kode i det hvor de prøvde å eskalere privilegier, slik at de kunne gjør API-kommandoer som kjører som operativsystem. 45% av apps der ute gjorde premium SMS, så det er en stor prosentandel som prøver å direkte tjene penger. 93% gjorde fjernkontroll, slik at de forsøkte å sette opp en bot net, en mobil bot net. Og 45% høstet identifiseringsinformasjon som telefonnumre, UUID, GPS-posisjon, brukerkontoer, og dette legger opp til mer enn 100 fordi de fleste malware prøver å gjøre noen av disse tingene. Jeg kommer til å bytte til den andre halvparten og snakke om kode sårbarheter. Dette er den andre halvdelen av risikofylt aktivitet. Det er her i hovedsak utvikleren er å gjøre feil. En legitim utvikler skrive en legitim app gjør feil eller er uvitende om risikoen ved den mobile plattformen. De vet bare ikke hvordan å lage en sikker mobil app, eller noen ganger utvikleren ikke bryr seg om å sette brukeren i fare. Noen ganger en del av sin forretningsmodell kan være høsting brukerens personlige informasjon. Det er liksom den andre kategorien, og det er derfor noe av dette ondsinnet versus legitime begynner å blø over fordi det er forskjell på meninger mellom hva brukeren ønsker og hva brukeren anser risikabelt og hva programutvikleren anser risikabelt. Selvfølgelig er det ikke søknaden utbyggers data i de fleste tilfeller. Og så til slutt, er en utvikler kan koble på en annen måte dette skjer et felles bibliotek som har sårbarheter eller denne risikoatferd i det Uvisst dem. Den første kategorien er sensitive lekkasje data, og dette er når programmet samler inn informasjon som plassering, adressebok informasjon, eierinformasjon og sender det av enheten. Og når den er av enheten, vet vi ikke hva som skjer med denne informasjonen. Det kan lagres usikret av programutvikleren. Vi har sett programutviklere bli kompromittert, og dataene som de er lagring blir tatt. Dette skjedde for noen måneder siden til en utvikler ned i Florida hvor et stort antall-det var iPad UUID og enhetsnavn ble lekket fordi noen, jeg tror det var anonym, hevdet å gjøre dette, brøt seg inn i denne utviklerens servere og stjal millioner av iPad UUID og datamaskinnavn. Ikke den mest risikable informasjon, men hva hvis det var lagring av brukernavn og passord og privatadresser? Det er mange apps som lagrer den slags informasjon. Risikoen er der. En annen ting som kan skje er hvis utbygger ikke tar vare å sikre datakanalen, og det er en annen stor sårbarhet Jeg kommer til å snakke om, at data sendes i klartekst. Hvis brukeren er på et offentlig Wi-Fi-nettverk eller noen er sniffing internett et sted langs den bane som data blir utsatt for. En svært kjent sak av denne informasjonen lekkasje skjedde med Pandora, og dette er noe vi forsket på Veracode. Vi hørte at det var en-Jeg tror det var en Federal Trade Commission Undersøkelsen skjer med Pandora. Vi sa, "Hva skjer der? La oss begynne å grave i Pandora program." Og hva vi bestemt var Pandora-programmet samlet kjønn og alder, og det har også vist GPS-posisjonen din, og Pandora søknad gjorde dette for det de sa var legitime grunner. Musikken som de skulle spille-Pandora er en musikkstreaming app- musikken de spilte var bare lisensiert i USA, så de måtte sjekke for å overholde sine lisensavtaler som de hadde for musikken at brukeren var i USA. De ønsket også å være i samsvar med foreldrerådgivende rundt voksent språk i musikk, og så det er et frivillig program, men de ønsket å være i samsvar med det og ikke spille eksplisitte tekster til barn 13 og under. De hadde legitime grunner for å samle inn disse dataene. Deres app hadde tillatelse til å gjøre det. Brukere trodde dette var lovlig. Men hva skjedde? De knyttet sammen i tre eller fire ulike annonsebiblioteker. Nå plutselig alle disse annonsebibliotekene får tilgang til den samme informasjonen. Annonse biblioteker, hvis du ser på koden i annonse bibliotekene hva de gjør er hver annonse bibliotek sier "Har min app har tillatelse til å få GPS-posisjon?" "Å, det gjør? Ok, fortell meg GPS-posisjonen." Hver eneste annonse biblioteket gjør det, og hvis programmet ikke har GPS tillatelse det vil ikke være i stand til å få det, men hvis den gjør det, vil det bli det. Dette er hvor forretningsmodellen av annonse bibliotekene er i motsetning til personvernet til brukeren. Og det har vært studier der ute som vil si at hvis du kjenner alderen av en person, og du vet hvor de befinner seg hvor de sover om natten, fordi du har sine GPS-koordinater mens de kanskje sover, vet du nøyaktig hvem denne personen er fordi du kan bestemme hvilke medlem av denne husstanden er den personen. Virkelig dette er å identifisere til annonsører nøyaktig hvem du er, og det ser ut som det var legitimt. Jeg vil bare ha min streaming av musikk, og dette er den eneste måten å få det. Vel, vi utsatt dette. Vi skrev dette opp i flere blogginnlegg, og det viste seg at noen fra Rolling Stone magazine lese en av våre blogginnlegg, og skrev sin egen blogg i Rolling Stone om det, og allerede neste dag Pandora trodde det var en god idé å fjerne annonse bibliotekene fra sitt program. Så vidt jeg vet de er de eneste, de skal commended. Jeg tror de er den eneste freemium type app som har gjort dette. Alle de andre Freemium apps har denne samme atferd, så du er nødt til å tenke på hva slags data du gir disse Freemium applikasjoner fordi det er alt kommer til annonsører. Praetorian også gjorde en studie om delte biblioteker og sa, "La oss se på hva som delte biblioteker er de beste delte biblioteker", og dette var dataene. De analyserte 53 000 apps, og nummer en delt bibliotek var Admob. Det var faktisk i 38% av søknadene der ute, så 38% av søknadene du bruker er trolig høste dine personlige opplysninger og sende det til annonsenettverk. Apache og Android var 8% og 6%, og så disse andre de ned på bunnen, Google Ads, Flurry, Mob City og Millennial Media, disse er alle annonseselskaper, og deretter, interessant nok, 4% knyttet i Facebook-biblioteket sannsynligvis å gjøre autentisering via Facebook slik app kan autentisere Facebook. Men det betyr også aksjeselskap Facebook kontrollerer koden som kjører i 4% av Android mobile apps der ute, og de har tilgang til alle data som at programmet har tillatelse til å få på. Facebook hovedsak prøver å selge annonseplass. Det er deres forretningsmodell. Hvis du ser på hele dette økosystemet med disse tillatelsene og delte biblioteker du begynner å se at du har mye risiko i en tilsynelatende legitimt program. Det samme lignende ting som har skjedd med Pandora skjedde med et program som heter Path, og bane trodde de var å være hjelpsomme, vennlige utviklere. De var bare prøver å gi deg en god brukeropplevelse, og det viste seg at uten å spørre brukeren eller fortelle brukeren noe- og dette skjedde på iPhone og på Android, Pandora app var på iPhone og Android- at banen søknaden var flytte hele adresseboken og sender den til bane bare når du installerte og kjørte programmet, og de ikke fortelle deg om dette. De syntes det var veldig nyttig for deg å være i stand til å dele med alle menneskene i adresseboken din at du bruker Sti søknaden. Vel, tydeligvis Sti trodde dette var bra for deres bedrift. Ikke så stor for brukeren. Du må tenke at det er én ting om kanskje en tenåring bruker dette programmet, og deres mange venner er der inne, men hva hvis det er administrerende direktør i et selskap som installerer Sti og deretter plutselig sin helhet adresseboken er der oppe? Du kommer til å få mye potensielt verdifull kontaktinformasjon for mange mennesker. En reporter fra New York Times, kan du være i stand til å få telefonnummeret for ex presidenter fra sin adressebok, så åpenbart mye sensitiv informasjon blir overført med noe sånt som dette. Det var slik en stor klaff om dette at Sti beklaget. De endret sin app, og det enda påvirket Apple. Apple sa: "Vi kommer til å tvinge app-leverandører til å be brukere hvis de kommer til å samle hele sin adressebok. " Det ser ut som det som skjer her er når det er ett stort brudd på personvern, og det gjør pressen vi ser en endring der ute. Men selvfølgelig, det er andre ting der ute. Linkedin-program høster kalenderoppføringer, men Apple gjør ikke brukeren bedt om det. Kalenderoppføringer kan ha sensitiv informasjon på dem også. Hvor har du tenkt å trekke linjen? Dette er virkelig slags et utviklende sted hvor det er egentlig ingen god standard der ute for brukerne å forstå når deres informasjon kommer til å være i faresonen og når de kommer til å vite det blir tatt. Vi skrev en app på Veracode kalt Adios, og egentlig tillot det deg å peke app på din iTunes-katalogen og se på alle de programmene som ble høsting din fulle adressebok. Og som du kan se på denne listen her, Angry Birds, AIM, AroundMe. Hvorfor Angry Birds trenger adresseboken? Jeg vet ikke, men det gjør liksom. Dette er noe som mange, mange programmer gjør. Du kan inspisere koden for dette. Det er veldefinerte APIer for iPhone, Android og Blackberry å komme på adresseboken. Du kan virkelig enkelt kontrollere for dette, og dette er hva vi gjorde i vår Adios søknad. Den neste kategorien, Unsafe Sensitive Data Storage, er noe der utviklere ta noe som en pinne eller et kontonummer eller et passord og oppbevare det i klartekst på enheten. Enda verre, de kan lagre det i et område på telefonen som er globalt tilgjengelig, som SD-kortet. Du ser dette oftere på Android fordi Android åpner for et SD-kort. IPhone-enheter ikke. Men vi engang så dette skje i en Citigroup-program. Deres online bankapplikasjon lagret kontonumrene usikker, bare i den klare, så hvis du mistet din enhet, egentlig du mistet din bankkonto. Dette er grunnen til at jeg personlig ikke gjør banking på min iPhone. Jeg tror det er for risikabelt akkurat nå til å gjøre disse typer aktiviteter. Skype gjorde det samme. Skype, selvfølgelig, har en saldo, et brukernavn og et passord som tilgang til denne balansen. De ble lagring av all denne informasjonen i klartekst på den mobile enheten. Jeg har noen eksempler her for å lage filer som ikke har de riktige tillatelsene eller skrive til disk og ikke har noen kryptering skje for det. Det neste området, Unsafe Sensitive Dataoverføring, Jeg har antydet dette et par ganger, og på grunn av offentlige Wi-Fi dette er noe som apps absolutt trenger å gjøre, og dette er sannsynligvis det vi ser gå galt mest. Jeg vil si-faktisk, tror jeg at jeg har de faktiske dataene, men det er nær halvparten av mobile applikasjoner skru opp med å gjøre SSL. De bare ikke bruke APIene riktig. Jeg mener, er alt du har å gjøre er å følge instruksjonene og bruke APIer, men de gjør ting som ikke sjekke om det er et ugyldig sertifikat i den andre enden, ikke sjekke om den andre enden prøver å gjøre en protokoll nedgradering angrep. Utviklerne, ønsker de å få avkrysnings deres, ikke sant? Deres krav er å bruke dette til å selge. De har brukt dette for å selge. Kravet er ikke til å bruke dette for å selge trygt, og så dette er grunnen til at alle programmer som bruker SSL for å sikre data som det blir overført av enheten virkelig trenger å bli inspisert å sørge for at ble implementert riktig. Og her har jeg noen eksempler hvor du kan se et program kanskje bruker HTTP i stedet for HTTPS. I noen tilfeller apps vil falle tilbake til HTTP hvis HTTPS ikke fungerer. Jeg har en annen samtale her på Android, hvor de har deaktivert sertifikatsjekk, så et man-in-the-middle-angrep kan skje. Et ugyldig sertifikat vil bli akseptert. Disse er alle tilfeller der angripere kommer til å være i stand til å komme på det samme Wi-Fi-tilkobling som bruker og tilgang til alle data som blir sendt over internett. Og til slutt, den siste kategorien jeg har her er hardkodet passord og nøkler. Vi faktisk se en masse utviklere bruker samme koding stil som de gjorde da de var å bygge web server-applikasjoner, slik at de bygger en Java server applikasjon, og de er hardcoding nøkkelen. Vel, når du bygger et serverprogram, ja, hardcoding nøkkelen er ikke en god idé. Det gjør det vanskelig å endre. Men det er ikke så ille på serversiden, fordi hvem som har tilgang til serversiden? Bare administratorer. Men hvis du tar den samme koden, og du helte den over til en mobilapplikasjon nå alle som har den mobile applikasjonen har tilgang til denne hardkodet nøkkel, og vi faktisk se dette en rekke ganger, og jeg har noen statistikk på hvor ofte vi ser dette skje. Det faktisk var i eksempelet kode som MasterCard publisert på hvordan du skal bruke deres tjeneste. Eksempelet kode viste hvordan du ville bare ta passord og legg den i en hardkodet streng rett der, og vi vet hvordan utviklerne elsker å kopiere og lime inn kodesnutter når de prøver å gjøre noe, så du kopiere og lime inn kodebiten at de ga som eksempel kode, og du har en usikker applikasjon. Og her har vi noen eksempler. Denne første er en vi ser mange der de hardcode dataene rett inn i en URL som blir sendt. Noen ganger ser vi streng passord = passordet. Det er ganske lett å oppdage, eller streng passord på Blackberry og Android. Det er faktisk ganske lett å sjekke for grunn nesten alltid utvikler navngir variable som holder passordet annen variant av passord. Jeg nevnte at vi gjør statisk analyse på Veracode, så vi har analysert flere hundre Android-og iOS-applikasjoner. Vi har bygget fulle modeller av dem, og vi er i stand til å skanne dem for ulike sårbarheter, spesielt sikkerhetsproblemene jeg snakket om, og jeg har noen data her. 68.5% av Android-apps vi så på hadde brutt kryptografisk kode, som for oss, kan vi ikke oppdage om du har gjort din egen krypto rutine, ikke at det er en god idé, men dette er faktisk bruker de publiserte APIer som finnes på plattformen, men gjør dem på en slik måte at krypto vil være sårbare, 68,5. Og dette er for folk som sender oss sine søknader faktisk fordi de tror det er en god idé å gjøre sikkerhetstesting. Disse er allerede folk som er sannsynligvis tenker sikkert, så det er nok enda verre. Jeg ikke snakke om kontroll linjeskift injeksjon. Det er noe vi sjekker for, men det er ikke så risikabelt et problem. Informasjonslekkasje, dette er hvor sensitive data blir sendt av enheten. Vi fant at i 40% av søknadene. Tid og stat, de er rase tilstand typen saker, vanligvis ganske vanskelig å utnytte, så jeg ikke snakke om det, men vi så på det. 23% hadde SQL-injeksjon problemer. Mange vet ikke at mange programmer bruke en liten liten SQL database på sin back end til å lagre data. Vel, hvis dataene som du gripe tak over nettverket har SQL-injeksjon angrep strenger i det noen kan kompromittere enheten gjennom det, og så tror jeg vi finner om 40% av web-applikasjoner har dette problemet, som er et stort problem epidemi. Vi synes det er 23% av tiden i mobile apps og det er sannsynligvis fordi mange flere web-applikasjoner bruker SQL enn mobil. Og da vi fortsatt se noen cross-site scripting, autorisasjonsspørsmål, og deretter legitimasjonsadministrasjon, det er der du har din hardkodet passord. I 5% av søknadene ser vi at. Og så har vi noen data på iOS. 81% hadde feilhåndteringen. Denne er fortrinnsvis av en kodekvaliteten, men 67% hadde kryptografiske problemer, så ikke fullt så ille som Android. Kanskje APIene er litt enklere, er eksempelkoder litt bedre på iOS. Men fortsatt en svært høy prosentandel. Vi hadde 54% med informasjonslekkasje, om lag 30% med buffer styringsfeil. Det er steder hvor det kan potensielt være et problem med minnekorrupsjon. Det viser seg at det er ikke så mye av et problem for utnyttelse på iOS fordi all koden må være signert, så det er vanskelig for en angriper å kjøre vilkårlig kode på iOS. Kodekvalitet, katalog traversering, men da legitimasjon ledelsen her på 14,6%, så verre enn på Android. Vi har folk ikke håndterer passord riktig. Og da de numeriske feil og buffer overflow, de er mer kommer til å være kodekvaliteten på iOS. Det var det for min presentasjon. Jeg vet ikke om vi er ute av tid eller ikke. Jeg vet ikke om det er noen spørsmål. [Mann] En rask spørsmål rundt fragmentering og Android Market. Apple minst eier patching. De gjør en god jobb med å få den ut der, mens mindre så i Android plass. Du trenger nesten å jailbreak telefonen for å holde deg oppdatert med den nåværende versjonen av Android. Ja, det er et stort problem, og så hvis du tenker på- [Mann] Hvorfor kan ikke du gjenta det? Å, akkurat, så spørsmålet var hva om fragmentering av operativsystemet på Android-plattformen? Hvordan påvirker risikoen ved disse enhetene? Og det faktisk er et stort problem fordi det som skjer er de eldre enheter, når noen kommer opp med en jailbreak på den enheten, egentlig det er opptrapping av privilegier, og til at operativsystemet er oppdatert noen malware kan deretter bruke denne sårbarheten til helt kompromittere enheten, og hva vi ser på Android er for å få et nytt operativsystem Google har til å sette ut operativsystemet, og deretter maskinvareprodusenten har til å tilpasse den, og deretter transportøren har å tilpasse den og levere den. Du har i utgangspunktet tre bevegelige deler her, og det er å snu seg at bærere ikke bryr seg, og maskinvareprodusenter ikke bryr seg, og Google er ikke prodding dem nok å gjøre noe, så egentlig over halvparten av enhetene der ute har operativsystemer som har disse privilegieopptrapping sårbarheter i dem, og så hvis du får malware på din Android-enhet er det mye mer av et problem. Ok, tusen takk. [Applaus] [CS50.TV]