|
COMMAND kernel SYSTEMS AFFECTED Windows NT/2000 PROBLEM 'Quimeras' found following. Local and remote execution of trojan programs in other user accounts included Administrator. As SDK says, when calling CreateProcess(), if the executable file name does not contain a directory path, the system searches for the executable file in the following sequence: - The directory from which the application loaded - The current directory for the parent process - Windows NT/2000: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32 - Windows NT/2000: The 16-bit Windows system directory. There is no Win32 function that obtains the path of this directory, but it is searched. The name of this directory is System. - The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. - The directories that are listed in the PATH environment variable. Let's think about explorer.exe, by default the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Shell has the value Explorer.exe. When a user logons the system launch explorer.exe. Does the system look in any directory before find it in C:\Winnt? YES !!! To demonstrate it copy cmd.exe to your system drive root (say C:\) and rename it to be explorer.exe then logoff and relogon. What happen? The system spawns a command console as the actual shell (cmd.exe renamed like explorer.exe). (To delete the trojan explorer run C:\Winnt\explorer.exe from the command console). If an ordinary user has write access on the system drive root directory (by default) it is very easy to exploit this issue, simply write a false explorer program that first launch a trojan program and second launch the real explorer, name it explorer.exe and copy it to the system drive root directory. Every time a user log on interactively, the trojan program will run with that user rigths, nothing to say if the user is in the Administrator group. For a demonstration xploit visit http://www.quimeras.com Could be this remotely exploitable? Yes, this could be remotely exploitable by an ordinary user at least in two ways. One of these is when the system drive root directory is accesible via a share, allowing a malicious user to put a false explorer.exe in it. The second way is more complex and needs the MS Telnet server running on the target computer (for an explanation of this case and demonstration exploit visit URL mentioned above). When the system starts a program that uses load-time dynamic linking, it uses the information in the file to locate the names of the required DLLs. The system then searches for the DLLs in the same sequence as with executables, so some system or applications especifics dlls could be also affected. It is easy to find more executables that could be supplanted, for example rundll32.exe. SOLUTION To workaround this vulnerability be sure that all executable file names in the registry are preceded by the appropiate path. You also can move a copy of real explorer.exe to the system drive root directory and give special rights on it. Allot of vulnerabilities/exploits will appear in the future based on this System behaviour when looking for EXEs and DLLs. Patch availability: - Microsoft Windows NT 4.0 Workstation, Windows NT 4.0 Server, and Windows NT 4.0 Server, Enterprise Edition: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23360 - Microsoft Windows NT 4.0 Server, Terminal Server Edition patches will be available soon. - Microsoft Windows 2000 Professional, Server, and Advanced Server: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=23359