A partner account manager can help. Contact us today.

 Subscribe me to your mailing list

Oracle Security: Researchers’ response to the post by Oracle CSO Mary Ann Davidson

Today Mary Ann – Oracle's CSO - published an incredibly shocking post about security researchers which was promptly deleted (either by herself or somebody else). The post was discussed by multiple resources such as Forbes, CRN, The Register and others. Most of them, however, did not provide researchers' opinion. I'm not going to cover all aspects of this post as it will take years, but I would like to share with you my main pinpoints. Just today we were going to release our series of articles about Oracle security, but were interrupted by that statement and decided to write a review, so please wait until next week.

What Mary Ann did with recent publication could seriously affect our safety, the safety of the entire world. This post is discrediting all researchers and statement that Oracle doesn't need their help would likely to make researchers publish discovered vulnerabilities in the wild. After all, Oracle customers (including ourselves) will be affected. It is well known that almost every big company in the world including government and military organizations rely on Oracle products. It doesn't matter if Mary Ann is right or wrong and if she really thinks so, her blogpost puts everybody at risk! It might be the biggest mistake Oracle made in a time when new data breaches happen almost every week!

I want to comment on this situation as a researcher who helped Oracle to close 30+ vulnerabilities in their products, was in charge of independent Oracle security Research since 2007, acknowledged by Oracle 16 times, wrote a book about Oracle Database security and have published very critical vulnerability in Oracle PeopleSoft recently (and this particular vulnerability or other ones we have discovered may somehow lead Mary Ann to write her blog post).

In her missive, Davidson urges customers to leave the task of analyzing Oracle code to find security holes to Oracle itself, saying her company is "pretty good at it" and that end users who do so are breaching Ts and Cs in their licenses designed to protect its "highly valuable" intellectual property.

As the blog post was rather provocative, so my response will be frank and even rude, but it was Mary Ann who set the tone for the discussion.

Here are some thoughts about Mary Ann's post which she decided to delete, but the copy is available here

1) Oracle is "pretty good at it"

Despite my great respect for Oracle, I have been discovering vulnerabilities in Oracle applications since 2007, with 30+ issues in Oracle applications found only by myself, and our team found probably twice more in total. And it was not a big deal, seriously. It was one of the first systems to me as an intern pentester to break into. It was very easy to find those vulnerabilities, as easy as hacking websites. You can't imagine that top vendor can make those simple mistakes and more importantly can act like that.

Do you think that you need to have advanced reverse engineering skills or be a nerd from the Mr. Robot series to find a vulnerability? Frankly speaking, no, you don't. It's much easier than you may imagine. For most issues I've found I did not use any reverse engineering tools and just tried to enter data in fields where nobody expected this type of data. Simple? Yes! And that works! What does it mean? It means that to find most of the vulnerabilities in Oracle products (and there are almost 4000 of them according to OSVDB, by the way) you don't need to be a hacker, you just need to have good testing skills. In scientific terms, it is a boundary testing, and if such types of tests are failed, it means even worse than a software with vulnerabilities. It's a software without proper Quality Assurance! Ok, big vendor, if you don't care about cybersecurity, is QA also unimportant?

2) Licenses designed to protect its "highly valuable" intellectual property.

Well, for most of the vulnerabilities we identified there is no need for any reverse engineering at all. This is how security research works. Some company hires us for pentesting. We carry out a test and find a series of critical issues, by simply checking if software properly responds to our actions or by checking if some parameters are configured in a secure way. Do we need to reverse-engineer a system if there is a user with default password or if we identified webservice which can provide unauthorized access to OS without authentication? And there are dozens of those examples, just look at the Alexey's Oracle Peoplesoft Applications are under Attack.

3) 'I do not need you to analyze the code since we already do that, it's our job to do that, we are pretty good at it, we can – unlike a third party or a tool – actually analyze the code to determine what's happening'

On the one hand, I can agree with the fact that it is a vendor's responsibility and we should not try to help them if they don't want, but it's not so easy. It doesn't matter until it doesn't affect us and our lives. Oracle applications are used in many mission–critical systems. If we identify some issues what can we do to help our customers and Oracle customers? We need to make recommendations to fix it, but if it is a 0-day there is no way to fix and we need to contact a vendor to help it with fixing this issue. So what we do is helping a client to deal with vendor. A vendor who as far as we see doesn't care about its customers at all. Just an example, what vulnerability have we found recently? Just an example, what vulnerability have we found recently? It was a vulnerability in Oracle PeopleSoft system, which can put hundreds of enterprises, government institutions, and universities at risk.It takes not more than a day to decrypt insecure Token generated by Oracle PeopleSoft using outdated hash function sha-1. Any bruteforcing program on latest GPU that costs about $500 can make it. 500$ for access to Fortune 500 companies data, great deal.

Do you know how many Government companies use Oracle systems? Almost every. If we would not find this issue and would not help Oracle to fix it, this issue will be found by someone else. And we shall see a headline about next OPM-like breach. Do you really want this to happen? Do you really want to have your relatives' and friends' information, all your credit cards, all your personal history exposed to cybercriminals? I don't. So, when Mary telling it is not our responsibility, I can say it is everybody's responsibility to protect companies and country from cyberattacks by making systems secure.

4) ERP systems security and SAP VS Oracle

I agree with Bob Tarzey's, Quocirca's analyst, statement , "ERP systems are of a great importance nowadays". Oracle is not just a vendor, it's the vendor which software is installed in almost every Fortune 2000 company, and our lives depend on their solutions' security. Nuclear power plants, manufacturing, banking - name anything and you will find either Oracle or SAP or both systems, which manage mission-critical processes. When this kind of vendor is telling that they don't need any help from external researchers, in terms of vulnerability findings, well, this world is too dangerous. There is only one vendor, which cubersecurity is on the same level of importance as this vendor is providing mission-critical systems such as ERP's and so on - SAP. And situations when vendor has not patched a vulnerability within more than 3 years is a nonsense, even taking into account that vulnerability was not very critical. The same situation was with Oracle JDE architecture vulnerability.

If we compare what SAP is doing in this area, their actions are smarter. In 2007 I could say that Oracle was more open to researchers and had an acknowledgements page while SAP didn't even have an email to report about identified issues. SAP took many steps to improve it, but however still has too many vulnerabilities (according to our "SAP Security In Figures" guide). But what's more important, SAP put their customers as well as we do at the highest priority and would never say something like Mary Ann did.