01 · The Real Story
This is the security equivalent of someone reading the clock on your wall through a window
CVE-1999-0524, dating to 1997, flags any host that responds to an ICMP Type 13 (Timestamp Request) packet with an ICMP Type 14 (Timestamp Reply) containing the system's current time in milliseconds since midnight UTC. This is a default behavior of the TCP/IP stack on virtually every operating system ever shipped — Linux, Windows, macOS, BSD, Cisco IOS, Juniper Junos, every embedded device with a network interface. Tenable plugin 10114 fires on any host that responds, which in most environments means *every single scanned IP*. Windows Vista through Server 2008 R2 and later deliberately return inaccurate timestamps (offset by up to 1000 seconds), further reducing the already negligible value of the disclosure.
Tenable rates this plugin as Medium severity (CVSS v3 base 4.0), while VPR scores it Low at 3.2. Neither rating reflects operational reality. The disclosed information — a host's approximate clock — has zero practical value to an attacker. Modern authentication protocols (Kerberos, TLS 1.3, OAuth2, SAML) do not treat system time as a secret; Kerberos's 5-minute skew tolerance is a *published constant*, not something an attacker discovers via ICMP. No CVE, advisory, incident report, or threat intelligence feed has ever documented a real-world attack chain that depended on ICMP timestamp disclosure as a meaningful prerequisite. This finding exists because vulnerability scanners check for it, not because it matters.
"ICMP timestamp disclosure is scanner noise, not a vulnerability. Suppress it and move on."
02 · The Attack Path
3 steps from start to impact.
STEP 01
Send ICMP Type 13 packet
The attacker sends a single ICMP Timestamp Request (type 13, code 0) to the target IP address. This requires raw socket access or a tool like
hping3 --icmp --icmptype 13 <target>, nmap -sn -PP <target>, or the trivial Python script from the threatlabindonesia GitHub repo. No authentication, credentials, or prior access is needed — just network reachability over ICMP.Conditions required:
- Network path to target that permits ICMP type 13 transit
- Target OS responds to ICMP timestamp requests (default on most stacks)
Where this breaks in practice:
- Most enterprise perimeter firewalls drop inbound ICMP type 13 from the internet by default
- Cloud security groups (AWS, Azure, GCP) deny all ICMP except echo by default
- Host-based firewalls (Windows Firewall, iptables) may block ICMP type 13 in hardened profiles
Detection/coverage: Every vulnerability scanner (Nessus, Qualys, Rapid7) detects this. GreyNoise tags ICMP scanners but does not specifically track timestamp probes as malicious.
STEP 02
Receive system timestamp
The target replies with an ICMP Type 14 (Timestamp Reply) containing three 32-bit timestamps: originate, receive, and transmit — all in milliseconds since midnight UTC. The attacker now knows the target's approximate system clock. On modern Windows, this value is deliberately jittered by up to ~1000 seconds.
Conditions required:
- Successful receipt of ICMP type 14 reply
Where this breaks in practice:
- The disclosed value (system time) is already available via NTP, HTTP Date headers, TLS ServerHello random bytes, Kerberos error messages, and dozens of other protocols
- Windows returns intentionally inaccurate timestamps
- The information has no known weaponization path
STEP 03
Attempt to leverage timestamp (theoretical)
The attacker would need to find a service on the target that uses a secret time-based value derived from the system clock — for example, a weak PRNG seeded solely by
time(). No modern operating system or mainstream application seeds cryptographic randomness from the wall clock alone. /dev/urandom, CryptGenRandom, and BCryptGenRandom all use entropy pools independent of the timestamp. This step has no documented real-world success.Conditions required:
- Target runs a service with a PRNG seeded exclusively by system clock
- No additional entropy sources in the PRNG
- Attacker can observe or influence the PRNG output
Where this breaks in practice:
- No mainstream software has used time-only PRNG seeding since the late 1990s
- Modern OS entropy pools (Linux getrandom, Windows BCryptGenRandom) make this irrelevant
- No published exploit chain exists that traverses this step
03 · Compensating Control
1
IGNORE 1.0→IGNORE 0.0
Suppress Tenable plugin 10114 in your scan policy — The single most impactful action is to stop reporting this finding. In a 10,000-host environment, this plugin generates thousands of findings that consume analyst time, inflate risk dashboards, and crowd out real vulnerabilities. Add plugin 10114 to your accepted-risk / suppression list with a documented rationale. This is not a mitigation SLA item — it is an IGNORE verdict and requires no remediation deadline.
2
IGNORE 1.0→IGNORE 0.0
Block ICMP type 13/14 at perimeter firewalls — If your compliance framework (e.g., PCI DSS, DISA STIG) requires remediation regardless of risk, add a perimeter firewall rule to drop inbound ICMP type 13 (Timestamp Request) and outbound ICMP type 14 (Timestamp Reply). This eliminates the finding from external scans. No SLA applies — this is an IGNORE verdict. Implement opportunistically during next firewall change window.
3
IGNORE 1.0→IGNORE 0.0
Disable ICMP timestamp replies on hardened hosts via OS configuration — For hosts under strict hardening baselines (DISA STIG, CIS Benchmark), disable timestamp replies at the OS level. On Linux:
sysctl -w net.ipv4.icmp_ratelimit=0 or drop via iptables. On Windows: configure Windows Firewall to block ICMP type 13 inbound. This is a defense-in-depth nicety, not a security necessity. No SLA applies.What doesn't work
- Patching the OS — there is no patch because this is default protocol behavior, not a software bug. Upgrading Windows, Linux, or firmware will not change ICMP timestamp response behavior unless the new version ships with a hardened default firewall profile.
- Network segmentation — while segmentation limits who can send ICMP type 13, the finding is informational-only and the same timestamp is available through many other protocols on the same segments. Segmentation does not change the risk from zero to less-than-zero.
- IDS/IPS signatures — alerting on ICMP type 13 generates massive false-positive volumes from legitimate network monitoring, NTP clients, and vulnerability scanners. Tuning IDS to flag this wastes SOC analyst time.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild exploitation | None documented — ever. Not listed in CISA KEV. No threat intelligence vendor (Mandiant, CrowdStrike, Recorded Future, GreyNoise) has attributed any campaign to ICMP timestamp disclosure. This CVE has existed for 29 years with zero weaponization. |
|---|---|
| Proof-of-concept | Trivially available — sending an ICMP type 13 packet is the "exploit." GitHub repos like threatlabindonesia/CVE-1999-0524-ICMP-Timestamp-and-Address-Mask-Request-Exploit wrap it in Python. hping3 --icmp --icmptype 13 <target> is the one-liner. The PoC is indistinguishable from normal network diagnostics. |
| EPSS | 0.3215 (98.3rd percentile). This score is misleadingly high — EPSS measures probability of *any* scanning/probing activity matching the CVE signature, and every vulnerability scanner on earth fires ICMP type 13. The score reflects ubiquitous scanning, not attacker intent or impact. |
| CISA KEV | Not listed. Not added in the catalog's entire history since November 2021. |
| CVSS v3.1 vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N (4.0 Medium). The NVD vector is arguably mis-scored — AV:L (Local) is incorrect for a network-reachable ICMP response. Even correcting to AV:N, the impact metrics (C:N/I:L/A:N) yield a low-impact finding. Tenable VPR: 3.2 (Low). |
| Affected versions | Every operating system and network device with an IP stack that responds to ICMP type 13. This is not a software bug — it is default protocol behavior defined in RFC 792 (1981). |
| Fix / patched version | There is no patch. Remediation is a firewall rule to drop ICMP type 13 inbound and type 14 outbound. Some OS hardening guides disable timestamp replies at the kernel level (net.ipv4.icmp_ratelimit or Windows Firewall rules). |
| Scanning / exposure | Shodan and Censys can identify ICMP-responsive hosts but do not specifically index timestamp replies as a vulnerability class. GreyNoise observes mass ICMP scanning but does not flag timestamp requests separately from general ICMP noise. |
| Disclosure date | 1997-08-01 — published 29 years ago. First Tenable plugin version: August 1, 1999. |
| Reporter | Defined in RFC 792 (September 1981) by Jon Postel. This is an IETF protocol feature, not a researcher-discovered vulnerability. |
Sources.
- Tenable Plugin 10114
- CVE-1999-0524 — Tenable CVE Detail
- FIRST EPSS Score for CVE-1999-0524
- RFC 792 — Internet Control Message Protocol
- Valency Networks — Is ICMP Timestamp Vulnerability Worth Considering
- GitHub PoC — threatlabindonesia CVE-1999-0524
- F5 K15277 — ICMP Vulnerability CVE-1999-0524
- Huntress — CVE-1999-0524 Analysis
05 · The Call
Final Verdict
↓ DOWNGRADED to IGNORE (1.0/10)
Why this verdict
- Zero impact ceiling: The disclosed information (approximate system clock) is not a secret in any modern protocol or application. Kerberos skew tolerance, TLS random nonces, and OS entropy pools are all independent of whether the attacker knows your timestamp. The maximum theoretical impact is negligible information disclosure with no path to confidentiality, integrity, or availability compromise.
- 29 years, zero weaponization: This CVE has been public since 1997. No documented incident, campaign, malware family, or red team operation has ever relied on ICMP timestamp disclosure as a meaningful attack step. If it were useful, someone would have used it by now.
- Role multiplier: universally irrelevant across all roles. This affects every networked host — domain controllers, hypervisors, edge appliances, CI/CD, databases, OT controllers. On none of these does learning the system clock create a viable attack path. On a DC, Kerberos time skew is a constant (default ±5 minutes) — not a secret. On an edge appliance, the timestamp enables nothing. On OT/SCADA, the clock is already exposed via NTP and HMI interfaces. The blast radius of the disclosed information is zero regardless of role. No floor applies because no high-value-role outcome exceeds informational.
- EPSS is a red herring: The 98th-percentile EPSS score reflects that every vulnerability scanner probes ICMP type 13. It does not indicate attacker exploitation interest. EPSS does not distinguish between "scanners fire this check" and "attackers weaponize this finding."
- Vendor severity already low, but still too high: Tenable VPR (3.2 Low) is the most reasonable vendor score. The CVSS v3 Medium (4.0) and v4 Medium (6.4) both overstate reality. The NVD's own
AV:Laccess vector is incorrect for a network-reachable ICMP finding, calling the scoring methodology into question.
Why not higher?
There is no scenario in which this finding warrants LOW or above. The disclosed information (system clock) is not a secret, is freely available through numerous other protocols (NTP, HTTP headers, TLS handshakes), and has never been documented as a prerequisite in any real attack chain across 29 years of exposure. Elevating this to LOW would imply it deserves backlog tracking, which wastes defender cycles.
Why not lower?
IGNORE is the lowest possible rating. A score of 1.0 (rather than 0.0) acknowledges that the finding technically represents information disclosure per CWE-200, even though the disclosed information has no practical security value. This is the correct floor for a protocol behavior that was never a vulnerability in any meaningful sense.
06 · Verification
Crowdsourced verification payload.
Run on any Linux/macOS auditor workstation with hping3 installed. No special privileges beyond raw socket access (root or CAP_NET_RAW). Example: sudo bash check_icmp_timestamp.sh 192.168.1.1
#!/usr/bin/env bash
# check_icmp_timestamp.sh — Verify if a target responds to ICMP Timestamp Requests
# Usage: sudo bash check_icmp_timestamp.sh <TARGET_IP>
# Requires: hping3, root/CAP_NET_RAW
# Output: VULNERABLE / PATCHED / UNKNOWN
set -euo pipefail
TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
echo "Usage: sudo $0 <TARGET_IP>"
exit 3
fi
if ! command -v hping3 &>/dev/null; then
echo "UNKNOWN — hping3 not found. Install with: apt install hping3 / brew install hping"
exit 3
fi
if [[ $EUID -ne 0 ]]; then
echo "UNKNOWN — must run as root (raw sockets required)"
exit 3
fi
# Send 3 ICMP Timestamp Request (type 13) packets, 1-second interval, 2-second timeout
OUTPUT=$(hping3 --icmp --icmptype 13 -c 3 -i 1 "$TARGET" 2>&1) || true
# Check if we received any timestamp replies (type 14)
if echo "$OUTPUT" | grep -qiE 'icmp_seq|timestamp|len='; then
# Count replies received
REPLIES=$(echo "$OUTPUT" | grep -c 'len=' || true)
if [[ "$REPLIES" -gt 0 ]]; then
echo "VULNERABLE — Target $TARGET responded to $REPLIES of 3 ICMP Timestamp Requests."
echo "Note: This is an informational finding (CVE-1999-0524 / Tenable 10114)."
echo "Risk: IGNORE — system clock disclosure has no practical security impact."
exit 0
fi
fi
# Check for explicit packet loss = 100%
if echo "$OUTPUT" | grep -qE '100% packet loss|0 packets received'; then
echo "PATCHED — Target $TARGET did not respond to ICMP Timestamp Requests."
exit 0
fi
echo "UNKNOWN — Could not determine status. Raw output:"
echo "$OUTPUT"
exit 3