Whitehats.ca - Synscan the worm enabler of the new Milennium

Mscan, Sscan and Synscan - The evolution of worm - enabling vulnerability scanners that span two Millenniums.

By Donald.Smith 5/20/2001

Mscan, sscan and synscan are very fast, simple and effective scanning and vulnerability detection tools. There are several versions of these tools being reported to incidents.org, whitehats.com, and other public IDS reporting sites. Starting with reports on mscan in 1998 ¹⁶, sscan reports in 1999 ¹⁵ and synscan first reported in 2000 ⁵. Synscan is the scanning and vulnerability testing engines for ramen ⁹, canserserver ¹¹ and is included in some versions of the t0rn root kit as t0rnscan⁷ Because of synscan’s use in these worms and the current signature databases ¹²synscan is the most commonly reported version of these tools today.

Synscan appears to have some flaws in them. Several of these have been documented in Joe Stewart’s writeups ⁵.Sending an ip packet with syn and ack set, spoofed from www.microsoft.de port 80 to the scanning machine on port 31337 will stop the listener side of synscan.

This does not stop the scanning it will continue to send syn packets. However the scanner machine will no longer be getting vulnerability information. Any worms using this version of synscan as their scanning engine will stop recording vulnerable machines and therefore stop spreading.

“hping –p 31337 –s 80 –k –S –A –a 212.184.80.190 ip.address,of.scanner” JoeStewart ⁵.

Tools used by these scanners.

Nsd From a comment in nsd.c “Written to pry some information out of a nameserver.” ² This tests for iquery and version of bind. This code exists in ramen, lpdW0rm and any worm that uses synscan as the vulnerability scanner. This appears to have a format string overflow vulnerability in its’ named version.string printing. This code appears in all versions of mscan, synscan and sscan it was renamed to binfo-udp.c in sscan2kpre-6. It was rewritten and used in the AdmWorm as the overflow for named .

Z0ne Attempts to map a domain by doing an axfr against the dns server for a domain. This code is included with all versions of sscan.

Nat10 The Netbois Security Kit version1.0. Based on code by Andrew Tridgell from his samba work. Andrew did not write this, however the author (unknown) used his code and did give him credit including the gnu license files as required;-) It is a tool to learn about netbios networks specifically to list the resources including the servers, printers, and hostnames.

Upscan This code is included with synscan.c Upscan is an IGMP scanner. Internet Gateway Management Protocal is used to communicate between routers and is usually passed throught the routers to hosts inside the network. Therefore it can be used to scan through and evade many IDS’s and some firewalls. Upscan also has a hardcoded ip address in it 206.252.191.1. It appears to be vulnerable to shuting down the listener by spoofing either an icpm or igmp packet from this address to the address of the scanner.

hping -1 –a 206.252.191.1 ip.address,of.scanner should work.

Tcpsock is the “special” vulnerability scanner code used by synscan. It checks for vulnerabilities in finger, telnet, rpc, bind, and cgi scripts. It makes application specific client requests to the victim service. Then capturing the return information of the victims service. This is phase 3 of synscan’s 3 scanning phases.

Scanners

Mscan By JSBach is the original scanner. First reported in 1998 this scanner became the basis for all of these other scanners, although this code also came from other code. Admtelnet from the ADMworm, Joshua Drake’s nsd.c, and part of BiT’s statd scanner were all used to help create this scanner ².

Sscan 0.1 By JSBach has an IDS signature that is very similar to synscan’s. The current snort and Whitehats signatures for synscan will alert on sscan0.1 and report this as synscan. Some reported synscan detects are actually sscan detects. It also has a queSO like fingerprinting scan. Which can cause false queSO alerts.

Sscan was the predecessor to synscan. Pyschoid tore lots of code out of sscan to get it to do what he wanted and not much more. He reduced the capabilities but improved the functionality. According to Pyschoid sscan did not work.

Pyschoid couldn’t get sscan to work. So he decided it was non functional.

I have made it work were are some tricks to compiling it.

Pyschoid removed the modules/scripting ability, the xwindow vulnerabilty tests and other sscan features to make synscan a VERY fast scanner.

