Bypass Meraki Splash pages in 10 secs to gain unrestricted Internet access

[SGenin]

The issue was reported by one of our offices in Africa. External individuals were supposedly able to bypass the Meraki splash page to access to the Internet without restrictions. The security hole was successfully reproduced in our lab and it just takes 10 seconds to hack the SSID:

- Connect to the open SSID

- Launch the app called Psiphon (available for IOS or Android)

- Start the Psiphon VPN, making sure all traffic is sent to the VPN

That's it, that Psiphon app seems to be able to create a VPN tunnel hidden in DNS packets. The tunnel is then used to route all traffic, even without being authenticated. We have hundreds of offices impacted and Meraki help desk reports:

“this has been forwarded as a feature request and currently we don't have a way to block theses apps from bypassing the splash pages. I will attach this case to the request that was forwarded to the development team. Unfortunately, I am unable to give you a timeline for when the request will be fulfilled.”

It would seem that fixing such massive security hole for an enterprise grade solution would be a top priority.

[jdsilva]

Is this strictly a Meraki problem or are other vendors affected?

[SGenin]

Our offices with Cisco WLCs were also impacted but we were able to block the app by amending settings and restrict the list of DNS servers that can be reached during the pre-auth phase.

On the Meraki platform, our settings are clearly saying to "Block all access until sign-on is complete". The walled garden listing the only sites accessible during the pre-auth process. Yet that app is still able to create the tunnel.

[jdsilva]

What about using the L3 firewall rules under Wireless > Configure > Firewall & traffic shaping to allow DNS to your servers, then deny all other UDP53?

The Psiphon website seems to say they tunnel over SSH/L2tpv3/IPSec. I can't find their docs saying they tunnel inside DNS. I'd really like to see that to see what their doing...

[dereje]

Sir can you elaborate what you did on Cisco WLC to solve  ??? i have the same issue here 

[grepaly]

Sure. Let me find my notes. Here they are:

a.) Log in to your Cisco Wireless Controller

b.) Go to Controller/Internal DHCP Server/DHCP Scope, click your scope and take a note of your DNS servers. In my case these were 8.8.8.8 and 8.8.4.4.

Usually you have only two DNS servers, but it is also possible to set three.

c.) Go to Controller > Interfaces and take a note of your virtual address.

d.) Go to Security, Access Control Lists, Access Control Lists.

e.) Create a new Access Control List by clicking New. Name it Pre-Auth-ACL.

f.) Click the name of the newly created ACL.

g.) Add the following five rules, while keeping their order.

1. Permit, Source 0.0.0.0/0.0.0.0, Destination: 0.0.0.0/0.0.0.0, Protocol: Any, Source port: Any, Dest port: Any, Direction: outbound.

2. Permit, Source 0.0.0.0/0.0.0.0, Destination: (your virtual address)/0.0.0.0, Protocol: Any, Source port: Any, Dest port: DNS, Direction: inbound.

3. Permit, Source 0.0.0.0/0.0.0.0, Destination: (your primary DNS)/0.0.0.0, Protocol: Any, Source port: Any, Dest port: DNS, Direction: inbound.

4. Permit, Source 0.0.0.0/0.0.0.0, Destination: (your secondary DNS)/0.0.0.0, Protocol: Any, Source port: Any, Dest port: DNS, Direction: inbound.

(If you have a third DNS, add it here)

5. Deny, Source 0.0.0.0/0.0.0.0, Destination: 0.0.0.0/0.0.0.0, Protocol: Any, Source port: Any, Dest port: Any, Direction: inbound.

h. Go to WLANS, Select your guest network, Select Security, Layer 3, and set the newly created ACL as Preauthentication ACL for IPv4.

[dereje]

hi thanks for your reply 

i think your senario is a bit different than me . 

i have a layer 3 switch DHCP server that i only use the guest wifi to connect guest users to internet. 

i am bit  confused about my vitual ip 1.1.1.1  which network mask to use .?and which protocol to select for to select DNS as destination port .  and is the  dns  host name a mandatory on my  vitual interface page and which name to use ?

i have local DNS servers 10.11.159.3  and .2 but when i use 255.255.255.0 it doesn\t allow me  it obliged me to use 255.255.255.255 as network mask . 

kindly for your help thanks 

[CptnCrnch]

DNS traffic has to pass in almost every captive portal setup, so this is not a Meraki issue per se. The fact that DNS can be used to tunnel data could of course be solved by DPI on Meraki but en more so on the DNS server in use. Umbrella for example would leverage its protocol knowledge to block this.

[grepaly]

The issue here is that DNS to any public IP is allowed in the pre-auth phase. It should be allowed only to those servers which are handed out to client by DHCP. Those allowed should be captured and all answers should point to the captive server instead of the original answer. Cisco WLC is also vulnerable but that can be fixed by creating a pre-auth ACL.

