[CONTACT]

[ABOUT]

[POLICY]

title card XiHz title card ran

Found at: gopher.blog.benjojo.co.uk:70/ip-address-squatting

 Who is squatting IPv4 addresses?
 ===

title card

 title card

ran out of IP(v4) addresses

RIPE NCC

looking at a 2 month wait for a recycled IPv4 /24 block

 It's an established fact on the internet that we have ran
out of IP(v4) addresses, and we are starting to see the
pressure on obtaining IPv4 space. For example if you want to get a
/24 block from RIPE NCC when you sign up as a member, then
you are currently looking at a 2 month wait for a recycled
IPv4 /24 block.

RIPE v4 waiting list

 RIPE v4 waiting list

We are getting there slowly

 The easy thing here is to say, "Well just use IPv6" but
well... We are getting there slowly.

RFC1918 Private network space

 But what happens if you have run out of local IPv4 space?
Or for some reason the RFC1918 Private network space is not
an option anymore? Some people resort to squatting IP address
space!

huge amount of network and home routers squatting on those addresses internally

 For the case of this post, I will define IP address
squatting as "using IP addresses that are not RFC1918 defined and
not your unicast space issued by a RIR". The first thing that
instantly comes to mind is Cloudflare obtained the addresses 1.1.1.1
and 1.0.0.1 to run a DNS resolver on, but had to fight back
against a huge amount of network and home routers squatting on
those addresses internally (I do also wonder if the last unicast
/24 block has similar issues)

even parents

 This problem is not that surprising though, your local
friendly sysadmin might be able to tell you of a story where they
have caught their colleagues, customers, or even parents squatting
on addresses.
 But how big of an issue is this? If only we had a large
amount of well known IP address blocks that we can make a safe
bet on not being used.
 ## Enter the US Department of Defence

AS8003

AS749

the Pentagon said

 At the start of 2021, the DoD started to announce huge
sections of their massive IP block allocations ( around 234000 /24's
worth ) out of AS8003, and then moved them to AS749. This was
initially suspected to be preparation of an IP sell off, since the
cost of v4 addressing has reached impressive highs recently.
However later on the Pentagon said:
 >  `" This pilot will assess, evaluate, and prevent
unauthorized use of DoD IP address space "`

darknet

 To me this reads as, "We don't want our large IP blocks
that are mostly unannounced in the BGP DFZ hijacked by people"
and at the same time "We have some people who want to run a
massive darknet"
 Running on these assumptions, we can assume that whatever
is announced by AS749 is unused DoD space, and so anything on
the internet pointing to those blocks is squatting (either by
typo or purpose) to at least some degree (assuming it's not a
DoD site itself)
 But how do we know what is pointing to anything on the
internet? How do we get massive amounts of DNS Data?
 ## Enter Certificate Transparency

simply asking them

tapping users DNS logs

Certificate Transparency (CT) logs

 There are many ways to get DNS data, You can obtain most
TLD's DNS zone files by simply asking them, you could use
Passive DNS services that obtain their data generally by tapping
users DNS logs, or you could use Certificate Transparency (CT)
logs to extract DNS names out of SSL certs.

bgp.tools

 I am already using the CT option for DNS data on
bgp.tools. Approximately every 2 weeks I complete around ~30B DNS
queries and compile into a file that is just IP addresses mapping
to host names. This allows the website to easily show what
DNS records point to an IP address block.

bgp.tools DNS view

 bgp.tools DNS view

Cloudflare run a decent site that shows statistical numbers and graphs

crt.sh

 There are other tools to look into CT logs too, Cloudflare
run a decent site that shows statistical numbers and graphs and
for searching CT logs without downloading them all there is a
great utility called crt.sh that Sectigo operates (A rebranding of
Comodo).
 But how do we use this data to figure out cases of IP
squatting, especially inside local LANs where we would not generally
expect to see public DNS entries pointing to them?
 ## Enter the WD MyCloud

NAS

Plex and other applications do a similar thing

 Western Digital released a bunch of compact NAS devices
that also have a remote access feature (Hence the "My-Cloud"
branding). This allows users to access their devices remotely even if
they are outside of the local network that the device is on.
However, since it's generally a requirement to have these kinds of
connections be encrypted, WD issues SSL certs for each one of these
devices, Plex and other applications do a similar thing in order to
allow secure connections in browsers.
 Using this fact, we can scan for these WD Devices by
