This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Create a listner password

From OWASP
Revision as of 10:22, 2 November 2007 by Mjk303 (talk | contribs) (New page: ==Background== One of the most popular hacker tricks is to inject a large amount of text into the listener, thereby causing it to abort. The database could be still up, but since the liste...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Background

One of the most popular hacker tricks is to inject a large amount of text into the listener, thereby causing it to abort. The database could be still up, but since the listener is down, no new connections can be established—which in effect is a "denial of service" attack.

To do that, the hacker might attempt to change the attributes of the listener. A popular tactic here is to list the various services handled by the listener via the services command. Note how much information is displayed—possibly enough for the hacker to gain illegitimate access:

LSNRCTL> set displaymode verbose LSNRCTL> services Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST=prolin1.proligence.com)(PORT=1521)(IP=FIRST))) Services Summary... Service "PROPRD" has 1 instance(s).

 Instance "PROPRD1", status READY, has 1 handler(s) for this

service...

   Handler(s):
     "DEDICATED" established:0 refused:0 state:ready
        LOCAL SERVER

(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=/u01/oracle/products/10.1/db1/bin/ora cle)(ARGV0=oraclePROPRD11)(ARGS='(LOCAL=NO)')(ENVS='_=/u01/oracle/pro ducts/10.1/db1/bin/racgmain,_USR_ORA_CONNECT_STR=/ as sysdba,_CAA_CHECK_INTERVAL=600,SHLIB_PATH=/u01/oracle/products/10.1/d b1/lib32:/u01/oracrs/10gr1crs/lib32:/opt/nmapi/nmapi2/lib/hpux32:,_CA A_ACTIVE_PLACEMENT=0,PATH=,_USR_ORA_ALERT_NAME=,_USR_ORA_IF=,_CAA_OPT IONAL_RESOURCES=,_USR_ORA_START_TIMEOUT=0,ORACLE_BASE=/u01/oracle/pro ducts/10.1/db2,_USR_ORA_DISCONNECT=false,_CAA_SCRIPT_TIMEOUT=600,_CAA _UPTIME_THRESHOLD=7d,_USR_ORA_STOP_TIMEOUT=0,_CAA_FAILOVER_DELAY=0,_U SR_ORA_PRECONNECT=none,_USR_ORA_FLAGS=,_CAA_TYPE=application,_USR_ORA _INST_NOT_SHUTDOWN=,_CAA_REASON=boot,INIT_STATE=3,_USR_ORA_OPEN_MODE= ,_CAA_STATE=:OFFLINE,,_CAA_RESTART_ATTEMPTS=5,_CAA_ACTION_SCRIPT=/u01 /oracle/products/10.1/db1/bin/racgwrap,_CAA_DESCRIPTION=CRS application for Instance,_CAA_HOSTING_MEMBERS=prolin1,ORA_RACG_EXEC_ENV=LD_LIBRARY_PA TH=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nm api/nmapi2/lib/hpux64:/usr/lib:,_CAA_CLIENT_LOCALE=,_CAA_NAME=ora.PRO PRD1.PROPRD11.inst,ORA_CRS_HOME=/u01/oracrs/10gr1crs,_CAA_AUTO_START= 1,_CAA_TARGET=:ONLINE,,_USR_ORA_PFILE=,_USR_ORA_OPI=false,_USR_ORA_CH ECK_TIMEOUT=0,_CAA_PLACEMENT=restricted,_USR_ORA_LANG=,LD_LIBRARY_PAT H=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nma pi/nmapi2/lib/hpux64:/usr/lib:,_CAA_REQUIRED_RESOURCES=ora.prolin1.vi p,_CAA_FAILURE_THRESHOLD=0,ORACLE_HOME=/u01/oracle/products/10.1/db1, _USR_ORA_SRV=,PWD=/u01/oracrs/10gr1crs/bin,_USR_ORA_VIP=,_USR_ORA_STO P_MODE=immediate,_CAA_FAILURE_INTERVAL=0,_USR_ORA_NETMASK=,_USR_ORA_D EBUG=0,ORACLE_SID=PROPRD1,ORA_NET2_DESC=9,12,ORACLE_SPAWNED_PROCESS=1 ')(ENV_POLICY=NONE))


