Questions about this topic? Sign up to ask in the talk tab.
Classes/Logs/2012/September/18/02-03
From NetSec
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
