Did you ever see a ISP print server hack like this?

Site Feedback and Other Questions
1

I started writing this post under the HELP section because i thought a printer APIPA was creating subnets in my LAN.. but this goes way beyond APIPA.... which may not even be playing any role here since the printer does get an IP on boot.

Apparently my ISP modem routes 10.22.96.1/24 as a valid external/routable address, which it also assign as gateway for 192.168.0.0/24 network, and all hosts along the way have print servers that somehow manages to send print jobs to my double-NAT'ed printer (an epson xp 214 if that matters)

Am I going insane? Anyone ever seen something like this? It is NOT a ISP provided printer. they only own the edge router which terminates their DOCSIS connection and nothing else.

Here's the data from my original post:

I have one stubborn printer connected via wifi to my openwrt router.

When I print it's settings page, it says it got the openWrt assigned DHCP address and nothing else:

ip address: 10.55.131.143
subnetmask: 255.255.255.0
default gateway: 10.55.131.1
APIPA: enable
primary dns: 10.55.131.1
secondary dns: none

So far so good. But there's a puzzle: I have one client on the same wifi/lan which was configured to use this printer on it's old address: 192.168.0.160... and it still manages to print! I imagine it is APIPA (Automatic Private IP Addressing)... but when I trace that on the that client, i see lots of things I cannot explain:

(context: my openwrt modem LAN is 10.55.131.1, wan is 10.55.130.101, and the ISP modem LAN is 10.55.130.1)

first is the path: it goes via external IPs!

$ tracepath 192.168.0.160 -n
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.55.131.1 (openwrt router)        15.957ms 
 1:  10.55.131.1 (openwrt router)         1.878ms 
 2:  10.55.130.1 (ISP router)             3.239ms 
 3:  10.22.96.1                          13.454ms 
 4:  201.6.73.177                        13.220ms 
 5:  201.6.65.46                         19.747ms 
 6:  201.6.65.32                         41.931ms 
 7:  no reply
^C

Then on the openwrt device, there's no knowledge about the first hop: 10.22.96.1 (i was double checking routing because at first I didn't notice the ISP router ip o the tracepath and assumed it was my openwrt router sending packages to the other LAN crated by apipa, but that is now obviously not the case. keeping this step regardless)

openwrt# ping 10.22.96.1
PING 10.22.96.1 (10.22.96.1): 56 data bytes
64 bytes from 10.22.96.1: seq=0 ttl=254 time=12.803 ms
64 bytes from 10.22.96.1: seq=1 ttl=254 time=9.944 ms
64 bytes from 10.22.96.1: seq=2 ttl=254 time=12.242 ms

openwrt# arp -l | grep 10.22
(nothing)

traceroute 192.168.0.160
traceroute to 192.168.0.160 (192.168.0.160), 30 hops max, 46 byte packets
 1  10.55.130.1 (10.55.130.1)  1.306 ms  1.227 ms  1.024 ms
 2  10.22.96.1 (10.22.96.1)  10.379 ms  10.509 ms  8.939 ms
 3  c90649b1.virtua.com.br (201.6.73.177)  12.042 ms  10.648 ms  12.154 ms
 4  c906412e.virtua.com.br (201.6.65.46)  12.963 ms  10.253 ms  12.256 ms
 5  c9064120.virtua.com.br (201.6.65.32)  12.658 ms  10.315 ms  12.084 ms
 6  *  *  *
 7  *  *  *

openwrt# arp -l | grep 192
(nothing)

openwrt# ping 192.168.0.160
--- 192.168.0.160 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

So now, its is clear those IPs are "outside", past the ISP router. let's see what we have there:

