Pete Finnigan's Oracle Security Weblog

I have not had chance to write any detailed blogs of late as we have been very busy with paying work and also working on our software products as we released version 2025 of PFCLScan and version 2026 is very close to release also with improvements, features and more being added. As usual I do have a back log of blogs that I would like to write and release to the website. I have am internal software called PFCLSocial that I created that allows me to draft and collect blogs as I get chance to write them or spend a few minutes so that they are stored and collected in a safe place on the desktop and not online until published.

Last December I gave a presentation at the UKOUG conference in the East Side Rooms in Birmingham. This was a great conference and I feel the UKOUG conference is improving year on year. It was great to meet and chat to so many people and to give two talks.

My first talk was "Fuzzing PL/SQL" and I wanted to focus here on a different method of testing PL/SQL for security issues that is more akin to what an attacker may do to exploit your PL/SQL code. If we take a simpler (well maybe not simpler in reality but...) example of an attacker exploiting a website; they may use a tool or by had try lots and lots of URLs and different parameters and try and guess pages of the website by name and particularly look for hidden pages or authenticated pages or look for know exploits in the frame work used such as Wordpress. In the web world there are many tools that can fire thousands of requests against a website to try and find exploits in it. Also in the network security world there are tools such as "Spike" that target network listeners like the Oracle database listener to look for vulnerabilities in general to "overflow" the listener code and gain access to the Oracle or root account.

In the PL/SQL world at a simplistic level the idea is to find all the input interfaces to your PL/SQL and to run every interface many times with many types of input in an attempt to do a similar idea as "spike" or "Burpsuite" in the web world. The idea is to run each PL/SQL procedure or function and pass a lot of random (or not so random) input in an attempt to get it to fall over and find vulnerabilities. This is the idea and it is live "blind" testing in contrast to static code analysis that would normally be done.

There is one issue to raise now before you look at my slides. This is a destructive type of testing and should not be done on a production system. It is obvious, if you pass random input to every procedure and function it is bound to corrupt the database. So only use methods like this if its a test system that can be replaced.

There is a second more subtle problem. Because we are blind testing we cannot guarantee code coverage to get to all issues. This is because you may need to input one value to cause the code to do x, y or z and then within Z we need another value to get to the vulnerability.

This fuzzing method can be used along side static analysis to replicate what an attacker may do.

The slides are on my website on the Fuzzing PL/SQL Page.

#oracleace #sym_42 #oracle #security #plsql #code #vulnerabilities #vulerability #hacking #fuzzing #blindtesting