GDPR.EU skulle give råd om virtuelt privatliv, men det udsatte i stedet adgangskoder

Mandag skrev Vangelis Stykas og Joe Durbin fra Pen Test Partners om 'ironien' ved at finde en datalækage i GDPR.EU. Som du kan se, blev lækagen (som siden er sikret) udført af et websted dedikeret til Den Europæiske Unions almindelige databeskyttelsesforordning, der blev vedtaget for et par år siden. Websiden blev delvis finansieret af EU selv, og den formodes at give organisationer information om, hvad de skal gøre for at overholde GDPR.

Du kan se, hvorfor nogen muligvis klassificerer lækagen som "ironisk", men hvis du ser historien fra en anden vinkel, kan du argumentere for, at der absolut ikke er nogen ironi i et GDPR-relateret websted, der lækker data. Ethvert websted, uanset dets formål, kan teoretisk blive sårbart over for cyberangreb. Hvad der imidlertid er ironisk i dette særlige tilfælde, er, hvordan GDPR.EU lækkede dataene, og hvem der var ansvarlig for dets sikkerhed.

En eksponeret .git-mappe sætter GDPR.EU i fare

GDPR.EUs udviklere brugte et udviklings Git-værktøj til at spore versionerne af deres kode og de ændringer, de foretager den. Når disse værktøjer bruges til at oprette websteder, lægger de en masse følsomme oplysninger (inklusive hele kildekoden) i en .git-mappe, som som standard er placeret i rodmappen. Ofte kopierer / indsætter rodkataloget til produktionsserveren, og .git-mapper ender også online. Allerede har du følsomme oplysninger tilgængelige på serveren, og hvis katalogfortegnelse er aktiveret (en konfigurationsfejl, der ikke er så usædvanlig, som den burde være), er det trivielt at surfe gennem dem overalt i verden.

Når det gælder GDPR.EU, da Pen Test Partners 'eksperter kiggede ind i .git-mappen, fandt de en hel del filer oprettet af WordPress, det indholdsstyringssystem, som webstedet er bygget på. En af dem, wp-config.php, indeholdt adgangskoden til GDPR.EUs MySQL-database. Som forskerne påpegede, er dette et internt system, så det ville ikke være let at bruge denne adgangskode til at ødelægge eller stjæle databasen. Ikke desto mindre er genbrug af adgangskode så almindeligt i dag, at vi ikke bør udelukke chancerne for, at de samme legitimationsoplysninger låser op for andre GDPR.EU-relaterede ressourcer. Hvad mere er, indeholdt .git-mappen også Autentificering unikke nøgler og salte, som ifølge Pen Test Partners kunne give angribere mulighed for at forhaster eller kompromittere webstedet.

Offentlige .git-mapper har været et problem i et stykke tid nu

.git-mapper er ikke noget nyt, og heller ikke de konfigurationsfejl, der fører til deres eksponering. I årevis har sikkerhedsforskere talet om vigtigheden af at sikre dataene i .git-mapper, og der er foretaget en hel del undersøgelser, som viser, at udviklere og systemadministratorer ikke følger de råd. I 2018 scannede for eksempel den tjekkiske sikkerhedsekspert Vladimir Smitka omkring 230 millioner domæner og fandt, at 390 tusind af dem havde deres .git-mapper udsat. Scanningen kostede ham $ 250, hvilket i betragtning af hvor dyrt et enkelt brud kunne være, ikke er noget. I modsætning hertil brugte Pen Test Partners ikke engang en krone på at finde ud af, at GDPR.EU havde udsat sine data.

Der er en browserudvidelse, der kan identificere websteder, der lækker data på grund af en offentlig .git-mappe. Det kaldes DotGit, og det er tilgængeligt helt gratis. Et medlem af Pen Test Partners 'team havde det installeret og ledte simpelthen efter mere information om GDPR. Dette er hvor let det var at finde datalækage. Heldigvis viste det sig heller ikke at være svært at løse problemet.

ProtonMails udviklere gjorde fejlen

Inden for fire dage efter den indledende afsløring var .git-mappen sikret, og informationerne var ikke længere offentligt tilgængelige. Det, der er interessant (og lidt ironisk) er, at det firma, der driver og er ansvarlig for sikkerheden ved GDPR.EU, kaldes Proton Technologies AG, udvikleren af ProtomMail. Med andre ord, de mennesker, der lover brugere en helt sikker ende-til-ende krypteret e-mail-tjeneste, lavede en temmelig grundlæggende konfigurationsfejl, der kunne have bragt et helt projekt i fare. Lad os håbe, at vi ser færre sådanne hændelser i fremtiden.