5.3 Core Network Services: DHCP, NTP & TFTP

5.3 Core Network Services: DHCP, NTP & TFTP

Enterprise local area networks rely on core infrastructure services to provision network addresses, synchronize cryptographic clocks, and deliver device firmware and configuration baselines. Because these foundational protocols were designed during the formative years of internetworking, they emphasize operational simplicity over cryptographic assurance. When compromised, an attacker can hijack client network routing, execute high-magnitude denial-of-service attacks, break identity authentication systems, or extract cleartext administrative credentials. This section explores the operational mechanics, attack vectors, and hardening protocols for DHCP, NTP, and TFTP.

---

1. Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP), defined in RFC 2131, automates the assignment of IPv4 addresses, subnet masks, default gateway routers, DNS nameservers, and domain search suffixes. It operates over the User Datagram Protocol (UDP):

• UDP Port 67: Destination port for DHCP Servers and Relay Agents.
• UDP Port 68: Destination port for DHCP Clients.

+-----------------------------------------------------------------------------------+
|                         DHCP DORA TRANSACTION SEQUENCE                            |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  DHCP Client (Port 68)                                   DHCP Server (Port 67)    |
|       |                                                             |             |
|       | ---- 1. DHCP DISCOVER (Broadcast: 255.255.255.255) -------> |             |
|       |      Src IP: 0.0.0.0, Dst IP: 255.255.255.255               |             |
|       |      Client Hardware MAC: AA:BB:CC:DD:EE:FF                 |             |
|       |                                                             |             |
|       | <--- 2. DHCP OFFER (Unicast or Broadcast) ----------------- |             |
|       |      Offered IP: 192.168.1.50, Subnet: 255.255.255.0        |             |
|       |      Gateway: 192.168.1.1, DNS: 192.168.1.10, Lease: 86400s |             |
|       |                                                             |             |
|       | ---- 3. DHCP REQUEST (Broadcast: 255.255.255.255) --------> |             |
|       |      Selects Server IP, Confirms Lease Terms                |             |
|       |                                                             |             |
|       | <--- 4. DHCP ACKNOWLEDGE (Unicast or Broadcast) ----------- |             |
|       |      Finalizes IP Lease; Client Binds Network Parameters    |             |
+-----------------------------------------------------------------------------------+

The DORA Exchange Sequence

1. DHCP Discover: The unconfigured client broadcasts a datagram searching for active DHCP servers. Because the client has no assigned IP, the source IPv4 address is set to 0.0.0.0 and the destination is the limited broadcast address 255.255.255.255.
2. DHCP Offer: A listening DHCP server reserves an available IP from its defined address scope and transmits an offer containing the proposed IP address, subnet mask, default gateway, DNS servers, and lease duration.
3. DHCP Request: The client broadcasts its acceptance of the selected server's offer. Broadcasting this request notifies all other DHCP servers that offered leases so they can release their reserved addresses back into their pools.
4. DHCP Acknowledge (ACK): The server commits the lease to its database and transmits an acknowledgment datagram, finalizing the assignment.

Attack Vectors Against DHCP

1. DHCP Starvation Attack

The DHCP address pool (scope) contains a finite number of assignable IP addresses (e.g., 254 addresses in a /24 subnet):

• An attacker connects an automated tool (such as yersinia or dhcpstarv) to an access port.
• The tool generates thousands of spoofed DHCP Discover packets, each advertising a uniquely randomized client hardware MAC address in the Ethernet and BOOTP headers.
• The legitimate DHCP server responds to each request, exhausting its entire pool of available addresses within seconds.
• Result: Legitimate endpoints connecting to the network fail to receive an IP lease, self-assigning a non-routable APIPA address (169.254.0.0/16) and experiencing a total Denial of Service (DoS).

2. Rogue DHCP Server Attack (Man-in-the-Middle)

Once the legitimate DHCP server is starved (or simply by racing to respond faster than the legitimate server over the local switch backplane):

• The attacker deploys an unauthorized Rogue DHCP Server on the local subnet.
• When a new victim host broadcasts a DHCP Discover, the rogue server responds first with a crafted DHCP Offer:
  • Assigned IP: Valid local IP address.
  • Default Gateway: Set to the Attacker's IP Address.
  • Primary DNS Server: Set to the Attacker's IP Address (or an attacker-controlled resolver).
