Accessing a user when you don’t know the password

There are times that you may need to logon to a database user, probably a schema owner to do a release, but you don’t know the password. You may not be able to (easily) change the password as it could be embedded in application connect strings or worse.

If may not be possible simply to change your session using alter session set current_schema=<schema-to-be-changed>; to auto-prefix all of your selects with the schema, especiually if the release references “USER_” views, which is unaffected by the session setting.

You need to become the account.

So, what you need to do is record the current password encryption, change the password, logon and do your maintenance, logoff and change the password back!

And this is how you do it:
Create an account:

04:38:35 SYS @ ORCL01 > create user hackme identified by password1;

User created.

04:38:35 SYS @ ORCL01 > grant connect,resource to hackme;

Grant succeeded.

Grab the encryption.This is stored in SYS.USER$.SPARE4 plus SYS.USER$.PASSWORD:

04:38:35 SYS @ ORCL01 > select name,'alter user '||name||' identified by values '''||spare4||';'||password||''';' command from sys.user$ where name = 'HACKME'
04:38:35   2  /

NAME       COMMAND
---------- ------------------------------------------------------------------------------------------------------------------------
HACKME     alter user HACKME identified by values 'S:59F38E64D3914BB9396C5D4B968380676333EA7CB34F2471A85C4770A7BA;H:2D3693D1357CF012D9A11EFE3D792C0C;T:B2261F70475F3BD6173867C68427E346C53216E3EC305121DDAF4E13E72E6889DF1E314934F3C5F46E5F12B82D8AC144955C937413FD192904A2762D66B31A872429AB78E72AFC2BC4101E68DB5903A6;4345E749C3EBB34A';

Now we can change the password, logon with the new password, logoff back to a DBA and change it back using the previously captured command

04:38:35 SYS @ ORCL01 > alter user hackme identified by hacker;

User altered.

04:38:35 SYS @ ORCL01 > connect hackme/hacker;
Connected.

04:38:35 HACKME @ ORCL01 > show user
USER is "HACKME"

04:38:35 HACKME @ ORCL01 > connect sys/oracle as sysdba
Connected.

04:38:35 SYS @ ORCL01 > alter user HACKME identified by values 'S:59F38E64D3914BB9396C5D4B968380676333EA7CB34F2471A85C4770A7BA;H:2D3693D1357CF012D9A11EFE3D792C0C;T:B2261F70475F3BD6173867C68427E346C53216E3EC305121DDAF4E13E72E6889DF1E314934F3C5F46E5F12B82D8AC144955C937413FD192904A2762D66B31A872429AB78E72AFC2BC4101E68DB5903A6;4345E749C3EBB34A';
User altered.

04:38:57 SYS @ ORCL01 > conn hackme/password1
Connected.

Magic!

You can also use DBMS_METADATA to get the encryption;

04:39:08 SYS @ ORCL01 >  set long 10000

04:39:08 SYS @ ORCL01 >  select dbms_metadata.get_ddl('USER','HACKME') command from dual;

COMMAND
--------------------------------------------------------------------------------

CREATE USER "HACKME" IDENTIFIED BY VALUES 'S:F299C40420DD341AF9AC4AC89C59A2BB1DFCEF01DB5E3C2B5AD837100117;H:2D3693D1357CF012D9A11EFE3D792C0C;T:101F2A697CA5F77B089C4ECA8EE2DDB82E340D46FE60712445699C5715C3C71BA06532F52CFA987076B51254E5E5A565C44E9F7479018F924707F30874A0BF958D1B8935B7434CF993D3346FF53F28B4;4345E749C3EBB34A'
DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP"

Please read the COMMENTS to learn about Proxy Accounts – an (admin) alternative from 10G onwards!

Contactless Payment Theft

You may have seen stories in the news about Contactless Payment theft; how it is possible for a criminal to merely brush against you with a new contactless card reader and steal up to £30 from your contactless payment card.01_reader

You can either decide that pressing a contactless card reader against your wallet isn’t a plausible crime (it IS a plausible crime) or you won’t be affected. Or you can be a  little paranoid and go out and buy a screened wallet or purse, designed to block the RFID signal. They aren’t cheap!

However, you can do it yourself with stuff you should already have around the house – Gaffer Tape and Aluminium Foil. Ideally, you would have a sheet of copper mesh to use as it’s even more effective at blocking the RFID signal but several layers of aluminium foil works just fine – blocking up to 80% of the signal and rendering the contactless card reader ineffective.

 

02_tools

Tools needed! 1 pair of scissors.

03_gaffer tape strips

Start by laying out 3 strips of Gaffer Tape, roughly the height of your wallet and aboud 2.5 time the length. This will form the case for the foil

04_foilTear off a nice big piece of foil and start to fold it up so it is a bit less than the height of your wallet. Make sure it is very flat!

05_fold_foil

Carefully place the foil onto the tape and 07_coveR_in_tapefold up the tape over the foil and trim the edges down so you have a nice neat packet

09_trim_excess_tape

10_protected_cards

Slip your RFID signal blocker into the notes section… and there you have it. 1 nicely protected wallet. No contactless theft possible and I have just saved myself £30 for a new screened wallet and feel a little safer when on public transport. Lovely.

OK – I know this is not my usualy Oracle technical blog, and Heath-Robinson inventions aren’t my usual story, but I do have a client who makes these machines and I probably know a little more about them than most. I’ve had one of these RFID blockers in my wallet for a very long time.

Oracle Default Password Checker

It’s amazing how much stuff you come across years after it was released by Oracle, like the view DBA_USERS_WITH_DEFPWD. It lists many standard or common database accounts where you still have a default password set. If you combine this with the DBA_USERS view, you can see instantly where you may have a gaping security hole…


select def.username,usr.account_status
from dba_users_with_defpwd def, dba_users usr
where def.username = usr.username

USERNAME ACCOUNT_STATUS
------------------------------ --------------------------------
ORACLE_OCM EXPIRED & LOCKED
XDB EXPIRED & LOCKED
OLAPSYS EXPIRED & LOCKED
WMSYS EXPIRED & LOCKED
DBSNMP EXPIRED & LOCKED
DIP EXPIRED & LOCKED
OUTLN EXPIRED & LOCKED
EXFSYS EXPIRED & LOCKED
CTXSYS EXPIRED & LOCKED
XS$NULL EXPIRED & LOCKED
APPQOSSYS EXPIRED & LOCKED

If those accounts aren’t expired & locked, your database is wide open.

To see which accounts are being checked (with their default hashes), run:


select substr(user_name,1,20) username,substr(pwd_verifier,1,20) pwd_hash
from sys.default_pwd$
order by 1

In 11.2.0.3, there are 841 accounts being verified… have you left your flies undone?

%d bloggers like this: