Priveon Labs Security Blog

On a recent flight, I was standing outside the gate waiting to board and was approached by a worker offering free in-flight WiFi. This got me thinking about all of the conversations I had over the years with various CxO and Directors regarding wireless security and data-leakage. In many cases, organizations have done a 'fairly-good' job securing their wireless infrastructure BUT quite often, the PCs are allowed to connect to any network they want. As a matter of fact, it can sometimes be difficult in some cases to stop a computer from detecting and auto-connecting to a WiFi network particularly if it is broadcasting the SSID and using no authentication or encryption as in coffee shops, restaurants, hotels, and yes… airplanes.

Now, let's think about airplanes and WiFi. Users, especially on business commuter routes, often use their laptop, cell phone, and other devices like PSP game systems. All of these devices could be WiFi enabled and in many cases auto-connect to the in-flight Wifi network. This typically occurs without the users knowledge. The users may not even realize they are connected, they may opt to connect and use the service, or they may connect, review the terms and cost of service and shutdown the browser leaving up the WiFi connection. The problem here is that we need to ask ourselves what is leaking. Remember, WiFi unencrypted is basically a hub. Things like sniffing (packet capture), MiTM attacks, directed hacking, spoofing, etc are all very easily done in this scenario.

So, what may be leaking? Let's consider a few items:

• User name and password for a web service (Twitter, Financial accounts, shopping site, etc)
• Credit card or other data if unsecured or MiTM attack is occurring
• FTP, Telnet, VNC, etc sessions
• DNS/WINS/HTTP/POP/etc requests for unavailable internal corporate services and applications
• Passwords on clear transmissions (often same password and account everywhere so can be leveraged for secure site access once obtained)
• Not to mention the system is online and exposed to other potentially malicious systems

In a recent data capture file (pcap) provided to me from a flight taken in the US, several items were gleaned. Some of the info is easily visible using a tool like TCPDUMP and/or WireShark to interpret the data capture and filter the results. Additionally, WireSharks ability to Follow a TCP Stream for sessions can quickly put together HTTP, TELNET, etc sessions for easy reading. Beyond those tools, you can also use something like Chaosreader (a freely downloadable perl-script) to perform file carving on the pcap file. This script is capable of carving up the pcap into smaller session based data including the ability to extract and provide images, telnet sessions, VNC sessions via replay, etc to the user. Think of the potential impact this could have on your corporate security.

This is really no different than what is possible at any other hotspot except for the possibility that business travelers can be targeted via common commuter flights and routes.
Something to think about. As a concusion to this blog entry, I will provide the following 'scrubbed' data obtained from the capture file:

MPSReports

Recently I was involved in a Cisco Clean Access deployment project when the implementation ran into some issues with utilizing the Active Directory Single Sign On feature of CCA in the existing Active Directory environment.  I had no direct access to the servers running Active Directory and the prospect of communicating the steps to run diagnostics and submit numerous log files through email did not excite me.  Instead I had remote support engineers run the Microsoft Product Support Reports utility. This very handy wizard based utility gathers numerous log files, runs an automated array of diagnostics, and pulls all the results into a single archive file that can be extracted by support personnel to analyze later. One can decide to analyze the data on their own or have it on hand if the need arises to open a support case with Microsoft Product Support.

In my case, I was able to view the output of the dcdiag utility, the event logs of the DC's, and the configuration of the server's network interfaces to identify some issues that were affecting the NAC deployment - all without ever touching the servers or walking a remote support engineer through the process of the data collection.

PowerShell Execution Policy

The utility doesn't make any changes to the system but there is a chance that it will change the PowerShell Execution Policy. If you are working on a Server 2008 machine then you can use the instructions below on how to check what your PowerShell Execution Policy is before you run MPSReports and how to change the setting if needed afterwards (the command syntax on systems that use a version of PowerShell other than 2.0  is slightly different).

Before running the tool one should run the following command from a PowerShell prompt and leave the window open throughout the process:

get-executionpolicy -list

After running the mpsreports tool, run the “get-executionpolicy –list” command again and verify that there is not difference in the execution policies before vs. after the tool was run. If any of the values changed, use the following command to set them to their previous value:

To set the execution policy in a particular scope, type:

        Set-ExecutionPolicy <policy-name> -scope <scope>

    For example: 

        Set-ExecutionPolicy RemoteSigned -scope CurrentUser

Recently while configuring some Cisco NAC appliances via a web based remote control application. At the exact point in the setup where I was configuring the admin passwords, the keyboard passthrough of the remote control app went completely crazy and I ended up with a very, very, secure NAC appliance. I found the following article from Cisco on how to reset or recover the admin passwords on the CAM/CAS very helpful.

Password Recovery Procedure for the Cisco NAC Appliance (Cisco Clean Access) - Document ID 71159

A new version of Kismet 802.11 layer2 wireless network tool was recently released. Most anyone who has done a pentest including 802.11 has utilized the powerful Kismet.

Some of the improved/updated features include:

1. Improved stability and crash recovery
2. New filtering options
3. New alert options
4. Completely new UI
5. Revamped network protocol
6. Less CPU used for high numbers of networks
7. Support for plugins

On the web:
http://www.kismetwireless.net/download.shtml

If you have a GMail account, you may have noticed the new "More GMail Security" link recently added by Google. One of the most notable changes is that GMail now forces HTTPS connections at login. This previously was an optional setting (off by default). I for one applaud GMail for making this simple but effective change. Forcing HTTPS prevents sniffing on untrusted networks as well as wireless session hijacking (aka "sidejacking") as discussed at BlackHat Vegas 2007 (Errata security's Ferret and Hamster tools). Now if other vendors will simply follow suit!