• When the client accepts this lease, all external traffic and DNS resolution queries are forwarded directly through the attacker's system, establishing a transparent, full Man-in-the-Middle (MitM) position.

Defensive Countermeasure: DHCP Snooping

To prevent rogue DHCP servers and starvation attacks, enterprise switches implement DHCP Snooping:

+-----------------------------------------------------------------------------------+
|                             DHCP SNOOPING ARCHITECTURE                            |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|    [ Legitimate DHCP Server ]                                                     |
|                |                                                                  |
|       (Trusted Switch Port) <--- Permits DHCP Offers & ACKs                       |
|                v                                                                  |
|        [ Layer 2 Switch ]                                                         |
|                ^                                                                  |
|      (Untrusted Switch Port) <--- Drops DHCP Offers/ACKs; Rate-Limits Discovers   |
|                |                                                                  |
|     [ Rogue Server / Attacker ]                                                   |
+-----------------------------------------------------------------------------------+

• Trusted Ports: Uplink interfaces connected directly to authorized DHCP servers or trunk links. All DHCP traffic (including Offers and ACKs) is permitted.
• Untrusted Ports: Standard access ports connecting to end-user devices. The switch inspects all incoming DHCP packets on these ports:
  • Any DHCP Offer, DHCP ACK, or DHCP NAK originating from an untrusted port is immediately dropped, blocking rogue DHCP servers.
  • DHCP Discover packet transmission rates are throttled (rate-limited) to prevent starvation flooding.
  • DHCP Snooping Binding Database: The switch dynamically builds an internal table tracking MAC Address, Assigned IP, Lease Time, VLAN ID, and Switch Port. This database serves as the authoritative verification engine for Dynamic ARP Inspection (DAI) and IP Source Guard (IPSG).

---

2. Network Time Protocol (NTP)

Network Time Protocol (NTP), defined in RFC 5905, operates over UDP port 123 to synchronize system clocks across distributed computers, routers, and infrastructure appliances.

The Stratum Hierarchy

NTP organizes time providers into a hierarchical structure called Stratums to prevent synchronization loops and maintain timing precision:

+-----------------------------------------------------------------------------------+
|                              NTP STRATUM HIERARCHY                                |
+-----------------------------------------------------------------------------------+
| Stratum 0:  Reference Clocks (Atomic Cesium Clocks, GPS Satellites, CDMA)         |
|             (Not connected to networks; connected directly to Stratum 1 servers)  |
+-----------------------------------------------------------------------------------+
| Stratum 1:  Primary Time Servers directly attached to Stratum 0 physical clocks.  |
|             Act as network time servers for national/global backbones.            |
+-----------------------------------------------------------------------------------+
| Stratum 2:  Secondary Servers that synchronize over network paths with Stratum 1. |
|             Enterprise boundary NTP servers typically operate at Stratum 2 or 3.  |
+-----------------------------------------------------------------------------------+
| Stratum N:  Synchronize with Stratum (N-1) servers across internetworks.          |
|             Maximum valid stratum level is 15.                                    |
+-----------------------------------------------------------------------------------+
| Stratum 16: Indicates an unsynchronized, invalid, or unreachable time source.     |
+-----------------------------------------------------------------------------------+

NTP Amplification DDoS Attacks (CVE-2013-5211)

Because NTP runs over connectionless UDP, the source IP address in request packets can be forged. Attackers weaponized this architectural characteristic by targeting an administrative query function in older versions of the ntpd daemon known as monlist:

• The monlist Command: A diagnostic feature intended for administrators. When queried via ntpdc -c monlist <target>, the NTP server returns a list of the last 600 IP addresses that communicated with that NTP server.
• Amplification Mechanism: Because 600 IP addresses cannot fit into a single UDP datagram, the server responds with up to 100 individual UDP packets (totaling approximately 48,000 bytes).
• An attacker sends a single spoofed request packet of roughly 234 bytes with the Source IP set to the Victim's IP Address.
• The vulnerable NTP server floods the victim with 48,000 bytes of response data, achieving an amplification factor exceeding 200x to 500x.
• When thousands of open NTP servers are probed simultaneously by a botnet, the aggregate reflection traffic overwhelms enterprise internet pipes, generating multi-hundred-gigabit DDoS volumes.
• Mitigation: Disable the monlist functionality by adding disable monitor or restricting queries via restrict default kod nomodify notrap nopeer noquery in ntp.conf, and upgrading ntpd to version 4.2.7p26 or newer.

