How does mobile free internet bypass works? (UBT / FBT)

Question

I have encountered a mobile application named "HTTP Injector" which lets you get free internet access (UBT / FBT).

The process to get it work and receive free internet seems to be as follows:

1. Guidance videos on YouTube show that an end user needs to have a VPN server with SSH set up.

2. The end user then needs to find an open HTTP proxy using a common website like hidemyass.com

3. The HTTP Injector application generates a "payload" which is actually a "HTTP CONNECT" request to the proxy.

4. The HTTP Injector is loaded with the credentials and configuration needed for initiating an SSH connection to the VPN server.

5. The "payload" with the CONNECT method is sent via SSH (somehow, maybe SSH tunneling) and...

6. The end user is then able to move from the WiFi connection back to Cellular Data.

How does this works? How does the SSH connection keep alive over a SIM with no cellular data quota left? Moreover, How does the VPN server knows how to forward the request to the proxy? And how come this haven't been prevented yet?

Answer 1

(See edit below for solution)

I've been trying to figure this out myself, because I'm incredulous that this actually works. As far as I can tell from the guides I've seen (I haven't used it myself), what happens is:

1. User opens an HTTP connection to an HTTP proxy server.
2. The connection uses an X-Online-Host header to trick the captive portal into thinking they're actually connecting to the portal(?). I'm not sure why the portal falls for this, though.
3. Once through the portal and at the proxy, they just connect to the SSH server and tunnel out to the internet from that.

I would appreciate some more information, as I am myself curious to know why this works.

EDIT: I figured it out in the end. The portal checks for HTTP requests and injects a 302 response if the request doesn't go to the portal itself. What this software does is connect to an HTTP proxy and issue a CONNECT to the SSH server. Right after the CONNECT, it issues a legitimate GET request to the captive portal. The captive portal thinks the user is talking to its own server, and lets the request through, which then goes on to establish an SSH connection and continue to the internet.

In other words, the proxy server ignores the GET, the captive portal ignores the CONNECT, and everyone's happy. Pretty clever.

Answer 2

This seems to exploit a vulnerability in how that particular ISP handles quotas.

A lot of ISPs implement quotas at an application level and not at a packet level, so they can discriminate based on the protocol (and its properties like which URLs you're browsing in case of HTTP). It seems that they've got a loophole where they block HTTP(S?) traffic when you're out of data, but forgot to block SSH (which operates on a different port).

As a result you're able to tunnel your traffic through the SSH server and enjoy your free data. The same exploit could apply to DNS or ICMP (there is software out there that can tunnel traffic through innocent-looking DNS or ICMP packets) if you find out that they don't filter either of those protocols.