Another hacker trick is to shut down the listener. New connections will be refused, again effectively creating a denial of service attack.

In addition, the listener can also be remotely administered. Using this technique, the hacker can remotely stop a listener by attacking another vulnerable machine.

How do you protect yourself from these threats?

Strategy

The best option is to remove all permissions from the executable files tnslsnr and lsnrctl , except those for the owner. (This method has been described in the previous section.) This way no one, excepting the Oracle software owner, can start or stop the listener. The executables look like this:

-rwx------ 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl -rwx------ 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr

In some cases you may want to grant the authority to start and stop the listener. In that case you have to turn on the permissions.

$ chmod 0711 lsnrctl However, in such a case, you should prevent unauthorized use by enforcing a password. When you set a password, all commands—except some benign ones like HELP—are disabled.

Setting the password works the same way in all versions; but the enforcement mechanism varies:

In Oracle9i Database Release 2 and earlier, all users need a password. In Oracle Database 10g Release 1 and later, the OS user who owns the database software does not need a password. All others need a password. Here's how to set the password:

$ lsnrctl

LSNRCTL> change_password Old password: <OldPassword> Not displayed New password: <NewPassword> Not displayed Reenter new password: <NewPassword> Not displayed Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521)(IP=FIRST))) Password changed for LISTENER The command completed successfully

If you are setting the password for the first time, you can press ENTER when asked for the "Old Password." After making the change, save it on the parameter file:

LSNRCTL> save_config This command encrypts the password and places it in the listener parameter file. You can examine it later:

  1. ----ADDED BY TNSLSNR 24-OCT-2005 17:02:28---

PASSWORDS_LISTENER_ODSSDB01 = 75CD180DE6C75466

  1. --------------------------------------------

When you decide to use a command, you have to supply the right password. (In Oracle Database 10g and later, the OS user that owns the software does not need a password.)

LSNRCTL> services Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) TNS-01169: The listener has not recognized the password

To pass the correct password:

LSNRCTL> set password mypassword The command completed successfully LSNRCTL> status Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS of the LISTENER


Alias LISTENER ...

If you pass the wrong password, you will receive the error

TNS-01169: The listener has not recognized the password. If you do not pass the password and try executing a powerful command, you will receive the error

TNS-01190: The user is not authorized to execute the requested listener command To confirm the password is in effect, view the setting in the STATUS display of the listener. To do so, issue:

$ lsnrctl status The output varies between versions. For Oracle9i Database, here is a partial output:

STATUS of the LISTENER


Alias LISTENER Version TNSLSNR for Solaris: Version 9.2.0.6.0 - Production Start Date 25-OCT-2005 10:26:47 Uptime 0 days 13 hr. 8 min. 36 sec Trace Level off Security ON

Note the last line (Security ON), which indicates the password is set.

In Oracle Database 10g, this process is a little different. Remember, in that release, the listener is set to be executable by the Oracle software owner only without a password. If you have set a password, then other users can execute it after supplying the password. Here is the status display:

STATUS of the LISTENER


Alias LISTENER_ODSPDB02 Version TNSLSNR for HPUX: Version 10.1.0.4.0 - Production Start Date 16-OCT-2005 05:58:35 Uptime 9 days 17 hr. 44 min. 41 sec Trace Level off Security ON: Local OS Authentication

Note the last line, ON: Local OS Authentication, which indicates that the password has not been set. When the password is set, the display will show that line as:

Security ON: Password or Local OS Authentication

Note the additional clause above—Password— which indicates a password has been set.

Implications

In Oracle Database 10g and later, there are no implications; OS authentication is used to authenticate the user and there is no need to provide a password to start or stop the listener. In Oracle9i and earlier, you have to provide a password, and hence the script requires a password.

Action Plan

IF Oracle Database 10g or later THEN

 Remove the permissions from all except the owner  

ELSE

 Remove the permissions from all except the owner

Set a password for the listener operations END IF