Tag Archives: Oracle database

Anthem hacked – 80 Million data sets lost

11 February 2015

This was a really long winter break. The Sony hack is all water under the bridge now. The hackers have gone back to work, with a bang. 80 Million data sets lost. Anthem was hit particularly hard, and Anthem’s customers are hit by a wave of phishing emails.

The main question is always: How could it happen? And, what can be done to prevent such thefts in the future?

I found an interesting statement in a report published 2/4/2015 by Steve Ragan at CSO-Online:

“On January 27, 2015, an Anthem associate, a database administrator, discovered suspicious activity – a database query running using the associate’s logon information. He had not initiated the query and immediately stopped the query and alerted Anthem’s Information Security department. It was also discovered the logon information for additional database administrators had been compromised.”

This makes it clear: The attackers got access to at least the database login information of some database administrators. In addition, they had to steal some at least standard user credentials for access to company computers. This is required to start the database queries. The rest is easy!

Remind: Attackers can read in company networks like in an open book.

Once they got access to some computers, social engineering could be used to find information about the business critical databases. With an e.g. Oracle client and Microsoft Access as front end, they are able to read all data, even if the database is fully encrypted. In the case of an SQL-Server backend you do not even need a database client software installed because the ODBC driver is part of the Office installation.

The big problem is that any company workstation could be used to launch a query. Even if e.g. an Oracle client is not installed, an instant client, which could be installed by the user, is absolutely enough for access to the business critical data.

The attack surface is enormous. But it’s easy to shrink it. Most database providers offer whitelisting technologies to restrict access from computers to the database server. In the best case, only some application servers, backup systems and admin workstations must have access to the database. Include only this systems in the white list, and exclude all other computers in the black list. That’s it.

For Oracle, parameter TCP.INVITED_NODES specifies the white list, TCP.EXCLUDED_NODES the black list in the SQLNET.ora configuration file.

The only question remaining is: How could the attackers get access to the login credentials of the database admins and the standard users? Unfortunately I haven’t found any hints so far…

That’s it for today.

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.