torsdag 25 februari 2010

Web Security Dojo

En ny öppen labbmiljö för appsec-utbildning ser dagens ljus -- Web Security Dojo. Den är byggd på Ubuntu och finns som virtuell maskin för Virtual Box och VMWare.

På den hittar vi godingar som ...
  • OWASP WebGoat
  • Damn Vulnerable Web App
  • Hacme Casino
  • OWASP InsecureWebApp
  • ... plus specialgjorda PHP-skript med REST- och JSON-labbar
Bland verktygen finns ...
  • Burp Suite (gratisversionen)
  • w3af
  • OWASP Skavenger
  • OWASP Dirbuster
  • Paros
  • Webscarab
  • Ratproxy
  • sqlmap
  • ... plus några bra Firefox add-ons

tisdag 23 februari 2010

Se upp med genererad toString()

För ett par dagar sen råkade jag och en kollega ut för en lite skrämmande sak. Vi satt och arbetade med loggningen i en webbapplikation.

I och med det så lät vi utvecklingsmiljön (IDEA IntelliJ) generera ett antal toString()-metoder åt oss för att öka tydligheten i loggmeddelandena. IntelliJ gör oftast riktigt snygga såna metoder. Men plötsligt upptäcker vi att lösenord skrivs ner i loggen för nyregistrerade användare! Förvisso bara i testmiljön men nog för att man ska få hjärtat i halsgropen.

Boven i dramat var en av våra genererade toString(). Ptja, hur skulle IntelliJ kunna veta att just password-attributet inte skulle med i utdata?

public class UserPutData {
private final String userName;
private final String password;
private final String email;
private final String firstname;
private final String surname;
private final String postcode;

...

@Override
public String toString() {
return "UserPutData{" +
"userName='" + userName + '\'' +
", password='" + password + '\'' +
", email='" + email + '\'' +
", firstName='" + firstname + '\'' +
", surname='" + surname + '\'' +
", postcode='" + postcode + '\'' +
'}';
}
}

Ooups!

lördag 20 februari 2010

Är checklistor lösningen?

Strax efter nyår så fördes en intressant diskussion på Secure Coding mailinglist. Den gällde något så "tråkigt" som checklistor. Är det lösningen på problemen med osäkra applikationer?

En amerikansk kirurg och medicinforskare vid Harvard Medical, Atul Gawande, har nyligen gett ut en bok med titeln "The Checklist Manifesto: How to Get Things Right". Genom forskning har han och hans team visat att den kanske största kvalitetsförbättringen inom sjukvård (speciellt operationer) kan nås med enkla checklistor. Jämfört med vad nya läkemedel och ny utrustning kan göra så är Atuls checklistor inget mindre än en revolution.

Samtidigt har han mött på enormt motstånd från läkarkåren och skrämmande få sjukhus har infört hans checklistor. Orsaken är prestige och status inom yrkeskåren. En högutbildad läkare behöver baske mig inga checklistor, tycks folk tänka. Men Atul Gawande hävdar motsatsen -- ju mer komplext ett yrke är, desto större kvalitetsvinst med checklistor. Därav kopplingen till IT och säkerhet.

Bild från The New Yorker-artikeln om Atuls checklistor (se länk nedan).

Diskussionen på Secure Coding mailinglist handlade om checklistor och mjukvarusäkerhet. Men frågan handlar förstås om kvalitet generellt vid systemutveckling. "Definition of Done" inom agil utveckling är ett exempel på en (liten) checklista. Security Development Lifecycle har andra checklistor inför release.

Verktyg för statisk analys är en sorts automatiserade checklistor. Men är det så att vi som utvecklar och säkerhetstestar mjukvara också behöver checklistor för att ta nästa kvalitetskliv? Hur skulle såna listor se ut? Kommer de användas på daglig basis, vid sprint-slut eller vid produktionssättning/leverans? Många intressanta frågor.

Det finns hur som helst en radiointervju med Atul Gawande på nätet. Jag började faktiskt gråta när han berättar om hur ett operationsteam för första gången lyckades rädda ett barn från en svår typ av olycka. Skillnaden var att man systematiskt gått igenom alla tidigare, misslyckade case och gjort ... en checklista. Lyssna här.

Atul Gawande är också kolumnist i The New Yorker och en bra aritkel om hans Checklist Manifesto finns här.

tisdag 16 februari 2010

PIN-kontroll online i Sverige?

Enligt Logic Group så tillåter EMV-standarden PIN-kontroll online eller offline även när kortläsaren är uppkopplad till banken (läs pdf här). Kontroll offline snabbar upp köpprocessen genom att PIN-koden inte behöver skickas in till banken.

Så här beskrivs det:

2.4 Offline PIN Verification
Offline PIN verification means that the PIN can be verified without going online to the acquiring bank. With offline PIN verification, the PIN that the cardholder enters is checked by the card itself. This will save time at the till because the transaction does not need to go online to check the cardholder’s identity.

2.5 Online PIN Verification
The issuer performs online PIN verification. The PIN entered by the cardholder into the PIN pad is securely encrypted and sent from the terminal to the acquirer in the authorisation request message. This method can be used for both magnetic-stripe and chip card transactions. The card itself can decide to force online PIN verification under certain circumstances. For example, if the pattern of card use is unusual, the card may force online PIN verification to ensure that it is not being used fraudulently. This method can also be used to facilitate cash withdrawal at the Point of Sale.

Mer och mer information verkar nu komma som tyder på att svenska butiker mestadels kör med PIN-kontroll online. T ex så skriver en bank idag att Cambridge-hacket kräver att "terminalen accepterar pinkod offline" vilket ska vara ovanligt i vårt land.

Synd att det tidigare har formulerats som "att kortet används off-line utan kontakt med banken" vilket inte är grejen. Cambridge-hacket fungerar med online-terminaler vilket också står tydligt i artikeln. Men det kräver att just PIN-kontrollen sker offline.

Notera att svenska bankkort fungerar utmärkt utomlands ...

BBC-film med hacket mot chipkort

BBC har intervjuat forskarteamet och filmat en lyckad attack i universitetets kafeteria. Bedragaren går fram, ställer sin vara på disken, stoppar i det manipulerade chipkortet i läsaren, anger PIN-koden 0000 och köpet går igenom med "Verified by PIN" på kvittot. Datorutrustningen och det stulna chipkortet har han i ryggsäcken.

Filmklippet finns här.

Svensk bank om hacket mot chipkort

Nu har en svensk bank gått ut med lugnande besked om chipkort. "Kort med chip – en säker lösning", skriver de (jag länkar inte till dem eftersom den enskilda banken inte är det viktiga). Jag är dock bekant med mycket säkerhetskunniga personer där så jag har förtroende för deras säkerhetstänk. Låt oss därför gå igenom vad de skriver.

"Media har under veckan rapporterat om säkerhetsbrister i kort som har chip. [Bankens] kortexperter ger dock lugnande besked: Kunderna har inget att oroa sig för. Säkerheten med chiptekniken är hög och PIN-koden går inte enkelt att avslöja."

Avslöja PIN-koder? Det har det aldrig varit tal om. Hacket innebär ju att man kan ange vilken PIN-kod som helst och inte behöver "avslöja" något.

"Inga chipkort har kopierats och PIN koden har inte kunnat missbrukas."

Nej, kopiera några kort har det inte heller varit tal om. En bedragare måste alltså stjäla eller hitta ett kort för att kunna utnyttja det.

"I slutet av förra veckan uppmärksammades en rapport från forskare i Cambridge som argumenterar för att chipkort går att manipulera för att utföra falska transaktioner på kundernas konton."

Falska transaktioner är precis vad det handlar om men det stulna kortet behöver inte manipuleras. Det kan utnyttjas direkt efter stölden, utan justeringar. Det är bara att sätta in i bedragarens kortläsare och sätta igång.

"Rapporteringen om att PIN-koden enkelt skulle gå att avslöja stämmer dock inte."

Nej, det har aldrig varit tal om att avslöja PIN-koden. Bedragarna kan ange vilken PIN-kod som helst!

"De scenarier som målas upp i media bygger på experiment utförda i laboratoriemiljö där ett flertal mindre sannolika faktorer skulle behöva samverka för att ett bedrägeri skulle lyckas."

Nej, forskarna har utfört köp på en riktig, uppkopplad kortterminal och kvittot angav "Verified by PIN". Det finns till och med bilder på allt inklusive kvittot i artikeln:


"Resonemanget bygger på att ett kort först stjäls och att avancerad teknik sen används för att manipulera kortet, genom att påverka kommunikationen mellan kort och terminal, samt att kortet används off-line utan kontakt med banken."

Nej och nej. Det stulna kortet behöver inte manipuleras och hacket fungerar på terminaler som är online. Forskarna skriver om de gamla kända hacken mot offline-terminaler. Det här är något helt annat.

Två viktiga saker dock:
  1. Det kan vara så att svenska terminaler gör en PIN-kontroll online. Om så är fallet så bör bankerna komma med den informationen nu. Och blanda inte ihop det med terminaler som är helt offline.
  2. Det går inte att ta ut pengar i bankomat med det nya hacket. Där sker nämligen PIN-kontollen online.
"[Bankens] kort- och terminalexperter (...) upplyser att ett sådant förfarande inte låter sig göras obemärkt och skulle fångas upp av bankens kontrollsystem."

Det här kan alltså vara sant vilket skulle betyda att Sverige har något sorts specialsystem. Det vore bra om bankerna kom med tydlig information på den här punkten -- sker PIN-kontrollen online vid kortköp i Sverige?

"Som vanligt gäller också att kunder som utsätts för bedrägeri alltid ersätts."

Tack! Det var ett besked vi ville ha. Frågan som berörs i forskningsartikeln är bara hur man övertygar bankerna om att ett bedrägeri har skett när de anser att chip+PIN är säkert.

"- Från vad som hittills framkommit är risken för bedrägerier på grund av detta mikroskopisk och därför är vår uppfattning att bankkort med chip är mycket säkra som betalningsmedel."

Forskarna är mycket tydliga på den här punkten -- bedrägerier är högst realistiska och det finns incidenter som tyder på att de redan sker. Kunskapen i kriminella kretsar är god nog för att tillverka en minivariant av den utrustning som krävs.

"- Även om ett kort skulle stjälas eller tappas bort är risken mycket liten för att kortkunden skulle råka illa ut på det sätt som beskrivs i rapporten. Vi som kortutgivare kan tack vare chiptekniken se hur transaktionen genomförts och hålla kortkunden skadeslös om ett bedrägeriförsök mot förmodan skulle ske."

Det är ju just det som hacket går ut på -- det kommer se ut som ett helt vanligt köp med korrekt PIN-kod. Hur ska man då "se hur transaktionen genomförts"?

"Som Sveriges största kortutgivare och Inlösare av korttransaktioner arbetar [Banken] ständigt med att följa teknikutvecklingen och ligga i framkant avseende säkerhet och användbarhet inom kortlösningar, för såväl kund som butik, och följer givetvis den fortsatta utvecklingen på området. Kunder som utsätts för bedrägeriförsök uppmanas alltid kontakta banken."

Så sant som det var sagt -- spärra ditt kort bums om du förlorar det.

Summerat
Jag får uppfattningen att banken antingen inte har läst forskningsartikeln eller sitter inne på information som är specifik för just svenska kortbetalningar. Därför rubbas inte min uppfattning att chipkorten är knäckta.


Fotnot: Jag arbetar i säkerhetsbranschen och har ingen nytta av att skaffa mig ovänner. Skälet att jag skriver om det här är att jag som säkerhetsexpert och som bankkund vill öka säkerheten. Det här är en allmän fråga.

söndag 14 februari 2010

Hacket mot chipkort

Som ni säkert såg på Rapport och har läst på nätet så har forskare vid University of Cambridge, däribland Ross Anderson, hittat ett sätt att betala med chipförsedda bankkort utan den rätta PIN-koden. Deras artikel kommer presenteras vid världens finaste konferens inom säkerhetsforskning -- IEEE Security & Privacy -- i maj. Den finns i draft-version här (pdf).

Hacket i ett nötskal
Forskarna noterade att behörighetssvaret till banken inte innehåller information om hur behörighetskontrollen ägt rum. Dvs banken får inte reda på om du matat in din PIN, skrivit under kvittot eller känner butiksägaren. Banken får bara beskedet "Behörigheten OK".

Så hur lurar man kortläsaren? Jo, genom att sätta i ett preparerat kort som godkänner vilken PIN-kod som helst och säger till det stulna kortet att köpet ska ske med underskrift istället för PIN. Alla andra steg i betalningen genomförs med det stulna kortet direkt.

Figur 1: Forskarnas testmiljö

Hacket i lite mer tekniska termer
Betalning med chipkort sker i tre steg:
  1. Kortkontroll -- talar om vilken bank som har gett ut kortet och att det är i omanipulerat skick. Sker mha elektronisk signatur.
  2. Behörighetskontroll -- ser till att personen har rätt att använda kortet, typiskt med PIN-kod. Sker utan elektronisk signatur.
  3. Betalningskontroll -- ger besked om banken godkänner transaktionen eller inte. Sker mha eletronisk signatur på transaktionsdatat.
