Freddy: I have found the chal - I was looking in the wrong place.
Would you mind, posting your suggested solution here? I'm not a believer in security by obscurity - I got the impression you're neither, so I assume your suggested fix solves the problem in the process.
I have thought about this a bit and I think I have come up with an improvement that can be implemented with reasonable effort:
Current situation (based on Freddys description):
1) user requests page ie
http://www.myspace.com
2) Chillispot redirects (302) to
https://login.fon.com?challenge,mac,uam ... hotspotmac
3) User sends form to
https://login.fon.com with username+password
4) login.fon.com redirects to
http://uamip:uamport?username,challengedPW
5) router decodes the challengedPW and sends a verification request with username/password to the fon radius servers.
5) uamip:uamport redirects (302) to
https://www.fon.com
Familly&Friends are checked on the router, this is one reason why they appear as unknown in the usage log.
From the above it's clear that the redirect 2) can be captured in cleartext and the request resulting from 4) can also be captured in cleartext.
The algorithm to create the challengedPW is known and based on the challenge transmitted in cleartext as well as a shared "secret" that is the same for all FON routers and can easily be extracted from the WIFI routers firmware.
Suggested immediate change (PHASE1):
EDIT: the solution suggested for PHASE1 makes no sense. I made the typical mistake of trying to find a quick fix without trying to break it. See below for the fix of the fix;-)
The shared secret should be individual for each router. To have the simplest possible implementation the shared secret could be a secure hash of the routers mac and a master secret (which is never transmitted to any router but known in the login script). Hence the (per router) individual shared secret would be ISS=SHA1(master_secret, MAC).
1) The FON configuration/heartbeat script retrieves the ISS (not the master secret) and stores it as "uamsecret" ie in place of "garrafon".
The login script at login.fon.com needs to be changed as followed:
$hex_mac= pack('H32', $_GET['router_mac']);
$iss= SHA1($master_secret.$hex_mac);
$hex_chal = pack('H32', $_GET['chal']);
$newchal = pack('H*', md5($hex_chal.$iss));
This can be implemented with minimal effort (I would say less than 1 hour). No additional database and no infrastructure change is required. It does not protect users against rogue hotspots, as the hotspot still obtains the username (email) and password in clear text. However it does provide protection against a snooping attack.
EDIT: As suggested this doesn't work. A snooping attacker can see the router_mac (ie WLAN MAC). It can then create a configuration/heartbeat request against the fon servers with the mac address of the hotpost beeing snooped to request the ISS.
remark1: Maybe an authentication process for the heartbeat script already exist in which case this edit is useless.
remark2: It does not help if the router chooses the ISS and transmits it to the servers without authentication.
Finding: The request used to exchange the ISS must be protected such that an attacker can not simulate it for a choosen router. Hence, the router needs to authenticate the request with credentials that an attacker can not obtain and which FON needs to store and check at each request. (It could still be the heartbeat/config request but it needs to be authenticated).
Some ideas: The ISS request could use the LAN (not WLAN) MAC of the router, the serial number of the router, the router password, etc. as credentials. Some of those are relatively week as they may be derived from the WLAN MAC and knowledge of production processes. Bootstrapping the new authenticating script version is relatively simple: the first request with the "router credentials" is used to store the credentials into the DB. Later requests check if the credentials match the DB entry and block access if not.
Suggested short-term change (PHASE2):
Lines in italic remain identical to current situation.
1) user requests page ie http://www.myspace.com
2) Chillispot redirects (302) to https://login.fon.com?challenge,mac,uam ... hotspotmac
3) User sends form to https://login.fon.com with username+password
4.1) login.fon.com creates a session key with short validity and stores the tuple (useralias,sessionkey) in a radius repository. useralias is NOT the username but the alias also displayed in the connection logs.
4.2) login.fon.com redirects to
http://uamip:uamport?useralias,challengedSessionKey
5) router decodes the challengedSessionKey and sends a verification request with useralias/sessionkey to the fon radius servers.
5.1) FON Radius server checks useralias/sessionkey.
5) uamip:uamport redirects (302) to https://www.fon.com
- Family&Friends are checked by login.fon.com.
- The sessionkey(s) must contain a good random, the hotspotmac, and time(out)stamp with validity of <1s.
Solved:
- Username (email) and password are not visible to an outside attacker or a rogue hotspot. The fon.com session can not be taken over by an attacker.
Remaining problems:
- Valid session keys can still be captured. The WIFI session can be taken over by an attacker. (see comments below)
Advantages:
- The suggested solution can be implemented without changing the firmware.
- A hotpot owner could capture the useraliases to implement a verification of the FON logging.
Comments on session keys in the suggested improvement:
Capturing attacker: The sessionkey can still be captured, however its short validity together with the "one session only" feature that already exists make it barely usable for the attacker. The mechanism can be strengthened by changing the firmware: The firmware should check if the hotspotmac provided in the sessionkey matches the current hotspot.
Rogue hotspot: An attacker could set up a rogue hotspot to capture "choosen mac" session keys. This rogue hotspot can use the mac of another existing hotspot to obtain valid session keys for the other hotspot. However the obtained session keys would have to be used in realtime. This allows unauthorized access to FON hotspots, however the user credentials remain confidential.
Final conclusion:
The suggested improvement does not fully resolve the problems with Chillispot. It does however protect usernames (email) and passwords. It is questionable if a user friendly solution can be found that completely outrules the potential to gain temporary unauthorized access to a hotspot. A rogue client positioned near an authentic hotspot together with a rogue hotspot simulating the authentic hotspot can always be used to tunnel a users connection attempt from the rogue hotspot to the authentic hotspot. The session created on this authentic hotspot can then be taken over after successfull login. This would also apply with WEP encryption enabled. In it's core it's a more involved variant of MAC spoofing.
A potential solution would be to block all traffic except traffic targeted at a fon.com vpn server. However this would require downloading and installing client software.
Another potential solution could be based on a localproxy implemented as a signed applet. The DHCP response from the hotspot may contain a proxy (ie localhost:1080) + non-proxied domain (fon.com). The localproxy could be implemented by a signed java applet served from
https://login.fon.com. However I think that the majority of installed systems will not recognize proxies provided via dhcp.
More importantly, we early adopters desire a far greater degree of collaboration with fon. They should have the firmware and web portal developers in here exchanging ideas. 
