Thursday, February 27, 2014

Airtight Networks: A look at WIPS Part 2 - Over the Air

So in Part 1 of this series on Airtight WIPS, we looked at how Airtight determines if an AP is rogue, or an "on-network rogue" by some vendors definition.  Now that we have found an AP is plugged into my network, what do I do with it.  In Airtight, we can quarantine the rogue AP, meaning we will try to prevent clients from associating to it.

In looking at what the Airtight system is doing, I decided to leverage my 1 year eval of Omnipeek aquired from the #WLPC conference.  Thanks @KeithRParsons for putting this on.
But before we look at what Airtight is doing to protect me, let's take a baseline.  Just an example of our client associating to this 

Here you can see a pretty textbook capture of the authentication/association process of "Jake's iPhone 5S" to my survey-5 SSID (open).

Now let's engage the quarantine of this rogue AP.  For this example, we are going to manually quarantine one of my rogue APs.  I chose manual just to ensure I am not accidentally containing any of my home networks and impacting my wife during testing.  Here is a quick screenshot of me doing this.  It's a pretty simple process, just select the rogue AP and clicking the Quarantine button.

Now that we are protecting my clients from the big bad "survey-5" rogue network, I'm going to repeat the process.

So for starters we see a deauthentication frame after both the Association Request and Response.  Let's look at the Deauth sent just after the Association request. The first indication I see is that the deauth frame was sent at 6Mbps, whereas in the previous example, all the management frames were sent at 12Mbps  This tells me this is the Airtight AP sending this frame and spoofing the rogue SSID. Now lets look at the details of this packet:

So the Airtight AP sent a broadcast de-authentication packet spoofed from the rogue SSID.  This is fine since A. this rogue is on my network and B. I've decided to quarantine it.  I was half expecting to see a unicast deauth, but broadcast works fine in this scenario.
Now let's look at the deauthentication that occurs right after the association response.  This time it appears that the deauth is coming from my iPhone.  Notice again that it is sent at 6Mbps.

We can see that the Airtight is now pretending to be my iPhone, saying that my iPhone has decided to leave the rogue SSID.  I honestly didn't expect this, but it totally makes sense.  In addition to make sure the client has left, it makes sense we should also send AP a deauth so it ends the clients session, ensuring the client is dropped if it doesn't listen to the deauth message.  Comparing the signal strength to my client

We see 22dbm difference, so I'm positive that this packet isn't coming from my phone, which is very close to the capture adapter.  Both the rogue and the Airtight AP are in the lab about 30 feet away.
As a side note, I did see some odd behavior on my iPhone during the deauth.  Instead of just disconnecting, the iPhone displayed a PSK entry field, even though this is an open SSID.

I didn't see the same behavior on my windows laptop, so this may be some Apple specific behavior.  Hopefully one of the Apple guys reads this and leaves a comment (in my dreams).
My windows 7 laptop was able to connect to the AP.  But while I was able to establish a connection, it was very short-lived.  We see the Airtight change gears and send some unicast deauth packets to both the client and AP.
Shortly after connecting, we see omnipeek detect a wireless duration attack, which just appears to be a CTS to self with a very large duration field:

After we this, my laptop starts probing and tries to associate again.  We see the same deauth results and the duration attack is repeated with a different NAV value occurs and the laptop gives up disconnects.  The Airtight appears to say, well if you won't listen to me, I'll just use the duration attack to reduce your ability to do anything on this WLAN until you give up.

I'm sure there are some more methods to the Airtight WIPS.  I know I've heard them speak on ARP poisoning as one of the tools in their toolbelt, but this post is running long as it is. I'm very impressed by Airtights ability to contain rogue clients and access points.  They've also done a great job making the classification of networks easy to manage.  In the next part of this series, I'm going to look at some common scenarios that I've found in my travels as a wireless engineer.  I would consider these scenarios commonplace and they are not designed as ways to "beat" WIPS, but to show off how well the Airtight system combats common rogue technologies and attacks against WLANs.

For Part 3: I'm going to round up some gear and put together some typical rogue AP type scenarios and show how the Airtight system defends and protects your clients.

Monday, February 17, 2014

Mac OS X Mavericks: DNS-Server required for default route

I ran into an interesting client behavior issues with several Apple Macbook Air Laptops today at work.  I was able to solve the mystery, but thought I would post my findings as I just confirmed it in the home lab with my wife's computer.

Observed behavior:
Mac OS X clients running 10.9.1 using a DHCP address require the DNS Server to be configured in order for the default route to take affect.  Without the default route, off-network traffic receives a "no route to host" error.

Now the network engineers at work were mocking up was an isolated network with no DNS or internet access. As far as I can tell

Catalyst 3750 acting as a L3 switch and doing DHCP for local VLANs.

DHCP Configuration:
ip dhcp pool ClientTest

Vlan Configuration:
interface Vlan145
  ip address

For this scenario, I am using a Flexconnect AP with the SSID dropping off to vlan 145.  Also I am using a server upstream to ping.  I haven't had a chance to verify that this works with other vendors, but I would guess it does.   Assume that routing is working (as it is).  The production scenario was with a 4500, with local mode APs, and the results were the same.