Bedragaren låter steg 1 och 3 gå till det stulna kortet men steg 2 till hans/hennes preparerade kort. Behörighetskontrollen (steg 2) inleds typiskt med att kortet anger vilka sätt personen som ska betala kan kontrolleras:
  1. Kontroll mha PIN-kod
  2. Kontroll med underskrift
  3. Ingen kontroll
Kortläsaren (eller butiksbiträdet) väljer ett av dessa. Alternativen är nödvändiga. Betalautomater kan exempelvis inte kontrollera underskrifter och vissa automater saknar knappsats att mata in sin PIN-kod på.

Om kortläsaren väljer PIN-kod så får personen mata in en kod som skickas till kortet för kontroll. Kortet svarar med Terminal Verification Results (TVR), 0x9000 om koden var rätt och 0x63Cn om den var fel, där n är antalet återstående försök. Notera att TVR vid godkänd PIN-kod varken anger vilket kontrollsätt som användes eller autentiserar svaret med en elektronisk signatur. Summa: Kortläsaren vet varken vad kortet svarar på eller att det är rätt kort som svarar!

Bankerna har ytterligare ett sätt att kommunicera betalningsinformation -- Issuer Application Data (IAD). Där kan man ange att PIN-kod användes men tyvärr är IAD-formatet olika för olika banker och inte del av specifikationen för kortbetalningar, EMV (Europay MasterCard Visa). Det är alltså inte en lösning på problemet.

Fungerar hacket i praktiken?
För att bedragarna ska lyckas handla i vanliga butiker behöver nån bygga ihop de tre enheterna till vänster i bilden ovan. En sån allt-i-ett-enhet kan säkerligen göras liten nog för innerfickan. Då är vi i situationen att folk kan stjäla våra bankkort och handla med dem direkt. Mycket allvarligt!

Kan bankerna fixa problemet snabbt?
Är det här något som bankerna kan fixa snabbt? Nej, antagligen inte. Det är specifikationen för kommunikationen mellan kundens kort, kortläsaren och banken som är felaktig. En ny specifikation måste tas fram och alla kortläsare måste justeras. Om kortläsarna tillåter att man uppdaterar hur kommunikationen med kort och bank ska ske så kan justeringen göras utan att byta ut dem. Annars står vi inför ett mycket dyrt och omständligt byte av alla läsare i våra butiker.

Hur kunde det gå så här?
Kanske den viktigaste frågan -- hur kunde bankerna och kortbolagen göra den här missen?

Fel nummer ett var den slutna processen. Tyvärr är det är samma historia som i fallet med det undermåliga dörrlåset Assa 2000 Evo. Man håller sin konstruktion hemlig för att man tror att det ska öka säkerheten. EMV-standarden togs fram i slutna rum utan extern granskning. Därför missade man chansen att låta världens säkerhetsforskare skärskåda lösningen innan den togs i drift.

Fel nummer två var komplexiteten. Den tekniska grundspecifikationen för EMV är på över 700 sidor, omkringliggande specifikationer på över 2000 sidor och sen tillkommer respektive banks dokumentation på styva 1000 sidor. Att ens tro att implementationen av något sådant ska bli säker motsäger en av grundprinciperna: Keep It Simple!

tisdag 9 februari 2010

Anmäl er till OWASP AppSec nu!

Registreringen för årets stora händelse -- OWASP AppSec i Stockholm -- har öppnat. Anmäl er nu och få 500 kr i rabatt.

Bli individuella OWASP-medlemmar och få ytterligare rabatt.

Program- och organisationskommittéerna sätter samtidigt igång arbetet med att granska de nästan 60 presentationsbidrag som skickats in. För att inte tala om de 25 förslag till tutorials och kurser som vi ska välja ur till de två utbildningsdagarna.

måndag 8 februari 2010

Inbjudna talare vid AppSec 2010

Vi kan stolt presentera våra första inbjudna talare till OWASP AppSec Research 2010 i Stockholm, 21-24 juni:

Chris Evans och Ian Fette, Google Inc
"Cross-Domain Theft and the Future of Browser Security"

The web browser, and associated machinery, is on the front line of attacks. We will first look at design-level problems with the traditional browser in terms of monolithic architecture and fundamental problems with the same-origin policy. We will then look at the types of solution that are starting to appear in browsers such as Google Chrome and Internet Explorer. We will look at other important browser-based defenses such as Safe Browsing. We will detail what a future browser might look like that has a much more secure design, but is still usable on the wide variety of web sites that people use daily.