[SoCalRacer]

1 - Check this setting on the SSID to see if it is set to block all access until sign-in is complete

Captive portal strength

2 - You might try L3 Firewall rules on that ssid to block the below ports that Psiphon uses, as I don't think you have the need for VPN users on an Open SSID

53, 80, 443, 554, 1935, 7070, 8000, 8001, 6971-6999.

3 - Also another option may be sponsored guest login

https://documentation.meraki.com/MR/Encryption_and_Authentication/Sponsored_Guest

[SGenin]

@jdsilva, allowing DNS only for Google in the AP firewall page didn't make the trick. VPN is still going through.

@SoCalRacer , that setting (block all access till sign-on is complete) is already enabled. I am a bit reluctant to block all ports you mentioned as they include HTTP/HTTPS... Last, that sponsor page uses the same splash mechanism and is also bypassed by the app (plus we spent hours and tons of $ developing and standardizing on that guest wifi branded portal).

We have advance security on all our MXs, setting content filtering to block "Proxy Avoidance and anonymizers" doesn't worked either...

[CptnCrnch]

What happens if you set your DHCP server to assign the Umbrella DNS to the guest clients? DNS tunneling should be blocked there (at least it would if you have an account and set it up like that).

Apart from that: you could run a packet capture for that client to analyze what‘s happening in the background. Based on that one could take proper action.

[HosamHasan]

Hello @SGenin 

I faced same problem in my office actually we use work around not sure if it is suitable for you we change guest SSID authentication from Open to WPA2-Enterprise with Meraki Authentication with No splash page option so guest will not access your network to be able to send traffic until they are authenticated just needs to print few instruction for the guet how to access once you created their credential, Hope this is fitt to your setup and could be help,

Regards,

Hosam,   

[SLR]

I would recommend Umbrella. 

[grepaly]

SLR, can you please elaborate? Where do you set Umbrella and how will that stop tunneling over DNS?

We tried to set Custom DNS in the SSID settings, even that is not working in the pre-auth phase.

[jdsilva]

Based on what everyone has said here I'm not sure that just setting Umbrella in your DHCP scope would work. If DNS is allowed out to anywhere then it needs to be more. 

There's an Umbrella integration available with MR where the AP actually intercepts DNS and redirects it to Umbrella. That could actually help here... But it's an additional license on a per AP basis.

https://documentation.meraki.com/MR/Other_Topics/Integrating_Cisco_Umbrella_with_Meraki_Networks

[grepaly]

Well, I am quite sure we don't want spend some more money this way just to plug this hole. It is possible to set custom DNS per SSID (Content filtering: custom DNS), we tried that, it did not work.

[SGenin]

The app uses DNS port to create a tunnel and channel all traffic inside it. It seems that Meraki is allowing DNS traffic to any IP in the background, even if our SSID settings are configured to block all traffic than the one listed in the walled garden.

Now the good news, pending further tests, is that we were able to block the app by creating layer 3 firewall rules preventing to use any DNS other than the DHCP provided ones but at MX level. Unfortunately when creating the same set of rules with the MR layer 3 firewall, it doesn't work and the tunnel can still be established over DNS.

So 2 problems:

1. Meraki allows DNS traffic to any server during the pre-auth phase. This makes it vulnerable to these apps creating tunnels over DNS.

2. The MR layer 3 firewall is not blocking DNS traffic for the SSID as opposed to the MX firewall. This makes it difficult to scale up a patch as our LAN clients are not using the same DNS servers (it's typically upstreamed to the ISP DNS).

[colinster]

I've dealt with this using a workaround for locations without an upstream firewall.

Workaround: Apply a traffic shaping rule to limit bandwidth on port 53 and other ports that might be used by a VPN. Users attempting to bypass splash pages to access the internet over VPN will not likely use your network if they only get 100 Kbps.

Real Solution: Use an upstream MX or other firewall to block VPN attempts on port 53. Make sure not to block your DNS server such as 8.8.8.8.

Root Cause:
When client devices connect to the MR they are placed in a captive portal policy and the MR firewall rules (L3 and L7) do not get applied to the client devices until after they authenticate with the captive portal. However the traffic shaping rules are indeed applied to clients, and you can limit the throughput of VPN traffic.

Documentation error:
In my testing, MR Traffic shaping rules are indeed applied before splash page authentication.
"When splash page authentication is configured, captive portal strength settings take precedence over configured traffic shaping and firewall rules. This means traffic shaping and firewall rules will only apply after Splash page authentication has occurred successfully."

Documentation Link:
https://documentation.meraki.com/MR/MR_Splash_Page/Configuring_Splash_Page_Authentication_with_an_LD...