This section deals with attacking Netware remotely.
The cheesy way is the way that will get you in, but it will be obvious to the server's admin that the server has been compromised. This technique works for 3.11.
Using NW-HACK.EXE, if the Supervisor is logged in NW-HACK does the following things. 1) The Supervisor password is changed to SUPER_HACKER, 2) every account on the server is made a supe equivalent, and 3) the sys admin is going to know very quickly something is wrong. What the admin will do is remove the supe rights from all accounts that are not supposed to have it and change the Supervisor password back. The only thing you can do is leave a backdoor for yourself (see the Backdoor section).
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 -
There is an undocumented API call that can be done, assuming you have the Netware SDK. Search through support.novell.com for a document called "Retrieving IP Interface Information". This info allows you to retrieve IP info on a Netware server. The document details exactly how to make the call.
Yes and no. No to 4.02 or higher. Here's the scoop on 4.0.
The version of LOGIN.EXE that shipped with 4.0 had a flaw that under the right conditions the account and password could be written to a swap file created by LOGIN.EXE. Once this occured, the file could be unerased and the account and password retrieved in plain text.
A couple of things might cause this. One, I'd check the rights for [PUBLIC], and secondly I'd check the USER_TEMPLATE id for excessive rights. The Write right to the ACL will allow you to do some interesting things, including making yourself Admin equivalent. For gaining equivalence to most anything else you need only Read and Compare.
The implication should be obvious, but I'll spell it out anyway. A backdoor can be made if an account is set up this way. Let's say you've created an account called TEST that has enough rights to do this kind of thing. Simply go in as the TEST account, make yourself Admin equivalent, do your thing, remove the Admin equivalent, and get the hell out. Neat and sweet.
I am unsure as to the conditions (if anyone knows, please forward me the info) but if your .PWL file is around 900 bytes versus 600 bytes, your workstation will log in without prompting you for a password. This bug was working as of December 1995, and I would think at this point patched via the latest service pack.
Two ways this can be abused -- on some systems generating the longer file you can simply make sure you generate a .PWL file with the target account name and reboot using that .PWL file.
The other way is to simply collect the .PWL file from an unattended workstation and boot using it.
Packet signatures works by using an intermediate step during the encrypted password login call, to calculate a 64-bit signature. This block is never transmitted over the wire, but it is used as the basis for a cryptographically strong signature ("secure hash") on the most important part of each NCP packet exchange.
A signed packet can indeed be taken as proof sufficient that the packet came from the claimed PC.
NCP Packet Signature is Novell's answer to the work of the folks in the Netherlands in hacking Netware. The idea behind it is to prevent forged packets and unauthorized Supervisor access. It is an add-on option in 3.11, but a part of the system with 3.12 and 4.x. Here are the signature levels at the client and server:
Packet Signature Option and meaning:
0 = Don't do packet signatures
1 = Do packet signatures if required
2 = Do packet signatures if you can but don't if the other end doesn't support them
3 = Require packet signatures
You can set the same settings at the workstation. The default for packet signatures is 1 at the server and client. If you wish to use a tool like HACK.EXE, try setting the signature level at 0 on the client by adding Signature Level=0 in the client's NET.CFG. If packet signatures are required at the server you won't even get logged in, but if you get logged in, hack away.
If you wish to change the signature level at the server, use a set command at the server console:
SET NCP PACKET SIGNATURE OPTION=2
As noted, the packet signature scheme only signs the important parts of NCP packets. Some NCP packets, including "fragmented" NCP packets, are not signed, and in some cases packet signature fucntions differently depending on the settings on the client. Also on Netware 4.x, a server attachs as an object in the connection list, and the packet signature on this does not work properly even if the server is set to Option 3. Details regarding these flaws can be found in a white paper by NMRC members Jitsu-Disk and Simple Nomad at http://www.nmrc.org/project/pandora/DOCS/NCP.TXT, and exploit code was released with Pandora v3.0 available from http://www.nmrc.org/project/pandora/download.html.
Top | Next: Netware Denial of Service | Previous: Netware Console Attacks | Table of Contents