Interested in a RDU hackerspace? Please take the Triangle Hackerspace survey. https://www.surveymonkey.com/s/trihack

You can learn more about the group at http://Trianglehackers.com .

# # #

If you’re not sure where to start, there are some key questions you should think about and have ready for discussion with your potential firewall vendor or integrator. Keep in mind, each environment is unique, and a quality integrator might have additional questions for you.”

Find this article on Dark Reading’s SMB Security Tech Center at:
http://www.darkreading.com/blog/archives/2010/08/choosing_the_ri.html

Here is more updated information on the WPA2 Hole 196 vulnerability now that AirTight has given the demo at BlackHat/Defcon.

John Cox at Network World put together a pretty nice final piece on the AirTight WPA2 Hole 196 vulnerability claims.

Included are quotes and details from me, AirTight, Matthew Gast (Aerohive), Robbie Gill (Aruba), John Pescatore (Gartner), Adam Conway (Aerohive) and Alan Amrod (Xirrus). Although I didn’t intend for him to quote my Southern-isms, they do relay the truth of the matter. Matthew has some great information you can find in other NWW articles on the attack.

Network World article
AirTight defends Wi-Fi WPA2 ‘vulnerability’ claim: A “publicity stunt?” Major threat? Or easily contained?
http://www.networkworld.com/news/2010/073010-airtight-wpa2-vulnerability.html

My wrap up:
- It’s not a big deal
- Attack is very limited and must be conducted by an authenticated user to another user
- Both victim and attacker must be on the same SSID and on the same access point
- Smart WIPS will protect against the attack
- Client isolation (used in most enterprise environments) prevents the attack all together

My original post
Additional comments are at the very bottom.
http://securityuncorked.com/2010/07/smoke-and-mirrors-the-upcoming-defcon-wpa2-crack/

# # #

Find this article on Dark Reading’s SMB Security Tech Center at:
http://www.darkreading.com/blog/archives/2010/07/four_musthave_s.html

As you may have heard at Black Hat and Defcon next week, AirTight Networks (a wireless security vendor) is doing a demo of a new WPA2 vulnerability that affects even 802.1X-authenticated networks. Of course, that piqued my curiosity as well so I did some digging and speculating. As a side note, I want to say I like AirTight and their products, so my response here addresses the vulnerability and is no reflection on the company itself.

Several press releases note the attack uses information of a vulnerability found on page 196 of the IEEE 802.11 wireless standard. Before I got there, I did a little guessing on various attacks that may be possible on 1X-authenticated networks.

Possible attacks:
- Compromise authentication server (AS) which participates in key distribution
- Compromise pairwise (individual station) keys
- Reuse of GTK (only for broadcast/multicast)
- Spoof AP or authentication server (AS) for MITM attack
- Implement an 802.1X EAP method which is insecure (ie EAP-MD5) and compromises the keys
- Attack on TKIP (versus CCMP)

Some of these possibilities seem unlikely, at best. For example, compromising the pairwise keys is virtually impossible. I would assume it’s not a TKIP attack since that’s old news. Looking at the list, if we jump to page 196 of the standard doc, we see the heading 8.5 Keys and Key Distribution . By the way, you can download the entire doc at the link below.

The documented vulnerability

Page 196, Section 8.5 Keys and Key Distribution
Under that section is this paragraph:

NOTE—Pairwise key support with TKIP or CCMP allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property.

Background: Individual keys versus group keys

Before I explain the paragraph above let me give you a brief overview. With 802.1X there are private keys that are distributed and rotated per-user, per-session. Those are called pairwise keys and they’re used for unicast traffic, so traffic directly destined for that wireless client. There are also group keys (GTK) that are used for broadcast and multicast traffic. Those keys are shared for a group of wireless clients per SSID and used just like wired multicast to reach everyone at once.

The vulnerability in English

Now let me decode that paragraph for you. What it says is that pairwise (individual) keys used in 802.1X with both TKIP and AES encryption have a check in place to determine if the source (TA) is being spoofed or not. So, if an attacker pretends to be an AP and sends traffic, the wireless client will know. However, broadcast and mulitcast traffic sent using group keys (GTK) do not have a spoofing check. That means an attacker could use the group key and send a broadcast to other clients, posing as an AP and those clients won’t know the difference.

