Strange Network Activity on iOS Devices

STRANGE NETWORK ACTIVITY ON IOS DEVICES

Most everyone trusts Apple and their iOS operating system. Not me, for three networking related reasons.

First, as I discovered in 2022, VPNs on iOS do not behave the way the should and Apple is fine with that. See my blog: VPNs on iOS are a scam.

Then too, iOS devices have an open TCP/IP port that can't be closed. To illustrate this, below is the result of an nmap port scan on an iPad running iOS version 16.4.1 which was current in May 2023. We see here that even a scan of only 1,000 TCP ports found two of them open - TCP port 49152 and TCP port 62078. This surprised me, as the last time I had looked into this, there was only one open TCP port. And, since iOS has no firewall, every iPad and iPhone is a sitting duck on whatever LAN it is connected to. For my personal privacy, I have not shown the full MAC address of the iPad below.

nmap -Pn 192.168.33.87
Starting Nmap 7.90 ( https://nmap.org ) at 2023-05-05 10:02 Eastern Daylight Time
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Nmap scan report for 192.168.33.87
Host is up (0.0082s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
49152/tcp open unknown
62078/tcp open iphone-sync
MAC Address: 5E:2D:63:xx:xx:xx (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 58.92 seconds

What does Apple have to say about having these ports open in their document: TCP and UDP ports used by Apple software products (Published April 21, 2022 and not revised since). Nothing. Heck, they can not even be bothered to say if the ports mentioned in the document are used for input, output or both.

What follows, is about the third reason.

- - - - - - - - -

I do something very few people do, I block data leaving my network that should not exist. I do this both because my router makes it very easy and because I like to understand what is happening on my Local Area Network.

This blog is about one type of data that should not exit my router destined for the Internet: packets to internal IP addresses.

Some IP addresses are set aside for internal use only. That means, for example, that my home can use them and you home can use them without causing a problem.

Take for example, IP addresses that start with 192.168.0 and 192.168.1 which are very commonly used by consumer routers. They are part of one group of internal-use-only IP addresses, those that start with 192.168. Also in this group is 192.168.3.x, 192.168.68.x and so forth.

Another group of internal-use-only IP addresses are those that start with 10. There are some other groups too, but these are the most common.

Since these IP addresses can not exist on the Internet, my router watches for them and blocks any data packets trying to get out to the Internet with a destination of an internal-only IP address. I'm a computer nerd, what can I say :-)

Over the years this has turned up some really strange stuff and Apple's iOS system has been, by far, the worst offender. I have had to modify the rules in some routers that I care for to stop logging this sort of thing because assorted iPhones and iPads have flooded the router log with this crap. I finally got so fed up that I decided to include samples of this network traffic here.

If you see this once, it's a fluke. Twice, fluke again. But I see it quite often.

In June 2020, I blogged: What is my iPad doing?. My iPad, running iOS 13.5.1, was detected contacting out-of-subnet, internal-use-only IP address 10.0.0.146. It wanted to make UDP requests to port 51625.

In May 2021, I blogged about More strange network activity from an iPad. This iPad (not mine) was detected contacting out-of-subnet, internal-use-only IP address 192.168.1.71 over the space of multiple days. It wanted to send UDP requests to ports 64452, 55197, 55202, 56727 and 49972. Earlier (October 2020) I had observed the same iPad trying to contact out-of-subnet, internal-use-only IP address 10.82.181.253 on UDP port 60761. The same day, it also tried to contact another out-of-subnet, internal-use-only IP address 10.1.10.40 on UDP port 60303.

Clearly, this is a thing. The assorted routers I oversee, show this activity with iOS devices and never with Android. Why? Why is there so much of this invalid data coming from assorted iOS devices? Is this traffic due to bugs in iOS? Bugs in an iOS app? Spying? If I was Apple and I wanted to spy on my customers, or I was directed to spy on my customers by the US Government, this is exactly how I would get data reported back to me.

A packet of data going to 10.1.2.3 (for example) would normally be thrown away by the first router on the Internet that comes into contact with it. Or, would it? The first such router is actually run by your ISP. It is not hard to imagine that rather than discarding these data packets, the government that an ISP lives under directs the ISP to save them. I am not saying this is happening. This is just a thought experiment. But, if I ran Apple and I was directed to spy on my customers this is how I would exfiltrate the data on the government targets.

The data below are excerpts from the router firewall log.

MAY 2023

The device in question is an iPad. The source IP address below (SRC) has been changed, the destination (DST) has not. As with the other examples on this page, this is here because the iPad was NOT on a 192.168.1.x subnet/network. On the days shown below, the iPad was all alone. It was the only device on the LAN. All residents of the home were away so no human touched the tablet. All the requests were UDP, none were TCP. I find it interesting that the destination ports do not repeat. This gives me no hook to hang my hat on.

On May 31st, it took Memorial Day off.
On May 30th, in the space of 5 seconds, it made 10 outbound requests to port 61703.
On May 29th, in the space of 1 second, it made 2 outbound requests to port 57406.
On May 28th, in the space of 4 seconds, it made 10 outbound requests to port 52340.
On May 28th, in the space of 2 seconds, it made 3 outbound requests to port 53954.
On May 27th, in the space of 5 seconds, it made 10 outbound requests to port 63134.
On May 26th, in the space of 5 seconds, it made 10 outbound requests to port 53642.
On May 25th, in the space of 3 seconds, it made 6 outbound requests to port 54350.
On May 24th, in the space of 5 seconds, it made 10 outbound requests to port 60994.
On May 24th, in the space of 2 seconds, it made 3 outbound requests to port 61039.

May 30 13:52:49 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=51421 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:49 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=40385 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:48 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=60208 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:47 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=11831 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:47 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=33486 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:46 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=56352 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:46 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=26778 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:45 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=13659 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:45 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=20962 PROTO=UDP SPT=54233 DPT=61703
May 30 13:52:44 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=40392 PROTO=UDP SPT=54233 DPT=61703

May 29 20:35:59 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=34003 PROTO=UDP SPT=55234 DPT=57406
May 29 20:35:59 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=6349 PROTO=UDP SPT=55234 DPT=57406

May 28 20:27:15 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=16372 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:15 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=22643 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:14 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=30741 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:14 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=24963 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:13 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=8431 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:13 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=55846 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:12 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=29251 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:12 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=37426 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:11 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=32228 PROTO=UDP SPT=61429 DPT=52340
May 28 20:27:11 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=21740 PROTO=UDP SPT=61429 DPT=52340

May 28 11:30:00 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=9306 PROTO=UDP SPT=64742 DPT=53954
May 28 11:29:59 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=28978 PROTO=UDP SPT=64742 DPT=53954
May 28 11:29:58 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=3369 PROTO=UDP SPT=64742 DPT=53954

May 27 20:10:22 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=42981 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:21 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=53457 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:21 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=10254 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:20 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=49408 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:20 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=40326 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:19 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=17389 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:19 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=475 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:18 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=40113 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:18 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=8196 PROTO=UDP SPT=49596 DPT=63134
May 27 20:10:17 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=22805 PROTO=UDP SPT=49596 DPT=63134

May 26 10:18:29 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=61784 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:29 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=17965 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:28 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=24546 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:27 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=47912 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:27 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=17341 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:26 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=43002 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:26 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=54398 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:25 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=45653 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:25 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=48933 PROTO=UDP SPT=60619 DPT=53642
May 26 10:18:24 SRC=192.168.6.7 DST=192.168.1.66 LEN=57 ID=59573 PROTO=UDP SPT=60619 DPT=53642

May 25 20:02:27 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=63301 PROTO=UDP SPT=58887 DPT=54350
May 25 20:02:26 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=60737 PROTO=UDP SPT=58887 DPT=54350
May 25 20:02:26 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=46471 PROTO=UDP SPT=58887 DPT=54350
May 25 20:02:25 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=52132 PROTO=UDP SPT=58887 DPT=54350
May 25 20:02:25 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=29832 PROTO=UDP SPT=58887 DPT=54350
May 25 20:02:24 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=2486 PROTO=UDP SPT=58887 DPT=54350

May 24 19:35:00 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=36907 PROTO=UDP SPT=49215 DPT=61039
May 24 19:34:59 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=46901 PROTO=UDP SPT=49215 DPT=61039
May 24 19:34:58 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=16737 PROTO=UDP SPT=49215 DPT=61039
May 24 17:49:42 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=62423 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:42 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=5022 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:41 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=40548 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:41 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=8769 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:40 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=19326 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:40 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=21038 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:39 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=24199 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:39 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=34394 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:38 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=14125 PROTO=UDP SPT=64911 DPT=60994
May 24 17:49:37 SRC=192.168.6.7 DST=192.168.1.65 LEN=57 ID=40933 PROTO=UDP SPT=64911 DPT=60994

An iPad sending UDP requests to a private IP address

APRIL 27, 2023

The device in question is an iPad. The source IP address below (SRC) has been changed, the destination (DST) has not. This is here because the iPad was NOT on a 192.168.1.x subnet/network. So why send data there? I dunno. All the requests were UDP, none were TCP.

At 11:13AM, in the space of 5 seconds, it made 10 outbound requests to port 63528.
At 10:42AM, in the space of 6 seconds, it made 10 outbound requests to port 56648.

Apr 27 11:13:24 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=27721 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:24 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=23553 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:23 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=38664 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:23 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=32253 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:22 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=63410 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:22 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=19679 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:21 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=14283 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:21 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=14967 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:20 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=57367 PROTO=UDP SPT=58310 DPT=63528
Apr 27 11:13:20 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=63096 PROTO=UDP SPT=58310 DPT=63528

Apr 27 10:42:19 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=6137 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:18 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=56409 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:18 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=24898 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:17 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=52676 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:17 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=41439 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:16 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=34536 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:16 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=37250 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:15 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=8301 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:15 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=28648 PROTO=UDP SPT=61145 DPT=56648
Apr 27 10:42:14 SRC=192.168.6.7 DST=192.168.1.154 LEN=81 ID=13269 PROTO=UDP SPT=61145 DPT=56648

An iPad sending UDP requests to a private IP address

FEBRUARY 2023

These outbound requests came from an iPad, I do not know the version of iOS it was running. The LAN IP address (SRC) of the iPad has been changed, but the important point is that it was not on a 192.168.1.x subnet. We see UDP requests to 192.168.1.64 (DST), targeting a handful of assorted high numbered ports: 57192, 32761, 55236 and 46308.

Feb 20 13:05:53 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=51824 PROTO=UDP SPT=55236 DPT=57192
Feb 20 13:05:52 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=38517 PROTO=UDP SPT=55236 DPT=57192
Feb 20 13:05:52 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=1884 PROTO=UDP SPT=55236 DPT=57192
Feb 20 13:05:52 SRC=192.168.98.102 DST=192.168.1.64 LEN=116 ID=10684 PROTO=UDP SPT=55236 DPT=32761
Feb 20 13:05:52 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=3982 PROTO=UDP SPT=55236 DPT=57192
Feb 20 13:05:52 SRC=192.168.98.102 DST=192.168.1.64 LEN=116 ID=29734 PROTO=UDP SPT=55236 DPT=32761

Feb 19 18:43:30 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=48191 PROTO=UDP SPT=57518 DPT=46308
Feb 19 18:43:30 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=6174 PROTO=UDP SPT=57518 DPT=46308
Feb 19 18:43:30 SRC=192.168.98.102 DST=192.168.1.64 LEN=116 ID=41521 PROTO=UDP SPT=57518 DPT=32761
Feb 19 18:43:30 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=23627 PROTO=UDP SPT=57518 DPT=46308
Feb 19 18:43:30 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=62062 PROTO=UDP SPT=57518 DPT=46308
Feb 19 18:43:30 SRC=192.168.98.102 DST=192.168.1.64 LEN=116 ID=57157 PROTO=UDP SPT=57518 DPT=32761

Feb 19 16:05:34 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=40059 PROTO=UDP SPT=54283 DPT=46308
Feb 19 16:05:34 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=14589 PROTO=UDP SPT=54283 DPT=46308
Feb 19 16:05:34 SRC=192.168.98.102 DST=192.168.1.64 LEN=80 ID=30408 PROTO=UDP SPT=54283 DPT=46308
Feb 19 16:05:34 SRC=192.168.98.102 DST=192.168.1.64 LEN=116 ID=55006 PROTO=UDP SPT=54283 DPT=32761

an iPad sending UDP requests to assorted high ports

MAY 16, 2020

This was an iPhone. TCP port 7000 is very popular in my observations of iOS devices. In this case, the LAN/subnet the iPhone was on, was indeed 192.168.50.x. The destination IP address, 10.0.1.2 is as suspicious as suspicious gets.

May 16 19:15:11 SRC=192.168.50.7 DST=10.0.1.2 LEN=64 TTL=63 PROTO=TCP SPT=51880 DPT=7000 SYN
May 16 19:15:09 SRC=192.168.50.7 DST=10.0.1.2 LEN=64 TTL=63 PROTO=TCP SPT=51880 DPT=7000 SYN
May 16 19:15:08 SRC=192.168.50.7 DST=10.0.1.2 LEN=64 TTL=63 PROTO=TCP SPT=51880 DPT=7000 SYN
May 16 19:15:07 SRC=192.168.50.7 DST=10.0.1.2 LEN=64 TTL=63 PROTO=TCP SPT=51880 DPT=7000 SYN
May 16 19:15:06 SRC=192.168.50.7 DST=10.0.1.2 LEN=64 TTL=63 PROTO=TCP SPT=51880 DPT=7000 SYN
May 16 19:15:05 SRC=192.168.50.7 DST=10.0.1.2 LEN=64 TTL=63 PROTO=TCP SPT=51880 DPT=7000 SYN

iPhone trying to contact TCP port 7000