Divide and Conquer Real World Distributed Port Scanning

(1)

Divide and Conquer

Real World Distributed Port Scanning

Divide and Conquer

Real World Distributed Port Scanning

Ofer Maor CTO Hacktics

16 Feb 2006 – Hackers & Threats I, 3:25PM (HT1-302)

Ofer Maor CTO Hacktics

(2)

Introduction

•

“Divide and Conquer: Real World Distributed Port Scanning”

reviews conventional port scanning and distributed port scanning techniques, suggesting new approaches for implementing

distributed port scanning in virtually any environment.

•

After a short overview of port scanning we will examine the

reasoning behind port scanning prevention and mechanisms which are used for such preventions.

(3)

Introduction

•

This presentation is all about live demonstrations – discussed topics will be explained through actual execution of probes and scans.

•

Today’s Objectives:

—

Prove that conventional port scanning prevention does not

really prevent port scanning, but rather creates a false sense of security

—

Provide security professionals with a new technique and a tool to conduct distributed port scans

(4)

Port Scanning Overview

•

Port Scanning is the process of identifying some or all open ports (listening services) on one or more hosts.

•

Usually conducted using automated tools, which can quickly scan through the entire potential port range (0-65535) of a server or

search for selected common or expected ports.

•

It is a crucial part of the attack’s reconnaissance phase, and is one of the first tasks done by an attacker when attempting to break into a machine.

•

Free and commercial port scanners are widely available, varying in supported features, user interface and environment. The NMap

(5)

Port Scanning Overview

(6)

Port Scanning Overview

•

Port Scanning is normally done by going over all (or some) TCP and/or UDP ports and checking the status of each port by

attempting to communicate with it.

•

With TCP scanning, three potential responses are available:

—

If an entire TCP handshake has been completed – the port is open.

—

If the server refuses the connection – the port is closed.

—

If no response at all is received (or if the firewall rejected the request) – the port is filtered.

•

Similarly, half-open scanners that examine only the second phase of the handshake (SYN/ACK or RST/ACK) can be used for

(7)

Port Scanning Prevention

•

With the growing popularity of port scanning, many organizations felt the need to create protection against it (rather than solving the true problem at hand).

•

This functionality is provided by various Intrusion Detection (or Prevention) Systems, known as IDS/IPS. These systems are

capable of identifying multiple connection requests from a single host and block the IP address of this host.

•

Most modern IDS/IPSs, including open source solutions such as Snort®, are

capable of providing a working mechanism to protect against conventional port

(8)

Divide and Conquer: Distributed Port Scanning

•

In order to overcome port scanning protection, the next step in the evolution of the attack was the distributed approach. .

•

The idea behind Distributed Port Scanning is to split the effort of the port scanning, having each host probe only few ports, thus not getting blocked by the system.

•

The gap between theory and practice, however, lies in the ability to control hundreds or thousands of hosts to perform this attack for the hacker or for the auditor.

(9)

Divide and Conquer: Distributed Port Scanning

•

Studies from last years show that large zombie networks can be

purchased for 2,000-3,000$.

•

Smaller networks are available for 500$ as well.

(10)

The Auditor’s Problem

•

Security professionals, such as auditors and pentesters, can not rely on zombies to do the work, as running such a zombie network is highly unethical, as well as illegal in most countries.

(11)

The FTP Bounce Solution

•

A workaround to this problem appeared in the form of the FTP Bounce Attack.

•

This attack allows taking advantage of a feature of the FTP

protocol, allowing a client connecting to an FTP server to instruct it to connect to a third machine on an arbitrary port.

•

This behavior provided an opportunity for a wide variety of attacks, including the execution of distributed port scanning.

•

Modern FTP servers are no longer vulnerable to FTP Bounce attacks (and most firewalls block them as well). While this is

(12)

The Idle Scan Solution

•

A similar workaround to this problem appeared later on in the form of the Idle scan.

•

This type of scan takes advantage of the common behavior of IP stack implementation, which increment an identifier known as the “fragment identification” by one for every packet they send.

