Magento waarschuwt voor beveiligingslek in e-commerceplatform

Magento waarschuwt zijn klanten nu ook zelf voor een beveiligingslek in zijn software voor webwinkels. Het gaat om een bug die remote injectie van code mogelijk maakt. Eerder kwamen beveiligingsonderzoekers al met waarschuwingen.

Op zijn blog probeert Magento klanten te waarschuwen voor de zogenaamde remote code execution-bug. Volgens het bedrijf is het een kritieke bug en moeten klanten die het e-commerceplatform gebruiken zo snel mogelijk updaten naar de nieuwste versie van de software: op 9 februari is er een patch vrijgegeven die de bug zou hebben verholpen. Magento heeft een webpagina geopend waarop webshopeigenaren kunnen kijken of ze nog vatbaar zijn voor de bug.

Alhoewel er dus al een patch uit kwam is het de eerste keer dat het bedrijf spreekt over de omvang van de bug. Zowel de Enterprise Edition als de Community Edition is getroffen door de bug. Wie er in slaagt om kwaadwillende code te injecteren kan de volledige controle over de webwinkel krijgen. Ook kunnen hackers klantengegevens in handen krijgen, aldus Magento.

Eerder lieten beveiligingsonderzoekers al weten dat de software van Magento, die door veel eigenaren van webwinkels wordt gebruikt, kwetsbaar was. Zij waarschuwden het bedrijf al in januari, maar maakten hun vondst onlangs publiekelijk. Enkele jaren geleden kwam ook al een grote bug in het e-commerceplatform aan het licht.

Reacties (36)

Zo te zien heeft Magento letterlijk mijn Magento patch test site gekopieerd, inclusief html comments. Niet zo netjes.

