But why should it be necessary? The route won’t be adopted by the GL router anyway?
I don’t get it.
That is still open to debate why it is. Either there is a bug in the Glinet routers, they removed the classlessroute option in their scripts without knowing it, or there was a comit in the past to OpenWrt where classlessroute is now default 0. Like I said I cant test it.
I think it’s not a bug but how routers work.
Since they combine routes and interfaces, they should be completely resistant against this attack. Spoken from an attacker on WAN side, ofc.
that makes zero sense. as also seen here: FS#2681 - ISP's DHCP option 121 makes 18.06.5 get no default GW · Issue #8519 · openwrt/openwrt · GitHub
example from a few years ago on OpenWRT where a ISP was sending routes with DHCP 121. as you see in this example, the OpenWRT router adopted the DHCP 121 routes.
Also the traffic from the router itself is also affected by this issue and not filtered by any rules.
Setting the default route to a malicious device isn’t a problem.
I think you dont understand what I said. The side topic of that example with the default gw is irrelevant. The example I linked is just to show: OpenWRT routers DO use DHCP 121 and will accept and confiure the routes. You claimed they dont. I said this is either then a bug in the Glinet routers, OR Glinet removed the ability, OR OpenWRT changed the behavior to default off. That is all I said.
1 Like
I cannot believe this thread is so long and I spent half a day to read this thread, the blog and do some test.
Route itself does not do everything. There is still firewall settings on the router to do vpn policy.
I don’t think it should be a CVE though. But it is a good article and debate.
There are other things worth more debating, e.g. dns rebind protection, arp spoofing etc.
2 Likes
Do you mean there is no routing table changes when the VPN is active? Can please clarify because I have also been testing it since this morning haha
Well, he got a CVE for it! But, I kind of agree with you as I said previously it’s a new technique rather than a vulnerability!
Once the celullar connection is established, the following process (clearly with Option 121) is used to renew the IP from the ISP side:
udhcpc -p /var/run/udhcpc-rmnet_mhi0.pid -s /lib/netifd/dhcp.script -f -t 0 -i rmnet_mhi0 -x hostname:X3000 -C -R -O 121
Can the ISP install a static route (similar to the one explained in the CVE) on the customer device using his DHCP?
I think I’ve found the answer for my Q: It seems that after I enabled the OpenVPN tunnel, the script /etc/firewall.vpn_server_policy.sh got called to create iptables mangling rules!
Don’t be dramatic, what scandals?
Do you really read the article you linked?
The router does respect option 121 of DHCP from upstream network.
But it seems that it won’t create different routes, at least in my test setup it did not.
0.0.0.0/1 just changed the default gateway, which is fine because it wont affect VPN.
The pushed route has to obay some patterns. Otherwise it will not apply.
I wont spent more time on this though.
2 Likes
I guess I will further test this with my available router models as soon as they arrived. 
Even if I am still sure that it’s meaningless what happens on WAN side.
1 Like
This is the point - if your client establishes the VPN from the client side, the most the attacker will see is an encrypted packet. They will be able to see what VPN provider or concentrator you are connecting to and related session initiation that is already available to the public wifi provider anyway, and everything from that point on will be encrypted. A big fat nothing for the attacker. TBH, outside of idle curiosity, I would not see a reason to continue testing @admon.
Trust me it’s not meaningless!
That’s what I have told when you tested it at the beginning of this post.
@alzhao i think you’re referring to the VPN policy that does the marking for VPN packets ? And this policy takes precedence over the routing table ?
I think the CVE itself focuses on the default route…
If it is a LAN route, It should be only one or several target IPs affected.
If I am being honest, this is really starting to feel like trolling @SpitzAX3000 ;).
Not really- the CVE focuses on a LAN client. connected to a VPN. So for example I did the CVE test using two machines (a victim with a vpn and an attacker m) connected to gl.inet device.
What I am trying to do now next is to do the same but by attacking my GL modem while it’s connected in a VPN client mode.