Archive for July, 2009

AES is becoming very close to broken

July 30th, 2009

In earlier posts I discussed what’s wrong with WPA and why its always a bad idea to base a standard around a single method of encryption, even AES. Bruce Schneier posted to his blog today regarding a new attack against AES. In short, the paper he references identifies how to dramatically reduce the number of guesses required to retrieve a key. While its not practical today for a basement hack to perform the attack, its still nasty stuff.

The attack in question is what is referred to as a related key attack. This requires the attacker to have some level of knowledge of the plain text secured by multiple related keys. In other words, we need to already know a bit of what is being protected and where to look for it.

This is a serious problem when you are talking about VPNs or wireless, because we are using it to secure IP traffic. IP uses some pretty consistent values:

  • Byte 0 contains the IP version (usually 4) and the size of the IP header (usually 20 bytes)
  • Byte 1 contains the type of service field (usually not used so set to 0)
  • Bytes 2 & 3 contain the total length field (a consistent value for traffic like ARP packets if you know the OS)
  • Byte 8 contains the TTL (a consistent value on a per OS basis)
  • Bytes 12-15 contain the source IP address (a consistent value for each specific system)

And that’s just the IP header…

So when we protect traffic on the wire, related key attacks can be particularly evil because there are many repetitive values to work with.

So what should you do? I’ll fall back on the same advice I gave in those earlier posts I referenced above. Make sure you have more options than just a single encryption algorithm, just in case things get a whole lot worse.

Proactive Cyber Defence Seminar

July 29th, 2009

I did the keynote today at the Proactive Cyber Defence Seminar held at the International Spy Museum. Very cool venue and worth checking out. It made for a nice mix of old school and cutting edge security. Worth the trip if you are in DC. Make sure you check out the spy poo. ;)

Thanks to all who attended as I had an absolute blast. I promised to post a PDF version of the slides, so here ya go…

proactive-cyber-defense-seminar

Leveraging the Windows “runas” command

July 28th, 2009

Sometimes we can be our own worst enemy. I’ve written a bit about Malware and how infection rates are through the roof. If you look at the one thing you can do to make a Malware author’s life easier, its logon to your Windows system as an Administrator equivalent.

This problem was solved long ago on UNIX and Linux systems via tools like su and sudo. You used to have an excuse for running Admin equivalent on Windows. Microsoft made it extremely difficult to perform IT functions unless you were a high level account. This problem was resolved years ago with the runas command however, so its time we took control of this potential security hole.

Why is it important to use runas

When you are logged on as an Administrator equivalent, you have full god/goddess rights to the local system, and possibly the whole network. This means that your credentials are capable of doing anything. If a Malware author drops something nasty on your system, they have the same level of access that you do. Administrators used to mitigate this threat by being careful about what they clicked on. Today however Malware can come at you through trusted sites. By running with a lower level of permissions, you can help reduce the magnitude of a Malware attack.

What does runas do for me?

When you execute the runas command, only applications running beneath it have high level permissions. So for example let’s say we leverage runas to launch the User Manager. The User Manager application will have Administrator level privileges but the rest of our system environment will not. If User Manager is open when an attacker delivers nasty Malware via your browser, the Malware will be constrained to the level of access granted by your regular user account because the browser is still running with lower level permissions.

Using runas via the GUI

One of the simplest ways to leverage the runas command is via shortcuts. In my last post I gave a list of common Windows administrator tools. Simply create a shortcut on your desktop for each tool you need to use. When you need to run the tool, right click the icon and select “Run as…” from the pop up menu (it should be the second option). This will produce the window shown in Figure #1. Simply supply the credential for your high level account and the tool will launch as it normally does.

runas

Note that in Figure #1 I’m logging on as Administrator. In an ideal world, each admin will have a dedicated administrator account (like cbrenton-admin or similar). This will make it much easier to create a proper audit trail of changes.

Using runas from the command line

