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?

2 Answers 2


(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.

  • 3
    I didn't understand. Can you please explain a little bit more? How does the software connect to an HTTP proxy in the first place when the captive portal blocks all request excepts to its own? Jan 26, 2018 at 13:24
  • Hi, can you elaborate on your findings and if you have tested your theories? How can someone simulate the vulnerability in a lab? Sep 12, 2021 at 20:04

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.

  • I actually tested this with a mobile provider, and once you run out of quota, they block everything except port 53 and their HTTP captive portal. But you didn't have to use DNS on port 53, it was possible to use any protocol. And a few commercial VPN providers do offer OpenVPN on port 53... Nov 10, 2022 at 10:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .