CONFidence 2009 är nu över så jag (Stefan) tänkte göra en sammanfattning av höjdpunkterna under konferensen. Det har varit två hektiska dagar så ni får allt i en post. (Det var inte meningen att den skulle bli såhär lång egentligen...)
Bruce Schneier, "Reconceptualizing Security"
Bruce höll dagens första keynote och fokuserade idag på psykologin bakom säkerhet. Han har skrivit en massiv artikel om ämnet tidigare. Det var inget nytt under solen men som alltid är det intressant att se Bruce prata.
Alexander Kornbrust, "Oracle SQL Injection in Webapps"
Kornbrust från Red Database Security pratade om SQL injection i Oracledatabaser. Han täckte från grunderna och uppåt till mer avancerade attacker och visade bl a hur hela tabeller kan plockas ut med bara ett request med hjälp av lite nya trick. De slides han använde var väldigt utförliga med många exempel så håll utkik på http://2009.confidence.org.pl/ efter materialet.
Alberto Revelli, Nico Leidecker, "Introducing Heyoka: DNS Tunneling 2.0"
Det här var förmodligen den bästa presentationen under konferensen. De hade riktiga, nya idéer som de implementerat och de förklarade hela sin tankeprocess på ett lättförståeligt sätt även om deras lösning var rätt intrikat.
Nico är snubben bakom verktyget sqlninja som jag nämnt i en tidigare post. De presenterade ett nytt verktyg de kallar Heyoka som tunnlar TCP över DNS. Det intressanta är att de implementerar lite nya trick som inte finns i till exempel OzymanDNS och Iodine. Målen är att öka bandbredden och göra tunneln svårare att upptäcka.
Heyoka (som för övrigt bara är i tidig beta ännu) använder två DNS-tunnlar; en för trafik uppströms (mot DNS-servern) och en för nedströmstrafik (från DNS-servern). Detta gör bland annat att källadressen på trafiken som ska skickas ut kan spoofas. Vanligtvis när man tunnlar trafik över DNS kommer det att skickas extremt många små paket från en maskin. Med hjälp av fejkad avsändare kan man "fördela" trafiken på alla andra maskiner i nätverket så att det blir svårare att upptäcka avvikelser. Man behöver inte bry sig om svaren, nedströms hanteras i den andra tunneln.
En annan intressant detalj är att Heyoka struntar i att använda base32 för att koda datan innan det skickas över DNS. De har nämligen upptäckt att många DNS-servrar klarar av binärdata i queries. För att hantera servrar som inte gör det sker ett handskakningsprotokoll när tunneln sätts upp så kodning görs bara när det krävs.
Michal Sajdak, "Remote Rootshell on a SOHO Router"
Det var den här presentationen jag skrev om igår kväll. Sårbarheten i ASMAX var bara en av de som togs upp; Linksys och D-Link var också representerade. ASMAX var förmodligen värst dock... Intressant för oss i OWASP är att Michal bara kollar på sårbarheter i enheternas webbgränssnitt. Hittills har undersökningen baserats på att han helt enkelt promenerat ner till elektronikaffären, köpt en router, ett modem eller en AP och gått hem för att testa den. Av allt att döma är det enkelt att hitta allvarliga sårbarheter i webbgränssnitten.
Hur kommer det sig att det är såhär? Man kan inte skylla på bristande datorkraft när det till exempel handlar om att validera indata till passthru(). Min teori är att inbyggda system inte ses på samma sätt som konventionella; det är ingen dator så den hanteras inte som en. Det gäller framförallt hur ägaren ser på det; en skrivare eller bordstelefon med webbgränssnitt tas inte med i säkerhetspolicyn på samma sätt som intranätservern. Har utvecklarna samma synsätt? Det är en spontan teori än så länge, jag skulle gärna höra era åsikter.
Sharon Conheady, "Social Engineering for Penetration Testers"
Sharon höll definitivt konferensens mest underhållande presentation. Hon jobbar på en firma i London och gör pentester där hon bara utnyttjar social engineering. Enligt egen utsago har hon aldrig misslyckats och jag tror henne. I sammanhanget är "att lyckas" när hon tar sig in i företagets känsliga lokaler (serverhall, arkivrum, etc) och inte är eskorterad.
Presentationen var bra strukturerad och nästan allt hon sa (förutom flera bra warstories) återfinns i de slides som publiceras på CONFidences sida om "ett tag". Om videon kommer online också så är även den varmt rekommenderad då hon som sagt har många intressanta historier. Under ett test blev hon stoppad av en säkerhetsvakt som sa att de hade ett "social engineering-test" på gång och att de var tvungna att dubbelkolla alla besökare men att hon var okej så hon kunde fortsätta...
Overall så var CONFidence en skön omväxling efter OWASP AppSec, presentationerna var inte lika inriktade på utveckling och var något mer tekniska. Jag skulle definitivt åka tillbaka nästa år om jag fick möjligheten.
söndag 17 maj 2009
fredag 15 maj 2009
ASS-MAX
Kort post, var tvungen att få det här ur mig. Michal Sajdak presenterade på kvällen idag några sårbarheter han hittat i en vanliga hemmaroutrar. Bland annat i en av märket ASMAX AR-804 gu. Man blir lätt upprörd av att bara lyssna på det.
Sammanfattning i nio punkter
1. Routern kör Linux.
2. Linux kör Apache för administration.
3. Innehållet i katalogen /cgi-bin renderas av Apache (Index of).
4. Där finns ett shellscript.
5. Shellscriptet tar en parameter som heter "system", värdet på parametern skickas till shellet via backticks och exekveras (sannolikt något utvecklarna har använt sig av men inte tagit bort).
6. Scriptet körs även om du inte har autentiserat dig.
7. Scriptet tar glatt emot parametern i ett GET-request så CSRF blir kanonenkelt och kräver bara en img-tag.
8. Sätt upp en hemsida med en IMG-tag som pekar på hxxp://192.168.0.1/cgi-bin/script?system+kommando+parametrar och vips så kommer besökare med ASMAX-routrar att köra dina kommandon på sin router.
9. Som root.
Och ja, den kör den senaste versionen av firmware.
Jag och CJ återkommer senare ikväll/inatt med sammanfattning av dagen.
Sammanfattning i nio punkter
1. Routern kör Linux.
2. Linux kör Apache för administration.
3. Innehållet i katalogen /cgi-bin renderas av Apache (Index of).
4. Där finns ett shellscript.
5. Shellscriptet tar en parameter som heter "system", värdet på parametern skickas till shellet via backticks och exekveras (sannolikt något utvecklarna har använt sig av men inte tagit bort).
6. Scriptet körs även om du inte har autentiserat dig.
7. Scriptet tar glatt emot parametern i ett GET-request så CSRF blir kanonenkelt och kräver bara en img-tag.
8. Sätt upp en hemsida med en IMG-tag som pekar på hxxp://192.168.0.1/cgi-bin/script?system+kommando+parametrar och vips så kommer besökare med ASMAX-routrar att köra dina kommandon på sin router.
9. Som root.
Och ja, den kör den senaste versionen av firmware.
Jag och CJ återkommer senare ikväll/inatt med sammanfattning av dagen.
Fler sammanfattningar från OWASP Dag 2
Efter en lång dag kommer här ytterligare en rapport från Krakow. Jag (Carl-Johan Bostorp, High Performance Systems) och Stefan har nu flyttat från Park Inn Hotel till "Hacker's Squad" för att delta i CONFidence 2009. Detta inlägg ska dock handla om OWASP-dagen, och även idag lyckades jag pricka in flera andra presentationer än de som John bloggat om. Här kommer därför en sammanfattning från några av dem.
Fixing Internet Security by Hacking the Business Climate
Bruce Schnerier - det närmsta rockstjärna som säkerhetsvärlden har - höll keynote för dag 2 på OWASP. Det började lite knackigt nästan med Bruce som kollade mycket på sina anteckningar, men allt eftersom blev det mindre störande då ämnet i sig trädde fram. Man kunde ana varför Bruce blivit en sådan mediaikon, han har en teknik som fångar lyssnaren i hans resonemang.
Bruce pratade om att vi aldrig kommer bli av med gamla attacker (buffer overflows har funnits sedan 60-talet), samtidigt som nya kommer till. Komplexitet är samtidigt säkerhetens värsta fiende, och där ser vi en stadig ökning. Det ser han som förklaringen till att trots att vi blir bättre på säkerhet, så ökar våra problem med det. Det var en rimlig förklaring på en fråga jag ställde mig under gårdangens presentation som David Harper höll angående Maturing beyond application security, nämligen hur det kom sig att trots att vi satsar så mycket mer på säkerhet idag, och kan så mycket mer, så stiger ändå antalet incidenter.
Bruce är precis som Ross Andersson inne i det ekonomiska perspektivet. Anledningen till att vi inte har bättre säkerhet idag är för att de ekonomiska incitamenten ligger fel för det. Lösningen tror Bruce kommer via fyra steg:
Han hade en övertygande argumentation för detta, som gick via försäkringsbolag. Ifall juridiskt ansvar finns, kommer företag vilja försäkra sig. Försäkring har fördelen att man omvandlar en variabel kostnad (risk för stora kostnader ibland), till en fix kostnad (som går att budgetera). Försäkringsbolagen å sin sida kommer bara ge lägre premier för verklig säkerhet. Detta att jämföra med den säkerhetsteater som vi ofta ser idag, där det hävdas att man är säker eller att något görs för säkerheten, medan det i själa verket gör lite för det. Avskräckande och åtal kan dock försvåras i och med Internets internationella natur, och där kommer krävas mer samarbete över gränserna.
Bruce tror på mer standardisering framöver, och mer outsourcing av säkerhet.
Deploying secure web applications with OWASP Resources
Detta var ännu en något felaktigt benämnd presentation som jag förmodligen inte gått på om det funnits en abstract. Det handlade inte så mycket om någon deployment, utan snarare om de utmaningar en av utvecklarna på New York University mött. Det i sig är förvisso intressant, men inget nytt under solen för min personliga del. Kuai Hinojosa nämnde kort några OWASP projekt som de haft nytta av.
Problemen hade bestått av:
Kuai Hinojosa som höll presentation var själv en del av ett utvecklingsteam. De använde flera olika OWASP resurser för att tackla problemen, bl.a.:
Kuai hade i presentationen lagt särskild tyngd på OWASP Developing Guide. Jag passade då på att fråga hur de såg på värdet av guiden i och med att den inte hade blivit uppdaterad på senare år. Tydligen var detta något som de hade stött på vissa problem kring, men att den utgjorde en bra bas. Även det svaret låg i fas med min uppfattning. Development Guide är IMHO ett av de bästa dokumenten som OWASP har.
Can accessible web applications be secure? Assessment issues for security testers, developers and auditors
Det här var en av de positiva överraskningarna från dagen. Det handlade om hur säkerheten påverkas när det finns krav på "accessbility and usability" (användbarhet). Det finns många incitament för detta, bl.a. kan det finnas lagar som reglerar att webbplatser skall vara handikappvänliga. Dock ingår mer i begreppet, bland annat att det skall gå att använda webbplatsen oavsett om man är i en ljus eller mörk miljö.
En standard för detta finns från W3C som heter WCAG. Colin Watson argumenterade att kraven ökade komplexiteten, vilket naturligtvis medförde större risk för sårbarheter. Han blev sedan konkret kring det. Han hade identifierat 8 olika krav som påverkade säkerheten och hade dessutom mappat dessa till OWASP Top 10. Intressant ur flera perspektiv, bland annat att krav inom vissa företag och myndigheter faktiskt kan orsaka vissa typer av sårbarheter.
Efter en lång dag så ska jag, Stefan Pettersson (min kollega från HPS), och tre av våra nya vänner här nere i Hacker's Squad gå och lägga oss. Morgondagen för med sig ytterligare en keynote från Schneier. Då kommer det dock följas av betydligt "offensivare" presentationer.
Fixing Internet Security by Hacking the Business Climate
Bruce Schnerier - det närmsta rockstjärna som säkerhetsvärlden har - höll keynote för dag 2 på OWASP. Det började lite knackigt nästan med Bruce som kollade mycket på sina anteckningar, men allt eftersom blev det mindre störande då ämnet i sig trädde fram. Man kunde ana varför Bruce blivit en sådan mediaikon, han har en teknik som fångar lyssnaren i hans resonemang.
Bruce pratade om att vi aldrig kommer bli av med gamla attacker (buffer overflows har funnits sedan 60-talet), samtidigt som nya kommer till. Komplexitet är samtidigt säkerhetens värsta fiende, och där ser vi en stadig ökning. Det ser han som förklaringen till att trots att vi blir bättre på säkerhet, så ökar våra problem med det. Det var en rimlig förklaring på en fråga jag ställde mig under gårdangens presentation som David Harper höll angående Maturing beyond application security, nämligen hur det kom sig att trots att vi satsar så mycket mer på säkerhet idag, och kan så mycket mer, så stiger ändå antalet incidenter.
Bruce är precis som Ross Andersson inne i det ekonomiska perspektivet. Anledningen till att vi inte har bättre säkerhet idag är för att de ekonomiska incitamenten ligger fel för det. Lösningen tror Bruce kommer via fyra steg:
- Tvingande juridisikt ansvar (liability)
- Överföring av ansvar (transfer of liability)
- Mekanismer för att reducera risk kommer då fram
- Åtal och avskräckande åtgärder
Han hade en övertygande argumentation för detta, som gick via försäkringsbolag. Ifall juridiskt ansvar finns, kommer företag vilja försäkra sig. Försäkring har fördelen att man omvandlar en variabel kostnad (risk för stora kostnader ibland), till en fix kostnad (som går att budgetera). Försäkringsbolagen å sin sida kommer bara ge lägre premier för verklig säkerhet. Detta att jämföra med den säkerhetsteater som vi ofta ser idag, där det hävdas att man är säker eller att något görs för säkerheten, medan det i själa verket gör lite för det. Avskräckande och åtal kan dock försvåras i och med Internets internationella natur, och där kommer krävas mer samarbete över gränserna.
Bruce tror på mer standardisering framöver, och mer outsourcing av säkerhet.
Deploying secure web applications with OWASP Resources
Detta var ännu en något felaktigt benämnd presentation som jag förmodligen inte gått på om det funnits en abstract. Det handlade inte så mycket om någon deployment, utan snarare om de utmaningar en av utvecklarna på New York University mött. Det i sig är förvisso intressant, men inget nytt under solen för min personliga del. Kuai Hinojosa nämnde kort några OWASP projekt som de haft nytta av.
Problemen hade bestått av:
- Kulturella problem; "vi har ju inga finanstransaktioner här" (oj vad den känns igen)
- Åtkomlighet vs. Security (allt enkelt åtkomligt, ingen segmentering, inte mycket brandväggat)
- Organisationens struktur (fler olika avdelningar, alla med sina applikationer som de vill bestämma över)
- Säker arkitektur (görs inte)
Kuai Hinojosa som höll presentation var själv en del av ett utvecklingsteam. De använde flera olika OWASP resurser för att tackla problemen, bl.a.:
- Top Ten som ett "säljblad", i kombination med WebGoat för att ge en ögonöppnare'
- Developing Guide, OWASP ESAPI
- Testing Guide på existerande applikationer, som man sedan fixade till med OWASP ESAPI
- CSRF Tester
- WebScarab samt w3af för att testa sina applikationer innan man skickade dem vidare
Kuai hade i presentationen lagt särskild tyngd på OWASP Developing Guide. Jag passade då på att fråga hur de såg på värdet av guiden i och med att den inte hade blivit uppdaterad på senare år. Tydligen var detta något som de hade stött på vissa problem kring, men att den utgjorde en bra bas. Även det svaret låg i fas med min uppfattning. Development Guide är IMHO ett av de bästa dokumenten som OWASP har.
Can accessible web applications be secure? Assessment issues for security testers, developers and auditors
Det här var en av de positiva överraskningarna från dagen. Det handlade om hur säkerheten påverkas när det finns krav på "accessbility and usability" (användbarhet). Det finns många incitament för detta, bl.a. kan det finnas lagar som reglerar att webbplatser skall vara handikappvänliga. Dock ingår mer i begreppet, bland annat att det skall gå att använda webbplatsen oavsett om man är i en ljus eller mörk miljö.
En standard för detta finns från W3C som heter WCAG. Colin Watson argumenterade att kraven ökade komplexiteten, vilket naturligtvis medförde större risk för sårbarheter. Han blev sedan konkret kring det. Han hade identifierat 8 olika krav som påverkade säkerheten och hade dessutom mappat dessa till OWASP Top 10. Intressant ur flera perspektiv, bland annat att krav inom vissa företag och myndigheter faktiskt kan orsaka vissa typer av sårbarheter.
Efter en lång dag så ska jag, Stefan Pettersson (min kollega från HPS), och tre av våra nya vänner här nere i Hacker's Squad gå och lägga oss. Morgondagen för med sig ytterligare en keynote från Schneier. Då kommer det dock följas av betydligt "offensivare" presentationer.
torsdag 14 maj 2009
Factoring malware and organized crime in to web application security
Gunter Ollman pratade om crimeware och hur det påverkar webbapplikationer, i synnerhet bankapplikationer. Hans poäng är att webbapplikationer har andra problem än SQL injection och cross-site scripting.
Grundläggande problem med bankapplikationer
Komplexitet i bankapplikationer är det största problemet. En användare vet inte hur många steg en transaktion kräver, de vet inte vilka felmeddelanden som finns, de vet inte i vilken ordning stegen sker och de vet inte vilka säkerhetskoder de måste slå in. Samtidigt har alla banker olika applikationer för att genomföra liknande transaktioner.
Varför detta är viktigt blir tydligt när man tar hänsyn till att bankens kunder kan vara infekterade av malware. MITB-funktionalitet (man-in-the-browser) är mer eller mindre standard i moderna trojaner och SSL/TLS kommer inte att göra ett jota mot detta. MITB gör att en angripare kan ändra gränssnittet i en applikation on-the-fly utan att det märks.
En vanilj-banktransaktion
Välj ett konto att ta pengar ifrån, ange hur mycket pengar som ska skickas och vilket konto som ska ta emot pengarna. När du är framme vid slutet av transaktionen får du se vad du har valt och ska godkänna; hur vet du att det du ser är korrekt? Bara för att rätt mottagare står i den renderade HTML som du tittar på betyder det inte att det är vad som kommer att skickas bakåt i bankens applikation. Vi kan inte lita på gränssnittet (om vi är infekterade).
Ett relativt gammalt problem och lösningen som jag har sett det har hela tiden varit att vi måste göra en (kryptografisk) checksumma för alla tre värden; från-konto, till-konto och summa. Det är detta säkerhetsdosan är till för. Bankapplikationen kommer att märka ett ändrat till-konto när den gör samma uträkning.
Komplexitet
Här kommer problemet med komplexitet in enligt Gunter, även om det har gjorts rätt blir det lätt för elakingar att lura användare. Skulle verkligen en användare reagera om bankapplikationen (under en falsk förevändning) skulle be dem att slå in ett "säkerhetsvärde", en "verifieringskod", en "kontrollsumma" eller liknande? Denna sifferserie är i själva verket angriparens kontonummer, eventuellt med ett bindestreck eller två för att se ut som något annat. Detta görs mitt i det vanliga flödet och gränssnittet ändras så att det ser normalt ut.
Sådana trick går att göra av anledningarna listade i andra paragrafen ovan, användaren tycker inte att det är konstigt att en ny kod behövs, "det ändras ju hela tiden". Sådana attacker har dessutom (enligt Gunter) förekommit i crimeware.
Mjaa...
Jag vet inte om jag håller med. Om alla tre värden ingår i checksumman (från, till, summa) och det framgår tydligt i bankdosan vad det är du fyller i så att det står "Mottagarkonto:" istället för "SÄKKOD #3" eller liknande (som i dagens) blir det svårare att lura en användare. Man ska märka att man gör fel "hey, det här är inte min mammas kontonummer". Det är en större tröskel att slå in den där "verifieringskoden" när det står "Mottagarkonto:" på dosan.
Det finns vissa problem med det här, det är jobbigt att slå in två hela kontonummer i sin säkerhetsdosa. Det är också jobbigt att ha en stor dosa (med stor display) som kan visa vad du ska slå in (dessutom är det dyrt för bankerna).
Våra stora svenska banker har inte implementerat det här fullständigt (har någon?). Koderna vi slår in är (delvis) abstrakta (KOD #2) och alla tre värden ingår inte i checksumman.
Det är lite stressigt nu, konferensen avslutas precis och mina batterier tar slut. Kanske pratar mer om det på vår blogg i framtiden.
Grundläggande problem med bankapplikationer
Komplexitet i bankapplikationer är det största problemet. En användare vet inte hur många steg en transaktion kräver, de vet inte vilka felmeddelanden som finns, de vet inte i vilken ordning stegen sker och de vet inte vilka säkerhetskoder de måste slå in. Samtidigt har alla banker olika applikationer för att genomföra liknande transaktioner.
Varför detta är viktigt blir tydligt när man tar hänsyn till att bankens kunder kan vara infekterade av malware. MITB-funktionalitet (man-in-the-browser) är mer eller mindre standard i moderna trojaner och SSL/TLS kommer inte att göra ett jota mot detta. MITB gör att en angripare kan ändra gränssnittet i en applikation on-the-fly utan att det märks.
En vanilj-banktransaktion
Välj ett konto att ta pengar ifrån, ange hur mycket pengar som ska skickas och vilket konto som ska ta emot pengarna. När du är framme vid slutet av transaktionen får du se vad du har valt och ska godkänna; hur vet du att det du ser är korrekt? Bara för att rätt mottagare står i den renderade HTML som du tittar på betyder det inte att det är vad som kommer att skickas bakåt i bankens applikation. Vi kan inte lita på gränssnittet (om vi är infekterade).
Ett relativt gammalt problem och lösningen som jag har sett det har hela tiden varit att vi måste göra en (kryptografisk) checksumma för alla tre värden; från-konto, till-konto och summa. Det är detta säkerhetsdosan är till för. Bankapplikationen kommer att märka ett ändrat till-konto när den gör samma uträkning.
Komplexitet
Här kommer problemet med komplexitet in enligt Gunter, även om det har gjorts rätt blir det lätt för elakingar att lura användare. Skulle verkligen en användare reagera om bankapplikationen (under en falsk förevändning) skulle be dem att slå in ett "säkerhetsvärde", en "verifieringskod", en "kontrollsumma" eller liknande? Denna sifferserie är i själva verket angriparens kontonummer, eventuellt med ett bindestreck eller två för att se ut som något annat. Detta görs mitt i det vanliga flödet och gränssnittet ändras så att det ser normalt ut.
Sådana trick går att göra av anledningarna listade i andra paragrafen ovan, användaren tycker inte att det är konstigt att en ny kod behövs, "det ändras ju hela tiden". Sådana attacker har dessutom (enligt Gunter) förekommit i crimeware.
Mjaa...
Jag vet inte om jag håller med. Om alla tre värden ingår i checksumman (från, till, summa) och det framgår tydligt i bankdosan vad det är du fyller i så att det står "Mottagarkonto:" istället för "SÄKKOD #3" eller liknande (som i dagens) blir det svårare att lura en användare. Man ska märka att man gör fel "hey, det här är inte min mammas kontonummer". Det är en större tröskel att slå in den där "verifieringskoden" när det står "Mottagarkonto:" på dosan.
Det finns vissa problem med det här, det är jobbigt att slå in två hela kontonummer i sin säkerhetsdosa. Det är också jobbigt att ha en stor dosa (med stor display) som kan visa vad du ska slå in (dessutom är det dyrt för bankerna).
Våra stora svenska banker har inte implementerat det här fullständigt (har någon?). Koderna vi slår in är (delvis) abstrakta (KOD #2) och alla tre värden ingår inte i checksumman.
Det är lite stressigt nu, konferensen avslutas precis och mina batterier tar slut. Kanske pratar mer om det på vår blogg i framtiden.
HTTP Parameter Pollution (HPP)
Luca Carettoni och Stefano Di Paola presenteradee sin nya attackteknik http parameter pollution. De har gjort en enkel men förstås elak sak -- multipla URL-parametrar. Tänk dig t ex www.sajt.se/?query=12&query=34, dvs parametern query två gånger. Vad händer då? Det visar sig vara odefinierat i standarden och därför ge olika beteenden på olika webbservrar och/eller applikationer.
Odefinierat beteende = buggigt beteende
Genom att testa en massa större webbapplikationer har de hittat ett antal intressanta hanteringar av multipla parametrar. En del applikationer tar sökparameter A och letar i databasen och sökparameter B och presenterar på webbsidan. I stil med ...
www.sajt.se/?search=Kalle&search=Stina
Din sökning på 'Kalle' gav följande träffar:
Stina Andersson
Stina af Grepe
Kristina Gunnarsson
Man kan ju undra vilken av de två parametrarna som validerades? Andra applikationer kastar undantag med informativa felmeddelanden. Ytterligare andra väljer någon av parametrarna såsom Google Search Appliance som tar den sista förekomsten.
Det blir riktigt intressant när olika parametervärden har olika accessrättigheter. Om vi tänker oss att alla användare ska få se viss data men bara administratörer ska få ändra den -- vad händer då vid följande parametersättning:
www.sajt.se/?action=view&attribute=name&action=edit
Att man överhuvudtaget kan ha fler än en förekomst av en parameter syns t ex i Javas API:
OK, om olika ramverk hanterar multipla förekomster av parametrar olika så borde vi väl kunna utnyttja den funktionaliteten till något? Japp. T ex för att ta oss förbi applikationsbrandväggar som filtrerar indata.
ModSecurity säger stopp vid följande SQL-injektion i en parameter:
www.sajt.se/surfa.aspx?page=select 1,2,3 from table where id=1
Men en ASP-server kommer tolka följande parametersättning ...
www.sajt.se/surfa.aspx?page=select 1&page=2,3 from table where id=1
... som en kommaseparerad lista av parametervärden och alltså ersätta &page= med ett kommatecken. Resultatet? Jo ...
www.sajt.se/surfa.aspx?page=select 1,2,3 from table where id=1
Odefinierat beteende = buggigt beteende
Genom att testa en massa större webbapplikationer har de hittat ett antal intressanta hanteringar av multipla parametrar. En del applikationer tar sökparameter A och letar i databasen och sökparameter B och presenterar på webbsidan. I stil med ...
www.sajt.se/?search=Kalle&search=Stina
Din sökning på 'Kalle' gav följande träffar:
Stina Andersson
Stina af Grepe
Kristina Gunnarsson
Man kan ju undra vilken av de två parametrarna som validerades? Andra applikationer kastar undantag med informativa felmeddelanden. Ytterligare andra väljer någon av parametrarna såsom Google Search Appliance som tar den sista förekomsten.
Det blir riktigt intressant när olika parametervärden har olika accessrättigheter. Om vi tänker oss att alla användare ska få se viss data men bara administratörer ska få ändra den -- vad händer då vid följande parametersättning:
www.sajt.se/?action=view&attribute=name&action=edit
Att man överhuvudtaget kan ha fler än en förekomst av en parameter syns t ex i Javas API:
- javax.servlet.ServletRequest.getParameter() returnerar någon förekomst av parametern
- javax.servlet.ServletRequest.getParameterValues() returnerar en array av alla förekomster
OK, om olika ramverk hanterar multipla förekomster av parametrar olika så borde vi väl kunna utnyttja den funktionaliteten till något? Japp. T ex för att ta oss förbi applikationsbrandväggar som filtrerar indata.
ModSecurity säger stopp vid följande SQL-injektion i en parameter:
www.sajt.se/surfa.aspx?page=select 1,2,3 from table where id=1
Men en ASP-server kommer tolka följande parametersättning ...
www.sajt.se/surfa.aspx?page=select 1&page=2,3 from table where id=1
... som en kommaseparerad lista av parametervärden och alltså ersätta &page= med ett kommatecken. Resultatet? Jo ...
www.sajt.se/surfa.aspx?page=select 1,2,3 from table where id=1
SQL injection - inte bra
Som sagt så är vi ett par svenskar här nere i Krakow, tror att vi har hittat sju hittills. Jag (Stefan Pettersson) tänkte, precis som CJ, pitcha in med några bloggposter till och från också. Vi ska dessutom vara med på CONFidence som börjar imorgon så det blir lite rapportering därifrån med.
Bernardo Damele A. G. är snubben bakom attackverktyget sqlmap. På eftermiddagen igår presenterade han några nya funktioner som han har implementerat. sqlmap automatiserar SQL injection-attacker. Med besked.
Farlig attack
SQL injection är en attack som inte går att underskatta. En sårbarhet som kan utnyttjas för SQL injection är nästan alltid hysteriskt illa. Som någon sade någon gång: "om det finns pengar någonstans i nätverket så är det i databasen". Den här attacken blottlägger ofta databasen totalt. Vad som gör saken ännu mer illa (illare?) är att attacker mot databaser inte stannar vid datastöld, dagens system är så fulla av funktioner att det ofta finns goda möjligheter att både läsa/skriva på filsystemet och köra kod på operativsystemet. Hur illa kan det bli?
Sofistikerade verktyg
sqlmap kan nu automatisera processen att, genom en SQL injection i en webbapplikation, ladda upp och köra exekverbara filer. Det är implementerat för både MySQL, PostgreSQL och SQL Server på ASP, ASP.NET och PHP. 7 av de 9 möjliga kombinationerna fungerar. sqlmap kopplar in payloads från Metasploit i det hela så att få en Meterpreter- eller VNC-session från en webbapplikations databas är peanuts. Givetvis använder den Metasploits encoders så att antivirus blir förvirrade.
Vad Bernardo har lagt till för funktionalitet i senaste versionen är i sig inget nytt, det har funnits verktyg för det redan tidigare, exempelvis sqlninja. (Dock stödjer sqlmap fler databaser och plattformar.)
Frågan är: hur mycket måste vi göra för att visa att SQL injection är ett kolossalt säkerhetshål? Vi vet ju redan vad vi måste göra.
Bernardo Damele A. G. är snubben bakom attackverktyget sqlmap. På eftermiddagen igår presenterade han några nya funktioner som han har implementerat. sqlmap automatiserar SQL injection-attacker. Med besked.
Farlig attack
SQL injection är en attack som inte går att underskatta. En sårbarhet som kan utnyttjas för SQL injection är nästan alltid hysteriskt illa. Som någon sade någon gång: "om det finns pengar någonstans i nätverket så är det i databasen". Den här attacken blottlägger ofta databasen totalt. Vad som gör saken ännu mer illa (illare?) är att attacker mot databaser inte stannar vid datastöld, dagens system är så fulla av funktioner att det ofta finns goda möjligheter att både läsa/skriva på filsystemet och köra kod på operativsystemet. Hur illa kan det bli?
Sofistikerade verktyg
sqlmap kan nu automatisera processen att, genom en SQL injection i en webbapplikation, ladda upp och köra exekverbara filer. Det är implementerat för både MySQL, PostgreSQL och SQL Server på ASP, ASP.NET och PHP. 7 av de 9 möjliga kombinationerna fungerar. sqlmap kopplar in payloads från Metasploit i det hela så att få en Meterpreter- eller VNC-session från en webbapplikations databas är peanuts. Givetvis använder den Metasploits encoders så att antivirus blir förvirrade.
Vad Bernardo har lagt till för funktionalitet i senaste versionen är i sig inget nytt, det har funnits verktyg för det redan tidigare, exempelvis sqlninja. (Dock stödjer sqlmap fler databaser och plattformar.)
Frågan är: hur mycket måste vi göra för att visa att SQL injection är ett kolossalt säkerhetshål? Vi vet ju redan vad vi måste göra.
onsdag 13 maj 2009
Sammanfattningar från fler av dagens föreläsningar på AppSec09
Som John skrev är vi några svenskar på plats här nere på AppSec09 i Krakow. John har föredömligt skrivit om två av dagens föreläsningar. Men det var ju fler än så, och därför kommer jag (Carl-Johan Bostorp) att fylla på med lite korta sammanfattningar om några av de övriga.
Leveraging agile to gain better security
Erland Oftedal från Norge berättade om sina erfarenheter om hur säkerhet kan integreras i agile-utveckling. Han grundade med en introduktion till agile och varför man använder agile. "We reflect after each iteration" summerade upp agile - man gör många iterationer för att till slut komma i fatt ett rörligt mål. Mellan varje iteration reflekterar man över om saker går som de ska. Agile bygger till stor del på snabb feedback.
Erland ville lyfta fram hur man kunde arbeta med säkerhet i agile-projekt genom att göra det till en kontinuerlig del. Genom det kommer man dessutom ifrån de vanliga problemen med att säkerhet bara brukar betraktas i korta perioder då man spenderar all sin ansträngning på en gång. Exempel på hur säkerhet integreras:
Mycket tyckte jag lät vettigt. En "brist" som funnits med olika metoder för säker utveckling (Microsoft SDL, Cigital Touchpoints) är att det ofta saknats en konkret anknytning till det praktiska arbetet. Det har blivit ett smörgåsbord med aktiviteter där någon måste välja vad som ska göras, när och hur. Av den anledningen tyckte jag det var intressant att höra hur Erland i praktiken jobbade med säkerhet i utvecklingen utifrån ett agile-perspektiv.
Tracking the progress of an SDL program
Cassio Goldschmidt från Symantec/Los Angeles höll i den här föreläsningen. Den kan sammanfattas kort; använd CWE och CVSS för att jämföra äpplen och äpplen i de olika faserna (design, utveckling, test, deployed). Håll koll på hur många buggar som upptäcks i de olika faserna. En kort introduktion av CWE och CVSS gavs. Med CWE kan man lätt generalisera och rapportera uppåt, med CVSS får man mer objektiva värden på hur allvarliga sårbarheterna man hittar är.
Maturing beyond application security
Bakom den rubriken dolde sig så småningom till största delen en introduktion av BSIMM. David Harper från Fortify berättade om hur BSIMM bygger på att man observerat vad som gjorts hos de där SDL är infört på ett lyckat sätt. Några erfarenheter från Fortify nämndes dock också:
När man känner sig nöjd med SDL i sin egen organisation finns dock fortfarande kod kvar från flera olika håll: outsourcing, open source och kommersiella applikationer. David såg dessa områden som nästa utmaning där man naturligtvis också bör gå in och försöka påverka för att hantera risker.
Web Application Firewalls: What the vendors do not want you to know.
Fingerprinting och bypassing WAF:s. Håll utkik efter dessa två tools som kommer komma framöver: wafw00f, waffun.
Fingerprinting sker genom exempelvis:
Bypassing sker genom exempelvis:
The Software Assurance Maturity Model
Denna föreläsning har John redan skrivit om. Jag tänkte se till att fylla på lite. Pravir (som står bakom SAMM) började nämligen med att säga något som jag hade tänkt skriva här på bloggen: Man är inte ens i närheten av att ha kommit till någon vidare mognad kring hur man ska arbeta med säker utveckling. Börjar man ställa frågor kring Microsoft SDL, OWASP CLASP och Cigital Touchpoints så går det snart upp att det är så. Dock så tycker jag SAMM ser riktigt spännande ut och Pravir har en pragmatisk grundinställning. Det jag saknat i tidigare SDL är råd om prioriteringar, hur man inför dem och rent konkret, hur det är bra att gå till väga och vilka metriker man kan använda för att mäta effektivitet. SAMM har utformats för att hjälpa till även i dessa områden. Starkt rekommenderad läsning för den som vill styra upp säkerheten alltså!
Leveraging agile to gain better security
Erland Oftedal från Norge berättade om sina erfarenheter om hur säkerhet kan integreras i agile-utveckling. Han grundade med en introduktion till agile och varför man använder agile. "We reflect after each iteration" summerade upp agile - man gör många iterationer för att till slut komma i fatt ett rörligt mål. Mellan varje iteration reflekterar man över om saker går som de ska. Agile bygger till stor del på snabb feedback.
Erland ville lyfta fram hur man kunde arbeta med säkerhet i agile-projekt genom att göra det till en kontinuerlig del. Genom det kommer man dessutom ifrån de vanliga problemen med att säkerhet bara brukar betraktas i korta perioder då man spenderar all sin ansträngning på en gång. Exempel på hur säkerhet integreras:
- Skriva säkerhetstestcase som körs vid varje incheckning
- Programmera i par - få en första kodgranskning omgående och sprid kunskap samtidigt
- Micro-workshops då en sårbarhet hittas
Mycket tyckte jag lät vettigt. En "brist" som funnits med olika metoder för säker utveckling (Microsoft SDL, Cigital Touchpoints) är att det ofta saknats en konkret anknytning till det praktiska arbetet. Det har blivit ett smörgåsbord med aktiviteter där någon måste välja vad som ska göras, när och hur. Av den anledningen tyckte jag det var intressant att höra hur Erland i praktiken jobbade med säkerhet i utvecklingen utifrån ett agile-perspektiv.
Tracking the progress of an SDL program
Cassio Goldschmidt från Symantec/Los Angeles höll i den här föreläsningen. Den kan sammanfattas kort; använd CWE och CVSS för att jämföra äpplen och äpplen i de olika faserna (design, utveckling, test, deployed). Håll koll på hur många buggar som upptäcks i de olika faserna. En kort introduktion av CWE och CVSS gavs. Med CWE kan man lätt generalisera och rapportera uppåt, med CVSS får man mer objektiva värden på hur allvarliga sårbarheterna man hittar är.
Maturing beyond application security
Bakom den rubriken dolde sig så småningom till största delen en introduktion av BSIMM. David Harper från Fortify berättade om hur BSIMM bygger på att man observerat vad som gjorts hos de där SDL är infört på ett lyckat sätt. Några erfarenheter från Fortify nämndes dock också:
- Integrera i vad som finns, vänta inte på "den stora SDL-rollouten" (vilket jag instämmer med)
- Utbildning sker bäst utifrån den egna kodbasen (förutsättningarna finns dock inte alltid från början, men det kan vara en bra idé att ordna dem tidigt)
När man känner sig nöjd med SDL i sin egen organisation finns dock fortfarande kod kvar från flera olika håll: outsourcing, open source och kommersiella applikationer. David såg dessa områden som nästa utmaning där man naturligtvis också bör gå in och försöka påverka för att hantera risker.
Web Application Firewalls: What the vendors do not want you to know.
Fingerprinting och bypassing WAF:s. Håll utkik efter dessa två tools som kommer komma framöver: wafw00f, waffun.
Fingerprinting sker genom exempelvis:
- Omskrivna headers (Server, Connection)
- Statuskoder
- Olika svar på icke-existerande sidor (404) beroende på om sidan finns eller om man skickade en request med attack-mönster
Bypassing sker genom exempelvis:
- Se till att man inte matchar svartlistor:
- Utnyttja dåliga motorer för reguljära uttryck för vitlistning: infoga ett %0a i parametern för att skilja av vad som matchas
The Software Assurance Maturity Model
Denna föreläsning har John redan skrivit om. Jag tänkte se till att fylla på lite. Pravir (som står bakom SAMM) började nämligen med att säga något som jag hade tänkt skriva här på bloggen: Man är inte ens i närheten av att ha kommit till någon vidare mognad kring hur man ska arbeta med säker utveckling. Börjar man ställa frågor kring Microsoft SDL, OWASP CLASP och Cigital Touchpoints så går det snart upp att det är så. Dock så tycker jag SAMM ser riktigt spännande ut och Pravir har en pragmatisk grundinställning. Det jag saknat i tidigare SDL är råd om prioriteringar, hur man inför dem och rent konkret, hur det är bra att gå till väga och vilka metriker man kan använda för att mäta effektivitet. SAMM har utformats för att hjälpa till även i dessa områden. Starkt rekommenderad läsning för den som vill styra upp säkerheten alltså!
OpenSAMM
Pravir Chandra presenterade sitt projekt Open Software Assurance Maturity Model, eller OpenSAMM. En modell för att utvärdera var ens organisation ligger idag och hur man ska ta sig framåt i sitt arbete med att bygga säkra system.
Projektets utgångspunkt var Microsofts Security Development Lifecycle (SDL) och OWASPs Comprehensive Lightweight Application Security Process (CLASP). Enligt Pravir så har SDL uppfattats som för tungt, även av Microsoft själva och CLASP uppfattats som bra men mest en samling aktiviteter utan ordning eller prioritet. Så man ville ta fram något bättre.
Tolv typer av säkerhetsarbete
I OpenSAMM definieras arbete med applikationssäkerhet i fyra huvudkategorier och tre underkategorier:
Inom varje kategori kan man befinna sig på en av fyra nivåer:
0: Inga aktiviteter
1: Grundläggande förståelse, tillgång till information
2: Utrullning i praktiken och arbete med effektiviteten
3: Skalbart användande
Färdkartor för fyra typiska organisationer
Inom OpenSAMM har man tagit fram fyra färdiga färdkartor för typiska organisationer:
OpenSAMM har släppts i version 1.0 och används redan av många organisationer. Pravir och övriga projektgruppen (många tunga namn med) siktar på att uppdatera cirka en gång per år. Man samlar också in information om hur det har gått för de organisationer som gett sig på ett införande.
Kolla in www.opensamm.org
Projektets utgångspunkt var Microsofts Security Development Lifecycle (SDL) och OWASPs Comprehensive Lightweight Application Security Process (CLASP). Enligt Pravir så har SDL uppfattats som för tungt, även av Microsoft själva och CLASP uppfattats som bra men mest en samling aktiviteter utan ordning eller prioritet. Så man ville ta fram något bättre.
Tolv typer av säkerhetsarbete
I OpenSAMM definieras arbete med applikationssäkerhet i fyra huvudkategorier och tre underkategorier:
- Governance - mätetal, utbildning, policy
- Construction - säkerhetskrav, säkerhetsarkitektur, hotmodellering
- Verification - designgranskning, säkerhetstest, kodgranskning
- Deployment - härdning, driftsäkerhet, hantering av sårbarheter och patchar
Inom varje kategori kan man befinna sig på en av fyra nivåer:
0: Inga aktiviteter
1: Grundläggande förståelse, tillgång till information
2: Utrullning i praktiken och arbete med effektiviteten
3: Skalbart användande
Färdkartor för fyra typiska organisationer
Inom OpenSAMM har man tagit fram fyra färdiga färdkartor för typiska organisationer:
- Oberoende mjukvarutillverkare
- Leverantör av webbtjänster på nätet
- Finans- och/eller bankorganisation
- Myndighet
- Organisationer ändrar sig långsamt vilket innebär att ett iterativt införande krävs
- Ingen lösning passar alla vilket innebär att man måste göra riskbaserade val
OpenSAMM har släppts i version 1.0 och används redan av många organisationer. Pravir och övriga projektgruppen (många tunga namn med) siktar på att uppdatera cirka en gång per år. Man samlar också in information om hur det har gått för de organisationer som gett sig på ett införande.
Kolla in www.opensamm.org
Ross Anderson om framtiden: 10 % hackade klienter
Första blogginlägget från OWASP AppSec 2009 i Krakow, Polen.
Ross Anderson inledde konferensen med sin syn på säkerhet i webbapplikationer och web 2.0. Precis som i sin välkända bok Security Engineering så har han ofta helt andra perspektiv än säkerhetsfolket i allmänhet. Intressanta perspektiv.
Varför går det fortfarande fel?
Ja, varför bygger vi fortfarande osäkra applikationer? Problemen har ju varit kända i 40 år. Enligt Ross beror det inte bara på bristfällig ingenjörskonst. System är ofta osäkra pga att de som beställer dem, driftar dem eller är ansvariga för att fixa fel i dem inte har några incitament. T ex inom sjukvård är det ofta läkare och chefer som beställer mjukvara. De ser till verksamheten, inte till it-säkerhet.
Leverantörernas fel?
Men borde inte leverantörerna, som är experter på att utveckla applikationer bygga säkra system även om kunden har missat att kravställa säkerheten? Nej, åtminstone inte de som bygger för en marknad. Eftersom time-to-market spelar en avgörande roll och har gjort det under hela IT-eran så skippar man säkerheten tills det är ett publikt problem.
IT-branschen domineras av så kallade first-movers, dvs företag som knep en marknad för att de var först med en produkt som svarade mot användarnas behov. Windows+Office, iPod och Symbian har alla sådana tendenser. Det i sin tur beror på att utvecklingskostnaden i princip är hela kostnaden. Att reproducera mjukvara och distribuera via nätet är i praktiken gratis för de stora spelarna. Man har alltså en marginalkostnad nära noll.
Antag att Windows+Office eller MacOS+iWork kostar 10000 kr per anställd per år. Hur mycket kostar det då att gå över till Ubuntu+Open Office? Jo, 10000 kr. Om det kostade mindre så skulle fler byta. Om det skulle kosta mer så skulle Microsoft och Apple höja sina priser. Hur har vi hamnat där?
Jo, med en marginalkostnad på noll för alla leverantörer så finns ett allmänt tryck nedåt på priser. Där hittar man hela gratis-debatten på nätet och "information wants to be free". För att fortsätta kunna ta betalt vill leverantörerna ha en inlåsningseffekt där det gör ont för användarna att byta plattform (återigen, jämför med iPod, Windows+Office, Symbian).
Så det är väldigt viktigt att komma ut på marknaden och låsa in kunderna. Det formulerades av en av de stora operativsystemstillverkarna på 90-talet som "We ship it Tuesday and get it right by version 3". Och Facebooks vd Mark Zuckerberg formulerar det idag som "Growth is primary, revenue is secondary".
Vad leder det till? Jo det driver fram snabba lösningar, applikationer som körs som root och alla fel skylls på användarna.
Sociala nätverk ökar mängden malware
OK, vi har osäkra applikationer, beställare som har för få säkerhetsincitament och leverantörer som är stressade och har för få ekonomiska incitament att bygga säkrare system. Utifrån det, vart är vi på väg? Ross hade en del framtidsutsikter, främst kring nätets sociala funktion.
Ett socialt sammanhang sänker människors gard och ökar riskerna. Det gäller i livet i stort och i sociala nätverk på nätet. Phising som väver in social information från sajter som Facebook ökar sannolikheten att offret klickar på länken. T ex ett fejkat mejl från din arbetskamrat med hans/hennes senaste inlägg på Facebook-väggen. "Klicka här för att läsa mer".
Ska vi vara mer på vår vakt?
Är då lösningen att människor tänker mer på sin personliga integritet? Knappast med tanke på att vårt agerande skiljer sig markant beroende på situation. Folk tänker inte på integritet pga utbildning, de tänker på det utifrån sammanhang. Man gjorde ett stort experiment på Carnegie Mellon University i Pittburgh för att se hur studenter tänkte kring sin integritet.
Först satt man upp en undersökningsapplikation på universitetsnätverket och bad utvalda studenter att svara på frågor om tentafusk, otrohet, droganvändning med mera. Alla frågor ställdes med stigande integritetskänslighet. Man mätte vid vilken nivå studenterna avbröt och vägrade svara. Det definierades som en sorts grundnivå.
Sen satt man upp motsvarande sajt men med information om att alla svar skulle krypteras, ip-adresser inte skulle loggas och så vidare. Nu avbröt studenterna tidigare! Varför? Jo, all information om säkerhet hade fått dem att tänka på sin integritet.
Sist gjorde man en extern sajt med fokus på "Show us how bad you are!". Studenterna svarade nu på långt fler och mer känsliga frågor.
Slutsatsen blev: Synliggör inte integritet och säkerhet om du vill ha folks personliga information. Och det är det Facebook har gjort. T ex visar man som default upp åtta slumpvisa vänner även om man sagt att ens profil inte ska vara synlig offentligt. Och det visar sig att just åtta vänner är precis nog för att dra slutsatser om vem du är, typiskt såna slutsatser som Facebooks kunder vill dra. Vill man som användare hindra läckage så finns (enligt Ross) 60 inställningar på sju olika sidor. Om användarna klagar svarar man bara "Titta det finns en inställning för det."
Det här kallar Ross för en privacy theatre - man ger sken av att värna integritet och säkerhet men egentligen bygger hela affärsidén på bristande integritet.
Förvänta er att 10 % av alla klienter är hackade
Med det växande intresset för sociala nätverk på nätet, den sänkta garden de ger, de osäkra applikationerna och den växande malware-marknaden så gissar Ross Anderson på att vi kommer ha mellan 1 och 10 % hackade klienter som jämviktsläge i framtiden. Det är under de förutsättningarna vi måste bygga internetbanker, intranät och molnapplikationer.
Ross Anderson inledde konferensen med sin syn på säkerhet i webbapplikationer och web 2.0. Precis som i sin välkända bok Security Engineering så har han ofta helt andra perspektiv än säkerhetsfolket i allmänhet. Intressanta perspektiv.
Varför går det fortfarande fel?
Ja, varför bygger vi fortfarande osäkra applikationer? Problemen har ju varit kända i 40 år. Enligt Ross beror det inte bara på bristfällig ingenjörskonst. System är ofta osäkra pga att de som beställer dem, driftar dem eller är ansvariga för att fixa fel i dem inte har några incitament. T ex inom sjukvård är det ofta läkare och chefer som beställer mjukvara. De ser till verksamheten, inte till it-säkerhet.
Leverantörernas fel?
Men borde inte leverantörerna, som är experter på att utveckla applikationer bygga säkra system även om kunden har missat att kravställa säkerheten? Nej, åtminstone inte de som bygger för en marknad. Eftersom time-to-market spelar en avgörande roll och har gjort det under hela IT-eran så skippar man säkerheten tills det är ett publikt problem.
IT-branschen domineras av så kallade first-movers, dvs företag som knep en marknad för att de var först med en produkt som svarade mot användarnas behov. Windows+Office, iPod och Symbian har alla sådana tendenser. Det i sin tur beror på att utvecklingskostnaden i princip är hela kostnaden. Att reproducera mjukvara och distribuera via nätet är i praktiken gratis för de stora spelarna. Man har alltså en marginalkostnad nära noll.
Antag att Windows+Office eller MacOS+iWork kostar 10000 kr per anställd per år. Hur mycket kostar det då att gå över till Ubuntu+Open Office? Jo, 10000 kr. Om det kostade mindre så skulle fler byta. Om det skulle kosta mer så skulle Microsoft och Apple höja sina priser. Hur har vi hamnat där?
Jo, med en marginalkostnad på noll för alla leverantörer så finns ett allmänt tryck nedåt på priser. Där hittar man hela gratis-debatten på nätet och "information wants to be free". För att fortsätta kunna ta betalt vill leverantörerna ha en inlåsningseffekt där det gör ont för användarna att byta plattform (återigen, jämför med iPod, Windows+Office, Symbian).
Så det är väldigt viktigt att komma ut på marknaden och låsa in kunderna. Det formulerades av en av de stora operativsystemstillverkarna på 90-talet som "We ship it Tuesday and get it right by version 3". Och Facebooks vd Mark Zuckerberg formulerar det idag som "Growth is primary, revenue is secondary".
Vad leder det till? Jo det driver fram snabba lösningar, applikationer som körs som root och alla fel skylls på användarna.
Sociala nätverk ökar mängden malware
OK, vi har osäkra applikationer, beställare som har för få säkerhetsincitament och leverantörer som är stressade och har för få ekonomiska incitament att bygga säkrare system. Utifrån det, vart är vi på väg? Ross hade en del framtidsutsikter, främst kring nätets sociala funktion.
Ett socialt sammanhang sänker människors gard och ökar riskerna. Det gäller i livet i stort och i sociala nätverk på nätet. Phising som väver in social information från sajter som Facebook ökar sannolikheten att offret klickar på länken. T ex ett fejkat mejl från din arbetskamrat med hans/hennes senaste inlägg på Facebook-väggen. "Klicka här för att läsa mer".
Ska vi vara mer på vår vakt?
Är då lösningen att människor tänker mer på sin personliga integritet? Knappast med tanke på att vårt agerande skiljer sig markant beroende på situation. Folk tänker inte på integritet pga utbildning, de tänker på det utifrån sammanhang. Man gjorde ett stort experiment på Carnegie Mellon University i Pittburgh för att se hur studenter tänkte kring sin integritet.
Först satt man upp en undersökningsapplikation på universitetsnätverket och bad utvalda studenter att svara på frågor om tentafusk, otrohet, droganvändning med mera. Alla frågor ställdes med stigande integritetskänslighet. Man mätte vid vilken nivå studenterna avbröt och vägrade svara. Det definierades som en sorts grundnivå.
Sen satt man upp motsvarande sajt men med information om att alla svar skulle krypteras, ip-adresser inte skulle loggas och så vidare. Nu avbröt studenterna tidigare! Varför? Jo, all information om säkerhet hade fått dem att tänka på sin integritet.
Sist gjorde man en extern sajt med fokus på "Show us how bad you are!". Studenterna svarade nu på långt fler och mer känsliga frågor.
Slutsatsen blev: Synliggör inte integritet och säkerhet om du vill ha folks personliga information. Och det är det Facebook har gjort. T ex visar man som default upp åtta slumpvisa vänner även om man sagt att ens profil inte ska vara synlig offentligt. Och det visar sig att just åtta vänner är precis nog för att dra slutsatser om vem du är, typiskt såna slutsatser som Facebooks kunder vill dra. Vill man som användare hindra läckage så finns (enligt Ross) 60 inställningar på sju olika sidor. Om användarna klagar svarar man bara "Titta det finns en inställning för det."
Det här kallar Ross för en privacy theatre - man ger sken av att värna integritet och säkerhet men egentligen bygger hela affärsidén på bristande integritet.
Förvänta er att 10 % av alla klienter är hackade
Med det växande intresset för sociala nätverk på nätet, den sänkta garden de ger, de osäkra applikationerna och den växande malware-marknaden så gissar Ross Anderson på att vi kommer ha mellan 1 och 10 % hackade klienter som jämviktsläge i framtiden. Det är under de förutsättningarna vi måste bygga internetbanker, intranät och molnapplikationer.
På plats i Krakow
Sent omsider kom jag fram till hotellrummet i Krakow, Polen. Imorgon bitti börjar OWASP AppSec Europe 2009 och vi bloggar så klart!
Mitt viktigaste ärende här är mötet om AppSec 2010 i Stockholm. Det blir spännande att höra vad ledningen för OWASP säger om våra planer för datum, lokaler och upplägg.
Mitt viktigaste ärende här är mötet om AppSec 2010 i Stockholm. Det blir spännande att höra vad ledningen för OWASP säger om våra planer för datum, lokaler och upplägg.
måndag 11 maj 2009
Säkerheten i Struts 2
OWASP Intrinsic Security Working Group har precis släppt en publikation som analyserar säkerheten i Struts 2. Dessutom har de tagit fram kod för att överbrygga de luckor som finns. Jag har bara ögnat igenom det än men det ser mycket intressant ut. T ex visar man följande:
- Skapa en autentiseringsinterceptor
- Skapa en rollinterceptor (accesskontroll på sidnivå utifrån användarens rättigheter)
- Skapa en interceptor för header-caching
- Motverka CSRF med den inbyggda tokenSession-interceptorn
- Förbättrad felhantering
- Skapa en interceptor som låser en session till SSL
- Skapa nya JSESSIONID efter autenticering/auktorisering
måndag 4 maj 2009
Seminariekväll om kodanalys och -granskning: Referat del 2
James Dickson från Simovits Consulting hade kvällens andra presentation. Ämnet var manuell kodgranskning. Efter en lätt självironisk start så hakade åhörarna på presentatörens flöde av insikter, verklighetsutblickar och småskämt på egen bekostnad. En egen stil helt enkelt. Trevligt.
Vem beställer manuell kodgranskning?
Drivande för att utvärdera säkerheten i egenutvecklade system är antingen en säkerhetskritisk bransch där organisationen är van att hantera risk eller compliance-krav såsom PCI DSS. De flesta kunder som har köpt granskning av James har redan gjort automatiska tester i stil med vad Fortify erbjuder. Man tar helst inte in en manuell granskare utan att ha gjort hemläxan.
Hur analyserar man?
Hur analyserar man? Ingen svart magi här. Det handlar om läsande av kod, checklistor och fokus på "dyra" dataflöden såsom pengar, krediter, personuppgifter och filer. Det vill säga sådan data som är kringgärdade säkerhetskrav. Man spanar efter rollbacks, bruten atomicitet, trasig felhantering och logiska fel. Det känns alltid viktigt att åstadkomma något så om koden ser fläckfri ut kan man alltid granska dokumentationen. Där finns dessutom många ledtrådar till var buggar lurar -- kommentarer som innehåller TODO, wtf och hmm är varningstecken.
För att göra en bra analys kan man behöva tillgång till andra specialister att bolla med. I James fall har han tillgång till folk som är duktiga på kryptografi och nätverkskonfiguration. Så fort han stöter på något skumt inom de områdena så kan han kolla med kollegorna back-office.
Vad hittar man?
De flesta säkerhetsbrister man hittar är osofistikerade. Man har försökt säkra upp genom gömda filer, man har lagt säkerhetskontroller hos klienten, otillåtna funktioner skyddas bara med hjälp av inaktiverade knappar som enkelt kan aktiveras, och i webbapplikationer ser man ofta ett .Net-viewstate som en attackerare kan koda av, ändra och koda om utan att servern reagerar. James har ett par egenutvecklade verktyg han kör för att testa de här sakerna.
Lite mer avancerade fel kan röra sig om att autentisering glöms bort på vissa sidor/funktioner i en webbapp, att sekvensnummer eller slumpfrön inte har tillräcklig entropi, brister i fel- eller trådhantering, eller obsolet kryptering som SSL 2.0 eller LM-hashar.
Svårast är att hitta deadlocks och race conditions och där är race conditions så klart allvarligast.
Vad blir reaktionen hos utvecklarna?
Hur reagerar utvecklarna som granskas? Kunderna kommer från två kategorier -- de som kan säkerhet och arbetar med det och de som ignorerat säkerhet och nu måste granska sin kod pga compliance. De förstnämnda blir nästan alltid glada för det man hittar -- de vill höja säkerheten. De sistnämda blir oftare arga och en granskning kan leda till dålig stämning i teamet.
James har inte mött på överdrivet mycket politik, dvs där utfallet av granskningen styrts av vem och vilka man "får" kritisera. Ofta har uppdraget beställts av någon högre upp och där är det sanningen som gäller eftersom de inte har något personligt att vinna eller förlora.
Bra trender
James ser vissa positiva trender. Utvecklare har fått både bättre verktyg och ökad kunskap om hur man bygger säkra system. Kompilatorer gör kollar eller bygger in skydd (t ex kanarievärden för att skydda mot vissa buffer overflows), utvecklingsmiljöerna ger allmänt stöd för högre kvalitet och nya språk har färre säkerhetsproblem. Fler och fler utvecklare intresserar sig också för säkerhet.
Dåliga trender
Trots många positiva tecken så tyckte sig James att bristerna kommer att öka. Komplexitetsnivån på applikationer stiger ständigt, applikationer består av ett stort antal subkomponenter som var och en måste konfigureras korrekt och fungera bra ihop, och många tekniker som språk och ramverk används hej vilt och i hårresande kombinationer. I den soppan så blir ofta kvaliteten bristande.
Fler men klurigare brister ger fortsatt flöde av granskningsuppdrag men med färre quick wins.
Våra kommentarer
[Martin]
Själv kan jag hålla med om komplexiteten i floran av tekniker; många verktyg nuförtiden blir alltmer specialiserade; Cherokee, Lighttpd och Nginx är tre exempel på duktigt optimerade webservrar som slåss om förstaplatsen. Det är helt klart en större utmaning för en säkerhetsgranskare ju fler nischade verktyg som används i systemet. Denna komplexitetsökning kan dock vara klart värd att ta -- en one-size-fits-all-monster som Apache är inte världens säkraste programvara heller, vilket James gärna påpekade.
[John]
Jag har stött på rätt mycket politik när jag har testat eller utvärderat system. I ett fall har jag tvingats omformulera kritik till utvecklingsförslag. I ett fall har jag tvingats signera godkända testprotokoll trots att felen inte var åtgärdade än -- "Vi lovar att fixa det sen. Men vi måste ha din signatur på protokollet nu, annars kan vi inte leverera till slutkund." Slutkunden var i tredje världen och hade själva godkänt specar som jag hittade allvarliga fel i. Att ta upp det skulle äventyra hela leveransen eftersom folk skulle tappa ansiktet och så vidare. Sättet att lösa det på var att "upptäcka" felen efter leverans och fixa på plats. Då blev alla nöjda.
Att James inte mött på så mycket politik och bråk tyder på en ökad professionalism bland dem som utvecklar system. Bra.
Jag tror precis som James att komplexiteten är en av de avgörande faktorerna. Men jag sällar mig inte till skaran som tycker att vi ska ändra något där. Vi vill ha mer komplexa it-system. Inte för komplexitetens egen skull utan för att vi vill ha mer it och mer avancerad it. För att klara att bygga större och mer komplexa system så måste fler och fler delar i utvecklingskedjan kvalitetssäkras. Det sker med alla ingenjörsdiscipliner och kommer även ske med vår. Programmeringsspråk, kunskap, metodik, kodanalys och testning måste möta upp komplexitetsutmaningen. Annars får vi osäkra, ineffektiva, oförvaltningsbara system.
Vänta nu -- är det inte osäkra, ineffektiva, oförvaltningsbara system vi har idag? ;)
Vem beställer manuell kodgranskning?
Drivande för att utvärdera säkerheten i egenutvecklade system är antingen en säkerhetskritisk bransch där organisationen är van att hantera risk eller compliance-krav såsom PCI DSS. De flesta kunder som har köpt granskning av James har redan gjort automatiska tester i stil med vad Fortify erbjuder. Man tar helst inte in en manuell granskare utan att ha gjort hemläxan.
Hur analyserar man?
Hur analyserar man? Ingen svart magi här. Det handlar om läsande av kod, checklistor och fokus på "dyra" dataflöden såsom pengar, krediter, personuppgifter och filer. Det vill säga sådan data som är kringgärdade säkerhetskrav. Man spanar efter rollbacks, bruten atomicitet, trasig felhantering och logiska fel. Det känns alltid viktigt att åstadkomma något så om koden ser fläckfri ut kan man alltid granska dokumentationen. Där finns dessutom många ledtrådar till var buggar lurar -- kommentarer som innehåller TODO, wtf och hmm är varningstecken.
För att göra en bra analys kan man behöva tillgång till andra specialister att bolla med. I James fall har han tillgång till folk som är duktiga på kryptografi och nätverkskonfiguration. Så fort han stöter på något skumt inom de områdena så kan han kolla med kollegorna back-office.
Vad hittar man?
De flesta säkerhetsbrister man hittar är osofistikerade. Man har försökt säkra upp genom gömda filer, man har lagt säkerhetskontroller hos klienten, otillåtna funktioner skyddas bara med hjälp av inaktiverade knappar som enkelt kan aktiveras, och i webbapplikationer ser man ofta ett .Net-viewstate som en attackerare kan koda av, ändra och koda om utan att servern reagerar. James har ett par egenutvecklade verktyg han kör för att testa de här sakerna.
Lite mer avancerade fel kan röra sig om att autentisering glöms bort på vissa sidor/funktioner i en webbapp, att sekvensnummer eller slumpfrön inte har tillräcklig entropi, brister i fel- eller trådhantering, eller obsolet kryptering som SSL 2.0 eller LM-hashar.
Svårast är att hitta deadlocks och race conditions och där är race conditions så klart allvarligast.
Vad blir reaktionen hos utvecklarna?
Hur reagerar utvecklarna som granskas? Kunderna kommer från två kategorier -- de som kan säkerhet och arbetar med det och de som ignorerat säkerhet och nu måste granska sin kod pga compliance. De förstnämnda blir nästan alltid glada för det man hittar -- de vill höja säkerheten. De sistnämda blir oftare arga och en granskning kan leda till dålig stämning i teamet.
James har inte mött på överdrivet mycket politik, dvs där utfallet av granskningen styrts av vem och vilka man "får" kritisera. Ofta har uppdraget beställts av någon högre upp och där är det sanningen som gäller eftersom de inte har något personligt att vinna eller förlora.
Bra trender
James ser vissa positiva trender. Utvecklare har fått både bättre verktyg och ökad kunskap om hur man bygger säkra system. Kompilatorer gör kollar eller bygger in skydd (t ex kanarievärden för att skydda mot vissa buffer overflows), utvecklingsmiljöerna ger allmänt stöd för högre kvalitet och nya språk har färre säkerhetsproblem. Fler och fler utvecklare intresserar sig också för säkerhet.
Dåliga trender
Trots många positiva tecken så tyckte sig James att bristerna kommer att öka. Komplexitetsnivån på applikationer stiger ständigt, applikationer består av ett stort antal subkomponenter som var och en måste konfigureras korrekt och fungera bra ihop, och många tekniker som språk och ramverk används hej vilt och i hårresande kombinationer. I den soppan så blir ofta kvaliteten bristande.
Fler men klurigare brister ger fortsatt flöde av granskningsuppdrag men med färre quick wins.
Våra kommentarer
[Martin]
Själv kan jag hålla med om komplexiteten i floran av tekniker; många verktyg nuförtiden blir alltmer specialiserade; Cherokee, Lighttpd och Nginx är tre exempel på duktigt optimerade webservrar som slåss om förstaplatsen. Det är helt klart en större utmaning för en säkerhetsgranskare ju fler nischade verktyg som används i systemet. Denna komplexitetsökning kan dock vara klart värd att ta -- en one-size-fits-all-monster som Apache är inte världens säkraste programvara heller, vilket James gärna påpekade.
[John]
Jag har stött på rätt mycket politik när jag har testat eller utvärderat system. I ett fall har jag tvingats omformulera kritik till utvecklingsförslag. I ett fall har jag tvingats signera godkända testprotokoll trots att felen inte var åtgärdade än -- "Vi lovar att fixa det sen. Men vi måste ha din signatur på protokollet nu, annars kan vi inte leverera till slutkund." Slutkunden var i tredje världen och hade själva godkänt specar som jag hittade allvarliga fel i. Att ta upp det skulle äventyra hela leveransen eftersom folk skulle tappa ansiktet och så vidare. Sättet att lösa det på var att "upptäcka" felen efter leverans och fixa på plats. Då blev alla nöjda.
Att James inte mött på så mycket politik och bråk tyder på en ökad professionalism bland dem som utvecklar system. Bra.
Jag tror precis som James att komplexiteten är en av de avgörande faktorerna. Men jag sällar mig inte till skaran som tycker att vi ska ändra något där. Vi vill ha mer komplexa it-system. Inte för komplexitetens egen skull utan för att vi vill ha mer it och mer avancerad it. För att klara att bygga större och mer komplexa system så måste fler och fler delar i utvecklingskedjan kvalitetssäkras. Det sker med alla ingenjörsdiscipliner och kommer även ske med vår. Programmeringsspråk, kunskap, metodik, kodanalys och testning måste möta upp komplexitetsutmaningen. Annars får vi osäkra, ineffektiva, oförvaltningsbara system.
Vänta nu -- är det inte osäkra, ineffektiva, oförvaltningsbara system vi har idag? ;)
lördag 2 maj 2009
Seminariekväll om kodanalys och -granskning: Referat del 1
För alla som inte var med på tisdagens seminariekväll om kodanalys och -granskning (eller har dåligt minne :) så kommer här en betraktande sammanfattning. Det är jag, Martin Holst Swende (MSC) och Robert Carlsson (BankId) som hjälpts åt att blogga.
Fortify Software sponsrade evenemanget, vilket inte minst resulterade den bästa buffén i Owasp Swedens anrika historia. Bra deltagande med ca 75 personer. På agendan stod:
18.00 Fredrik Möller, Fortify: Intro och Fortifys engagemang i OWASP
18.10 David Anumudu, Fortify: Presentation + demo av Fortify Solution (eng)
19.40 James Dickson, Simovits Consulting: "Code review ur ett säkerhetsperspektiv"
Vilka är Fortify?
Fortify är ca 180 anställda worldwide. Man värnar om applikationssäkerhet, t ex genom att se hur man kan stödja OWASP Top 10 i sina produkter. Man har också ett nära samarbete med OWASP i flera länder.
Fortify tar bra betalt där man kan, men bidrar också i en del öppna sammanhang. T ex Java Open Review där deras analysresultat publiceras öppet.
Varför har vi osäkra applikationer?
David Anumudu från Fortify inledde med sin syn på varför vi har osäkra applikationer idag. Dels beror det på komplexiteten i produkterna. Statistiskt så finns det ca 20-30 buggar per KLOC (tusen rader kod). Komplexitet och storlek på operativsystem och applikationer ökar kraftigt. Windows idag består av 55 miljoner rader kod (från 12 miljoner 1998). En komplett Debian Linux-distribution består av 283 miljoner rader kod (från 55 miljoner rader 2000). Antalet rapporterade svagheter ökar i motsvarande grad. Det är helt enkelt för många miljoner rader kod för att utvecklare av kött och blod ska kunna hålla ihop både helhet och detaljer.
I världen finns attraktiva tillgångar och både goda och onda användare. Det som skall kontrollera vem som får använda tillgångarna är programvara som ofta ska vara helt öppen och tillgänglig för alla men samtidigt helt säker. Kundens eller de tilltänkta användarnas outalade krav adresseras typsikt inte under utveckling -- står det inte i kraven så kommer det inte med. Säkerhet är ofta ett outalat krav än idag.
Penetrationstester har länge varit lösningen. Men de är som praktiska krocktester -- man testar efter att man byggt. Lösningen enligt David är att göra som i bilindustrin. Designa in säkerhet i bilarna från början och krocktesta simulerat innan verkligheten. Inom applikationssäkerhet bör vi alltså testa först under utvecklingen innan vi pentestar. Det är dessutom mycket billigare.
Fortifys produkter för kodanalys
David demonstrerade Fortifys produkter och svarade på frågor. Den automatiserade kodanalysen är uppdelad i tre delar; SCA (Source Code Analysis) - statisk kodanalys, PTA (Progam Trace Analysis) - injicering av testkod i kodbas för att analysera under körning, samt RTA (Real-Time Analysis) för kod som är i drift. SCA kan utföra 400 kontroller, t ex finns det risk för XSS?
Demonstrationen genomfördes på en sårbar demoapplikation skriven i Java/jsp. 8500 rader kod analyserades på två minuter med verktyget. Det hittade ett antal problem som sorteras, grupperas och värderas. XSS, lösenordshantering, personlig integritet, SQL-injektion och så vidare.
För varje problem visas ett exempel på hur data flödar in och ut ur klasser (metoder och variabler om man vill) och visar i form av ett sekvensdiagram var sårbarheten uppstår. Allt enligt det kända source/sink-mönstret, dvs källor till elak data (source) och farlig användning av elak data (sink). Man får också information om vad sårbarheten kan ge upphov till för skada och exempel på hur man kan komma till rätta med den.
Frågor från publiken
- Skall man bara genomföra statisk kodanalys?
Statisk analys kan ses som ett mikroskop som ger detaljer på hur sårbarheter ser ut. Det behöver kompletteras med en manuell analys för att få överblicken och hitta logiska fel. Den statiska analysen kan se komplexa dataflöden och samband och ta bort repetetivt detaljarbete från de manuella granskarna. Såväl Fortify som Simovits Consulting tyckte att automatisk och manuella granskningar kompletterar varandra och är nödvändiga för ett bra resultat; den automatiska kodgransningen tar hand om the nitty gritty details och komplexa dataflöden som är alldeles för snåriga att hitta vid okulär besiktning, medan den manuella granskningen mer bör inriktas på en högre nivå -- the big picture.
- Är falska positiver vanliga?
Ca 5 % för språk som C# och Java. Mer (10-20 %) för C/C++.
- Vilka programmeringspråk stödjer Fortiys verktyg?
Man stödjer 17 programmeringsspråk (C, C++, Java, .Net är de stora).
Våra egna kommentarer
[Martin]
Jag blev riktigt imponerad av mognadsgraden på analysen, kanske har de kodanalysverktyg jag tidigare stött på gett mig en ofördelaktig bild av dem. Dock, antalet stödda plattformar för PTA och RTA verkade inte vara så stort. Själv undrade jag kodanalysen hanterade dynamiska språk, flera av de 'heta' språken har ännu inte stöd av Fortify (ex Ruby el Python).
[John]
Jag har rotat mycket i statisk analys och var inte helt nöjd med Davids svar på frågor om falska positiver och om analys av dynamiska språk.
Att säga att "jag tror inte det är svårare för oss att analysera dynamiskt typade språk än statiskt typade" betyder antingen att man inte vet tillräckligt mycket om statisk analys eller att man inte vill gå in på detaljer under presentationen. David kan säkert sina saker men jag var i alla fall redo för lite mer detaljer än vad som gavs. Det bör vara en helt annan sak att göra statisk data- och kontrollflödesanalys på ett dynamiskt typat språk än ett statiskt typat.
Gällande falska positiver kontra falska negativer så var svaren också lite svepande. Fortify är primärt ute efter att lösa kundproblem vilket rimligtvis betyder att de har orienterat begränsningarna i sin kodanalys åt vad kunder vill ha. Det hade jag velat höra lite mer om. För det innebär alltid avvägningar mellan träffsäkerhet, sundhet och kompletthet.
Med det sagt så tyckte jag Fortify kunde visa upp en mogen produkt som på många sätt verkade vara anpassad för riktiga projekt. Det är vad vi behöver.
Fortify Software sponsrade evenemanget, vilket inte minst resulterade den bästa buffén i Owasp Swedens anrika historia. Bra deltagande med ca 75 personer. På agendan stod:
18.00 Fredrik Möller, Fortify: Intro och Fortifys engagemang i OWASP
18.10 David Anumudu, Fortify: Presentation + demo av Fortify Solution (eng)
19.40 James Dickson, Simovits Consulting: "Code review ur ett säkerhetsperspektiv"
Vilka är Fortify?
Fortify är ca 180 anställda worldwide. Man värnar om applikationssäkerhet, t ex genom att se hur man kan stödja OWASP Top 10 i sina produkter. Man har också ett nära samarbete med OWASP i flera länder.
Fortify tar bra betalt där man kan, men bidrar också i en del öppna sammanhang. T ex Java Open Review där deras analysresultat publiceras öppet.
Varför har vi osäkra applikationer?
David Anumudu från Fortify inledde med sin syn på varför vi har osäkra applikationer idag. Dels beror det på komplexiteten i produkterna. Statistiskt så finns det ca 20-30 buggar per KLOC (tusen rader kod). Komplexitet och storlek på operativsystem och applikationer ökar kraftigt. Windows idag består av 55 miljoner rader kod (från 12 miljoner 1998). En komplett Debian Linux-distribution består av 283 miljoner rader kod (från 55 miljoner rader 2000). Antalet rapporterade svagheter ökar i motsvarande grad. Det är helt enkelt för många miljoner rader kod för att utvecklare av kött och blod ska kunna hålla ihop både helhet och detaljer.
I världen finns attraktiva tillgångar och både goda och onda användare. Det som skall kontrollera vem som får använda tillgångarna är programvara som ofta ska vara helt öppen och tillgänglig för alla men samtidigt helt säker. Kundens eller de tilltänkta användarnas outalade krav adresseras typsikt inte under utveckling -- står det inte i kraven så kommer det inte med. Säkerhet är ofta ett outalat krav än idag.
Penetrationstester har länge varit lösningen. Men de är som praktiska krocktester -- man testar efter att man byggt. Lösningen enligt David är att göra som i bilindustrin. Designa in säkerhet i bilarna från början och krocktesta simulerat innan verkligheten. Inom applikationssäkerhet bör vi alltså testa först under utvecklingen innan vi pentestar. Det är dessutom mycket billigare.
Fortifys produkter för kodanalys
David demonstrerade Fortifys produkter och svarade på frågor. Den automatiserade kodanalysen är uppdelad i tre delar; SCA (Source Code Analysis) - statisk kodanalys, PTA (Progam Trace Analysis) - injicering av testkod i kodbas för att analysera under körning, samt RTA (Real-Time Analysis) för kod som är i drift. SCA kan utföra 400 kontroller, t ex finns det risk för XSS?
Demonstrationen genomfördes på en sårbar demoapplikation skriven i Java/jsp. 8500 rader kod analyserades på två minuter med verktyget. Det hittade ett antal problem som sorteras, grupperas och värderas. XSS, lösenordshantering, personlig integritet, SQL-injektion och så vidare.
För varje problem visas ett exempel på hur data flödar in och ut ur klasser (metoder och variabler om man vill) och visar i form av ett sekvensdiagram var sårbarheten uppstår. Allt enligt det kända source/sink-mönstret, dvs källor till elak data (source) och farlig användning av elak data (sink). Man får också information om vad sårbarheten kan ge upphov till för skada och exempel på hur man kan komma till rätta med den.
Frågor från publiken
- Skall man bara genomföra statisk kodanalys?
Statisk analys kan ses som ett mikroskop som ger detaljer på hur sårbarheter ser ut. Det behöver kompletteras med en manuell analys för att få överblicken och hitta logiska fel. Den statiska analysen kan se komplexa dataflöden och samband och ta bort repetetivt detaljarbete från de manuella granskarna. Såväl Fortify som Simovits Consulting tyckte att automatisk och manuella granskningar kompletterar varandra och är nödvändiga för ett bra resultat; den automatiska kodgransningen tar hand om the nitty gritty details och komplexa dataflöden som är alldeles för snåriga att hitta vid okulär besiktning, medan den manuella granskningen mer bör inriktas på en högre nivå -- the big picture.
- Är falska positiver vanliga?
Ca 5 % för språk som C# och Java. Mer (10-20 %) för C/C++.
- Vilka programmeringspråk stödjer Fortiys verktyg?
Man stödjer 17 programmeringsspråk (C, C++, Java, .Net är de stora).
Våra egna kommentarer
[Martin]
Jag blev riktigt imponerad av mognadsgraden på analysen, kanske har de kodanalysverktyg jag tidigare stött på gett mig en ofördelaktig bild av dem. Dock, antalet stödda plattformar för PTA och RTA verkade inte vara så stort. Själv undrade jag kodanalysen hanterade dynamiska språk, flera av de 'heta' språken har ännu inte stöd av Fortify (ex Ruby el Python).
[John]
Jag har rotat mycket i statisk analys och var inte helt nöjd med Davids svar på frågor om falska positiver och om analys av dynamiska språk.
Att säga att "jag tror inte det är svårare för oss att analysera dynamiskt typade språk än statiskt typade" betyder antingen att man inte vet tillräckligt mycket om statisk analys eller att man inte vill gå in på detaljer under presentationen. David kan säkert sina saker men jag var i alla fall redo för lite mer detaljer än vad som gavs. Det bör vara en helt annan sak att göra statisk data- och kontrollflödesanalys på ett dynamiskt typat språk än ett statiskt typat.
Gällande falska positiver kontra falska negativer så var svaren också lite svepande. Fortify är primärt ute efter att lösa kundproblem vilket rimligtvis betyder att de har orienterat begränsningarna i sin kodanalys åt vad kunder vill ha. Det hade jag velat höra lite mer om. För det innebär alltid avvägningar mellan träffsäkerhet, sundhet och kompletthet.
Med det sagt så tyckte jag Fortify kunde visa upp en mogen produkt som på många sätt verkade vara anpassad för riktiga projekt. Det är vad vi behöver.
Prenumerera på:
Inlägg (Atom)