There are two main high level threats; the first that an attacker wants to steal your data and the second that he chooses the Oracle database as an easy target to then catapult himself into the rest of your IT infrastructure.
We start our audits at a theoretical level by asking questions. We gather details of the architecture of the data/database and understand how it fits into the whole organisation focusing on how data flows and also identifying all major processes and jobs that access the database directly. We then conduct an interview with key people to gather details on aspects of the Oracle database security that cannot be tested technically or where we want to also understand the organisations position on some aspect of data security but where we can test it technically to confirm or deny what the customer happening. We use PFCLScan, our database security scanner for Oracle. This tool can be used to conduct interviews as well as to scan a database for vulnerabilities. We then scan the database and the operating system with PFCLScan to produce a detailed scan and report of the technical settings and OS and listener settings of the database. Based on what the scanner finds a detailed audit then consists of hands on investigations using many of our PL/SQL based tools to dig further into specific areas of the particular databases security.
All of these techniques and the tools are covered in my two day class - How to perform a security audit of an Oracle database which I teach regularly. The next public class starts on Monday on UK hours over webex and there is still time to register if you would like to attend - see the public training dates page for details.
I will be adding more public Oracle security training dates next week including a class in Athens, Greece later in the year with Oracle and I am also planning to run a class here in York again as these have been very successful in the past. The proposed class in York will be three days, including my two days how to perform a security audit of an Oracle database and also my one day class securing and locking down Oracle. I will also be adding new online dates via webex.com for all of my Oracle Security classes. I will announce towards the end of next week when all of the new training dates are live along with how to register.
Just over a week ago we released a new 1.9 version of PFCLScan; This included a lot of changes, new checks, new reports, bug fixes from raised tickets and a new E-Business Suite project template. All customers who are licensed are now in possession of version 1.9. If anyone is interested to see a demo we will be happy to arrange and do that over webex. Our licenses are very good value allowing anyone to perform a security audit of an Oracle database.
We are now in the process of finalising the plan for what will be in the next major release of PFCLScan, which will be 2.0, later this year in the autumn.
At this stage (none is this is 100% finalised yet but its close) we will include the plugins feature as we need to have these to support some new features planned. There will be new features (improved cracker, ability to customise more elements) and new tools (port scanner, code analyser, log file analysers..). There will be a lot of new checks, the E-Business Suite project will be expanded, an APEX project added, a health check project added and possibly some others as well. We will add new reports, we will add CVE based checks. We will also fix more bugs reported by customers. Any much more.
One of the key elements of the design of PFCLScan from the start was its ability to be flexible and run checks in different languages / types such as SQL, PL/SQL, Shell, SFTP, Lua, Internal and much more. Also the checks can be (and indeed are in our shipped policy sets) interlinked to provide power and flexibility. This means that the results of one check can be fed into further checks ad-infinitum and these checks can be across languages / types such as the results of a SQL check feeds into an OS type check written in Shell script. Part of this flexibility are the tools / engines we provide as part of PFCLScan. One new tool just developed for Version 2.0 is a new port scanner. We have written this tool to allow external ports to be scanned (and found) on a database server and then assessed as to why they are exposed externally as part of the audit. As we are conducting an audit and can also connect via ssh to the server we can also see all ports that are listening which are shown to be external via the internal netstat command. Here is an example for my Linux server running Oracle 12.1.0.2:
[root@ol65 ~]# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:36957 0.0.0.0:* LISTEN 1771/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1726/rpcbind
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2080/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1833/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2160/master
tcp 0 0 :::62554 :::* LISTEN 6273/ora_d000_orcl
tcp 0 0 :::5500 :::* LISTEN 5253/tnslsnr
tcp 0 0 :::59972 :::* LISTEN 1771/rpc.statd
tcp 0 0 :::111 :::* LISTEN 1726/rpcbind
tcp 0 0 :::1521 :::* LISTEN 5253/tnslsnr
tcp 0 0 :::22 :::* LISTEN 2080/sshd
tcp 0 0 ::1:631 :::* LISTEN 1833/cupsd
tcp 0 0 ::1:25 :::* LISTEN 2160/master
[root@ol65 ~]#
As you can see the lines 0.0.0.0 means that the port is "listened" for on all interfaces; the 127.0.0.1 means that they are local to the server only (ports 25 and 631) and the IPV6 syntax ::: means that these are external ports. We can see that the ports 22, 111, 1521, 5500, 59972, 36957 and 62554 should be exposed externally. We can run the new port scanner tool (part of PFCLScan) from the command line - all internal tools can be used from the command line either as part of a complete project scan or individually. Here it is:
C:\oscan\Release>ps -v -d 192.168.1.92 -f 1 -e 65535 -g 100000 -n 100
PS: Release 2.0.4.1314 - Production on Thu Jul 6 18:39:55 2017
Copyright (c) 2017 PeteFinnigan.com Limited. All rights reserved.
[2017 Jul 06 17:39:55] Listen: Starting PS...
[2017 Jul 06 17:39:55] Listen: Initialise Port Scanner
[2017 Jul 06 17:39:55] Listen: Running Port Scanner
22/tcp open
111/tcp open
1521/tcp open
5500/tcp open
36957/tcp open
62554/tcp open
[2017 Jul 06 17:41:11] Listen: Completed Port Scan
[2017 Jul 06 17:41:11] Listen: Closing Down PS
C:\oscan\Release>
As you can see 6 of the 7 ports were found; the missing one is 59972. The scan took 1 minute and 16 seconds to scan all 65536 ports. A comparison scanning the same database server with nmap shows:
...
Discovered open port 111/tcp on 192.168.1.92
Discovered open port 22/tcp on 192.168.1.92
Discovered open port 36957/tcp on 192.168.1.92
Discovered open port 1521/tcp on 192.168.1.92
Discovered open port 62554/tcp on 192.168.1.92
Discovered open port 5500/tcp on 192.168.1.92
Completed SYN Stealth Scan at 18:45, 36.55s elapsed (65535 total ports)
...
So neither nmap nor our tool ps.exe finds port 59972 listening externally even though netstat locally shows it to be listening externally. The nmap scan took 36 seconds not including its startup so overall we are not far behind the speed of nmap. So we are happy with this new tool as part of PFCLScan especially as we can correlate between the internal netstat and also ps.exe scans as part of our database auditor project/policies.
If you would like to know more about (or to book) our database audit service, our Oracle security training or PFCLScan please contact us.
