After many episodes featuring the wireless pineapple on Hak5, I decide that it is time to get one and try it out (I’m way late getting to this one – about 4 years late). I actually won 2 auctions for the FON on EBay so I bought 2 of them.
Anyway, I was going to write a HOWTO for this, but I came across Darren Kitchen’s Jasager HOWTO, which is a very comprehensive, step-by-step walkthrough with screenshots, and I felt that there is no need to write a HOWTO after using his. If you are just starting out with the FON and you are looking for a good HOWTO to get Jasager up and running, I would recommend that you start here. The only thing I can add to the HOWTO, on Step 10, I needed to use single quotes instead of double quotes for the command issued to patch the Redboot config:
From: mtd -e “RedBoot config” write out.hex “RedBoot config”
To: mtd -e ‘RedBoot config’ write out.hex ‘RedBoot config’
The FON is a TON of a fun to play around with. If you play around with it enough, it’s almost inevitable that you will probably brick it at least once. The HiR Information Report has a great write up on how to un-brick the FON with a link to a script that will help you connect to the FON through telnet (if you kept it enabled). Here is a link to the article and the redboot.pl script from Digininja’s site.
Of course, if you need to do this, you will need to setup a TFTP server on your machine connecting to the FON to copy over the firmware.
Here is a good HOWTO for setting up a TFTP server in Ubuntu. NOTE: If you are running a version of Ubuntu 9.04 or later, you may need to add the “–daemon” option to /etc/default/atftpd in order for the sudo invoke-rc.d atftpd start command to work.
NOTE: This is NOT a new exploit by any means. Here is a link to an advisory released back in January of 2006. And Microsoft was notified well in advance before the advisory was released. From the advisory: “Microsoft was contacted on October 13, 2005. After numerous exchanges of emails and a conference call, Microsoft was able to reproduce and isolate the issue within their software. As there are multiple and easy-to-implement workarounds for the issue, Microsoft has scheduled to include the fix in the next service packs.”
The only “good” thing that I can say about this exploit is that doesn’t appear to affect newer versions of Windows (like Vista or Windows 7). Of course, that won’t stop a user from manually connecting to a Wireless AP with the same name… But that’s really a different issue altogether…
Here are the workarounds:
Workaround #1: Disable wireless when not in use. Workaround #2: Use an alternate Wireless Client Manager, (e.g. for an integrated Intel Wifi connector, use Intel PROSet/Wireless) as all others tested do not seem to have the problem (this testing was not all-inclusive). Workaround #3 (recommended): 1. Click on the Wireless option in the System Tray and open the Wireless Network Connection window. 2. Click on "Change advanced settings". 3. In the Wireless Network Connection Properties window, click on the Wireless Networks tab. 4. Click on the Advanced button. 5. Click on "Access point (infrastructure) networks only" This workaround prevents you from connecting to any ad-hoc network in the first place.