27.000 websteder inficeret gennem kritisk Joomla-sikkerhedshul

Et af de mest udbredte CMS-systemer, Joomla, er ramt af to sikkerhedshuller, og websteder, der ikke har installeret den seneste patch, bliver systematisk forsøgt inficeret.

Der gik blot 36 timer, før knapt 30.000 websteder var inficeret som følge af to kritiske sikkerhedshuller i CMS-systemet Joomla, som blev lukket for en uge siden. Der er stadig sites, der er sårbare, og derfor opfordrer flere sikkerhedsfirmaer Joomla-sites til hurtigst muligt at installere sikkerhedsopdateringerne.

Ifølge Sucuri gik en kampagne i gang for at masseinficere Joomla-sider kort efter offentliggørelsen af opdateringerne til Joomla den 25. oktober.

Det er ikke første gang, at populære CMS-systemer på denne måde bliver udsat for massive angreb, kort efter lukningen af kritiske sikkerhedshuller.

Det er både sket for Wordpress og Drupal, og Joomla har ifølge sikkerhedsfirmaet Sophos også i 2014 oplevet, at der gik mindre end syv timer, før webadministratorer stod i en situation, hvor de var nødt til at antage, at deres sites var inficerede, hvis de ikke havde nået at installere patchen.

Sikkerhedshullerne i Joomla gør det muligt at oprette brugere og give dem administratoradgang til siderne. Det ene sikkerhedshul gør det muligt at oprette en bruger, selvom brugeroprettelse er deaktiveret, og det andet gør det altså muligt at oprette brugere med udvidede rettigheder.

Begge sikkerhedshuller blev rettet af Joomla-organisationen inden for en uge, efter de blev indberettet, men der gik altså blot få timer, før de første forsøg på at udnytte sikkerhedshullerne på upatchede Joomla-sites begyndte.

Ifølge Joomla-organisationen findes sikkerhedshullerne i de supporterede versioner fra 3.4.4 frem til 3.6.3. Den opdaterede version er 3.6.4.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Bent Jensen

Sørger for at ens system er patches samt opdateret, noget der heldigvis foregår forholdsvis let og ubemærket i et Linux miljø.

Hvis man ikke har tid, viden og overskud til at holde øje med patch og få det gjort. Så læg ens hjemmesider ud til nogen som har. Det gør jeg, så kan jeg bruge min krafter på så meget andet.

Som at holde weekendt, ude at skulle bekømmer mig om sikkerheden, idet mindste ikke der :-)

  • 0
  • 0
#3 Rune Jensen

Mjo. Jeg kører en ASP-side, du ved det gode gamle MS-knald fra dengang IE6 dominerede verden, og jeg har oplevet en lille stigning i antallet af forsøg på scanning efter sårbarheder i både wordpress og Joomla.

Det er pluginsne, de går efter, samtidig med de forsøger at finde biblioteket til admin.

Jeg har implementeret en scanning af både query string og en slags regex scanning på URLer, som ikke findes (en log på alle 404ere), som indeholder f.eks. wordpress, admin, plugins mv.

Men man skal også være opmærksom på sine plugins, det er nok budskabet. Selve CMSet er formentlig hurtigere ude med sikkerhedsopdateringer end ganske mange 3. parts plugins er.

Den, de går efter lige pt. er en youtube-plugin. Ikke at det siger mig noget videre.

Det har så iøvrigt ikke så meget at gøre med, på hvilket OS system det køres, hvis der er sårbarhed i selve CMSet eller dets plugins.

Der bruges ganske meget directory traversal i deres scanning... Så jeg har også en blocking på det (en traversal ser nogenlunde sådanher ud: SKRÅSTREG..SKRÅSTREG..SKRÅSTREGadmin)

Der er ingen CMSer, som har brug for at lave en directory traversal i query string, så man kan med sindsro blokere alle sådanne forsøg. Case in point... Jeg kan ikke beskrive et sådant forsøg på en V2 comment, jeg bliver blokeret...

  • 0
  • 0
#4 Rune Jensen

Når gælder, hvordan disse botter ser ud, så kan man gå ud fra, at omkring 80% af dem er "gammelt" bot-software. Ejerne af disse botter er dovne som bare... Og de opdaterer ikke deres botter førend, de når under en vis succes rate.

Her er nogle af de ting, som er mistænkelige:

En GET request, hvor Content-Type er application/x-www-form-urlencoded. Denne content-type bruge normalt kun ved POST, men hvis man nu er doven, så skelner man ikke imellem de to methods. Jeg har endnu ikke set denne content-type ved en GET request, hvor det ikke var en bot.

En user-agent, hvor browser-version er mere end 8 versioner ældre end den nyeste version (med undtagelse af MS, hvor det gerne stadig er en IE6 eller IE 7). Hvis den angives som IE6, er den i langt de fleste tilfælde en harvester.

Ingen accept-language. Langt de fleste browsere sætter Accept-language, omend man kan forestille sig visse plugsins måske vil forhindre det.

Accept-Encoding uden GZIP i en request. Alle browsere forstår GZIP, fordi det er en ret gammel standard, og den forbedrer brugeroplevelsen. Hvis en request sætter en accept-encoding uden GZIP, er det som regel en bot i et meget gammelt stykke bot-software.

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