Tag Archives: David Bisson

Rasputin Hacker Uses SQLi to Hack 60 Universities and Government Agencies

25 March 2017

SQL injection is one of the oldest, most used and best understood attack vectors. The solution (input sanitizing) is also well understood, but still lots of systems vulnerable to SQL injection are operated on the internet. And the cybercriminal Rasputin is obviously a genius in detecting such systems.

In his post “Rasputin Hacker Uses SQLi to Hack 60 Universities and Government Agencies“, David Bisson provides some insight into the problem and why organizations are struggling with the solution:

“The evidence suggests economics play a role in causation for this troubling trend. The problem and solution are well understood, but solutions may require expensive projects to improve or replace vulnerable systems. These projects are often postponed until time and/or budget is available, until it’s too late to prevent SQLi victimization.

As always, it’s a lack of budget and resources. But especially in the case of university web sites I find this really difficult to understand.

Computer science students can work on this issues in seminars and projects after the basic database and web programming courses. Even the project management can be done by students. Only few expensive professionals are required to coordinate the activities with the universities IT department.

If one starts with the web pages where user input is requested, the major problems can be solved in short or medium term. In addition, students will get very valuable insights into real cyber security issues and how to solve them.

Have a good weekend.

Malware in SQL – Really new?

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.