|
|
04-1. Why can't I get through the 3.x server to another network via TCP/IP?
04-2. How can I boot my server without running STARTUP.NCF/AUTOEXEC.NCF?
04-3. How can I login without running the System Login Script?
04-4. How do I remotely reboot a Netware 3.x file server?
04-5. How can I abend a Netware server? And why?
04-6. What is interesting about Netware 4.x's licensing?
04-7. What is Newtare NFS aind is it secure?
04-8. Can sniffing packets help me break in?
04-9. What else can sniffing get me?
04-10. How can I check for weak passwords?
Section 04
Loading the TCPIP.NLM in a server with two cards does not mean that packets will be forwarded from one card to another. For packet forwarding to work, the AUTOEXEC.NCF file should have the line:
load tcpip forward=yes
For packets to go through the server, you must set up a "gateway=aa.bb.cc.dd" option on the workstation. This leaves routing up to the server. If you are writing hack tools, keep this in mind if they use IP. Some older routers may not recognize the Netware server as a router, so you may not have many options if your target is on the other side of one of these routers. Newer routers are Netware aware and will "find" your server as a router through RIP.
Netware 3.11 IP will only forward between two different subnets. Proxy Arp is currently not supported in Netware IP. Example:
123.45.6 & 123.45.7 with a mask of ff.ff.ff.00 will forward packets
123.45.6 & 231.45.7 with a mask of ff.ff.ff.00 will not
This way you do not waste precious time trying to cross an uncrossable river. Some admins use this to limit the flow of IP traffic.
For Netware 3.xx, use these command-line options:
SERVER -NS to skip STARTUP.NCF, and
SERVER -NA to skip AUTOEXEC.NCF
NetWare 2.x does not HAVE the files STARTUP.NCF and AUTOEXEC.NCF. Instead they hard-code all the information into NET$OS.EXE, so you will have to rebuild it to change anything.
Often an admin will try and prevent a user from getting to DOS or breaking out of the System Login Script to "control" the user. Here's to way to prevent that -
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 -
REMOVE DOS
DOWN
EXIT
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.
I'll answer the second question first. You may be testing your server as an administrator and wish to see how you are recovering from crashes. Or you may be a hacker and wish to cover your tracks VERY DRAMATICALLY. After all, if you are editing log files and they are going to look funny when you are done, a good crash might explain why things look so odd in the logs.
These are per itsme:
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 somekind 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.
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.
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.
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.
For a list of DOS-based sniffers, see the alt.2600/#hack FAQ. I personally prefer the Network General Sniffer ;-)
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?