Waarom vindt mijn malware-scan de skimmer niet?

Veel scanners kijken alleen naar bestanden. Een skimmer in de database, bijvoorbeeld in coreconfigdata of een CMS-block, is geen bestand en valt daarbuiten. Controleer de database dus apart.

Waar zit de skimmer meestal in Magento?

Vaak in de configuratiepaden design/head/includes en design/footer/absolutefooter, in CMS-blocks en -pagina's, of in e-mailtemplates. Controleer ook admin-gebruikers en cron-taken.

Kan ik de besmette waarde gewoon verwijderen?

Ja, maar maak eerst een back-up en noteer wat er stond. Zoek daarna de ingang. Zonder dat staat de code snel weer terug. Leeg ook de cache en CDN-cache.

Hoe merk ik dat er een skimmer actief is?

Open de betaalpagina met de browser developer tools en kijk op het tabblad Network naar requests naar onbekende domeinen. Veel skimmers sturen data weg tijdens het invullen of het plaatsen van de bestelling. Monitoring van wijzigingen helpt vroeg waarschuwen.

Helpt een Content Security Policy tegen database-skimmers?

Het helpt het effect te beperken, omdat de browser verbindingen naar niet-toegestane domeinen blokkeert. Het voorkomt niet dat de code in de database komt. Combineer het met toegangsbeheer, patchen en monitoring. Vermoed je een skimmer of wil je dat we je database en betaalpagina doorlopen? Neem direct contact op, dan kijkt het team dat ook het onderzoek doet meteen mee. Zie ook /security/magento.

Skimmer in de database: verborgen code in Magento CMS-blocks

Je hebt alle bestanden gescand en alles is schoon. Toch stuurt je checkout kaartgegevens weg. Dan zit de skimmer waarschijnlijk in je database.

Een bestandsscan kijkt naar PHP en JavaScript op schijf. Maar Magento slaat veel content en instellingen in de database op, en die wordt gewoon in je pagina's gerenderd. Aanvallers weten dat. Wie code in de database zet, ontloopt elke tool die alleen bestanden controleert.

Waarom file-scans niet genoeg zijn

Een bestandsscanner zoekt naar bekende patronen in bestanden. Een skimmer in de database is voor hem onzichtbaar, om drie redenen.

Er is geen bestand. De code is een tekstwaarde in een tabel. Een scanner op het bestandssysteem komt er niet.
Het is legitiem gebruik van een functie. Magento staat HTML en scripts in CMS-blocks en configuratie toe. Dat is een feature, geen bug.
Het overleeft een schoonmaak. Je verwijdert alle verdachte bestanden en deployt opnieuw, maar de code in de database blijft staan. Dan werkt de skimmer gewoon door.

Dat laatste is de reden dat we na een incident altijd de database nalopen. Zonder die stap ruim je het symptoom op en blijft de besmetting. Zie ook Magento 2 gehackt: wat nu?.

Hoe komt code in de database?

Er zijn grofweg twee routes.

Via de admin. Een aanvaller met een gestolen admin-account zet code in een CMS-block of de configuratie. Dit is simpel en vraagt geen exploit. Zie admin beveiligen.
Via een kwetsbaarheid. Een lek in Magento of een extensie geeft schrijftoegang tot de database of tot het aanmaken van content, zonder dat de aanvaller een admin-wachtwoord heeft. De bekende lekken in onze lijst van grote Magento-lekken zijn voorbeelden van hoe een aanvaller ver kan komen.

Welke route is gebruikt, bepaalt wat je daarna dicht moet zetten. Alleen de code verwijderen is niet genoeg als de ingang openblijft.

Waar in de database zit het?

Dit zijn de plekken waar wij standaard kijken. De volgorde is die van de kans dat we iets vinden.

core_config_data

Deze tabel bevat de configuratie van de shop. Enkele paden zijn bijzonder interessant voor aanvallers, omdat de waarde direct in elke pagina wordt gerenderd:

design/head/includes: extra code in de van elke pagina.
design/footer/absolute_footer: extra code onderaan elke pagina.
design/head/scripts: scripts in de head, afhankelijk van de versie en configuratie.

Vooral design/head/includes en design/footer/absolute_footer zien we terug. Ze staan op elk scope-niveau (default, website, store view) opgeslagen, dus kijk naar alle scopes.

cms_block en cms_page

CMS-blocks en -pagina's mogen HTML bevatten, dus ook