Classes/Logs/2012/September/18/02-03

02:07:55 <foo>	So last class we covered using open source information (public information, registration records, etc.) to map a network without touching it
02:08:16 <foo>	today we're going to touch it, interrogate it and generally get it to tell us all its dirty little secrets
02:09:10 <foo>	now let's open up a console and start looking at what nmap can do, we may cover some other tools as time allows but for now we're going to focus on nmap 
02:10:35 <foo>	a lot of what we're going to talk about can be done with scapy, netcat/socat and some other tools but nmap gives us built in LUA integration which we may get to a bit later so stay tuned. 
02:11:34 <foo>	Starting out, load up the nmap man pages in a browser and run: $ nmap --help 
02:11:36 <foo>	http://nmap.org/book/man.html
02:12:18 <foo>	in another window, load up tcpdump so we can start looking at what nmap is doing
02:12:34 <foo>	tcpdump -Xalvv gives some nice verbosity and the hex values help in packet decoding
02:14:01 <foo>	now you might as well just sudo bash or su - root at this time as we're going to be playing around with raw sockets and the like
02:14:41 <foo>	SCAN TECHNIQUES: -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans -sU: UDP Scan -sN/sF/sX: TCP Null, FIN, and Xmas scans --scanflags <flags>: Customize TCP scan flags -sI <zombie host[:probeport]>: Idle scan -sY/sZ: SCTP INIT/COOKIE-ECHO scans -sO: IP protocol scan
02:14:54 <foo>	horrible paste job, but we have a reference.
02:15:29 <foo>	as you may be aware, TCP requires a three way handshake to connect
02:15:41 <foo>	there is a 4 way handshake, but it breaks things. 
02:16:28 <foo>	SYN, SYN / ACK, and ACK 
02:16:49 <foo>	reference for you: http://en.wikipedia.org/wiki/Transmission_Control_Protocol
02:17:06 <foo>	and http://www.ietf.org/rfc/rfc793.txt
02:17:17 <foo>	The TCP RFC Spec is helpful as a knowledge base. 
02:18:12 <foo>	a TCP SYN Scan (-sS) is also called a half-open scan, because it only does half of the TCP handshake
02:18:28 <foo>	this is advantageous as is a more "stealthy" scan as a full connect() isn't opened
02:18:54 <foo>	So you never move past the TCP stack and don't raise as many alarms
02:19:17 <foo>	So in this case, you send a syn packet
02:19:21 <foo>	and wait.
02:19:35 <foo>	if you receive a SYN / ACK, you know the port is open. 
02:19:49 <foo>	now, if the port isn't open
02:19:58 <foo>	what do you think the host is going to send back? 
02:20:14 <foo>	It's going to say "nah, man" and reset the connection
02:20:22 <foo>	by sending an RST back. 
02:21:32 <foo>	now let's see what this looks like
02:22:16 <foo>	on your own box you can follow along: 
02:22:18 <foo>	nmap -vv -sS -e lo 127.0.0.1
02:22:18 <foo>	Starting Nmap 5.00 ( http://nmap.org ) at 2012-09-18 02:22 UTC
02:22:18 <foo>	NSE: Loaded 0 scripts for scanning.
02:22:20 <foo>	Initiating SYN Stealth Scan at 02:22
02:22:23 <foo>	Scanning localhost.localdomain (127.0.0.1) [1000 ports]
02:22:25 <foo>	Discovered open port 25/tcp on 127.0.0.1
02:22:28 <foo>	Discovered open port 22/tcp on 127.0.0.1
02:22:30 <foo>	Discovered open port 53/tcp on 127.0.0.1
02:22:33 <foo>	Completed SYN Stealth Scan at 02:22, 0.10s elapsed (1000 total ports)
02:22:35 <foo>	Host localhost.localdomain (127.0.0.1) is up (0.000013s latency).
02:22:38 <foo>	Scanned at 2012-09-18 02:22:00 UTC for 0s
02:22:41 <foo>	Interesting ports on localhost.localdomain (127.0.0.1):
02:22:43 <foo>	Not shown: 997 closed ports
02:22:46 <foo>	PORT   STATE SERVICE
02:22:48 <foo>	22/tcp open  ssh
02:22:51 <foo>	25/tcp open  smtp
02:22:53 <foo>	53/tcp open  domain
02:24:26 <foo>	your output from tcpdump is going to look something like this
02:24:28 <foo>	02:24:03.163848 IP (tos 0x0, ttl 40, id 2945, offset 0, flags [none], proto TCP (6), length 44)
02:24:31 <foo>	    localhost.localdomain.38988 > localhost.localdomain.telnet: Flags [S], cksum 0xa388 (correct), seq 3507980576, win 1024, options [mss 1460], length 0
02:24:34 <foo>	        0x0000:  4500 002c 0b81 0000 2806 8949 7f00 0001  E..,....(..I....
02:24:37 <foo>	        0x0010:  7f00 0001 984c 0017 d117 8920 0000 0000  .....L..........
02:24:39 <foo>	        0x0020:  6002 0400 a388 0000 0204 05b4            `...........
02:24:41 <foo>	02:24:03.163878 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
02:24:44 <foo>	    localhost.localdomain.telnet > localhost.localdomain.38988: Flags [R.], cksum 0xbf31 (correct), seq 0, ack 3507980577, win 0, length 0
02:24:47 <foo>	        0x0000:  4500 0028 0000 4000 4006 3cce 7f00 0001  E..(..@.@.<.....
02:24:50 <foo>	        0x0010:  7f00 0001 0017 984c 0000 0000 d117 8921  .......L.......!
02:24:52 <foo>	        0x0020:  5014 0000 bf31 0000                      P....1..
02:24:55 <foo>	02:24:03.164479 IP (tos 0x0, ttl 47, id 15408, offset 0, flags [none], proto TCP (6), length 44)
02:24:58 <foo>	these two packets were received right after each other
02:25:06 <foo>	you can see this by the sequence number
02:25:17 <foo>	seq 3507980576 and ack 3507980577
02:25:45 <foo>	the first packet was sent to the telnet port, port 22
02:25:58 <foo>	er
02:26:00 <foo>	23
02:26:09 <foo>	looking at one thing, saying another. 
02:26:16 <foo>	your first packet is a SYN packet
02:26:20 <foo>	you can tell this by the Flags
02:26:25 <foo>	02:24 <%foo>     localhost.localdomain.38988 > localhost.localdomain.telnet: Flags [S], cksum 0xa388 
02:26:30 <foo>	[S] is for SYN
02:26:46 <foo>	now because the port was closed, the response was a reset [R.]
02:26:50 <foo>	02:24 <%foo>     localhost.localdomain.telnet > localhost.localdomain.38988: Flags [R.], cksum 0xbf31 
02:27:13 <foo>	everyone following so far?
02:28:03 <foo>	bueller?
02:34:09 <foo>	moving on. 
02:34:25 <foo>	by comparison, a full connection to ssh (yes, tcp/22) looks like:
02:34:41 <foo>	02:33:35.580453 IP (tos 0x0, ttl 64, id 59951, offset 0, flags [DF], proto TCP (6), length 60) localhost.localdomain.60197 > localhost.localdomain.ssh: Flags [S], cksum 0xccc1 (correct), seq 221372115, win 32792, options [mss 16396,sackOK,TS val 3062904060 ecr 0,nop,wscale 5], length 0
02:34:55 <foo>	02:33:35.580485 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) localhost.localdomain.ssh > localhost.localdomain.60197: Flags [S.], cksum 0xa539 (correct), seq 494673542, ack 221372116, win 32768, options [mss 16396,sackOK,TS val 3062904060 ecr 3062904060,nop,wscale 5], length 0
02:35:06 <foo>	02:33:35.580506 IP (tos 0x0, ttl 64, id 59952, offset 0, flags [DF], proto TCP (6), length 52) localhost.localdomain.60197 > localhost.localdomain.ssh: Flags [.], cksum 0x8a5b (correct), seq 1, ack 1, win 1025, options [nop,nop,TS val 3062904060 ecr 3062904060], length 0
02:35:13 <foo>	02:33:35.686808 IP (tos 0x0, ttl 64, id 10875, offset 0, flags [DF], proto TCP (6), length 73) localhost.localdomain.ssh > localhost.localdomain.60197: Flags [P.], cksum 0xfe3d (incorrect -> 0xcb7b), seq 1:22, ack 1, win 1024, options [nop,nop,TS val 3062904087 ecr 3062904060], length 21
02:35:27 <foo>	What you see here is an established SSH connection
02:35:38 <foo>	localhost.localdomain.60197 > localhost.localdomain.ssh: Flags [S]
02:35:43 <foo>	localhost.localdomain.ssh > localhost.localdomain.60197: Flags [S.]
02:35:50 <foo>	localhost.localdomain.60197 > localhost.localdomain.ssh: Flags [.]
02:35:58 <foo>	SYN, SYN / ACK, ACK
02:36:07 <foo>	followed by PSH / ACK
02:36:14 <foo>	localhost.localdomain.ssh > localhost.localdomain.60197: Flags [P.]
02:36:50 <foo>	that's what an nmap -sT Connect() scan does. 
02:37:09 *	lejill ([email protected]) has joined #CSIII
02:37:44 <foo>	nmap -sT -vv -p22 127.0.0.1
02:37:45 <foo>	Starting Nmap 5.00 ( http://nmap.org ) at 2012-09-18 02:37 UTC
02:37:46 <foo>	NSE: Loaded 0 scripts for scanning.
02:37:46 <foo>	Initiating Connect Scan at 02:37
02:37:46 <foo>	Scanning localhost.localdomain (127.0.0.1) [1 port]
02:37:46 <foo>	Discovered open port 22/tcp on 127.0.0.1
02:37:48 <foo>	Completed Connect Scan at 02:37, 0.03s elapsed (1 total ports)
02:37:51 <foo>	Host localhost.localdomain (127.0.0.1) is up (0.031s latency).
02:37:53 <foo>	Scanned at 2012-09-18 02:37:14 UTC for 0s
02:37:56 <foo>	Interesting ports on localhost.localdomain (127.0.0.1):
02:37:58 <foo>	PORT   STATE SERVICE
02:38:01 <foo>	22/tcp open  ssh
02:39:06 <foo>	in this case, we're mapping 127.0.0.1 a /32
02:39:34 <foo>	however you can expand this to larger networks such as a /24 with 254 possible hosts. 
02:39:56 <foo>	ccccccbgjikcgkiliievvffkctjbnidjvgrbhtlcjtre
02:41:14 *	manizzle ([email protected]) has joined #CSIII
02:42:15 *	lorentz has quit (Ping timeout)
02:42:22 <foo>	now being able to map TCP ports is important
02:42:34 <foo>	however you also need to be able to identify the other protocols that may be running on the network
02:42:40 *	lorentz ([email protected]) has joined #CSIII
02:42:40 *	DanielBrandt gives channel operator status to lorentz
02:42:47 <foo>	to do this, you would do an IP Protocol scan
02:44:05 <foo>	IP Protocol scans let you know what Protocols, such as TCP, UDP, ICMP, IGMP, etc. are running on a host
02:44:13 <foo>	this is the nmap -sO flag
02:44:47 <foo>	these protocols are identifiable because of the IP Protocol number in the IP header
02:45:29 <foo>	in the excerpt above, you can see the IP Protocol of TCP
02:45:31 <foo>	02:33:35.580453 IP (tos 0x0, ttl 64, id 59951, offset 0, flags [DF], proto TCP (6), length 60)
02:45:45 <foo>	"proto TCP" which is protocol 6. 
02:47:16 *	lejill has quit (client exited: leaving)
02:47:26 *	Tsunami has quit (Ping timeout)
02:48:26 <foo>	so, QUESTIONS?
02:49:41 <hatter>	I know the answer to this
02:49:42 <hatter>	but
02:49:45 <hatter>	I think its a good question to ask
02:50:16 <hatter>	How can I tell the difference between the response from my intended host and a response from one of its upstream routing appliances?
02:50:26 <hatter>	if we're scanning a host for internet protocols
02:50:36 <hatter>	its possible the router may reply in stead of the host.
02:50:56 <foo>	that is most easily determined by comparing TTL values
02:51:25 <foo>	in the packet pastes above
02:51:27 *	codejury ([email protected]) has joined #CSIII
02:51:30 <foo>	you see the ttl value of 64
02:51:40 <foo>	that is the default linux ttl value
02:51:46 <foo>	ttl = Time To Live
02:51:49 <foo>	or otherwise known as hop count
02:51:59 <foo>	in ipv6 its properly renamed hop count
02:52:12 <foo>	the value of 64 is seen because we're scanning localhost
02:52:30 <foo>	so knowing the base TTL value is always useful
02:52:54 <hatter>	both for os fingerprinting as well as for
02:52:58 <foo>	also, doing a traceroute or better tcp traceroute to a known port will get you a baseline ttl value
02:53:04 <hatter>	determining what a response came from
02:53:11 <foo>	that's right. 
02:54:08 <foo>	a tcp traceroute does a connect to a specific host
02:54:26 <foo>	and measures the ttl by incrementing it from 0 between the source and destination
02:54:42 <foo>	this is effective because it causes error messages to be generated as soon as the ttl reaches 0
02:56:10 <foo>	to tie this back to development and coding real quick in our final minutes
02:56:16 *	lejill ([email protected]) has joined #CSIII
02:56:20 <foo>	nmap comes with a powerful scripting engine
02:56:23 <foo>	that interprets LUA
02:56:31 <foo>	for packet analysis
02:56:53 <foo>	http://nmap.org/book/nse.html
02:57:29 <foo>	LUA is pretty basic
02:57:34 <foo>	not to be interpreted as BASIC
02:57:43 <foo>	*crickets*
02:57:53 <foo>	http://www.blackhatlibrary.net/LUA has a quick introduction
02:58:17 <foo>	http://www.lua.org/ has detailed example scripts
02:59:59 <foo>	and that wraps up Introduction to Network Mapping Part 2 - nmap