yapscan

TCP Half-open port scanner / fast ICMP scanner. Some limited support for UDP scans too. It’s beta, but still kinda useful.

Download Yapscan v0.7.4-beta as tar.gz. Recent changes are detailed in the CHANGELOG.

Update: You’re better off using the SVN copy on google code.  It’s more up to date.

MD5 and SHA1 checksums are the packages can be downloaded.  They’re based on the package name (below v.v.v represents the version, e.g. 0.6.1):

http://pentestmonkey.net/tools/yapscan/yapscan-v.v.v-beta.tar.gz.md5

http://pentestmonkey.net/tools/yapscan/yapscan-v.v.v-beta.tar.gz.sha1

User documentation is also available in PDF format.

 

Yapscan User Documentation

 

Contents

  • Overview
  • License
  • Installation
    • Quick Start
    • Trouble Shooting
    • Workaround For Missing OpenSSL Libraries
  • Features
    • TCP SYN Scanning
    • (Limited) UDP Port Scanning
    • ICMP Scanning
    • Scanning Speed
    • Retries
  • Yapscan Output
    • Scan Information
    • Scan Start and End Times
    • TCP Scanning
    • ICMP Scanning
  • Limitations
    • Memory-hungry
    • Replies from different IPs
  • Why write Yet Another Port Scanner?
  • Credit

 

Overview

Yapscan is primarily a half-open TCP port scanner and ICMP scanner. It has a few other uses too. These are explained more fully in the “Features” section below.

License

This tool may be used for legal purposes only. Users take full responsibility for any actions performed using this tool. The author accepts no liability for damage caused by this tool. If these terms are not acceptable to you, then do not use this tool.

In all other respects the GPL version 2 applies:

 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as
 published by the Free Software Foundation. 

 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details. 

 You should have received a copy of the GNU General Public License along
 with this program; if not, write to the Free Software Foundation, Inc.,
 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

Installation

Quick Start

If you have a Linux system, with any luck the installation will just work. Other systems are not supported at this time.

Firstly, go and download the latest tarball of yapscan from http://pentestmonkey.net if you haven’t already.

 su -
 cd /usr/local/src
 tar xfz yapscan-X.Y.tar.gz
 cd yapscan-X.Y
 make
 make install

Trouble Shooting

Yapscan should install on most flavours of Linux. I’ve tried it on Gentoo using gcc v3.3.x, 3.4.x and 4.1.x (both x86 and AMD64) and Debian “Testing” using gcc-4.1.2. I think I’ve ironed out any bugs which stop compilation. That said, you’re reading this section, so I guess something went wrong…

Any installation problems will be results of either missing header files, missing libraries or my dodgy code. Whatever the cause I’d like to make sure that this section covers the problem (or that I fix any dodgy code). If you run into problems and the notes below don’t help, please email me at the address on the first page.

Yapscan depends on libpcap to capture reply packets, so firstly make sure you’ve installed it. On Gentoo the package is called “libpcap” on Debian it’s “libpcap-dev”(the version that includes the header files).

Linking against OpenSSL is also recommended because it speeds up scanning. Installation is still possible if you can’t install OpenSSL – there’s a workaround below. The OpenSSL package on Gentoo is called “openssl”, on Debian it’s “openssl-dev”.

If installing these dependencies doesn’t solve your problem, mail me and I’ll try to help.

Workaround For Missing OpenSSL Libraries

Open up “Makefile” in you favourite text editor and change this bit:

 # OpenSSL's MD5 library speeds up scanning.  If you have openssl installed, do this:
 DEFINES=-DHAVE_LIBCRYPTO ${DEBUGDEFINES}
 LDLIBS=-lpcap -lcrypto 

 # Otherwise do this:
 # DEFINES=${DEBUGDEFINES}
 # LDLIBS=-lpcap

to:

 # OpenSSL's MD5 library speeds up scanning.  If you have openssl installed, do this:
 # DEFINES=-DHAVE_LIBCRYPTO ${DEBUGDEFINES}
 # LDLIBS=-lpcap -lcrypto 

 # Otherwise do this:
 DEFINES=${DEBUGDEFINES}
 LDLIBS=-lpcap

The try to compile again:

 make clean
 make
 make install

Features

TCP SYN Scanning

Also known as half-open scanning.

On an internal network you probably just want to see the open ports. Here are some example of how to specify hosts and ports:

 # yapscan -sS 192.168.0.1-254 -p 1-1024
 # yapscan -sS 10.0.0.1-10.0.255.255 -p 21,22,23,53,80,139,445,3389
 # yapscan -sS 172.16.0.0/16 -p 80
 # yapscan -sS -f targets-ips.txt -p 4444

