21/03/2012

Quick Reference on Port Scanning

Intro

This article is about basic types of port scanning.

Port States (taking from Nmap man page)

open

An application is actively accepting TCP connections, UDP datagrams or SCTP associations on this port.

closed

A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then they would appear in the filtered state, discussed next.

filtered

Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common.

unfiltered

The unfiltered state means that a port is accessible, but Nmap is unable to determine whether it is open or closed. Only the ACK scan, which is used to map firewall rulesets, classifies ports into this state. Scanning unfiltered ports with other scan types such as Window scan, SYN scan, or FIN scan, may help resolve whether the port is open.

open|filtered

Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.

closed|filtered

This state is used when Nmap is unable to determine whether a port is closed or filtered. It is only used for the IP ID idle scan.

TCP SYN scan (with Hping2)

Scanner --- SYN (Sequence Number Set to 1) ---> Target
Scanner <- SYN/ACK (Sequence Number Set 0 and Acknowledgment Set 0) - Target
Scanner --- RST (Sequence Number Set Again to 1) ---> Target (Only if host listens)

Note: Scanner Viciously Dropped The Connection.

Or

Scanner --- RST/ACK ---> Target (Not used by Hping2 connection termination pattern)

Note: Graciously Terminated connection? (both parties have ti exchange an ACK flag), see below.

Scanner --- FIN ---> Target
Scanner <--- FIN/ACK --- Target
Scanner --- ACK ---> Target

Only a SYN packet is sent to the target port.If a SYN/ACK is received from the target port, we can deduce that it is in the LISTENING state. If a RST/ACK is received, it usually indicates that the port is not listening, but we can deduce that the host is up. A RST/ACK or RST can be sent by the system performing the port scan so that a full connection is never established (also known as half open connections).

Half Open Connections in SYN scans

A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can. The terminating side should continue reading the data until the other side terminates as well (always based in RFC's).

Connection termination in port scanning?

The connection termination phase uses, at most, a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint. After both FIN/ACK exchanges are concluded, the terminating side waits for a timeout before finally closing the connection, during which time the local port is unavailable for new connections; this prevents confusion due to delayed packets being delivered during subsequent connections.It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK. This is perhaps the most common method.

TCP ACK scan (with Hping2)

Scanner - ACK (Sequence Number Set 0 and Acknowledgment Set 0)-> Target
Scanner <--- RST (Sequence Number Set Again to 1) ---> Target

Or

Scanner <--- Connection Timeout or Sent ICMP Error --- Target

The ACK scan probe packet has only the ACK flag set (unless you use --scanflags with Nmap). When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don't respond, or send certain ICMP error messages back (type 3, code 1, 2, 3, 9, 10, or 13), are ussually labeled filtered by Nmap.

TCP Full Handshake or Connect scan (with Hping2)

Scanner --- SYN (Sequence Number Set to 0) ---> Target
Scanner <--- SYN/ACK (Sequence Number Set 0 and Acknowledgment Set 1) --- Target
Scanner --- ACK (Sequence Number Set 1 and Acknowledgment Set 1) ---> Target
Scanner --- FIN/ACK ---> Target
Scanner <--- ACK --- Target

Or

Scanner --- RST ---> Target (Nmap terminates the connection this way!)

Note: This type of scans might be logged from firewalls based always type and configuration of firewalls.

UDP scan (with Hping2)

Scanner --- UDP ---> Target
Scanner <--- ICMP error (for closed ports) --- Target
Scanner <--- Connection Timeout (for open or filtered ports) --- Target

When a UDP packet is sent to a port that is not open, the system will respond with an ICMP port unreachable message. Most UDP port scanners use this scanning method, and use the absence of a response to infer that a port is open. However, if a port is blocked by a firewall, this method will falsely report that the port is open.

TCP NULL scan (with Hping2)

Scanner --- NULL ---> Target (All flags is set to 0)
Scanner <--- RST --- Target

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered from firewall that silently drops the
connection)

TCP Null scan This technique turns off all fl ags. Based on RFC 793, the target system should send back an RST for all closed ports.

TCP FIN scan (with Hping2)

Scanner --- FIN ---> Target
Scanner <--- RST --- Target

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered from firewall that silently drops the
connection)

TCP FIN scan This technique sends a FIN packet to the target port. Based on RFC 793 (http://ww.ietf.org/rfc/rfc0793.txt), the target system should send back an RST for all closed ports. This technique usually only works or used to worj on UNIXbased TCP/IP stacks.

TCP Xmas scan (with Hping2)

Scanner --- FIN,URG,PUSH ---> Target
Scanner <--- RST --- Target (For all closed ports, drop connection; works in UNIXboxs)

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered and silently drops the connection)

TCP Xmas Tree scan This technique sends a FIN, URG, and PUSH packet to the target port. Based on RFC 793, the target system should send back an RST for all closed ports.

TCP Window scan (with Hping2)

