WLAN Enterprise Mobility Strategy

July 23rd, 2010 by Jon Janego

Continuing my series on deployment strategies for enterprise WLAN, today I’m covering the most common type of WLAN deployment – extending the enterprise to mobile users.

Basic Enterprise Mobility – Strategy

Extending the enterprise’s wired LAN to wireless is one of the more straightforward tasks from a network design perspective, but the authentication piece for the Wireless LAN needs to be strictly controlled.  Fortunately, wireless can benefit from the widespread deployment of another technology in the enterprise world – centralized authentication servers.

Many enterprise environments utilize a centralized authentication system to manage their user accounts, with Microsoft Active Directory being one of the most common.  This system can also be leveraged to provide authentication to the Wireless LAN.  Active Directory can serve as an 802.1X authenticator, allowing the wireless network to use EAP technology to authenticate users.  The two EAP methods most worthy of consideration in a WLAN environment are EAP-TLS, and PEAP.

EAP-TLS provides full mutual authentication, using a public key infrastructure to create and manage certificates for both client devices and the authenticating server.  In practice, it will allow users to seamlessly authenticate to the wireless network, because the certificate exchange occurs behind the scenes.  In an Active Directory environment, the certificates used in authentication can be deployed remotely by the Domain Controllers.  This works especially well with laptop users, but can be a challenge with mobile devices that do not have a wired connection to the network.  Certificates can be pushed to mobile devices in several ways, such as by use of a dedicated management WLAN or physical installation via memory cards or barcode scanning, but in a large environment with many mobile devices, it may be wise to look into alternatives.

Fortunately, a worthy alternative to EAP-TLS exists with PEAP authentication.  PEAP provides for similar levels of security to EAP-TLS, but does not rely on client certificates to authenticate devices to the network.  Instead, PEAP uses a more traditional username & password combination.  These credentials can be integrated with an Active Directory environment, allowing administrators granular control over what users get access to the WLAN.  PEAP also mitigates the potentially expensive maintenance cost of managing certificates on mobile devices.

EAP-TLS and PEAP, combined with WPA2-AES, provide the strongest authentication and encryption solutions available in WLAN, and as such should be used to protect any critical data traveling over the network.  While integration with Active Directory is not mandatory, because many organizations have such an environment already deployed, extending its use to cover WLAN authentication is an attractive option.  If your organization does not have a centralized authentication system in place already, the deployment of a WLAN can be a strong motivation to do so.  Several free alternatives to Active Directory also exist, such as FreeRADIUS.  Some enterprise-grade WLAN infrastructure also provides the ability to generate and manage certificates using an internal server hosted on the access point.  Given the easy integration with common authentication systems, and the availability of free alternatives, there really is no reason not to deploy a centralized authentication solution to secure your enterprise WLAN.

Pre-Shared Keys – also known as “Personal” authentication – are generally not appropriate for enterprise environments.  WPA2-AES using pre-shared keys does not have any documented vulnerabilities, but any PSK solution relies on sharing authentication credentials between multiple users and devices.  This can affect the integrity of the network, and doesn’t provide any traceability to activities of users on the network.  It should be avoided in a mission-critical environment.

WLAN In the Enterprise – Use Cases and Strategies

July 21st, 2010 by Jon Janego

Continuing from my first post in the series, today I hope to cover the common use cases and general strategies for securing an enterprise WLAN.

Depending on the size and business needs of the enterprise, a WLAN can be used in a few different ways:

Basic Mobility – the most common use of WLAN is simply to extend the existing wired LAN to wireless users.  This can have a very positive impact on productivity, allowing users more flexibility throughout the workspace.

Segmented Mobile Data - this type of WLAN is one where the network is dedicated to use of a specific type of data that is segmented from the main enterprise network.  Typical use cases here are in hospitals or retail stores, where compliance regulations provide strict guidance on data protection and segmentation.

Guest Internet Access – common in cafes and large businesses, this type of WLAN typically provides only internet access and is entirely segmented from the enterprise wired LAN.

