Let’s suppose that we have activated our database auditing as recommended and put in place a centralized auditing solution so that the audit data can be sent to a remote server and protected (Like in my previous blog post) . Let’s now think like a hacker, can we hide our database activities (or some of it) ?
The Linux Audit system provides a way to determine the violator of the security policy and the actions they performed such as tracking malicious changes on the oracle executable.
Using Linux Audit system we can basically do the following activities :
- Watching file access
- Monitoring system calls
- Recording commands run by a user
- Recording security events
In this short blog post i will show how we can easily use it to catch changes in “./bin” directory.
In one of my previous post i showed how we can inject a backdoor in an ORACLE database based on Dennis Yurichev findings.The described method required the modification of the oracle executable files. Few days ago Rodrigo Jorge shared a blog post explaining how we can add another layer of security to the oracle binaries files to protect them against improper changes. That motivated me to check if i still can implement the hidden Trojan without modifying the oracle executable files ?
In this blog post i wanted to test some of Dennis Yurichev findings described in “Oracle RDBMS rootkits and other modifications” in recent oracle database 220.127.116.11 (The same can be done with 12.2) .So the idea here is to inject a backdoor in oracle LISTENER so that we can access Linux shell remotely.
You know POUG ? Of course you know POUG ! This is one of the best Oracle conference out there ! Great peoples ! Great Speakers ! Great Place ! Awesome ambiance !!!
Last week i was honored to be there ! It was a pleasure to meet many other Oracle geeks and to participate to this great event !
So as promised here is my presentation (My first public speak by the way) on slide share : Just click here !
Many thanks for all the POUG Team for this great adventure ! Don’t miss POUG18 !!!!
In my last blog post “CREATE ANY DIRECTORY”=DBA=SYSDBA ! Ouch ! i talked about the potential threat that can represent the PREPROCESSOR feature introduced in oracle 11gr2 in a consolidated environment and how to develop a systemtap live patch to help preventing that.As Frank Pachot also stated a new parameter “PDB_OS_CREDENTIAL” was introduced in oracle 18.104.22.168 which is meant to prevent that in CDB databases:
As Kamil Stawiarski explained in some great articles :
“A lot companies consolidates databases into one appliance – like for example Oracle Exadata. So you can have a lot of different databases in one physical cluster. And what if I tell you that you can execute any OS command as an oracle user, having just access to a database user with appropriate privileges? What if I tell you that DBA=SYSDBA? And not just SYSDBA for one database but for every database in a cluster?” Ref1
This is possible using only three elements thanks to the PREPROCESSOR feature introduced in oracle 11G Ref2 :
Here is a vulnerability i recently discovered inside the CDBView package (Create the cdb view) on my Database Patch Set Update : 22.214.171.124.161018 (24006101) .The package is granted to the “EXECUTE_CATALOG_ROLE” Role by default.
The package is not even wrapped, but this is not a problem as we can easily unwrap it anyway :
This is my third blog post about DB Link encryption/decryption.In the first one i demonstrated how we can find the database link password in clear text using GDB and Intel pin tools.In the second one i have given more information about how it was encrypted/decrypted (AES in CBC encryption mode).It’s now time to reverse engineer it !