Assumptions of the attack

• Attacker must be an 802.1X-authenticated user on your wireless network
• Attacker must be on the same ESSID as the target(s)
• Attack vector is limited to damage directly resulting from broadcasts/mulitcasts
• A MITM attack (spoofing the AP) could only happen if:
  o the attacker can force a dissociation for users with the GTK
  o the group keys (GTKs) don’t refresh/change at the new association
  o the target stations are set to NOT check for server certificate for AS
  o or the attacker can falsify trust (ie push certificate) using broadcast

If the last line is true, then we may have some secondary issues to deal with and the implications could be more serious. We need to do some checking to see what all can be pushed via broadcasts with the group keys in order to understand the breadth of the attack possibilities.

The implications of the vulnerability

In my opinion, this vulnerability is of limited importance (for now). Without reading the entire 1,000+ pages of the standard again, my understanding is the threat is limited by the assumptions above. My personal feeling is this: If our attacker is an authenticated user on your enterprise network, meaning they’re part of your directory services and an employee most likely, then they have access to far more resources. Attacking data at the source, or even on the wired side where the packets are in clear text would be MUCH easier than launching this attack.

Resources

• IEEE 802.11 wireless standard
  http://standards.ieee.org/getieee802/download/802.11-2007.pdf
• AirTight’s announcement of the “Hole 196″ vulnerability
  http://www.airtightnetworks.com/home/airtight-media/webinars/wpa2-hole196-vulnerability.html

# # #

Several of you have caught me at various conferences and events and asked that I be sure to post links to content I’ve written for other sites. So, here ya’ go.

You can now find regular content of mine on Dark Reading, at their new SMB Security Tech Center and in the Security Views blog column. Here you’ll find articles to help small businesses kick start their security projects and make smart technology decisions. My content will cover all aspects of security, combining experience from the enterprise world on a scale that’s relevant for SMBs.

If there’s a topic on SMB security you’d like to hear about - just let me know!

My first post The Cash Drawer Lock Box and SMB Security can be found at Dark Reading here http://www.darkreading.com/blog/archives/2010/07/the_cash_drawer.html.

Keep visiting the site for regular posts from me, maybe even weekly. I know, you’ll all be shocked if I get back to weekly posts.

• Dark Reading SMB Tech Center
• Dark Reading Security Views Blog

# # #

The roles of TNC and IETF
As many of you know from my posts and talks, I always distinguish between frameworks and standards. TNC is a consortium that created a framework for NAC communications and endpoint checks. Many vendors have already bought in to the TNC specifications, but there have been a few holding out; Cisco being the largest and most influential. Strangely enough, Cisco wanted to have a standard in place, versus a less formal framework. Ironic, I know. In any event, the IETF (in the form of IETF’s NEA) has been trying to fill that gap of true NAC standards. The problem has been that, although vendors said “yes” to the IETF standards, no one was contributing any new specifications for it. Here’s where TNC reenters the picture. Slowly but surely, the IETF has been adopting the TNC’s frameworks as accepted specs for the standards.

The importance of this announcement
Today’s news demonstrates one more big step in the right direction for TNC, IETF and all the vendors participating. With the acceptance of two more TNC specifications into the IETF standard, we can expect to round out the full IETF NAC Standard by the close of 2010. With a full set of standards, vendors will be able to offer scalable, evolving solutions that integrate more seamlessly with the rest of the infrastructure. Exciting, isn’t it!?

The announcement begins

Internet Engineering Task Force Publishes Network Access Control Standards Based on Trusted Computing Group Specifications

PORTLAND, MARCH 11, 2010 - Trusted Computing Group today announced that two specifications created by its Trusted Network Connect (TNC) work group have been accepted and published as specifications by the Internet Engineering Task Force (IETF). This means that developers and OEMs wanting to create network access control products now will have a single set of standards to support.
“Enterprise users are the real winners; the agreement on a single standard for network access control and endpoint assessment will provide consistency across products from leading networking vendors,” said Russ Housley, chairman of the IETF.

