O O Ø O O O O
CERT IN-99-01
- Title:
- sscan Scanning Tool
- Date Issued:
- January 28, 1999
- Last Modified:
- January 28, 1999
- Code:
- IN-99-01
- Source:
- CERT
CERT Incident Note IN-99-01
The CERT Coordination Center publishes incident notes to provide information
about incidents to the Internet community.
"sscan" Scanning Tool
Thursday, January 28, 1999
Recently a new scanning tool named "sscan" was announced on various public
mailing lists. This tool is a derivative of the "mscan" tool that was widely used
against a large number of sites in the second half of 1998. For more information
about mscan, please read our earlier Incident Note IN-98.02:
http://www.cert.org/incident_notes/IN-98.02.html
The sscan tool performs probes against victim hosts to identify services which may potentially be
vulnerable to exploitation. Though sscan itself does not attempt to exploit vulnerabilities, it can be
configured to automatically execute scripts of commands that can be maliciously crafted to exploit
vulnerabilities. Thus, it is possible for an unpredictable set of attacks to be mounted against a victim
site in conjunction with the sscan probes.
The documentation distributed with sscan includes an example set of scripted commands illustrating
how a self-replicating attack might be crafted using well known vulnerabilities detected by sscan. We
encourage you to familiarize yourself with the actions sscan performs and to insure that your site is
not vulnerable to attack.
The current version of sscan has been written specifically to execute on a UNIX platform. Because
the tool crafts packets with custom attributes, privileged access to the source host is required to run
sscan. We encourage you to be mindful of the potential for intruder control of the source host when
responding to an incident involving sscan probes.
To determine whether the sscan tool is possibly being used against your site, look for the following
activity:
1.Initial probes to selected services to determine the availability of the target host. TCP ACK
packets are sent to the target host with the source and destination ports set as follows:
source and destination TCP port 23 (telnet)
source and destination TCP port 25 (smtp)
source and destination TCP port 110 (pop3)
source and destination TCP port 143 (imap)
source and destination TCP port 80 (www)
As currently configured, the sscan tool will not attempt to probe a host further if no response
is received from these initial probes.
2.If any of the above probes receives a response, further probes are made to the target host in
an attempt to identify potential vulnerabilities. Connection probes to the following TCP ports
are user optional and may or may not appear in additional sscan activity. The TCP ports are
listed in the order in which they currently would be probed by sscan.
80 (www)
23 (telnet), 143 (imap), 110 (pop3) [all three, or none, are probed]
111 (sunrpc)
6000 (x11)
79 (finger)
53 (domain)
31337 (unassigned by IANA)
2766 (Solaris listen/nlps_server)
Connection probes to the following TCP ports are always attempted and are not user optional.
The TCP ports are listed in the order in which they are probed by sscan.
139 (netbios-ssn)
25 (smtp)
21 (ftp)
22 (ssh)
1114 (Linux mSQL)
1 (tcpmux)
Ports responding to the probes in this section are considered by sscan to be "open" ports.
3.Two types of probes are made in an attempt to identify the target host's operating system.
TCP connection probe to port 23 (telnet) to obtain the login banner
Probes attempting to identify system and network architecture similar to those
discussed in CERT Incident Note IN-98.04:
http://www.cert.org/incident_notes/IN-98.04.html
In this case, five packets are sent to the target host on the first TCP port identified as
being "open" in the previous scanning (section 2). The five packets have the following
characteristics:
Packet #1 - SYN ACK packet from source TCP port 1
Packet #2 - FIN packet from source TCP port 2
Packet #3 - FIN ACK packet from source TCP port 3
Packet #4 - SYN FIN packet from source TCP port 4
Packet #5 - PUSH packet from source TCP port 5
4.Using information gathered from the probes, sscan attempts to determine if the target host
may potentially have any of the following accessible information services or known
vulnerabilities:
qpopper - see
http://www.cert.org/advisories/CA-98.08.qpopper_vul.html
ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-98.01.qpopper.buffer.overflow.vul
imapd - see
http://www.cert.org/advisories/CA-98.09.imapd.html
http://www.cert.org/advisories/CA-97.09.imap_pop.html
SMTP EXPN command
Solaris listen/nlps_server (port 2766)
Linux mSQL (port 1114)
BIND - see http://www.cert.org/advisories/CA-98.05.bind_problems.html
Various CGI-BIN vulnerabilities - see ftp://ftp.cert.org/pub/tech_tips/cgi_metacharacters
phf - also see http://www.cert.org/advisories/CA-96.06.cgi_example_code.html
handler - also see ftp://ftp.cert.org/pub/cert_bulletins/VB-97.07.sgi
Count.cgi - also see http://www.cert.org/advisories/CA-97.24.Count_cgi.html
test-cgi - also see
http://www.cert.org/advisories/CA-97.07.nph-test-cgi_script.html
php.cgi - also see ftp://ftp.auscert.org.au/pub/auscert/ESB/ESB-97.047
webgais
websendmail
webdist.cgi - also see ftp://ftp.cert.org/pub/cert_bulletins/VB-97.07.sgi
faxsurvey
htmlscript
pfdisplay.cgi
perl.exe (Windows platforms)
wwwboard.pl (Windows platforms)
NFS filesystems exported to everyone - see
http://www.cert.org/advisories/CA-94.15.NFS.Vulnerabilities.html
mountd - see http://www.cert.org/advisories/CA-98.12.mountd.html
rstatd - see http://www.cert.org/advisories/CA-97.26.statd.html
nlockmgr
rpc.nisd - see http://www.cert.org/advisories/CA-98.06.nisd.html
X11 (open X servers)
Wingate - see http://www.cert.org/vul_notes/VN-98.03.WinGate.html
Finger (optional) - The default behavior is to perform finger on 'root' and 'guest'
accounts. Target accounts are configurable and may differ from the defaults mentioned
here.
5.At this point, there may be additional, unpredictable activity if sscan is configured to execute
user crafted scripts of commands.
If any machines in your network use any of the above services, we encourage you to make sure that
all patches are up to date and your machines are properly secured.
We also urge you to filter all traffic at your firewall except that which you explicitly decide to allow.
Please read our packet filtering tech tip for more information:
ftp://ftp.cert.org/pub/tech_tips/packet_filtering
Sites using UNIX systems may also wish to consult the following documents:
ftp://ftp.cert.org/pub/tech_tips/UNIX_configuration_guidelines
ftp://ftp.auscert.org.au/auscert/papers/unix_security_checklist
CERT/CC wishes to thank AusCERT for their assistance in developing this Incident Note.
CERT/CC Contact Information
Email: cert@cert.org
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
Postal address:
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
U.S.A.
CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) Monday
through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on
weekends.
Using encryption
We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is
available from http://www.cert.org/CERT_PGP.key. If you prefer to use DES, please call the
CERT hotline for more information.
Getting security information
CERT publications and other security information are available from our web site
http://www.cert.org/.
To be added to our mailing list for advisories and bulletins, send email to
cert-advisory-request@cert.org and include SUBSCRIBE your-email-address in the
subject of your message.
Copyright 1999 Carnegie Mellon University.
Conditions for use, disclaimers, and sponsorship information can be found in
http://www.cert.org/legal_stuff.html.
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark
Office
NO WARRANTY
Any material furnished by Carnegie Mellon University and the Software Engineering
Institute is furnished on an "as is" basis. Carnegie Mellon University makes no
warranties of any kind, either expressed or implied as to any matter including, but not
limited to, warranty of fitness for a particular purpose or merchantability, exclusivity
or results obtained from use of the material. Carnegie Mellon University does not
make any warranty of any kind with respect to freedom from patent, trademark, or
copyright infringement.