Mailing List Archive

On Mon, Jan 27, 2003 at 05:38:09PM -0600, Erik Anderson wrote:
>
> For our usage we are going to enhance Nessus’s service discovery
> capabilities and provide this work back to the Nessus community.
>
> We need Nessus to extracted, determine, or guesstimate information
> about running remote services like service type, service version,
> protocol version, and vendor if possible.
>
> Below are my findings on Nessus’s service detection capabilities,
> requests, and question.
>
> Current FindServices capabilities:
> This group of services appear to have header based detection built
> into Nessus. Is this list complete?
> chargen
[...]
> vtun
> time
> socks_proxy
>
> Normal service detection based on ports only (Non-ssl ports)
> Port 4: Echo
[..]

Please read the source code of the plugin first. This list is used to
tell the user what *normally* runs on this port.


> SSL service detection based ports only
[...]

Only if you asked the plugin to *NOT* automagically detect SSL services.




> First questions:
> 1) What is the sequence of events Nessus goes through from when NMAP
> returns an open port to the final XML/Text report output?

- Nmap stores the list of open ports in the KB
- find_services.nes is launched :
- For each open port, it connects to it, and recognizes if
it's running SSL or not (except if asked not to do so, as
SSL negociation sometimes crashes services)

- It sends an HTTP request (it could be anything)

- Then it reads the data in the socket buffer. This can include
the banner of the remote service, or the reply to the HTTP
request we sent

- Based on the result, it attempts to determine which service is
running behind the port.

- It stores that information in the KB

- dcetest.nasl and rpcinfo.nasl are launched
-> They map which ports are running DCE/RPC services, and mark
them as 'known' in the KB

Then, in Nessus 1.3 :

- find_service2.nasl is launched
- It sends a HELP command to every port not yet recognized
- It recognizes a couple of additional services

- unknown_services.nasl is launched last. It connects to every port
not yet recognized and tells the user that Nessus did not find what
was running on this port.

> 2) Do all open ports goes through a detection sequence?

Yes.

> 3) If NMAP returns a standard non-ssl port what does Nessus do to
> verify that generic port to service mapping?

See above.

> 4) If NMAP finds an oddball off-port running, what detection/connect
> sequences does Nessus run through to try and map back that open port
> to a known service? Does it try and pull a header or send data
> requests to the port to map that data back to a known service?

Read the source code of the plugins mentionned above.


> 5) Does Nessus try and detect if ports are normal or SSL?

Yes.

> Below is a starter list of things we need.
> 1) Run all standard services through sequences to get/guess service
> versions
> 2) Run all standard services through sequences to try and get vendor
> information.
> 3) Run all oddball ports through a query/response sequence to try and
> determine if it is a normal or SSL port.
> 4) Run all oddball ports through a query/response sequence to try and
> determine if this is a standard service running on a custom port.
> 5) If no other information is available for an oddball port try and
> determine the communications delivery methods (XML, ODL, HTTP).


That's exactly what is being done.


> I see many times something to the effect:
[...]
> Is this adequate? Should items like this be improved upon? There
> should definitely be detection sequences to determine things like
> MSSQL Server, Oracle, Sybase, etc... running on off ports.

It's not adequate, but you selected a very particuliar case. Most
plugins do something like :

port = get_kb_item("Services/<servicename>");
if(!port)port = <servicedefautport>;


> Request for comments:
> I will be enhancing the FindService features to accomplish the above.

Thanks, but I think you're work will be pretty easy.


-- Renaud

Erik Anderson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For our usage we are going to enhance Nessus’s service discovery
> capabilities and provide this work back to the Nessus community.

That's great, Renaud already answered most of the questions so I'm going
to pinpoint only some stuff.