Leuke stat: ik heb ook geplot hoeveel procent per land gepatched is (live data, er wordt continue gescand op basis van een builtwith.com lijst van alle Magento's ter wereld).

Daar was ik wel even achteraan gegaan...

Makkelijker gezegd dan gedaan op zondag. Maar ze hebben inmiddels een bronvermelding gemaakt, met dank aan hun top community manager Ben Marks.

Geen expert maar hierbij wat info:

Als je vreemde admin account er tussen ziet staan dan ben je inderdaad in bepaalde mate al gehacked.
In hoeverre moet verder onderzoek uitwijzen.

Belangrijk is om de patches door te voeren en je cache te legen.
Ook cache zoals APC of andere caching programma's op server niveau dienen geleegd te worden.
Check daarna hier: https://shoplift.byte.nl of je nog steeds vulnerable bent.
Niet meer vulnerable? Good job, naar het volgende punt en anders kijken of de patches wel correct geinstalleerd kunnen worden en of je de cache wel goed leegt.

Als de patch geinstalleerd is moet je natuurlijk direct ook de admin users verwijderen welke niet door jezelf aangemaakt zijn.
Verander ook direct de wachtwoorden voor de correcte accounts.
Omdat ze toegang kunnen hebben gehad tot je database kunnen ze ook inloggen met je bestaande admin accounts - de wachtwoorden zijn niet echt zwaar encrypted opgeslagen namelijk.

Nu is de patch toegepast, incorrecte admin account zijn verwijderd en van de bestaande admin accounts zijn de wachtwoorden gewijzigd.

Wat nu een goed plan is om te doen is je default frontend admin path wijzigen.
Standaard: <jedomeinnaam>/admin
Wijzigen gaat via het bestand aanpassen: app/etc/local.xml
De volgende regel moet aangepast worden:
<frontName><![CDATA[admin]]></frontName>
naar:
<frontName><![CDATA[hierjenieuweadminpath]]></frontName>

Leeg je cache bv door: rm -rf var/cache/*
Of via magento en log uit en weer in via je nieuwe admin pad.
Dit is een kleine aanpassing, wat het geautomatiseerd aanvallen op de admin lastiger maakt.
Aanvallers moeten nu dmv bruteforce erachter komen wat je admin pad is.

Nu moet je achterkomen wat er gedaan is na de hack.
En hier wordt het lastiger en per case verschillend hierover kan ik weinig tips geven.

Tip 1 (van Byte):
zcat logs/*|awk '$6 == "\"POST" && $9 == 200 {print $7}'|sort|uniq -c|sort -nr|grep -e ".*php$"
Waar logs moet verwijzen naar je logs folder van je webserver.
Deze zoekt naar verdachte post php requests.
Lees verder hier: Verdachte bestanden opsporen - Byte

Tip 2:
Zoek naar onlangs gewijzigde bestanden:
find . -mtime -7 -fprint aangepast7dagen.txt
Dit zoekt naar alle aangepaste bestanden in de afgelopen 7 dagen en slaat de resultaten op naar: aangepast7dagen.txt
let op: je kan een timestamp wijzigen dus niet altijd effectief.
let op 2: je zult ook veel resultaten krijgen van je cache

Tip 3:
Check of je niet nieuwe modules hebt zoals filemanagers via Downloader

Vanaf hier moet je verder op onderzoek uit en zal geen enkele case meer hetzelfde zijn.
Je kan security audits laten doen door pro's als je er zelf niet uitkomt.
Let in ieder geval goed op dat je geen backdoors actief laat.

In de toekomst minimaliseren dat dit nog een keer gebeurd:
1) Update je systemen, modules regelmatig en critical patches direct.
2) Zorg voor de juiste file en directory permissions, klik hier
3) Scherm je admin en downloader af, klik hier
4) Ga op zoek naar nog meer magento of linux best practices online.

Heb de meeste maatregelen al jaren geleden als 'standard practice' toegevoegd.

De geinstalleerde filemanager, is deze ook zichtbaar in de lijst van geinstalleerde modules in de backend onder Systeem > Ontwikkelaar?

Aangezien er shops/eigenaren/uitbaters zijn die of niet overweg kunnen met de downloader of deze simpelweg hebben uitgeschakeld (lees laten blokkeren) kan het een makkelijke manier zijn om een aantal selfchecks uit te voeren i.c.m. de extra aangemaakte admin gebruikers.

EDIT: Is er ook een naam bekend van de geinstalleerde filemanager? Of is het een random/wisselende lettercombinatie?

[Reactie gewijzigd door Beanie op 27 april 2015 01:43]

Hier ook enkele shops moeten patchen. Vond het idd vreemd dat nieuwsbericht via Magento zo op het laatste moment binnenstroomde terwijl de patch alweer van een tijd terug is.

Omdat ik 1 klant heb met een shared server met geen ssh mogelijkheden heb ik deze handmatig moeten patchen. Wat redelijk snel ging dankzij https://www.milople.com/b...gento-security-patch.html. Uiteraard wel eerst backups maken van de bestanden die je gaat overschrijven

[Reactie gewijzigd door SYQ op 26 april 2015 11:56]

Deze link heeft beide patches in 1: http://magentary.com/kb/a...d-supee-1533-without-ssh/

Ook tip van die pagina, verander je admin url
leeg caches nadat je alles geupdate hebt.

Deze gratis extensie is ook handig: http://www.magentocommerce.com/magento-connect/watchlog.html

kun je kijken wie er in wil loggen in je backend c.q wie er succesvol is ingelogd.

[Reactie gewijzigd door bbob1970 op 26 april 2015 12:49]

ah ook handig, maar voor mij bleek het voldoende om alleen de 5344 patch te installeren.

De 1533 is alleen nodig als de hosting niet goed is ingesteld, dit kan je simpel testen door een bestand aan te maken met bv phpinfo() erin en op te slaan in je root als 'test.php.csv'. Vervolgens dit openen met je browser en controleren of je bestand ter download krijgt aangeboden wat goed is. In alle andere gevallen snel de patch toepassen.

ps. adminurl aanpassen is een standaard actie van mij tijdens het opzetten van een magento shop

[Reactie gewijzigd door SYQ op 26 april 2015 13:03]

Verder komen er ook aanvallen op de downloader url, deze wordt vaak vergeten. Deze url wijzigen of alleen toegang geven vanaf bepaald ip in htaccess.

De manier waarop Magento omspringt met dit hele verhaal vind ik erg beroerd.

1. 9 februari wordt het lek gepatched. Magento stuurt vervolgens 1 (letterlijk 1) tweet de wereld in dat er een lek is en dat er een patch is. Die tweet kan dus makkelijk verdwijnen in de grote hoop, zeker als je bedenkt dat Magento op hetzelfde account ook allerlei marketing gerelateerde tweets de wereld in stuurt.
2. Pas enkele weken terug (we hebben het dan over april) zorgt Magento voor de eerste mededeling via hun mededelingen kanaal waarop je meldingen in je backend van Magento te zien krijgt. Ruim 2 maanden na de patch en de melding dus. Waarschijnlijk alleen omdat onderzoekers de publiciteit hebben gezocht en zeggen dat er een probleem is.
3. De patch is alleen als patch beschikbaar. Nog steeds. De huidige installatie files van Magento bevatten nog steeds het lek, en via het update systeem van Magento is ook nog geen geupdate files beschikbaar.

Je hebt helemaal gelijk, maar ik vind het ook nogal wonderbaarlijk dat mensen met een Magento webshop blijkbaar niet op de hoogte zijn over de updates. Het is een van de meest cruciale onderdelen van je bedrijf en dan heb je daar geen beleid over of ondersteunende partners die voor je opletten.

De manier waarop Magento omspringt met dit hele verhaal vind ik erg beroerd.

1. 9 februari wordt het lek gepatched. Magento stuurt vervolgens 1 (letterlijk 1) tweet de wereld in dat er een lek is en dat er een patch is. Die tweet kan dus makkelijk verdwijnen in de grote hoop, zeker als je bedenkt dat Magento op hetzelfde account ook allerlei marketing gerelateerde tweets de wereld in stuurt.

Een tweet zie ik niet eens als bekendstelling. Ik zal hem nooit zien, ik heb geen Twitter en weiger om een account te nemen omdat een bedrijf me niet eens een mailtje kan sturen.
Hetzelfde geldt trouwens voor Facebook en dergelijke, ik ga uit van een klant/leverancier relatie, niet via vage derden.

Beroerd inderdaad. Wilde al zoiets roepen, maar het is niet meer nodig

Hoe kan je controleren of je site gehacked is ? Ik heb gecontroleerd met de hogervermelde link, en die geeft aan dat ik veilig ben, maar is dit een garantie dat niemand extra admin accounts heeft aangemaakt ?
Ik heb dinsdag ll. gepatched.

De eerste check is even naar Systeem > Rechten > Gebruikers te gaan, en te kijken of er geen nieuwe vreemde namen tussen staan. Bij elke hack lijkt in iedergeval constant één of meerdere admin accounts aangemaakt te worden.

Daarnaast is het gewoon handig om je hele site even langs te lopen. Klein checklistje:
* Check of er geen gekke gebruikers zijn aangemaakt
* Check in Magento Downloader of er geen gekke nieuwe modules zijn toegevoegd (bijvoorbeeld een file-manager)
* Check (als je er toegang toe hebt) je access_logs van je webhosting om te kijken of er geen gekke POST http requests tussen staan
* Loop na welke bestanden sinds 23 April zijn aangepast, handig in linux shell/SSH: "ls -l -R > tree.txt" en dan tree.txt even downloaden en zoeken naar tekst "Apr 23" bijvoorbeeld. (je zult hier ook veel in je var/session en var/cache vinden misschien, die zijn minder relevant.)

Met dit checklistje ben ik in iedergeval al mijn magento hosting klanten afgegaan. Met helaas wel één hit, maar was snel weer opgelost

[Reactie gewijzigd door alexnauta op 26 april 2015 17:25]

Dus met die Security Patch Page kan ik magento websites afgaan om te kijken of ze kwetsbaar zijn? Ideaal

Ik hoop voor magento dat het alleen maar uit te voeren is als je in kan loggen in de backend van de webshop. Zo niet dan is het idd kinderspel om uit te zoeken welke websites je aan moet vallen.

Nee hoor, je kan het voor iedere magento website uitvoeren. Niet alleen dat, maar er zijn zelfs API tools om dit heel rap te kunnen doen.

$ curl https://magento.com/security-patch-check/{domain}/{admin path}

Of je nu meteen je hack uitvoert en kijkt of ie werkt is toch even veel werk?

Ja, idd. Die pagina die vermeldt word daarom kan je gewoon een adres invoeren... Moet toch een betere manier voor zijn...

Je kan ook checken op https://shoplift.byte.nl

Had hier ook nog één test installatie die 23 april gehackt werd nadat blijkbaar één van de patches niet goed was gegaan (wel juiste versie-keuze). Werkwijze van deze hacker:

* Meerdere admin-accounts aanmaken in Magento
* Filemanager geïnstalleerd via de downloader
* Paar bestanden waren aangepast in diverse mappen

Maargoed, de troep is weer opgeruimd, mensen, check je magento installatie dus ook als je zeker weet dat je alle patches hebt gedaan. (helemaal als je wel eens een core-aanpassing doet (FOEI! ;-) ))

Verder nog iets geks gevonden? (zelfde probleem hier)

Ik zie inderdaad 2 nieuwe admin accounts, een "Magpleasure" filemanager en een eental bestanden die aangepast zijn.

Net even een locale lijst vergeleken met de on-line versie - geen verschil te zien (gelukkig).
Ook geen andere accounts als de mijne... ben waarschijnlijk net op tijd geweest om te patchen.

Ik vraag me alleen af hoe men specifiek magento websites kan vinden op het internet - de mijne stond pas enkele dagen online, en de naam was alleen bij mij en de serviceprovider bekend (Neostrada).

Het is niet zo moeilijk om dit te doen. Ik zou in een kwartiertje/half uurtje iets in Python kunnen schrijven wat:

1. Naar Google gaat en zoekt op shop/webwinkel
2. De eerste 10.000 gevonden domeinnamen volgt en er /admin achter plakt
3. De gevonden HTML daar vergelijkt met een bepaalde footprint van het Magento admin panel login
4. En als bonus met de door Magento zelf aangeboden api/tool kijkt of de site kwetsbaar is

Dit hele proces zou ook niet meer dan 10 minuten duren. Wellicht zou je zelfs kunnen Googlen op een bepaalde magento footprint zoals "powered by magento" oid. Bottomline: Zodra je in Google staat ben je al de sjaak.

Hoe kan je controleren of je site gehacked is ? Ik heb gecontroleerd met de hogervermelde link, en die geeft aan dat ik veilig ben, maar is dit een garantie dat niemand extra admin accounts heeft aangemaakt ?
Ik heb dinsdag ll. gepatched.

waar is de mangeto downloader ? ik zag een vreemde user op mijn nog niet actieve webshop

De downloader is te benaderen via de Magento Connect Manager vanuit je admin backend of door je shop url + /downloader in te tikken.

Het is wijs de downloader sowieso af te schermen of geen permissies meer te geven wanneer je geen extensies of updates hoeft te downloaden.

Als die bug uit 2012 de laatste kritieke beveiligingslek is, doen ze het toch best netjes bij Magento. Er zijn genoeg pakketten die het slechter doen.

Op 23 april zijn de details van het lek vrijgegeven door CheckPoint. Ze hebben er een mooi filmpje over gemaakt:
https://www.youtube.com/watch?v=pnNWCLADBJc

24 uur later kwamen de eerste scans langs opzoek naar het lek. Deze maken in de database een extra admin gebruiker aan. Dit om in korte tijd zoveel mogelijk site over te nemen om ze later te kunnen misbruiken.

Heb je een site gebaseerd op Magento en je hebt de patch nog niet geinstalleerd. Ga er dan maar vanuit dat je site al gehacked is.

Zie hier voor details:
https://blog.sucuri.net/2...exploits-in-the-wild.html