Aruba forces customers into Cloud: Offers no way out

February 18, 2014 by 6 Comments

Authors note: Aruba has addressed this satisfactorily by removing the offending release of code. Further details are available in the comments section of the post below. This header was added as a post-script to the original blog which remains below for posterity. Well done Aruba.

Software updates are a matter of life. Developers and coders aren’t perfect, bugs need to be fixed, new features need to be rolled out, new hardware needs to be supported. As networking professionals, we’ve come to terms with the sometimes continual churn that patch vehicles have enabled – the Internet as a distribution mechanism has made it commonplace for manufactures to ship incomplete features or functionality under the guise of ‘by the time you complain about it, we’ll have a download ready to fix it”. They all do it. We all consume it.

Sometimes a manufacturer does something so egregious and underhandedly reprehensible that it simply cannot be. Aruba release their 6.4.0.0 ArubaOS on Feb 15th, 2014 and snuck in a ‘phone home’ feature. They state twice that they’re enabling this feature by default:

Once buried on their dashboard if you happen to navigate to their code by clicking on the words in their tree, not the ‘+’.

You'll miss the warning if you use the boxes!

You’ll miss the warning if you use the boxes!

The second is in their release notes. I applaud their efforts to make their customers aware that they will be changing the default values in their release notes, but the download page navigation needs some help. Their release notes clearly state:

The PhoneHome Automatic Reporting feature is enabled by default. PhoneHome feature can be disabled by selecting the Disable option under Maintenance > Aruba TAC Server section of the WebUI.

What they do not tell you is that even if you have explicitly disabled this option previously, when you update your code to the afflicted 6.4.0.0 build, it automatically re-enables this feature without warning you! Aruba intentionally snuck in an information gathering option and mislead their customers by stating that it was only enabling the ‘feature’ by default. In common english, this means when you’ve accepted the default settings – for example on a new build or a controller default, this option will be enabled. What they did not tell you is that there is no ‘opt-out’ way of having this turned on during a code update! They certainly give you guidance on how to disable it post-installation, but by that point in time, it can safely be assumed that your controller has phoned home and divulged all of your enterprise wireless configurations – information that you may not want to send to them – such as your PSKs, your RADIUS shared secrets, your default local administrator credentials – all without warning their unsuspecting, and all-too trusting customers, that Aruba was going to be maintaining a list of their most secret enterprise data.

Aruba is secretly compiling data from all of their existing enterprise customers regardless of any opt-out that was previously set.

What if your company had a security policy in place that stated that no configurations were to be shared outside of your organization? What if you had no Cloud strategy? How does having Aruba keep a copy of your configuration expose your organization to compliance issues? How will that impact FIPS compliance? Seemingly no one at Aruba cares about these issues and as far as I’m aware, there are only two ways to prevent this from occurring – and both need to be planned for before you update your software:

  1. blackhole or ACL off your controllers from talking to the Aruba cloud until you can log into the controller.
  2. disconnect your controller from the network during your update and console into it to undo the command.

Either way is intrusive and difficult to manage and if you were not aware of this data-heist prior to your update, you have no way of confirming if your data has already been compromised. In my opinion Aruba needs to do damage control here real-quick like and:

  1. Pull the malicious and infected code off of their downloads section immediately.
  2. Apologize for negligently harvesting customer data.
  3. Clearly articulate what customer data was stolen and how it was stored.
  4. Clearly articulate how long once a controller has come online that it ‘rats your configs out’ to the manufacturer.
  5. Give customers the option to have their data removed from Arubas servers and have a third party audit this removal for confirmation.
  6. Modify the code to obey previous opt-out configurations and re-post it.

Until then, you may want to let your SOC, CTO, IT Director, or resident person in charge that if you did the 6.4.0.0 code update from Aruba that you should consider your network keys, shared secrets, and local admin accounts compromised and start working on a remediation plan immediately.

Advertisements

Filed under Aruba

MythBusters WiFi: Xirrus

February 18, 2014 by 8 Comments

I’ll be the first to admit that when I see something ‘out of the norm’ I shudder and have a knee-jerk reaction that is not always positive. There is so much success around the tried and true enterprise approach to wireless of using omni directional antennas that when you see someone intentionally deviate from it, it can be jarring to say the least! I’ve had the pleasure to be present at the Xirrus Wireless Field Day sessions for WFD5 and WFD6 and I can honestly say that they did a superb job of taking a contentious topic and addressing it head on. For those that are unfamiliar with the Xirrus product, their unique approach to wireless is to stack multiple Access Point radios into a single housing and use highly directional antennas to create an ‘Umbrella Corporation logo’ of coverage:

Image likely copyrighted by Capcom

(it should be noted that I do not believe that Xirrus is somehow evil, involved in genetic engineering, or otherwise a bad company – the logo is simply an easy way to represent a high degree of directionality from a centralized point)

Adding multiple radios into a single housing is not a unique approach. Most everyone on the market starts with two radios in their Access Points and you can even find a handful of three-radio solutions, but Xirrus takes this approach to the next level by stacking as many as 16 radios into a single Access Point! The challenge that other manufacturers do not need to address is overlap. In a standard two or three-radio approach, you typically operate one radio in 2.4GHz and the other in 5GHz (and for those rare 3rd radio guys, they usually stick that radio in monitor or listen-only mode). Tack some omni directional antennas on those bad boys and you’ve got yourself an AP! Xirrus however, intends to have multiple radios in a single AP operate on in the same frequency. This presents some challenges about the efficiency you can gain from having more than one radio in the same frequency in the same physical package (AP). At WFD5, there was much gnashing of teeth regarding how you accomplish this in one package. I’ll not go over the gory details, the video is posted here. Xirrus came back to WFD6 and brought with them their Director of RF Engineering, Avi Hartenstein and tacked the conversation head on.

My goal was simple with this post. I wanted to prove that directionality does exist in the Xirrus product once and for all. I was able to acquire a 4 radio array and decided that the best approach to visualize this purported phenomenon was to actually survey with an AP in an area with no obstructions (scientific, no?). I took the array, statically assigned one of the radios to a fixed channel, turned its power down to -15dBm (yes, they go *that* low!), and took it outside. The results speak for themselves:

 Umbrella logo likely copyrighted by Capcom

Ladies and gentlemen, you saw it here first (or maybe not) – the myth of the Xirrus wedge is real! You can see near the bottom of the image where the AP was placed (at random orientation). I peeled this wedge view out using Ekahau’s Site Survey application after quite a walk outside in the cold. This directionality is fairly easy to see even with my coarse sampling outside. It should be noted that it will be near impossible to visualize this dramatic of a wedge indoors however due to the prevalence of those pesky attenuators otherwise known as walls and furniture.

I’ve seen my fair share of wireless deployments, I know what I’m comfortable with, I know when I move outside of my comfort zone. An experience I reference often is an educational facility that was using directional patch antennas indoors on 10 ft ceilings pointed at the ground. While this is a startling design, when I dug deeper into their design methodology, I discovered that they surveyed using the exact model of antenna and AP that was deployed, correctly visualized the resultant zone of coverage, and validated that this met their applications need. While not a solution I would lead with, there was no fault with their design methodology or implementation, and the infrastructure operated as designed. When you tackle a Xirrus deployment, I would advocate the same approach: understand your needs (throughput, density, coverage, etc), and design to meet those needs using the gear you will be deploying. Survey what you deploy, deploy what you survey. In the Xirrus world, this presents a few design choices to consider:

1) Orientation of the AP.

The Xirrus array has a compass in it. Use this compass to determine the orientation of your array during the survey and ensure that when it gets deployed that this lines up correctly (use the logo on the housing if you need to).

2) Oversubscription.

You must pay close consideration to the number of uplinks to your array and balance this with your deployment expectations. Oversubscription is nothing new so don’t let this scare you – just be aware that you’re moving your uplinks (and potential bottlenecks) further up the line (closer to the AP). This is going to be particularly important as you consider updating your array to newer technologies such as 802.11ac.

3) Powering the Array

Ensure that you have made concessions for powering the array. This will likely require an external power injector but sourcing them along with the array should not be problematic.

4) Antennas change with the modules.

One of the most insightful things I learned from the WFD sessions are a reinforcement that the antenna is part of the radio module. When you replace that module, you replace the antennas that are a part of that module. This could potentially impact the RF of your deployment and will most assuredly change the visualization of your survey data.

Xirrus uses highly directional antennas in a unique way to extend the reach of a radio. This coupled with a low powered radio gives you a number of excellent design pieces for most any wifi environment or need. Pay close attention to the number of radios that you need, apply some logic and reason to your design (don’t expect 8 of your 16 radios to operate in 2.4GHz for example) and make sure your celling has sufficient mount points. The arrays can be weighty. 🙂

Filed under Access Points, Wireless, Xirrus