>> [Seminarium] [Försvar Bakom Device: Mobile Application Security]
[Chris Wysopal] [Harvard University]
[Det här är CS50.] [CS50.TV]
>> God eftermiddag. Mitt namn är Chris Wysopal.
Jag är CTO och medgrundare av Veracode.
Veracode är ett program säkerhetsföretag.
Vi testar alla typer av olika applikationer,
och vad jag ska prata om idag är mobil applikation säkerhet.
Min bakgrund är att jag har gjort säkerhetsforskning
under mycket lång tid, förmodligen ungefär lika länge som vem som helst.
Jag började i mitten av 90-talet,
och det var en tid som var ganska intressant eftersom
Vi hade ett paradigmskifte i mitten av 90-talet.
Helt plötsligt allas dator var ansluten till Internet,
och sedan hade vi början till webbapplikationer,
och det är vad jag fokuserade på en hel del då.
Det är intressant.
Nu har vi en annan paradigmskifte sker med datorer,
vilket är övergången till mobila applikationer.
>> Jag tycker att det är lite av en liknande tid då det var i slutet av 90-talet
När vi undersökte webbapplikationer och hitta defekter som
sessionshantering fel och SQL-injektion
som egentligen inte existerade tidigare, och helt plötsligt var de överallt
i webbapplikationer, och nu en hel del av den tid jag tillbringar
tittar på mobila applikationer och tittar på vad som händer där ute i det vilda.
Mobila applikationer är verkligen kommer att bli den dominerande datorplattform,
så vi verkligen behöver spendera mycket tid om du är i säkerhetsbranschen
med fokus på webbapplikationer.
Det fanns 29 miljarder mobilappar ner under 2011.
Det spås bli 76 miljarder appar 2014.
Det finns 686 miljoner enheter som kommer att köpa i år,
så det är där människor kommer att göra
merparten av sin klient datorer framöver.
>> Jag pratade med en vice vd på Fidelity Investments
ett par månader sedan, och han sa att de bara såg mer trafik
göra ekonomiska transaktioner från sin kundbas
på sin mobil applikation än på deras hemsida,
så en vanlig användning för webben i det förflutna har varit
kontrollera dina aktiekurser, hantera din portfölj,
och vi faktiskt se att under 2012 omkoppling
att vara mer dominerande på den mobila plattformen.
Visst, om det inte kommer att bli någon brottslig verksamhet,
all skadlig aktivitet, det kommer att börja vara fokuserad på den mobila plattformen
med tiden som folk byta till det.
Om du tittar på den mobila plattformen,
att titta på riskerna med plattformen är det lämpligt att dela upp det i olika lager,
precis som du skulle göra det på en stationär dator,
och du tycker om de olika lagren, mjukvara, operativsystem,
nätverkslagret, hårdvara lager, och naturligtvis, det finns sårbarheter på alla dessa lager.
>> Samma sak händer på mobilen.
Men mobil, verkar det som om en del av dessa lager är sämre.
För en, är mer problematisk på mobil nätverkslagret
eftersom många människor har i sitt kontor eller hemma
kabelanslutningar eller de har säkra Wi-Fi-anslutningar,
och med en hel del mobila enheter du är uppenbarligen utanför hemmet
eller utanför kontoret en hel del, och om du använder Wi-Fi finns
Du kanske använder en osäker Wi-Fi-anslutning,
något som är en Wi-Fi-anslutning,
så när vi tänker på mobila appar som vi måste ta hänsyn till
att nätverksmiljön är mer riskfyllda för de tillämpningar
När Wi-Fi används.
Och när jag kommer in i flera av de risker mobila applikations
ser du varför det är viktigare.
Det finns risker på hårdvarunivå på mobila enheter.
Detta är ett område med pågående forskning.
Folk kallar dessa bredbandsattacker eller baseband attacker
där du attackerar den fasta programvaran som lyssnar på radion.
>> Dessa är verkligen skrämmande attacker eftersom
användaren behöver inte göra någonting.
Du kan träffa massor av enheter inom RF intervall
på en gång, och det verkar som om varje gång denna forskning bubblar upp
det snabbt blir klassificerat där
folk susa in och säga: "Här, berätta om det, och snälla sluta prata om det."
Det finns en del forskning som pågår inom bredbandsområdet,
men det verkar vara mycket hysch hysch.
Jag tycker det är mer av en nationalstat typ av forskning som pågår.
Ett område med aktiv forskning, dock är operativsystemet lagret,
och återigen, detta är annorlunda än i den stationära datorvärlden
grund i den mobila rymden du har dessa grupper av människor som kallas jailbreakers,
och jailbreakers är annorlunda än vanliga forskare sårbarhets.
De försöker hitta sårbarheter i operativsystemet,
men anledningen till att de försöker hitta sårbarheter är inte
bryta sig in i någon annans maskin och äventyra den.
Det är att bryta sig in i sin egen dator.
>> De vill bryta sig in i sin egen mobil, ändra sina egna mobila operativsystem
så att de kan köra de program som de själva väljer
och byta saker med fulla administrativa rättigheter,
och att de inte vill berätta säljaren om detta.
De är inte som en säkerhetsforskare som är en vit hatt säkerhetsforskare
som kommer att göra ansvarsfull avslöjande och berättar säljaren om det.
De vill göra denna forskning, och de vill faktiskt publicera den
i en utnyttja eller ett rootkit eller en jailbreak-kod,
och de vill göra det strategiskt, som direkt efter
skeppen leverantörs det nya operativsystemet.
Du har denna kontradiktoriska relation
med OS-nivå sårbarheter på mobilen,
vilket jag tycker är ganska intressant, och ett ställe som vi ser det
det gör det så att det är bra publiceras utnyttja koden där ute
för kernel-nivå sårbarheter,
och vi har sett de som faktiskt utnyttjas av malware författare.
Det är lite annorlunda än i PC-världen.
Och sedan det sista skiktet är det övre skiktet, applikationsskiktet.
Det är vad jag ska prata om idag.
>> De andra skikten föreligger, och de andra skikten spela in i det,
men jag är oftast att tala om vad som händer på applikationslagret
där koden körs i sandlådan.
Det behöver inte ha administratörsbehörighet.
Det har att använda API: er i anordningen,
men ändå, kan en hel del skadlig aktivitet och en hel del risk att hända på det lagret
eftersom det är det lager där all information finns.
Apps kan komma åt all information på enheten
om de har rätt behörigheter,
och de kan få tillgång till olika sensorer på enheten,
GPS-sensor, mikrofon, kamera, vad har du.
Även om vi bara pratar om på applikationslagret
vi har en hel del risker där.
Den andra saken som är annorlunda med den mobila miljön
är alla operativsystem spelarna, oavsett om det är BlackBerry eller Android
eller iOS eller Windows Mobile, de har alla en finkornig tillstånd modell,
och detta är ett av de sätt som de inbyggda i operativsystemet
tanken att det är inte så riskabelt som du tror.
Även om du har alla dina kontakter på det, all din personliga information,
du har dina bilder, har du din plats på det,
du lagrar din bank pin för automatisk inloggning på det, det är säkert eftersom
apps måste ha vissa behörigheter för att komma åt vissa delar
av informationen på enheten, och användaren måste presenteras med
dessa behörigheter och säga okej.
>> Problemet med det är att användaren alltid säger okej.
Som en person som säkerhet, jag vet att du kan uppmana användaren,
säga något riktigt dåligt kommer att hända, du vill att det ska hända?
Och om de har bråttom eller är det något riktigt lockande på andra sidan av det,
som ett spel kommer att installeras som de har väntat på,
de ska klicka okej.
Det är därför jag säger på mitt bildspel här låt mig kasta fåglar på grisar redan,
och du kan se på bilden här finns det exempel på en BlackBerry tillstånd låda.
Det står "Var god ange BlackBerry Travel applikationsbehörigheter
efter att ha klickat på knappen nedan, "och i princip användaren är bara att säga
ställa in behörigheter och spara.
Här är en Android-prompt där den visar saker,
och faktiskt satt något som nästan ser ut som en varning.
Det har fått en sorts avkastnings skylt där säger nätverkskommunikation, telefonsamtal,
men användaren ska klicka på installera, eller hur?
Och sedan Apple man är helt ofarlig.
Det ger inte någon form av varning.
Det är bara Apple vill använda din nuvarande plats.
Visst du kommer att klicka okej.
>> Det är finkornig tillstånd modell,
och program måste ha en manifest-fil där de förklarar
de behörigheter som de behöver, och som kommer att få visas för användaren,
och användaren måste säga att jag ger dessa behörigheter.
Men låt oss vara ärliga.
Användarna är bara att alltid säga okej.
Låt oss ta en snabb titt på de behörigheter som dessa program ber om
och några av de behörigheter som finns där.
Detta företag Praetorian gjorde en undersökning förra året
av 53.000 ansökningar som analyserats i Android Market och 3: e parts marknaderna,
så detta är alla Android.
Och den genomsnittliga app begärt 3 behörigheter.
Vissa program begärde 117 behörigheter,
så uppenbart dessa är mycket finkornig och alldeles för komplicerat för en användare att förstå
om de är presenteras med denna app som behöver dessa 117 tillstånd.
Det är som det licensavtal för slutanvändare som är 45 sidor lång.
Kanske snart kommer de att ha ett alternativ där det är som
skriva ut behörigheter och skicka mig ett mail.
>> Men om man tittar på några av de bästa intressanta behörigheter
24% av de program som de ner ut ur 53.000
begärda GPS-information från enheten.
8% läser kontakterna.
4% skickade SMS och 3% mottaget SMS.
2% inspelat ljud.
1% bearbetats utgående samtal.
Jag vet inte.
Jag tror inte att 4% av de program i App Store måste verkligen skicka SMS-meddelanden,
så jag tror det är en antydan om att något oförutsett som händer.
8% av de apps behöver läsa din kontaktlista.
Det är nog inte nödvändigt.
En av de andra intressanta saker om behörigheter är
om du länkar i delade bibliotek i din ansökan
de ärver behörigheterna för ansökan,
så om din app behöver kontaktlistan eller behöver GPS-position för att fungera
och du länkar i en reklam-bibliotek, till exempel,
att annonsbiblioteket kommer också att kunna komma åt kontakterna
och också kunna få tillgång till GPS-position,
och utvecklaren av appen vet ingenting om den kod som körs i annonsbiblioteket.
De är bara att koppla det i att de vill tjäna pengar på sin app.
>> Det är här-och jag ska tala om några exempel på detta med
ett program som heter Pandora där en ansökan utvecklare
kanske omedvetet att läcka information
från sina användare på grund av biblioteken som de har länkat i.
Lantmäteri landskapet där ute, titta på alla olika apps
som har rapporterats i nyheterna som skadliga eller gör något som användaren inte ville
och sedan inspektera en massa appar-Vi gör en hel del statisk binär analys på mobila applikationer,
så vi har inspekterat dem och tittade på själva koden-
vi kom fram till det vi kallar vår 10 topp lista över riskfyllda beteenden i applikationer.
Och det är uppdelat i två sektioner, skadlig kod,
så dessa är dåliga saker som apps kanske gör att
kommer sannolikt att vara något som en illvillig individ
har särskilt lagt i ansökan, men det är lite suddig.
Det kan vara något som en utvecklare tycker är bra,
men det slutar som betraktas som skadliga för användaren.
>> Och sedan den andra delen är vad vi kallar kodning sårbarheter,
och det är saker där utvecklaren princip är att göra misstag
eller bara inte förstår hur man skriver appen ordentligt,
och det är att sätta appen användare i riskzonen.
Jag kommer att gå igenom dessa i detalj och ge några exempel.
För referens, jag ville sätta upp den OWASP mobil topp 10 listan.
Dessa är de 10 frågor som en grupp på OWASP,
Open Web Application Security Project, de har en arbetsgrupp
arbetar på en mobil topp 10 listan.
De har en mycket berömd webb topp 10 listan, som är topp 10
mest riskfyllda saker kan man ha i en webbapplikation.
De gör samma sak för mobilen,
och deras lista är lite annorlunda än vår.
6 ut ur 10 är desamma.
De har 4 som är olika.
Jag tror att de har lite av en annorlunda syn på
risk i mobila appar där en hel del av sina frågor
är verkligen hur programmet kommunicerar med en back-end server
eller vad som händer på back-end server,
inte så mycket program som har riskbeteende som är bara enkla klient apps.
>> De i rött här är skillnaderna mellan de två listorna.
Och en del av min forskargrupp har faktiskt bidragit till det här projektet,
så vi får se vad som händer med tiden, men jag tror att takeaway här är
Vi vet inte riktigt vad det topp 10 listan är i mobilappar eftersom
de har egentligen bara funnits i 2 eller 3 år nu,
och det har inte funnits tillräckligt med tid att verkligen forska i operativsystem
och vad de är kapabla till, och det inte har funnits tillräckligt med tid
för skadliga samhället, om man så vill, att ha spenderat tillräckligt med tid
försöker attackera användare genom mobila applikationer, så jag räknar med dessa listor för att ändra lite.
Men för nu, dessa är de 10 saker att oroa sig för.
Du kanske undrar på mobilsidan där gör skadlig mobil kod-
hur går det få på enheten?
North Carolina State har ett projekt som heter Mobile Malware Genome Project
där de samlar så mycket mobil skadlig kod som de kan och analysera det,
och de har brutit ner injektionsvektor att den mobila skadlig kod använder,
och 86% använder en teknik som kallas ompackning,
och detta är bara på Android-plattformen
kan du verkligen göra det här ompackning.
>> Anledningen är Android-kod är byggd med
en Java byte-kod som heter Dalvik som är lätt decompilable.
Vad den onde kan göra är
ta en Android-applikation, dekompilera den,
sätter sina skadlig kod, kompilera det,
och sedan lägga upp den i App Store som utger sig för att vara en ny version av denna ansökan,
eller bara kanske ändra namnet på programmet.
Om det var någon sorts spel, ändra namnet en aning,
och så denna ompaketering är hur 86% av mobil skadlig kod blir fördelade.
Det finns en annan teknik som kallas uppdatering som är
mycket lik ompackning, men du faktiskt inte sätta den skadliga koden i.
Vad du gör är att du lägger in en liten uppdatering mekanism.
Du dekompilera, sätta dig i en uppdateringsmekanism, och du kompilera det,
och sedan när programmet körs det drar ner skadlig kod på enheten.
>> De allra flesta är dessa två tekniker.
Det är egentligen inte mycket nedladdning drive-bys eller drive-by downloads på mobiler,
vilket skulle kunna vara som en nätfiskeattack.
Hej, kolla in denna riktigt cool hemsida,
eller du behöver gå till denna webbplats och fyll i formuläret
att hålla fortsatt att göra något.
De är phishing-attacker.
Samma sak kan hända på den mobila plattformen där de
pekar på en mobil app att ladda ner, säga "Hej, det här är Bank of America."
"Vi ser att du använder det här programmet."
"Du bör ladda ner andra program."
Teoretiskt skulle det fungera.
Kanske är det bara inte används tillräckligt för att avgöra om det är lyckat eller inte,
men de fann att mindre än 1% av tiden som teknik används.
Merparten av tiden är det verkligen en ompaketerade kod.
>> Det finns en annan kategori som kallas fristående
där någon bara bygger en helt ny applikation.
De bygger ett program som utger sig för att vara något.
Det är inte en ompaketering av något annat, och det har den skadliga koden.
Det används 14% av tiden.
Nu vill jag tala om vad som är den skadliga koden gör?
En av de första malware där ute
du kan överväga ett spionprogram.
Det spionerar i grunden på användaren.
Den samlar in e-post, SMS-meddelanden.
Det visar på mikrofonen.
Den skördar kontakt boken, och det skickar det till någon annan.
Denna typ av spionprogram finns på datorn,
så det verkar vettigt för människor att försöka göra detta på mobila enheter.
>> Ett av de första exemplen på detta var ett program som heter Secret SMS Replicator.
Det var i Android Marketplace för ett par år sedan,
och tanken var om du hade tillgång till någons Android-telefon
att du ville spionera på, så kanske det är din make
eller din andra och du vill spionera på sina textmeddelanden,
Du kan ladda ner den här appen och installera den och konfigurera den
att skicka ett SMS till dig med en kopia
för varje SMS-meddelande de fick.
Detta är naturligtvis i kränkningar av App Store gäller service,
och detta togs bort från Android Marketplace inom 18 timmar från det att vara där,
så ett mycket litet antal människor var i riskzonen på grund av detta.
Nu tror jag att programmet hette något kanske lite mindre provocerande
som Secret SMS Replicator det förmodligen skulle ha fungerat mycket bättre.
Men det var ganska självklart.
>> En av de saker vi kan göra för att avgöra om apps har detta beteende som vi inte vill ha
är att inspektera koden.
Det här är faktiskt riktigt lätt att göra på Android eftersom vi kan dekompilera apps.
På iOS kan du använda en disassembler som IDA Pro
att titta på vad Apis appen ringer och vad den gör.
Vi skrev vår egen binär statisk analysator för vår kod
och det gör vi, och så vad du kan göra är att du kan säga
inte enheten göra något som i grunden är spionerar på mig eller spåra mig?
Och jag har några exempel här på iPhone.
Det första exemplet är hur man kommer åt UUID på telefonen.
Detta är faktiskt något som Apple just har förbjudit för nya tillämpningar,
men gamla program som du kan ha som körs på telefonen kan fortfarande göra det här,
och så att unika identifierare kan användas för att spåra dig
i många olika applikationer.
>> På Android, jag har ett exempel här för att få enhetens plats.
Du kan se att om det API-anrop är där som app spårar,
och du kan se om det blir fint läge eller grova plats.
Och sedan på botten här, jag har ett exempel på hur på BlackBerry
ett program kan komma åt e-postmeddelanden i inkorgen.
Detta är den typ av saker som du kan kontrollera för att se
Om appen gör dessa saker.
Den andra stora kategorin av skadligt beteende, och detta är förmodligen den största kategorin nu,
är obehörig uppringning, obehörig premium SMS-meddelanden
eller obehöriga betalningar.
En annan sak som är unikt med telefonen
är att enheten är ansluten till ett faktureringskonto,
och när verksamheten sker i telefon
det kan skapa laddningar.
Du kan köpa saker via telefon,
och när du skickar ett premium SMS-meddelande du faktiskt ger pengar
till kontohavaren i telefonnumret på den andra sidan.
Dessa sattes upp för att få aktiekurser eller få din dagliga horoskop eller annat
men de kan ställas in för att beställa en produkt genom att skicka ett SMS.
Människor ger pengar till Röda Korset genom att skicka ett textmeddelande.
Du kan ge 10 $ på det sättet.
>> Angriparna, vad de har gjort är att de satt upp
konton i utlandet, och de bädda i malware
att telefonen kommer att skicka ett premium SMS-meddelande,
säga, ett par gånger om dagen, och i slutet av månaden som du inser att du har spenderat
tiotals eller kanske hundratals dollar, och de går iväg med pengarna.
Det blev så illa att det var det allra första som Android
Marketplace eller Googles plats-det var Android Marketplace på tiden,
och det är nu Google Play-det första som Google började kolla efter.
När Google började distribuera Android apps i deras App Store
de sa att de inte skulle kontrollera om någonting.
Vi ska dra appar när vi har anmälts att de har brutit våra användarvillkor,
men vi kommer inte att leta efter något.
Tja, ungefär ett år sedan blev det så illa med denna premium SMS-meddelande malware
att detta är den allra första de började kolla efter.
Om en app kan skicka SMS-meddelanden
de kontrollera denna ansökan vidare manuellt.
De letar efter de API: er som kallar detta,
och nu sedan Google har expanderat,
men detta var det första som de började leta efter.
>> Några andra program som gjorde några SMS-meddelanden,
denna Android Qicsomos, jag antar att det kallas.
Det var en aktuell händelse på mobilen där denna CarrierIQ kom ut
som spionprogram sätta på apparaten från transportörerna,
så att folk ville veta om deras telefon var utsatta för detta,
och detta var en gratis app som testade det.
Jo, naturligtvis, vad denna app gjorde var det skickade premium SMS-meddelanden,
så genom att testa för att se om du är infekterad med spionprogram
du laddat skadliga program till din enhet.
Vi såg samma sak hända i sista Super Bowl.
Det var en falsk version av Madden fotbollsmatch
som skickade premium SMS-meddelanden.
Den försökte verkligen att skapa ett bot-nätverk också på enheten.
Här har jag några exempel.
Intressant nog, Apple var ganska smart,
och de inte tillåter applikationer att skicka SMS-meddelanden alls.
Ingen app kan göra det.
Det är ett bra sätt att bli av med en hel klass av sårbarhet,
men på Android kan du göra det, och naturligtvis på BlackBerry kan du göra det också.
Det är intressant att på BlackBerry allt du behöver är Internet behörigheter
att skicka ett SMS-meddelande.
>> Den andra saken riktigt att vi söker
När vi är ute efter att se om något är skadligt är bara någon form av
obehörig nätverksaktivitet, liksom titta på nätverksaktivitet
appen är tänkt att ha sin funktion,
och titta på denna andra nätverksaktivitet.
Kanske en app, för att arbeta, måste få data över HTTP,
men om det är att göra saker via e-post eller SMS eller Bluetooth eller något liknande
nu som app skulle kunna vara skadlig, så detta är en annan sak du kan kontrollera för.
Och på denna bild här har jag några exempel på det.
En annan intressant sak som vi såg med skadlig kod som hände under 2009,
och det hände på ett bra sätt.
Jag vet inte om det har hänt så mycket sedan dess, men det var en app
som impersonated annat program.
Det fanns en uppsättning program, och det dubbades 09Droid attacken,
och någon bestämde att det fanns en hel del små, regionala, medelstora banker
som inte har online-banktjänster,
så vad de gjorde var att de byggde cirka 50 online-banktjänster
att allt de gjorde var att ta det användarnamn och lösenord
och omdirigera dig till webbplatsen.
Och så de satte dem alla upp i Google Marketplace,
i Android Marketplace, och när någon sökte för att se om deras bank
hade ett program de skulle finna det falska programmet,
som samlas in sina meriter och sedan omdirigeras dem till deras hemsida.
Det sätt som detta faktiskt blev-apps var uppe för ett par veckor,
och det fanns tusentals nedladdningar.
>> Sättet det här uppdagades var någon hade ett problem
med en av ansökningarna, och de kallade sin bank,
och de kallade sin bank kundsupport linje och sa,
"Jag har ett problem med din mobila bank applikation."
"Kan du hjälpa mig?"
De svarade: "Vi har inte en mobil bankapplikation."
Det startade utredningen.
Den bank som heter Google, och sedan Google tittade och sa,
"Wow, har samma författare skrivit 50 bankapplikationer," och tog dem alla.
Men visst det kan hända igen.
Det finns en lista över alla olika banker här
som var en del av denna bluff.
Den andra saken som en app kan göra är närvarande UI i ett annat program.
Även om det är igång kan det dyka upp på Facebook-UI.
Den säger att du måste lägga in ditt användarnamn och lösenord för att fortsätta
eller sätta upp något användarnamn och lösenord UI för en webbplats
att kanske användaren använder bara för att försöka lura användaren
till att sätta sina meriter i.
Detta är verkligen en rak parallell av e nätfiskeattacker
där någon skickar ett e-postmeddelande
och ger i princip en falsk UI för en webbplats
att du har tillgång till.
>> Den andra saken vi söker i skadlig kod är systemet modifiering.
Du kan söka efter alla API-anrop som kräver root-rättigheter
att utföra fullständigt.
Ändra enhetens webbproxy skulle vara något som en ansökan
bör inte kunna göra.
Men om programmet har koden in där för att göra det
du vet att det är nog ett skadligt program
eller mycket stor sannolikhet att vara ett skadligt program,
och så vad som skulle hända är att app skulle ha något sätt att eskalerande privilegier.
Det skulle ha några privilegier utnyttja
i ansökan, och sedan när det eskalerade privilegier
det skulle göra dessa systemförändringar.
Du kan hitta skadlig kod som har privilegier
i det även utan att veta hur privilegier
utnyttja kommer att hända, och det är ett trevligt och enkelt sätt
att söka efter skadlig kod.
DroidDream var förmodligen den mest kända stycke Android malware.
Jag tror att det påverkade omkring 250.000 användare över några dagar
innan den hittades.
De ompaketerade 50 falska applikationer,
sätta dem i Android App Store,
och i huvudsak används den Android jailbreak kod för att eskalera privilegier
och sedan installera ett kommando och kontroll och vrid alla offer
in i en bot nät, men du kunde ha upptäckt detta
Om du skannar ansökan och bara letar efter
API-anrop som krävs root behörighet att köra på rätt sätt.
>> Och det finns ett exempel här har jag som ändrar proxy,
och detta faktiskt är endast tillgänglig på Android.
Du kan se Jag ger dig en hel del exempel på Android
eftersom det är där de mest aktiva malware ekosystem är
eftersom det är verkligen lätt för en angripare att få skadlig kod
i Android Marketplace.
Det är inte så lätt att göra det i Apple App Store
eftersom Apple kräver utvecklare att identifiera sig
och signera koden.
De kontrollerar faktiskt vem du är, och Apple är faktiskt granska ansökningarna.
Vi ser inte mycket av verklig malware där anordningen blir äventyras.
Jag kommer att tala om några exempel där det är riktigt privatliv som börjar bli äventyras,
och det är vad som verkligen händer på Apple-enheten.
En annan sak att leta efter skadlig kod, riskabel kod i enheter
är logiska eller tidsinställda bomber, och tidsinställda bomber är förmodligen
mycket lättare att leta efter än logiska bomber.
Men med tidsinställda bomber, vad du kan göra är att du kan leta efter
ställen i koden där tiden testas eller en absolut tid sökt
innan vissa funktioner i appen händer.
Och detta kan göras för att dölja denna verksamhet från användaren,
så det händer sent på natten.
DroidDream gjorde all sin verksamhet från 11:00 till 08:00 lokal tid
att försöka göra det samtidigt som användaren inte kanske använder sin enhet.
>> Ett annat skäl för att göra detta är om folk använder beteendeanalys av en ansökan,
kör appen i en sandlåda för att se vad beteendet av ansökan,
de kan använda tidsbaserad logik för att göra verksamheten
När appen är inte i sandlådan.
Till exempel, en App Store som Apple
kör programmet, men de förmodligen inte kör varje ansökan om, säg, 30 dagar
innan du godkänner det, så kan du lägga
logik i din applikation som sagt, okej, bara göra det dåliga
efter 30 dagar har gått eller efter 30 dagar efter publiceringsdatum för ansökan,
och som kan hjälpa den skadliga koden dölja från människor inspekterar för det.
Om antivirusföretag kör saker i sandlådor
eller app butiker själva är detta kan hjälpa
dölja det från denna inspektion.
Nu, den andra sidan av det är det är lätt att hitta med statisk analys,
så faktiskt inspektera koden som du kan leta efter alla platser
där ansökan testar tid och inspektera det sättet.
Och här har jag några exempel på dessa tre olika plattformar
hur kan kontrolleras tiden för den app maker
så du vet vad du ska leta efter om du inspekterar appen statiskt.
>> Jag gick bara igenom en hel massa olika skadliga aktiviteter
som vi har sett i det vilda, men vilka som är de vanligaste?
Samma studie från North Carolina State Mobile Genome Project
publicerat några uppgifter, och det fanns i princip fyra områden
att de såg där det fanns en hel del verksamhet.
37% av de apps gjorde privilegier,
så de hade någon typ av jailbreak-kod i det
där de försökte att eskalera privilegier, så att de kunde
gör API-kommandon körs som operativsystem.
45% av de program där ute gjorde premium SMS,
så det är en stor andel som försöker att direkt tjäna pengar.
93% gjorde fjärrkontroll, så de försökte sätta upp en bot net, en mobil bot nät.
Och 45% skördas identifieringsinformation
som telefonnummer, UUID, GPS-position, användarkonton,
och detta innebär att mer än 100 eftersom de flesta skadliga program försöker göra några av dessa saker.
>> Jag kommer att byta till den andra halvan och prata om koden sårbarheter.
Detta är den andra halvan av den riskfylld verksamhet.
Det är här i huvudsak utvecklaren gör fel.
En legitim utvecklare skriva en legitim app
gör fel eller är okunniga om riskerna för den mobila plattformen.
De vet bara inte hur man gör en säker mobil app,
eller ibland utvecklaren inte bryr sig om att sätta användaren i riskzonen.
Ibland är en del av deras affärsmodell kan vara
skörd av användarens personliga information.
Det blir liksom den andra kategorin, och det är därför en del av denna skadliga
kontra legitima börjar blöda över eftersom det finns olika uppfattningar
mellan vad användaren vill och vad användaren anser riskabelt
och vad programutvecklaren anser riskabelt.
Naturligtvis är det inte programmet utvecklarens uppgifter i de flesta fall.
>> Och slutligen, är ett annat sätt detta sker en utvecklare kan länka in
ett delat bibliotek som har sårbarheter eller detta riskbeteende i det
okänt för dem.
Den första kategorin är känslig dataläckage,
och det är när appen samlar in information
liknande plats, adressbok, ägarinformation
och skickar det av enheten.
Och när det är av enheten, vet vi inte vad som händer med den informationen.
Det skulle kunna lagras på ett osäkert av programutvecklaren.
Vi har sett applikationsutvecklare får äventyras,
och de uppgifter som de ska förvara får tas.
Detta hände för några månader sedan till en utvecklare i Florida
där ett stort antal-det var iPad UUID och enhetsnamn
läckte ut för att någon, jag tror det var anonym,
hävdade att göra detta, bröt sig in i denna utvecklarens servrar
och stal miljontals iPad UUID
och datornamn.
Inte den mest riskfyllda uppgifter,
men tänk om det var lagring av användarnamn och lösenord
och hemadresser?
Det finns massor av program som lagrar den typen av information.
Risken är där.
>> Det andra som kan hända är om utvecklaren inte tar hand
för att säkra datakanalen, och det är en annan stor sårbarhet jag ska prata om,
att data skickas i klartext.
Om användaren är på en Wi-Fi-nätverk
eller någon sniffar på internet någonstans
längs den väg som data exponeras.
En mycket berömda fallet av denna informationsläckage hände med Pandora,
och detta är något som vi forskat på Veracode.
Vi hörde att det fanns en-Jag tror det var en Federal Trade Commission
utredning pågår med Pandora.
Vi sa, "Vad är det som händer där? Låt oss börja gräva i Pandora programmet."
Och vad vi fastställt var Pandora programmet samlas
ditt kön och din ålder,
och det också åt din GPS-position, och Pandora ansökan
gjorde detta för vad de sa var legitima skäl.
Den musik som de spelade-Pandora är en musikstreaming app-
musiken de spelade var bara licensierade i USA,
så de var tvungna att kolla att uppfylla sina licensavtal som de hade
för musiken som användaren var i USA.
De ville också att följa föräldrarnas rådgivande
runt vuxenspråk i musik,
och så det är ett frivilligt program, men de ville följa det
och inte spela explicita texter för barn 13 och under.
>> De hade legitima skäl för att samla in dessa data.
Deras app hade behörighet att göra det.
Användare som tyckte detta var legitim. Men vad hände?
De länkade i 3 eller 4 olika annonsbibliotek.
Nu helt plötsligt alla dessa annons bibliotek
får tillgång till denna samma information.
Biblioteken ad, om man tittar på koden i biblioteken annons
vad de gör är varje annons bibliotek säger
"Har min app har tillåtelse att få GPS-position?"
"Åh, det gör? Okej, säg mig den GPS-position."
Varenda annonsbibliotek gör det,
och om appen inte har GPS-tillstånd
det kommer inte att kunna få det, men om det gör det, kommer det att få det.
Det är där den affärsmodell av biblioteken annons
motsätter sig privatlivet för användaren.
Och det har varit studier där ute som kommer att säga om du känner till åldern
av en person och du vet var de befinner
där de sover på natten, eftersom du har deras GPS-koordinaterna
medan de kanske sover, du vet exakt vem personen är
eftersom du kan avgöra vilken medlem i det hushållet är den personen.
Verkligen detta är att identifiera för annonsörer
exakt vem du är, och det ser ut som det var legitimt.
Jag vill bara ha min strömmande musik, och det är det enda sättet att få det.
>> Tja, vi utsätts detta.
Vi skrev upp i flera blogginlägg,
och det visade sig att någon från Rolling Stone magazine
läsa en av våra blogginlägg och skrev sin egen blogg i Rolling Stone om det,
och redan nästa dag Pandora tyckte det var en bra idé
att ta bort biblioteken annons från tillämpning.
Såvitt jag vet att de är det enda-de bör berömmas.
Jag tror att de är det enda freemium typ av app som har gjort detta.
Alla andra Freemium apps har samma beteende,
så du måste tänka på vilken typ av data du ger
dessa Freemium applikationer eftersom det hela kommer att annonsörer.
Praetorian gjorde också en studie om delade bibliotek och sade,
"Låt oss titta på vad delade biblioteken är de delade bibliotek," och detta var datan.
>> De analyserade 53.000 apps,
och antalet 1 delade biblioteket var Admob.
Det var faktiskt i 38% av ansökningarna där ute,
så 38% av de program du använder
är sannolikt att skörda din personliga information
och skicka den till annonsnätverk.
Apache och Android var 8% respektive 6%,
och sedan de andra som ner i botten, Google-annonser, Flurry,
Mob City och tusenåriga Media,
dessa är alla annonsföretag, och sedan, intressant nog,
4% länkad i Facebook biblioteket
förmodligen att göra autentisering via Facebook
så appen kan autentisera Facebook.
Men det betyder också att företaget Facebook kontrollerar koden
som kör i 4% av Android mobila apps där ute,
och de har tillgång till alla de uppgifter som denna app har behörighet att komma åt.
Facebook försöker i huvudsak att sälja reklamtid.
Det är deras affärsmodell.
>> Om du tittar på hela den här ekosystemet med dessa behörigheter
och delade bibliotek som du börjar att se att
du har en hel del risker i ett förment legitim applikation.
Samma liknande sak som hände med Pandora
hände med ett program som heter Path,
och Path trodde att de var hjälpsamma och vänliga utvecklare.
De försökte bara ge dig en bra användarupplevelse,
och det visade sig att utan att fråga användaren eller berätta för användaren vad som helst-
och detta hände på iPhone och på Android,
Pandora app var på iPhone och Android-
att Path ansökan greppa hela din adressbok
och ladda upp den till Path precis när du installerat och sprang ansökan,
och de inte berätta om detta.
De tyckte det var riktigt bra för dig
för att kunna dela med alla människor i din adressbok
att du använder Path programmet.
>> Tja, uppenbarligen Path tyckte detta var bra för deras företag.
Inte så bra för användaren.
Du måste tänka att det är en sak om kanske en tonåring
använder denna ansökan och deras dussintals vänner är där inne,
men tänk om det är VD för ett företag som installerar Path
och sedan helt plötsligt hela sin adressbok är där uppe?
Du kommer att få en hel del potentiellt värdefull kontaktinformation
för många människor.
En reporter från New York Times, kanske du kan få telefonnumret
för före detta presidenter från sin adressbok,
så uppenbarligen en hel del känslig information får överföras med något sånt här.
Det var en så stor flik om detta att Path bad om ursäkt.
De ändrade sin app, och det till och med påverkade Apple.
Apple sade, "Vi kommer att tvinga app leverantörer att uppmana användarna
om de kommer att samla hela sin adressbok. "
>> Det ser ut som det som händer här är
när det finns ett stort integritetsintrång och det gör pressen
Vi ser en förändring där ute.
Men naturligtvis, det finns andra saker där ute.
Den Linkedin programmet skördar kalenderposter,
men Apple inte gör användaren att bli tillfrågad om det.
Kalenderposter kan ha känslig information i dem också.
Vart ska du dra gränsen?
Detta är verkligen typ av en framväxande plats
där det finns egentligen ingen bra standard där ute
för användarna att förstå när deras information kommer att vara i riskzonen
och när de ska vet att det tas.
Vi skrev en app på Veracode heter Adios,
och i huvudsak det får dig att peka appen på iTunes-katalogen
och titta på alla program som skördar hela din adressbok.
Och som ni kan se på denna lista här, Angry Birds,
AIM, AroundMe.
Varför Angry Birds behöver din adressbok?
Jag vet inte, men det gör det på något sätt.
>> Detta är något som många, många applikationer gör.
Du kan inspektera koden för detta.
Det finns väldefinierade API: er för iPhone, Android och BlackBerry
att komma åt adressboken.
Du kan verkligen lätt att inspektera för detta, och det är vad vi gjorde i vår Adios applikation.
Nästa kategori, Unsafe Känsliga datalagring,
är något där utvecklare ta något som en nål eller ett kontonummer
eller ett lösenord och förvara det på det klara på enheten.
Ännu värre, kan de förvaras i ett område i telefon
som är globalt tillgängliga, som SD-kortet.
Du ser detta oftare på Android eftersom Android möjliggör ett SD-kort.
IPhone-enheter inte.
Men vi såg även detta hända i ett Citigroup applikation.
Deras internet bank lagrad kontonumren osäkert,
bara i det klara, så om du förlorat din enhet,
i huvudsak du förlorat ditt bankkonto.
Det är därför jag personligen inte gör bank på min iPhone.
Jag tycker det är för riskabelt just nu för att göra dessa typer av aktiviteter.
>> Skype gjorde samma sak.
Skype, naturligtvis, har en kontobalans, ett användarnamn och lösenord
att komma åt den balansen.
De lagra all denna information i klartext på den mobila enheten.
Jag har några exempel här för att skapa filer
som inte har rätt behörigheter eller skriva till skivan
och inte har någon kryptering hända för det.
Denna nästa område, Unsafe Känslig Data Transmission,
Jag har nämnt det några gånger, och på grund av Wi-Fi
detta är något som apps absolut måste göra,
och det är förmodligen det som vi ser går fel mest.
Jag skulle säga-faktiskt, jag tror att jag har de faktiska uppgifterna,
men det är nära till hälften av mobila applikationer
skruva upp gör SSL.
De bara inte använder API: er på rätt sätt.
Jag menar, är allt du har att göra är att följa instruktionerna och använda API: er,
men de saker som inte kontrollera om det finns ett ogiltigt certifikat i andra änden,
inte kontrollera om den andra änden försöker göra ett protokoll nedgradering attack.
>> Utvecklarna, de vill få sin kryssruta, eller hur?
Deras krav är att använda detta för att sälja. De har använt denna för att sälja.
Kravet är inte att använda detta för att sälja säkert,
och så det är därför alla program som använder SSL för att säkra data
som det sänds av enheten verkligen behöver inspekteras
att se till att genomfördes korrekt.
Och här har jag några exempel där du kan se ett program
kanske använder HTTP istället för HTTPS.
I vissa fall apps kommer att falla tillbaka till HTTP
Om HTTPS inte fungerar.
Jag har ett annat samtal här på Android där de har inaktivcertifikatkontroll,
så en man-in-the-middle attack kan hända.
Ett ogiltigt certifikat kommer att accepteras.
Dessa är alla fall där angriparna kommer att kunna få på
samma Wi-Fi-anslutning som användare och åtkomst alla data
som är som skickas över internet.
>> Och slutligen, den sista kategorin jag har här är hårdkodade lösenord och nycklar.
Vi ser faktiskt en hel del utvecklare använder samma kodning stil
som de gjorde när de byggde webbservrar,
så de bygger en Java-serverprogram, och de är att hårdkoda nyckeln.
Jo, när du bygger ett serverprogram, ja,
hårdkoda nyckeln är inte en bra idé.
Det gör det svårt att ändra.
Men det är inte så illa på serversidan, eftersom vem som har tillgång till serversidan?
Endast administratörer.
Men om du tar samma kod och du hällde den över till en mobil applikation
nu alla som har det mobila appen har åtkomst till den hårdkodade knapp,
och vi faktiskt se den här många gånger, och jag har en del statistik
om hur ofta vi ser detta hända.
Det var faktiskt i exempelkod som Mastercard publicerade
om hur man kan använda deras tjänst.
Den exempelkod visade hur man bara skulle ta lösenordet
och lägga den i en hårdkodad sträng just där,
och vi vet hur utvecklare älskar att kopiera och klistra in kodsnuttar
när de försöker göra något, så du kopiera och klistra in kodavsnittet
att de gav som exempel kod, och du har ett osäkert program.
>> Och här har vi några exempel.
Det första är en som vi ser en hel del där de hårdkoda
data rakt in i en URL som får skickas.
Ibland ser vi sträng password = lösenord.
Det är ganska lätt att upptäcka, eller sträng lösenord på BlackBerry och Android.
Det är faktiskt ganska lätt att kontrollera eftersom nästan alltid
utvecklaren namnger den variabel som är hållande lösenordet
viss variation av lösenord.
Jag nämnde att vi gör statisk analys på Veracode,
så vi har analyserat flera hundra Android och iOS applikationer.
Vi har byggt kompletta modeller av dem, och vi kan skanna dem
för olika sårbarheter, speciellt de sårbarheter jag talade om,
och jag har några uppgifter här.
68,5% av Android apps som vi tittat på
hade brutit krypteringskoden,
som för oss, kan vi inte upptäcka om du gjort din egen krypto rutin,
inte att det är en bra idé, men det är faktiskt använder de publicerade API: er
som finns på plattformen, men gör dem på ett sådant sätt
att krypto skulle vara sårbara, 68,5.
Och det är för människor som skickar oss sina ansökningar faktiskt eftersom
de tycker att det är en bra idé att göra säkerhetstestning.
Det är redan folk som förmodligen tänker säkert,
så det är förmodligen ännu värre.
>> Jag inte tala om kontroll radmatning injektion.
Det är något vi söker efter, men det är inte så riskabelt en fråga.
Informationsläckage, det är där känsliga data skickas av enheten.
Vi fann att i 40% av ansökningarna.
Tid och stat, som är konkurrenstillstånd typ frågor, oftast ganska svårt att utnyttja,
så jag inte prata om det, men vi såg på det.
23% hade SQL injection frågor.
Många människor vet inte att en hel del program
Använd en liten liten SQL-databas på deras backend för att lagra data.
Tja, om de data som du greppa över nätverket
har SQL-injektion attack strängar i det
någon som kan äventyra enhet genom att
och så tror jag att vi hittar cirka 40% av webbapplikationer har detta problem,
vilket är en stor epidemi problem.
Vi tycker att det är 23% av tiden i mobilappar
och det är förmodligen för att många fler webbapplikationer använder SQL än mobil.
>> Och då vi fortfarande se några cross-site scripting, tillståndsfrågor,
och sedan referens ledning, det är där du har din hårdkodade lösenord.
Under 5% av ansökningarna ser vi att.
Och sedan har vi några uppgifter om iOS.
81% hade felhantering frågor.
Detta är mer av en kod kvalitetsproblem,
men 67% hade kryptografiska frågor, så inte riktigt så illa som Android.
Kanske de API: er är lite lättare, exempelkoder lite bättre på iOS.
Men fortfarande en mycket hög andel.
Vi hade 54% med informationsläckage,
omkring 30% med buffert management fel.
Det är platser där det skulle kunna finnas ett minnesfel.
Det visar sig att det är inte så mycket av ett problem för exploatering
på iOS eftersom all kod måste undertecknas,
så det är svårt för en angripare att köra godtycklig kod på iOS.
Kod kvalitet, katalogtraverse, men då referenser management här på 14,6%,
så värre än på Android.
Vi har folk som inte hanterar lösenord på rätt sätt.
Och sedan de numeriska fel och buffertspill,
de som är mer att vara kod kvalitetsfrågor på iOS.
>> Det var det för min presentation. Jag vet inte om vi är för sent eller inte.
Jag vet inte om det finns några frågor.
[Man] En snabb fråga runt fragmentering och Android marknaden.
Apple åtminstone äger patchning.
De gör ett bra jobb med att få ut det där, medan mindre så i Android utrymme.
Du behöver nästan att jailbreaka din telefon för att hålla dig uppdaterad
med den aktuella versionen av Android.
Ja, det är ett stort problem, och så om du tycker om-
[Man] Varför kan du upprepa det?
>> Just det, så frågan var hur fragmentering
av operativsystemet på Android-plattformen?
Hur påverkar det risken i dessa enheter?
Och det är faktiskt ett stort problem eftersom det som händer är
de äldre enheter, när någon kommer upp med ett jailbreak för den enheten,
i huvudsak det är utökning av privilegier, och till dess att operativsystemet är uppdaterat
alla skadliga program kan sedan använda denna sårbarhet att helt kompromissa enheten,
och vad vi ser på Android är för att få ett nytt operativsystem
Google har att lägga ut operativsystemet, och sedan maskinvarutillverkaren
måste anpassa den och sedan transportören har att anpassa den och leverera den.
Du har i princip tre rörliga delar här,
och det har visat sig att de transportörer som inte bryr sig,
och hårdvarutillverkare inte bryr sig, och Google är inte petade dem tillräckligt
att göra något, så i huvudsak över hälften av enheterna ute
har operativsystem som har dessa privilegier sårbarheter i dem,
och så om du får skadlig kod på din Android-enhet är det mycket mer av ett problem.
>> Okej, tack så mycket.
[Applåder]
[CS50.TV]