It’s hard to believe that another year has passed from last RSA. But, indeed, time flies when you’re busy, I guess.

So, for the second year in a row, McAfee wins the SC magazine award for best database security solution. I’m so proud!

I was interviewed for a nice article about database security on Dark Reading. The interesting question, I think, is not wether to invest in DB security. To me, it’s a given that you have to do it (even though some customers still don’t agree). The question is – how will the threat landscape change if everyone went ahead and deployed DB security protection – activity monitoring, vulnerability assessment, encryption where possible, etc.

If you were a hacker, what would you do?

I have to say that I don’t believe in silver bullets and perfect tools so whatever the enterprise deploys, it will have holes. But, as a hacker, knowing that there is constant monitoring and prevention on every access to the database, I’d probably be very careful and maybe take a different route to the data (file servers, end-point machines, …).

What do you think?

Joxean Koret, a hacker we’ve worked with in the past, has just released a 0day following Oracle’s April 2012 CPU. As far as I understand, Joxean believed that the CPU fixed the issue as his name was mentioned and this was the feedback he got from both Oracle and the company he sold the hack to.

But, to his surprise, it turns out that Oracle did not really fix the issue. Oracle’s response was that the issue will be fixed in the next version. This is really confusing because Oracle’s customers expect the CPU to mention only fixed vulnerabilities.

All in all, a very solid work by Joxean!

UPDATE: official word from Oracle

After OEMing our products for 6 months, it seems McAfee agrees that we are doing something important and they want a bigger part of it.  Actually, they want all of it.

As a founder, this is an exciting time for me. It’s a mixed feeling of pride, joy and a bit of sadness. Somewhat similar to your baby leaving home for college (I’d imagine, did not experience it yet). We’ve put huge amounts of time and effort into making what we think is a great product that will help a lot of people.  Now we have the opportunity not only to bring database activity monitoring to more people, but to make the product even better.

I’d like to thank the wonderful Sentrigo employees who made this a reality due to their hard work and dedication. We will continue and build bigger, better solutions for database security!

On a personal note, at least my commute will not change. I can see the McAfee building from my office window just across 101 🙂

This is just too funny – the site owner is accusing the guys that reported the vulnerability of extortion. More details can be found here and here.

And it all started with a simple SQL Injection that can be exploited through the site error messages. I talked about this multiple times in the past.

Of course, the passwords were in clear text and multiple messages from site members to use hashing and not email passwords to users were deleted from the site’s forum.

We just found out that Sentrigo was nominated for a Community Choice Award from SQL Server Magazine, as the

Best Security / Auditing / Compliance Product

Of course, if it was based only on the strength of the product, there’s no question we would win 🙂
But, since it will be decided based on open voting from the internet, I’d like to ask for your help:
Please go to the link below, and


Just follow this link:

And choose Sentrigo Hedgehog Enterprise for item #6
(you may of course vote for any other categories as well…)

We had a great time at the SC magazine awards dinner on Tuesday. We were finalists in the “best SME security solution” category but unfortunately we did not win.

Here is Andy, our VP marketing before the dinner and announcements:

And here he is after some wine and us not winning:

As another year comes to a close, it’s time for both new year’s resolutions as well as predictions.

On the resolutions front, I hope to be much more active on my blog next year.  As we grow as a company, I seem to have less time for my musings, as I spend more time with customers and those we hope will become customers.  Overall, it’s a good problem to have…

As far as predictions go, this is always dangerous ground.  A year from now, someone will undoubtedly come back and point out that I really missed some major new trend, or called one that never came to be.  But, these are simply best guesses based on what I’m seeing out there, and I’d be happy to hear from those who have additional trends of their own. You can also read all about it here and here.

Hackers are getting better tools

This one will increase the frequency of attacks, based on several factors:

  • Automation will let good hackers move faster
  • Less skilled hackers will now be able to use more sophisticated attacks
  • Lesser known sites will see more “random” attacks as the tools look for vulnerabilities instead of the hackers targeting specific companies and finding a way in

More attacks will be based on outsiders turned insider

As the perimeter defenses become better, most companies have continued to neglect the risk of the privileged insider.  So, the easy money may go to alternative approaches to getting insider access.  Bribery and even extortion come to mind, but so does getting hired as a consultant or even an employee, mainly to get at the data.

