4

I'm aware the risks of connecting to a public AP poses as well as how MITMish is the hotspot approach.

I wonder if there is anything in the OS layer (iOS, Android) that prohibit the execution of applications installed in the device such as browser or Facebook app inside Captive Portal.

The scenario I have in mind is some cool button that appears in the screen after user is authenticated in the hotspot that has a nifty "whatsapp://", "googlechrome://" or even URL' s that are "app-aware" like Messenger "m.me/coolPage" that open in the browser and than closes opening the Messenger application, if installed.

If there are these controls in place for this kind of attack, can they be circunvented by any means?

Thanks in advance!

Improve this question

1 Answer 1

Reset to default
2

In a browser can a captive portal page do everything what another page can. So the only additional danger is that you open it without clicking on it. But that's true for many pages in the modern web, everywhere is stuff loaded in invisible iframes and similar.

There were exploits to do operation system level stuff, e.g. calling costly numbers via tel:// URLs, which was possible from all websites. Modern phones only show you the dialer with the number, but at this time they started dialing automatically. Running other URL intents like whatsapp:// and similar is possible as well, but the apps providing such intents should be secure to do nothing dangerous without more user interaction.

The other less common aspect is, that apps which try to load resources before the portal is detected on the OS level (if there is such a detection) get the portal instead of their resources. Here the security is the same as in an insecure network, where someone can spoof the API endpoints and more.

So the captive portal page is just a hijacked HTTP request with the same consequences as in other hijacking scenarios.

Improve this answer
3
  • 1
    I appreciate your answer, but when you say a captive portal can do everything other pages can, I have to disagree. The captive portal is intended to be a "sandboxed browser" used only to authenticate users before giving them access to the Internet, so there is much more restrictions related to iframes, Javascript and others I didn't touched directly while testing. Testing on Android, links that tried to open other applications where blocked because of the intent they where refering. Again, thanks for the answer.
    – Francisco Zanatta
    Commented Mar 6, 2018 at 18:05
  • Recent Android often shows you a special browser (not sure how sandboxed it is) but other apps may see the portal as well. I would guess some apps communicating all the time with their server will hit the portal at their API endpoint before the OS finished the portal test. To see it in your browser when the OS has portal detection you will need to be fast, though. And an active portal attack could trick the portal test. But you may call this a hijacking attempt and not a portal anymore. Disclaimer: I did not test with the most recent OS if they block traffic until the portal detection finished
    – allo
    Commented Mar 7, 2018 at 8:39
  • With a little more HTTP traffic inspection, I saw that the device does a GET request to several domains/endpoints they own after it is connected to a wireless network. It it fails to receive a response, it automatically opens the captive portal and follows the redirect instructed by the router/hotspot. This is done by the OS and the domains/endpoints used by Android and iOS differ. The question that remains is: how much the webpage can do with my device after this redirect, given the captive portal restrictions. If someone has a protocol spec/RFC about how captive portals should work helps.
    – Francisco Zanatta
    Commented Mar 7, 2018 at 14:38

You must log in to answer this question.

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