Wired LAN Replacement - this type of network is becoming a feasible alternative to the hassle of running cable, and will likely continue to grow in popularity as time goes by

These use cases can blend together in any number of ways.  A well thought-out design at the beginning, along with the right hardware planning, can accomidate these uses and even more.

General Strategy

Like other networking strategies, the use of proper segmentation at the Layer 2 level is critical when designing a WLAN.  Your most critical data flows should have their own segment, protected by methods like VLAN segmentation, firewalling, private IP spaces, and routing tables.  Regardless of the authentication and encryption method used for the WLAN itself, properly designing its location within the enterprise wired LAN is critical.

Data encryption in 802.11 is accomplished by a combination of the authentication type with an underlying encryption method.  Use of WPA2-AES encryption should be considered mandatory in any new WLAN deployment.  This encryption technology has no documented vulnerabilities and widespread hardware and software support.  If your enterprise has devices that do not support WPA2-AES, strongly consider replacing them.  When designing a network, its security should not be determined by the weakest link.  Unless there is a business case for doing something otherwise, use the strongest encryption and authentication methods available.

My next post will get into some specifics about these different use cases!

Deploying A World-Class WLAN in Your Enterprise

July 16th, 2010 by Jon Janego

In the last decade, 802.11 Wireless LAN technology has had a dramatic impact on the technology world.  Reliable, high-bandwidth networking is now easily available to anybody who wants it, and the number of WiFi enabled devices continues to grow at a dramatic rate.  So naturally, businesses ranging from basic office environments, to complicated co-located warehousing/retail/office operations have begun leveraging the technology as well.  Unfortunately, the ease of setup that WLAN offers has led to some confusion among even seasoned IT practitioners.  In this series of  posts, I hope to provide some simple guidance to help clarify how to securely and efficiently manage an enterprise Wireless LAN.

Some History

I will not go into the history of the 802.11 standard in too much detail here, although there are a couple of important points to recognize when thinking about how to deploy a WLAN in your business.  The most important thing to know is this – many of the WLAN security technologies that were being used in deployment until three or four years ago are vulnerable to several well-known attacks.  If your business has a WLAN that has “just been working” for a while – it should probably get some attention.

To elaborate on this a bit further, the most common Wireless LAN encryption method used until late 2003, WEP, has been subject to some very public weaknesses, almost since its inception.  Its temporary replacement, WPA-TKIP, has similar (although not as dramatic) weaknesses, that have been public since at least 2008.

Adding insult to these platform-common weaknesses, some of the alternate, “more secure” based authentication methods advised by vendors have also been picked apart and had their vulnerabilities shown to the world.  I’m looking at you, LEAP.

To sum it up briefly – many networks that people thought were secure in 2003 or 2004 are definitely not secure today.  And unfortunately, WLAN sometimes is treated like a part of the physical infrastructure – if it ain’t broke, don’t fix it!

Current Tech

Fortunately, 802.11 is really starting to come into its own lately, and can be an extremely secure – in some ways more secure – piece of critical infrastructure.  The extremely solid (and so far unbroken) WPA2-AES encryption standard defined by 802.11i has had widespread vendor support since 2007.  And certificate-based authentication methods such as EAP-TLS, PEAP, and EAP-TTLS have similarly experienced a growth in support, among not just desktop OS platforms, but mobile operating systems as well.  And Wireless Intrusion Detection Systems are hitting their stride, ranging from several robust and effective professional solutions from vendors like AirTight, Cisco, and Motorola, to fantastic open-source applications like Kismet.  And robust infrastructure management software is now making the administration of Wireless LANs more simple and effective.

In short, today it is possible to deploy a WLAN that will meet all the use cases an enterprise can throw at it, and that is as secure as a typical wired LAN infrastructure.

In the next post, I’ll cover typical enterprise WLAN use cases, and the strategies for designing and securing them.

Pivot Mercilessly!

March 17th, 2010 by Jon Janego

