daemon-sec-cheatsheet

pentesting-ntp.md (15314B)

---

 ---
 title: "123/udp - Pentesting NTP"
 section: "Network Services"
 sectionSlug: "network-services-pentesting"
 sourcePath: "src/network-services-pentesting/pentesting-ntp.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/pentesting-ntp.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: false
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # 123/udp - Pentesting NTP
 
 ## Basic Information
 
 The **Network Time Protocol (NTP)** ensures computers and network devices across variable-latency networks sync their clocks accurately. It's vital for maintaining precise timekeeping in IT operations, security, and logging. Because time is used in nearly every authentication, crypto-protocol and forensic process, **an attacker that can influence NTP can often bypass security controls or make attacks harder to investigate.**
 
 ### Summary & Security Tips
 
 - **Purpose**: Syncs device clocks over networks.
 - **Importance**: Critical for security, logging, crypto-protocols and distributed systems.
 - **Security Measures**:
   - Use trusted NTP or NTS (Network Time Security) sources with authentication.
   - Restrict who can query/command the daemon (``restrict default noquery``, ``kod`` etc.).
   - Restrict Mode-6 (`ntpq`) and legacy Mode-7 (`ntpdc`/`monlist`) control queries or rate-limit them.
   - Monitor synchronization drift/leap-second state for tampering.
   - Keep the daemon updated (see recent CVEs below).
 
 **Default ports**
 
 ```text
 123/udp   NTP            (data + legacy control)
 323/udp   chronyd command/monitoring protocol (when remotely bound)
 4460/tcp  NTS-KE (RFC 8915) – TLS key-establishment for NTP
 ```
 
 ```text
 PORT    STATE SERVICE REASON
 123/udp open  ntp     udp-response
 ```
 
 ---
 ## Enumeration
 
 ### Classic ntpd control protocols (Mode 6/7)
 
 ```bash
 # Information & variables
 ntpq -c rv <IP>
 ntpq -c readvar <IP>
 ntpq -c peers <IP>
 ntpq -c associations <IP>
 
 # Legacy mode-7 (often disabled >=4.2.8p9)
 ntpdc -c monlist <IP>
 ntpdc -c listpeers <IP>
 ntpdc -c sysinfo  <IP>
 ```
 
 ### chrony / chronyc (UDP/323)
 
 `chronyc` does **not** send these commands to UDP/123: the default `chronyd` command port is **323/udp**. Remote access additionally requires a non-loopback `bindcmdaddress` and a matching `cmdallow`; chrony 4.7+ can further restrict exposed reports with `opencommands`. The `-a` switch seen in old examples is now ignored. Scan and query this surface separately.<sup>[[9]](#references)[[11]](#references)</sup>
 
 ```bash
 nmap -sU -sV -p 323 <IP>
 chronyc -n -h <IP> tracking
 chronyc -n -h <IP> sources -v
 chronyc -n -h <IP> sourcestats
 chronyc -n -h <IP> activity
 ```
 
 Only the configured monitoring commands are reachable over the network; commands which alter daemon state remain Unix-socket-only. Reports such as `sources`, `tracking`, `ntpdata`, `clients`, and `serverstats` can reveal upstream addresses, clock quality, client activity, and rate-limit state when an operator has exposed them.<sup>[[9]](#references)[[11]](#references)</sup>
 
 ### Nmap
 
 ```bash
 # Safe discovery & vuln detection
 nmap -sU -sV --script "ntp* and (discovery or vuln) and not (dos or brute)" -p 123 <IP>
 
 # Explicit monlist check
 nmap -sU -p123 --script ntp-monlist <IP>
 ```
 
 ### Mass/Internet scanning
 
 ```bash
 # Check if MONLIST is enabled (zgrab2 module)
 zgrab2 ntp --monlist --timeout 3 --output-file monlist.json -f "zmap_results.csv"
 ```
 
 ---
 ## Examine configuration files
 
 - ``/etc/ntp.conf`` (ntpd)
 - ``/etc/chrony/chrony.conf`` (chrony)
 - ``/etc/systemd/timesyncd.conf`` (timesyncd – client only)
 
 Pay special attention to ``restrict`` lines, ``kod`` (Kiss-o'-Death) settings, ``disable monitor``/``includefile /etc/ntp/crypto`` and whether *NTS* is enabled (``nts enable``). For chrony, audit `bindcmdaddress`, `cmdport`, `cmdallow`/`cmddeny`, `opencommands`, and `cmdratelimit`; `allow` controls NTP clients and is independent from `cmdallow`.<sup>[[11]](#references)</sup>
 
 ---
 ## Selected Vulnerabilities and Operational Risks
 
 | Year | CVE | Component | Impact |
 |------|-----|-----------|--------|
 | 2023 | **CVE-2023-26551 through CVE-2023-26555** | ntp 4.2.8p15 and earlier | Several low-severity parsing and bounds-checking flaws fixed in **4.2.8p16**; upgrade or back-port the vendor fixes.<sup>[[5]](#references)</sup> |
 | 2023 | **CVE-2023-33192** | **ntpd-rs** (Rust implementation) | Malformed **NTS** cookie causes remote **DoS** prior to v0.3.3 – affects port 123 even when NTS **disabled**.<sup>[[6]](#references)</sup> |
 | 2024 | distro updates | **chrony 4.4 / 4.5** – several security hardening & NTS-KE fixes (e.g. SUSE-RU-2024:2022)<sup>[[7]](#references)</sup> |
 | 2025 | **CVE-2025-58066** | **ntpd-rs 1.2.0–1.6.1**, server mode | A response/request validation error can turn two exposed servers into a persistent packet loop; fixed in 1.6.2.<sup>[[14]](#references)</sup> |
 | 2014 | NTP reflection at scale | Cloudflare documented a **400 Gbps NTP amplification** attack that abused exposed `monlist` responders. Keep monitoring queries inaccessible from untrusted networks.<sup>[[3]](#references)</sup> |
 
 The 2023 ntp.org group contains two distinct attack surfaces. **CVE-2023-26551 through CVE-2023-26554** are out-of-bounds writes in `libntp/mstolfp.c`; their records describe a malicious server attacking the **client-side `ntpq` process**, not `ntpd`. **CVE-2023-26555** affects `praecis_parse()` in the Palisade reference-clock driver and requires a more specialized input path, such as a manipulated GPS receiver.<sup>[[5]](#references)[[12]](#references)[[13]](#references)</sup>
 
 > **Operator exposure:** Because CVE-2023-26551 through CVE-2023-26554 are client-side `ntpq` parsing flaws, querying an untrusted or attacker-controlled NTP server is the dangerous direction. Avoid pointing an unpatched diagnostic client at arbitrary Internet hosts; use **4.2.8p16** or a vendor-backported fix.<sup>[[5]](#references)[[12]](#references)</sup>
 
 ---
 ## Advanced Attacks
 
 ### 1. NTP Amplification / Reflection
 
 The legacy Mode-7 `monlist` query can return information about up to **600 recent clients**. A small spoofed request can therefore trigger a much larger multi-packet response, producing amplification factors in the hundreds in vulnerable configurations.<sup>[[3]](#references)[[4]](#references)</sup> Mitigations:
 
 - Upgrade to a supported release (at least **4.2.8p16** for the 2023 fixes) and **add** `disable monitor` where legacy monitoring is unnecessary.
 - Rate-limit UDP/123 on the edge or enable *sessions-required* on DDoS appliances.
 - Enable *BCP 38* egress filtering to block source spoofing.
 
 See Cloudflare’s learning-center article for a step-by-step breakdown.<sup>[[4]](#references)</sup> 
 
 ### 2. Time-Shift / Delay attacks (Khronos / Chronos research)
 
 Even with authentication, an on-path attacker can attempt to **shift the client clock** by dropping or delaying packets. RFC 9523's **Khronos** mechanism queries a large, diverse server pool and periodically applies a robust selection algorithm to resist time-shifting attacks.<sup>[[8]](#references)</sup> Chrony's `maxdistance`, `maxjitter`, and `minsources` controls are useful source-selection safeguards, but they are configuration controls rather than an implementation of Khronos.<sup>[[11]](#references)</sup>
 
 ### 3. NTS abuse & 4460/tcp exposure
 
 NTS moves the heavy crypto to a separate **TLS 1.3 channel on 4460/tcp** (``ntske/1``). Poor implementations (see CVE-2023-33192) crash when parsing cookies or allow weak ciphers. Pentesters should:
 
 ```bash
 # TLS reconnaissance
 nmap -sV -p 4460 --script ssl-enum-ciphers,ssl-cert <IP>
 
 # Grab banner & ALPN
 openssl s_client -connect <IP>:4460 -alpn ntske/1 -tls1_3 -ign_eof
 ```
 
 Look for certificate-validation failures, unexpected trust anchors, missing `ntske/1` ALPN negotiation, and implementation-specific parsing failures. RFC 8915 requires TLS 1.3 or later for NTS-KE and separately negotiates an AEAD algorithm for protected NTP packets.<sup>[[1]](#references)</sup>
 
 ### 4. Response-loop / message-storm DoS
 
 Do not assume that every packet received on UDP/123 is a client request. In ntpd-rs 1.2.0 through 1.6.1, a server replied even to **server response** packets. An attacker able to spoof the address of exposed server B in one such packet to server A could make A and B continuously reply to each other. This is a distinct primitive from amplification: the initial spoofed packet creates a self-sustaining two-node loop.<sup>[[14]](#references)</sup>
 
 Treat active validation as disruptive. In an authorized lab, first inventory versions/configuration and watch for alternating UDP/123 traffic which continues without client requests:
 
 ```bash
 sudo tcpdump -ni any 'udp port 123 and (host <SERVER_A> or host <SERVER_B>)'
 ```
 
 The vulnerable range applies only when ntpd-rs is acting as a server and accepts non-NTS traffic. Upgrade to **1.6.2+**; when patching is delayed, restrict clients and discard non-request NTP modes at the edge.<sup>[[14]](#references)</sup>
 
 ### 5. Malicious pool servers and zone monopolization
 
 Authentication protects packet origin and integrity, but it cannot make a deliberately malicious time server truthful. A 2026 measurement study found that only **19.7%** of active NTP Pool servers were fully independent after grouping aliases, accounts, and network connectivity. Its capacity-informed model and ethical validation showed that **90% of country zones** could have at least half of their pool traffic captured with ten or fewer maximum-capacity server registrations.<sup>[[15]](#references)</sup>
 
 Useful attacker primitives include cheap IPv6 aliases, declaring high `netspeed`, learning pool monitors while in monitor-only mode, returning correct time selectively to those monitors, and later skewing ordinary clients. Residual queries can also continue long after a server is removed because some clients retain its address. During an assessment, therefore, resolve pool names repeatedly from multiple vantage points and group answers by operator/account where known, ASN, prefix, physical alias, and IP family—four addresses are not four independent trust domains.<sup>[[15]](#references)</sup>
 
 For critical clients, prefer pinned, independently administered NTS servers rather than relying on multiple names from one pool or provider. Diversity must include administrative and network-path diversity, not only address count.<sup>[[1]](#references)[[15]](#references)</sup>
 
 ---
 ## Hardening / Best-Current-Practice (BCP-233 / RFC 8633)
 
 *Operators SHOULD:*
 
 1. Use **≥ 4** independent, diverse time sources (public pools, GPS, PTP-bridges) to avoid single-source poisoning; several IPs behind one operator, ASN, or pool account are correlated sources.<sup>[[15]](#references)</sup>
 2. Enable ``kod`` and ``limited``/``nomodify`` restrictions so abusive clients receive **Kiss-o'-Death** rate-limit packets instead of full responses.
 3. Monitor daemon logs for **panic** events or step adjustments > 1000 s. (Signatures of attack per RFC 8633 §5.3.)
 4. Consider **leap-smear** to avoid leap-second outages, but ensure *all* downstream clients use the same smear window.
 5. Keep polling ≤24 h so leap-second flags are not missed.
 6. Keep `chronyd` command access on loopback where possible. Otherwise firewall UDP/323, narrowly scope `cmdallow`, expose only required `opencommands`, and retain `cmdratelimit`.<sup>[[11]](#references)</sup>
 
 See RFC 8633 for a comprehensive checklist.<sup>[[2]](#references)</sup> 
 
 ---
 ## Shodan / Censys Dorks
 
 ```text
 port:123 "ntpd"          # Version banner
 udp port:123 monlist:true # Censys tag for vulnerable servers
 port:4460 "ntske"         # NTS-KE
 ```
 
 ---
 ## Useful Tools
 
 | Tool | Purpose | Example |
 |------|---------|---------|
 | **zgrab2 ntp** | Mass scanning / JSON output including monlist flag<sup>[[10]](#references)</sup> | See command above |
 | `chronyd` with `local` + `allow` | Run a controlled NTP server in a pentest lab | See configuration below |
 | Packet-crafting frameworks | Build or replay NTP packets in an authorized lab after establishing an on-path position | Validate the packet fields and timing effect with a capture |
 
 `chronyd -q` sets the local clock once and exits; it does **not** create a test server. A minimal isolated-lab server can instead be started with:<sup>[[11]](#references)</sup>
 
 ```bash
 cat >/tmp/chrony-lab.conf <<'EOF'
 local stratum 8
 allow 192.0.2.0/24
 bindaddress 192.0.2.10
 EOF
 sudo chronyd -d -f /tmp/chrony-lab.conf
 ```
 
 ---
 ## HackTricks Automatic Commands
 
 ```text
 Protocol_Name: NTP
 Port_Number: 123
 Protocol_Description: Network Time Protocol
 
 Entry_1:
   Name: Notes
   Description: Notes for NTP
   Note: |
     The Network Time Protocol (NTP) ensures computers and network devices across variable-latency networks sync their clocks accurately. It's vital for maintaining precise timekeeping in IT operations, security, and logging. NTP's accuracy is essential, but it also poses security risks if not properly managed.
 
     https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-ntp.html
 
 Entry_2:
   Name: Nmap
   Description: Enumerate NTP
   Command: nmap -sU -sV --script "ntp* and (discovery or vuln) and not (dos or brute)" -p 123 {IP}
 ```
 
 ---
 
 
 ## References
 
 - [1] [RFC 8915 – Network Time Security for the Network Time Protocol (port 4460)](https://www.rfc-editor.org/rfc/rfc8915)
 - [2] [RFC 8633 – Network Time Protocol BCP](https://www.rfc-editor.org/rfc/rfc8633)
 - [3] [Cloudflare – Technical Details Behind a 400 Gbps NTP Amplification DDoS Attack](https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/)
 - [4] [Cloudflare Learning Center – NTP Amplification DDoS Attack](https://www.cloudflare.com/learning/ddos/ntp-amplification-ddos-attack/)
 - [5] [NTP Project – ntp-4.2.8 series changelog](https://www.ntp.org/support/securitynotice/4_2_8-series-changelog/)
 - [6] [NVD – CVE-2023-33192 (ntpd-rs NTS cookie denial of service)](https://nvd.nist.gov/vuln/detail/CVE-2023-33192)
 - [7] [SUSE – Recommended update for chrony (SUSE-RU-2024:2022-1)](https://www.suse.com/support/update/announcement/2024/suse-ru-20242022-1/)
 - [8] [RFC 9523 – A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos](https://www.rfc-editor.org/rfc/rfc9523)
 - [9] [chrony project – chronyc(1) manual](https://chrony-project.org/doc/4.9/chronyc.html)
 - [10] [zgrab2 – ntp module](https://github.com/zmap/zgrab2/tree/master/modules/ntp)
 - [11] [chrony project – chrony.conf(5) configuration manual](https://chrony-project.org/doc/4.9/chrony.conf.html)
 - [12] [CVE.org - CVE-2023-26551 (`mstolfp` out-of-bounds write)](https://www.cve.org/CVERecord?id=CVE-2023-26551)
 - [13] [CVE.org - CVE-2023-26555 (`praecis_parse` out-of-bounds write)](https://www.cve.org/CVERecord?id=CVE-2023-26555)
 - [14] [ntpd-rs advisory – response-loop denial of service (GHSA-4855-q42w-5vr4)](https://github.com/pendulum-project/ntpd-rs/security/advisories/GHSA-4855-q42w-5vr4)
 - [15] [NDSS 2026 – On Borrowed Time: Measurement-Informed Understanding of the NTP Pool's Robustness to Monopoly Attacks](https://www.ndss-symposium.org/wp-content/uploads/2026-f541-paper.pdf)