|
1 | | -# Enumerate Applications on Webserver |
| 1 | +# Attack Surface Identification |
2 | 2 |
|
3 | 3 | |ID | |
4 | 4 | |------------| |
5 | 5 | |WSTG-INFO-04| |
6 | 6 |
|
7 | 7 | ## Summary |
8 | 8 |
|
9 | | -A paramount step in testing for web application vulnerabilities is to find out which particular applications are hosted on a web server. Many applications have known vulnerabilities and known attack strategies that can be exploited in order to gain remote control or to exploit data. In addition, many applications are often misconfigured or not updated, due to the perception that they are only used "internally" and therefore no threat exists. |
10 | | -With the proliferation of virtual web servers, the traditional 1:1-type relationship between an IP address and a web server is losing much of its original significance. It is not uncommon to have multiple sites or applications whose symbolic names resolve to the same IP address. This scenario is not limited to hosting environments, but also applies to ordinary corporate environments as well. |
| 9 | +Identifying the attack surface of a web application involves discovering all applications, domains, virtual hosts, and externally exposed services associated with the target infrastructure. This process extends beyond identifying hosted applications and includes DNS enumeration, subdomain discovery, virtual host analysis, non-standard ports, and the review of digital certificates and Certificate Transparency logs. |
| 10 | + |
| 11 | +With the proliferation of virtual hosting and shared infrastructure, the traditional 1:1 relationship between an IP address and a web server has largely disappeared. A single IP address may host multiple applications across different domains, environments, or administrative interfaces. Failing to identify these assets can result in incomplete assessments and overlooked vulnerabilities. |
11 | 12 |
|
12 | 13 | Security professionals are sometimes given a set of IP addresses as a target to test. It is arguable that this scenario is more akin to a penetration test-type engagement, but in any case it is expected that such an assignment would test all web applications accessible through this target. The problem is that the given IP address hosts an HTTP service on port 80, but if a tester should access it by specifying the IP address (which is all they know) it reports "No web server configured at this address" or a similar message. But that system could "hide" a number of web applications, associated to unrelated symbolic (DNS) names. Obviously, the extent of the analysis is deeply affected depending on whether the tester tests all the applications or only tests the applications that they are aware of. |
13 | 14 |
|
14 | 15 | Sometimes, the target specification is richer. The tester may be given a list of IP addresses and their corresponding symbolic names. Nevertheless, this list might convey partial information, i.e., it could omit some symbolic names and the client may not even be aware of that (this is more likely to happen in large organizations). |
15 | 16 |
|
16 | 17 | Other issues affecting the scope of the assessment are represented by web applications published at non-obvious URLs (e.g., `https://www.example.com/some-strange-URL`), which are not referenced elsewhere. This may happen either by error (due to misconfigurations), or intentionally (for example, unadvertised administrative interfaces). |
17 | 18 |
|
18 | | -To address these issues, it is necessary to perform web application discovery. |
| 19 | +To address these issues, a comprehensive attack surface identification process must be performed. |
19 | 20 |
|
20 | 21 | ## Test Objectives |
21 | 22 |
|
22 | | -- Enumerate the applications within the scope that exist on a web server. |
| 23 | +- Enumerate all web applications within scope. |
| 24 | +- Identify DNS names, domains, and virtual hosts associated with the target. |
| 25 | +- Discover additional domains and subdomains using passive and active DNS techniques. |
| 26 | +- Analyze digital certificates and Certificate Transparency logs for additional hostnames. |
23 | 27 |
|
24 | 28 | ## How to Test |
25 | 29 |
|
@@ -118,6 +122,43 @@ The same task may be performed by vulnerability scanners, but first check that t |
118 | 122 |
|
119 | 123 | There are a number of techniques which may be used to identify DNS names associated to a given IP address `x.y.z.t`. |
120 | 124 |
|
| 125 | +#### DNS Enumeration |
| 126 | + |
| 127 | +DNS enumeration aims to identify domains, subdomains, and related DNS records associated with the target organization to expand the assessment scope. DNS enumeration plays a key role in identifying additional virtual hosts mapped to the same IP address. This may reveal development systems, staging environments, legacy services, or administrative interfaces. |
| 128 | + |
| 129 | +Both passive and active techniques can be used. |
| 130 | + |
| 131 | +#### Passive DNS Enumeration |
| 132 | + |
| 133 | +Passive techniques do not directly interact with the target infrastructure and instead rely on publicly available data sources. Examples include: |
| 134 | + |
| 135 | +- Public DNS records (A, AAAA, MX, TXT, NS) |
| 136 | +- Reverse DNS lookups (PTR records) |
| 137 | +- Search engines |
| 138 | +- Passive DNS databases |
| 139 | +- Certificate Transparency logs |
| 140 | + |
| 141 | +Passive techniques are preferred during early reconnaissance phases to avoid detection. |
| 142 | + |
| 143 | +#### Active DNS Enumeration |
| 144 | + |
| 145 | +Active techniques directly query the target's DNS infrastructure and may generate logs on the target systems. These include: |
| 146 | + |
| 147 | +- Subdomain brute forcing |
| 148 | +- DNS zone transfer attempts |
| 149 | +- DNS record enumeration using tools |
| 150 | + |
| 151 | +Common tools used for DNS enumeration include: |
| 152 | + |
| 153 | +- `amass` |
| 154 | +- `subfinder` |
| 155 | +- `dnsrecon` |
| 156 | +- `fierce` |
| 157 | +- `dig` |
| 158 | +- `nslookup` |
| 159 | + |
| 160 | +Example using `dig`: `dig example.com ANY` |
| 161 | + |
121 | 162 | #### DNS Zone Transfers |
122 | 163 |
|
123 | 164 | This technique has limited use nowadays, given the fact that zone transfers are largely not honored by DNS servers. However, it could still be worth attempting. First of all, testers must determine the name servers serving `x.y.z.t`. If a symbolic name is known for `x.y.z.t` (let it be `www.example.com`), its name servers can be determined by means of tools such as `nslookup`, `host`, or `dig`, by requesting DNS NS records. |
@@ -185,11 +226,41 @@ Subject: C = US, ST = California, L = Los Angeles, O = Internet Corporation for |
185 | 226 | DNS:www.example.org, DNS:example.com, DNS:example.edu, DNS:example.net, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net |
186 | 227 | ``` |
187 | 228 |
|
| 229 | +#### Certificate Transparency Logs |
| 230 | + |
| 231 | +Certificate Transparency (CT) logs are publicly accessible records of issued TLS certificates. These logs can be searched to identify hostnames and subdomains associated with a target organization, including staging systems, administrative interfaces, legacy systems, or other externally reachable services. |
| 232 | + |
| 233 | +Reviewing CT logs may reveal hostnames that are not directly discoverable through DNS zone transfers, reverse lookups, or search engine queries alone. Testers should extract discovered hostnames and validate them through DNS resolution to determine whether they are active and within the defined scope of the assessment. |
| 234 | + |
| 235 | +When reviewing CT log data, consider: |
| 236 | + |
| 237 | +- Hostnames indicating development, staging, or testing environments. |
| 238 | +- Administrative or management interfaces. |
| 239 | +- Deprecated or legacy systems that may still be accessible. |
| 240 | +- Wildcard certificates that may imply additional undiscovered subdomains. |
| 241 | + |
| 242 | +Information gathered from CT logs should be validated to confirm ownership and relevance before further testing. |
| 243 | + |
| 244 | +Care must be taken to respect scope limitations defined in the engagement. |
| 245 | + |
| 246 | +Discovered assets should be validated and documented before further testing activities. |
| 247 | + |
| 248 | +One common approach to querying CT logs is to use publicly available search portals that aggregate certificate data. For example, a tester may search for certificates issued to `example.com` and review the listed subdomains. |
| 249 | + |
| 250 | +For instance: `https://crt.sh/?q=%25.example.com` |
| 251 | + |
| 252 | + |
| 253 | + |
| 254 | +*Figure 4.1.4-1: Example of Certificate Transparency log search results.* |
| 255 | + |
| 256 | +The results may list subdomains such as `dev.example.com`, `staging.example.com`, or other hostnames that are not directly referenced from the primary site. Discovered hostnames should be validated through DNS resolution before further testing. |
| 257 | + |
188 | 258 | ## Tools |
189 | 259 |
|
190 | | -- DNS lookup tools such as `nslookup`, `dig` and similar. |
191 | | -- Search engines (Google, Bing, and other major search engines). |
192 | | -- Specialized DNS-related web-based search service: see text. |
| 260 | +- DNS lookup tools such as `nslookup`, `dig`, and `host` |
| 261 | +- Subdomain enumeration tools such as `amass`, `subfinder`, `dnsrecon`, and `fierce` |
| 262 | +- Search engines (Google, Bing, and other major search engines) |
| 263 | +- Reverse IP lookup services |
193 | 264 | - [Nmap](https://nmap.org/) |
194 | 265 | - [Nessus Vulnerability Scanner](https://www.tenable.com/products/nessus) |
195 | | -- [Nikto](https://www.cirt.net/nikto2) |
| 266 | +- [Nikto](https://github.com/sullo/nikto) |
0 commit comments