Splash page vulnerability when hosting a custom one

[Mathis]

Hello,

I'm opening this post to let you know about a flaw that has existed for some time in Meraki's custom splash page system.

First, for context, our need is to use a splash page hosted on our servers that queries a login system of our own and then authorizes or not the user with Meraki.

My system was working perfectly until I realized something quite crazy when I looked a little deeper into how Meraki works with authorization.

When a client connects, it is redirected to the splash page, and Meraki provides a "base_grant_url" which is simply used to validate the connection.

So when my system has validated that the user is authorized to connect, it redirects the user to the "base_grant_url" provided by meraki, and here he is in my network.

Except that this "base grant url" has no token, no system to protect the validation request, it's simply the following link: "https://nXX.network-auth.com/splash/grant" where the "XX" is simply your meraki sub-domain.

So, to sum up, a random user tries to connect to your network protected by custom splash page, enters the url "https://nXX.network-auth.com/splash/grant" in his browser and is connected to my network and authorized!

If we take a step back on the subject, meraki doesn't hide from it, on the official documentation for the custom splash page they even provide the url, except that because of this, it's impossible to make a custom splash page with an authentication system.

When I see all the companies with meraki that use splash page providers and are able to be bypassed with a simple link, and I see meraki's response is "We're aware of this and have no plans to change it", I feel like I'm dreaming.

I noticed that there had already been posts on the subject exactly 6 years ago, and that nothing has moved since...

I hope this post can potentially give me some ideas to get around this, or even get meraki to add a new type of authorization for its splash pages, who knows?

Thanks !

[alemabrahao]

Just to remind you that regardless of vendor, the AP looks for HTTP GET requests on TCP port 80 in order to redirect users to the Splash page. If Block all access until sign-on is complete is enabled for the Captive Portal Strength, and the user attempts to access a web page that uses HTTPS, the AP will be unable to redirect the browser to the Splash page because the web traffic is encrypted. Additionally, if the user attempts the access a web page that uses a different port other than TCP port 80 the connection will also be blocked. In either case, the user's browser will timeout. If this is occurring, verify users are accessing a web page using HTTP over TCP port 80.

I particularly don't like using Splash page because it is an open authentication without encryption (remembering that it is vendor independent).

So what can I say that this is not unique to Meraki, my suggestion is, if you want to raise the level of security use another wireless authentication method.

[PhilipDAth]

You should report this under the bug bounty program.

https://bugcrowd.com/ciscomeraki