Lexbase undgick ingen. Enligt domstolsverket lade de totalt nästan en miljon kronor på att köpa ut domar. Inte jättemycket till startkapital och det räckte tydligen inte hela vägen heller. Tingsrätten i Halmstad berättade att de slutade lämna ut domar till dem för att de inte betalade för sig.

Efter lanseringen på måndagen den 27 januari gick det dock fort. På torsdagen lade Lexbase hostingleverantör Bahnhof ut ett pressmeddelande:

På onsdagkvällen drog Bahnhofs teknikavdelning och Lexbase oberoende av varandra slutsatsen att sajten skulle stängas på grund av upptäckta säkerhetsbrister. Vid hackerattacker förbehåller sig Bahnhof rätten att stänga av kunder för att inte äventyra säkerheten för själva sajten, för dess besökare samt för Bahnhofs övriga system.

Det kryllade av sårbarheter i Lexbase. De resulterade åtminstone i att en lista på 100 000 personnummer dumpades och började cirkulera samt att godtyckliga domar kunde laddas ner utan att passera betalningssteget.

I veckan gick DN ut med att tjänsten drog in en miljon kronor om dagen under de tre dagar den var uppe. Uppgifterna ska tydligen komma från flera oberoende källor. De har dock inte bekräftats. Det betyder i så fall att det gjordes omkring 15–20 000 köp varje dygn och det låter ju åtminstone inte omöjligt.

Vi hade kunnat rädda Lexbase AB på en vecka.

Även om det inte fanns obegränsat med pengar till att börja med så fanns det alltså en del. Ovanpå detta måste det ha funnits en ganska tillförlitlig prognos om att de skulle komma att dra in en hel del.

Springflod, Omegapoint, Bitsec, High Performance Systems, Truesec, Sentor, Europoint, Safeside, Knowit Secure, 2Secure; det finns en rad firmor i Sverige som har skickliga säkerhetskonsulter. Vi hade kunnat rädda Lexbase AB på en vecka. 40 timmar konsulttid. De hade haft råd. Om inte hade åtminstone jag förmodligen kunnat övertygas om att dela risken.

Parentes: det finns mycket att säga om syftet med offentlighetsprincipen och hur Lexbase påverkar människor och samhället. Jag tror inte att en tjänst som Lexbase behövs, därmed innebär den tydligt mer skada än nytta. I det här sammanhanget är Lexbase dock bara ett exempel. Så ursäkta min neutralitet.

Oavsett, det må vara oansvarigt av Lexbase att låta människor enkelt söka fram och köpa valfria domar. Men, att göra ett så taffligt jobb att alla domar kan laddas ner obegränsat är vårdslöst. De borde ha lagt mer pengar på att minska risken.

Missförstå mig inte, jag är definitivt för ett större risktagande när det kommer till it-säkerhet. Vår bransch fegar ofta i onödan; vi kan vidta de mest rigorösa åtgärdsplanerna även fast tydliga hotbilder saknas. Risktagandet måste dock vara intelligent. Lexbase var vårdslöst.

Det kan inte ha rått några tvivel om att deras tjänst skulle (1) dra uppmärksamhet till sig, (2) att det skulle väcka avsky hos vissa, kanske många, och (3) att det självklart finns många som skulle vilja ha domar utan att betala.

Lexbase hade till och med en ganska ovanlig fördel, de behövde definitivt skydda sig, men inte mot särskilt kvalificerade angrepp. Om de kan stå emot tillräckligt länge för att fritidshackers från 4chan och Flashback ska tappa intresset så är de i good shape. Relativt enkelt.

…jag är definitivt för ett större risktagande när det kommer till it-säkerhet. Vår bransch fegar ofta i onödan.

Kort sagt, det var självklart att de hade en reell hotbild. Dåligt utgångsläge för att ta stora risker. Exempelvis att bygga tjänsten utan att ha säkerhetskompetens och sen hålla tummarna.

Dessutom, om man ska ta risker, då ska man åtminstone se till att ha klart för sig vem som får ta smällen.

