Friday, October 12, 2012

Resolving Hostapd issues in the new SILICA VM

[Editor's Note]

There are a lot of layers in SILICA - from the VM's hypervisor, to the Linux kernel, to the firmware and card itself. And, of course, there's SILICA (which is a pure-Python program, as you know). We often get requests to enable SILICA to run on "any card" but we've found that not having control of all parts of the stack leads to very difficult to diagnose issues - things you can't have in the wild as you are in the middle of a penetration test. Below, Alex describes in gruesome detail the process of fixing one such bug...

Resolving Hostapd issues in the new SILICA VM


Recently we moved SILICA into a new virtual machine that is based on Ubuntu 12.04. With a little bit of fine tuning SILICA is running great. However I noticed that our fake access point / impersonation wasn't working as expected. Our code leverages the hostapd daemon that allows you to create a software AP.

My first thought was that there was some kind of problem with the version of hostapd so I started by trying to update the Ubuntu version of hostapd. After a few attempts I got it to compile with the right config file and it was up and running. The problem was that for some mysterious reason the access point that I had created was not broadcasting any beacon packets. So that took me to my second thought of trying to downgrade the version of hostapd to the latest stable 0.7.3 at the time. I was previously trying 1.0. A few minutes later after compiling all the dependencies I still had the same results; no beacon packets were being sent out.

Looking a bit deeper into the issue I started checking my configuration file to see if there was some misconfiguration or change between the versions. I did notice that hostapd was utilizing a driver which was a layer of communication with the host operating systems driver. After trying different options I did not get anywhere but at this point I started thinking that there may be more to it than just a user space daemon not functioning properly. My thought was to see what will happen if I was to use the old carl9170 SILICA driver but it didn't work.

I promptly downloaded the compat-wireless drivers that matched the old version and I was up and running with a freshly built driver code base. The card was identified and loaded fine and most of the basic functionality was working and everything seemed to be back to normal so I loaded up SILICA to see if the issue was still there. I created a fake AP like I did earlier and waited on Wireshark to see if there any broadcast packets being sent out but the issue was still there. At this point I was completely lost so I decided to take up the issue with other people to see if someone else had any ideas.

After asking around a few of the kernel wireless developers and giving them a lot of dmesg outputs in Pastebin I was told that there may be some incompatibility between my card and the driver version I was using and to try and update to the latest compat-wireless. So I updated to the latest compat-wireless even though I already knew at this point that this was system related and not hostapd related.

The problem was still there no matter what version or configuration I tried.

So being left with my last resort I decided there was nothing left to do but to dive into the driver code base and see what is really happening (unfortunately). A few hours later and a lot of printk's I realized that the code that exposes the access point mode lived inside the firmware and if the firmware did not support that then the driver will give you access to all the other features but that. Luckily the firmware for carl9170 is open source and I already had the latest git checked out on my system. I went through the build configuration and I enabled some features and cross-compiled the code. The driver handles the uploading into the device so I quickly reloaded the kernel module.

At this point I had a fresh firmware that I had built from the git running on my wireless card. I loaded up SILICA again and started the Fake AP option. A minute later I started to see beacons being broadcasted from my card! I loaded an attack just to make sure everything still worked and the feature was fully functional and that succeeded. I did a quick run through the entire feature set of SILICA and everything works as expected. So there it was - a new firmware solved the problem.

The new update of SILICA is going to automatically replace the old firmware.

No comments: