Webwinkels gehackt via zeroday-lekken in Magento-extensies
Cybercriminelen maken gebruik van verschillende zeroday-lekken in Magento-extensies om webwinkels te hacken en zo code te injecteren die creditcardgegevens van klanten steelt. Magento is een populair platform voor webwinkels. De afgelopen maanden zijn tal van webwinkels en bedrijven in het nieuws gekomen nadat er op de betaalpagina's creditcardskimmers waren aangetroffen die creditcardgegevens opslaan en stelen.
Het ging onder andere om Ticketmaster, British Airways en elektronicawebwinkel Newegg. In sommige gevallen hadden de criminelen directe toegang tot de gehackte website, in andere gevallen werd er gebruik gemaakt van code van derde partijen die op deze websites draaiden. Bij de aanvallen die tegen webwinkels met de kwetsbare Magento-extensies zijn gericht is de aanvalsvector steeds hetzelfde, zo stelt de Nederlandse beveiligingsonderzoeker Willem de Groot.
De aanvallers maken gebruik van een specifieke PHP-functie om hun eigen PHP-code in de website te injecteren. Op deze manier kunnen ze de database of JavaScript-bestanden aanpassen en van een creditcardskimmer voorzien. Magento heeft veel van de kwetsbare PHP-functies in de eigen code vervangen, maar dat geldt niet voor veel populaire extensies, zo stelt De Groot. Hij merkt op dat aanvallers tal van PHP Object Injection-kwetsbaarheden in een groot aantal extensies hebben gevonden en nu actief Magento-webwinkels op deze extensies controleren.
De onderzoeker heeft 20 kwetsbare extensies in kaart gebracht en adviseert webwinkels om die meteen uit te schakelen en de logbestanden op ongeautoriseerde activiteiten te controleren.
Fout. Het heeft niets met PHP zelf te maken maar met de code van de developers van deze extensies.
Fout. Het heeft niets met PHP zelf te maken maar met de code van de developers van deze extensies.
Fout. Het heeft niets met PHP zelf te maken maar met de code van de developers van deze extensies.
Dat is geen PHP functie zelf dan, maar een custom geschreven stukje PHP code.
In dit geval heeft hij wel gelijk, aangezien de functie unserialize wordt gebruikt (zoals ik later nog post) voor data wat blijkbaar niet sanitized wordt op een correcte manier, en dus een issue veroorzaakt, waardoor er data injected kan worden. Dit wordt ook duidelijk op de PHP functie aangegeven.
Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes. Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user.
If you need to unserialize externally-stored serialized data, consider using hash_hmac() for data validation. Make sure data is not modified by anyone but you.
http://php.net/manual/en/function.unserialize.php
Er wordt sowieso al afgeraden dit te gebruiken voor sommige gevallen.
Fout. Het heeft niets met PHP zelf te maken maar met de code van de developers van deze extensies.
De functie heet unserialize() en de documentatie geeft duidelijk weer (in het rode kadertje) dat hij gevaarlijk is:
http://php.net/manual/en/function.unserialize.php
Dat is niet uniek voor PHP, er zijn andere talen die soortgelijke mogelijkheden in hun standaardbibliotheek hebben met soortgelijke waarschuwingen voor de risico's ervan, bijvoorbeeld (met ook een rood kadertje om de waarschuwing):
https://docs.python.org/3/library/pickle.html
https://www.functions-online.com/unserialize.html
Vervolgens een oude toepassing van object injection uit 2014 oude wijn in nieuwe zakken
public function tunnelAction()
{
$gaData = $this->getRequest()->getParam('ga');
$gaHash = $this->getRequest()->getParam('h');
if ($gaData && $gaHash) {
$newHash = Mage::helper('adminhtml/dashboard_data')->getChartDataHash($gaData);
if ($newHash == $gaHash) {
if ($params = unserialize(base64_decode(urldecode($ga
Het bovenstaande overgenomen uit analyse op:
https://websec.wordpress.com/2014/12/08/magento-1-9-0-1-poi/
Voortborduren derhalve van Willem de G. dus op bekende thema's dus, niets nieuws onder de zon,
Maar blijft actueel en hij krijgt er wel een patform voor. PHP coders zijn hardleers.
'luntrus
https://www.smashingmagazine.com/2018/01/php-wordpress-functions-site-insecure/
In feite ligt hier ook een terrein voor een hoster, die de website admin met onvoldoende kennis om zijn of haar site veilig te houden, kan bijstaan. Te veel en te vaak gaat het fout uiteindelijk ook ten koste van de bezoekers van een dergelijke website.
Dus het probleem met onveilige PHP functies is veel breder dan alleen bij Magent> Het geldt voor alle op PHP gebaseerde CMS. Word Press met name vereist niet het gebruik van de nieuwste PHP versie.
Steeds meer werkt men met PHP-cheatsheets.
Fout. Het heeft niets met PHP zelf te maken maar met de code van de developers van deze extensies.
De functie heet unserialize() en de documentatie geeft duidelijk weer (in het rode kadertje) dat hij gevaarlijk is:
http://php.net/manual/en/function.unserialize.php
Dat is niet uniek voor PHP, er zijn andere talen die soortgelijke mogelijkheden in hun standaardbibliotheek hebben met soortgelijke waarschuwingen voor de risico's ervan, bijvoorbeeld (met ook een rood kadertje om de waarschuwing):
https://docs.python.org/3/library/pickle.html
Dat had ik al gepost.
Aangezien ik geen Wordpress gebruik (en zoveel mogelijk links laat liggen), houdt ik het liever op Symfony frameworks.
Gewoon de juist functies gebruiken, dan zit je over het algemeen goed.
Het is jammer dat veel developers geen rekening houden met side-effects, of sanitizing correct toepassen.
Unserialize is prima voor data waarvan je altijd 100% kunt uitgaan dat het geen troep kan bevatten.
Als je met data omgaat wat je niet 100% kunt verifieren, nooit functies gebruiken die dit kunnen executen, zoals je bij veel exploit PHP scripts ziet die base64 ook toepassen.
Dat had ik al gepost.
Aangezien ik geen Wordpress gebruik (en zoveel mogelijk links laat liggen), houdt ik het liever op Symfony frameworks.
Gewoon de juist functies gebruiken, dan zit je over het algemeen goed.
Dan kom je bij Drupal uit (als je de content management systems lijn doortrekt vanuit Wordpress). Of Typo3. Of Joomla!. Of October CMS. Of https://symfony.com/projects/category/cms.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
