||Home : Advisories : netaddress.com/usa.net email file theft and smurf|
||netaddress.com/usa.net email file theft and smurf
||12th December 2000
-----BEGIN PGP SIGNED MESSAGE-----
December 12th, 2000
www stoev org
Title: netaddress.com/usa.net email file theft and smurf
Any user of usa.net-powered email service can read any file on the
server, accessible to the web daemon and can flood other users with
large attachments without wasting bandwidth to upload them.
In my opinion, any web mail system, powered by USA.NET,
http://www.netaddress.com for sure.
Searching with altavista.com and google.com produced this list of
otherUSA.NET-powered web mail providers, however those have not been
checked, and may as well be not vulnerable (or not powered by
The Compose Message form of netaddress.com has five hidden form
fields named FileAttachment. When one attaches a message, one of this
form fields is set to something like
1. This field value contains an absolute server path, so setting it
gives us /etc/passwd of netaddress.com server.
2. One can have several FileName form fields set to the same value
and netaddress.com will happily attach and mail the contents of the
file several times (the FileName form fields in the form are five,
however this number is not the limit). The server will try to delete
the file after attaching it to the message, so the following two
vulnerability scenarios are possible:
a) The web interface can read and delete the file -- the file is sent
once (to the attacker), and then deleted from server. No good if this
is a critical file.
b) The web interface can read, but can not delete the file -- the
file is attached in full as many times as specified in the compose
message form, since deleting it after attaching it fails and it is
still available to be attached again in the same message (or, any
future message). This option allows us to mail a big file from the
server repeatedly to the victim without using much of our own
bandwidth -- we do not even need to upload the file on our own.
The vendor was contacted on Thu, 7 Dec 2000 23:16:43 +0200, and
replied as follows: "We duplicated your findings within thirty
minutes of initially reading your email to us and a fix was devised
within another hour. We chose to deploy this fix into production the
same evening, at 2209 MST. Testing of the newly released code was
by 0005 MST"
The vendor reacted professionally and has set up a security alias
(firstname.lastname@example.org) for reporting security incidents.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: www stoev org
-----END PGP SIGNATURE-----