[ntp:questions] Jesus Christ! -> even internet time-sync (NTP) is vulnerable to exploitation?

brian utterback brian.utterback at oracle.com
Mon Dec 22 04:11:11 UTC 2014


On 12/21/2014 8:13 PM, David H. Lipman wrote:
> From: "Virus Guy" <"Virus"@Guy . com>
>
>> "David H. Lipman" wrote:
>>
>> (Dave Lipman posted examples from his router logs of incoming traffic to
>> port 123)
>>
>>
>
> Nope.  There is no reason to believe that the LAN behind the static IP
> does anything but syncs time periodically.
>
> You've included news:protocols.time.ntp  We'll see if anyone form that
> NG has some input/information.
>

How stateful is your router firewall? The NTP protocol only uses UDP and
firewalls often have trouble distinguishing UDP replies. So, one
scenario is that you have computer's using the pool directive sending
out queries and the replies coming back are getting logged.

However, one thing I notice is that the the logs seem to indicate that
the actual target port is not the NTP port (123), but instead is the
chargen port (19). Unless you have some weird NAT thing going on, I
would say that you are not the target of an attack, someone instead is
trying to use your network as a pawn in an attack against those NTP Pool
servers. If you were not dropping these packets and logging them, they
would arrive at a system and if it actually was running the chargen
service a response packet filled with data would be sent to the source
IP and port, i.e. port 123.  Since these are NTP servers, the chargen
packet would be delivered to NTP on the server where it would be flagged
as a malformed packet. Hopefully such a packet would be immediately
dropped but it would be possible that instead it would get an error
packet returned to your system's chargen service which would respond
with another chargen packet and so on and so on.

So, I think it is very likely that someone is sending you those packets
with a spoofed source address and port in the hope that your system will
start sending packets to the NTP servers possibly forming a nasty data
loop and taking them off the error.

Just my two cents.

-- 
Brian Utterback
Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterback at oracle.com




More information about the questions mailing list