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) ?
So here we have access to our 19c oracle database (using pure unified auditing) and we want to hide our sysdba activity (disable auditing only for our current session) . All what we are going to do here is based on oradebug !
The first thing that we are going to do is change the protection of our memory region using mprotect to allow writing to it :
So now we have the write flag correctly set.This flag need to be set so that we can patch the oracle kernel function “sopts_IsUnifiedAuditOn” and disable auditing for our target session.
Sadly the oradebug poke function seem to not work as expected in recent oracle release
But don’t worry there is always other ways 🙂 We are going to use the “memset” function here to modify a little bit our function ( By the way I just modified the value pushed into the EAX register ) :
And that’s it we are good to go, we are in stealth mode now ! All auditing for our current session have been disabled ! Still we will find the execution of the last oradebug command in the “unified_audit_trail” :
PS: The oradebug command can be disabled by setting “_disable_oradebug_commands” to all.
That’s it 😀