NTP Security - Librem 5

Hi there,
i have sniffed some Traffic while i thought, i got hacked.
This happened without using a App or a Browser.
A NTP-Sync with some happenings to a lot of Ports.
(I am just a beginner of IT-Sec just know a bit but i am very Curios)
I just checked how a normal NTP sync should look like on the Wireshark-Page and compared the one i made.
The default Wireshark NTPsync Traffic:
Is there a difference to a normal NTP-Sync on the Librem5, or was there some instance who used an Exploit against my Phone.
Because the template of a normal Ntp-sync and my sniff are very different.
I´ve reported the happening to the Website-Team of the Webpage i was connected before, cause i thought the Attack came from their servers or any compromised infrastructure in between.
I had some connection problems while changing my Isp.
Settings on UFW:
opened 443 port
Deny incoming
Allow Outgoing Traffic
Deinstallation of UFW had solved the Problem i had on my ISP-Disconnectivity.
A Reinstallation brought the same Problem again.
That seemed illogical to me , with these Firewall-Rules.
After that, i have started the Wireshark-Sniff not using any Internet-related App and these NTP initiated Traffic was there, but i think my Phone got compromised before, by Usb or some other Backdoor.
(Sometimes there are I/O-Fails on sudo apt update or upgrade)
Had these f.E. on a Thonny package.
All connections in and out, had been on Modem, i have not used any Wifi for a long time.
Wiresharksniff: https://ufile.io/2lkngraq
Password: Pureos97
After these long time of Reporting and now should be ok to upload?
Do you think it is related to these ones: https://github.com/spwpun/ntp-4.2.8p15-cves
The Time of the CVE-exploring and the happenening fits.
Beautiful Regards!!

NTP should be safe again, but i want to know how my device was compromised before ?

That vulnerability is completely irrelevant to Librem 5. It doesn’t even use ntpd.

Ok, good to know. Thanks for answering!
Is the Librem not using NTP at all? Or just not NTPD, d stands for a Daemon ? Cause the Traffic i have sniffed, has no DNS Traffic before the 2 NTP Packet-syncs, and after that there are a lot of Packets communication to Ports on the Internal, before there are some failed Retransmitted Packets, the PCAP-File shows everything. So a Device communicated to my Phone without DNS-solving, directly? Normaly DNS solves the Ip if a device would potencially Sync time on NTP, so there should income and outgo 2 DNS-Packets in Total, to solve the IP, on my Traffic there is none, the Traffic start with NTP and then there is TCP on different Ports with the internal IP. Do you know why is that, is that normal ? Is this Traffic showing an Exploit ?

I would imagine it is using systemd-timesyncd but you would have to check that on your phone. So it would still be using NTP (the protocol).

Whether any DNS traffic occurs or is expected is hard to say without knowing which NTP implementation you are using and how it is configured. There are multiple ways of resolving a host name - plus name resolutions can be cached - plus system components can be configured with hard-coded IP addresses.

On my desktop the DNS server is (that’s systemd-resolved) - which then allows the stub resolver on that IP address to carry out more sophisticated logic for where the actual DNS server is. (You can get an idea of what’s going on with resolvectl status ) However any given piece of local code is not absolutely required to use IP to communicate with the local DNS server at all.

On the balance of probabilities, it is unlikely.


resolvectl status

Global has the Protocols: +LLMNR +mDNS
resolv.conf mode: uplink
Link2 (usb0)
Current Scopes: none
Protocols: +LLMNR +mDNS
Link3 (lxbcr0)
Current Scopes: none
Protocols: DefaultRoute +LLMNR +mDNS
on > ip addr
i have as loopback.
and 10.3.x.x/24 on lxcbr0 for the bridge to waydroid
I was just wondering why there is this process initiated by NTP:
Packet 1: NTP client
Packet 2: NTP server
Packet 3: TCP from port 42424 to 443 (https)
Packet 4: TCP from port 42424 to 443 (https)
Packet 5: NTP client
Packet 6: NTP server
Packet 7: TCP from port 42424 to 443 (https)
Packet 8: Retransmission
Packet 9: Retransmission
Packet 10: Retransmission
Packet 11: Retransmission
Packet 12: Retransmission
Packet 13: Retransmission
Packet 14: Retransmission
Packet 14: Retransmission
Packet 15: TCP from port 443 (https) to 53438
Packet 16 to 35 is internal on loopback: , every second packet is SYN

All other TCP Packets are : RST

There is so much red and black in this pcap, and i have not used any prompt nor any app, but wireshark.
in etc/systemd/timesyncd.conf
there is
the NTP IP sniffed belonged to Cloudflare, not to debian.pool.ntp.org , i just checked up on iplookup.
Hope i am not to annoying ;(
Greetings !

1 Like

Maybe DoH?

We would probably need to know what IP address.

Confusing the issue is that those Debian pools almost certainly return geo-specific results, and probably also do round-robin.

Looking at #1 right now, for me, and reverse looking up the resulting IP addresses, I get

which is a pretty ‘random’ collection, and almost certainly not what you would get.

1 Like

I have just used this service:
Probably your research is more exact.
As i said i am just a beginner, and have not studied but had strange happenings to my Systems in the last 2 Years.
Do you know how to get Code out of the Packets?
Is that possible in any way?
I mean from the ASCII on the right side? Would be cool to find the Bug together.
Hope thats not to unrealistic, not even being sure if this is a bug :smiley:

Not sure why you are using that. That service is giving a geographical location for a given IP address. Such services are notoriously unreliable. For example, for me right now, some of the services consulted on that web site are in error by a few thousand kilometres and others by hundreds of kilometres and no service gave a result that is at all close (and, no, I’m not using a VPN).

I don’t know what you are asking here.

To get the above results, I used nslookup (not installed by default on the Librem 5) but you can get similar results with dig (which may be installed by default).

Basically, I went into nslookup
I typed the domain name (1.debian.pool.ntp.org.)
it gave me a bunch of IP addresses
I then “typed” in each IP address in turn (I only received IPv4 addresses)
it gave me a domain name for the IP address

However where a service aims to have zillions of customers they will often rotate the servers that are returned for any given DNS query in order to spread the load. As a result, repeating the DNS query, immediately or later on, will get different results.

There could be a bug, there could be a security failure, there could be a misunderstanding. At this stage, I don’t have enough information to decide which is the case - but I would lean towards “misunderstanding”.

I have just thought about making it reproducable, to see the effects to the Phone.
I have done some Research: https://docs.pwntools.com/en/stable/commandline.html#pwn-asm, this one can make an Exploit.
Packet 7 is interesting.
Maybe the RST-Part of the Packet is doing something to the Phone.
One (maybe different) Happening was, when i wanted to Backup, and after Deletion of the Backup there had been some Brave-Browser config-Files left over. (This could had any Cause, but maybe something happened to make these visible, or the Config-Files where in the Ram and after the internal-flash-memory was full, they went unhidden to the flash after deletion??? )
That was really strange.
I just had not enough space for the Backup on the internal-flash-memory.
Guess that caused it, let the Ram overflow and then the Files from the Ram went visible, dont know.
The best would be to just give the Phone to someone of the PureOS-Team.
After some research i think on the pcapng, there is a TCP-Buffer-Overflow, initiated by NTP.
Also i have let the phone Offline since the happening.
Hope this all is not to bad.

I’d recommend studying the basics and not assuming every transmission which is not fully understand could be some malicious behaviour.

Vulnerabilities are present but most of the time not that apparent.


Yes i can understand that.
Sorry for this flaming. Edited now for good, i hope.
Friendly Regards !!

I can only repeat that.