>
> I see many times something to the effect:
> if (get_port_state(1433))
> {
> soctcp1433 = open_sock_tcp(1433);
>
> if (soctcp1433)
> {
> data = "It is possible that Microsoft's SQL Server is installed on
> the remote computer.";
> security_warning(port:1433, data:data);
> }
> }
>
> Is this adequate? Should items like this be improved upon? There
> should definitely be detection sequences to determine things like
> MSSQL Server, Oracle, Sybase, etc... running on off ports.

As Reanaud said, this is not adequate. You can consider submitting a bug
report (to bugs.nessus.org) for this plugin asking it to be modified (it
should use the KB, should it not?)

> Request for comments:
> I will be enhancing the FindService features to accomplish the above.
> We will be giving these enhancements back to the Nessus community.

That's great as I've said.

> First we would like to see responses to the below questions:
> 1) What should be done to improve the existing features?

If you check the findservices plugin you will see it provides a nice
generic framework for service discovery. It might be lacking some
popular services but they could be easily coded in. In this respect, I
think 'amap' (a Nessus user pointed it a while back) could be useful.
Check Bug #59 (http://bugs.nessus.org/show_bug.cgi?id=59). I list in the
bug report a number of services that seem to be detected by amap and are
not detected by findservices.

Taking amap's fingerprint for the service and putting it into
findservices should be an easy task.


> 2) What new features should be added to improve the feature set?

I believe adding more services to the ones available is a must.
Specially popular services such as ms-sql, oracle's listeners and LDAP.

> 3) What would people like to see as far as service detection
> capabilities go?

More service detection + more information on the given service and
issues. For example, if a remote server has 'netstat' I want to be able
to view (in reports) both the availability of the service and a dump of
the current open ports (which could be added to the KB).

> 4) How much of this information should be reported back in the Nessus
> report? (FYI: We need all information the server gleamed returned
> back to the client to be provided in the Nessus XML report)

I belive all information should be sent back, we might probably need to
add, later on, a way for users to remove deep-technical info from
reports but from the time being all information is useful-

>
> Please provide feedback/recommendations so I can develop a list of
> requirements to provide management and get to the real coding work.
>
> ThanX in advance
>
> Erik

Thank you for your work. Hope my suggestions were useful.

Regards

Javi

I think we need to make sure that this will get into the database that
Javier is spearheading in a usefull way.

-----Original Message-----
From: owner-nessus-devel@list.nessus.org
[mailto:owner-nessus-devel@list.nessus.org]On Behalf Of Erik Anderson
Sent: Monday, January 27, 2003 5:38 PM
To: nessus-devel@list.nessus.org
Subject: Enhancing Nessus FindServices (request for comments)



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For our usage we are going to enhance Nessus&#x2019;s service discovery
capabilities and provide this work back to the Nessus community.

We need Nessus to extracted, determine, or guesstimate information
about running remote services like service type, service version,
protocol version, and vendor if possible.

Below are my findings on Nessus&#x2019;s service detection capabilities,
requests, and question.

Current FindServices capabilities:
This group of services appear to have header based detection built
into Nessus. Is this list complete?
chargen
echo
http-rpc-epmap
vnc
nntp
vqServer-admin
www
gopher
gnutella
realserver
smtp
ftp
ssh
http_proxy
pop1
pop2
pop3
imap
auth
postgresql
mysql
cvspserver
wild_shell
telnet
netbus
linuxconf
finger
gnuserv

The below 3 appears to have detection based code but only a note is
provided (Not registered in Nessus as a service)
vtun
time
socks_proxy

Normal service detection based on ports only (Non-ssl ports)
Port 4: Echo
Port 19: Chargen
Port 21: FTP
Port 22: SSH
Port 23: Telnet
Port 25: SMTP
Port 37: Time
Port 70: Gopher
Port 79: Finger
Port 80: HTTP
Port 98: Linuxconf
Port 109: POP2
Port 110: POP3
Port 113: AUTH
Port 119: NNTP
Port 143: IMAP
Port 220: IMAP3
Port 443: HTTPS
Port 465: SMTPS
Port 563: NNTPS
Port 593: Http-Rpc-Epmap
Port 901: SWAT
Port 993: IMAPS
Port 995: POP3S
Port 1080: SOCKS
Port 1109: KPOP
Port 2401: CVSpserver
Port 3128: Squid
Port 3306: MySQL
Port 5000: VTUN
Port 5432: Postgres
Port 8080: HTTP-Alt

