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.