-------------------------------------------[ 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:
SMBs allow for remote access to:
-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
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
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.