Simovits

Min resa till OSWE certifieringen

I den här bloggen tänkte jag berätta lite informellt om min resa för att få certifieringen ”OffSec Web Expert (OSWE)” (https://www.offsec.com/courses/web-300/). Utöver att berätta om min väg till certifieringen så kommer jag berätta en del om mina erfarenheter av kursen som är kopplad till certifieringen, och ge några tips för den som skulle vara intresserad av att påbörja samma resa.

Organisationen OffSec (https://www.offsec.com/) är kända för flera av deras olika certifieringar, där den mest välkända är ”OffSec Certified Professional (OSCP)”. I regel betraktas certifieringar från OffSec som de mest prestigefyllda inom IT-säkerhet, mest på grund av deras praktiska prov som krävs. Kursen och certifieringen som avhandlas i den här bloggen (OSWE) är en specialiserad historia inriktad helt på webbapplikationer. Framförallt är fokuset på så kallad ”whitebox” testning, där en stor del källkodsanalys utförs. Kursen är därför helt inriktad på de som redan innan har erfarenhet av webbapplikations-sårbarheter, och som vill fördjupa dessa. Eftersom både kodanalys och egen programmering är centrala delar så krävs också programmeringsvana.


Bakgrund

Ända sedan jag började med penetrationstestning så har alltid webbapplikations varianten varit den som har tilltalat mig mest. Det finns många anledningar till det, men det som är väldigt speciell för alla typer av applikationstestning är att sårbarheter som upptäckts i exempelvis en egengjord webbapplikation är en form av ”zero-day”, det vill säga en helt ny sårbarhet. Detta är i kontrast med nätverkspenetrationstestning, där i regel kända sårbarheter och tillhörande verktyg nästan enbart förekommer.

En återkommande aspekt som många som utför penetrationstestning av webbapplikationer säkerligen reflekterat över är att det många gånger inte går att uttala sig om att en sårbarhet definitivt inte finns. Om en funktion ger ett generiskt felmeddelande, eller inget alls, kan det i tidsbegränsade blackbox/greybox tester i princip vara omöjligt att helt utesluta somliga kategorier av sårbarheter. I kontrast, när tillgång till källkoden också förmedlas, går det att analysera koden för att ihop med praktiska tester kunna bekräfta eller dementera hela kategorier av sårbarheter på ett beslutsamt och effektivt sätt. Det är min åsikt att whitebox tester borde utföras mycket oftare, eftersom det är enbart denna form av testning som bestämt kan bedöma säkerhetsnivån för en webbapplikation.

Givet ovan så har jag länge varit nyfiken på OSWE certifieringen och den tillhörande kursen. Just fokuset på whitebox principer särskiljer denna från många andra kurser som erbjuds av andra aktörer.


Påbörjandet

I slutet av november 2023 påbörjande jag min långa resa. Strukturen av kursen är att det finns flera olika moduler (ca 13) som fokuserar på olika sårbarheter. Dessa är historiska sårbarheter som har detekteras i olika open-source eller kommersiella webbapplikationer. I både text och video (ej för de absolut senaste modulerna) beskrivs metodik för att hitta och utnyttja dessa sårbarheter. Varje modul innehåller ett antal övningar (exercises) och ”extra miles”. De sista är övningar som går bortom kursmaterialet, vilket kan vara alltifrån ganska enkla till väldigt svåra (kräva en dag av egen fördjupning). Alla övningarna utförs mot separata virtuella maskiner som tillhandahålls.

När jag startade hade jag nog ingen aning om vad jag gav mig in på. Har tidigare programmeringserfarenhet via olika egna små projekt och lite små strökurser, men har aldrig pysslat med utveckling på riktigt. Trots det höll jag humöret uppe när jag började.

Den första modulen går igenom grunderna, såsom dekompilering och skriptande. Här skapade mina egenheter det första hindret. Till skillnad från alla andra och deras hund, har jag en viss aversion mot Python (kanske ämnet för en framtida blogg). Föga överraskande är det de språket som alla exempel i kursen använder för programmering av utnyttjandet av sårbarheter. Min första utmaning var därför att översätta de initiala exemplen till JavaScript och Node (vilket till skillnad från Python bland annat erbjuder ett stabilt API, ordentlig dokumentation och en vettig pakethanterare i NPM). Efter att dessa exempel återskapandes så upprättade jag även en generell struktur ovanpå ”fetch” för att kunna göra vanliga saker såsom att manipulera HTTP anrop. I slutändan visade det sig att denna initiala tidskostnad lönade sig, eftersom det gav mig både bättre förståelse och bättre flexibilitet samt effektivitet än om jag hade förlitat mig på deras Python exempel.

Under den veckan av dedikerad pluggtid som jag hade till mitt förfogande lyckades jag avverka totalt fyra moduler. Med det återstod en stor del av kursen (ca nio moduler). Här kommer således en första iakttagelse: räkna minst med att det tar en dags heltidsstudie för en modul. Dock är även detta optimistiskt, exempelvis så struntar man helt då i extra miles övningarna som ibland kan ta flera timmar var för sig. Även för personer som har tidigare erfarenhet av webbapplikationssårbarheter tar det tid att gå igenom materialet.

Under december 2023 lyckades jag på min egna tid avverka ytterligare en modul. Jag var då uppe vid fem moduler klara, med asterisken att jag helt hade struntat i extra miles. Vid den här tidpunkten började jag förstå hur mycket tid som krävs för att kunna gå igenom allt material ordentligt i kursen. Min ambition kvarstod dock, att kunna gå igenom allt och försöka mig på provet under våren 2024. Att den tidsuppskattningen sprack är ingen underdrift…


Avbrottet

Från januari 2024 till december 2024 blev det inget pluggade för mig. Som man brukar säga, livet kommer emellan med både roliga och sorgesamma åtaganden.

Jag sneglade på materialet för första gången på över sex månader under hösten 2024, och kunde se hur två av de modulerna som jag tidigare hade utfört hade ”arkiverats”. Offsec uppdaterar sina kurser löpande (utan förvarning), och kan då ersätta moduler med nya. Istället för att helt ta bort dessa så markeras de istället som arkiverade. Betydelsen är att modulerna inte längre har samma betydelse för examinationen, men att de fortfarande finns för de som är nyfikna och vill öva lite extra. Utöver att två moduler som jag hade utförts försvann så tillkom två nya. Med det så reducerades jag till tre av tretton moduler klara. Med tidigare tidsåtgång färskt i minnen var detta nedslående. Såhär i efterhand tror jag att det var ytterligare en anledning varför jag hade svårt att återuppta mitt pluggande. Samtidigt så fanns viljan och drivet kvar någonstans.


Pluggandet

I slutet av december 2024 återupptog jag mitt pluggande. Jag var fast beslutsam att inte låta kursen vinna över mig. Sakta formulerade jag en plan för mig själv om hur jag skulle gå igenom allt material och ungefär när mitt provtillfälle skulle bli. Min tanke var att inte lämna något åt slumpen vid provet, det vill säga jag skulle vara så förbered som jag överhuvudtaget kunde bli. Framförallt, det ska inte finnas något material kvar i kursen som jag inte har gått igenom/löst. Samtidigt stålsatte jag mig för de uppoffringar som krävs. Framöver kommer varje helg att domineras av pluggande.

Med högsta växeln i lagd så lyckades jag avverka alla moduler, inklusive alla extra miles, på ca en månad. Sista dagarna av januari 2025 var jag klar med kursmaterialet. En naturlig tanke är att det därför skulle vara dags för provet straxt därefter. Dock kvarstår ytterligare en del av kursen, ”challenge labs”. Dessa är ett antal olika separata virtuella maskiner som kör sårbara webbapplikationer. För varje finns det två flaggor, den första kräver att man kommer över ett admin konto, och den andra att man åstadkommer godtycklig kodexekvering. Genom att utföra praktiska tester, men framförallt utföra kodanalys, så ska man kunna hitta sårbarheterna för att kunna erhålla flaggorna. När jag började med dessa maskiner fanns det fem stycken. Veckan innan mitt prov la de till ytterligare en, för sex totalt. Att arbeta med challenge labsen är viktigt för att kunna förbereda sig för provet. Den största lärdomen från dessa är att sårbarheter kan vara relevanta som strikt inte har behandlats i kursmaterialet. Därför måste man öva upp sin förmåga att hitta tillsynes avvikande beteende och sedan utföra efterforskningar om sårbarheterna på egen hand för att kunna utnyttja dem.

I slutet av februari hade jag gjort alla challenge labs, men samtidigt hade jag inte skriptat dem fullständigt. En avgörande punkt under provet kommer vara att man sammanställer alla sårbarheter och deras utnyttjande i ett och samma skript. Tanken är att det enbart ska räcka att köra skriptet för att få alla flaggor och kodexekvering på målet. Alla stegen måste därför automatiseras. Därför gick jag tillbaka och skriptade alla till den nivån, vilket var lärorikt. Första veckan i mars hade jag således avverkat exakt allt kursmaterial. Samtidigt ville jag ägna lite tid till att göra mina sista efterforskningar om några sårbarheter och praktiskt förbereda mig inför provet. Det sista inkluderade att förbereda skript inför provet (så man enbart kunde bygga vidare på dem istället för att börja på nytt) men också att undersöka exakt hur provet går till. Just provtillfället är väldigt speciellt för Offsec, och den här kursen är ett av de mer omfattande exemplen från dem.

Veckan innan jag skulle utföra mitt prov lades dessutom en ny challenge lab till. I ren affekt avverkade jag den på en förmiddag och märkte att jag ändå var ganska förbered inför det riktiga provet.


Provet

Jag bokade mitt prov för 21 mars 2025. Tills dess hade jag förberett alla mina grundskript, anteckningar om sårbarheter och dedikerad testdator. Låt mig nu berätta lite om provet, och varför det för mig innebar en hel del vånda.

Provet är strukturerat som följer: Man får två maskiner (liknade challenge labs), där varje maskin har två flaggor. Den första flaggan (åtkomst till admin konto) ger 35 poäng, den andra (kodexekvering) 15 poäng. För att få godkänt måste man få 85 poäng av 100 möjliga. Man har därför råd att misslyckas med en kodexekvering. Än så länge inga direkta konstigheter. Det är istället de praktiska aspekterna som är speciella. Tidsgränsen för provet är 47 timmar och 45 minuter. Provet är dock övervakat (”proctor”). Under hela tiden är det därför någon som övervakar en via webkameran, och man måste hela tiden berätta om man reser sig och försvinner ur synvyn. Inga andra enheter får användas under provtillfället. Vilka verktyg som får användas är också kraftigt begränsat. Det här är bara några av reglerna. Att hela tiden känna sig övervakad och ha alla dessa regler i åtanke innebär ett extra stressmoment. När tidsgränsen för provet är klar så ska en rapport sammanställs som beskriver hur man hittade sårbarheterna, hur man utnyttjande dem, ens skript, bilder och vad flaggorna var. För att göra det får man ytterligare 24 timmar, och nu utan övervakning. Sammantaget kan alltså provet ta som mest 72 timmar, tre dygn.

Jag påbörjade mitt prov fredagen den 21 mars, med starttiden klockan 5 på morgonen (alla provtider brukar vara tidigt på dagen för oss i Sverige). Innan dess måste man ansluta och gå igenom massor av praktiska moment för övervakningsdelen. Ungefär kvart över 5 kunde jag starta. Efter mindre än en timme hade jag lyckats få min första flagga. Att få kodexekvering på den maskinen visade sig vara knepigt, vilket var lite nedslående. Istället så gick jag över till den andra maskinen. Ungefär vid lunch lyckades jag nå den första flagan på den andra maskinen. Jag var nu en flaga ifrån minimum nivå för att klara sig. Ungefär vid 17 tiden så lyckades jag få kodexevering på den andra maskinen. Nu hade jag uppnått minimikravet för godkänt, givet att allt annat (skript och rapport) inte innehöll något tillkortakommande. När man läser andras provupplevelser så nöjer sig många här och struntar helt i att försöka på den sista flaggan. För mig var det inget alternativ, i mina tankar gav det ingen buffert/marginal om något skulle brista i rapporteringen. Jag skulle känna mig utlämnad till nyckfullheten hos den som rättar min rapport sen. Istället så fixade jag med mitt skript för den andra maskinen som jag nu var helt klar med. När jag var klar med det så var klockan ca 20 på kvällen och jag bestämde mig för att gå och lägga mig. Jag hade mer än en hel dag på mig att hitta den sista kodexeveringen i den första maskinen. Föga överraskade så sov jag inte så bra och vaknade där runt kl 2 på lördagen. Istället för att försöka somna om så gick jag upp och satt igång. Efter att ha undersökt och uteslutit massor av andra sårbarheter och möjligheter så började det sannolika alternativet uppenbara sig för mig där runt 12 tiden. Jag var nu tvungen att läsa in mig på hur den sårbarheten fungerade för det specifika programmeringsspråket och hitta sätt med vilket det går att utnyttja. Ca klockan 14 hade jag lyckas bekräfta sårbarheten och behövde nu bara designa ett sätt att använda den för att få godtycklig kodexekvering. Vid 16 tiden hade jag lyckas få min kodexekvering och kunde hämta flaggan. Nu hade jag alltså lyckats få fyra av fyra flaggor. En utmaning som kvarstod var att skripta flödet för att kunna utnyttja kodexekveringssårbarheten, vilket var lite knepigare än vad man kunde tro på grund av alla olika stegen som krävdes. Vid ca 18 tiden var jag dock klar med mitt skript även för den första maskinen. Jag spenderade en timme att starta om prov maskinerna flera gånger och köra om mina skript för att försäkra mig att de alltid fungerade som tänkt. En egenhet upptäckte jag under denna process som jag kunde fixa. När klockan var 19 var jag minst sagt trött och bedömde att det var bäst att försöka sova lite innan jag gjorde min sista kontroll så att jag hade allt underlag för rapporten (anteckningar och viktigast bilder). Ungefär klockan 2 vaknade jag på söndagen och spenderade en sista timme på att gå igenom allt underlag för rapporten och testköra mina skript ytterligare gånger. Allt verkade vara i sin ordning så kunde avsluta övervakningsssessionen. Efter en liten paus så påbörjade jag min rapport. Offsec tillhandahåller en mall som de gärna vill att man följer för sin rapport. Med detta format så kunde jag få klar den första versionen av min rapport till ca kl 12. Efter ytterligare en paus så korrekturläste jag min rapport och skickade in den ca kl 15. Äntligen var det klart.

Redan klockan 2 på måndagsnatten fick jag ett meddelande om att jag hade klarat provet och därför hade fått OSWE certifieringen.


Sista tankar och tips

Efter den här långa svamlande texten är det nog på sin plats att sammanfatta lite sista tankar och tips för den som är sugen på att också ta OSWE.

Mina generella tanker om kursen och certifieringen är positiva. Kursmaterialet är i regel bra. Några extra mile övningar är lite märkligt formulerade (extra miles saknar alltid facit). Challenge labs maskinerna är jättebra för att lära sig praktiskt hur man utför grundläggande kodanalyser och hittar sårbarheter. Dessutom så tvingar de en att lära sig att efterforska sårbarheter på egenhand, eftersom de ibland kan innehålla varianter på sårbarheter som man inte har sett i kursmaterialet tidigare. Den största behållningen med kursen är att den tvingar en att lära sig saker på riktigt. Till skillnad från många andra organisationer och deras kurser samt prov så är detta enbart praktiska moment. Det går inte enbart att memorera saker för att sedan klara ett banalt flervalsprov. Det är till sådant grad att många andra prov från andra aktörer nästan framstår som lite löjeväckande i jämförelse. Den största negativa aspekter är för mig övervakningsdelen vid provtillfället. Att behöva isolera sig i två dygn och vara övervakad är jobbigt både mentalt men också ur ett livspusselperspektiv. En sista sak som skulle kunna förbättras är att det fortfarande finns ett antal moduler som har ”blackbox” perspektiv. Att dessa finns är i sig inte dåligt, men samtidigt märks det att det inte är ett prioriterat perspektiv längre. Intrycket blir därför att kursen ibland är något spretig, och att det tar värdefullt fokus ifrån whitebox principerna.

När det gäller provet så tyckte jag att det var svårt, men ändå rättvist. En person som enbart har tagit del av kursmaterialet kan få det svårt att klara provet, men samtidigt så är en av de större lärdomarna förmågan att själv kunna göra efterforskningar av sårbarheter. Ytterligare studier och tidigare erfarenheter hjälper en också här. Min erfarenhet var att skillnaden mellan godkänt gränsen (3 av 4 flagor) och fullpott (4 av 4 flagor) var betydande, och att det därför borde gå för de flesta att få godkänt givet att man bara pluggar tillräckligt.

Några tips för kursen och certifieringen är att:

Trots mina överlag positiva erfarenheter så kommer jag nog inte ge mig i kast med något liknande. Åldern och de uppoffringar som krävs är nog för påtagliga. Samtidigt har jag hört talas om ”HTB Certified Web Exploitation Expert (HTB CWEE)” (https://academy.hackthebox.com/preview/certifications/htb-certified-web-exploitation-expert) som tydligen innefattar en 10 dagars lång examination (dock utan övervakning). Men så galen är jag inte….eller…nä….kanske….NEJ…men om…sluta…så förmodligen inte….fast samtidigt…