I just returned from a great trip to SANS 2010, in Orlando, where I was taking SEC 560 – Penetration Testing.  Our instructor, Ed Skoudis (an amazing guy, by the way), repeatedly hammered into our brains the mantra “Pivot Mercilessly!”

This concept is something that a penetration tester or vulnerability assessor needs to always keep in mind – look for the easy toehold into a system, and then see where you can go from there.  “Pivot” throughout the environment using the weak link as a starting point.

I was performing an assessment recently on a Solaris system that demonstrated this concept very effectively.  One of the boxes was vulnerable to a relatively old telnet vulnerability , which we exploited with pleasure – granting us root access to the machine.  From there, we examined the trust relationships inside the network and noticed that this box had “r service” trust relationships set up with many other machines in the network.  So, we used rsh to connect to numerous other boxes, all with root level access, and from those boxes to others… quickly we had the entire system PWNED.

All of this was made possible by a single box with one weak spot.  This is likely the case with most systems out there – maybe you’ll have one or two boxes vulnerable to exploits, especially in a well-managed corporate network.  From there, it’s up to you to pivot your way through the rest of the system!

SANS 2010

February 25th, 2010 by Jon Janego

If any readers out there are interested in meeting up, all three of us will be attending the SANS 2010 training conference in Orlando, Florida the week of March 7th.

Feel free to drop us a line here and we can have a beer!

Quick and Easy Portable Media Encryption

February 25th, 2010 by Walter Goulet

As part of my personal service delivery process, I have a need to store sensitive information for client engagements (vulnerability assessment results, network diagrams etc). To avoid having a dependency on specific test systems, I prefer to use portable USB drives to store data in the event that I need to switch to another system. However, I don’t want to risk losing this drive with confidential data on it. My solution is to create an encrypted partition on the disk in such a fashion that I can quickly mount the drive on another system without downtime.

