Jagten på OWASP sårbarheder

Sikkerhed fylder mere og mere i en applikationsudviklers hverdag fordi 1) der er blevet større fokus på Cybersikkerhed, 2) hackerne er blevet dygtigere og 3) applikationerne er mere komplekse end tidligere. Derudover er industrien rundt om cybersikkerhed blevet big-business, og som dygtig hacker kan man nok tjene en fornuftig skilling på at angribe og finde sårbarheder i applikationer.

Hos Schultz holdt vi derfor i december måned en capture-the-flag konkurrence i at finde flest mulige OWASP sårbarheder i en web-applikation. Det skaber en awareness om applikationssikkerhed hos udviklere og arkitekter, giver stor viden at bruge sin kreativitet til at angribe en allerede eksisterende web-applikation og så er det bare sjovt!

OWASP

Open Web Application Security Project (OWASP) er et online community, som udgiver gratis artikler, metoder og lignende indenfor web-applikationssikkerhed. Det har eksisteret siden 2001 og som en del af deres arbejde udgiver de regelmæssigt en top-10 liste over de mest kritiske sårbarheder i web-applikationer. Det er fx. sårbarheder som injection (fx SQL injection), Cross-site-scripting (XSS), manglende autentifikation og lignende.

Alle web-udviklere bør stifte bekendtskab med OWASP top-10 og ikke mindst, hvordan man mitigerer og sikrer sin applikation mod disse sårbarheder. Derfor er OWASP også en del af vores udviklerhåndbog hos Schultz og del af de penetrationstest, som vi afvikler.

Konkurrencen

Tanken bag konkurrencen var at udbrede kendskabet og ikke mindst at få kreativiteten i spil, når man angriber en web-applikation. Det kunne være rigtigt fedt, hvis udviklerne arbejdede sammen om angrebene og på den måde gjorde hinanden dygtigere. Derfor blev konkurrencen udformet som en capture-the-flag team-konkurrence, hvor det gjaldt om, at finde en sårbarhed som gav et vist antal point. Sårbarheden blev rapporteret ind på en central Capture-the-flag server, som holdt styr på pointene for hvert team.

I vores research fandt vi en web-applikation OWASP-Juice-shop, som indeholder mere end 90 udfordringer, der kan løses. Juice-shoppen kan også køre i en Capture-the-flag version, så den understøtter vores tanker om en team-baseret tilgang til hacking.

Opsætning

Vi satte et Kubernetes cluster op på DigitalOcean til at afvikle Juice-shop applikationen i en pod til hvert team. Hver gang en nyt team kom på banen, blev der oprettet en ny pod, så teams i deres kampiver ikke kunne forstyrre hinanden. Vi opsatte også en Capture-the-flag server (i docker), som skulle holde styr på points og sikre, at et erobret flag var validt (hvilket sker ved at flag krypteres med en nøgle af begge applikationer). Vi opsatte samtidigt nogle regler, så det ikke var helt fri leg:

Rules for the Schultz Christmas Capture-the-flag vulnerability event

• You are to participate in teams hacking the juice-shop together.
• You are not allowed to hack the Capture-the-flag server.
• You are not allowed to DDOS any of the servers - we do not want to pick a quarrel with DigitalOcean.
• You are not allowed to hack any of the other teams’ applications.
• You are not allowed to hack the underlying Kubernetes or DigitalOcean infrastructure - again no quarrels.
• You are not allowed to access the documentation, source code (except for the javascript in the client) or any other parts of the underlying web application.
• You are most certainly allowed to bribe the Arbiters (KBT and MMA)– but it’s not guaranteed to work.

Cheating will be punished - publicly!

Resultatet

Vi skød konkurrencen i gang en uge før første søndag i advent. Det gav os mulighed for at uddele 4 adventsgaver i løbet af december måned.

Ret hurtigt begyndte der at blive erobret point for de simpleste sårbarheder.

Efter de 4 uger havde det vindende team "Team currywurst" fået 21.625 point og løst 49 udfordringer.

Konkurrencen fik gode tilbagemeldinger og der var en god tilslutning til konkurrencen i en i forvejen travl måned. En anden gang vil vi nok lave konkurrencen mere intensiv - det var som om luften gik ud af ballonen efter de første to uger.

Jeg kan kun anbefale at lave et tilsvarende arrangement i din organisation. Det giver nogle gode frokostdiskussioner om web-applikationssikkerhed og åbner øjnene for mulige sårbarheder i egne applikationer.