•

It is therefore possible to spoof a packet supposedly originating from a 3rd party host, then examining the fragment identification of that host (if the port answered back to the host, this number will be incremented).

(13)

Finding a Widely Available Resource

•

The solution to distributed port scanning must therefore present itself using a resource complying to the following criteria:

—

Widely Available – To ensure that a large network can be easily created, evading the most sensitive port scanning protection.

—

Free – To guarantee that anyone wishing to perform such an assessment is capable of doing so.

—

Legal – Does not require the auditor to perform hostile acts against hosts on the internet.

(14)

(15)

Real World Distributed Port Scanning

•

Using HTTP Proxies, it is therefore possible to achieve a real world solution for the auditor problem, allowing easy execution of

distributed port scanning.

•

The HTTP proxy based scanning can be achieved in one of two main techniques:

—

Via HTTP CONNECT requests – Easy, but rare.

(16)

HTTP CONNECT Scan

•

The CONNECT method is part of the HTTP RFC and is designed to allow tunneling of traffic which can not be normally proxied, such as HTTPS data.

•

The usage of CONNECT as a port scanner is trivial – The proxy is contacted, and a CONNECT request is being sent to the proxy,

requesting it to connect to the probed port.

•

If the port is available, the following response is presented, identifying it as an open port:

HTTP/1.0 200 Connection established

(17)

HTTP CONNECT Scan

•

Alternatively, the proxy will return a “Connection Refused” or

“Gateway Timeout” error to indicate that the port was not available.

•

By using CONNECT probing it is therefore possible to identify the 3

possible states of the port: Opened, Closed or Filtered.

•

While the HTTP Proxy Port Scanner Tool supports HTTP

CONNECT requests, this type of scan can not be relied upon, due to two key factors

—

Many free proxies will not support the CONNECT method at all

(18)

HTTP Proxy Response Fingerprinting

•

The HTTP method supported by virtually all free proxies is GET

•

While GET requests are not aimed at performing a TCP connect at the remote host, they do however connect as part of the process,

and can also be used to connect to non standard ports by providing the port number after the host name, such as http://host:1234/

•

By relying on this functionality, it is possible to effectively instruct the proxy to connect to

remote hosts using arbitrary ports.

•

While the response is not clear as with the

(19)

HTTP Proxy Response Fingerprinting

•

Like other fingerprinting mechanisms, such as OS fingerprinting or HTTP Server fingerprinting, the basic idea was to map out the

behavior of common proxy servers available on the internet when attempting to connect to various types of open, closed and filtered ports.

•

After analyzing the list of given proxies, it is possible to run the same tests against scanned machines, identifying open ports,

while distributing the test between the thousands of different free proxies.

(20)

HTTP Proxy Response Fingerprinting

Response I: HTTP/1.0 200 OK HTTP/1.0 200 OK HTTP/1.0 200 OK HTTP/1.0 200 OK Location: Location: Location:

Location: SomeSiteSomeSiteSomeSiteSomeSite Content

Content Content

Content----Type: text/htmlType: text/htmlType: text/htmlType: text/html Server: Microsoft

Server: Microsoft Server: Microsoft

Server: Microsoft---IIS-IISIISIIS Content

Content Content

Content----Length: 214Length: 214Length: 214Length: 214

Date: Mon, 13 Jun 2005 23:07:58 GMT Date: Mon, 13 Jun 2005 23:07:58 GMT Date: Mon, 13 Jun 2005 23:07:58 GMT Date: Mon, 13 Jun 2005 23:07:58 GMT …

… … …

(21)

HTTP Proxy Response Fingerprinting

Response II:

+OK Welcome to +OK Welcome to +OK Welcome to

+OK Welcome to MailEnableMailEnableMailEnableMailEnable POP3 ServerPOP3 ServerPOP3 ServerPOP3 Server

--ERR Unknown commandERR Unknown commandERR Unknown commandERR Unknown command

(22)

HTTP Proxy Response Fingerprinting

Response III:

220 220 220