SSL service detection based ports only
Port 261: Nsiiops = IIOP name service over tls/ssl
Port 443: HTTPS
Port 448: ddm-ssl
Port 465: SMTPS
Port 563: NNTPS
Port 585: imap4-ssl
Port 614: SSLshell
Port 636: LDAPS
Port 684: Corba IIOP SSL
Port 989: FTPS data
Port 990: FTPS control
Port 992: telnets
Port 993: IMAPS
Port 994: IRCS
Port 995: POP3S
Port 1241: Nessus
Port 2478: SecurSight Authentication Server
Port 2479: SecurSight Event Logging Server
Port 2482: Oracle GIOP SSL
Port 2484: Oracle TTC SSL
Port 2679: Sync Server SSL
Port 3077: Orbix 2000 Locator SSL
Port 3078: Orbix 2000 Locator SSL
Port 3269: Microsoft Global Catalog w/ LDAP/SSL
Port 3471: jt400 SSL
Port 5007: WSM Server SSL
Port 7135: IBM Tivoli Access Manager runtime environment - SSL
Server Port 8443: Tomcat
Port 9443: Websphere internal secure server
Port 19201: SilkPerformer agent (secure connection)

First questions:
1) What is the sequence of events Nessus goes through from when NMAP
returns an open port to the final XML/Text report output?
2) Do all open ports goes through a detection sequence?
3) If NMAP returns a standard non-ssl port what does Nessus do to
verify that generic port to service mapping?
4) If NMAP finds an oddball off-port running, what detection/connect
sequences does Nessus run through to try and map back that open port
to a known service? Does it try and pull a header or send data
requests to the port to map that data back to a known service?
5) Does Nessus try and detect if ports are normal or SSL?

Below is a starter list of things we need.
1) Run all standard services through sequences to get/guess service
versions.
2) Run all standard services through sequences to try and get vendor
information.
3) Run all oddball ports through a query/response sequence to try and
determine if it is a normal or SSL port.
4) Run all oddball ports through a query/response sequence to try and
determine if this is a standard service running on a custom port.
5) If no other information is available for an oddball port try and
determine the communications delivery methods (XML, ODL, HTTP).


I see many times something to the effect:
if (get_port_state(1433))
{
soctcp1433 = open_sock_tcp(1433);

if (soctcp1433)
{
data = "It is possible that Microsoft's SQL Server is installed on
the remote computer.";
security_warning(port:1433, data:data);
}
}

Is this adequate? Should items like this be improved upon? There
should definitely be detection sequences to determine things like
MSSQL Server, Oracle, Sybase, etc... running on off ports.


Request for comments:
I will be enhancing the FindService features to accomplish the above.
We will be giving these enhancements back to the Nessus community.
First we would like to see responses to the below questions:
1) What should be done to improve the existing features?
2) What new features should be added to improve the feature set?
3) What would people like to see as far as service detection
capabilities go?
4) How much of this information should be reported back in the Nessus
report? (FYI: We need all information the server gleamed returned
back to the client to be provided in the Nessus XML report)

Please provide feedback/recommendations so I can develop a list of
requirements to provide management and get to the real coding work.

ThanX in advance

Erik

*********************
Erik Anderson
Carmichael Security
Work: eanders@carmichaelsecurity.com
W/H/O: eanders@pobox.com

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Security 7.0.3

iQA/AwUBPjXC4GBNrGASwj07EQLh9QCg51/L7dBaCAy8xcvwVWNc9gQW82wAnRCL
X8vzV73rwT1LUxCuV7nxwjvR
=pQiv
-----END PGP SIGNATURE-----