Chris Evans kallar sig själv Googles "Trouble maker" och har en lång bakgrund inom webbsäkerhet. Ni kan läsa om sårbarheter som Chris har hittat och rapporterat här.

Ian Fette är produktchef för Chrome och har hand om Googles Anti-Malware Initiative. Här är en video där Ian presenterar Chrome V8 (slides nedanför):


söndag 7 februari 2010

Säkerheten på Internet Q3-Q4 2009

Websense Security Labs har precis släppt statistik över mängden skadlig kod och spam på Internet senaste halvåret. Dyster läsning.
  • Om du söker på trender och buzzwords så leder 14 % av träffarna till sidor med skadlig kod
  • 71 % av webbsidor med skadlig kod är legitima sajter som hackats
  • 86 % av all e-post är spam
... och kanske värst av allt:
  • 95 % av alla användarinlägg och postad data är spam eller skadlig kod. Gjort mha automatiserade verktyg får man förmoda.
Läs hela rapporten här.

lördag 6 februari 2010

Rugged Software Manifesto

Igår presenterades The Rugged Software Manifesto på SANS Application Security Summit 2010 i USA. En av de tre författarna är Jeff Williams, orförande i OWASP-stiftelsen. Det kan nog kortas ner lite men det är vettiga levnadsregler för utvecklare som vill att deras mjukvara ska klara sig på nätet.

Manifestet:
  • I am rugged... and more importantly, my code is rugged.
  • I recognize that software has become a foundation of our modern world.
  • I recognize the awesome responsibility that comes with this foundational role.
  • I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
  • I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic, and national security.
  • I recognize these things - and I choose to be rugged.
  • I am rugged because I refuse to be a source of vulnerability or weakness.
  • I am rugged because I assure my code will support its mission.
  • I am rugged because my code can face these challenges and persist in spite of them.
  • I am rugged, not because it is easy, but because it is necessary... and I am up for the challenge.

måndag 1 februari 2010

Kort guide till sslstrip

Jag har kört Moxie Marlinspikes sslstrip vid några demon och tänkte jag skulle dela med mig av hur man enkelt sätter upp det. Det är ett verktyg som bygger om en https-sida till http on the fly och tillåter en attackerare att läsa och manipulera trafik som egentligen skulle skickas krypterat.

Installera sslstrip på en virtuell Ubuntu
Installera en virtuell Ubuntu. På den hämtar du hem senaste sslstrip och packar upp på valfritt ställe. Ställ dig i den uppackade sslstrip-katalogen och prova att starta:
> sudo python sslstrip.py -h

Det kan hända att du behöver ta hem ytterligare Python-paket, t ex webbservern Twisted Web:
> sudo apt-get install python-twisted-web

Starta IP forwarding
I filen sysctl.conf finns konfiguration för kärna och nätverksstack. Säkerhetskopiera nuvarande konfiguration:
> sudo cp /etc/sysctl.conf /etc/sysctl.conf.bak

Öppna konfigurationen:
> sudo emacs /etc/sysctl.conf

Leta reda på raden som säger "#Uncomment the next line to enable packet forwarding for IPv4" och gör som den säger, dvs ta bort kommentarstecknet '#' på nästa rad. Spara och stäng.

Starta sslstrip
Starta sslstrip:
> sudo python sslstrip.py --listen=8080 --favicon

Kolla sslstrips logg (från sslstrip-katalogen):
> tail sslstrip.log

Den bör vara tom just nu men kommer att innehålla alla postade fomulär som borde gått över https. Gå tillbaka och kör tail igen när du har postat till någon https-sida enligt nedan.

Kolla den virtuella maskinens IP-nummer:
> ifconfig | grep 'inet addr'

Konfigurera proxy på värdmaskinen
På din värdmaskin, Firefox, gå till Inställningar -> Avancerat -> Nätverk -> Inställningar.
Välj Manuell proxykonfiguration och skriv in den virtuella maskinens IP-nummer samt port 8080. Klicka OK.

Sniffa trafiken till din bank
Nu kan du i Firefox surfa till exempelvis din bank, klicka på "logga in" och se hur sslstrip bygger om https-sidan till http! Logga in på banken och kolla sen sslstrips logg för att se hur den sniffar trafiken.

Det här är alltså exempel på en Man-In-the-Middle-attack. Det krävs att man hamnar mellan klient och server, t ex genom ARP spoofing. Men när jag demar så "fuskar" jag mha Firefox proxyinställningar.