[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
- read forum
- new topic
- search

- meetings list
- recent additions
- add your info
 top 100 sites
- visit top sites
- sign up now
- members

- add your url
- add domain
- search box
- link to us

- our projects
- free email
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : netaddress.com/usa.net email file theft and smurf

Title: netaddress.com/usa.net email file theft and smurf
Released by: Philip Stoev
Date: 12th December 2000
Printable version: Click here

Hash: SHA1

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.

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


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


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.

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


by 0005 MST"

The vendor reacted professionally and has set up a security alias

(security@usa.net) for reporting security incidents.


Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

Comment: www stoev org





(C) 1999-2000 All rights reserved.