-------------------------------------------[ The Windows NT BlackPaper -------------------------------------------[ By Neon Surge -------------------------------------------[ for Shatter Inc. %% This file is meant for educational and informational purposses only. This file is not a "How To" guide, any unlawful use of this file or the information within this file is not the fault of Neon Surge, Shatter Inc., or the fault of any owner and/or operator of an internet site and/or webpage where the file may reside. %% Lets jump right in. For those of you who are not riggers (architecture/network media specialists) let me begin by saying that NT as an operating system is fairly safe and secure. Now you may think to yourself that it isnt, but think about all the Unix related security holes you know of, a ton huh? Anyhow, as with any operating system, NT has holes, lets see what we can learn about these holes, shall we? First things first, NT does not support alot of the normal TCP/IP functions that youre used to. NT does not normally support NFS, SunRPC, NIS, r* commands, Telnet, and some other obscure ones. In order for NT to allow for various system services to be performed on a remote computer, it uses RPC, remote procedure calls. Please do not confuse this with SunRPC. You can run NT/RPC's over a NetBIOS/SMB session or you can piggie back it directly off of TCP/IP (or other transport protocol, perhaps NWLink IPX/SPX). Unfortunately we dont have any good documentation on what inherent services NT provides through native RPC. Complex server type programs (Like Exchange) provide their own RPC services in addition to the ones NT provides as an operating system --(TCP Port 135 is used as a port-mapper port, we also know that if too much information is fed through port 135, you can crash an NT box.). Some client software must access TCP port 135 before accessing the RPC service itself (hint, hint). Keep in mind that TCP port 135 can be blocked. Bummer, eh? One problem among the Hacker community is that most hackers dont like to investigate new avenues, or explore new methods. They will take the easy way out, using a method thats already been documented by someone else. So what if they come across a system that has patched that security problem? Will todays hacker try to find a new way in? Nope... most of the slackers I know will give up. It is for this reason that alot of the members in the community have never heard of SMBs, because its a session level protocol that is not a Unix standard (although there is something somewhat like SMBs for Unix, known as Samba). SMBs are used by Windows 3.X, Win95, WintNT and OS/2. The one thing to remember about SMBs is that it allows for remote access to shared directories, the registry, and other system services. Which makes it important in our line of, uuuhh, work. As stated above, unfortunately, there is no good documentation of the services that use SMBs. Now, a couple of Key Points: SMBs are used by: -Win 3.X -Win 95 -Win NT -OS/2 SMBs allow for remote access to: -Shared directories -The Registry -Other system services You will find that by default all accounts in NT have complete SMB functionality. This includes the Guest account. (In WinNT 3.51, the guest is auto created and active, in WinNT 4.0, the guest account is auto created but is not active) Now, 2 things to remember: When it comes to login attempt failures, the administrator account IS NEVER locked out after a certain number of login attempts (this rule ALWAYS applies), also by default, when windows NT is installed, NONE of the accounts have fail login attempt lock out. Also, in order for SMB to work, UDP/TCP ports 137,138,139 (NetBIOS over TCP) must be open. ---A word about Remote registry alteration: By default the Everyone group in NT has write access to much of the registry. In NT 3.51, this was a major issue due to the remote registry access feature of RegEdit. Any user could manipulate the registry on any server or workstation on which his account (or the guest account) was enabled. WindowsNT fixed the problem with this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipesServers\winreg Now, true, remote registry editing is not allowed in NT4, but this rule does not apply to Administrator (or perhaps other users in the Administrators group.. ::grin::). Ok, so far we've covered some pretty good information, but lets go into that new product that microsoft loves so much. The product they really hyped.. NTFS (NewTechnologiesFileSystem). First of all, NTFS is a rip off of the OS/2 file system, HPFS. No biggie, lets not get pickie. Anyhow, NTFS is actually a beautiful thing, if used properly. NTFS allows administrator to not only put access permissions on folders, but it also allows for access permissions on individual files within that folder. Example: Jane and Ralph both have access to the folder 'Shoes'. Theres only one file within the 'shoes' folder. Only jane has access to this one file, Ralph does not. So when Ralph opens the 'shoe' folder, it appears empty, but when Jane opens the 'shoe' folder, the file is there. Now, If an administrator does not set permissions on files within a folder but you know the exact path to the file, you can copy the file out of the folder onto a FAT (File Allocation Table) system, successfully bypassing the security. Example: The folder 'Shoes' has permissions on it. You do not have access permission to the folder, BUT if you typed: copy c:\shoes\secure.txt a:\ It would allow you to copy the file. Pretty neat huh? I have heard that the latest NT4 patches have corrected this problem, I will let ya know when I get a chance to test it out. File Sharing, I love those words. SMB file and print server protocols used by NT are harder to spoof than the NFS implementation on Unix systems. It is possible that a gateway (and I dont mean the brand name company) machine could spoof an SMB session, then read and write any files to which the true user of the session had access. -WARNING- This method is not for the beginner. Now, windows allows for this wonderful thing called User Profiles. This allows for users to have login scripts, personalized desktops, etc etc. Now some very personal information can be contained within these profiles. For example, some users put the userid and password that they use for Microsoft Mail onto their logon script, this way when they log into the machine, it auto logs them into their mailbox. User profiles are stored in the %SYSTEMROOT%\SYSTEM32\CONFIG directory and also on a shared directory on the server. Lets discuss our little friend, the special share. NT shares the %SYSTEMROOT%\SYSTEM32\REPL\IMPORT\SCRIPTS directory, this way, users can read their login scripts during login. Under normal default conditions, ANYONE can access this share and read anyone elses login script. So whatever juicy pieces of information are in the login script are now yours. Some other special shares are created depending on other software installed on NT or other servers that NT has to cooperate with. These other shares will probably be discussed in another BlackPaper. Getting lucky with that special account. There is a certain type of NT account that has the ability to BackUp and Restore database and account information. Accounts of this type have the ability to read, modify and write any file in the system. So, if ya cant get the Admin account, who knows... maybe theres a backup operator account. Ya never know.