Black Hat USA 2011: dag 1
Det var en ganska bra line-up under onsdagen, totalt kördes nio parallella tracks: bit flow, threat intel, next-gen web, breaking software, embedded exploitation, deeper analysis samt två workshop-spår.
Keynote
Morgonens keynote-talare var Cofer Black, en välrenomerad herre med 28 år inom underrättelsetjänsten bakom sig; CIA counter-terrorism (CT). Han inledde helt oblygt med att berätta att han för tio år sedan, den 5 augusti 2001, var talare på en liknande scen, Black var då chef för CT-avdelningen, och att han då (kanske lika oblygt) konstaterade att det fanns individer som var motiverade att genomföra ett stort attentat mot amerikaner, möjligen i USA. Vi vet alla vad som hände ungefär en månad senare. Han blev alltså, enligt egen utsago, inte förvånad den 11 september 2001.
Ett av Blacks huvudspår i sitt anförande var svårigheten (1) att validera hot och (2) att få överordnade att förstå/acceptera att det finns hot. Det senare ett problem som vår bransch alltså delar med underrättelsetjänsten. "[The need for] validation of threats and attacks will come to your world", sade han uttryckligen. Ja kanske det. Kanske den dag vi har kommit så långt att vi inte behöver oroa oss över den småbrottslighet som står för majoriteten av alla attacker.
Vidare föreslog han att den bekanta förkortningen CBRN: chemical, biological, radation, nuclear; borde bytas ut mot KBC: kinetic, bacteriological och... cyber. Som exempel på kinetic attacks gavs hotellen i Mumbai för några år sedan samt the DC Sniper. Naturligtvis faller även attacken på Utöya i Norge här. Bakteriebiologiska attacker har dessutom tydligen blivit mycket enklare på sista tiden. Slutligen pekade han på Stuxnet. "The Stuxnet attack is the rubicon of the future", tillsammans med en kommentar om att det p g a kostnaderna måste ha varit en stat som legat bakom... Det som imponerade på Black verkade vara övergången från mjukvara till fysisk förstörelse i verkligheten.
War Texting
Don Andrew Bailey från iSEC Partners visade vad han hade hittat för problem i de gränssnitt vissa inbyggda system har mot mobilnätet. Huvuddemot i presentationen, som var omtalat, var att de låste upp och startade en Subaru över mobilnätet genom att skicka SMS till larmsystemet. Häftigt och väl genomfört av Bailey men knappast oväntat, man kan känna sånt här på sig. Det är typiskt att sådana här system har levt i skyddad verkstad bara för att ingen har tittat efter ordentligt och så fort någon sätter sig ner och tittar visar det sig vara en hel del damm bakom soffan.
Jag gillade särskilt exemplet med Zoombak, en liten dosa med GPS som man kan lägga i bilen eller dotterns ryggsäck för att sedan kolla var de befinner sig med hjälp av en webbsida. Genom att replaya SMS-meddelanden (i vilka en IP-adress har ändrats) kunde han lura dem att rapportera in till honom över Internet. Det var också möjligt att, missade hur det gick till exakt, flooda Zoombak med felaktiga koordinater så att din bil ser ut att stå i Afghanistan. Utvecklat i skyddad verkstad.
Det är svårt att överblicka hur stort problem det här är. Om man dock betänker hur billiga sådana här kretsar är och hur praktiskt det är att kunna fjärrstyra något från i princip varsomhelst så kan man anta att de sitter i många, många system. En stor anledning till att problemet med just dessa gränssnitt är att utvecklare blir tvungna att designa protokollen själva, något som är långt från trivialt. Det är bara att acceptera att allt som kan angripas per definition är säkerhetssystem; om det sedan är en brandvägg, tunnelbanespärr eller Daughter Tracker 2000 är egalt.
Hacking Google ChromeOS
Matt Johansen och Kyle Osborn från Whitehat Security hade fått prestigeuppdraget att göra tester mot Googles nya operativsystem ChromeOS. Ur användarens synvinkel gör ChromeOS egentligen bara en sak; kopplar upp mot Internet och öppnar en Chrome-browser. Det finns ingen åtkomst till filsystem eller liknande utan detta är tänkt att skötas med molntjänster över webben.
Det första de började kika på var extensions till Chrome (browsern). Dessa är inte att likställa med add-ons till t ex Firefox, extensions är mer som vanliga webbapplikationer.
Faktum är att de hittade ett väldigt allvarligt problem: extensions till Chrome kommer med särskilda rättigheter som säger vilka URI:er de får kontakta och det är utvecklarna själva som sätter dessa (patterns i stil med http|https://*/* förekommer med andra ord). Om en extension med lössläppta rättigheter har en cross-site scripting-sårbarhet och en angripare kan utnyttja detta mot dig kan de injicera JavaScript i alla sidor du har öppna.
Alltså, en extension som har *://*/*-rättigheter och inte kodar utdata som kommer från en angripare är att likställa med att det finns XSS-sårbarheter i alla sidor du besöker.
Ett kortare recept: (1) hitta extensions där du har möjlighet att skicka indata, RSS-läsare, mailklienter o s v, (2) välj ut alla som har galna rättigheter, (3) leta efter cross-site scripting-sårbarheter. (Ironiskt nog tänker jag mig att de med *-rättigheter också har XSS-sårbarheter i större utsträckning än andra extensions.)
Google har tydligen ett par idéer om vad de ska göra åt (det svåra) problemet. Spontant känns det som att * borde förbjudas helt för domäner, möjligen att subdomäner som *.domän ska vara tillåtet. Det är dock många intressen som spelar in här (jag har säkert missat någon anledning till att tillåta *-domäner) där en kan vara strävan att ta marknadsandelar. Om det är skitjobbigt att få din applikation att fungera p g a komplexa rättigheter kommer du utveckla för någon annan, om du utvecklar för någon annan kommer användare att köpa av någon annan. Business á la Facebook...
Black Ops of TCP/IP 2011
Dan Kaminsky var tillbaka med ännu en installation av sin gamla hederliga Gott & Blandat-presentation. Årets upplaga innehöll lite BitCoin, lite UPNP, lite klassisk IP spoofing samt hur man kan upptäcka att man är "utsatt" för net neutrality. Innehållet var halvintressant, jag går dock slaviskt och tittar på Kaminsky för att insupa den obegränsade glädje han utstrålar över att göra det han gör. Han får mig att _vilja_ sätta mig i två veckor och titta på packet captures. :-)
Apple iOS 4 Security Evaluation
Dino Dai Zovi från Trail of Bits har gjort ett hästjobb med att reversa iPhones operativsystem. Presentationen behandlade några av de säkerhetsfunktioner som kommer med moderna iOS-versioner (>= 4.3): ASLR, NX, kodsignering, sandboxing och datakryptering.
En intressant finding var att väldigt, väldigt få av alla tredjepartsappar är kompilerade position-independent så att de täcks av ASLR helt och hållet. Ingen av de som är listade topp tio, inte ens Angry Birds. (Det här är ett generellt problem med ASLR.)
Vidare gladde det mig att han konstaterade att stulna eller förlorade enheter utgör den största risken. Om du är någon av mina kunder har du hört mig säga det många gånger, att Dino säger det har dock betydligt mer tyngd.
Några avslutande konstateranden angående iOS: använd iPad 2 (det finns inga boot ROM exploits), vänta på iOS 5 innan ni inför det på företaget, BlackBerrys dataskydd är mycket mer sofistikerat, iPhone 3 borde inte tillåtas på företag, Android saknar både NX och ASLR samt har ett svagare kodsignering och dataskydd.
--
Stefan Pettersson
Keynote
Morgonens keynote-talare var Cofer Black, en välrenomerad herre med 28 år inom underrättelsetjänsten bakom sig; CIA counter-terrorism (CT). Han inledde helt oblygt med att berätta att han för tio år sedan, den 5 augusti 2001, var talare på en liknande scen, Black var då chef för CT-avdelningen, och att han då (kanske lika oblygt) konstaterade att det fanns individer som var motiverade att genomföra ett stort attentat mot amerikaner, möjligen i USA. Vi vet alla vad som hände ungefär en månad senare. Han blev alltså, enligt egen utsago, inte förvånad den 11 september 2001.
Ett av Blacks huvudspår i sitt anförande var svårigheten (1) att validera hot och (2) att få överordnade att förstå/acceptera att det finns hot. Det senare ett problem som vår bransch alltså delar med underrättelsetjänsten. "[The need for] validation of threats and attacks will come to your world", sade han uttryckligen. Ja kanske det. Kanske den dag vi har kommit så långt att vi inte behöver oroa oss över den småbrottslighet som står för majoriteten av alla attacker.
Vidare föreslog han att den bekanta förkortningen CBRN: chemical, biological, radation, nuclear; borde bytas ut mot KBC: kinetic, bacteriological och... cyber. Som exempel på kinetic attacks gavs hotellen i Mumbai för några år sedan samt the DC Sniper. Naturligtvis faller även attacken på Utöya i Norge här. Bakteriebiologiska attacker har dessutom tydligen blivit mycket enklare på sista tiden. Slutligen pekade han på Stuxnet. "The Stuxnet attack is the rubicon of the future", tillsammans med en kommentar om att det p g a kostnaderna måste ha varit en stat som legat bakom... Det som imponerade på Black verkade vara övergången från mjukvara till fysisk förstörelse i verkligheten.
War Texting
Don Andrew Bailey från iSEC Partners visade vad han hade hittat för problem i de gränssnitt vissa inbyggda system har mot mobilnätet. Huvuddemot i presentationen, som var omtalat, var att de låste upp och startade en Subaru över mobilnätet genom att skicka SMS till larmsystemet. Häftigt och väl genomfört av Bailey men knappast oväntat, man kan känna sånt här på sig. Det är typiskt att sådana här system har levt i skyddad verkstad bara för att ingen har tittat efter ordentligt och så fort någon sätter sig ner och tittar visar det sig vara en hel del damm bakom soffan.
Jag gillade särskilt exemplet med Zoombak, en liten dosa med GPS som man kan lägga i bilen eller dotterns ryggsäck för att sedan kolla var de befinner sig med hjälp av en webbsida. Genom att replaya SMS-meddelanden (i vilka en IP-adress har ändrats) kunde han lura dem att rapportera in till honom över Internet. Det var också möjligt att, missade hur det gick till exakt, flooda Zoombak med felaktiga koordinater så att din bil ser ut att stå i Afghanistan. Utvecklat i skyddad verkstad.
Det är svårt att överblicka hur stort problem det här är. Om man dock betänker hur billiga sådana här kretsar är och hur praktiskt det är att kunna fjärrstyra något från i princip varsomhelst så kan man anta att de sitter i många, många system. En stor anledning till att problemet med just dessa gränssnitt är att utvecklare blir tvungna att designa protokollen själva, något som är långt från trivialt. Det är bara att acceptera att allt som kan angripas per definition är säkerhetssystem; om det sedan är en brandvägg, tunnelbanespärr eller Daughter Tracker 2000 är egalt.
Hacking Google ChromeOS
Matt Johansen och Kyle Osborn från Whitehat Security hade fått prestigeuppdraget att göra tester mot Googles nya operativsystem ChromeOS. Ur användarens synvinkel gör ChromeOS egentligen bara en sak; kopplar upp mot Internet och öppnar en Chrome-browser. Det finns ingen åtkomst till filsystem eller liknande utan detta är tänkt att skötas med molntjänster över webben.
Det första de började kika på var extensions till Chrome (browsern). Dessa är inte att likställa med add-ons till t ex Firefox, extensions är mer som vanliga webbapplikationer.
Faktum är att de hittade ett väldigt allvarligt problem: extensions till Chrome kommer med särskilda rättigheter som säger vilka URI:er de får kontakta och det är utvecklarna själva som sätter dessa (patterns i stil med http|https://*/* förekommer med andra ord). Om en extension med lössläppta rättigheter har en cross-site scripting-sårbarhet och en angripare kan utnyttja detta mot dig kan de injicera JavaScript i alla sidor du har öppna.
Alltså, en extension som har *://*/*-rättigheter och inte kodar utdata som kommer från en angripare är att likställa med att det finns XSS-sårbarheter i alla sidor du besöker.
Ett kortare recept: (1) hitta extensions där du har möjlighet att skicka indata, RSS-läsare, mailklienter o s v, (2) välj ut alla som har galna rättigheter, (3) leta efter cross-site scripting-sårbarheter. (Ironiskt nog tänker jag mig att de med *-rättigheter också har XSS-sårbarheter i större utsträckning än andra extensions.)
Google har tydligen ett par idéer om vad de ska göra åt (det svåra) problemet. Spontant känns det som att * borde förbjudas helt för domäner, möjligen att subdomäner som *.domän ska vara tillåtet. Det är dock många intressen som spelar in här (jag har säkert missat någon anledning till att tillåta *-domäner) där en kan vara strävan att ta marknadsandelar. Om det är skitjobbigt att få din applikation att fungera p g a komplexa rättigheter kommer du utveckla för någon annan, om du utvecklar för någon annan kommer användare att köpa av någon annan. Business á la Facebook...
Black Ops of TCP/IP 2011
Dan Kaminsky var tillbaka med ännu en installation av sin gamla hederliga Gott & Blandat-presentation. Årets upplaga innehöll lite BitCoin, lite UPNP, lite klassisk IP spoofing samt hur man kan upptäcka att man är "utsatt" för net neutrality. Innehållet var halvintressant, jag går dock slaviskt och tittar på Kaminsky för att insupa den obegränsade glädje han utstrålar över att göra det han gör. Han får mig att _vilja_ sätta mig i två veckor och titta på packet captures. :-)
Apple iOS 4 Security Evaluation
Dino Dai Zovi från Trail of Bits har gjort ett hästjobb med att reversa iPhones operativsystem. Presentationen behandlade några av de säkerhetsfunktioner som kommer med moderna iOS-versioner (>= 4.3): ASLR, NX, kodsignering, sandboxing och datakryptering.
En intressant finding var att väldigt, väldigt få av alla tredjepartsappar är kompilerade position-independent så att de täcks av ASLR helt och hållet. Ingen av de som är listade topp tio, inte ens Angry Birds. (Det här är ett generellt problem med ASLR.)
Vidare gladde det mig att han konstaterade att stulna eller förlorade enheter utgör den största risken. Om du är någon av mina kunder har du hört mig säga det många gånger, att Dino säger det har dock betydligt mer tyngd.
Några avslutande konstateranden angående iOS: använd iPad 2 (det finns inga boot ROM exploits), vänta på iOS 5 innan ni inför det på företaget, BlackBerrys dataskydd är mycket mer sofistikerat, iPhone 3 borde inte tillåtas på företag, Android saknar både NX och ASLR samt har ett svagare kodsignering och dataskydd.
--
Stefan Pettersson
Kommentarer
Trackback
