Tag Archives: Separation of Duties

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.

Advertisements

How to Mitigate the Risk of Cyber Attacks? The Principle of Least Privilege shows the Direction!

21 March 2015

Lysa Myers writes in ‘Premera Breach: Healthcare businesses in the crosshairs‘, published on 18 March 2015 in welivesecurity.com about ‘five things businesses should be doing to help decrease risk and mitigate damage in case of a breach.’

I find it most remarkable that one of her recommendations is to enforce the Principle of Least Privilege in daily business. In my opinion this is the right step in the right direction.

Enforce the principle of least privilege across the entire IT infrastructure and application stack and you will gain back control.

For example, access to the company network should be granted only to those people who need this to do their job. In addition, access should only be possible during standard working hours, and, in the best case, from a single computer at a time.

This will prevent attackers from accessing the company network outside the working hours and from using an account during working hours from another computer.

From this example it becomes clear that to enforce the Principle of Least Privilege changes have to be applied to all sides (People, Processes and Technology) of the Golden Triangle of IT security.

In addition, the principle of Separation of Duties should be enforced for access to business critical information. In any case, access to critical information should be approved by the information owner. In the best case, access should only be possible if the information owner and the employee are logged in at the same time in the application system.

Enjoy Lysa’s post, and have a good weekend.

Anthem Hacked – The call for ‘More of Everything’ grows louder

19 February 2015

Just some thoughts about the call for more technology, encryption, pen testing, etc.

The big question is: Would database encryption have slowed down or stopped the attackers? From my experience with Transparent Data Encryption (TDE) in the Oracle universe I can only answer: Definitely Not!

If it’s properly set up TDE works very well to prevent unauthorized access to data in rest. Administrators and users are not able to read or copy database files when e.g. the database is shut down.

But as long as the database is started TDE works transparent for all users and the administrators: They can access the data with applications or SQL tools without any restriction.

If you like to keep the administrators away from the data you must set up Oracle Database Vault on top of TDE. Database Vault acts as a firewall between the users and the administrators. Administrators can run their administrative tasks, but they could no longer access the data. In addition, the Separation of Duties principle is enforced for security critical operations like definition of users.

But what’s about malicious insiders? Malicious insiders are responsible for about two-third of all attacks, but neither TDE nor Vault would stop them from accessing all data. With Label Security a fine-grain access control system is available that gives data admins the opportunity to restrict a user to individual data sets in a table.

Sounds like rocket science, doesn’t it? Far from it. Most of this products are for several years in the market, but they are widely unknown, and, the effort for implementation is high.

That’s it for today.

For further reading please see

Anthem Cyber Hack: 5 Fast Facts You Need to Know

Anthem Breach Should Convince Healthcare To Double Down On Security

Anthem Breach Prompts New York To Conduct Cybersecurity Reviews Of All Insurers

Isolated security measures make no sense!

27 November 2014

In the past days I did lots of application protection planning with Oracle databases as backend.

Oracle SQL*Net encryption is an easy to implement measure for protection of the network traffic against sniffing attacks in a standard client-server application with an Oracle database as backend.

Why is encryption of the Oracle network traffic such important? Because everyone who can edit the sqlnet.ora configuration file is able to set up Oracle network tracing by adding just some configuration parameters.

With tracing enabled the entire session traffic, e.g. a change password command like

Alter user system identified by ",v$1ry c2mplex p$3ssword!";

is logged in plain text to the trace file. That’s extremely dangerous! Never change your password this way!

But the output of a standard SQL command like

 Select employeeName, employeeSocialSecNumber from employees;

will be reported in plain text as well, even if column ’employeeSocialSecNumber’ is secured with Oracle Transparent Data Encryption option. Works as designed, transparent to the user. Even if the user takes care of the data the attacker with admin privileges could easily create a copy from the trace file.

With SQL*Net encryption activated the trace is no longer readable.

SQL*Net encryption is set up by just adding some configuration parameters to the sqlnet.ora file on the clients and the server. Thus everyone who is able to edit the sqlnet.ora file on the client could potentially disable encryption…