Someone may have used synscan1.6 and the scripting examples include in SSCAN.README to create ramen. The readme for the Sscan scanner says

“NOTE: WE TAKE FULL RESPONSIBILITY FOR EVERYTHING YOU DO ILLEGALLY WITH

THIS PROGRAM. WE CONDONE ILLEGAL AND MALICIOUS USE OF THIS PROGRAM.”

Sscan also has documentation in the readme file on how to write an Internet worm using sscan and it’s modules abilities. I suspect this became the blueprint for ramen.

Synscan by psychoid is actually two vulnerability scanners and several support tools. The first scanner is Upscan.c which uses igmp to find hosts that are “up” on a network. Then the attacker can use synscan with a list of ip addresses from a file. IGMP is often allowed through routers by default. IGMP is the Internet Gateway Management Protocal used to manage internet gateways (routers mostly) . Synscan is usually used without Upscan by just scanning an entire class (a, b or c) network. Synscan.c is based on code from sscan. Synscan is vulnerable to having its’ listener process shutdown by spoofing a syn packet from www.microsoft.de ⁵ on 80 to the scanner’s ip address on port 31337 this kills the checkvuln function It also appears to have a remote root buffer overflow based on flaws in the nsd code. Synscan is the scanning and vulnerability testing engines for ramen, canserserver and included in some versions of the t0rn root kit as t0rnscan. Probably because of its use in these worms synscan1.6 is the most commonly reported version of this tool today.

In versions 1.8 Dor and Tradegy fixed the nsd format overflow and the shutdown vulnerabilities. The id has been “randomized” and it uses syn packets during phase 1 instead of syn fin used in versions 1.5 and 1.6.

I have reviewed publicly available versions (1.5,1.6 and 2.1) of the synscan source code they have several flaws that I have not seen documented

1. The reason the sequence numbers and ack numbers don’t change more often is because srand is called with unix time function as its seed. Under linux this returns the time to the nearest second. Then rand is called to provide the pseudo random numbers. According to the Linux Man Pages “These random sequences are repeatable by calling srand with the same seed value.” Others have noticed that these numbers appear to change around 50 hosts but it really depends on the speed of the scanning host and the speed of the scan. This tool allows for a delay factor which defaults to 1 tick but can be set to any valid short int. The author did not understand that by calling srand(TIME) would give them the same “random” number until the TIME function they used returned a different number. So they keep calling srand with the SAME number giving them the exact same “random” number for one second. So seq, ack and in versions 1.8 and later the IP id stay the same for 1 second on the scanning machine.

2^. The network wildcard loop goes up to 255 which is not a valid host id. So when using this tool to scan a class C network address will cause SYNSCAN to scan every host in the network including the 255 “net address”. A good general IDS signature might be to look for addresses with a 255 in the host portion. This should never come from the outside to the inside or from the inside to the outside. This is a fairly common mistake among network tool writers.

3^. In versions 1.8 and later the IP ID has been randomized, however the random code is similar to the code in 1.5 for the randomized ACK and SEQ so it stays the same for 1 second then changes to a new random number.
T0rnscan version (0.b) by RippEd is a syn scanner and vulnerability scanner used in ramen and is included in some versions of the t0rn root kit. T0rnscan can be used to scan an entire class (a, b or c) network. T0rnScan is based on code from Synscan(1.8?). T0rnscan can do its own queso style os fingerprinting. This queso style fingerprinting has caused numerous incorrect detections for queso rather then t0rnscan.

I have reviewed a publicly available version (0.b) of the T0rnscan’s source code. It appears to have flaws that I have not seen documented T0rnscan appears to have a potential remote root buffer overflow based on flaws in the vuln.c code. There is a printf that prints the string it gets during it’s vulnerability checking without checking the input to printf!

The ID has been randomized however the random code has the same flaw listed about with regards to the “static” random number The ttl is also randomized but will be between 200 and 255 with a strong tendency to be 255 because of the formula used to make random ttls.

This scanner has the same problem as synscan with random numbers changing every second. It also has the 0 and 225 IP address error.

Finally, several people have documented T0rnscan as a renamed (not changed) synscan1.6. I have not seen this version of T0rnscan. The version I have is closely related to synscan 1.8.

