← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:10114 · CWE-200 · Disclosed 1997-08-01

ICMP Timestamp Request Remote Date Disclosure

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a receptionist telling strangers what time the wall clock says

The finding fires when a host or network appliance answers an unauthenticated ICMP Timestamp Request (type 13) with a Timestamp Reply (type 14). There is no meaningful software version boundary here: *any* OS, hypervisor, firewall, load balancer, printer, or appliance that chooses to answer the protocol can trigger it, which is why NVD maps it broadly and often without concrete versions. Tenable also notes older Windows families such as Vista/7/2008/2008 R2 deliberately returned inexact values rather than exact time.

Tenable's LOW label is already restrained, but for enterprise patch prioritization this is better treated as IGNORE. The issue is reconnaissance-only unless you can pair it with a second weakness such as obsolete time-based authentication or weak time-derived randomness, and that chaining requirement is the entire story: by itself this does not get an attacker code execution, credentials, privilege, or durable access.

"Scanner noise, not patch priority: this leaks the clock, not the keys."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Send an ICMP timestamp probe

An unauthenticated remote actor sends ICMP type 13 using commodity tooling such as nmap -PP or hping3 --icmp-ts. If the network path permits the packet and the target implements the message, the host may answer immediately from the IP stack or control plane without touching any application service.
Conditions required:
  • Target is reachable over IP from the attacker's position
  • Intervening firewalls/ACLs allow ICMP timestamp traffic
  • The target stack or appliance is configured to answer type 13
Where this breaks in practice:
  • Many perimeter firewalls already drop uncommon ICMP types
  • Management interfaces are often isolated from untrusted networks
  • Some modern hosts return inaccurate values or do not answer at all
Detection/coverage: Excellent scanner coverage. Nessus detects it directly; nmap -PP and hping3 --icmp-ts can validate it. Network telemetry can catch type 13/14 if ICMP control-plane traffic is logged.
STEP 02

Harvest time and minor fingerprinting data

The reply exposes the remote clock value and sometimes response quirks that help with OS or appliance fingerprinting. RFC 792 defines the reply as millisecond time since midnight UTC, but implementations vary, which is why researchers have used the behavior for characterization as much as timing.
Conditions required:
  • A valid timestamp reply is returned
  • The attacker can observe the reply
Where this breaks in practice:
  • The disclosed datum is low-value by itself
  • Clock skew of seconds to minutes is rarely decisive in modern environments
  • Other, richer fingerprinting sources usually exist already
Detection/coverage: This step is easy to observe in packet capture, but few SOC pipelines alert on isolated timestamp replies unless expressly tuned.
STEP 03

Chain into a separate weak design

To turn the leak into something operational, the attacker must combine the clock data with another flaw: a weak time-based authentication scheme, a predictable seed, or a fragile protocol that assumes clock secrecy. That second condition is uncommon in modern enterprise software and usually indicates a different, more important defect that should be scored on its own merits.
Conditions required:
  • A second vulnerable mechanism exists that materially depends on accurate target time
  • The attacker knows how to exploit that second mechanism
Where this breaks in practice:
  • This prerequisite is the main severity killer
  • Modern MFA, Kerberos, SSO, and OTP ecosystems do not become breakable because a host answered type 13
  • Weak time-seeded randomness is mostly a legacy or embedded-system problem
Detection/coverage: No scanner can prove the dangerous chain from this finding alone; the timestamp reply is only the recon precondition.
STEP 04

Use it as low-grade recon, not compromise

In real operations this usually ends here: the attacker learns the host is alive and gets a little more fingerprinting signal. That can marginally improve targeting, but it does not meaningfully change defender risk compared with the dozens of louder indicators an internet-exposed host already emits.
Conditions required:
  • The attacker is conducting reconnaissance at scale
Where this breaks in practice:
  • Comparable or better host liveness and fingerprinting data is available from normal TCP/UDP probing
  • The blast radius is nil unless another exploit path already exists
