McWireless Exposed
by Epiphany (epiphany@port7alliance.com) and J0hny Lightning (j0hnylightning@hotmail.com)
Through word of mouth we heard that select McDonald's locations are offering free Internet access to their customers via 802.11b for a trial period lasting through the 1st of July.
This article is a compilation of our findings while playing at several of these Wi-Fi spots. Our exploration was conducted from a laptop running Windows ME and a laptop running FreeBSD 4.8 with PRISM II cards.
The Basics
The company that brought Wi-Fi to McDonald's is called Cometa Networks.
At the time of this writing, this service is available at only ten locations scattered throughout Manhattan. A map can be found at www.mcdwireless.com. The pilot period will last until July and then people will be forced to pay three dollars for 60 minutes on the network. (Or so they say.)
During the pilot period a card resembling a calling card is given out with every meal purchased at a participating McDonald's. Each card has a username, password, and serial number in the corner. The username is five characters and the password is five digits. We believe that the two are generated using an algorithm, but we do not have enough cards to find a pattern. Cometa Networks plans to take this project nationwide to hundreds of locations by the end of this year.
The SSID of the McDonald's network is: cometa
Both of the laptops we used connected to the network automatically.
winipcfg and dhclient were used on the Windows ME and FreeBSD machines respectively to get IP addresses.
Fooling Around
When a web browser was opened on either machine, a DNS error popped up and the browser reverted to login.cometanetworks.com.
This site is currently accessible on the WWW, but trying to login causes a CGI error. Before we logged in with the accounts on our cards we wanted to see what was possible. We found that DNS names could not be resolved at all:
$ ping www.google.com ping: cannot resolve www.google.com: Unknown host |
However, pinging Google's IP was successful:
$ ping 216.239.51.99 PING 216.239.51.99 (216.239.51.99): 56 data bytes 64 bytes from 216.239.51.99: icmp_seq=0 ttl=48 time=190.319 ms ... |
Unfortunately, trying to connect to the website by putting the IP of Google in the browser was a bust. So was trying to Telnet to any port of any machine's IP address.
The next thing we did was change the IP of the DNS servers to that of our local ISP. On *NIX this can be done by editing: /etc/resolv.conf
On Windows you can change this setting in Control Panel -> Network. Now our boxes were able to resolve hosts.
Pinging Google was a success, however trying to view a web page was not. The browser was still directed to the login page. Our boxes were not able to make any TCP or UDP connections to any boxes on the web at all.
Telnet'ing or SSH'ing to a shell account was also a bust. We deduced that TCP/UDP was firewalled, but ICMP wasn't. It was time to log in and work from there.
After putting in a login/password a questionnaire pops up.
The HTML on this page had some interesting JavaScript that was in charge of opening the login timer. Unfortunately, changing this code did nothing except cause an error. At a later trial we found that changing the DNS is beneficial, because the default setting causes errors from time to time.
We kept the FreeBSD machine logged in legitimately and used the Windows ME box to see what in formation we could uncover without logging in. After some attempts at pilfering, we discovered some interesting HTML code.
The suspicious code was this particular string:
<INPUT type=hidden value=12.103.97.40 name=UIP> |
With a quick portscan using Nmap for FreeBSD and SuperScan for Windows we came up with several unusual port numbers.
It was one of these that brought us to a discovery. It turned out that connecting to port 1111 through a browser, (http://12.103.97.40:1111), brings up a totally different login page.
We have dubbed this "The Back Door." We think this page was set up for technicians who are too busy to be limited to 60 minutes. This IP address also has port 80 open, with a similar "backdoor" login page, except there are some subtle differences in the HTML.
A curious traceroute on 12.103.97.40 showed that this was the first and only hop, meaning that logging in like this was local to the network of the particular McDonald's we were in. We believe that other locations have similar backdoors which in theory can be found with traceroute and a port scanner. (Just search all the hops for port 1111 and you may get lucky.)
Logging in through the backdoor allowed our computers to connect to the network but without loading up the 60 minute timer nuisance. To test the actual validity of our backdoor, we waited for one of our accounts to expire and tried to login with the same account legitimately. This caused an error. The backdoor worked without a hitch.
This only verified our belief that it is possible that the username/password pairs on the cards are algorithmically generated and the local backdoor is not updated with the expired accounts. With the backdoor one account is enough to come back forever and stay logged in as long as you want.
Before we left our McWireless exploitation marathon, we slapped a sticker on the wall that said "Hackers always come in the backdoor."
Wrapping Up
If there is anyone out there who has played with wireless at McDonald's, we would love to hear from you.
We are planning a follow up article for when the pilot period is over and the service is no longer free. And of course, we wouldn't leave you without giving you some logins for the backdoor:
cvktd/57517 fkzdi/42587 uexto/11833 xiiub/71958 |
Shouts and thanks: everyone at port7alliance.com, lusystems.tk, #mabell, stankdawg.com, MADcow.