Noted Steve Hanna, co-chairman of the TCG TNC work group and of the IETF working group on this topic, “This industry-wide agreement on standards will increase the number of vendors and customers adopting standards-based network security. In addition, products developed for the new standards can be deployed with the many existing products using TNC specifications to protect the network and critical assets from a myriad of threats.”

The first standard (called PB-TNC by the IETF and IF-TNCCS 2.0 by the TCG) defines a standard way to perform a health check of a network “endpoint” such as a laptop computer or printer. If the endpoint is not healthy, it can be fixed or have its network access restricted. The second standard (called PA-TNC by the IETF and IF-M 1.0 by the TCG) defines a standard set of health checks that are commonly performed, such as checking anti-virus status. These newest standards are based on the TNC standards that customers have been using for years.
continued

You can read the full press release online at: http://www.trustedcomputinggroup.org/media_room/news/113

Look for more information and content soon about TCG’s TNC, IETF and NAC standards, including a video interview with TNC’s Steve Hanna.

Resources and links:

• Trusted Computing Group http://www.trustedcomputinggroup.org
• IETF http://www.ietf.org

 # # #

What is it?
Maker Faire:NC is a newfangled fair that brings together science, art, craft and engineering plus music in a fun, energized, and exciting public forum. The aim is to inspire people of all ages to roll up their sleeves and become makers. This family-friendly event showcases the amazing work of all kinds of makers–anyone who is embracing DIY and wants to share their accomplishments with an appreciative audience.

Costs and Participation
Attend: FREE
Makers: FREE
Exhibitors: $50 - $200 (100-1600 sq ft)

A note from the organizer:

Maker Faire is an annual event organized by the people who bring us MAKE Magazine.  Maker Faire:NC is a fully sanctioned event but is being planned and coordinated by Raleigh/Durham locals.  Our goal is to bring together Makers, Crafters, Inventors, Evil Geniuses, Scientists, Artists, and anyone else interested in learning from NC, SC, VA, DC, and beyond.

Just like the bigger Left-Coast version, Maker Faire:NC celebrates things people create themselves — from James Bond-worthy electronic gizmos to Martha Stewart-quality “slow made” foods and homemade clothes. Inspiration is ubiquitous at the festival and there are surprises around every corner for people of all ages.

“At the surface, Maker Faire is a fun event for people of all ages,” explained (San Mateo 2009) Event Director Sherry Huss. “But we want people to experience more than just a weekend of creative entertainment, we want them to leave feeling inspired — that they too can create things, express themselves, and engage the world around them. Our goal is to resuscitate the spirit of American creativity and innovation.”

This video from the Full Size Maker Faire held in 2009 in California will give you a little idea of what we’re all about.

Ideas for Makers who want to participate (remember, it’s FREE)!

• Green Tech and Clean Tech
• Robotics
• Music Performance and Participation
• 3D Printers and CNC Mill
• Textile Arts and Crafts
• Home Energy Monitoring
• Rockets and RC Toys
• Radios, Vintage Computers and Game Systems
• Electronics
• Electric vehicles
• Biology/Biotech and Chemistry Projects
• Food and Beverage Makers
• Kites
• Shelter (Tents, Domes, etc.)
• Unusual Tools, Machines, or Techniques
• How to Fix Things or Take them Apart (Vacuums, Clocks, Washing Machines, etc.)

Links and Resources

• Maker Faire NC Site: http://makerfairenc.com/
• Maker Faire NC on Twitter: @makerfaireNC

# # #

Universal NAC Feature Model document: 
A guide to model and compare NAC solutions

Author: Jennifer Jabbusch
White paper, feature and mechanical evaluation and comparison of Network Access Control technologies
24 pages, PDF format
2010-03-03 RSA Edition, first release
Copyright Carolina Advanced Digital, Inc., see contact page to request republishing rights

Document Summary

All NAC products are not created equal and there is not a one-NAC-fits-all solution. The Universal NAC Feature Model was developed for internal use at Carolina Advanced Digital and is invaluable in informing and guiding discussions with clients evaluating NAC solutions. Initially intended for private use, the value to the larger industry has led to the development of this material in guidebook form.