Along with the GUI interface, you can leverage runas from the command line as well. The simplest solution is to place a command prompt shortcut on your desktop and launch it as specified above. If you already have a command prompt session going, you can leverage the runas command directly. The syntax is:

runas /user:<high level account name> <command we wish to run>

If we wish to generate a new command prompt with high permissions, we can do that too. The syntax is:

runas /user:<high level account name> c:\windows\system32\cmd.exe

This will produce output similar to Figure #2. Note that we have simply leveraged runas to spawn a new command prompt session. Now anything run within this new command prompt will be executed with higher permissions.

runas-command-line

Exec Summary

Today there is no excuse for logging into Windows as an administrator equivalent. By leveraging the runas command along with some shortcuts, IT folks can still get the job done while refraining from being their own worst enemy.

Quick Access To Windows Admin Tools

July 28th, 2009

In my last post I talked about how using the Windows GUI can at times be cumbersome. If you administer a Windows network, you are frequently leveraging the Windows admin tools. Here are some tips to make that task a bit easier.

List of Tools

Here’s a list of the most commonly used Window’s admin tools as well as the command needed to launch them:

  • Add/Remove Programs = appwiz.cpl
  • Certificate Manager = certmgr.msc
  • Computer Manager = compmgmt.msc
  • Control Panel = control.exe
  • Copy screen to clipboard = <ctrl><Print Scrn>
  • Copy active window to clipboard = <ctrl><alt><Print Scrn>
  • Device Manager = devmgmt.msc
  • Event Viewer = eventvwr.msc
  • File Explorer = explorer.exe
  • File Signature Verification = sigverif.exe
  • Group Policy Editor = gpedit.msc
  • MS Management Console = mmc
  • Network Properties = control netconnections
  • Performance Monitor = perfmon.msc
  • Registry Editor = regedt32.exe
  • Security Center = wscui.cpl
  • User Manager = lusrmgr.msc
  • Security Policy Editor = secpol.msc
  • Services Screen = services.msc
  • Solitaire = sol.exe
  • System Config Utility = msconfig.exe
  • Task Manager = taskmgr.exe
  • Task Manager = <ctrl><shift><esc>
  • Task Scheduler = control schedtasks
  • User Manager = lusrmgr.msc

Quick Launch Options

Here are some tips for making each of the above easily accessible:

  1. Click Start –> Run then type in the command listed above
  2. Press <Windows key><r> then type in the command listed above
  3. Create a desktop shortcut
  4. Create a taskbar shortcut
  5. Create a single program group so everything is in one place

Helpful Shortcuts For The Windows IP Geek

July 25th, 2009

Many of us do testing with our Windows systems which inevitably require us to change firewall settings and IP info. While Windows has given us a pretty GUI for performing these tasks, it can be cumbersome to navigate the menu options. In this post I’ll show you how creating a few icons can help you take better control of this problem.

Dealing with the Windows firewall

One of the common tasks I need to perform is disabling and enabling the Windows firewall. I sometimes need to shut it off for testing, but of course want it turned back on again if I’m connected to a potentially hostile network. This introduces the additional problem that I can never remember if I had it turned on or off the last time the system was booted.

Disabling the Windows firewall

Open up a text editor and create a file named disable-firewall.bat. Type the following line into the file:

netsh firewall set opmode disable

Now save the file and create a desktop shortcut that points to it. Whenever you double click the icon, the Windows firewall will shut down.

Enabling the Windows firewall

Open up a text editor and create a file named enable-firewall.bat. The file will contain only a single line:

netsh firewall set opmode enable

Now save the file and create a desktop shortcut that points to it. Whenever you double click the icon, the Windows firewall will turn on.

Checking the Windows firewall status

Open up a text editor and create a file named fw-status.bat. Type the following three lines into the file:

netsh firewall show state
pause
exit

Now save the file and create two shortcuts pointing to it. One on the desktop and one in your startup group. When your system first boots up, a command prompt will open showing the current state of the Windows firewall. It will then pause on the screen until you press a key. Anytime you need to check the current status, simply double click the shortcut you placed on the desktop.

