Digitale fotspor – hvordan finne veien hjem til deg

Digitale fotspor er ledetråder vi etterlater oss på nettet, så små at vi ikke tenker over hva de kan brukes til. Det kan fort straffe seg.

Jeg skal i denne bloggposten forsøke å ta tankegangen om ledetråder over i webservernes verden og vise hvordan et ondsinnet angrep kan foregå. Vi starter i det små med en helt normal nettleser forespørsel.

fotspor 600x300 Digitale fotspor – hvordan finne veien hjem til deg

Hva røper løsningen?

Kommunikasjonen mellom bruker og webserver foregår via utveksling av HTTP beskjeder. En forespørsel (request) sendes fra nettleser, webserveren svarer med en respons (response). Disse beskjedene inneholder ulike felter som tolkes av hver sin part (headerfelt). Jeg vil her fokusere på to spesifikke felter i responsen fra webserveren – «Server» og «X-Powered-By». I Chrome nettleseren har jeg mulighet til å holde øye med HTTP beskjedene som blir sendt mellom meg og webserveren. Jeg åpner en «vilkårlig» nettside og kikker på beskjeden som blir sendt og mottatt. Responsen jeg får inneholder de tidligere nevnte feltene. «Server» forteller meg hvilket operativsystem og webserver den bruker, mens «X-Powered-By» forteller meg hvilket CMS som håndterer innholdet I dette tilfellet sier webserveren at den bruker Debian Linux, at CMS-et heter ABC og at Apache er i versjon XYZ. Den sier riktignok ikke hvilken versjon av Debian – men etter å snoket litt rundt på Debian.org etter utgivelsesnotater, så finner jeg ut revisjonsnavnet på grunnlag av hvilken Apache versjon som kjøres. I noen tilfeller oppgir også headerfeltene hvilken PHP-versjon som kjøres, men ikke i dette tilfellet. Jeg ser at programvaren her er en «tanke» utdatert – mon tro om serveren fremdeles er satt opp likt som fra dag èn?

Kjente svakheter

På nett finnes det mange registre man kan slå opp i for å finne ut om programvare har kjente hull. Disse kalles for CVE databaser – Common Vulnerabilities and Exposures. Jeg noterer meg at det finnes mange hull for både denne Debian og Apache versjonen – mange høyst kritiske. På noen sårbarheter finner jeg også en bruksanvisning på hvordan man utnytter hullene. Hadde jeg visst PHP versjonen så kunne jeg mest sannsynligvis funnet sårbarheter der også (på samme måten som jeg fant ut revisjonsnavnet til Debian). Mitt fokus er CMS-et i seg selv, så jeg lar det ligge. Jeg finner mange sårbarheter rundt Debian og Apache. Det finnes ingen oppføringer av nyere dato for CMS-et. Hva gjør jeg nå? Det blir enten å Google eller å gå rett til kilden ved å lese dokumentasjon. Jeg velger det sistnevnte i første omgang. Bortgjemt i den tekniske dokumentasjonen finnes det et avsnitt som forteller at CMS-et har en «om meg» side. Jeg besøker denne og finner at den gir ifra seg verdifull informasjon.  Her finnes bl.a. versjonsnummeret og hvilke tillegg som er installert. Hva kan Google gi meg nå? En uavhengig sikkerhetskonsulent har blogget om et tillegg som lekker informasjon om brukerkontoene. Bloggposten inneholder også en utførlig bruksanvisning. Jeg velger å replisere dette miljøet på en virtuell maskin. Oppskriften fungerer – jeg får tilgang til langt mer enn jeg burde, konkluderer mitt arbeid med at jeg har funnet veien hjem til «deg» og at nøkkelen lå under matta.

Hvorfor velger vi å fokusere på dette temaet?

Fordi informasjon vi legger ut eller gjør tilgjengelig lett kan misbrukes. Rekognosering er et grunnleggende steg i de fleste angrep. Dette vil si at man går et system nærmere i sømmene på jakt etter sårbarheter. Den lille ansamlingen av informasjon jeg fikk ut av webserveren var nok til at jeg fikk hentet ut samtlige brukerkonti med tilhørende passord. For en (semi)profesjonell angriper så bringer denne beskrivelsen intet nytt. Men  forhåpentlig bidrar det til at du gjør en rekognosering på egen løsning.

Publisert