ActiveFax Version 3.81 ftp bounce vulnerability

Vendor actfax.com: was notified in jun 2004 and has acknowledge the vulnerability.
Vendor has not mentioned this in there release notes.

About ActiveFax:
ActFax has been designed for network-wide transmission and receipt of fax messages, as well as sending and forwarding fax messages by email. The software runs on any Windows version from Windows 95 or higher and also supports terminal servers. Due to the client/server architecture of ActFax, all data is stored centralized on the fax server. 

Affected version(s): 3.81 perhaps early versions also but that has not been tested.

The program is running a server on port 21 by default, emulating partly an real ftp server. 

This server running on port 21 is prone to ftp bounce attacks as described in Phrack mag. Issue 51.
Only the port scanning technique is working on ActiveFax 3.81.

- FTP bounce attack : An interesting "feature" of the ftp protocol (RFC 959) is
support for "proxy" ftp connections.  In other words, I should be able to
connect from evil.com to the FTP server-PI (protocol interpreter) of target.com
to establish the control communication connection.  Then I should be able to
request that the server-PI initiate an active server-DTP (data transfer
process) to send a file ANYWHERE on the internet!  Presumably to a User-DTP,
although the RFC specifically states that asking one server to send a file to
another is OK.  Now this may have worked well in 1985 when the RFC was just
written.  But nowadays, we can't have people hijacking ftp servers and
requesting that data be spit out to arbitrary points on the internet.  As
*Hobbit* wrote back in 1995, this protocol flaw "can be used to post virtually
untraceable mail and news, hammer on servers at various sites, fill up disks,
try to hop firewalls, and generally be annoying and hard to track down at the
same time."  What we will exploit this for is to (surprise, surprise) scan TCP
ports from a "proxy" ftp server.  Thus you could connect to an ftp server
behind a firewall, and then scan ports that are more likely to be blocked (139
is a good one).  If the ftp server allows reading from and writing to a
directory (such as /incoming), you can send arbitrary data to ports that you do
find open.

For port scanning, our technique is to use the PORT command to declare that
our passive "User-DTP" is listening on the target box at a certain port number.
 Then we try to LIST the current directory, and the result is sent over the
Server-DTP channel.  If our target host is listening on the specified port, the
transfer will be successful (generating a 150 and a 226 response).  Otherwise
we will get "425 Can't build data connection: Connection refused."  Then we
issue another PORT command to try the next port on the target host.  The
advantages to this approach are obvious (harder to trace, potential to bypass
firewalls).  The main disadvantages are that it is slow, and that some FTP
servers have finally got a clue and disabled the proxy "feature".