Dealing with IP settings

If every network used DHCP, dealing with IP would be much easier. When we work in a lab however, we typically have to manually configure IP for communications. Obviously we can use the GUI for this, but its easy to streamline the process with a couple of shortcuts.

Manually setting a wired IP address

For the purpose of this exercise I’ll assume the IP address you want to assign is 192.168.1.10. Change this IP address as needed.
Open up a text editor and create a file named 192-168-1-10.bat. The file will contain only a single line:

netsh interface ip set address local static 192.168.1.10 255.255.255.0

Now save the file and create a desktop shortcut that points to it. When ever you double click the icon, the IP address on your wired interface will be changed.

Adding a default gateway

If there is a default gateway you need to specify, we can do that as well. Assuming the gateway is at 192.168.1.1, we would change the above command to read:

netsh interface ip set address local static 192.168.1.10 255.255.255.0 192.168.1.1 1

Specifying a DNS server

If you need to specify DNS servers, we’ll need to add a few extra lines to the batch file. Let’s build on the last example and assume we have two DNS servers, one at 10.1.1.1 and another at 172.30.1.10. In this case our batch file would contain the following:

netsh interface ip set address local static 192.168.1.10 255.255.255.0 192.168.1.1 1
netsh interface ip set dns local static 10.1.1.1
netsh interface ip set dns local static 172.30.1.10

Reverting back to DHCP

Open up a text editor and create a file named reset-dhcp.bat. The file will contain only a single line:

netsh interface ip set address local dhcp

Now save the file and create a desktop shortcut that points to it. When ever you double click the icon, Windows will look to a local DHCP server for the IP info it will use.

What if I use multiple IP addresses?

The above example works great provided you consistently use the same IP address. What if you need a bit more flexibility to change it on the fly? Luckily we can handle that problem through the use of variables.

Open up a text editor and create a file named varip.bat. The file will contain only a single line:

netsh interface ip set address local static %1 255.255.255.0

Now save the file to a directory in your path statement. The Windows directory itself is usually a good last ditch option. If you don’t know which directories are in your path, simply open a command prompt and type the command “path”. This will produce a semi-colon ( ; ) separated list of all directories in your path. This tip will not work if the file is not saved to a directory in your path statement.
Whenever you need to set your IP address simply click Start–> Run and type in:

varip 192.168.50.25

or what ever IP address you wish to use. If you commonly need to change the subnet mask, change the command to read:

netsh interface ip set address local static %1 %2
Now when you click Start–> Run you would type:

varip 192.168.50.25 255.255.255.128

or whatever IP address/subnet mask combination you wish to use.

Exec Summary

While the Windows GUI is relatively easy to navigate, it can be cumbersome for common tasks like changing IP address or firewall settings. This can easily be rectified by creating a few batch files and placing shortcuts to them on the desktop.

How To Earn Money With Your Own Personal Botnet

July 25th, 2009

In an earlier post I discussed the problems with Malware and the financial motivations for creating evil software. I mentioned that skilled Malware writers are no longer focused on pure mass propagation, but rather it has become a way to earn a living.

Kasperky Labs has published an excellent paper entitled The Economics of Botnets that puts some real world dollar values behind the motivations. The paper talks about just how easy it is to setup and manage a Botnet, as well as the insane amounts of money that can be earned. Well worth a read.

Making The Web a Safer Place With NoScript

July 24th, 2009

Yesterday I was reviewing the stats for this site and was pleasantly surprised to see that 70%+ of all visitors are using the Firefox browser. In a previous post I discussed What Makes A System Vulnerable and defined it as being when we permit remote users to interact with code running on the local system. Firefox has an excellent security extension called NoScript which can dramatically reduce this vector of exposure.

The premise of NoScript is so rudimentary, you have to wonder why every browser vendor does not make this functionality a built in option. NoScript gives you control of which sites can execute code on your system. Its that simple. So merely browsing to a Web site no longer immediately implies that you trust them enough to execute programs (Java, Flash, etc.) on your desktop. NoScript is flexible, relatively unobtrusive, and a “must have” extension for staying safe on the Internet.

