> Confirmed - starting up the iOS Snapchat app does a lookup to the domains you listed, and then sends NTP to every unique IP. Around 35-60 different IPs.
Hmm. Is that a fraud prevention thing or something? No way on earth a user app should be getting its own time
See my other post here, and the problems in the (third party) iOS NTP library "features" and its use.
There "createAssociations" in that library without any parameters contacts all the IPs behind the big domain list of the NTP servers!
And according to the forum every IP is contacted -- behind one server name there are 3-4 servers in the DNS in this case, I get 31 server! Real "distributed denial of service" attack.
Ironically, part of an HTTPS handshake involves sharing the server time in a cryptographically-verifiable manner. I am not sure why they don't use that! https://github.com/ioerror/tlsdate
This practice is becoming increasingly common for "time-sensitive applications":
https://github.com/lyft/Kronos/blob/master/Sources/NTPClient...
The third-party library used by Snapchat didn't have any "maximum of servers" (using 30 at once(!)) and defaulted to many in the ntp.org pool, across all the continents!
http://mailman.nanog.org/pipermail/nanog/2016-December/08962...
I don't own an iPhone.
To the unobservant user it looks like the OS is rebooting, although it's much quicker than a real reboot.
I think on the Nexus 4, Snapchat still ships with a warning that it doesn't work properly.
Mine would reboot about every second time I took a picture.
Two of them have been in the last month or so. Unfortunately the phone doesn't just reboot. It shuts down completely and refuses to boot back up with a low battery warning. I believe this is actually hardware related but I have had it crash when trying to call an Uber. I think Facebook may have caused a crash too.
Uber was especially painful because hailing taxis in my city (Seattle) is essentially impossible and pay phones are not a thing that exist in 2016. Luckily I was near a bus stop and know how the lines work without my phone.
It was a shocking illustration of how dependent I have become on my smartphone.
If you want to prevent users from altering their time use your server and do a time compare with your server.
NTP can be easily intercepted and altered so it would make a lot more sense to do this via a encrypted certificate pinned communication path increasing my work load drastically to alter the time.
I snapchat going to pay for the DDOS they created?
The library was only doing a couple request per NTP server, so rate limiting really wouldn't have helped.
NTP has KOD (Kiss of Death) which was meant for that situation, but it is often ignored/not handled properly by applications :/
Also, NTP runs on UDP rather than TCP, and it only requires one packet from each party to exchange time, so it's harder to rate-limit it without making your server unreliable.
It doesn't say anything about synchronisation between phone and server.
EDIT: In fact it is easier to implement it this way than using NTP. I've implemented something similar and I found it easier to add an API endpoint that returns time() than to ship an NTP client...
And of course, you don't get the page that states why when the website is served via https. Not that I need to see the page to know it was either blocked for "hacking" or "entertainment", and I'm guessing it's not entertainment.
Edit: This probably explains why our clocks have been off by 45 minutes since Monday. I guess it will be entertaining to see how long it takes for IT to figure this one out.
Why not just tell them. What have you got to lose? Hell, blame your charitable spirit on the holiday season if you must.
Edit: I realize "got told off" didn't really capture what happened. I came in early one day and noticed we were having a dns issue. I manually refreshed my DNS cache and it started to work. I sent him an email to let him know that the DNS cache was expired. He told me I was out of line and complained to HR.
I had to go meet with HR, which was pointless since they think he is on a power trip as well. Anyways he added a line to the IT policy that specifically prohibits "performing a diagnosis on the network or any of IT managed systems."
They are very important people.
You're best off running your own NTP infrastructure that's isolated from the public Internet NTP servers if you want stable time sources. Put a CDMA NTP server in two locations, let them sync, and go. You can get cheap EndRun servers on eBay for a few hundred bucks.
AD and a few other systems get very snippy if the time various servers have isn't in sync, although they don't have much of a problem if every server has the wrong time (within reason).
https://github.com/jbenet/ios-ntp
Specifically, all the servers(!) from here are contacted: https://github.com/jbenet/ios-ntp/blob/master/ios-ntp-lib/Ne...
Note that the library author wrote:
"ios-ntp is often (mostly?) used to make sure someone hasn't fiddled with the system clock. The complications involved in using multiple servers and averaging time offsets is overkill for this purpose. The following skeleton code is all that is needed to check the time."
And that "skeleton" contacts just "time.apple.com"
But the library really has the default possibility of contacting a lot of the ntp.org servers from a big list ("createAssociations" with no parameters!) and it's bad.
As we know, the developers like to just "copy-paste" whatever is where. Or use any defaults. "Hey it works."
It seems that the iOS library author "helpfully" provided the default of contacting 30 servers from the ntp.org pool.
/*┌──────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Prepare a sort-descriptor to sort associations based on their dispersion, and then create an │
│ empty array for associations to fill .. │
└──────────────────────────────────────────────────────────────────────────────────────────────────┘*/https://github.com/jbenet/ios-ntp/blob/master/ios-ntp-lib/Ne...
for use of two different styles of boxes, + some additional typographic experiments.
I actually kind of like it. Not enough to start using it yet, but then again, in Lisp code I make a judicious use[0] of ^L characters and form-feed-mode. Form feed character seems to be a forgotten but pretty neat invention.
It'd be harder to pull off on Google Play Store but I think Apple could make this happen if they wanted to.
Excessive NTP queries aren't going to cause noticeable issues on the device or on Apple's test network, especially with only one or two people testing simultaneously.
edit: snapchat apparantly isn't a facebook property, but it has very deep pockets and as such my comment still stands.
> You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance.
- http://www.pool.ntp.org/en/vendors.html#vendor-zone
Hopefully they were just unaware of the vendor zone policy.
It seems they didn't know, or didn't care, how both the third party iOS library they used and the NTP worked, see my other posts here.
They surely didn't need ntp.org pool at all.
It took 4 days, to zero on the root cause. As is usual in a complex scenario like this there are a few false positives, some suspects abusing the protocol and alas final redemption. Amazing work by a dedicated group of technical folks in coordinating (just via emails, I suppose) and tracing the root cause.
The first one I had heard of was Netgear vs. UW-Madison.
Guess I know why now..