Sscan2kpre6 is the current released version of sscan and is much more functional then the original sscan or synscan. It includes 170 vulnerability checks for ftp, imap, pop2, pop3, bind, lots of Trojan ports, lots of cgi vulnerabilities and other vulnerabilities.

Sscan2kpre6 has an option for using nmap to guess Operating Systems or it can do its own queso style os fingerprinting. This queso style fingerprinting has caused numerous incorrect detections. Sscan is much more dangerous then queso. If detected as queso, some analysis might just writeit off as “yet another scan”. The queso style fingerprinting method in this scanner is flawed. It reported Solaris 2.x for a machine running linux 7.0.

This scanner was designed to support an Internet worm. The comments in the SSCAN.README file “you could probably write a whole internet worm in the scripting language.” is followed by an example of how to use sscan2kpre6 to write an Iinternet worm. This scanner has checks for lots of many well known Trojan ports but all but port 31337 is commented out. Uncommenting these would make this a very easily detected scanner.

This scanner tries to use a POP2 buffer overflow and

can use pop2 banners to check the Operating System. This might be the 109 that we are seeing and Steven Northcut mentioned at SANs2001 in NewOrleans. This scanner uses anonymous as the username and guest@Microsoft.com as the anonymous ftp login password when checking for anonymous login.

This tools scans for wingates. This is so they can “hide”.the real source of the scan. The default configuration for WinGate allows an intruder to use a WinGate server to conceal his or her true location without the need to forge packets ¹⁹.

There are so many versions of this scanner and supporting tools that I have summarized the differences and features below.

Name	vers#	Flags	ID	Ttl	win	Ports	Default ports scanned	author	Released Reported	Vulnerabilities
Mscan	1.0	Syn					23, 80, 143, 110, 6000, 25, 79, 53	Jsbach	6/1998
Sscan	0.1	Syn, During fingerprinting Queso Flags or nmap	39426	42	28	Highnumber >1024 to scanning port.	1,21, 22, 23, 25, 53, 79, 110, 111, 139, 143, 1114, 6000, 2766, 31337	Jsbach	1/15/1999
Nsd.c	???	UDP		64			53	Joshua James Drake	6/9/98	Format bug in printf statement that could provide remote root buffer overflow on the system this scanner is running on.
Z0ne	1.1						53	ADM	12/9/1999
synscan	1.5	SynFin	39426	42	28	From=to	23, 80, 111, 1080	psychoid	1999	Uses nsd therefore shares the vulnerabilities from it. Vulnerable to shutdown packets from www.microsoft.de:80 to scanner:31337
Synscan	1.6	SynFin	39426	42	28	From=to	23, 80, 111, 1080	Pyschoid	1999	Uses nsd therefore shares the vulnerabilities from it. Vulnerable to shutdown packets from www.microsoft.de:80 to scanner:31337
Upscan	1.0	IGMP	69	255			Igmp type 2 Igmp code 31 Igmp_mtrace?? Check rcf1112	Pyschoid	1999
T0rnScan	0.b	SYN	Random	255 200 + rand() %56	Random	Highnumber -> scanning port(s)	21,110,143,2766,80,111	RiPPEd Inc. but based on synscan1.6	1999	Format bug in printf statement that could provide remote root buffer overflow on the system this scanner is running on.
Synscan	1.8	Syn	Random					Pyschoid and Dor	???	Not vuln to listner shutdown and bind lookup remote buffer overflow fixed. Not released I have not seen the source.
Synscan	1.?	Syn	19104	2??	28	From=to	21 is all I saw.	???	???	I have not seen source but I did capture packets in the wild.
Scanssh	1.55	Syn	0	255		From = ntohs(*seqnr); to=22	22	Niels Provos	2000
Synscan	2.0	Syn	Random	255	28	From=to	23 80 111	Dor and Tragedy	????	Not vulnerable to Microsoft packets and known remote root overflow. Dor has a copy of this available at his web site.
Scan2k-Pre6	Pre6	Ack During vuln scan syn,ack	39426	42	28	During scan From=to During connection for vulnerability scan > 1024 to wellknown ports	1, 21, 22,23,25,53,79, 80, 109, 110, 111, 113, 139, 143, 1114, 2766, 6000, 12345, 12346, 20034, 21544, 31337, 31789, 54320, 65533, , 65535	Eth0, mixter, axess
RpCScaN	1.0	Syn						Dor and Tragedy

