netaddress.com/usa.net email file theft and smurf amplification

[Philip Stoev <philip () STOEV ORG>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

December 12th, 2000
www stoev org

Title: netaddress.com/usa.net email file theft and smurf
amplification

Synopsis:

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.

Vulnerable systems:

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
USA.NET):

http://webmail.netscape.com, http://www.apexmail.com,
http://www.farmbid.com, http://www.gopinoy.com,
https://secure.postoffice.net, http://www.register.com,
http://www.address.com, http://www.torchmail.com,
http://freemail.osite.com.br, http://www.acidclub.net,
http://www.acidclub.com, http://www.chamberpage.com

Details:

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

FileName=at.txt&localFilename=/smtp-relay/storage/attachments/NACGIDAA
02aIbq&ContentType=text/plain&attachmentNumber=0

1. This field value contains an absolute server path, so setting it
to

FileName=at.txt&localFilename=/etc/passwd&ContentType=text/plain&attac
hmentNumber=0

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.

Vendor status:

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
completed
by 0005 MST"

The vendor reacted professionally and has set up a security alias
(security () usa net) for reporting security incidents.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: www stoev org

iQA/AwUBOjVJZ1i4DH/L1CReEQIwHgCg2WH9e4M2q6zuTWkDv67DQwAlXoQAn1Ev
k0OkmOXh8qeQXwwz0+9XXCb3
=7AlP
-----END PGP SIGNATURE-----