Anche questa guida dovrebbe insegnare la penetrazione in un sistema Win NT. Difatti mostra diversi strumenti che si possono usare per l'analisi di un sistema e cosa si può evitare per mantenere sicuro un sistema.
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.
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.
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.
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.
Switches -a Lists the remote computer's name table given its host name.
the last byte of the name converted into hex.
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.
Idle The remote computer has been opened in the current session, but is currently not accepting connections.
Reconnecting If your connection failed on the first attempt, it will display this state as it tries to reconnect.
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).
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.
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.
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.
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.
The computer \\SPUPPY is a domain controller of DOMAIN4.
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.
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.
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.
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.
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.
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.
00000020 DD 91 00 6E 04 44 F6 1E 84 D6 00 32 51 EB 50 18 ...n.D.....2Q.P.
00000040 72 64 20 72 65 71 75 69 72 65 64 20 66 6F 72 20 rd.required.for.
00000000 98 ED A1 00 01 01 00 01 70 4C 67 80 08 00 45 00 ........pLg...E.
00000020 C0 53 04 44 00 6E 00 32 51 EB F6 1E 84 F8 50 18 .S.D.n.2Q.....P.
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.
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 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 .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.
3) IIS Web server maps .bat and .cmd extensions to cmd.exe.
1) IIS Web server allows a hacker to execute his "batch file"
single command can be executed.
COMMAND[N], nothing will be logged by IIS Web server.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The server will then be more than happy to execute the file for the visitor of the site.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Now we know all the subauthorities for the current domain. Domain accounts only differ by the last number of the SID, called a RID.
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).
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).
net use \\131.107.2.200\ipc$ "" /user:""
/_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_log/author.log If author.log is there it will need to be cleaned to cover an intruders tracks.
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.
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.