Synscan detects in the wild

Packet capture of Tornscan from http://www.sans.org/y2k/011701-1500.htm

ID=39426 implies a synscan1.6 code base.

---------------------------------------------------------

Packet 1

TIME: 09:51:55.037837

LINK: 00:02:B3:07:EE:ED -> 00:90:27:B8:B4:21 type=IP

IP: 216.179.148.250 -> XXX.XXX.XX6.12 hlen=20 TOS=00 dgramlen=40 id=9A02

MF/DF=0/0 frag=0 TTL=27 proto=TCP cksum=4893

TCP: port 9704 -> 9704 seq=0621232889 ack=0573123859

hlen=20 (data=0) UAPRSF=000011 wnd=1028 cksum=EB95 urg=0

DATA:

---------------------------------------------------------

Packet 2

TIME: 09:51:55.038981 (0.001144)

LINK: 00:90:27:B8:B4:21 -> 00:02:B3:07:EE:ED type=IP

IP: XXX.XXX.XX6.12 -> 216.179.148.250 hlen=20 TOS=00 dgramlen=40 id=D109

MF/DF=0/0 frag=0 TTL=128 proto=TCP cksum=AC8B

TCP: port 9704 -> 9704 seq=0000000000 ack=0621232891

hlen=20 (data=0) UAPRSF=010100 wnd=0 cksum=3EC3 urg=0

DATA:

---------------------------------------------------------

Packet 3

TIME: 09:51:55.057821 (0.018840)

LINK: 00:02:B3:07:EE:ED -> 00:00:F8:1A:41:AF type=IP

IP: 216.179.148.250 -> XXX.XXX.XX6.13 hlen=20 TOS=00 dgramlen=40 id=9A02

MF/DF=0/0 frag=0 TTL=27 proto=TCP cksum=4892

TCP: port 9704 -> 9704 seq=0621232889 ack=0573123859

hlen=20 (data=0) UAPRSF=000011 wnd=1028 cksum=EB94 urg=0

DATA:

---------------------------------------------------------

Packet 4

TIME: 09:51:55.058126 (0.000305)

LINK: 00:00:F8:1A:41:AF -> 00:02:B3:07:EE:ED type=IP

IP: XXX.XXX.XX6.13 -> 216.179.148.250 hlen=20 TOS=00 dgramlen=40 id=6C4B

MF/DF=0/0 frag=0 TTL=64 proto=TCP cksum=5149

TCP: port 9704 -> 9704 seq=0000000000 ack=0621232890

hlen=20 (data=0) UAPRSF=010100 wnd=0 cksum=3EC3 urg=0

DATA:

---------------------------------------------------------

Packet 5

TIME: 09:51:55.076996 (0.018870)

LINK: 00:02:B3:07:EE:ED -> 08:00:20:75:03:AA type=IP

IP: 216.179.148.250 -> XXX.XXX.XX6.14 hlen=20 TOS=00 dgramlen=40 id=9A02

MF/DF=0/0 frag=0 TTL=27 proto=TCP cksum=4891

TCP: port 9704 -> 9704 seq=0621232889 ack=0573123859

hlen=20 (data=0) UAPRSF=000011 wnd=1028 cksum=EB93 urg=0

DATA:

---------------------------------------------------------

Packet 6

TIME: 09:51:55.077456 (0.000460)

LINK: 08:00:20:75:03:AA -> 00:02:B3:07:EE:ED type=IP

IP: XXX.XXX.XX6.14 -> 216.179.148.250 hlen=20 TOS=00 dgramlen=40 id=B14F

MF/DF=0/1 frag=0 TTL=27 proto=TCP cksum=F143

TCP: port 9704 -> 9704 seq=0000000000 ack=0621232890

hlen=20 (data=0) UAPRSF=010100 wnd=0 cksum=3EC2 urg=0

DATA:

Snort of synscan(1.7?) in the wild.