grepping for the domain that these devices use called
`remotewd.com`:
 ```
 [xxx.bgp.tools] $ pv mega | grep remotewd.com$ > remote-wd
 20.5GiB 0:00:30 [ 689MiB/s] [============================>]
100%
 [xxx.bgp.tools] $ wc -l remote-wd
 2248019 remote-wd
 [xxx.bgp.tools] $ tail remote-wd
223.255.150.74,device-0675828b-2e8c-4be5-96e7-0a595fbae6dc.remotewd.com
223.255.150.74,device-9e007f60-c53d-43dd-8743-4ac1a569952e.remotewd.com
223.255.156.58,device-190d10b4-2465-4d52-91e1-fc223885a510.remotewd.com
223.255.157.74,device-d3a1aa96-f383-467f-a9ae-dfa8b7bfdb81.remotewd.com
223.255.255.67,device-local-c3712a54-3c25-442e-90ee-a56c02ad9db4.remotewd.com
 ```

UPNP

 So here we can see that a single MyCloud device has two
DNS names. `device-$UUID.remotewd.com` and
`device-local-$UUID.remotewd.com`. The difference is the `device-local` one's map to the local
address on the device, and the `device-` one's map to the Internet
address (accounting for NAT). Presumably the WD devices are doing a
form of automatic port forwarding like UPNP.
 The neat thing is that we can find one UUID and use it
to grep for both the WAN address and the LAN address of a
device:
 ```
 [xxx.bgp.tools] $ cat remote-wd | grep
0675828b-2e8c-4be5-96e7-0a595fbae6dc
192.168.1.103,device-local-0675828b-2e8c-4be5-96e7-0a595fbae6dc.remotewd.com
223.255.150.74,device-0675828b-2e8c-4be5-96e7-0a595fbae6dc.remotewd.com
 ```

RFC1918

 So, great! Now we can write a script to go and find
abnormal LAN addresses for these devices. We do this by checking
that the local address does not match the internet address, and
that the local IP address space is outside of IP ranges defined
by RFC1918.

small-ish program

click here for a full dump

 With a small-ish program we get this: (click here for a
full dump)
 ```
 1.0.0.117 = 8ece6a15-2fed-420d-95dd-d920d5666869 is a IP
squat?
 1.0.0.132 = ecd4bff4-01a5-40d6-8e70-cc9e102de492 is a IP
squat?
 ...
 1.1.10.15 = 09a3b350-27a6-45f1-b44d-f152cbcb3e4c is a IP
squat?
 1.1.1.111 = ab7cb7f7-ae9a-4390-a526-99248ac55593 is a IP
squat?
 1.1.1.1 = 4c0fe0e5-8f84-43e4-9cba-b76f9cddb368 is a IP squat?
 1.1.1.17 = 44836275-6825-4767-8b70-a5e04c4a820e is a IP
squat?
 ...
 2.12.1.6 = cb578ebe-9319-4451-950c-e03ece3549b7 is a IP
squat?
 2.2.2.162 = 971ad945-056c-40b2-9e68-ffa7bed37da8 is a IP
squat?
 2.2.2.249 = f1b13fbb-6297-4ac0-9724-5ce2bbfa9f91 is a IP
squat?
 2.2.2.38 = cf92953b-e625-4bdf-9229-ab3933f18d9b is a IP
squat?
 2.43.1.33 = a26d4b29-4145-48eb-a439-64ca4a6aa9f9 is a IP
squat?
 ...
 4.28.65.10 = b9fd42f2-3491-4775-9d3d-dce4bc89ae5b is a IP
squat?
 4.3.80.8 = ee009944-4054-43fa-a7f7-08927ea86cfb is a IP
squat?
 4.4.4.3 = a5ad8ecd-93b1-4690-b21a-4322cd5e02cb is a IP squat?
 4.8.19.16 = 733745f3-e9e0-4a7d-abb1-d5cc0aaf0b30 is a IP
squat?
 ...
 5.35.1.156 = f2325dc8-a79e-41e7-bd99-fe30d6afa25a is a IP
squat?
 5.5.1.75 = d69d77c9-181c-441f-af19-c881880534db is a IP
squat?
 ...
 8.34.143.56 = 4fb6a202-98f1-4e98-92ec-9357ecb1c4eb is a IP
squat?
 8.8.8.92 = 78a897cb-48d1-46c0-ba91-66c353bab06c is a IP
squat?
 8.9.80.111 = 28968a74-edc2-42ce-b7d0-5416f958245c is a IP
squat?
 ...
 9.9.52.93 = f4a6f3c1-5c44-4fb5-b96c-7203272cc297 is a IP
squat?
 9.9.9.24 = 10df8b8b-74cb-4230-a236-12105de7173e is a IP
squat?
 9.9.9.38 = 8b9707fa-7b59-49dd-b7a3-4ef5b88659ff is a IP
squat?
 11.0.0.103 = d13da0c6-8e6e-43fb-8109-a35d6b469101 is a IP
squat?
 11.0.0.113 = 55364bcd-389d-4464-aa71-c2fc87dfb2bf is a IP
squat?
 11.0.0.16 = 5502da73-a1dc-4e90-b21c-8d30c76058cf is a IP
squat?
 ...
 99.99.99.91 = f95c5933-eaf9-48ce-a87a-cf9567df305b is a IP
squat?
 100.0.0.100 = 5349507f-d05b-496e-93b5-9766e948b8d2 is a IP
squat?
 100.0.0.10 = 12d38773-813e-49cc-bdd7-48a884fcf829 is a IP
squat?
 ...
 168.190.30.15 = a3f43288-2d34-4764-ba13-65a1e00dded0 is a IP
squat?
 168.192.0.252 = 6a8248c2-9a35-47c7-8061-469faa7adbac is a IP
squat?
 168.192.0.34 = fb2cf7f1-0a3b-42d0-b04d-8d816d69a3bb is a IP
squat?
 168.192.110.102 = 183be2ee-4913-45f2-867f-40c5038f757b is a IP
squat?
 168.192.1.111 = bba93f2f-32d3-41e0-ab98-0c08f6d2b438 is a IP
squat?
 168.192.1.12 = cb1fcb60-a0ff-474a-b8a2-9f6246e5f3d9 is a IP
squat?
 168.200.1.6 = 95e5745c-a102-4ccd-92aa-651eaf0af006 is a IP
squat?
 ...
 192.167.4.118 = a84e8794-cae0-4e9a-ba8a-fce18f7e6a0f is a IP
squat?
 192.167.60.157 = 4d24f693-e9ea-4e70-b945-478a1fdabfb0 is a IP
squat?
 192.169.0.100 = 5f48efb9-a7d4-45d3-8ba3-e4234daff96c is a IP
squat?
 192.169.0.100 = da4b9dc3-6d99-4eb7-a67b-ab244515baf9 is a IP
squat?
 192.169.0.100 = e050a252-9636-4a89-ac2a-02a4acb6bb8a is a IP
squat?
 ...
 193.167.1.38 = 6481ac7d-c5b4-4ba6-ae9e-166a8ff76a15 is a IP
squat?
 193.168.0.178 = 37b18ba6-f01c-4f4d-a08c-48450c6d47af is a IP
squat?
 193.168.100.41 = 0ce6f895-d82a-479e-bd7f-b873418582e7 is a IP
squat?
 ...
 ```
 It appears that triplets are popular (IE, `1.1.1.X`,
`2.2.2.X`, `3.3.3.X`), and common "fat fingering" of RFC1918 ranges,
with `193.168.X.X`, `191.168.X.X`, `192.186.X.X` showing up.

