18 February 2017

In post ‘Magento stores targeted by self-healing malware that steals credit card details‘, published by David Bisson on 18 February 2017 at Graham Cluleys’s newsletter, I found the really astonishing statement from Willem de Groot:

This is the first time I see malware written in SQL.

What happened? To put is briefly, someone found a vulnerability in Magento-powered online stores. He guessed the web shop’s administrator password. With this, he managed to get the database schema user’s username and password, connected to the database and added an after-insert trigger to the sales_flat_order table. The after-insert triggers adds code to the web page which sends customer credit card details to the attackers C&C server.

To be honest, there’s nothing new here.

As in 90% of all data breaches, a vulnerability known for some month was used to get administrative access to the shop software. For details please see post ‘10 tricks to improve Magento admin security‘.

But this must not necessarily end in a data breach. The issue here is, that the admin user was used to get privileged access to the database. This kind of trouble can be easily avoided by strict separation of duties inside the database. Only the database schema owner should have the privileges to change the database schema, i.e. add a trigger to a table. All other database users should have the privilege to access data sets only. And the web shop software administrator should have no access to database content at all. That’s plainly long known database design best practice.

In general, database application designers spend a lot of time ensuring data integrity. Data integrity was not violated here. In this case, we encounter code integrity issues, which result in the loss of confidentiality.

Separation of duties is the standard means for mitigation of this kind of issues. In addition, we should consider adding code integrity checks to ensure code integrity at runtime.

Have a good weekend.