Fortunately parameter SQLNET.ENCRYPTION_SERVER set to REQUIRED on the database server controls session behaviour. A client connection attempt with session encryption disabled will be rejected with error message ORA-12260. Great!

But all server admins are able to edit this configuration file…

What can we learn from this?

Applying isolated security measures will not raise the overall security level.

The House of Security

The House of Security. Click to enlarge.

The combination of security measures makes the difference!

Happy Thanksgiving!

The new first line of defence?

22 November 2014

In his latest post at ComputerWeekly.com Warwick Ashford reviews the CyberArk Report ‘Exploits of Privileged Accounts Shift the Front Lines of Security’. His post is absolutely worth reading.‘

‘“One of the reasons for this is smaller, less well-defended organisations have become a prime target for attackers who are ultimately aiming at larger partners in the supply chain,” said Mokady.’

That’s definitely true. Perhaps you remember the Home Depot data breach? This breach was caused by stolen credentials of a third-party vendor.

‘“Securing privileged accounts represents the new first line of defence in the ongoing cyber battle companies are fighting,” he added.’

Very well said. But what really confuses me is that Udi Mokady talks about the new first line of defense. 

The majority of the big data breaches have been caused by stolen credentials. With a Two Factor Authentication (TFA) most of this breaches could have been prevented.

It’s definitely very important to secure privileged accounts. With admin privileges it is very easy to change log settings or tamper audit records. But it is definitely not enough to secure only privileged accounts. Because even with standard user privileges you may have access to business critical data to do your job.

Let me give you an example. Oracle Transparent Data Encryption and SQL*Net encryption and integrity checking are easy to implement measures to secure an Oracle database. This will prevent man-in-middle attacks, eavesdropping of the data traffic and direct access to the database files.

Sounds pretty secure, doesn’t it? Unfortunately it isn’t. Even an unprivileged user, and even more a malicious insider with stolen credentials, is able to install an oracle instant client and use Excel and ODBC to create a copy of all data he could use with his standard user rights.

With TFA enabled, at least on all business critical systems, and for all users, the probability of such an event is dramatically reduced.

Securing accounts with TFA is the very first line of defense.

In addition you should decide about granting privileged access on a per task basis. For business critical infrastructure and applications an administrator should receive an authorization and one-time-password for just one task. At log off the authorizations are dropped. In the best case the admin group for a windows servers is empty. Only the local admin could always logon, but his password is in a safe place.

The authorization process should be implemented with strict application of the separation-of-duties principle, and the permissions should be granted with strict Application of the principle of least privilege. Important: The employees who grant authorizations and privileges should never have the possibility to grant whatever privileges to themselves.

Moreover the consistent application of the principle of least privileges even for standard users and processes will significantly reduce the attack surface of your company.

Nothing really new, just the same old story.

Glacier near by Grächen, Switzerland

Glacier near by Grächen, Switzerland

Have a good Weekend.

The Home Depot Story

13 November 2014

After two month of investigation the reason for the Home Depot data breach appears to be clear: Cyber criminals used stolen credentials from a third-party vendor to enter the Home Depot network. In a report by Mike Davin from November 7, 2014 one could read some more details: ‘The hackers then acquired elevated rights that allowed them to navigate portions of Home Depot’s network and to deploy “unique, custom-built malware” on its self-checkout systems in the U.S. and Canada.’

It’s a complete mystery to me why companies do not secure the access to business critical data with Two Factor Authentication. TFA would severely hamper such data breaches. I am not overly surprised that the attacker could acquire elevated privileges.

But what really worries me is that the attackers we able deploy software to the company’s point-of-sales devices. It is quite obvious that the software deployment process is not sufficiently secured and could be easily tampered.

From my point of view Home Depot’s IT should invest some time in threat modelling of the software deployment process to avoid such incidents in future. In particular the strict enforcement of the Separation-of-Duties principle will prevent unplanned deployment of critical Software.

Have a good day!