Now for the client.  My client in this case is a 2012 MBA running 10.9.1.

Here is my ifconfig output:
        en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST>    mtu 1500
ether 28:37:xx:xx:xx:xx 
inet6 fe80::3 prefixlen 64 scopeid 0x4
inet netmask 0xffffff00 broadcast
nd6 options=1<PERFORMNUD>
media: autoselect
status: active

Now lets see if we can ping the default gateway:
Valeries-MacBook-Air:~ valeriesnyder$ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=3.185 ms
64 bytes from icmp_seq=1 ttl=255 time=3.030 ms
c64 bytes from icmp_seq=2 ttl=255 time=5.038 ms

Success.  Now lets ping my server upstream from the lab:
Valeries-MacBook-Air:~ valeriesnyder$ ping
PING ( 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: No route to host
Request timeout for icmp_seq 2

Hmm, this should work.  I verify in the network control panel that I have the as the default router.  There's no reason I *shouldn't* be able to ping the server.  Except that I'm not passing the DNS Server through the DHCP server.

Lets change the DHCP server configuration to the following:
ip dhcp pool Test

In this example, i'm using which is a totally bogus DNS server.  It doesn't need to work in order to get routing to work on the MBA.
Same SSID, just the DNS-Server change.

Here is the relavent ifconfig output:
ether 28:37:xx:xx:xx:xx 
inet6 fe80::3 prefixlen 64 scopeid 0x4 
inet netmask 0xffffff00 broadcast
nd6 options=1<PERFORMNUD>
media: autoselect
status: active

Now skipping straight to pinging outside the local subnet we find that it works, just by adding the DNS-Server
Valeries-MacBook-Air:~ valeriesnyder$ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=124 time=8.056 ms
64 bytes from icmp_seq=1 ttl=124 time=2.113 ms
64 bytes from icmp_seq=2 ttl=124 time=3.217 ms

I have no idea why this client behavior occurs, or if it intentional. I was able to replicate the behavior with a Win2k8r2 dhcp server and an IP Helper.
   *Note that Windows populates a DNS Server of if you do not specify a DNS server.
   You *MUST* delete this option in order to replicate the behavior.

Further Testing:
Configuring the IP address of the client manually without a DNS server configured exhibits the same behavior.

Mac OS X Mavericks (10.9.1) requires a DNS Server defined in order to use the configured default route.

Sunday, February 16, 2014

Airtight Networks: A look at WIPS Part 1: Over the Wire

When it comes to security, I have a personal motto: Think maliciously, act responsibly.  I really enjoy trying to manipulate clients, exploiting behavior and finding ways to prevent it in the "real world".

For protecting wireless networks in the "real world" one of the best tools is is WIPS.  Word on the street is that the Airtight solution is pretty good.  The presentation by Rick Farina at Wireless Field Day 6 was fun for me.  Rick is a great presenter and brought a lot of fun and energy to a security presentation.  For more on the WFD6 presentation, check out what fellow delegate Lee Badman wrote on his personal blog:

Also watch his presentation here:

This is the first of a few posts on Airtight Networks WIPS solution.  Part 1 will cover how Airtight does rogue detection, Part 2 will cover containment and OTA communication and Part 3 will cover common Rogue scenarios and look at how

*I will note that Airtight gave me a C55 AP during my visit during WFD5.  While I'm grateful to them for this, these posts are my own opinion and not influenced by their generosity.

Coming from the Cisco world, I see that Airtight takes a very different approach to identifying on-network rogues. Instead of trying to correlate Wi-Fi traffic to wired traffic by listening on the wire (Rogue Detector), scanning CAM tables on switches, or trying to connect to open access points and sending traffic towards the controller (RLDP),  Airtight sends broadcast (or potentially unicast) frames on a vlans connected to the Sensor/AP and then listens to see if those frames are ever sent over the air.

Let's look at the wired side of my Airtight C55 AP.  For example, here the mac addresses from my WIPS mode AP on my network:

You'll notice that there's the management mac and the rest are mac addresses created by the WIPS-mode AP, one for each vlan that we are doing WIPS on.  Here is what I have my AP configured for:

*Note, VLAN125 is present, just not in the picture.

Spanning the port on the Airtight AP, I'm able to capture some of the packets coming from the WIPS-AP.
For simplicity, i wrote a display filter to clean up the data only from the Airtight AP:

(eth.src > f2:91:4a:7f:00:00 and eth.src < f2:91:4a:7f:ff:ff)

You can see it does a lot of GARP for addresses on the VLANs I am monitoring.  I also observed it sending DHCP requests on the VLANs configured as well:

So what does this give us?  Well, by sending these L2 broadcast messages out, the hope is that a rogue (on network) AP will hear the L2 broadcast and forward this traffic out to clients over the air.  Once this happens, the WIPS wireless radio will hear the packet and be able to see that it is from itself.  This allows the Airtight system to tell that an AP is connected to the network.  From here we can Airtight take action against this rogue network/clients connecting to this network.

What's next?  In part 2 of this series, I'm going to look at how the Airtight WIPS prevents clients from connecting to a Rogue AP, as well as looking at some of the options settings.  For Part 3, I'm going to try my hand at some common scenarios to see where the Airtight system works and where it does.