One of the leading challenges in discussing NAC is the terminology. Instead of referring to vendor terms or the random acronyms and naming convention used in the NAC frameworks, this guides uses plain English to describe the four feature components of network access control systems and the specific mechanics used to implement the technologies.

This Universal NAC Feature Model is a guide for organizations to model network access control (NAC) features from a variety of products and vendors. It aids in the comparison and analysis of available features and provides a common language to identify and describe required methods and execution of technology. This allows for useful comparisons across vendors who offer the same features, but with drastically different methods.

This document breaks down all the components and mechanics employed by various vendors, explains each piece in detail, and provides commentary on factors to consider while investigating NAC products. The tables and explanations in this guide can be used to map key concepts to their vendor- specific counterparts and map a desired feature to the mechanics that support it.

To all readers, I hope you enjoy the information in this guide and find the layout and explanations useful. As far as I know this is the first document of its kind, outlining the full depth and breadth of NAC features, functions and mechanics from all vendors, in a single guide. I expect it to serve as a foundation for discussions in the industry and in dialogue between consumers and vendors.

This document provides:
- A uniform terminology and descriptions of features and technical mechanics to compare all NAC products currently available.
- A hierarchical view of NAC features and mechanics in a simple one-page table.
- An explanation of the technical mechanics of NAC and commentary on considerations as you investigate NAC solutions.
- A foundation that will grow and be updated as technologies and products change in the market.

Related documents: Catching the Unicorn: a technical exploration of why NAC is failing

# # #

Were you in the session? Before I launch into my opinions, I’m most interested in hearing from anyone that was in the Peer 2 Peer. As the facilitator, I get a different kind of value from these peer sessions. The real question is: did you? Feel free to post comments (anonymous is fine) or email me directly using the contact form.

First, NAC is not dead. Wednesday’s full room was proof of that; I think we had only a couple of seats open of the 25 maximum available. I will share with you that these P2P attendees were a little disappointed that the industry events were not giving NAC the attention they did just a couple of years ago. Everyone understands why, but their comments resonated with me. They feel abandoned by the vendors and the industry; left to fend for themselves and work out the many major kinks of a security technology that’s not as ready for prime time as we’d hoped. We lamented over the decrease in industry’s willingness to help us in our efforts and the obvious lack of NAC sessions on the schedules of major conferences, such as RSA and the upcoming INTEROP.

Second, people do want NAC. The interest seems to be completely in line with my personal observations that port security and authentication are still highest on the list of requested features, with a strong desire for endpoint integrity sliding in as a solid second or third. These are the features being touted by the primary remaining vendors in the NAC and endpoint security space and there IS a demand for them.

Third, the consumers are happy to compromise. Instead of selecting from a menu of over-zealous vendors pitching their fix-all solutions, the consumers want more reasonable expectations, more manageable deployments and a sustainable maintenance plan - and they don’t mind giving up a few features to reach those goals. The stories I heard were ones of heartache, headache and hopelessness, riveted with frustrations, mostly stemming from the use of the wrong technology in the wrong environment. Although there were vendor-specific tribulations mentioned by the group, I steered clear of that part of the discussion, realizing that the failure wasn’t in the product as much as it was in the processes created by poorly made technical decisions. Unfortunately, these people are at the mercy of the vendor to help them with the process and many times the vendor’s sales force (and even at times, the engineering team) doesn’t understand enough about the environment and their own product to make recommendations for a successful rollout.

As promised, I did distribute the Universal NAC Feature Model document to the group (well, until I ran out of printed copies). I’ll make that document available here as well this weekend. Now available.

With the confinement of a short 50-minute, session, we certainly couldn’t solve the evils of the NAC world, but it got everyone talking and it got me thinking - again. We can do this. We just need to make it affordable, efficacious and reasonable to integrate. It is possible, and the session reinforced my support for the groups working to create frameworks and standards that will help these consumers of the technology (and all others) find the right product for them and integrate it in a much less painful way.

# # #