Mossack Fonseca, Drupal och The Panama Papers

Vi har alla hört om skandalerna kring “The Panama Papers” och den panamanska advokatbyrån Mossack Fonseca. Storyn nystades fram genom att en hackare som kallade sig “John Doe” bröt sig in i advokatbyråns servrar och fick tillgång till en rekordmängd dokument och e-postmeddelanden. Intrånget kunde genomföras på grund av kända säkerhetsluckor i Wordpress och Drupal. Eftersom vi i huvudsak använder Drupal som CMS i våra kundprojekt tog vi ett snack med ett par av våra utvecklare, Erik Johansson och Christoffer Palm, för att ställa några säkerhetsrelaterade frågor.

Hur är det möjligt för hackare att bryta sig in i ett system via en webbplats?

- I det här fallet handlade det om en sårbarhet i Wordpressmodulen "Revolution Slider” som gjorde att personer utan tillåtelse kunde komma åt en konfigurationsfil där användarnamn och lösenord för databasservern fanns tillgängliga i klartext. Med de uppgifterna kunde personerna ansluta till databasen och komma över uppgifterna för deras mailserver som var angivna i en annan modul som används till att skicka mail från Wordpress via en SMTP-server.

Mossack Fonsecas webbplats, där det huvudsakliga intrånget skedde, drevs på Wordpress. Kunde de inte ha skyddat sig mot en attack?

- De kunde absolut ha skyddat sig mot en sådan här attack. Det första steget är att se till att ens sajter är uppdaterade. Kör en ett CMS som exempelvis Drupal eller Wordpress måste en även se till att moduler och plugins som används är uppdaterade. Det hjälper alltså inte att bara uppdatera sitt CMS. Ofta inom open-sourcevärlden släpps det en fix för att täppa igen säkerhetshål innan de avslöjas för allmänheten. Därför gäller det att hålla ögonen öppna efter sådana nyheter.

- Något som även är väldigt viktigt om en har stora säkerhetskrav är att separera servrar i nätverket från varandra. Det ska alltså inte gå att komma åt exempelvis mailservern om en har lyckats göra intrång på webbservern vilket var fallet här.

Deras kundplattform var byggd på Drupal, varför kunde de ta sig in där med?

- Angriparna kunde ta sig in i Drupal av samma anledning som de kunde ta sig in i Wordpress: genom utdaterad mjukvara. Säkerhetshålet som användes här är känt sedan lite mer än ett och ett halvt år tillbaka (läs Drupalgeddon) och borde absolut varit fixat vid tidpunkten för intrånget.

Är de här systemen generellt sett osäkrare än andra system?

- Välanvända CMS-system är ofta väldigt säkra då de används av så många att säkerhetshål ofta uppmärksammas tidigt. Om en bygger andra projekt i PHP som inte är direkt Drupal-relaterade finns det även verktyg som t.ex. https://security.sensiolabs.org/ som hjälper en att säkra upp kod samt https://insight.sensiolabs.com/ som hjälper en att säkerställa kvalitet på projektet och möjligen upptäcka säkerhetsbrister tidigt i utvecklingen.

- ”Nackdelen” med mjukvara som bygger på open source är att källkoden är öppen för alla, detta gör att det ofta blir en kamp mellan utvecklare och hackare om vem som är först med att hitta ett säkerhetshål. Hittar hackare det först annonseras det inte via publika kanaler och då finns det inte så mycket att göra. Är säkerhetshålet hittat av utvecklare så släpps det i regel alltid en fix innan sårbarheten annonseras ut. Detta ger då utvecklare en chans att uppdatera sina sajter innan säkerhetshålet blir till allmän kännedom.

Vad kan jag som underhåller en webbplats i Drupal göra för att förebygga liknande intrång?

- Du som underhåller en webbplats byggd i Drupal bör alltid ha senaste versionen av Drupal Core och de moduler som har lagts till. Har du skrivit en egen modul är det viktigt att den följer de kodstandarder som finns.

- Se även till att du följer listor som t.ex. https://www.drupal.org/security eller får e-post skickat till dig varje gång det finns en uppdatering av Drupal eller någon modul du använder. Drupal har sedan version 6 en inbyggd modul som heter Update Status (ändrade namn till Update Manager i Drupal 8) som enligt standard gör en kontroll varje dag och skickar ut ett mail till den angivna e-postadressen med information om vad som behöver uppdateras. Detta fungerar dock enbart om du har cron (https://en.wikipedia.org/wiki/Cron) konfigurerat på din server.

Behöver jag som kund hos Odd Hill idag vara orolig?

- Absolut inte. När det kommer säkerhetsuppdateringar som är kritiska uppdaterar vi alla berörda sajter. Vid Drupalgeddon patchade vi omkring 70 kunders sajter på under 2 timmar. Eftersom vi tog säkerhetshålet på allvar har inte en enda kund blivit drabbad av säkerhetshålet. Man kan dock aldrig vara 100% säker, det är därför bra att ha ett serviceavtal med oss där kontinuerliga uppdateringar ingår.