I also put drive-by malware attacks in this category, as the unsuspecting user simply browsing a site lets malware in that attacks from the inside.

Organizations will focus on minimizing surface area of attack

The less content you have, the easier it is to lock it down.  Just as the e-Discovery era brought about email retention policies, we’re beginning to see people deleting sensitive records as soon as they are no longer needed, reducing the information at risk.  At the same time, tools like tokenization will limit the number of databases with actual information to just one, while apps only store pointers.  By securing the one live repository (I’d recommend Sentrigo for this of course!), you’re now protected.

Databases finally make it to the cloud

There’s been much noise about the cloud, but so far I haven’t seen many customers putting business critical apps, with sensitive data, in the cloud.  One reason has certainly been concern about data security (and compliance).  With solutions like Hedgehog, you can deploy a small sensor that gets installed whenever and wherever the cloud provider puts your database, and it is just as secure as in your own datacenter.  And you can monitor the admins at the provider as well.  As companies get comfortable with these technologies, critical databases will move to the cloud.

Compliance will remain a “bare minimum” effort

Not so much a new trend, but I expect in the continuing difficult economy, we will still see most companies investing the least amount possible to comply with regulations, rather than taking an approach of what they consider best practices to secure data.  Thus, we’ll still see breaches of “compliant” companies, and as a result there will be pressure on auditors to enforce more strictly, and pressure on regulators to update standards to fill commonly exploited gaps.  To stay on top of this, flexibility will be required.

So, here they are. I’d love to hear your thoughts…

A member of Sentrigos’ security and research team, Assaf Nativ, found an interesting security issue in all versions of MS SQL Server. Turns out that SQL Server saves in memory in clear text user credentials (passwords) of users logging in using SQL Server native authentication. Users using Windows authentication are not affected. Although Microsoft recommends that only Windows authentication should be used, the reality is that many instances are configured to use mixed mode authentication with applications and administrators connecting to the instance using native authentication.

We, of course, reported this to MSRC about a year ago but received a response saying that this is not a security issue because it requires administrative privileges to exploit. Well, we respectfully disagreed and approached MSRC several times but without success in changing their mind.

I believe that this is indeed a security flaw that should be fixed for the following reasons:

  • How many passwords do you use? For how many systems? You do the math 🙂 – most users reuse the same passwords between systems because it’s impossible to remember a separate strong password for all systems we use. Even administrators should not have access to end users’ set of passwords, as they can gain access to sensitive systems that were not open to them.
  • Most breaches are perpetrated by skilled insiders (e.g. administrators, programmers, etc). It is for this very reason that various standards and regulations mandate segregation of duties.
  • Many applications are deployed with administrative privileges. Hackers using a single SQL injection vulnerability can now access administrative passwords which may be used to penetrate other systems on the network, escalating the breach. This is even worse in the case of SQL Server 2000 and 2005 where this can be done remotely.

We, at Sentrigo, were convinced that SQL Server administrators out there should be aware of the danger and also should have a way to mitigate it so we’ve decided to publicize it and release a free tool to remove the clear text passwords from memory.

What do you think about this issue? I’d love to hear your thoughts.

Recently, I read a very interesting paper by Alexandr Polyakov talking about how an unprivileged user can get OS access to the database machine by stealing NTLM challenge-response authentication strings.
I really liked the way it was written and the fact that it uses automated metasploit plug-ins that will try to evade detection by using obfuscation techniques.

Since the paper mentioned Hedgehog, I took it as a challenge to protect against such an attack :-). One obvious solution is to monitor the CREATE INDEX with INDEXTYPE of ctxsys.context. The way Hedgehog monitors transactional information, using evasion techniques like base64, translate, etc. is not effective as we read the command directly from the memory when it’s being parsed.

The rule I’ve created is – “cmdtype = ‘create index’ and statement contains ‘ctxsys.context'”. Now, although this is a somewhat simplistic version of the rule, I believe it will still be effective. One other option is to catch ‘create index’ with accessed objects including ODCI stuff. Next, I’m going to try this with metasploit.

Here is the screenshot of the rule:

Hedgehog CTXSYS rule

Hedgehog CTXSYS rule

Running the clear text version of the attack produces the following:

Alert on ctxsys index

Alert on ctxsys index

Any other ideas out there?

Next Page »