|
|
| Line 1: |
Line 1: |
| − | ==Background==
| + | http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf |
| − | 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.
| + | Page 16 |
| | | | |
| − | 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:
| + | http://www.oracle.com/technology/pub/articles/project_lockdown/phase1.html#1.6 |
| − | | |
| − | 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:
| |
| − | | |
| − | #----ADDED BY TNSLSNR 24-OCT-2005 17:02:28---
| |
| − | PASSWORDS_LISTENER_ODSSDB01 = 75CD180DE6C75466
| |
| − | #--------------------------------------------
| |
| − | | |
| − | 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
| |