Getting NoScript

The easiest way to retrieve and install NoScript is right through the Firefox Add-ons window. Simply click “Tools” from the main menu bar and select “Add-ons” from the drop down menu. When the Add-ons window appears, click the “Get Add-ons” button at the top left side of the Window. If you do not see NoScript mentioned on the “Recommended” list, click the “Browse All Add-ons” link on the top right of the screen.

Clicking the link will spawn a new Firefox tab directing you to the Firefox add-ons site. In the search bar type in “noscript”. When NoScript appears in the results, click the “Add to Firefox” button. When the installation is complete simply restart your Firefox browser. You are now ready for safer Web browsing. When new updates become available you will be automatically notified.

Using NoScript

When you first start using NoScript it may appear that many of your favorite Web sites are broken. Flash video will no longer auto-load, drop down menus may fail, etc. Take a look at the bottom of your Firefox window. You will see output similar to Figure #1. NoScript is telling us that all script execution is currently disabled for this site. The site tried to run 12 scripts and there were 0 embedded objects (like frames displaying text or video from other sites). To change this behavior simply click the “Options…” button.

noscript-status

Clicking “Options…” will produce a menu similar to Figure #2. The information pertaining to this specific site is at the bottom of the menu. NoScript is telling us that the site tried to execute scripts from four different domains; mmismm.com, revsci.net, com.com and cnet.com. We are given two options for each domain, let the scripts from that domain run just for this session (Temporarily), or permit the domain to execute scripts for this and future sessions as well (Allow).

noscript-options

Mmismm.com and revsci.net are advertising companies. They also have a poor trust rating through the Web Of Trust (WOT is another cool Firefox plug-in by the way) so we may want to leave scripts from these domains disabled. The remaining two domains are part of CNET. So if we like to view news and articles from this company we may wish to grant access. Note this should not be automatic however. For example this menu was generated while I was visiting the CNET News site. I was still able to view all the content I was interested in just fine, so really there is no reason to permit any of these domains to execute scripts and expose myself to potential attack.

If you do permit script execution from certain domains, Firefox will automatically reload the page and execute the permitted scripts. You’ll now notice that the NoScript status bar will now look more like Figure #3. NoScript is telling us that the site we visited tried to execute scripts from six different domains, but only four of them were permitted. The domains allowed to run scripts are then listed out for us to review. There were 69 scripts total and zero embedded object.

noscript-status2

If we later decide a site is not so trustworthy, its easy to revoke permissions. If we are at the site in question, simply click “Options…” and select the “Forbid” menu item for that domain. If we are not currently browsing the site, go to the top of the menu and select “Options…” (second appearance of this title). Click the “Whitelist” tab, scroll through the list to find the site in question, and click the Remove Selected Sites” button. Problem solved.

Once you have used NoScript for a while and wish to get into some of the more advanced options, the NoScript site has some excellent information. Start with the FAQ and then move on to the user forums. If you find NoScript saves you even once from an attack, it may be worth clicking the “Donate” button at the top of the main page. ;)

Why Firewall Reject Rules Are Better Than Firewall Drop Rules

July 23rd, 2009

Most firewalls come pre-configured to quietly drop traffic rather than reject it. But what’s the difference between the two and is it truly better to drop instead of reject? If you have never given this question much thought, the answer might surprise you.

Firewall traffic control options

Firewalls typically give you three options when interacting with traffic, these are:

  • Accept – Let the traffic pass through
  • Drop – Remove the packet from the wire and generate no error packet
  • Reject – Remove the packet from the wire and return an ICMP “Communication administratively prohibited” (ICMP type 3, code 13) error packet

Some firewalls are customizable when it comes to the reject packet that gets returned. For example Netfilter provides options from making the port look like its closed to tar pitting the connection. For the purpose of this post I’ll stick with just the administratively prohibited message since that’s the most widely deployed.

What happens when you port scan a system

An attacker can identify open versus closed ports on a system because each responds differently to a stimulus packet. When I send a TCP SYN packet to a system, one of the following is going to occur:

  • If the port is open a TCP SYN/ACK will be returned
  • If the port is closed a TCP RST/ACK will be returned

So if a SYN/ACK is returned, I know the port is open. If a RST (reset)/ACK is returned, I know the port is closed.

Now expand this out to the Internet level and some other possibilities come into play:

  • If the host is off-line an ICMP host unreachable will be returned by the upstream router
  • If the network the host is connected to is off-line, an ICMP network unreachable will be returned by the upstream router
  • If a router or a firewall with a reject rule is blocking the connection, an administratively prohibited error is returned
  • If the port is protected by a firewall with a drop rule, nothing is returned

Note that its the final two possibilities that involve traffic control. If we drop traffic, nothing is returned to the scanner. If we reject, then an ICMP error is returned.

The myth of stealthing the firewall

Vendors favor drop rules for two reasons, both of which are incorrect. The first is that dropping traffic helps to “stealth” the firewall. The concept is that since the firewall is returning no data, an attacker will be unable to determine you have a firewall. Look at the above response options again. The only time nothing is returned consistently is when a firewall with a drop rule is in the way. So by dropping traffic you are not stealthing the firewall, you are advertising it. This is why tools like nmap will actually report the probe as “filtered” when nothing comes back.

When I’ve confronted vendors with this fact, the response is either “Huh?” or “They still don’t know your firewall’s IP address so its still stealthed”. The second statement is only partially true in that an attacker would have to perform the additional step of running a tool such as tcptraceroute to determine the IP address of the firewall.

So the concept of being able to stealth a device that interacts with traffic flow is a complete myth. The closest match is probably Netfilter’s ability to reject via host unreachable messages. While this does not hide the IP address of the firewall, it does make the firewall look more like a router and help to mask the network segmentation behind it.

The myth of using less bandwidth

The second reason vendors favor drop rules is they think it generates less traffic on the wire. This makes sense logically unless you understand how TCP/IP communicates. In other words, on the surface this statement seems rational. Keep the ICMP errors off the wire and you are using less bandwidth. The reality however is that TCP tries very hard to be reliable. This means that when the first probe packet is quietly dropped, the source is going to send two, possibly four more packets to try again. If you add up the bits on the wire, you actually end up using more bandwidth when you force the source into retransmission mode.

What do the RFC’s say?

So which method is RFC legal, dropping or rejecting? If we reference RFC 1122 it says:

3.3.8  Error Reporting

         Wherever practical, hosts MUST return ICMP error datagrams on
         detection of an error, except in those cases where returning an
         ICMP error message is specifically prohibited.

“Specifically prohibited” refers to the fact that you should never respond to an error packet with another error packet. Its just too easy to create infinite loops. So if we are prohibiting traffic flow we are suppose to be returning an ICMP error message.

Making your IP range less attractive to spoofing

One of the biggest problems with using drop rules is that you make your IP range more attractive for spoofing. Consider the typical SYN flood attack where an attacker attempts to fill up a server’s TCP connection queue so that legitimate connection requests can not be serviced. The attacker will flood the target with TCP connection requests, typically from multiple zombie hosts. Since the attacker has no intention of completing the TCP three packet handshake, the source IP address is spoofed to help protect the true identity of the zombie.

If an attacker spoofs one of your IP addresses as part of their SYN flood, you will see the server under attack send unsolicited SYN/ACK packets to the spoofed IP address. This is not the server attacking your network, its simply the server responding to a connection request and it has no idea the source IP address was spoofed.

OK, let’s return to the above listed scanning options and combine that with your network setup to see what impact you will have on the attacker’s ability to perform a successful SYN flood attack. If your IP address they are spoofing is:

  • Exposed host = RST/ACK returned, connection queue cleared on server in approximately 50 ms.
  • Host off-line = Upstream router returns host unreachable in approximately 3 seconds
  • Network off-line = Upstream router returns network unreachable in approximately 50 ms
  • Reject rule = Firewall/router returns Administratively prohibited message in approximately 50 ms
  • Drop rule = Server under attack attempts to respond for 30 seconds or more