NTP monlist Reflection Attack Flow:
[ Attacker / Botnet ] ──► Sends 234-Byte monlist Query (Spoofed Src IP: Victim) ──► [ Vulnerable NTP Server ]
                                                                                              │
[ Target Victim ]     ◄── Overwhelmed by 48,000 Bytes of Amplified Responses (500x) ──────────┘

Systemic Security Impact of Clock Desynchronization

Accurate network time is a prerequisite for enterprise security controls:

1. Kerberos Authentication Failure: Active Directory and Kerberos V5 rely on timestamps within Authenticator tickets to prevent replay attacks. The default maximum allowable clock skew between a client workstation and the Key Distribution Center (KDC) is 5 minutes (300 seconds). If system clocks drift beyond this limit, authentication fails completely, preventing user logons and locking domain workstations out of network resources.
2. Forensic Timeline Invalidation: During incident response, forensic analysts aggregate logs from firewalls, Active Directory domain controllers, web servers, and endpoint detection agents. If clocks are desynchronized, chronological event reconstruction across SIEM tools becomes impossible, masking the true path of an adversary.
3. PKI & TLS Certificate Verification: Digital certificates (X.509) specify exact Not Before and Not After validity timestamps. A skewed system clock may cause a host to reject perfectly valid TLS certificates (triggering service downtime) or erroneously accept expired or prematurely issued certificates, bypassing security protections.

---

3. Trivial File Transfer Protocol (TFTP)

Trivial File Transfer Protocol (TFTP), defined in RFC 1350, is a bare-bones file transfer protocol operating over UDP port 69.

Inherent Protocol Deficiencies

Unlike FTP or SSH/SFTP, TFTP was engineered to fit within tiny Read-Only Memory (ROM) chips on diskless workstations and network bootstrap environments:

• No Authentication: There is no username or password verification; anyone capable of sending a UDP packet can request a file.
• No Encryption: All commands, file payloads, and headers are transmitted in cleartext.
• No Directory Permissions: TFTP implementations lack access control lists (ACLs) or granular file ownership enforcement; if a file exists within the TFTP root directory, it can be read or overwritten.
• Stop-and-Wait Transport: Operates via a simple lock-step transfer model where every 512-byte data block must be individually acknowledged before the next block is transmitted.

Penetration Testing & Infrastructure Risk Profile

Despite its total lack of security, TFTP remains widely deployed in networking environments:

1. Router & Switch Configuration Harvesting: Network administrators frequently use TFTP to back up and restore Cisco IOS configurations (copy running-config tftp://...). In penetration testing, if an attacker discovers an open internal TFTP server or leverages an SNMP read-write community string, they can force network devices to upload their configuration files directly to an attacker-controlled TFTP listener, exposing enable passwords, pre-shared VPN keys, and network ACLs.
2. VoIP Infrastructure Exploitation: Enterprise IP phones (e.g., Cisco Unified IP Phones, Avaya, Polycom) automatically boot via DHCP Option 150 or 66, which directs the phone to a TFTP server IP. The phone connects to TFTP over UDP 69 to download firmware binaries and XML configuration files (e.g., SEP<MAC_ADDRESS>.cnf.xml). These XML configuration files frequently contain:
   • Cleartext SIP authentication usernames and passwords.
   • PBX controller IP addresses.
   • Local web interface administrative credentials.
   • Extension mappings and softkey configuration profiles.

# Extracting an IP phone configuration file via TFTP
tftp 192.168.1.15
tftp> get SEP001122334455.cnf.xml
# Inspecting XML payload reveals cleartext credentials:
# <sipPassword>SuperSecretVoipPass!</sipPassword>

1. Hardening Recommendations: Restrict TFTP services strictly to isolated provisioning VLANs, prohibit TFTP traversal across corporate routed boundaries via firewall rules, and migrate network device backups and VoIP provisioning to secure alternatives, such as Secure Copy Protocol (SCP), SFTP, or HTTPS.