220 domain.comdomain.comdomain.comdomain.com ESMTP ESMTP ESMTP ESMTP MailEnableMailEnable Service, Version: 1.73MailEnableMailEnable Service, Version: 1.73Service, Version: 1.73--Service, Version: 1.73--- ready at ready at ready at ready at 04/20/05 21:25:32

04/20/05 21:25:32 04/20/05 21:25:32 04/20/05 21:25:32

503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands 503 Bad sequence of commands

(23)

HTTP Proxy Response Fingerprinting

Response IV: HTTP/1.0 503 Service Unavailable HTTP/1.0 503 Service Unavailable HTTP/1.0 503 Service Unavailable HTTP/1.0 503 Service Unavailable Server: Squid/2.3.STABLE1 Server: Squid/2.3.STABLE1 Server: Squid/2.3.STABLE1 Server: Squid/2.3.STABLE1 Mime Mime Mime

Mime----Version: 1.0Version: 1.0Version: 1.0Version: 1.0

Date: Mon, 13 Jun 2005 22:29:56 GMT Date: Mon, 13 Jun 2005 22:29:56 GMT Date: Mon, 13 Jun 2005 22:29:56 GMT Date: Mon, 13 Jun 2005 22:29:56 GMT Content

Content Content

Content----Type: text/htmlType: text/htmlType: text/htmlType: text/html Content

Content Content

Expires: Mon, 13 Jun 2005 22:29:56 GMT Expires: Mon, 13 Jun 2005 22:29:56 GMT Expires: Mon, 13 Jun 2005 22:29:56 GMT Expires: Mon, 13 Jun 2005 22:29:56 GMT X

X X

X----SquidSquidSquid-Squid---Error: ERR_CONNECT_FAIL 111Error: ERR_CONNECT_FAIL 111Error: ERR_CONNECT_FAIL 111Error: ERR_CONNECT_FAIL 111 X

X X

X----Cache: MISS from proxyCache: MISS from proxyCache: MISS from proxyCache: MISS from proxy Proxy

Proxy Proxy

Proxy---Connection: close-Connection: closeConnection: closeConnection: close …

… … …

(24)

HTTP Proxy Response Fingerprinting

… … … …

While trying to retrieve the URL: While trying to retrieve the URL: While trying to retrieve the URL: While trying to retrieve the URL:

<A HREF="http://MyHost:1053/">http://MyHost:1053/</A> <A HREF="http://MyHost:1053/">http://MyHost:1053/</A> <A HREF="http://MyHost:1053/">http://MyHost:1053/</A> <A HREF="http://MyHost:1053/">http://MyHost:1053/</A>

The following error was encountered: The following error was encountered: The following error was encountered: The following error was encountered: <UL> <UL> <UL> <UL> <LI> <LI> <LI> <LI> Connection Failed Connection Failed Connection Failed Connection Failed </UL> </UL> </UL> </UL>

The system returned: The system returned: The system returned: The system returned:

<PRE> (111) Connection refused</PRE> <PRE> (111) Connection refused</PRE> <PRE> (111) Connection refused</PRE> <PRE> (111) Connection refused</PRE>

The remote host or network may be down. Please try the request The remote host or network may be down. Please try the request The remote host or network may be down. Please try the request The remote host or network may be down. Please try the request again.

again. again. again.

Your cache administrator is <A HREF=" Your cache administrator is <A HREF=" Your cache administrator is <A HREF="

Your cache administrator is <A HREF="mailto:rootmailto:rootmailto:rootmailto:root">root</A>. ">root</A>. ">root</A>. ">root</A>. …

(25)

HTTP Proxy Response Fingerprinting

Response V:

HTTP/1.0 504 Gateway Time HTTP/1.0 504 Gateway Time HTTP/1.0 504 Gateway Time

HTTP/1.0 504 Gateway Time----outoutoutout Server: Squid/2.3.STABLE1 Server: Squid/2.3.STABLE1 Server: Squid/2.3.STABLE1 Server: Squid/2.3.STABLE1 Mime Mime Mime

