'Veel Magento-webshops nog kwetsbaar door lek in Zend Framework'
Veel webshops die op het Magento e-commerceplatform draaien, zouden kwetsbaar zijn door een lek in het Zend Framework. Het lek is al gedicht, maar kan nog misbruikt worden als sitebeheerders de benodigde updates niet installeren.
Het lek in het Zend Framework, een opensource-framework waar onder andere Magento gebruik van maakt, kan misbruikt worden via zogenaamde xml external entity-injecties. Hierdoor kan een aanvaller toegang krijgen tot een server en onder andere gegevens uit een database buitmaken. Magento heeft onlangs de gaten in zijn webwinkelsoftware gedicht met updates voor zowel de Community Edition als de Enterprise Edition, nadat het lek ook werd gedicht in recente versies van het Zend Framework.
Volgens onderzoek van de Duitse website Heise Security blijkt een groot aantal webwinkels echter nog geen maatregelen te hebben genomen om het lek te dichten. Uit een steekproef van 50 mogelijk kwetsbare webwinkels bleken 24 Magento-sites nog steeds gekraakt te kunnen worden omdat de laatste updates nog niet zijn geïnstalleerd.
Het in verhouding grote aantal Magento-webwinkels dat kwetsbaar voor de xee-aanvalsmethode is, kan opvallend genoemd worden: het lek is al sinds medio juni bekend en er zijn bovendien exploits publiekelijk beschikbaar. Daarnaast maakt er meer software gebruik van het Zend Framework, waardoor potentieel meer software kwetsbaar kan zijn.
Reacties (38)
Als Magento minder spam produceert in het update-kanaal wordt het denk ik eerder opgemerkt door admins.
Niet alleen krijg je veel spam over de updates, ook ben ik van mening dat het updateproces alles behalve soepeltjes verloopt. Een van de webshops die ik beheer loopt op Magento, en elke keer wanneer er een update komt, ben ik minimaal een werkdag kwijt om de shop weer goed te laten functioneren.
Ik mag toch hopen dat jij niet klakkeloos elke update gaat installeren op een site die in productie is?
Al helemaal niet waar modules van externe partijen bij zitten, wie weet wat er allemaal stuk gaat..
Al helemaal niet waar modules van externe partijen bij zitten, wie weet wat er allemaal stuk gaat..
Uiteraard draai ik alles netjes op een testomgeving.
Dat kan ook gewoon aan een 'slechte' installatie liggen of de instellingen bij je hosting partij. Ik kom hetzelfde ook tegen bij bv. Joomla en Wordpress, de ene installatie van WP heb ik zelf gedaan, de ander heeft iemand anders gedaan. De ene gaat vlot en perfect met updaten, de ander is elke keer een puinhoop en moet je een hoop handwerk verrichten. Vaak is de hoster even lekker bezig omdat ze zoveel mogelijk hebben geprobeerd de server dicht te timmeren en worden bepaalde (nieuwe/veranderde) php transacties gezien als kwaadwillend daardoor werkt je website opeens niet meer.
[Reactie gewijzigd door Cergorach op dinsdag 14 augustus 2012 18:13]
Waarom zou je iedere keer een update nodig hebben ?
De zend update was één van de weinig echte security update die absoluut noodzakelijk zijn. Voor de rest als een shop werkt waarom updaten, tenzij het een echte update is om alles te vernieuwen.
De zend update was één van de weinig echte security update die absoluut noodzakelijk zijn. Voor de rest als een shop werkt waarom updaten, tenzij het een echte update is om alles te vernieuwen.
*facepalm*
Recentelijk hebben we:
Release Notes - Magento 1.7.0.2 (Jul 5, 2012)
Fixed: Security vulnerability in Zend_XmlRpc
Release Notes - Magento 1.7.0.1 (Jun 20, 2012)
Fixed: Several potential security vulnerabilities
De release notes gaan slechts terug tot versie 1.6 (juni 2011), maar ik weet dat daarvoor er ook nog een hoop puur security fixes zijn geweest. Daar komt bij dat een hoop 'workarounds' voor bugged features juist security vulnerabilities opleveren.
En je heb gelijk, als het gaat om puur functionele fixes/verbeteringen en de gebruikers hebben daar geen last van (en je heb niet de boel zitten hacken met 'workarounds'), dan hoef je inderdaad niet te updaten. Maar kennelijk heb je zelf ook niet goed op zitten letten, want twee weken voor de Zend patch was er ook al een patch die security vulnerabilities dichte. Omdat er potential wordt gebruikt in de bewoording betekent nog niet dat je het niet moet uitrollen aangezien we niet weten wat de security issues zijn die gefixed zijn (en die gaan ze ons ook niet vertellen).
Recentelijk hebben we:
Release Notes - Magento 1.7.0.2 (Jul 5, 2012)
Fixed: Security vulnerability in Zend_XmlRpc
Release Notes - Magento 1.7.0.1 (Jun 20, 2012)
Fixed: Several potential security vulnerabilities
De release notes gaan slechts terug tot versie 1.6 (juni 2011), maar ik weet dat daarvoor er ook nog een hoop puur security fixes zijn geweest. Daar komt bij dat een hoop 'workarounds' voor bugged features juist security vulnerabilities opleveren.
En je heb gelijk, als het gaat om puur functionele fixes/verbeteringen en de gebruikers hebben daar geen last van (en je heb niet de boel zitten hacken met 'workarounds'), dan hoef je inderdaad niet te updaten. Maar kennelijk heb je zelf ook niet goed op zitten letten, want twee weken voor de Zend patch was er ook al een patch die security vulnerabilities dichte. Omdat er potential wordt gebruikt in de bewoording betekent nog niet dat je het niet moet uitrollen aangezien we niet weten wat de security issues zijn die gefixed zijn (en die gaan ze ons ook niet vertellen).
Yuy gratis shoppen. Zo ga je plots vrouwelijke hackers krijgen:-)
waarom zo onlaag gemod: is op zich on-topic en nog humor ook.
U bent onbekend met de hackende huisvrouwen?
Mijn vrouw hackt continu mijn bankrekening. Dus ja, ik ben er bekend mee.
Niets is 100% veilig zelfs jij niet als mens op straat, er is altijd een kans dat er iets verschrikkelijks gebeurt.
Dat wordt nooit beweerd, in dit geval is het lek al lang gedicht alleen moeten mensen updates installeren. In Windows zitten ook zo vaak lekken, als mensen de updates niet installeren moeten ze ook niet zeuren dat Windows onveilig is
Er is niets mis met de veiligheid van Open Source Software, er is iets mis met de update policy van een hoop webshops en websites. Dat is een bekend probleem, vaak hebben (kleine) webstores geen eigen ITers die de boel direct updaten als er patches uitkomen, het is vaak één keer een ITer inhuren (if that) om de boel te installeren en daarna bijna nooit meer updaten. Het is een issue met veel software, helemaal met 'gratis' software (wat OSS vaak is) omdat er dan helemaal geen opstart kosten aan zitten. Het is niet de eerste keer dat ik software tegenkom waar al jaren geen updates over zijn uitgevoerd...
Ach hoe belangrijk kan IT nu toch zijn om daar geld aan uit te geven... En maar klagen dat er steeds persoonlijke gegevens op straat liggen.
Er zal eerdaags wel wat moeten gaan veranderen wanneer ondernemers zich realiseren dat ze tot ¤450.000 aan boete kunnen oplopen als hun site is gehacked en ze blijken niet voldoende beveiliging te hebben.
nieuws: Regering wil boete slechte beveiliging persoonsgegevens verhogen
Ach hoe belangrijk kan IT nu toch zijn om daar geld aan uit te geven... En maar klagen dat er steeds persoonlijke gegevens op straat liggen.
Er zal eerdaags wel wat moeten gaan veranderen wanneer ondernemers zich realiseren dat ze tot ¤450.000 aan boete kunnen oplopen als hun site is gehacked en ze blijken niet voldoende beveiliging te hebben.
nieuws: Regering wil boete slechte beveiliging persoonsgegevens verhogen
[Reactie gewijzigd door Cergorach op dinsdag 14 augustus 2012 17:58]
Iedere webshop eigenaar krijgt bij het inloggen van magento zelf een melding te zien!
dus waarom ze er dan niets aan doen is mij een raadsel.
http://www.magentocommerc...nd-platform-vulnerability Link toegevoegd.
dus waarom ze er dan niets aan doen is mij een raadsel.
http://www.magentocommerc...nd-platform-vulnerability Link toegevoegd.
[Reactie gewijzigd door slabetje op dinsdag 14 augustus 2012 17:57]
Dat is relatief simpel te verklaren.
Niet elke webshopeigenaar heeft zijn webshop ook zelf gebouwd. Sterker nog, 9/10 webshopeigenaren heeft zijn/haar webshop laten ontwikkelen door een website bouwer.
Uit ervaring kan ik je vertellen dat er vaak onduidelijkheden bestaan over de onderhoudsverplichtingen. Wie zorgt er voor dat de website 'up to date' blijft? De eigenaar of de bouwer?
Het 'up to date' houden van een website is natuurlijk niet gratis, daarom kiezen veel eigenaren er voor om geen servicecontract af te sluiten. Of minder ervaren website bouwers vergeten het aan te bieden aan hun klanten.
Het bouwen van een website is 1, maar het onderhouden is misschien nog wel veel arbeidsintensiever.
Niet elke webshopeigenaar heeft zijn webshop ook zelf gebouwd. Sterker nog, 9/10 webshopeigenaren heeft zijn/haar webshop laten ontwikkelen door een website bouwer.
Uit ervaring kan ik je vertellen dat er vaak onduidelijkheden bestaan over de onderhoudsverplichtingen. Wie zorgt er voor dat de website 'up to date' blijft? De eigenaar of de bouwer?
Het 'up to date' houden van een website is natuurlijk niet gratis, daarom kiezen veel eigenaren er voor om geen servicecontract af te sluiten. Of minder ervaren website bouwers vergeten het aan te bieden aan hun klanten.
Het bouwen van een website is 1, maar het onderhouden is misschien nog wel veel arbeidsintensiever.
Vele laten idd een shop bouwen, mag niet te veel kosten en moet dan geld opleveren. Ze kijken er verder niet naar om nog hebben ze de kennis er naar om te kijken. Natuurlijk kun je het laten doen maar dat kost geld, en geld mag het niet kosten het moet opbrengen.
Er is echer wel een groot verschil tussen een daadwerkelijke developer en Beun de Haas die Magento, Wordpress ed gebruikt.
Dus 9/10 laten de website bouwen, maar slechts 1/1000 (waarschijnlijk nog minder) laat dit doen door iemand met kennis van zaken.
Dus 9/10 laten de website bouwen, maar slechts 1/1000 (waarschijnlijk nog minder) laat dit doen door iemand met kennis van zaken.
Als ze niet willen updaten moeten ze ook niet gaan janken als straks hun webshopje is gehackt.
Zij janken niet, dat doen de klanten.....
Het zou strafbaar moeten zijn IMO, dit soort nalatigheid. Heb wel eens een paar keer meegemaakt dat m'n creditcardnr was buitgemaakt door criminelen en in beiden gevallen was dit doordat er ingebroken was op een webshop. Geld wel teruggekregen natuurlijk, maar je hebt er toch weer een hoop gedoe mee.
Wat dat betreft kan je beter PayPal zoveel mogelijk gebruiken als betalende gebruiker en aan dat PayPal account je credit card hangen. De meeste (kleine) webshops ondersteunen Paypal, een Amazon bv. weer niet, maar die zal dan ook minder snel gehacked worden.
Ligt er helemaal aan wie de creditcard afhandeling doet. Als je een payment provider hebt zoals vele blijven de creditcard gegevens niet op jou website maar bij de payment provider. Van die partijen mag je verwachten dat ze de boel op order hebben en meestal staan ze ook onder controle.
Tja, veel webshops zijn ooit neergezet en worden amper tot niet meer bijgehouden. Er zijn nog veel Magento shops die op versies van 2-3 jaar geleden draaien. Er zijn zelfs nog bouwers die nieteens met de nieuwste versies aan de gang gaan als ze een nieuwe shop maken.
Nu is er wel een fix uitgebracht die voor alle versies van Magento zou moeten werken, alleen moet je dat net weten en je developer weten in te schakelen, hopen dat die gast(en) reageren en dat ze het fixen.
Ik ken ook shops die neergezet zijn en waar gewoon totaal geen onderhoud aan wordt uitgevoerd, erg leuk als er fouten in zitten, en dat zijn niet altijd kleine frotshopjes... sommige hangen ook zo houtje-touwtje aan elkaar dat iedere update/upgrade de hele shop sloopt...
Nu is er wel een fix uitgebracht die voor alle versies van Magento zou moeten werken, alleen moet je dat net weten en je developer weten in te schakelen, hopen dat die gast(en) reageren en dat ze het fixen.
Ik ken ook shops die neergezet zijn en waar gewoon totaal geen onderhoud aan wordt uitgevoerd, erg leuk als er fouten in zitten, en dat zijn niet altijd kleine frotshopjes... sommige hangen ook zo houtje-touwtje aan elkaar dat iedere update/upgrade de hele shop sloopt...
De nieuwste versie bij magento betekend ook vaak weer wijzigingen in template of andere extensies die je moet updates. De vraag is ook of je moet blijven updaten als alles voor jou goed werkt.
Een security update is altijd een must maar van magento 1.6 naar 1.7 hoeft geen must te zijn.
Een security update is altijd een must maar van magento 1.6 naar 1.7 hoeft geen must te zijn.
Fix is te doen binnen 5 minuten. Dus niet lui zijn, nu doen!
1.4.0.0 tot 1.4.1.1
1.4.2.0
1.5.0.0 tot 1.7.0.1
Uploaden naar de Magento root
SSH inloggen, naar de Magento root navigeren en volgende command uitvoeren :
patch -b -p0 < CE_1.5.0.0-1.7.0.1.patch
1.4.0.0 tot 1.4.1.1
1.4.2.0
1.5.0.0 tot 1.7.0.1
Uploaden naar de Magento root
SSH inloggen, naar de Magento root navigeren en volgende command uitvoeren :
patch -b -p0 < CE_1.5.0.0-1.7.0.1.patch
Wat !? in 5 minuten ??
Zeker het forum van Magento en diverse blogs nog nooit gelezen.
Overigens geven niet alle providers je SSH toegang en dan wordt het een heel ander verhaal.
De patch zit in 1.7.0.2. Deze is ook op te lossen in het ZEND framework.
tipje, Vergeet niet de backup anders kost het je nogmaals 5 minuten
Zeker het forum van Magento en diverse blogs nog nooit gelezen.
Overigens geven niet alle providers je SSH toegang en dan wordt het een heel ander verhaal.
De patch zit in 1.7.0.2. Deze is ook op te lossen in het ZEND framework.
tipje, Vergeet niet de backup anders kost het je nogmaals 5 minuten
Jup, 5 minuten. Heb 'm zelf ook gedaan. Draai je Magento, dan neem je toch een degelijke hosting. SSH vind ik daarbij dan wel een must have. Het forum van Magento , daar valt ook geen nuttige informatie te vinden overigens. Dat die mensen problemen met Magento ondervinden is pure onkunde.
Backup? Gewoon even reverse patchen. Dat is het voordeel van een minimale patch: het risico blijft beperkt 
Bij wordpress bv heb ik gemerkt dat een betere beveiliging zit in de manier waarop je de cms installeerd. Het probleem wat ik heb namelijk met dit soort software is dat alles op dezelfde wijze geinstalleerd word qua structuur.
Wordpress heeft bv altijd /wp_admin om in te loggen. Waarom maken ze niet een variabel aan waar je zelf kan aangeven waar de admin login komt te staan in de software.
Ik probeer juist wordpress versie onafhankelijk een aantal zaken anders te doen bij de installatie :
- Installatie database prefix wp_ verander ik naar iets anders VOOR dat ik ga installeren
- Admin user verwijderen en een nieuwe admin gebruik aanmaken
- .htacces bestand toevoegen die verhinderd dat men bij de configuratie file van wp kan.
- Ook in .htacces een regel toevoegen waarbij de .htacces niet benaderd kan worden.
Mocht men dan via een plugin of een onbekende hack binnen dringen dan maak ik het ze in ieder geval zo moeilijk mogelijk.
Maar het is gewoon de pest met dit soort software.
Wordpress heeft bv altijd /wp_admin om in te loggen. Waarom maken ze niet een variabel aan waar je zelf kan aangeven waar de admin login komt te staan in de software.
Ik probeer juist wordpress versie onafhankelijk een aantal zaken anders te doen bij de installatie :
- Installatie database prefix wp_ verander ik naar iets anders VOOR dat ik ga installeren
- Admin user verwijderen en een nieuwe admin gebruik aanmaken
- .htacces bestand toevoegen die verhinderd dat men bij de configuratie file van wp kan.
- Ook in .htacces een regel toevoegen waarbij de .htacces niet benaderd kan worden.
Mocht men dan via een plugin of een onbekende hack binnen dringen dan maak ik het ze in ieder geval zo moeilijk mogelijk.
Maar het is gewoon de pest met dit soort software.
Een .htaccess bestand kan nooit via http benaderd worden.- Ook in .htacces een regel toevoegen waarbij de .htacces niet benaderd kan worden.
... Of je hebt een wel heel slechte Apache HTTP configuratie wil dat mogelijk zijn[...]
Een .htaccess bestand kan nooit via http benaderd worden.
.ht* is een uitzondering op het indexen/lezen in de Apache configuratie. En er zijn een paar rare configs out there!
Hmm, kan het in moderne config files niet terugvinden. Ik weet dat vroeger in XAMPP zag staan.
Hmm, kan het in moderne config files niet terugvinden. Ik weet dat vroeger in XAMPP zag staan.
[Reactie gewijzigd door Redsandro op dinsdag 14 augustus 2012 21:25]
Dit stop ik in mijn .htaccess
<files wp-config.php>
order allow,deny
deny from all
</files>
<Files .htaccess>
order allow,deny
deny from all
</Files>
http://www.securityorb.co...g-php-file-htaccess-file/
<files wp-config.php>
order allow,deny
deny from all
</files>
<Files .htaccess>
order allow,deny
deny from all
</Files>
http://www.securityorb.co...g-php-file-htaccess-file/
Zo goed als alles wat je noemt is security through obscurity, waarmee je in de praktijk niets veiliger maakt en jezelf alleen maar met extra werk opzadelt. De zin van dingen als de tabelnamen veranderen zie ik eigenlijk al helemaal niet....
In sommige gevallen kan dat bij Open Source waar bekende security gaten in zitten net het verschil betekenen tusssen gehacked worden en niet. Natuurlijk zal het een gerichte aanval niet afslaan, maar hoe vaak zie je niet in de server logs voorbij komen dat alle versies van phpMyAdmin worden gecontroleerd? Kleine moeite om hem op een andere URL te zetten en groot plezier als je daardoor niet ooit het slachtoffer wordt van een automatische hack.
Jij hebt werkelijk geen enkel idee wat met security door obscurity wordt bedoeld...
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
