Slik håndterte de PHP-krisen: Sendte passord til 10.000 journalister
Mens Ramsalt nok ned sine tjenester, la Labrador CMS på et midlertidig sikkerhetslag for 471 publikasjoner i 20 land. – Det var en ganske hektisk dag på jobben, ja.
Publisert
– Dette kunne blitt katastrofalt. Et sikkerhetshull som gjør det mulig å kjøre kode i editoren vår, vil vi gjøre alt for å stoppe, sier Jan Thoresen, CEO i Labrador CMS, til kode24.
Da PHP-sårbarhetene ble kjent onsdag, anbefalte Nasjonal sikkerhetsmyndighet å ta ned nettsider og plattformer i påvente av oppdateringen klokka 16. Det gjorde Digitaliseringsdirektoratet, OsloMet og Feide.
Også Ramsalt valgte den løsningen, noe som gikk utover nettsider som sykepleien.no, magasinetsko.no, tidsskriftet.no og juristen.no, skriver Fagpressen.
– For oss trumfet garantert sikkerhet kravet om oppetid, sier Yngve W. Bergheim, partner i Ramsalt, til kode24.
Labrador CMS tok et helt annet grep, og skrudde i stedet på et ekstra sikkerhetslag på CMS-et like før oppdateringen kom.
Det betød at 10.000 journalister i 471 publikasjoner i 20 land fikk tilsendt et ekstra brukernavn og passord som måtte brukes for å komme inn på plattformen.
– Det var en ganske hektisk dag på jobben, ja. Dette var det mest alvorlige sikkerhetshullet som har vært ekspoert på en stund, sier Thoresen til kode24.
– Tenkte at det var smartere
Labrador også vurderte å ta ned plattformen helt, slik andre gjorde.
– PHP er en av mange komponenter vi bruker i vår infrastruktur som håndterer over 10.000 journalister hver uke og flere tusen http-requests på fronten hvert sekund, forklarer CTO Ole Andreas Flaaten Jonsgård til kode24.
Thoresen utdyper:
– Siden vi er i mediebransjen og det sitter langt inne å stenge, tenkte vi at det var smartere å legge på ekstra sikkerhet i timene det gjaldt. Vi klarte å holde sidene oppe, og publisering var fullt mulig for journalistene som hadde passord, sier CEO-en i Labrador.
De la ikke på sikkerhetslaget før PHP-oppdateringen, og med den mer informasjon om hvordan hullet kunne utnyttes, kom klokka 16, selv om problemet var kjent tidligere på dagen.
– Vi var mest sårbare fra fiksen kom og fram til vi fikk patcha, sier Thoresen.
De gjorde flere ting i tillegg til sikkerhetslaget for å sikre alle flater som kunne være berørt av feilen, men Jonsgård ønsker ikke å gå inn på det.
– Massiv operasjon
Rundt 300 av Labradors 471 publikasjoner er i Norge. Alt går på norsk teknologi. Den doble innloggingen varte til rundt klokka 22 onsdag kveld, men enkelte måtte logge på fram til torsdag morgen.
– Er metoden Labrador brukte sikker nok, når alle andre stengte ned?
– Ja, absolutt, den var helt sikker. Men jeg forstår godt at man har lyst på arbeidsro og ta det ned, sier Thoresen.
Thoresen i Labrador forteller at det var en «massiv operasjon» å distribuere passord og brukernavn til over 10.000 journalister i Norge, Europa, USA, og noen få i Asia, som Sør-Korea.
– Men det virka og det var vellykka. Vi har ikke funnet tegn til angrep. Det var noen få hickups med enkelte spesialtjenester, men den største skaden ble at det ble ekstrajobb for journalister å logge seg på. Vi har fått mange takke-eposter fra redaktører og journalister som takker for at vi passet på og gjorde jobben for dem, sier Thoresen.
– Hva gjorde dere teknisk for å få til dette sikkerhetslaget?
– Det var en enkel standardteknologi som alle utviklere kan, på toppen av vanlig SSO vi hadde fra før.
Ramsalt: Sikkerhet trumfet oppetid
Ramsalt Lab gjorde det stikk motsatte og stengte ned tilgangen til sine plattformer gradvis utover onsdag ettermiddag og kveld. De startet selve oppgraderingsprosessen først klokka 21.50, og de siste nettsidene var oppe igjen klokka 23.50.
Ramsalt har spesialisert seg på å bygge nettløsninger med Drupal, en åpen kildekode publiseringsløsning som igjen bygger på nettopp PHP.
– Det betyr at majoriteten av vår portefølje måtte oppdateres, alt i alt snakker vi om mange hundre instanser, sier Yngve W. Bergheim, partner i Ramsalt, til kode24.
– Hvorfor gikk dere for løsningen med å ta ned plattform og nettsider som driver på den?
– Før selve sikkerhetsoppdateringene var tilgjengelige, var anbefalingen at PHP-versjoner fra 8.1 og nyere fysisk måtte tas av nett og oppgraderes så fort som mulig. Dette refererte også NSM til og vi har mange offentlige kunder som har svært høye krav til sikkerhet, og flere av de kontaktet oss i forbindelse med NSM-versellet, forteller Bergheim.
De offisielle Linux-oppdateringspakkene for deres infrastruktur ble forsinket utover ettermiddagen. Da valgte de å følge den faglige anbefalingen om full nedstengning.
– For oss trumfet garantert sikkerhet kravet om oppetid, og vi valgte en kontrollert og preventiv nedstengning fremfor å basere oss på utrygge workarounds.
Bergheim legger til:
– Det kan gå svært kort tid fra en sårbarhet blir kjent, til den utnyttes automatisk i stor skala. Dette har skjedd tidligere med andre sårbarheter i annen programvare.
Ved å ta sidene av nett, eliminerte vi den risikoen fullstendig.
– Eneste riktige konklusjonen
Før Ramsalt tok ned plattformene, la de på strengere sikkerhetskonfigurasjoner som PHP anbefalte og et ekstra sikkerhetslag via tjenester som Cloudflare og Bunny CDN.
– Vi vet at enkelte aktører valgte å lene seg kun på slike løsninger for å holde sidene åpne, men som det ble poengtert fra både NSM og PHP, er at disse tiltakene gir ingen reell løsning på denne sårbarheten, det er kun mitigerende tiltak, sier Bergheim og fortsetter:
– Å la et slikt filter stå som eneste beskyttelse for et sikkerhetshull som i verste fall gir angripere full tilgang uten passord, innebærer en restrisiko vi overhodet ikke ønsket å utsette våre kunders data for. Derfor ble fysisk nedstengning den eneste riktige konklusjonen for oss inntil den offisielle patchen var på plass.
– Hvilke konsekvenser kunne angrep på PHP-sårbarhetene fått for dere og deres kunder?
– Dette var sårbarheter av mest kritiske sort. Et angrep kunne ha gitt uvedkommende full kontroll over systemene helt uten behov for passord eller innlogging. For kundene våre kunne det betydd datainnbrudd, tap av sensitiv informasjon og manipulering av innhold. Ved å ta sidene av nett, eliminerte vi den risikoen fullstendig.
Han understreker at nedetiden for nettpublikasjonene i flere timer på kvelden er uheldig.
– Vi oppdaterte kundene våre via vår server-statusside, og direkte, og vi opplever stor forståelse fra kundene for at vi velger et føre-var-prinsipp. Gitt hvor alvorlig trusselbildet var globalt, foretrekker vi å ta sidene ned i noen timer fremfor å gamble med kundenes sikkerhet, sier Bergheim.
Foretrekk oss i Google Discover
Ved å legge oss til som foretrukket kilde i Google vil du blant annet få opp flere av sakene våre i Google Discover. Tusen takk for støtten!