Detection/coverage: Internet-wide studies and commodity scanners show broad visibility, but this remains a low-consequence recon artifact rather than a reliable intrusion path.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of meaningful standalone exploitation was found in the reviewed sources, and this CVE is not listed in the CISA KEV catalog.
Proof-of-concept availabilityCommodity probing is trivial: Nmap documents -PP for ICMP timestamp requests, and Kali's hping3 documents --icmp-ts as an alias for ICMP type 13.
EPSSCVEdetails reports 0.65% EPSS with roughly 70th percentile. Absolute probability is still low; the percentile looks inflated because the long tail of ancient CVEs scores near zero.
KEV statusNot present in CISA KEV at time of review.
CVSS interpretationNVD retains a legacy CVSS v2 2.1 / LOW vector AV:L/AC:L/Au:N/C:P/I:N/A:N. That vector is a poor fit for the practical reality here: the observable behavior is remote, but the impact is so slight that the score still lands near the floor.
Affected scopeEffectively any device that replies to ICMP timestamp requests. NVD lists very broad generic CPEs with no meaningful version ceilings, which is a hint that this is protocol behavior rather than a discrete software defect.
Fixed versionsThere is no universal patched version. Most vendors treat this as configuration or control-plane hardening; some ship product-specific fixes or recommend ACL/firewall filters. Example: A10 published resolved ACOS releases, while Dell OS6 documents an ACL workaround.
Exposure / scanning dataThe 2019 paper *Sundials in the Shade* found 2.2 million internet hosts replying to ICMP timestamp requests across 42,500+ ASes. So exposure exists, but the consequence remains recon-grade.
Disclosure timelineCVE publication traces back to 1997-08-01; Nessus plugin 10114 was first published 1999-08-01 and updated 2024-10-07.
Research / reporting originThis is a legacy generic issue, not a modern product-specific bug bounty or exploit-chain discovery. No current researcher attribution materially changes prioritization.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to IGNORE (0.8/10)

The decisive factor is that this finding has no standalone compromise path: it only discloses the target's clock and becomes interesting *only if* a second, separate weak design is already present. For a 10,000-host program, pushing this into the patch queue steals time from flaws that actually produce initial access, privilege gain, or lateral movement.

HIGH Standalone exploitability is negligible
MEDIUM Exposure prevalence varies by perimeter and appliance mix

Why this verdict

  • [object Object]
  • Standalone impact is recon only: the host leaks time data, not credentials, code execution, privilege, or persistence.
  • The attack path requires a second weakness: the only serious scenarios depend on obsolete time-based authentication or weak time-derived randomness elsewhere in the stack.
  • This is not a real patch-management item: there is often no universal vendor patch, only protocol filtering or device-specific hardening, so treating it like a software vulnerability distorts remediation priorities.

Why not higher?

There is no KEV signal, no meaningful evidence of active campaigns built around this issue, and no direct attacker payoff from the timestamp reply alone. Even when exposed externally, the blast radius is tiny unless another defect is already available to weaponize the clock leak.

Why not lower?

It is not *nothing*: internet-facing control planes and legacy appliances do leak a real datapoint, and the behavior can aid fingerprinting and scan validation. If you are chasing external scan cleanliness or hardening network appliances, blocking type 13/14 is reasonable hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Block ICMP types 13 and 14 at the perimeter — Drop inbound ICMP Timestamp Requests and outbound Timestamp Replies on edge firewalls, internet DMZs, and exposed management planes. This is the cleanest way to kill the finding and reduce recon noise; because the verdict is IGNORE, do it in the next normal network-policy change window rather than under any expedited SLA.
  2. Restrict appliance management interfaces — Put firewalls, load balancers, hypervisor managers, and switch/router management IPs behind admin-only networks or VPN paths. That shrinks the reachable population dramatically and matters more than chasing every host that happens to answer the protocol.
  3. Document a risk-acceptance rule — If the finding is on internal-only servers with no special control-plane exposure, document that the issue is reconnaissance-only and excluded from patch SLAs. This prevents recurring scanner churn from displacing real remediation work.
What doesn't work
  • Running normal OS patch rollups often does nothing; this is commonly protocol behavior or firewall policy, not a software defect with a universal patch.
  • EDR is mostly irrelevant, especially for appliances and control planes that answer ICMP in the network stack before any userland telemetry exists.
  • MFA does not address the issue directly; the finding is not an authentication bypass on its own.
06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation or jump box that has network reachability to the target, not necessarily on the target itself. Invoke it exactly as sudo python3 icmp_ts_check.py 192.0.2.10; raw ICMP sockets require root/Administrator privileges. It sends one ICMP Timestamp Request and reports VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
"""
icmp_ts_check.py - Verify whether a host replies to ICMP Timestamp Requests (type 13)
Exit codes:
  0 = PATCHED / no timestamp reply observed
  1 = VULNERABLE / timestamp reply observed
  2 = UNKNOWN / execution error or insufficient privileges
"""

import os
import socket
import struct
import sys
import time
import select
import random
from datetime import datetime, timezone

ICMP_TIMESTAMP_REQUEST = 13
ICMP_TIMESTAMP_REPLY = 14
TIMEOUT = 3.0


def checksum(data: bytes) -> int:
    if len(data) % 2:
        data += b"\x00"
    s = 0
    for i in range(0, len(data), 2):
        s += (data[i] << 8) + data[i + 1]
    s = (s >> 16) + (s & 0xFFFF)
    s += s >> 16
    return (~s) & 0xFFFF


def ms_since_midnight_utc() -> int:
    now = datetime.now(timezone.utc)
    return ((now.hour * 3600 + now.minute * 60 + now.second) * 1000) + (now.microsecond // 1000)


def build_request(ident: int, seq: int) -> bytes:
    originate = ms_since_midnight_utc()
    # type, code, checksum, identifier, sequence, originate, receive, transmit
    header = struct.pack("!BBHHHIII", ICMP_TIMESTAMP_REQUEST, 0, 0, ident, seq, originate, 0, 0)
    csum = checksum(header)
    return struct.pack("!BBHHHIII", ICMP_TIMESTAMP_REQUEST, 0, csum, ident, seq, originate, 0, 0)


def recv_reply(sock: socket.socket, ident: int, seq: int, timeout: float):
    end = time.time() + timeout
    while time.time() < end:
        remaining = end - time.time()
        r, _, _ = select.select([sock], [], [], remaining)
        if not r:
            break
        packet, addr = sock.recvfrom(65535)
        if len(packet) < 20:
            continue
        ihl = (packet[0] & 0x0F) * 4
        icmp = packet[ihl:]
        if len(icmp) < 20:
            continue
        icmp_type, icmp_code, _, r_ident, r_seq, orig, recv_ts, xmit_ts = struct.unpack("!BBHHHIII", icmp[:20])
        if icmp_type == ICMP_TIMESTAMP_REPLY and icmp_code == 0 and r_ident == ident and r_seq == seq:
            return {
                "src": addr[0],
                "originate": orig,
                "receive": recv_ts,
                "transmit": xmit_ts,
            }
    return None


def main():
    if len(sys.argv) != 2:
        print("UNKNOWN - usage: sudo python3 icmp_ts_check.py <ip-or-hostname>")
        sys.exit(2)

    target = sys.argv[1]

    try:
        dst_ip = socket.gethostbyname(target)
    except Exception as e:
        print(f"UNKNOWN - cannot resolve target: {e}")
        sys.exit(2)

    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
        sock.settimeout(TIMEOUT)
    except PermissionError:
        print("UNKNOWN - raw socket requires root/Administrator")
        sys.exit(2)
    except Exception as e:
        print(f"UNKNOWN - socket error: {e}")
        sys.exit(2)

    ident = random.randint(0, 0xFFFF)
    seq = 1
    packet = build_request(ident, seq)

    try:
        sock.sendto(packet, (dst_ip, 0))
        reply = recv_reply(sock, ident, seq, TIMEOUT)
    except Exception as e:
        print(f"UNKNOWN - probe failed: {e}")
        sys.exit(2)
    finally:
        sock.close()

    if reply:
        print(f"VULNERABLE - received ICMP timestamp reply from {reply['src']} (recv_ts={reply['receive']}, xmit_ts={reply['transmit']})")
        sys.exit(1)
    else:
        print("PATCHED - no ICMP timestamp reply observed")
        sys.exit(0)


if __name__ == "__main__":
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: keep plugin 10114 out of the patch queue and document the rationale as a recon-only, non-exploitable-by-itself finding. If you want scanner cleanup or edge hardening, block ICMP type 13/14 on internet-facing and management networks during the next routine firewall change; for an IGNORE verdict there is no noisgate mitigation SLA and no noisgate remediation SLA—document rationale only unless external exposure on appliances makes the hygiene change worth doing.

Sources

  1. Tenable Nessus Plugin 10114
  2. NVD CVE-1999-0524
  3. RFC 792 - Internet Control Message Protocol
  4. Nmap Host Discovery Techniques
  5. Kali hping3 documentation
  6. Sundials in the Shade: An Internet-wide Perspective on ICMP Timestamps
  7. CISA Known Exploited Vulnerabilities Catalog
  8. CVEdetails CVE-1999-0524
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.