Ever looked at the messages in the Oracle listener logs generated by Tripwire IP360 scans and wondered what was going on?
The most common one you see probably looks something like this:
01-JUN-2015 12:39:37 * (CONNECT_DATA=(COMMAND=VERSION)) * version * 1189 TNS-01189: The listener could not authenticate the user TNS-01169: The listener has not recognized the password
Generally, this is raised by our basic application detection for ‘Oracle TNS Listener’ (ID: 1119). This is essentially the equivalent of running ‘lsnrctl version’ from the command line. However, since this request is running remotely, if your TNS Listener is configured correctly, it requires authentication, which our request doesn’t supply.
TNS-01189 is raised because OS Authentication is enabled on the listener, and TNS-01169 is raised because a password is set for the listener. This command is the basis for our TNS Listener application detection.
In addition, some older vulnerabilities also use the same command when determining if a vulnerable version is running.
Another log message you might have seen that is also related to our basic application coverage is:
01-JUN-2015 12:47:46 * (CONNECT_DATA=(SID=!!IP360VERTTEST!!)) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.220.136)(PORT=65443)) * establish * !!IP360VERTTEST!! * 12505 TNS-12505: TNS:listener does not currently know of SID given in connect descriptor
This one is pretty clear that it’s from an IP360 scan, and is generated by a rule that stores the port number of the TNS Listener.
If your TNS Listener is not authenticated you’ve probably seen the vulnerability ‘Oracle TNS listener no password set’ (ID: 2063) show up in your scans. Otherwise, the listener will be authenticated and the request run by the vulnerability shows up as something like this:
01-JUN-2015 17:54:25 * (CONNECT_DATA=(COMMAND=status)(VERSION=168821248)) * status * 1189 TNS-01189: The listener could not authenticate the user TNS-01169: The listener has not recognized the password
It’s pretty similar to the version request above, but this one is the equivalent of running ‘lsnrctl status’ from the command line. This is not a vulnerability you want to see on a production machine, so hopefully, you see those authentication errors in your log after it.
The final log message you’ll probably encounter is generated by the ‘Oracle TNS Poison Vulnerability’ (ID: 47216). An attempt is made to register a service remotely, which on a non-vulnerable system shouldn’t allow.
Therefore, you’ll see messages in your log similar to these when the request is denied:
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.111.222)(PORT=1521))) 01-JUN-2015 17:50:49 * service_register * NCIRCLE * 12545 TNS-12545: Connect failed because target host or object does not exist TNS-12560: TNS:protocol adapter error TNS-00515: Connect failed because target host or object does not exist 64-bit Windows Error: 49: Unknown error 01-JUN-2015 17:50:50 * service_died * NCIRCLE * 12537
Or if you’re running 12c or later it might look like this instead:
Listener(VNCR option 1) rejected Registration request from destination 192.168.220.136 01-JUN-2015 15:14:46 * service_register_NSGR * 1182 TNS-01182: Listener rejected registration of service ""
Since vulnerabilities that don’t exist on a system won’t show up in your IP360 Report, it can be difficult to know what is actually tested when these messages show up in your log.
Hopefully, this helped give some insight into why these messages are being generated.