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