MySQL & SSL
Två händelser har uppmärksammats senaste veckan: (1) en protokollsårbarhet har upptäckts i SSL 3.0 och TLS 1.0 som gör att angripare t ex kan stjäla cookies från https-sessioner och (2) www.mysql.com serverade ett exploit pack under, bedömt, några timmar efter ett intrång.
Sårbarheten i SSL
Attacken mot SSL som implementerats av Thai Doug och Juliano Rizzo bygger på att en angripare kan modifiera klartextblock innan de krypteras och XOR:as med nästa klartextblock i CBC-mod. Mer specifikt genom att skjuta in en sträng framför klartexten för att på så sätt "flytta" gränsen mellan två block. De kallar attacken för blockwise chosen-plaintext attack (BCPA). I klarspråk betyder det att de kan gissa cookien ett tecken i taget.
Attacken har dock ett par förutsättningar för att du ska kunna utsättas, säg att du är uppkopplad mot Facebook:
Till exempel kan det här översätta till cross-site scripting i Facebook och att angriparen sitter på samma (osäkra) trådlösa nät som du. (Det finns andra situationer men det här borde vara den som är mest trovärdig.)
Mycket bra research. Attacken bygger på och förfinar andras arbete och implementeras dessutom på ett av våra vanligaste krypteringsprotokoll.
Attacken mot www.mysql.com
Det är oklart hur attacken gick till, hur angriparna fick in JavaScriptet på MySQLs hemsida. (Brian Krebs har en teori.) Resultatet är dock känt, varje besökare dirigeras om till en annan server där de möts av BlackHole exploit pack som försöker utnyttja sårbarheter i webbläsare, Flash, Acrobat, Java, etc. I de fall attacken mot klienten lyckas laddas någon form av botprogram ner, vid tillfället kunde bara fyra av 44 antivirusprogram upptäcka det.
Attacken var av typ standard 1A. Inget märkvärdigt egentligen mer än att det var en välbesökt (400k personer/dag) sida som åkte dit. En detalj i det hela var att en av de inblandade malware-servrarna ligger hos ett svenskt webbhotell.
Slutsats
Så, vi fick (1) en riktigt häftig och krävande protokollsårbarhet mot vårt vanligaste säkerhetsprotokoll och (2) en standardattack på standardmanér mot en webbsida. Jag är övertygad om att den senare skördade många fler offer under sina första minuter än vad den förra kommer att göra någonsin.
Det är synd på fler än ett sätt.
--
Stefan Pettersson
Sårbarheten i SSL
Attacken mot SSL som implementerats av Thai Doug och Juliano Rizzo bygger på att en angripare kan modifiera klartextblock innan de krypteras och XOR:as med nästa klartextblock i CBC-mod. Mer specifikt genom att skjuta in en sträng framför klartexten för att på så sätt "flytta" gränsen mellan två block. De kallar attacken för blockwise chosen-plaintext attack (BCPA). I klarspråk betyder det att de kan gissa cookien ett tecken i taget.
Attacken har dock ett par förutsättningar för att du ska kunna utsättas, säg att du är uppkopplad mot Facebook:
- Angriparen behöver kunna exekvera JavaScript i din browser från Facebook.
- Angriparen behöver kunna se din krypterade trafik mot Facebook.
- Angriparen behöver tid på sig så du måste vara på Facebook tillräckligt länge.
Till exempel kan det här översätta till cross-site scripting i Facebook och att angriparen sitter på samma (osäkra) trådlösa nät som du. (Det finns andra situationer men det här borde vara den som är mest trovärdig.)
Mycket bra research. Attacken bygger på och förfinar andras arbete och implementeras dessutom på ett av våra vanligaste krypteringsprotokoll.
Attacken mot www.mysql.com
Det är oklart hur attacken gick till, hur angriparna fick in JavaScriptet på MySQLs hemsida. (Brian Krebs har en teori.) Resultatet är dock känt, varje besökare dirigeras om till en annan server där de möts av BlackHole exploit pack som försöker utnyttja sårbarheter i webbläsare, Flash, Acrobat, Java, etc. I de fall attacken mot klienten lyckas laddas någon form av botprogram ner, vid tillfället kunde bara fyra av 44 antivirusprogram upptäcka det.
Attacken var av typ standard 1A. Inget märkvärdigt egentligen mer än att det var en välbesökt (400k personer/dag) sida som åkte dit. En detalj i det hela var att en av de inblandade malware-servrarna ligger hos ett svenskt webbhotell.
Slutsats
Så, vi fick (1) en riktigt häftig och krävande protokollsårbarhet mot vårt vanligaste säkerhetsprotokoll och (2) en standardattack på standardmanér mot en webbsida. Jag är övertygad om att den senare skördade många fler offer under sina första minuter än vad den förra kommer att göra någonsin.
Det är synd på fler än ett sätt.
--
Stefan Pettersson
Skadeansvar åvilar tillverkaren
Update @2011-09-28: God vän och insiktsfull kollega Christoffer har tagit upp software liability också.
Trots att jag gör det hela tiden så gillar jag egentligen inte att bara hänvisa till andra bloggar eller artiklar och säga "det här är bra". Nu måste jag dock göra det igen...
Poul-Henning Kamp, FreeBSD-utvecklare extraordinaire (och pappa till FreeBSD-MD5-hashen), skrev för omkring två veckor sedan en artikel om software liability: tillverkare av mjukvara borde hållas ansvariga för fel i produkten. Precis som tillverkare av hus, bilar eller tvättmaskiner. Jag har skämtat om ämnet tidigare och tycker att det är en väldigt attraktiv tanke men jag har inte tagit en tydlig position ännu. Jag har lite svårt att överblicka effekterna.
Anywho, Kamps artikel är suverän. Han inleder med en diskussion och utveckling av Ken Thompsons tal Reflections on Trusting Trust från 1984 (som jag har nämnt tidigare någon gång tror jag) och problemen med att man aldrig kan lita på andras kod. Därifrån tar han det vidare till ett förslag om tre klausuler (FreeBSD, go figure) som lämpar över ansvaret för skador på tillverkaren.
Rolig är han också:
Today the operant legal concept is "product liability," and the fundamental formula is "if you make money selling something, you'd better do it properly, or you will be held responsible for the trouble it causes." I want to point out, however, that there are implementations of product liability other than those in force in the U.S. For example, if you burn yourself on hot coffee in Denmark, you burn yourself on hot coffee. You do not become a millionaire or necessitate signs pointing out that the coffee is hot.
Trevlig helg!
--
Stefan Pettersson
Trots att jag gör det hela tiden så gillar jag egentligen inte att bara hänvisa till andra bloggar eller artiklar och säga "det här är bra". Nu måste jag dock göra det igen...
Poul-Henning Kamp, FreeBSD-utvecklare extraordinaire (och pappa till FreeBSD-MD5-hashen), skrev för omkring två veckor sedan en artikel om software liability: tillverkare av mjukvara borde hållas ansvariga för fel i produkten. Precis som tillverkare av hus, bilar eller tvättmaskiner. Jag har skämtat om ämnet tidigare och tycker att det är en väldigt attraktiv tanke men jag har inte tagit en tydlig position ännu. Jag har lite svårt att överblicka effekterna.
Anywho, Kamps artikel är suverän. Han inleder med en diskussion och utveckling av Ken Thompsons tal Reflections on Trusting Trust från 1984 (som jag har nämnt tidigare någon gång tror jag) och problemen med att man aldrig kan lita på andras kod. Därifrån tar han det vidare till ett förslag om tre klausuler (FreeBSD, go figure) som lämpar över ansvaret för skador på tillverkaren.
Rolig är han också:
Today the operant legal concept is "product liability," and the fundamental formula is "if you make money selling something, you'd better do it properly, or you will be held responsible for the trouble it causes." I want to point out, however, that there are implementations of product liability other than those in force in the U.S. For example, if you burn yourself on hot coffee in Denmark, you burn yourself on hot coffee. You do not become a millionaire or necessitate signs pointing out that the coffee is hot.
Trevlig helg!
--
Stefan Pettersson
Okontroversiella men riktiga åsikter
Val Smith (valsmith) är, och har länge varit, en riktigt duktig reverse engineer och exploit-utvecklare. Han har presenterat på massa konferenser, skrivit en massa uppsatser och är inblandad i Metasploit och Offensive Computing. Han har rejält med street cred i branschen helt enkelt.
Nu har valsmith skrivit ett blogginlägg, My Personal War Against Overuse of Memory Corruption Bugs, där han säger att han har slutat lägga tid på buffer overflows och liknande sårbarheter där minne skrivs över (min fetstil):
[...] but how much skilled time investment is required to take a bug from a crash to a highly reliable, continuation of execution, ASLR / DEP bypassing exploit ready for serious use? Average numbers I have heard from friends who do this all day long are 1 - 3 months, with 6 months for particularly sticky bugs. How many people are there that can do this? Not many. So you have a valuable resource tied up for months at a time to produce a bug which may get discovered and published in the interm ( a process you have no real control over), patched and killed. When was the last time you heard about a really bitchin Windows 7 64bit remote?
I could not agree more.
Det är ingen tvekan om att sånt här (pdf) är sinnesjukt imponerande. Sotirov, HD Moore, Charlie Miller, Dino, Zalewski, Dave och alla deras gelikar är avundsvärt begåvade och extremt målinriktade. Arbetet med att ta sig förbi ASLR, DEP, sandlådor och diverse andra skydd för att till slut få ett robust exploit är dock inte värt det. Tänk om all deras energi istället kunde fördelas på tusen gånger fler människor som istället lade energin på att få ordning på de enkla sakerna. Då kanske Comodo, RSA, DigiNotar o s v hade klarat sig.
Men, eftersom omfördelning av energi sådär än så länge inte ens är science fiction så är valsmiths eget förslag: att lägga energin på att hitta och utnyttja mer fundamentala sårbarheter som är riktigt svåra att reparera, alldeles fantastiskt.
--
Stefan Pettersson
Nu har valsmith skrivit ett blogginlägg, My Personal War Against Overuse of Memory Corruption Bugs, där han säger att han har slutat lägga tid på buffer overflows och liknande sårbarheter där minne skrivs över (min fetstil):
[...] but how much skilled time investment is required to take a bug from a crash to a highly reliable, continuation of execution, ASLR / DEP bypassing exploit ready for serious use? Average numbers I have heard from friends who do this all day long are 1 - 3 months, with 6 months for particularly sticky bugs. How many people are there that can do this? Not many. So you have a valuable resource tied up for months at a time to produce a bug which may get discovered and published in the interm ( a process you have no real control over), patched and killed. When was the last time you heard about a really bitchin Windows 7 64bit remote?
I could not agree more.
Det är ingen tvekan om att sånt här (pdf) är sinnesjukt imponerande. Sotirov, HD Moore, Charlie Miller, Dino, Zalewski, Dave och alla deras gelikar är avundsvärt begåvade och extremt målinriktade. Arbetet med att ta sig förbi ASLR, DEP, sandlådor och diverse andra skydd för att till slut få ett robust exploit är dock inte värt det. Tänk om all deras energi istället kunde fördelas på tusen gånger fler människor som istället lade energin på att få ordning på de enkla sakerna. Då kanske Comodo, RSA, DigiNotar o s v hade klarat sig.
Men, eftersom omfördelning av energi sådär än så länge inte ens är science fiction så är valsmiths eget förslag: att lägga energin på att hitta och utnyttja mer fundamentala sårbarheter som är riktigt svåra att reparera, alldeles fantastiskt.
--
Stefan Pettersson
Säkerhet och biologi
Inte är det konstigt att känna viss upphetsning när man läser en uppsats som inleds med orden:
The security and stability of a nation, group, or people can be considered as closely analogous to the immunity of a multicellular organism against internal and external threats to its integrity.
Uppsatsen heter From Bacteria to Belief, är skriven av Luis P. Villarreal och utgör kapitel fyra i Natural Security: A Darwinian Approach to a Dangerous World.
Den tvärvetenskapliga synen på säkerhet har sedan många år sett till ekonomi och psykologi. Biologi eller åtminstone immunologi och evolutionsbiologi kanske kan visa sig nyttigt i framtiden. Kul att läsa om är det i alla fall.
--
Stefan Pettersson
The security and stability of a nation, group, or people can be considered as closely analogous to the immunity of a multicellular organism against internal and external threats to its integrity.
Uppsatsen heter From Bacteria to Belief, är skriven av Luis P. Villarreal och utgör kapitel fyra i Natural Security: A Darwinian Approach to a Dangerous World.
Den tvärvetenskapliga synen på säkerhet har sedan många år sett till ekonomi och psykologi. Biologi eller åtminstone immunologi och evolutionsbiologi kanske kan visa sig nyttigt i framtiden. Kul att läsa om är det i alla fall.
--
Stefan Pettersson
Mail v. instant messaging
Hur kommer det sig att företag lägger så pass mycket energi på att utvärdera, fundera och undra över säkerheten i instant messaging-program som Skype och MSN när de inte tycks ha problem med mail?
Man är i regel oroad över två saker angående IM: (1) sårbarheter i klientprogramvaran och de nödvändiga uppdateringsrutinerna som kommer med problemet. (2) Den andra saken verkar vara funktionen programmet är till för att lösa, d v s att låta anställda skicka och ta emot meddelanden samt att skicka och ta emot filer.
Låt oss angripa dem en i taget.
(1) Gällande sårbarheter i klientprogramvaran så gissar jag att de "vanliga" programmen, Excel, Word, Acrobat och Flash, står för en så mycket större mängd av klientsårbarheter att det blir svårt använda det som ett argument. Om du vågar köra dessa program så innebär inte en IM-klient en särskilt förhöjd risk.
(2) Ponera att SMTP, POP3, IMAP, etc inte fanns idag utan att alla använde t ex Skype för att skicka meddelanden och filer till varandra. Anta att någon skapade de RFC:er som beskriver nämnda protokoll idag och publicerade dem. Mailprotokollen hade aldrig blivit accepterade. Både säkerhetsfolk och användare hade ju skrattat.
Trevlig helg i alla fall!
--
Stefan Pettersson
Man är i regel oroad över två saker angående IM: (1) sårbarheter i klientprogramvaran och de nödvändiga uppdateringsrutinerna som kommer med problemet. (2) Den andra saken verkar vara funktionen programmet är till för att lösa, d v s att låta anställda skicka och ta emot meddelanden samt att skicka och ta emot filer.
Låt oss angripa dem en i taget.
(1) Gällande sårbarheter i klientprogramvaran så gissar jag att de "vanliga" programmen, Excel, Word, Acrobat och Flash, står för en så mycket större mängd av klientsårbarheter att det blir svårt använda det som ett argument. Om du vågar köra dessa program så innebär inte en IM-klient en särskilt förhöjd risk.
(2) Ponera att SMTP, POP3, IMAP, etc inte fanns idag utan att alla använde t ex Skype för att skicka meddelanden och filer till varandra. Anta att någon skapade de RFC:er som beskriver nämnda protokoll idag och publicerade dem. Mailprotokollen hade aldrig blivit accepterade. Både säkerhetsfolk och användare hade ju skrattat.
- Va? Kan man skicka meddelanden till vem som helst helt utan att "lägga till" dem först?
- Va? Kan man inte alls lita på vem som är avsändare?
- Va? Skickas meddelanden i klartext över Internet?
- Va? Skickas filer också i klartext?
- Va? Kommer den där filen jag skickar till dig att ligga och skräpa, inte bara på min och din hårddisk utan även i våra respektive mailkorgar, både lokal cache och på servern, för överskådlig framtid?
- Va? För att förtydliga, en känslig fil som skickas från mig till dig lagras alltså på minst fyra, kanske sex, kanske fler, platser?
- Va? Kommer 95 % av alla meddelanden som skickas mellan personer att vara skräp och annonser som ingen vill ha?
- Va? Kommer det att vara svårt att överföra filer som är större än 5 Mb?
Trevlig helg i alla fall!
--
Stefan Pettersson