Cloudflare's 1.1.1.1

Google's 8.8.8.8

Quad9's 9.9.9.9

UK Government DNS

Freenom's 80.80.80.80

Quad101

114dns.com

 Triplets are likely to collide with popular anycast DNS
resolvers, like Cloudflare's 1.1.1.1, Google's 8.8.8.8, Quad9's 9.9.9.9,
UK Government DNS 25.25.25.25, Freenom's 80.80.80.80 , Quad101,
114dns.com, etc.

bgp.tools bulk lookup API

 The typos are just unfortunate. But what about possible
squats? Well we can look up the announcing ASNs of the IP list
using the bgp.tools bulk lookup API:
 ```
 $ echo "begin" >> lookup-file
 $ echo "verbose" >> lookup-file
 $ cat output-sorted.txt | awk '{print $1}' >> lookup-file
 $ echo "end" >> lookup-file
 $ cat lookup-file - | nc bgp.tools 43  | tee
resolved-list
 13335   | 1.0.0.117        | 1.0.0.0/24
 | US | ARIN     | 2010-07-14 | Cloudflare, Inc.
 13335   | 1.0.0.132        | 1.0.0.0/24
 | US | ARIN     | 2010-07-14 | Cloudflare, Inc.
 ...
 9644    | 223.61.1.108     | 223.48.0.0/12       |
KR | APNIC    | 0001-01-01 | SK Telecom
 $ cat resolved-list | wc -l
 3585
 $ cat resolved-list | egrep '^749 ' | wc -l
 171
 ```
 So out of all the suspected IP squats detected using the
WD MyCloud data, around 5% of them are on suspected unused
DoD space.
 We can also run this in reverse and figure out the most
common RFC1918 space that people use:
 ```
 $ ./wd-stats | sort -n
      7,192.0.2.0/24
     10,198.18.0.0/15
     55,192.0.0.0/24
    216,100.64.0.0/10
    850,169.254.0.0/16
  87328,10.0.0.0/8
  10773,172.16.0.0/12
 966115,192.168.0.0/16
 ```
 But this only covers residential/prosumer markets who would
stereotypically purchase a device like this. What about the "proper" server
world?
 ## Enter the AWS VPC Endpoint

"Interface Endpoints"

 AWS Virtual Private Clouds (VPCs) (think of them like
network LANs) have a fun feature called "Interface Endpoints" that
allow you to put AWS services (like S3) that would normally only
be reachable on public address spaces to appear as local IP
addresses in your VPC address space. This is useful since it can
remove the need for some servers to have any outbound internet
access at all. Assisting in security posture amongst other things.
 But since people also want to communicate with AWS
securely, even inside the presumably high security of AWS VPCs, the
new interface endpoint needs an SSL cert and a DNS entry. This
is useful since it gives us a clue on who is using what IP
addresses inside their VPC's.
 ```
 $ pv mega | grep vpce- | grep vpce.amazonaws.com >
vpc-endpoints
 $ wc -l vpc-endpoints
 234919 vpc-endpoints
 ```
 ```
 $ ./vpc-stats | sort -n
      1,192.0.0.0/24
      2,192.0.2.0/24
      5,198.18.0.0/15
    741,100.64.0.0/10
   1096,192.168.0.0/16
  14199,172.16.0.0/12
  23677,10.0.0.0/8
 ```
 We can see that `10.0.0.0/8` and `172.16.0.0/12` are popular
picks for VPC addresses. But what about possible squats?
 It's worth saying now, it's possible that some of these
are not IP Squats and are instead Bring Your Own IP inside of
Amazon, or complex Direct Connect setups. But if we see DoD AS749
then we can assume those are cases of IP squatting.
 ```
 $ ./vpc-stats  | tee vpc-output | sort -n | head
 1.100.126.10
,bucket.vpce-0b3bb7a5b64eb1981-ymxb0boe-eu-west-1b.s3.eu-west-1.vpce.amazonaws.com
 1.100.126.10
,bucket.vpce-0b3bb7a5b64eb1981-ymxb0boe.s3.eu-west-1.vpce.amazonaws.com
 1.2.3.26
,bucket.vpce-08ed65ca57dce3ab4-i01pkug2-us-gov-west-1b.s3.us-gov-west-1.vpce.amazonaws.com
 3.230.20.24
,bucket.vpce-018d369d104a616c8-a0sfaap3.beta.s3.us-east-1.vpce.amazonaws.com
 4.0.1.68
,bucket.vpce-0e90ca15c8f461fd9-zl6yishp-ap-northeast-2a.s3.ap-northeast-2.vpce.amazonaws.com
 4.0.2.137
,bucket.vpce-0e90ca15c8f461fd9-zl6yishp-ap-northeast-2c.s3.ap-northeast-2.vpce.amazonaws.com
 ...
 ```

full data here

 And the same checks for suspected DoD IP squats (full data
here):
 ```
 $ cat vpc-ips - | nc bgp.tools 43 | tee vpc-ips-resolved
 4766    | 1.100.126.10     | 1.96.0.0/12
| KR | APNIC    | 0001-01-01 | Korea Telecom
 0       | 1.2.3.26         | 
      |    | Unknown  | 0001-01-01 |
ERR_AS_NAME_NOT_FOUND
 14618   | 3.230.20.24      | 3.224.0.0/12
| US | ARIN     | 2005-11-04 | Amazon.com, Inc.
 3356    | 4.0.1.68         | 4.0.0.0/9
   | US | ARIN     | 2000-03-10 | Lumen (Level 3)
 ...
 $ wc -l vpc-ips-resolved
 829 vpc-ips-resolved
 $ cat vpc-ips-resolved | egrep '^749 ' | wc -l
 138
 ```
 Using this limited view inside of VPC Subnets, we can see
that over 16% of all of the non-RFC1918 space is suspected
squatted DoD space!
 ## Enter the IPv4 address market
 As we can see, while the DoD is sitting on some huge
volumes of IPv4 space, buying the space off them might require
additional work to "clean up" decades of assumptions that it was
unlikely to become reachable internet addresses.
 At the time of writing the market price for an IPv4
address is around 50 USD, this means that assuming AS749 is the
DoD's "spare" blocks then using naive maths the US Department of
Defence is sitting on approx 2,997,516,800 USD worth of IP
addresses.

F-35 fighter jet is 78M USD

 That's quite a lot! Though it's worth keeping in mind that
assuming that the cost of a F-35 fighter jet is 78M USD, then
they could exchange their entire spare IP blocks for "just" 38
F-35's. Doesn't really seem like much. Also given how much money
countries spend on defence, I can understand why the DoD doesn't
seem to be trying to cash out on their IP space just yet ;)
 An amusing thought really. That the price of a /12 and
/13 is around the same as a F-35.
 ---

RSS feed

Twitter

 If you want to stay up to date with the blog you can
use the RSS feed or you can follow me on Twitter
 

Also, I'm currently looking for work

from March onwards. If you like what I do or think that you
could do with some of my bizarre areas of knowledge, please
contact me over at workwith@benjojo.co.uk!

 Until next time!


AD:

Advertising? Click here to get started!