From an external network, you might also want to see the closed ports (-c):

 # yapscan -sS www.example.com -p 1-65535 -c

You can scan just the common ports (using a portlist derived from nmap):

 # yapscan -sS 127.0.0.1 -i lo -P common

(supported keywords are based on filenames what ship with yapscan. As of v0.5.5-beta there is: all, known, common, database)

Note that we needed to specify the different interface to listen for replies on (default is eth0).

Specify ports using names as well as numbers (from /etc/services):

 # yapscan -sS router -i eth1 -p telnet,80,443,ssh,6000-6063

Or specify your own port list (1 port per line):

 # yapscan -sS -f mytargets.txt -P myports.txt

You can do “-p -” like in nmap too if you want to scan 1-65535:

 # yapscan -sS -f mytargets.txt -p -

I’ve also implemented the exotic type of scans like Xmas tree, null, etc. These aren’t particularly well tested as of v0.5.5-beta. See the help message for more info: yapscan -h

Also see “Scanning Speed” and “Retries” near the end of this section. In particular, make sure you specify a low speed for remote testing (e.g. -b 32k).

(Limited) UDP Port Scanning

This scan mode is designed to answer the question “Does host X have any closed UDP ports?” i.e. does it reply with an ICMP Port Unreachable for probes sent to one or more of its UDP ports.

This type of scan will (unfortunately) not tell you all the open UDP ports.

I use this mainly for scanning Firewalled hosts which I’m pretty sure won’t have any closed UDP ports.

Yapscan sends empty UDP packets to a range of ports at a steady (usually quite fast) rate. It will report any ICMP port unreachable messages it receives.

If you receive no replies then you know there are no closed UDP ports.

 # yapscan -su router -i eth1 -p 1-65535

IMPORTANT NOTE: If you receive 1 or more ICMP port unreachable error messages, you cannot infer that these are the only close ports. Yapscan does not back-off intelligently like nmap, so a host which limits that rate at which it sends ICMP errors, will (falsely) appear to have less ports open.

ICMP Scanning

Yapscan can perform the following type of ICMP sweeps:

  • Echo Request
  • Timestamp Request
  • Addressmask Request
  • Information Request

You can perform 1 or more types of scan at once:

 # yapscan -sI 10.0.0.0/16 -t echo
 # yapscan -sI 10.0.0.0/16 -t echo -t addr
 # yapscan -sI 10.0.0.0/16 -t info
 # yapscan -sI 10.0.0.0/16 -t time
 # yapscan -sI 10.0.0.0/16 -t -

The last example will scan all supported ICMP types.

As of v0.5.5-beta yapscan is also able to send Router Solicitations, but it won’t report replies, so this 5th type isn’t much use at present.

Scanning Speed

Yapscan scans at a steady (and configurable) speed. You can get an ETA on you scan by pressing Enter during the scan.

As of v0.4.9-beta yapscan will never underestimate the remaining scan time, though it can over estimate it under certain conditions.

By default yapscan scans at 1000000 Bits / Second. Unless you have a fast link / understanding clients or both I suggest you only use the default for LAN testing. I wouldn’t recommend going much about 2Mb/s for reliability / DoS reasons, but you can try it if you like:

 # yapscan -sS -p - 192.168.0.1-14 -b 4M

WAN testing’s probably better done at a more sociable speed like 64Kb/s:

 # yapscan -sS -p - www.example.com -b 64k

Obviously, if the scan rate is set higher than either your upstream bandwidth or the client’s downstream bandwidth, packets will be dropped and the reliability of the scan reduced.

Retries

Reliability is obviously paramount during pentests, so the use of retries is encouraged. ICMP scans do 2 retries by default (a total of 3 tries in all). TCP and UDP only do 1.

For an even more reliable ICMP scan you could do:

 # yapscan -sI -r 5 myhost -t -

A TCP scan would be made more reliable by:

 # yapscan -sS -r 2 myhost -p -

Yapscan Output

Scan Information

The first thing you see when you run yapscan is the “Scan Information” section. This section summarises the parameters for the scan. I included this basically so that when I looked back over my scan results I had some idea of what I’d scanned.

  ----------------------------------------------------------
 |                   Scan Information                       |
  ----------------------------------------------------------
 Target count: ...... 1
 Interface: ......... lo
 Bandwidth limit: ... 1000000 bits/sec
 Source address: .... 127.0.0.1
 RTT: ............... 0.950000 secs
 Tries: ............. 3
 ICMP Probe Types: .. 8 (ECHO_REQUEST)

The output looks slightly different for the various scan types.

Scan Start and End Times

The start and end times are included to provide a record of when the scan was done.

 ######## Scan started at 2006-10-22 20:37:26 +0000 #########
 ...
 ####### Scan completed at 2006-10-22 20:37:27 +0000 #########

TCP Scanning

Below is the output of a fictional TCP SYN scan run with the -c option to show closed ports as well as open ones (so I can illustrate some fields not always shown in the output).

 10.0.1.1:25   smtp  Len=46 TTL=19 IPID=0 FLAGS=_AR_____ SEQ=0x00000000 ACK=0x4e5d5003 WIN=0 DATA="rctcpoy"
 10.0.2.2:80    http  Len=46 TTL=21 IPID=0 FLAGS=_AR_____ SEQ=0x00000000 ACK=0x0b712500 WIN=0 DATA="rctcpo"
 10.0.3.3:53    domain  Len=44 TTL=64 IPID=0 FLAGS=SA______ SEQ=0xd1183250 ACK=0x17f67482 WIN=32792
 10.0.4.4:1999     tcp-id-port     Len=40 TTL=59 IPID=43634 FLAGS=_AR____C SEQ=0x00000000
 ACK=0x28f45290 WIN=0
 10.0.5.5:1999      tcp-id-port     Len=45 TTL=244 IPID=22340 FLAGS=_AR_____ SEQ=0x00000000
 ACK=0xab7e84c2 WIN=0 DATA="cisco"

We’ll use the first reply to quickly cover most of the generic fields, then we’ll look at some of the interesting ones.

Field Meaning
10.0.3.3 IP Address reply came from
25 TCP Port number reply came from
smtp Name of port (from /etc/services)
Len=46 Length of packet (IP header + TCP header + data)
TTL=19 Time-to-Live of reply packet
IPID=0 IP ID on reply
FLAGS=_AR_____ TCP Flags: S=SYN, A=ACK, R=RST, F=FIN, P=PSH, U=URG, E=ECN, C=CWR
SEQ=0×00000000 TCP Sequence number
ACK=0x4e5d5003 TCP Acknowledgement number
WIN=0 TCP Windows size
DATA=“rctcpoy” Data carried by TCP packet (if any)

We see that IP address 10.0.3.3 has TCP port 53 open (note the SYN and ACK flags are set on the response). The rest of the packets indicate closed ports (the RST flag is set).

Some of the RST packets have data attached. This is much more rare than I’ve made it seem in this example, but it’s an interesting feaure of yapscan, so worth some discussion.

According to http://www.sonicwall.com/support/pdfs/technotes/SonicOS_TCP_RST.pdf, the string “rctcpo” for 10.0.2.2 seems to indicate that the host is protected by a Sonicwall Firewall. Presumably 10.0.3.3 is similarly protected, but I haven’t tracked down any documentation as to the exact meaning of “rctcpoy”.

The data “cisco” is return on the response from 10.0.5.5. This is a feature of certain older version of Cisco IOS. The feature is documented as a fingerprinting vulnerability at http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0453.

Finally, note that the packet from 10.0.4.4 has the TCP C flag set. This is the Congestion Window Reduced flag, a relatively new TCP option.

NB: There is currently no support for displaying IP options or TCP options.

ICMP Scanning

The output below shows pretty much all of the various fields you’re likely to come across when running ICMP sweeps with yapscan:

 10.0.1.1:18/0 [ADDRESS_REPLY] Len=32 TTL=56 IPID=10224 ID=10406 SEQ=13643 MASK=255.255.254.0
 10.0.2.2:18/0 [ADDRESS_REPLY] Len=32 TTL=248 IPID=15111 ID=4233 SEQ=39939 MASK=255.255.255.252
 10.0.3.3:14/0 [TIMESTAMP_REPLY] Len=40 TTL=249 IPID=31174 ID=2463 SEQ=52706 orig=0x040f417e
 recv=0x83ecf893 xmit=0x83ecf893 std=0 end=1
 10.0.4.4:14/0 [TIMESTAMP_REPLY] Len=40 TTL=128 IPID=1617 ID=2182 SEQ=92 orig=0x041ae462
 recv=0x9cdc1a04 xmit=0x9cdc1a04 std=1 end=0 xmit-time=19:07:49.276 delta=-1.984
 10.0.5.5:14/0 [TIMESTAMP_REPLY] Len=40 TTL=240 IPID=10035 ID=6689 SEQ=42152 orig=0x040f40aa
 recv=0x04131907 xmit=0x04131907 std=1 end=1 xmit-time=18:59:20.455 delta=252.000
 10.0.6.6:16/0 [INFO_REPLY] Len=28 TTL=247 IPID=48924 ID=3706 SEQ=64144
 10.0.7.7:16/0 [INFO_REPLY] Len=28 TTL=243 IPID=64889 ID=10674 SEQ=17306
 10.0.8.8:0/0 [ECHO_REPLY] Len=28 TTL=128 IPID=1616 ID=21821 SEQ=92

Generic ICMP Fields

The following fields are common to all ICMP results:

Field Meaning
10.0.1.1 IP Address reply came from
18/0 The ICMP Type of the reply was 18. The ICMP Code was 0.
[ADDRESS_REPLY] A human readable form for the ICMP Type. Type 18 is Address Mask Reply
Len=32 Length of packet (IP header + ICMP header + data)
TTL=56 Time-to-Live of reply packet
IPID=10224 IP ID on reply
SEQ=13643 ICMP Sequence number

 

ICMP Address Mask Fields

A single field is unique to ICMP Address Mask scans:

Field Meaning
MASK=255.255.254.0 The netmask of the corresponding IP is 255.255.254.0

 

ICMP Timestamp Fields

Yapscan will tell you if the remote system clock is accurate if the timestamp supplied is in a standard format. It manages this even the remote system has a broken IP stack which uses the wrong endianness for the timestamp fields.

Field Meaning
orig=0x040f417e Originator timestamp in hex
recv=0x83ecf893 Received Timestamp in hex
xmit=0x83ecf893 Transmit Timestamp in hex
std=0 Do the timestamp fileds contain the number of milliseconds since midnight UTC as suggested by RFC 792?
end=1 Does the endianness of the xmit field appear to be correct (big endian AKA network byte order)? Most versions of Windows use the wrong endianness in this field.
xmit-time=19:07:49.276 Only displayed if std=1. A human readable representation of the xmit field. If the endianness of xmit was wrong, it is reverse before being converted to human readable format, so Yapscan will display meaningful timestamps even for Windows systems.
delta=-1.984 Only displayed if std=1. The number of seconds ahead of UTC the remote system’s clock is. (UTC according to your system clock).

 

ICMP Echo Fields

See Generic ICMP Fields section above. No additional fields are available for Echo replies.

 

ICMP Information Fields

See Generic ICMP Fields section above. No additional fields are available for Info replies.

Limitations

Memory-hungry

Yapscan implements retries by keeping a list of hosts and ports to be scanned in memory. This has the side effect of using an awful lot of memory on large scans: 770MB for 65535 ports on 256 hosts

This a pretty big problem. I really need to break the scan into chunks.

Replies from different IPs

If you send a packet to an address which elicits a reply from a different IP address (e.g. you ping 192.168.0.255 and get a reply from 192.168.0.5) the reply will not be reported by yapscan.

This is because all cookies carry a “cookie” of some description which is derived from the source and destination IP of the original probe. Yapscan will inspect the reply and ensure that cookie contained within it is derived from the source and destination IP. If an unexpected IP replies yapscan will assume that the traffic is not a response to a probe.

Why write Yet Another Port Scanner?

When I started writing yapscan I wanted to:

  1. Learn some C++
  2. Write some generic classes that handle all the mundane parts of port scanning (like hostlist traversal, retries, bandwidth usage).

The idea being that next time I needed to write a scanner (whether it be ARP, IPv6, DNS server-finder, mass DoS payload deliverer, etc.) I’d be able to quickly code up the probe, define how to parse responses and the generic classes would take care of the rest.

Alas, my eyes were too big for my belly and I’ve ended up with yet another IPv4 port scanner.

Maybe I’ll achieve my original goal someday, but as of today I’m still some way off.

That said, I do find yapscan useful during most pentests, so I thought I’d submit it back to he community in hope that others would too.

Credit

Much inspiration (and even small amounts of code) as been drawn from other tools. It’s only right that I pay my dues…

 

synscan
http://bindshell.net/tools/synscanThe fastest half-open portscanner that I’m aware of. I borrowed the code for determining link-layer header lengths from synscan. 
nmap
http://insecure.org/nmapThe most reliable portscanner I’m aware of. I use nmap during every pentest. Most of yapscan’s options are designed to be intuitive for nmap users. 
ike-scan
http://www.nta-monitor.com/tools/ike-scanHostlist structures and retries are heavily inspired by ike-scan. 
hping2
http://www.hping.orgThe output format is loosley based on hping2′s. 
scanrand
http://www.doxpara.com/pakettoI love the Inverse SYN Cookies idea. Very simple method to determine if replies on the wire are meant for your scanner or some other app. 

Tags: , ,

Posted in Misc