Mime----Version: 1.0Version: 1.0Version: 1.0Version: 1.0

Date: Mon, 13 Jun 2005 22:34:31 GMT Date: Mon, 13 Jun 2005 22:34:31 GMT Date: Mon, 13 Jun 2005 22:34:31 GMT Date: Mon, 13 Jun 2005 22:34:31 GMT Content

Content Content

Content----Type: text/htmlType: text/htmlType: text/htmlType: text/html Content

Content Content

Expires: Mon, 13 Jun 2005 22:34:31 GMT Expires: Mon, 13 Jun 2005 22:34:31 GMT Expires: Mon, 13 Jun 2005 22:34:31 GMT Expires: Mon, 13 Jun 2005 22:34:31 GMT X

X X

X----SquidSquidSquid-Squid---Error: ERR_CONNECT_FAIL 110Error: ERR_CONNECT_FAIL 110Error: ERR_CONNECT_FAIL 110Error: ERR_CONNECT_FAIL 110 X

X X

X----Cache: MISS from proxyCache: MISS from proxyCache: MISS from proxyCache: MISS from proxy Proxy

Proxy Proxy

Proxy---Connection: close-Connection: closeConnection: closeConnection: close …

… … …

(26)

HTTP Proxy Response Fingerprinting

•

As can be easily seen from these cases, Squid’s behavior is easy to fingerprint in order to use it as a port scanner:

—

When the data returned is a valid HTTP response with 503 as its response code, the port is Closed.

—

When the data returned is a valid HTTP response with 504 as its response code, the port is Filtered. (Note that unlike with NMap scanning, filtered only applies to dropped requests)

—

When the data returned is not an HTTP response, or is an HTTP response with a different code, the port is Open.

(27)

Fingerprinting Pitfalls

•

The main problem when performing such probing are limitations presented by the proxy itself.

—

Some proxies allow port 80 only

—

Some proxies allow port 80 and high ports only

—

Some proxies allow only other specific ports

•

In such case the proxy returns an error or simply ignores the request.

•

Additionally, some proxies may not have as distinct fingerprints as Squid does, making differentiation between closed and filtered

(28)

Fingerprinting Pitfalls

•

And some more proxy (pit)falls…

(29)

Distributed Proxy Port Scanning Tool

•

Moving from theory to practice – Hacktics’ Distributed Proxy Port Scanning Tool

•

The tool allows auditors and security professionals to perform a distributed port scan, through automation of the entire process:

—

Identifying free available HTTP proxies

—

Checking whether identified proxies can be used for port scanning

—

Identifying the relevant fingerprints of proxies in the list

—

Executing a port scan against a list of all (or selected) TCP ports, through distribution of requests between all proxies

(30)

Additional Potential Use

•

Using a similar framework, it is possible to:

—

Perform distributed vulnerability scanning, defeating IDS IP-based aggregation

—

Distribute web application attacks, thwarting off all IP-based protection and aggregation

—

Test for weaknesses against distributed denial of service attacks

(31)

Conclusion

•

Using IDS to prevent port scanning provides false sense of security against focused attacks. Similarly, all aggregated IP based blocking can easily be overcome by distributed means.

•

Effective protection must come in the form of a hardened environment, which does not rely on obscurity for achieving security and will not be put under a threat by a mere port scan.

•

Moreover, performing IP based blocking allows hackers to easily

cause denial of service attacks of commercial proxies.

(32)

(33)

Additional Information

The detailed paper which this presentation was based on, as well as the tool presented during

the presentation can be found at:

http://www.hacktics.com/resources.html

For additional information or discussion of these topics, feel free to contact us:

(34)

Presentation Resources

•

NMap Tool & Information: http://www.insecure.org/nmap/

•

USA Today Zombie Network Article:

http://www.usatoday.com/tech/news/computersecurity/2004-09-08-zombieprice_x.htm

•

FTP Bounce Attack Information:

http://www.cert.org/advisories/CA-1997-27.html

•

Free Proxies Statistics