WordPress-plugin gav sikkerhedshul til hackere

WordPress-tilføjelsen Fancybox-for-WordPress er blevet udpeget til at være den tilføjelse, som har gjort en lang række WordPress-sider sårbare overfor angreb.

WordPress-tilføjelsen Fancybox-for-WordPress har et sikkerhedshul, som allerede er blevet udnyttet til at injicere malware ind på forskellige WordPress sider. Det skriver Computerworld.

Sider med tilføjelsen bør ifølge Computerworld.com sørge for at opdatere deres plug-in med den version, som blev sendt ud torsdag.

Det er sikkerhedsefterforskere fra websikkerhedsfirmaet, Sucuri, som onsdag udsendte en advarsel om sårbarheden, efter at have set angreb, som injicerede en ondsindet iframe ind i websiderne.

De sporede problemerne til en fejl i Fancybox-for-WordPress, som giver webmasteren adgang til let at integrere FancyBox Javascript bibliotek ind på deres side.

FancyBox er et værktøj til at vise billeder, html-indhold og multimedie i en såkaldt lightbox, som flyder i toppen af siden. Tilføjelsen er blevet downloaded 600.000 gange fra det officielle WordPress plug-in-katalog til dato.

»Efter nogle analyser kan vi bekræfte, at dette plug-in er en seriøs sårbarhed, som giver adgang til at indsætte ondsindet materiale på de sårbare sider,« skriver Sucuri-efterforskerne i en blog, hvor de anbefaler folk at fjerne tilføjelsen, fordi fejlen ikke er blevet repareret.

Det er måske alligevel ikke helt nødvendigt at fjerne den, da tilføjelsen siden er blevet udsendt i to nye versioner lige efter hinanden torsdag, hvilket fixer sårbarheden. Version 3.0.3 adresserer fejlen, mens 3.0.4 omdøber plug-in-indstillingen, hvor problemet kom fra.

»Dette burde stoppe den ondsindede kode fra at dukke op på siderne, hvor plug-in'et er opdateret uden at fjerne den ondsindede kode,« siger udviklerne bag tilføjelsen i changelog. Samtidig opfordrer de brugerne til at benytte sig af den seneste version.

WordPress er ifølge ComputerWorld.com et favoritmål for hackere, som vil kompromittere dem til at være bærere af ondsindet indhold og spamsider, eller bare vil overtage kontrollen over de underliggende webservere. Svagheder i tilføjelser og temaer til programmet har været udnyttet i store angreb, som kompromitterede tusinder af websider.

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
Rune Jensen

Her et lille udpluk af, hvad der bliver scannet efter på min hjemmeside, som har givet 404:
/administrator/index.php
/wp-login.php
/cms/uploadify/uploadify.swf
/admin/fckeditor/editor/filemanager/browser/default/connectors
/webadmin/fckeditor/editor/filemanager/browser/default/connectors

Det er ikke fordi jeg vil opfordre til security by obscurity, men vel heller ikke nogen grund til ligefrem at hjælpe automatiseret scannersoftware.

Altså måske man skulle ændre navnet på admin-mappen til noget andet fx.

Listen er iøvrigt ganske meget længere end det. Hvad der søges efter er standard admin login sider, samt evt. filmapper/navne på kendte plugins til CMSer og filnavne og mapper til selve CMSet.

Listen er også en udmærket måde at vise, hvorfor logs er sådan en god idé. Nogle af de her filer, som søges efter, har jeg redirected til en "Occupy the bots"-side, hvor de kan have det sjovt sammen med andre botter, og så kan jeg analysere dem uden de gør skade (AKA honeypot).

Så, det med selve sårbarheden, og hvordan den influerer...

Ganske mange request jeg får ind, stammer fra IPer, som på en eller anden måde er inficeret med eller viderebefordrer malware.

Og Ransomware er helt klart i vækst, sket indenfor den sidste måned.

I forbindelse med research på en af disse IPer, havnede jeg på Malwarebytes hjemmeside. Og jeg blev sådan lidt overrasket. Deres konklusion er, det er ikke længere nok med antivirus. Man er nødt til at bruge whitelists for at undgå de her driveby downloads.

Tak for det, Malwarebytes. Det er vi nogen, som har sagt 4-5 år nu. Godt nogen i den der AV-industri kom til fornuft.
https://blog.malwarebytes.org/malvertising-2/2015/01/major-malvertising-...

(NB: Analysen dækker en clickfraud, ikke ransomware, da den fejlagtigt blev detecteret som ransomware i starten. Ændrer dog ikke på, jeg har fået et stigende antal af de her Ransomware besøg på det sidste.)

  • 1
  • 0
Rune Jensen

Det er i princippet bare en scriptet side, som botterne bliver "ledt" til (enten fordi de bevæger sig hvor de ikke skal og så føres dertil af et indbygget "bot-script" i hjemmesiden, eller fordi de er nysgerrige - læs links, som ikke læses af mennesker). Eller fordi de leder efter f.eks. standard-filer som /admin.php, som så usynligt leder dem til siden (kan formentlig gøres via .htaccess?). Hovedsagen er - de vil sjældent følge en 301 ud af en side. Derfor de skjulte links også. De skal lokkes - ikke tvinges.

Nogle vil sikkert kunne give en bedre beskrivelse og opskrift på en honeypot, men grundlæggende, så handler det om en side, som er skjult for mennesker og skjult for søgemaskiner, men yderst attraktiv for og optimeret imod "ondsindede" botter.

Idéen er så, at man forsøger at fastholde botterne i honeypotten, fordi det de finder der er for "lækkert" til at modstå. Sådan man både får dem væk fra hovedsitet, men også så man kan studere dem og evt. finde forsvar imod dem. Logningen er en ret vigtig del af det af den grund.

Nu er min så ret primitiv, men f.eks. på honeypot-siden kan være en form med feltnavne som "message" og et text-area, det vil være ganske interessant for spambotter.

Ligeledes vil feltnavne som "admin" i en anden form tiltrække andre typer af botter.

Både form feltnavne, men også den måde, som siden reagerer på fx. en POST request på, kan være af betydning for, om en bot "tror" på, at honeypotsiden er hvad den vil have fat i. Så man kan godt risikere at skulle tune siden.

Skal nok tilføje, at hvad angår "lækkerbiskener", så tillader jeg alt i fx. query string, som tit bruges til SQL-injection. Bare kun på honeypotsiden. Loggingen foregår alligevel i tekst-filer uden kontkt til en DB. Men det er altså alt efter hvad man vil tillade selv.

Og så skal man nok lige huske robots.txt forstås af de "godartede" søgemaskiner, og ellers giver de samme søgemaskiner sig til kende i useragent og i helt desperate tilfælde, så oplyser de selv deres IPer på deres hjemmesider. Man vil helst ikke have søgemaskiner ind i honeypotten.

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