Information collection for Web Security penetration testing (Part II)

When conducting a security penetration test, we first need to collect as much information as possible for the target application. Therefore, information collection is an essential step for penetration testing. This task can be completed in different ways,

By using search engines, scanners, simple HTTP requests, or specially crafted requests, applications may leak information such as error information, version information, and technologies used. This article describes in detail how to test which applications are running on the target address and how to use messages in advance through error messages.

1. Identify applications

When testing Web application vulnerabilities, the most important step is to find out which applications are hosted on the Web server. Many applications have known vulnerabilities and attack methods, allowing them to gain remote control or access confidential data. In addition, many applications often encounter configuration errors or are not updated for a long time, because some people always think that they are used internally, so they are ignored.

In the past, the relationship between Web servers and IP addresses was usually one-to-one. However, with the rapid growth of virtual Web servers, many websites/applications share the same IP address.

As a security professional, sometimes a group of IP addresses must be processed to test a target server. The problem is that if the given IP address is an HTTP Service hosted on port 80, When you access the service by specifying an IP address, it reports that the address does not have messages such as Web Servers configured. In fact, the system may "hide" many Web applications, but they are given irrelevant Symbol names. Obviously, the breadth of analysis is greatly affected by the tested applications. You may not have noticed them, or just noticed some of them. Sometimes there are many target objects to be tested, such as a column of IP addresses and their corresponding symbol names. Even so, this list may only pass part of the information, that is, it may omit some symbolic names-because even customers do not know them, especially for those large organizations.

Other issues that affect the scope of audit are non-explicit Web applications that do not reference their URLs (such as http://www.example.com/some-strange-URL) from anywhere. This may be caused by incorrect configurations or intentional actions, such as non-public management interfaces. To solve this problem, web application testing is required.

The following describes the black box testing and examples. Web application detection is a process of searching for Web applications on a given infrastructure. These infrastructures are usually defined by a set of IP addresses, or a set of DNS Symbol names, or both. Either a typical penetration test or an application-centric evaluation test, this information needs to be provided before the actual audit. Unless otherwise specified in the employment contract (for example, "only test the application on http://www.example.com/"), audit should be conducted as much as possible, that is, it should find all applications accessible through a given target. In the following example, we will study some technologies that can achieve the above objectives.

Note: The following technologies apply to Internet-oriented Web servers, DNS, and Web-based reverse IP resolution services and search engines. In this example, we use a private IP address (such as 192.168.1.100) to represent a common IP address.

Three factors affect the number of applications related to a given DNS name (or an IP address:

1. Different base URLs

For a Web application, an obvious entry point is logging. In this example ". However, in general, we do not need to publish Web applications in this stealth mode unless you do not want to provide them in a standard way, but secretly inform your users of the specific location of these applications. However, this does not mean that these applications are hidden, but they are not published, but they are still there.

2. Non-Standard Port

Although Web applications are usually located at Port 80 (http) and port 443 (https), Web applications can be bound to any TCP port and referenced by specifying the port number, for example, http [s]: // www.example.com: port /. For example, For example, http://www.example.com: 20000 /.

3. VM

DNS allows us to map a single IP address to one or more Symbol names. For example, IP address 192.168.1.100 can be mapped to the following DNS names: names www.example.com, help;.example.com, and webmail.example.com. A vm generally uses this one-to-multiple method to provide different content. Specifies that the information of the VM we are referencing will be embedded in the Host: Header of HTTP 1.1.

Unless we know help;.example.com and webmail.example.com, we will not doubt that there are other Web applications.

The following describes how to solve these problems:

Solution to problem 1

In fact, we cannot thoroughly find all Web applications that use non-standard names. Because it is non-standard, there are no fixed standards to guide naming, but there are several techniques that penetration testers can use to gain some additional insights. First, if the Web server configuration is incorrect and you are allowed to browse the directory, you may find these applications. The security vulnerability scanner can also help us complete this task. Second, these applications can be referenced through other web pages. Therefore, they can be crawled by web crawlers or indexed by search engines. If we suspect that such a stealth application exists on www.example.com, we can use the site operator to search by google and then use "site: www.example.com" to check the search results. The returned URL may point to these non-explicit applications. Another way is to look at URLs that look like non-public applications. For example, a Web mail front-end can. For management interfaces (for example, a Tomcat Management Interface), you may hide the URL but it is not referenced in any other place. Therefore, it may be helpful to perform a dictionary search. The security vulnerability scanner is also useful in this regard.

Solution 2

It is relatively easy to check Web applications on non-standard ports. For example, you can use a port scanner, such as nmap, and the-sV option to identify services on any port, including the http [s] service. It is necessary to fully scan the 64 k tcp port address space. For example, the following command looks up all open ports whose IP address is 192.168.1.100 and tries to determine which services are bound to them:

Nmap-PN-sT-svs-p0-65535 192.168.1.100

Check the output and find the http or SSL encapsulated service flag. For example, the output result of the preceding command is as follows:

Interesting ports on 192.168.1.100 :( The 65527 ports scanned but not shown below are in state: closed) port state service VERSION22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99) 80/tcp open http Apache httpd 2.0.40 (Red Hat Linux )) 443/tcp open ssl OpenSSL901/tcp open http Samba SWAT administration server1241/tcp open ssl Nessus security scanner3690/tcp open unknown8000/tcp open http-alt? 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1

In this example, we can see that:

◆ There is an Apache HTTP server license on port 80

◆ There seems to be an https server on port 443. Further confirmation is required. For example, you can use a browser to access https: // 192.168.1.100. Bytes

◆ A Samba SWAT Web interface is available on port 901. Bytes

◆ The service on port 1241 is not https, but the Nessus daemon process encapsulated by SSL. Bytes

◆ Port 3690 runs an unspecified service. Bytes

◆ Another unspecified service is located on port 8000, which may be http. It is not uncommon to find the http server on this port. Let's take a look:

$ Telnet 192.168.10.100 8000 Trying 192.168.1.100... connected to 192.168.1.100.Escape character is ^]. GET/HTTP/1.0 HTTP/1.0 200 OKpragma: no-cacheContent-Type: text/htmlServer: MX4J-HTTPD/1.0 expires: nowCache-Control: no-cache...

This indicates that it is actually an HTTP server. In addition, we can use a Web browser to access this URL, or use the GET or HEAD command of Perl to verify it.

Apache Tomcat is running on port 8080.

Of course, this task can also be done through the security vulnerability scanner, provided that your scanner can identify the http [s] service running on a non-standard port. For example, Nessus can identify http [s] services on any port, test known Web server vulnerabilities, and test SSL configurations of https services. As previously suggested, Nessus can recognize popular application/Web interfaces, such as Tomcat management interfaces.

Solution 3

To clarify