The anatomy of a SYN flood

There are two metrics that come into play in making a SYN flood successful. The first is how many SYN packets can the attacker spoof per second. This metric will be determined by the size of the attacker’s zombie army. The second metric however, is something you have control of. That is “How long will each spoofed connection request tie up memory in the server’s connection queue?”.

As you can see in the above responses, when an attacker spoofs an IP address protected by a firewall drop rule, the bogus connection request ties up the server’s connection queue for the greatest amount of time. So let’s say the attacker wants to tie up one connection slot worth of memory for 60 seconds. That would take two spoofed packets protected by a firewall drop rule, or 1,200 spoofed packets if each spoofed IP is protected by a firewall reject rule. So spoofing dropped source IPs means the attacker requires fewer SYN packets per second in order to perform a successful attack. By deploying a drop rule you are inadvertently helping the attacker and making your address space more attractive to IP address spoofing.

Exec Summary

Using drop rules to prevent traffic flow is widely deployed. This author feels this has more to do with “everyone following the herd” than with a drop implementation truly being a better security posture than using reject rules. Reject rules are more RFC compliant, generate less traffic on the wire, and make your address space less attractive for IP address spoofing.

Cheers!

C

Eliminating The Need For WPA In The Enterprise – Part 2

July 22nd, 2009

In my last post I discussed the problems with deploying WPA in an enterprise environment. Let’s back up a bit and list why we secure wireless networks:

  • Permitting uncontrolled access can lead to compromise
  • Authentication is required to verify the person connecting in
  • Data can be sniffed so encryption is needed for data privacy

Pretty straight forward reasoning, but now stop and consider why we secure remote users when they connect in from the Internet:

  • Permitting uncontrolled access can lead to compromise
  • Authentication is required to verify the person connecting in
  • Data can be sniffed so encryption is needed for data privacy

Note the reasons are the same. I’m big on root cause analysis, and the reason so many of us jump though hoops with WPA is that we’re trying to fit a square peg into a round hole. In other words, rather than recognize that a wireless signal is a separate uncontrolled entity, we try really hard to slap on a quick fix so it can be trusted at the same level as the wired segments secured behind our office walls. Not a surprise really, given that the first protocol we were given to secure wireless was called the Wired Equivalent Privacy (WEP) protocol. Needless to say the name directly implies that wireless can be made to be as secure as a wired switch port. History has shown, and continues to show otherwise however.

Consider the network drawing in Figure #1. Note that we have reconfigured the network to better address the root cause problems with wireless. Wireless is no longer considered as trustworthy as a wired switch port. Its treated in a similar fashion to its closest matching security zone, the Internet. We simply hang our access points off of another firewall port and apply a similar security posture.

wireless-vpn

So when someone connects to the access point, what happens? The connection is made in the clear with no security enabled. Simply connect to the proper SSID and go. The local DHCP server then hands the system an IP address. At this point our setup acts like any other non-secured network.

Look what a wireless system gets access to however. Through the firewall, the only permitted point of access is the VPN gateway. This is the same as when the user connects in from the Internet. So rather than having to trust a single security implementation (WPA) with its single choice for data privacy (AES), you can deploy what ever you feel is appropriate. The robustness and flexibility of SSH, SSL and IPSec all become possibilities for securing your datastream. While each solution supports AES for data privacy, they open up a plethora of other, some feel better, options like Blowfish and Twofish.

But wait, couldn’t an attacker connect to my access point and go after the laptops that are connecting in? Absolutely. Again, this zone has the same security level as the Internet so the same rules apply. Think about your typical wireless user however. They tend to be road warriors, who also connect in from the Internet. This means their system should already have the required VPN software and a personal firewall system. So if the laptop is configured to connect in from the Internet, its ready to go in this wireless configuration as well.

