I've been looking at finding unique ways to deal with the x-vpn, its tricky in bypassing our firewall.
From what I can see it creates a tunnel to a private network within the client machine, and then passes the traffic via https, through a series servers categorised as content servers, is is needed for access via the firewall as most of the time this will be a sever that is side loading content for a general use website. and with 8000 servers for it to chose from, its not so easily blocked.
I had implemented a certain level of application blocks, which are circumventable, if you know what hidden files to look for and delete, and for some of the more savvy users it still remains in use.
my latest consideration of attack, is to see how to set route or a gateway for the utun6 connection it creates, that directs any traffic within the 172 network range, back to 172.0.0.1
netstat -nr
shows what gets routed and how when x-vpn is connected:
Internet:
Destination Gateway Flags Netif Expire
default 192.168.1.100 UGScg en0
1 172.21.0.1 UGSc utun6
2 172.21.0.1 UGSc utun6
3/10 172.21.0.1 UGSc utun6
3.64/11 172.21.0.1 UGSc utun6
3.96/13 172.21.0.1 UGSc utun6
....and so on
a route for every scope of the internet is formed via 172.21.0.1
so if I can confuse the client to not reach that gateway for the tunnel, or to direct traffic for the 172.0.0.0/8 subnet to 127.0.0.1
I most likely will be able to break it's functionality, in a way that most kids will never know to look.
but my capacity of doing network changes within terminal are limited, and proving to not work so far, but if I can achieve this via command line, I can then push it out as a command.
So far though my attempts to add routes have only applied to the en0 interface and not the utun6 interface