openwrt# nmap --all 201.6.73.177 -P0
Starting Nmap 7.95 ( https://nmap.org ) at 2024-11-30 17:47 UTC
Nmap scan report for c90649b1.virtua.com.br (201.6.73.177)
Host is up (0.014s latency).
Not shown: 994 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
515/tcp  open     printer
1723/tcp filtered pptp
9100/tcp open     jetdirect

while that server have a full print server by the look of the ports, the 10.22.96.0/24 range have "printers":

$ nmap --all -P0 10.22.96.0/24
.... all ips reply with ...
Nmap scan report for 10.22.96.52
Host is up (0.017s latency).
Not shown: 932 filtered tcp ports (no-response), 65 filtered tcp ports (host-unreach)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 10.22.96.53
Host is up (0.021s latency).
Not shown: 931 filtered tcp ports (no-response), 66 filtered tcp ports (host-unreach)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 10.22.96.54
Host is up (0.019s latency).
Not shown: 930 filtered tcp ports (no-response), 67 filtered tcp ports (host-unreach)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 10.22.96.55
Host is up (0.020s latency).
Not shown: 931 filtered tcp ports (no-response), 66 filtered tcp ports (host-unreach)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect

the 192.168.0.0/24 ips have different ports by the dozen-ips... e.g. 0-59 have 515 open, 60+ only ipp ports.

 $ nmap --all 192.168.0.1/24 -P0
Starting Nmap 7.95 ( https://nmap.org ) at 2024-11-30 18:12 UTC
Stats: 0:00:25 elapsed; 0 hosts completed (64 up), 64 undergoing Connect Scan
Connect Scan Timing: About 0.13% done
Stats: 0:03:40 elapsed; 0 hosts completed (64 up), 64 undergoing Connect Scan
Connect Scan Timing: About 1.66% done; ETC: 21:47 (3:30:47 remaining)
Nmap scan report for 192.168.0.0
Host is up (0.011s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 192.168.0.1
Host is up (0.0078s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 192.168.0.2
Host is up (0.0066s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect
...
Nmap scan report for 192.168.0.60
Host is up (0.013s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT     STATE  SERVICE
515/tcp  open   printer
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 192.168.0.61
Host is up (0.0083s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT     STATE  SERVICE
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 192.168.0.62
Host is up (0.010s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT     STATE  SERVICE
631/tcp  closed ipp
9100/tcp open   jetdirect

Nmap scan report for 192.168.0.63
Host is up (0.0076s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT     STATE  SERVICE
631/tcp  closed ipp
9100/tcp open   jetdirect
2

It takes about 1h to put sandbox with trivially exploitable ports exposed to get active attacks.
Since your openwrt is not exposed to internet hou should share your concern with ISP.

3

don't think i understood.

i don't think the ports are the issue. But the routing.

How can you get ISP routers to send you 10/8 ips? Then the latency is too low to be reaching other subscriber, I think. And the IPs whois and reverse dns do look "official".

And then on top of the weird routing, this is a really old printer, i don't think they have any remote management, specially one that can be hosted on edge like that. So lost on how this is "working". ...I will do some packet captures when i get more time, after i send ipp data to the external 192.168.0.160 ip and it magically goes back to my double-nat printer... whatever the heck it is it will have to go trhu the openwrt router.

4

Thanks for providing context! :slight_smile:

In step 1-2, you are leaking traffic from OpenWRT to your ISP.

This is because OpenWRT does not come with any default blackhole routes for private IP ranges (fx. RFC1918).

But you can add them yourself:

# uci add network route
# uci set network.@route[-1].interface='loopback'
# uci set network.@route[-1].type='blackhole'
# uci set network.@route[-1].target='10.0.0.0/8'
# uci set network.@route[-1].metric='100'
# uci add network route
# uci set network.@route[-1].interface='loopback'
# uci set network.@route[-1].type='blackhole'
# uci set network.@route[-1].target='172.16.0.0/12'
# uci set network.@route[-1].metric='100'
# uci add network route
# uci set network.@route[-1].interface='loopback'
# uci set network.@route[-1].type='blackhole'
# uci set network.@route[-1].target='192.168.0.0/16'
# uci set network.@route[-1].metric='100'
# uci commit network

In step 3-4, your ISP (CLARO / AS28573) routes the traffic on their internal network, and that is of course a little bonkers. They should have filtered private IP addresses at the edge. Assuming you are a normal FTTH customer, of course.

I tried to traceroute to 192.168.0.160 from inside CLARO but of course the dumb probe tool would not let me enter a private IP. :wink:

In any case, rest assured that they are not publishing 192.168.0.0 as an IPv4 prefix, or someone would be after them post-haste.

You mean 3rd hop.

Looks to me like AS28573 / CLARO have a transit network in between the CPE router (10.55.130.1) and their core routing infrastructure. And you are allowed to ping into that transit network.

Might be useful for "is the wan up?" type ping probes. You could add a route to it explicitly to OpenWRT now that you know it's there, but finding the correct subnet size takes a bit of probing. /24 as example below.

# uci add network route
# uci set network.@route[-1].interface='eth0'
# uci set network.@route[-1].target='10.22.96.0/24'
# uci set network.@route[-1].gateway='10.55.130.1'
# uci add network route

In case you want to be able to continue pinging into that network, but also you want some blackhole routes so you no longer leak traffic.

Same as before, they also route 192.168.0.0 towards 10.22.96.1 internally on their network.

Same as before, no ICMP replies after probe hits 201.6.65.32.

Fascinating.

Are you sure that you do not have any port forwarding rules configured in OpenWrt?

For example "tcp port 9100 --> send to this internal host".

That might cause nmap to show wrong results.

You can tcpdump on the same machine while you run nmap and examine the TTL of replies to see how far away they came from.

Same. Fascinating though.

Hmm, perhaps via a port forwarding rule in the router.

Doubt.

Think that's just link-local addressing for IPv4.

Same as fe80:: addresses you see on IPv6 interfaces.

You can ping it from another link-local address in the same broadcast domain, but under any normal circumstance the nearest router will drop traffic with an APIPA destination IP (169.254.0.0/16) rather than forward it, as per spec.

https://en.wikipedia.org/wiki/Link-local_address

1 Like
5

That was a thoughtful post. Thank you before anything.

First time hearing about type=blackhole.

Is it safe to blackhole 10/8 when my lan is on that subnet?

I do! it's part of my generic lazy setup. I add port forwards from :9100 to printer:9100, but only three ports 515, 631, 9100. not all of those. And the netbios port depends on the target IP range on that subnet. ...But you did find the reason for all the weird scans on 10.22.96.0/24. 192.168.0.160 and 201.6.73.177 are still a mystery.

(192.168 is "solved" with the blackhole route tho.)

I got some dumps but still haven't had the time to look into them. I think it will be only way to add more clues to this.

6

We should start with this.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:

grafik

Remember to redact passwords, MAC addresses and any public IP addresses you may have:


ubus call system board

cat /etc/config/network

cat /etc/config/wireless

cat /etc/config/dhcp

cat /etc/config/firewall
7

Np!

Your lan is not on that subnet, it is on 10.55.131.0/24. More specific prefixes take precedence when it comes to the routing table. /24 is more specific than /8. The prefix itself also has to match of course.

This is also how traffic destined for lans (well, at least the ones that are actually defined by virtue of an IP interface) doesn't go out to the internet...:

If you fx. add IP address 192.168.0.1/24 on an interface, automatic route table entries are created, one for "192.168.0.0/24 is directly connected on device ethX", you can see this one with ip -4 route list table main. Also a route to the host IP gets added as a /32 entry to the local table, see ip -4 route list table local.

Local table takes precedence over other route table, not sure exactly why, but in any case you can see references to all the route tables in use with ip -4 rule list. Notice "rule" not "route".

And of course, for subnets that are directly connected on an interface, like 192.168.0.0/24 above, the kernel will ARP into the network to talk to hosts, whereas for routes with a gateway statement, the kernel will resolve the gateway's MAC address and just forward the traffic there instead.

The kernel also uses ARP to find the gateway MAC, if it doesn't have a static ARP entry, so the gateway ("via X" in the route table) must of course itself be on a directly connected subnet.

(The directly connected subnets are indicated by "onlink" in the route table, expect to see the kernel use ARP probes to reach those, expect them to appear in arp -an output once probes resolve.)

(There's also a local "src" IP address in the routing table for directly-connected subnets. It is used when the local box is generating output traffic itself into that subnet, then that is used as the source ip.)

If no routes are found, the kernel will drop the traffic, and if it came from somewhere else, presumably send back an ICMP "Destination Unreachable" message. There's a list of reason codes in the Wikipedia page for ICMP, quite the smorgasbord.

The kernel might choose another reason code if you ask it to. For example a "prohibit" route will cause an ICMP reply with "Administratively Prohibited" as the reason, and "blackhole" will just drop the traffic without any ICMP reply. The list you can see in man ip route if you have ip (iproute2) with man pages installed.

(Forgive me if you know all this already, just trying to be thorough!)

Since you already added a 0.0.0.0/0 (default) entry to the main route table, traffic towards unknown RFC1918 networks and the like will no longer be dropped, but routed towards whatever gateway you specified on that route..

Oh, and a final exception to the "automatic routes" explainer above.. If you add an IP to the lo interface, Linux will not add an automatic route to the main route table, but to the "local" table instead, and no forwarded traffic will go there - forwarded traffic to that particular subnet will get nix'd, kind of like with a blackhole route.

Final, final note, I promise... "Reverse path filtering" is disabled by default in OpenWrt, but is pretty common on other network equipment, especially less primitive stuff. When enabled, it looks at the Source IP when traffic arrives on the box, makes sure that the source ip is onlink on the arrived-at interface, and if not drops the traffic as a "bogon" or "martian".

Okay, I think that concludes the "simple security measures you can do with the routing table" course, haha.

Cool, always fun when you guess something right! :slight_smile: