A Bell goes south.
A user of Bellsouth.net, David Grant, told me of a new security hole
in the ISP's Web mail service. Grant walked me through it over the
phone and I can verify that Bellsouth.net behaves as he claims.
If you type a valid username but an incorrect password at the
Bellsouth.net login
page, the error page you arrive at contains the supplied username
and password in clear text in its URL. Right there at the top
of the screen. This doesn't happen for valid logins, most of the time.
A readable username and password should never appear as part of
a constructed URL, even if (as in this case) the software thinks they
are invalid. The credentials get recorded in the browser's history
log where they are susceptible to prying eyes and the odd JavaScript
exploit.
Updated 2001-02-26, 10:31 pm:
(Rob Mayoff and Paul McJones pointed out that my original scenario,
in which name and password show up in referrer logs, is incorrect. If
the user types a URL into the browser the referrer log is blank. My bad.)
There's worse. Grant claims that on more than one occasion, Bellsouth's
software has sent him to the error page even when he typed name
and password correctly. I did not see this demonstrated but have
no reason to doubt Grant's powers of observation. Now we're got valid
login credentials appearing in the browser's history file. This can't
be good.
Fixing this problem is not brain surgery (as the rocket scientists
like to say). Supply the login data via POST instead of in the URL.
Make the target a CGI that redirects the user with a clean referrer.
If you must pass the login data in the URL, encrypt it.
Grant has emailed Bellsouth about the problem and has demonstrated it
to an agent's satisfaction over the phone. The ISP's uniform response
has been, effectively, "This is not all that serious a hole and we're
not going to do anything about it."
Are you a user of Bellsouth's Web email? Please send this article's URL
to your favorite support person there. Do you know anyone with a clue
who works at Bellsouth? Please ask them to get this fixed.
(Note that this new vulnerability is different than the one widely
reported at the
end
of 1998 and the
beginning
of 1999. As far as I can see these earlier reports were
separate outbreaks of recognizing the same security hole, inherited
from the Bigfoot Web email service that Bellsouth was using at the
time.)
Updated 2001-02-27, 11:02 pm:
A reader wrote that the problem appeared to have been fixed, at
least on certain Bellsouth servers. He noted that login sessions get
connected to the user's home server based on the login name. I
collected by hand a number of Bellsouth user names from
news.admin.net-abuse newsgroups
in Google's
Deja archive and tried logging in to Bellsouth's
generic Webmail login
page, supplying a bogus password in each case. For every
login name that was still valid -- I tested 32 in all -- I verified that
Bellsouth's error page still openly displays the username and the
failed password in the URL field. This is the case for
servers named webmail.X.bellsouth.net, where X is:
- atl (Atlanta, GA)
- mia (Miami, FL)
- rdu (Raleigh-Durham, NC)
- lig (Slidell, LA)
- bna (Nashville, TN)
- sdf (Louisville, KY)
- mco (Orlando, FL)
Updated 2001-02-28, 8:22 am:
David Grant adds:
In regard to the reader who thinks the problem may have been
partially corrected -- one observation I have made is that if you try
to login with an invalid password a second time without closing and
reopening the browser, the supplied username and password are not
exposed -- BellSouth's server responds as it should. But if you then
close and reopen the browser and try again, the problem occurs
again, at least the first time you try it. I've verified this
behavior on two different machines, though of course, I cannot
confirm that it is so with all browsers, OSes, etc.