I covered an all in one wireless exploit device previously, and will now cover some mitigation ideas. There is no individual exploit to mitigate but a series of weaknesses and insecurities that can lead to attack. To cover each step of the attack;

Attack Step
The device entices clients to connect, by responding to all wireless probes.

Prevention
Client wireless implementations should be more careful when beacons are sent out. Beacons should not be sent out for all stored wireless networks indiscriminately. Clients should use broadcast probes where appropriate instead. iOS 6 seems to now implement broadcast probes as standard. Whilst this is a positive move, most mobile wireless devices have connected to at least one wireless hotspot. Beaconing for popular SSIDs in the local area such as “BTOpenzone”, “FON”, “Boingo Hotspot” in the UK and so on will continue to attract most wireless devices. Another option would be to require that open networks are manually connected to by default unless that setting is manually overridden along with associated warning. In the mean time, not connecting at wireless hotspots, removing saved wireless hotspot profiles, and turning WiFi off when not in use are all options.

Attack Step
Once connected, assign the device an IP via DHCP and use DNAT to redirect all traffic to all hosts back to the device itself.

Prevention
The device should perhaps perform some tests to see if traffic manipulation is in use. This could be legitimate, but at least warn the user that something strange could be going on.

Attack Step
The device will answer iPhone or Blackberry’s HTTP test for internet access and return the expected response

Prevention
I suspect this feature is supposed to detect if an internet hotspot login is required. It should either be removed or secured better to avoid just opening an arbitrary page on connection to a hotspot. This feature alone could be exploited in other ways.

Attack Step
Client attempts to check email and perhaps contact other servers based on apps installed.

Prevention
Tighter verification of protocol implementations should be performed. User should be specifically warned if SSL is not in use.

Attack Step
SSL hijack.

Prevention
The client should display an SSL warning that clearly explains that the session may be being hijacked. Rather than a weak informational type message, the warning should be clear and explicit, and require the user to specifically accept that the connection may be being intercepted. The user should be particularly careful to note any out of character behavior such as suddenly prompting with identity or verification issues