One of the things I really like about this configuration is that it not only reduces back end administration (no more WPA management), but help desk support time as well. Users just want their laptop to work and are more effective when they can follow a consistent process. When we tell them “Perform steps A, then B, then C to connect in from the Internet, but steps D, then E then F if you are at the office”, some will inevitability become confused. With the setup above they always follow the same connection process, regardless of physical location.

Since no security solution is ever perfect, there has to be some down sides, right? First, we are putting a slightly higher load on the firewall. Internal communications between a wireless system and a server would normally not involve the firewall, but now it does. This problem could easily be resolved with a second firewall however.

The second issue is security related but is dependent on how we deploy the above configuration. In an ideal world all access points would be connected to a single isolated switch. Reality in a large environment however might necessitate the use of VLANs because the access points are geographically dispersed from each other. The use of VLANs opens up the possibility of VLAN hopping. While this author does not think an attacker could mess with DTP through an access point in order to gain access to the trunk, its certainly possible from a directly connected system so eventually someone smarter than I may figure it out. In short, remember that this security zone has the same trust level as the Internet and handle it accordingly. Shut off DTP or any other auto VLAN negotiation capability the vendor has turned on by default.

Finally, rogue access points are still an issue. This solution does nothing to stop an end user from bringing in an access point from home and plugging it in. You still need to keep a watchful eye for this activity. About the only thing this solution does for you is now you know any access point plugged into the wired network is rogue and needs to be addressed.

Hope this is helpful!

C

Eliminating The Need For WPA In The Enterprise – Part 1

July 21st, 2009

Many of us who leverage wireless in an enterprise environment dutifully deploy wireless encryption (WEP or WPA) as well. This is not trivial, as it requires a continual commitment of time and resources in order to maintain the system’s integrity. But is this expenditure really necessary, or is there a more effective solution available that most of us simply overlook?

The need to properly secure wireless

Most of us recognize why wireless connections need to be properly secured. Running a wide open access point is just begging to have your network broken into. Wireless is trivial to sniff and there are a tons of tools available to help you crack it. A good wireless hack knows that proximity affords little protection. I’ve personally been able to get 802.11 working over 5 miles. With the right antennas, others have pushed this as far as 35 miles.

What’s wrong with WEP and WPA?

Most of us understand why WEP is completely broken. If not, Google is your friend. If you don’t understand why WEP is bad its worth the time to do the research. Its a great example of how to do everything wrong.

So the accepted protocol today for wireless security is WPA. At the time of this writing, WPA is faltering but not completely broken. Researches have figured out how to perform key recovery in small packets. Vendors have figured out how to speed up the process of brute forcing keys. The recommended WPA key size today is 48 characters or larger. This is far too big for end users to remember so inevitably the value is written down, in clear text, probably in multiple locations.

There are resource issues here as well. Wireless security is an entire infrastructure system that needs to be managed. Keys and credentials need to be maintained. Even if we take the easy way out and deploy EAP-TTLS we still have a healthy number of components to keep in sync. When things go wrong, troubleshooting can also be a pain as it can sometimes be difficult to determine if the problem is the wireless signal, credentials or even DHCP.

Limiting your data privacy options

When you use WPA, your only data privacy option is AES. AES is a NIST standard that is widely deployed. While it has survived the last eight years without a major vulnerability, timing attacks have been discovered along with a few dents in AES’s armor. Its never a good idea to put all of your eggs in one basket. This is why we backup mission critical data or transmit it over redundant routes. If the worst occurs and AES is found to be broken, you are completely hosed until a new protocol is chosen and incorporated by vendors. The solution will most certainly include replacing all of your access points, as it did when we moved with RC4 under WEP to AES under WPA.

Exec Summary

So we absolutely need to secure wireless connections but the current options available are either slightly better than useless (WEP) or very cumbersome (WPA). Clearly we need additional possibilities that will reduce administration as well as increase the number of choices for data privacy. In my next post I will propose one possibility that is immediately viable for deployment in today’s enterprise environment.