Scanner - ACK (Sequence Number Set 0 and Acknowledgment Set 0)-> Target
Scanner <--- RST (Sequence Number Set Again to 1) ---> Target


Or

Scanner <--- Connection Timeout or Sent ICMP Error --- Target


Window scan is exactly the same as ACK scan except that it exploits an implementation detail of certain systems to differentiate open ports from closed ones, rather than always printing unfiltered when a RST is returned. It does this by examining the TCP Window field of the RST packets returned. On some systems, open ports use a positive window size (even for RST packets) while closed ones have a zero window. So instead of always listing a port as unfiltered when it receives a RST back, Window scan lists the port as open or closed if the TCP Window value in that reset is positive or zero, respectively.

TCP Mainmon scan (with Hping2 used for BSD hosts)

Scanner --- FIN/ACK ---> Target
Scanner <--- RST (Possibly) --- Target

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered and silently drops the connection)

The Maimon scan is named after its discoverer, Uriel Maimon. He described the technique in Phrack Magazine issue #49 (November 1996). Nmap, which included this technique, was released two issues later. This technique is exactly the same as NULL, FIN, and Xmas scans, except that the probe is FIN/ACK. According to RFC 793 (TCP), a RST packet should be generated in response to such a probe whether the port is open or closed. However, Uriel noticed that many BSD-derived systems simply drop the packet if the port is open.

TCP Idle Scan (using Nmap)

Scanner --- SYN/ACK ---> Zombie
Scanner <--- RST with IP ID = 1 --- Zombie
Scanner --- Forged from zombie SYN ---> Target

Then when open port:

Target --- SYN/ACK ---> Zombie
Target <--- RST IP ID = 2 --- Zombie
Scanner --- SYN/ACK ---> Zombie
Scanner <--- RST IP ID = 3 --- Zombie 

Or when closed or filtered port:

Target --- Timeout  or RST ---> Zombie (With timeout or RST no ID is increased)
Scanner --- SYN/ACK ---> Zombie
Scanner <--- RST IP ID = 2 --- Zombie

Fundamentally, an idle scan consists of three steps that are repeated for each port:
  1. Probe the zombie's IP ID and record it.
  2. Forge a SYN packet from the zombie and send it to the desired port on the target. Depending on the port state, the target's reaction may or may not cause the zombie's IP ID to be incremented.
  3. Probe the zombie's IP ID again. The target port state is then determined by comparing this new IP ID with the one recorded in step 1.
References:

http://www.pcvr.nl/tcpip/udp_user.htm
http://www.techrepublic.com/article/exploring-the-anatomy-of-a-data-packet/1041907
http://www.freesoft.org/CIE/Course/Section3/7.htm

What About Http Header Injection?

Intro 

HTTP Header Injection is an old vulnerability that has been documented very well since 2006 from  Amit Klein. Nowadays lots of products have implemented anti HTTP Header Injection mechanisms. The basic attacks someone can perform through header injection are numerous(e.g. Apache 2.0.55 mod_proxy and Sun Java System Web Proxy Server 4.0, DeleGate 8.11.5).

The key characters that are used to perform that attack are CRLF and LF characters. By saying LF and CRLF attacks I mean the character set of , %0a and %0d the CRLF character is represented as %0d%0a. Generally speaking some can say that an HTTP Header Injection attack can do three types of attacks:
  1. HTTP Response Smuggling
  2. HTTP Splitting
  3. HTTP Request Smuggling
  4. File Download Injection   
Expanding on attacks more:
  • Cross-Site Scripting (XSS): Until now, it has been impossible to mount XSS attacks on sites through a redirection script when the clients use IE 7.0 and above unless the Location header can be fully controlled. With HTTP Response Splitting, it is possible to mount an XSS attack even if the Location header is only partially controlled by the attacker.
  • Web Cache Poisoning (meaning temporary defacement): This is a new attack. The attacker simply forces the target (i.e. a cache server of some sort) to cache the second response in response to the second request. An example is to send a second request to “http://web.site/index.html”, and force the target (cache server) to cache the second response that is fully controlled by the attacker. This is effectively a defacement of the web site, at least as experienced by other web site clients, who use the same cache server. Of course, in addition to defacement, an attacker can steal session cookies, or “fix” them to a predetermined value.
  • Cross User attacks (user specific temporary defacement): As a variant of the attack, it is possible for the attacker not to send the second request. This seems odd at first, but the idea is that in some cases, the target may share the same TCP connection with the server, among several users (this is the case with some cache servers). The next user to send a request to the web server through the target will be served by the target with the second response the attacker generated. The net result is having a client of the web site being served with a resource that was crafted by the attacker. This enables the attacker to “deface” the site for a single page requested by a single user (a local, temporary defacement). Much like the previous item, in addition to defacement, the attacker can steal session cookies and/or set them.
  • Hijacking pages with user-specific information: With this attack, it is possible for the attacker to receive the server response to a user request instead of the user. Therefore, the attacker gains access to user specific information that may be sensitive and confidential.