To meet these requirements, I use a combination of Dropbox (http://www.dropbox.com), Keepass (http://keepass.info/), and Truecrypt (http://www.truecrypt.org/). I use Dropbox as a portable ‘Program Files’ directory where I install portable versions of Keepass and Truecrypt. This allows me to have my ‘Program Files’ directory replicated on all systems where the Dropbox client is installed (for backup purposes, I usually have my Dropbox account synchronized to 2 different systems).

I use Truecrypt to create an encrypted partition on the USB drive (using AES for encryption and HMAC-SHA-512 as a hash algorithm). The volume key used to encrypt/decrypt the partition is then stored as a password in my Keepass database (which is also stored in my Dropbox).

As long as the Dropbox is synchronized between my test systems, switching from one system to the other is as simple as plugging the USB drive in and launching Truecrypt/Keepass from my Dropbox.

Here’s my step by step instructions to replicating this setup on a Windows XP/Vista/7 system (I assume you already have Dropbox installed on your system):

  1. Create a ‘Programs’ directory in your Dropbox folder. In this folder, create 2 subdirectories, ‘Keepass’ and ‘Truecrypt’.
  2. Copy the portable versions of these programs into their respective folders (Truecrypt does not have an explicit ‘portable’ distribution, rather download the setup file here and choose the ‘Extract’ option when running the setup, Keepass on the other hand provides a portable version that can be downloaded here).
  3. Launch Keepass and create a new password entry for the portable drive. I suggest using the Password generator function to generate the password. Note that since this password is used as an encryption key, I recommend selecting all available characters for generating the password and using the maximum key length (64 characters).
  4. Plug in the portable USB drive that will contain the encrypted partition (note: this has only been tested with USB hard drives; I have not tested this with smaller USB flash drives).
  5. Launch TrueCrypt and use the ‘Create Volume’ button to launch the new volume creation wizard. I recommend writing down the path to the volume being created to make it easier to mount later. For my personal setup, I chose to create a regular (non-hidden) partition using AES and SHA-512 for encryption and as a hash algorithm. When prompted for the volume password, use the password entry created in Keepass.
  6. The volume is now created!

To actually mount the encrypted partition, start Truecrypt and select an available drive entry. Select the encrypted volume from the Volume list then click ‘Mount’. When prompted, enter the password from the Keepass password entry.

Note that regardless of which system was used to create the encrypted partition, you can mount it on any other system as long as you have access to Truecrypt and your volume password.

Information Leakage via Delicious

July 10th, 2009 by Jon Janego

By now, the concept of “google hacking” is pretty commonly understood.  People may not be preventing it very well, but it’s moved beyond a new thing.

For the uninitiated, though, here’s a brief summary: using Google (or any other search engine – but really, is there any other?) to find vulnerable web apps, personal information, mp3s in public directories, etc etc.  It’s great fun, and a pretty fundamental initial step of profiling an attack target.

Johnny Long was one of the main evangelists of this method and has a great database of search terms.  It’s no longer actively maintained, but you can still find plenty of good information with this as a starting point!

So Google hacking is great, but it only gets you to the public internet.  What if I wanted to profile the inside of a company, from the outside?  And passively – without hitting their servers myself?  Wouldn’t it be great if I could look for public information shared by company insiders?

Delicious seems almost perfectly designed to do this kind of activity.  For the unfamiliar, delicious is an online bookmarking site, designed around the idea that sharing bookmarks is a great way to learn about new sites.  Which is an alright idea…  but don’t people also bookmark a lot of private information?  I sure do!

Making matters worse, delicious encourages users to get started by uploading their browser bookmarks.  Essentially uploading gobs of potentially personal data to a public site.  This is a classic case of information leakage.  A dedicated attacker can use this public information to get all sorts of juicy tidbits about a company.

Let’s do some examples.  This all works great in theory, but, like Google, there is a LOT of data to sort through.  Say I’m a bad guy interested in insider information about a company.  I can start looking for the basics – say… “intranet”.  Delicious makes this easier by encouraging users to tag their posts for easy categorization:

http://delicious.com/tag/intranet

So that gives me everything that users have tagged with ‘intranet’.   Lots of sites about intranet design, usability, etc.  But also sites tagged by users to manage their own bookmarks!  So I’ll start digging into an individual company… how about AMD?

http://delicious.com/search?p=amd&u=&chk=&context=recent&tag=intranet

intranet_amd

The first result doesn’t look interesting, but the second and third, well those sound like intranet sites!  This is confirmed by trying to follow them through and the DNS not resolving.  Nice!  Now let’s see what else this presumed AMD employee has bookmarked…

links_1

Wow, lots of development related links!  Interesting.  And what’s that link on page 2 about “AMD Manager Toolkit” ??  This fellow looks like he’s a technical manager at AMD!

Dig a little deeper, and it looks like we have another intranet site – mentioning the (presumably internal) code name of a project.  Interesting!  Go further into the links, and you see even further links to internal project Wiki pages.

links_2

Surfing around to a few of the non-intranet sites gives me an even better profile of this person.  They work with unit testing.  They use UML, C++, and Ruby, and read a lot about circuit design.  They live in India.  They’re learning guitar, and are interested in martial arts.

This may seem like innocent information to an outsider, but if I was doing this for espionage purposes, I just learned a lot about the internal operations of a project – and this is with 10 minutes of work on one webpage.  What else could I find if I dug through the internet further?

Web 2.0 is a lot of fun, and can be really useful.  But what’s often overlooked are the implications of sharing all this information.  Unless you make it a point to protect your privacy, that privacy probably doesn’t exist.  And for businesses, this can be a major potential risk.

Delicious certainly doesn’t help stop this – according to the FAQ, you cannot make your links private by default, but instead must manually edit them to make them private.  And also, the TOS leaves responsibility entirely in the hands of the users.  Very laissez-faire!

Should companies ban employees from using sites like delicious?  Probably not.  But I think that this demonstrates that employees need to be more educated on what they are exposing themselves and their employer to when using social networking sites.

Integrated vs. Standalone RADIUS Servers in WLAN Deployments

June 29th, 2009 by Walter Goulet

Several popular WLAN infrastructure vendors include lightweight RADIUS servers directly in their access points. These lightweight servers are typically designed for use by vendors as a backup solution in the event that connectivity to an off-board RADIUS server is lost.

I recently had the opportunity to speak with a WLAN network administrator and we briefly discussed the merits of using an integrated RADIUS server on APs vs using an external RADIUS server for authentication. After thinking about it for a few days, I realized that relying solely on the integrated RADIUS server for wireless authentication is rarely a good idea.

  • Integrated RADIUS servers on APs are typically minimal servers that are designed to serve a small number of clients. If the WLAN network grows in size, the number of users that will need to be configured could easily exceed the limits of the integrated RADIUS servers.
  • Some integrated RADIUS servers do not offer support for accounting services. This can be either a non-issue or a serious disadvantage depending on the purpose of the WLAN.
  • Integrated RADIUS servers typically use proprietary local database engines/management interfaces to administer the user database, which makes it difficult to do certain operations like import/export user databases between APs or switch to APs from a different vendor.
  • Standalone RADIUS servers offer advanced capabilities such as integrating with LDAP or Exchange servers to provide single sign-on capabilities. Integrated RADIUS servers in APs don’t have such capabilities due to the complexities and necessary protocol support required to interact with other authentication servers.
  • Integrated RADIUS servers can only support the EAP methods that are built into it, restricting the set of EAP methods that can be used in the WLAN. Standalone RADIUS servers can typically support a much larger number of EAP methods and therefore provide the WLAN administrator with a great deal of flexibility. Note that APs which are acting only as a NAS are only relaying EAP messages between clients and the RADIUS server and therefore don’t need to have support for the different EAP types built-in.

However, even with all of the advantages a standalone RADIUS server offers over an integrated RADIUS server, there are some compelling advantages of the integrated solution: the integrated server is likely only to fail when the AP itself physically fails, the authentication sequence may be slightly faster since there is no extra hop between the AP and a RADIUS server, and of course it doesn’t require any additional capital expense for your network. In short, the decision between a integrated and standalone server solution should carefully consider short term and long term costs/network growth as well as flexibility in supporting both existing and future requirements of the network.

No WPA2 With Windows Wireless Zero Config??

June 8th, 2009 by Jon Janego

Wow – I would never have thought that in this day and age, a major vendor like Microsoft wouldn’t fully implement a spec.  However, in the case of WPA2 it looks like that they did exactly that – at least until 2005.

BUT making things more interesting- this was an “optional” update with XP SP2, until it was finally rolled into XP SP3.  There is a hotfix for XP SP2 machines in order to support WPA2 – KB 893357.

WPA2/AES didnt’ really become widely implemented until 2006, but it was in the 802.11i spec that introduced WPA in 2004.  For a major vendor like MS to not implement it is pretty crazy.  But then again I, as a wireless security professional, didn’t setup a WPA2/AES network in my home until last month.  So maybe they were onto something.

Anyways, if you’re using XPSP2 and a WPA2 network – you need the hotfix, or XPSP3+.  Good luck out there!  I really recommend moving to WPA2/AES, especially considering the improvements in the Nvidia CUDA drivers that are allowing TKIP to be broken in an increasingly short amount of time.

Where Have We Been?

April 15th, 2009 by Jon Janego

Wow, it’s been over a month without much action here at Securism.  But it’s not for lack of stuff to talk about – precisely the opposite, we’ve all been so incredibly busy that this little blog has fallen by the wayside.  But I promise that we’ll get right back up at it!  In the meantime, here’s what we’ve all been doing.

Ben and I both attended the SANS 2009 conference in early March, in Orlando.  He was in the advanced penetration testing class, and I was taking the wireless security class.  Verdict on both of those: AWESOME.

Walter also went to a SANS conference in Phoenix to attend a class on secure network design.

I also just finished the EC-Council Certified Ethical Hacker program, which is a good overview certification class.  Don’t underestimate that exam – it’s a tricky one!

Beyond the gobs of training, we’ve also been working on some great stuff at work, getting well up to our necks in the world of PCI.

So, dear readers, don’t fret.  We’re still here, and will be back shortly!