Situationer där en person uppmuntras att ta större risker eftersom någon annan får ta konsekvenserna av personens handlande kallas moral hazard. Det var ett begrepp som användes rätt frekvent under och efter finanskrisen. Det är ett fenomen som gäller i princip alla sociala tjänster på nätet där ”innehållet” är dess användare. Lexbase är på något perverst sätt analogt.

En annan kontroversiell tjänst var i en liknande situation för några år sen. Den så kallade ”otrohetssajten” Victoria Milan läckte profilbilder på precis samma sätt som Lexbase läckte domar. I den väl, men kanske inte tillräckligt väl, kända sårbarhetslistan OWASP Top Ten benämns sårbarheten insecure direct object reference. Det är grundskolenivå. Vem riskerar ta den största smällen av den läckan, Victoria Milan eller deras medlemmar? Moral hazard.

…att göra ett så taffligt jobb att alla domar kan laddas ner obegränsat är vårdslöst.

Nog så. Tillbaka till konsulterna som hade kunnat rädda Lexbase på 40 timmar. Givetvis är det inte tal om någon projektplan, styrgrupp, formell testning, utbildning eller särskilt strukturerat arbete med god dokumentation när man har 40 timmar på sig att snygga till en, förmodligen halvfärdig, högrisktjänst. I synnerhet när den är relativt komplicerad och har kopplingar till externa betal- och karttjänster. Förmodligen är det dessutom bråttom så det behöver göras på några veckor. Det är gerillarådgivning.


Retorisk offert till Lexbase AB

Tack för möjligheten att ge anbud om säkerhetsrådgivning till Lexbase AB. […] Springflod AB föreslår att 40 timmar disponeras som följer:

Möte med den huvudsakliga utvecklaren, chefen för Lexbase AB och gärna bolagsjuristen. Flera frågor att diskutera: Vad är affärsmodellen? Hur är det tänkt att ni ska tjäna pengar? Vad kommer att hända när tjänsten lanseras? Hur fungerar tjänsten i stort? Vilka plattformar bygger den på? Hur kommer den att driftsättas? Vi kommer också att gå in på hur intrång kan gå till och vad de har haft för konsekvenser för andra. (2 timmar) Utvecklaren får i uppgift att studera OWASP Top Ten till nästa gång. Springflod sammanställer relevant best practice rörande plattformarna. (4 timmar)

Nytt möte med utvecklare och andra relevanta tekniker om det finns. Helst snart efter föregående möte. Gå igenom Top Ten tillsammans igen, fokusera på exempel från verkligheten, ge analogier. Målet är att utvecklaren själv ska se var sårbarheterna kan finnas. Ny, mer detaljerad beskrivning av hur tjänsten är uppbyggd. Ren whiteboardövning. Tillsammans kartlägga systemets gränsytor för att få in ett tänk kring attackytor. Gå igenom best practice från förra gången. (4 timmar)

Nytt möte med utvecklare och tekniker, ett par dagar senare. Vissa lättare tester mot den halvfärdiga plattformen. Här upptäcks förmodligen lite SQL injection, XSS, lösenord i klartext och insecure direct object reference om de finns. Vissa av dessa kommer att vara enkla att åtgärda på plats, andra svårare. Framför allt: teach a man to fish. (8 timmar)

Repetera föregående möte ytterligare en gång efter lämpligt tidsintervall. Beroende på utfall här kan resterande timmar att behöva anpassas. Helst ska de kunna användas när applikationen är i princip klar och då utgöra en genomgång av resultat från t ex Skipfish (som kör över natten) och fler manuella tester. Som teknisk avslutning sker kontroll av plattformens konfiguration som har härdats enligt tidigare best practice-dokument. (8+4 timmar)

Avslutningsvis vill jag uppmuntra till en diskussion kring omfall med de som var med på det inledande mötet. Vad gör vi om…? Syftet är att förbereda bolaget inför lansering och minimera överraskningar. (2 timmar)


Lexbase hade tjänat in kostnaden för rådgivningen på mindre än två timmar under första dagen. Dessutom hade aldrig Bahnhof stängt av dem efter tre miljoner kronor. Jag borde höja timarvodet…