Where to look for Header Injections

In order to look for this vulnerability, the tester needs to identify all user controlled input that influences one or more headers in the response, and check whether he/she can successfully inject a CR+LF sequence in it. The headers that are the most likely candidates for this attack are: 
  • Location
  • Set-Cookie
About the HTTP Location header

The HTTP Location header is returned in responses from an HTTP server under two circumstances:

1.To ask a web browser to load a different web page. It is passed as part of the response by a web server when the requested URI has:
  • Moved temporarily
  • Moved permanently
In this circumstance, the Location header should be sent with an HTTP status code of 3xx.

2. To provide information about the location of a newly-created resource.In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202. While the INTERNET standard RFC 1945 (HTTP 1.0) requires a complete absolute URI for redirection, the most popular web browsers tolerate the passing of a relative URL as the value for a Location header.

 About the HTTP Set-Cookie header 

The HTTP Set-Cookie header is sent only if the server wishes the browser to store cookies. Set-Cookie is a directive for the browser to store the cookie and sends it back in future requests to the server (subject to expiration time or other cookie attributes), if the browser supports cookies and cookies are enabled.

An example of Http Header Injection

The following example leads according to OWASP Top 10 to Unvalidated Forwards and Redirects which is characterized to as A10 (low risk). 

The Client Http Request:
GET /changelocale.do?lang=el_GR&return=b98f6%0d%0a35306e9b215 HTTP/1.1
Host: my.victim.gr
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Referer: http:// my.victim.gr /info/index.do
Cookie: JSESSIONID=679F1E163E33F1985E9595D7CA99AA50; JSESSIONIDSSO=B72AD94DC4A73B7BB3B0C0D908AC14D4
DNT: 1

The Server Http Response:
HTTP/1.1 302 Moved Temporarily
Date: Fri, 09 Mar 2012 13:09:55 GMT
Server: Apache/2.0.46 (Red Hat)
Set-Cookie: JSESSIONIDSSO=B72AD94DC4A73B7BB3B0C0D908AC14D4; Expires=Thu, 01-Jan-1970 00:00:10 GMTLocation: http:// my.victim.gr /b98f635306e9b215
Content-Language: el-GR
Content-Length: 0
Connection: close
Content-Type: text/html;charset=ISO-8859-7

In this example we can see that the variable return set's the Location Http Header to an internal redirect (same domain redirect , url), which is not such a big issue.  From that example we can understand that an attacker does not have to aim particularly for the Http Location header or Http Set-Cookie header. Redirects can happen by manipulating also the variable that are written to Http Headers.

Another example

While using the same web application by manipulating the return variable we can create to Open redirection attacks:

Http Client Request:

GET //changelocale.do?locale=rrr&return=http://www.google.com HTTP/1.1
Host: my.victim.gr
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Cookie: JSESSIONID=9B012A669272DAE64F37A9F299C712F8
DNT: 1

Http Server Response:
HTTP/1.1 302 Moved Temporarily
Date: Wed, 21 Mar 2012 12:48:02 GMT
Server: Apache/2.0.46 (Red Hat)
Set-Cookie: JSESSIONID=A1945F44A0286E2861C7FF29622C9092; Path=/
Location: http://www.google.com
Content-Language: 3fa28
2f5a989697
Content-Length: 0
Connection: close
Content-Type: text/html;charset=ISO-8859-1

Following the redirect would go to www.google.com
HTTP/1.1 302 Found
Location: http://www.google.gr/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=www.google.com
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.www.google.com
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=google.com
Set-Cookie: JSESSIONID=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.google.com
Set-Cookie: PREF=ID=32220ea34784094e:FF=0:TM=1332331816:LM=1332331816:S=HH0lu29CjkyrKw96; expires=Fri, 21-Mar-2014 12:10:16 GMT; path=/; domain=.google.com
Set-Cookie: NID=58=YNMgIzggmzZizztb1UOjCBemBW8lNc6OM2uRV95769PX-bxF_gFS759DYRUsqIC671ZdNVDhWW9O4f4LSr-baWhGX61rZPyrcPjMCNpEzgdw5PHaqJAPjTXG3pZtkKjr; expires=Thu, 20-Sep-2012 12:10:16 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Date: Wed, 21 Mar 2012 12:10:16 GMT
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

Explanation: So we managed to perform a Location Http Header injection without using the CRLF character. We injected a URL to the variable , then received two 302 http redirects and then we were sent to google.com.

References:

  1. http://lists.grok.org.uk/pipermail/full-disclosure/2006-February/042358.html
  2. http://packetstorm.codar.com.br/papers/general/whitepaper_httpresponse.pdf
  3. https://www.owasp.org/index.php/Testing_for_HTTP_Splitting/Smuggling_(OWASP-DV-016)#HTTP_Splitting
  4. http://en.wikipedia.org/wiki/HTTP_location
  5. http://en.wikipedia.org/wiki/HTTP_cookie