Lek in verouderde Joomla-platformen zorgt voor spamaanval
Toegevoegd door - Ariën -, 14 jaar geleden
Tientallen Nederlandse sites zijn afgelopen weken het slachtoffer geworden van een spambotaanval. Hierbij zijn er diverse berichten gestuurd vanaf gehackte Joomla-platformen. De spambot met de naam 'Rodecap' aanval heeft gebruik gemaakt van een enorme lijst van sites die met een php-backdoor zijn gekaapt.
Onder de getroffen website bevinden zich ook tientallen Nederlandse sites, deze zijn voornamelijk van MKB-bedrijven, stelt onderzoeker Roman Huess. De besmetting is door diverse antivirusbedrijven ontdekt. De onderzoeker verzamelde in een uur tijd een lijst van ruim 3.500 sites die door Rodecap worden misbruikt.
Via een backdoorscript op de geïnfecteerde website versturen de aanvallers spam. De malware gebruikt de URL van www.google.com om vanaf besmette systemen te communiceren met de command & control-server, waarbij de DNS-gegevens van een ander domein worden gebruikt.
Gerelateerde nieuwsberichten
25/10/2016 Ontwikkelaars Joomla brengen patch uit voor kritiek lek
16/12/2015 Joomla dicht opnieuw gevaarlijk beveiligingslek
23/10/2015 Joomla dicht gevaarlijk beveiligingslek
Er zijn 10 reacties op 'Lek in verouderde joomlaplatformen zorgt voor spamaanval'
"Via een backdoorscript op de geïnfecteerde website versturen de aanvallers spam. De malware gebruikt de URL van www.google.com om vanaf besmette systemen te communiceren met de command & control-server, waarbij de DNS-gegevens van een ander domein worden gebruikt."
Kan iemand dat eens duidelijker uitleggen, lijkt interessant maar snap het niet echt wat ze precies gedaan hebben.
Kan iemand dat eens duidelijker uitleggen, lijkt interessant maar snap het niet echt wat ze precies gedaan hebben.
Simpel gezegd: de hackers plaatsten een specifiek script. Dat script werd aan geroepen vanuit de C&C server om specifieke commando's aan te roepen. In dit geval dus om spam te versturen. De C&C-server is de plek waarvandaan de commando's worden verstuurd.
Ik weet niet precies hoe 'niftig' dit ding in elkaar zat, maar weet wel dat er een aantal duizend websites waren besmet. In tegenstelling tot alle berichten in de media, is het niet alleen Joomla maar ook WordPress en andere CMS-en.
Als ze die lijst gewoon eens zouden bekijken, zouden ze weten dat meer dan één CMS is..
Ik weet niet precies hoe 'niftig' dit ding in elkaar zat, maar weet wel dat er een aantal duizend websites waren besmet. In tegenstelling tot alle berichten in de media, is het niet alleen Joomla maar ook WordPress en andere CMS-en.
Als ze die lijst gewoon eens zouden bekijken, zouden ze weten dat meer dan één CMS is..
0 
-0 
-0
@ Chris -
Bedankt dat je de tijd nam om het duidelijk uit te legggen.
Bedankt dat je de tijd nam om het duidelijk uit te legggen.
Vaak komen dit soort acties toch door oude versies, of een plugin die een lek heeft. Zo was dat ook het geval hierbij.
Een eigen systeem maken kost veel tijd en voor bedrijfen ook geld. Maar uiteindelijk bespaart het je veel problemen.
Een eigen systeem maken kost veel tijd en voor bedrijfen ook geld. Maar uiteindelijk bespaart het je veel problemen.
0 -0
-0
oh... Ik wordt altijd een beetje gek van al die "zelf maken is leuker" argumenten... Dat weten we ondertussen wel en je zult er vast veel plezier mee hebben.
Ik zou echter altijd gaan voor een opensource project. Waarom? Omdat die door veel meer mensen beheerd wordt en dus zijn er veel mee zienswijzen waardoor een project veiliger wordt en omdat het veel tijd kost om je eigen project te maken en bij te houden.
Want wie zegt dat jou klant jouw CMS versie update? Of wordt je CMS uberhaupt wel upgedated? En ik vraag me ook altijd ten sterkste af of je eigen CMS wel veiliger is dan een opensource CMS. Ik denk zelf van niet, tenzij je net zoals Chris gespecialiseerd bent in beveiliging.
Ik zou echter altijd gaan voor een opensource project. Waarom? Omdat die door veel meer mensen beheerd wordt en dus zijn er veel mee zienswijzen waardoor een project veiliger wordt en omdat het veel tijd kost om je eigen project te maken en bij te houden.
Want wie zegt dat jou klant jouw CMS versie update? Of wordt je CMS uberhaupt wel upgedated? En ik vraag me ook altijd ten sterkste af of je eigen CMS wel veiliger is dan een opensource CMS. Ik denk zelf van niet, tenzij je net zoals Chris gespecialiseerd bent in beveiliging.
Ik ben geneigd akkoord te gaan met Wouter.
Ik hoorde echter eens een hacker het omgekeerde (nu ja...) zeggen. Ik wil het even melden.
Zijn redenering was: kei handig dat al die versies nog actief zijn in sites.
bv. Zoek een willekeurige drupal site; Kijk naar de core versie; dan kijk je in je "hack" mapje, en je weet welke truuk je moet boven halen.
En als je het goed wil doen: Eerst zet je zelf een site online (of thuis) en je hackt die. Dan zoek je een lijstje met sites met de zelfde core versie en je hackt ze allemaal op het zelfde moment; vooraleer iemand een patch kan schrijven.
Ik hoorde echter eens een hacker het omgekeerde (nu ja...) zeggen. Ik wil het even melden.
Zijn redenering was: kei handig dat al die versies nog actief zijn in sites.
bv. Zoek een willekeurige drupal site; Kijk naar de core versie; dan kijk je in je "hack" mapje, en je weet welke truuk je moet boven halen.
En als je het goed wil doen: Eerst zet je zelf een site online (of thuis) en je hackt die. Dan zoek je een lijstje met sites met de zelfde core versie en je hackt ze allemaal op het zelfde moment; vooraleer iemand een patch kan schrijven.
0 -0
-0
Op zich ook wel logisch. Die kant-en-klaar pakketten worden door veel mensen onderhouden. Van de ene kant zou je zeggen leuk, want dan wordt het allemaal goed gecontroleerd. Alleen in de praktijk blijkt dat andermans code nooit helemaal goed te controleren is. Al gauw wordt er vanuit gegaan dat het wel goed zal zijn. Daarnaast worden er zeer veel plugins gemaakt door Jan en Alleman. Er hoeft maar een klein lek in 1 zo'n plugin te zitten en het is bekeken. Vervolgens wordt zo'n lek bekend gemaakt en dan is het hek van de dam. Miljoenen sites worden via een scriptje automatisch gescand op het betreffende lek. Zijn ze besmet, dan worden ze gehackt. Bij een eigen systeem is van het bovenstaande geen sprake.
0 -0
-0
Quote:
Alleen in de praktijk blijkt dat andermans code nooit helemaal goed te controleren is. Al gauw wordt er vanuit gegaan dat het wel goed zal zijn
Oh? Misschien is dit jouw ervaring. Maar dan kijk ik bijv. een naar symfony (weet niet hoe dit bij andere frameworks zit). Deze doet er veel aan security. De grote applicaties die symfony gebruiken, bijv. Drupal, hebben allemaal toegang tot een afgeschermd gedeelte waarop security problemen kunnen worden gemeld. Er is dan een speciaal team bij SensioLabs icm de lead dev. van het desbetreffende component die deze lek zo snel mogelijk proberen op te lossen. Vervolgens kunnen alle mensen met toegang dit script reviewen en als iedereen het accepteert wordt er een nieuwe security versie gereleased.
1 à 2 keer in de maand komt er wel weer zo'n security release (gister was er nog 1).
Quote:
Daarnaast worden er zeer veel plugins gemaakt door Jan en Alleman. Er hoeft maar een klein lek in 1 zo'n plugin te zitten en het is bekeken. -
Kijk! bingo! Dat is waar het om gaat. De plugins zijn de onveilige factoren in open-source software.
Ongewenste links verwijderd
[/modedit]
0 -0
-0
Het voordeel van opensource cms systemen is dat het het onderhouden wordt door een grote community, nadeel is dat alle bugs gepubliceerd worden en dat de gebruikers de updates negeren, waardoor hun systeem een gemakkelijk doelwit is/wordt
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu