I have a few comments here... > Ok...this one is a little better than the last one...technically speaking > but not very much of a threat if you think about it. While technically > sound (and full of neat tricks to get information which might otherwise be > gotten easier through other methods), it still doesn't mean much of a > threat. Hence the "medium" listing of severity in the advisory. > First of all (once again) you'd be hard pressed to find a router which will > allow SPX through. Even if the RCONSOLE session was over TCP/IP, you would > have to be running NetWare/IP in order to connect via Telnet (I > know...NetWare 5 is pure IP...save that for when everyone upgrades). If the XCONSOLE.NLM is running with the TCP/IP stack, you can telnet in and do either X or vt100 and have a remote session. This has been the case since Netware 3.x. > Second, even if you could capture the RCONSOLE password from a trace, you > would still have to go through the business of tracing through the "test" > server to find the unencrypted form of the password. Yes but this is still trivial to do, considering the price of Netware with a two user license. > Third, if you finally got access to the server from RCONSOLE (assuming > you're using this to dig up the NDS tree), you would have to transfer all of > the *.NDS files from the SYS: volume of the server. This is not possible > with RCONSOLE and you can't get at those files any other way (the OS > prevents access to that directory). 1. Load NETBASIC.NLM (included with NW 4.11 or greater). If you don't have it, use JCMD.NLM (which RCONSOLE will allow to be uploaded to the server). 2. If using NETBASIC, type SHELL. Now CD SYS:_NETWARE and copy the files to any location on the server you see fit. 3. Load FTPSERV.NLM for ftp access, or move the NDS files to SYS:LOGIN for easy anonymous retrieval if you have local network access. 4. If you have trouble moving the NDS files from their location in SYS:_NETWARE, run DSMAINT or DSREPAIR which creates a copy of the database in SYS:SYSTEM, then move the copy these utilities create. > Fourth, you wouldn't be able to create a new NDS tree with the files from > another server without calling NDS support at Novell and having them do a > DSDUMP. They would have to select the files you want to put back in as your > database and then do a bunch of db pruning/cleanup in order to make the > database workable. Probably more money than your average hacker is willing > to pay. 5. Use Pandora (http://www.nmrc.org/pandora/), freeware which has the tools to extract password hashes, and offline dictionary or brute force attack the hashes for passwords. It's much slower than L0phtcrack or Crack at cracking passwords (because of Novell's one way hash algorithm) but it gets the job done. > Of course, the more sophisticated person could write an NLM which would > delve into the database and dump stuff out for you. You could install this > from an RCONSOLE session (ie transfer the NLM somewhere on the server then > load it). But then again, NLMs aren't that easy to write and a snooper > would definitely draw attention to himself if he ABENDs a server remotely. The sophisticated Al Grant has already written such an NLM, I don't have the location handy. Al is at ag129at_private > My solution? If you must do RCONSOLE, run PPTP (Novell not MS) This way, > outside prying eyes can't see the RCONSOLE session. Oh...going through a > firewall would help too. BTW -- Novell's PPTP actually works; the MS > implementation is typical - misinterpret the spec, implement it halfway (and > poorly) thus leaving it full of holes. > > The ultimate solution, if you have a really sensitive server, is to not load > RCONSOLE and do SECURE CONSOLE. 100% agreement on not running RCONSOLE. Novell advises not to run it on critical servers, but since NDS is somewhat distributed I wouldn't use it at all. > I'm still waiting for BackOrifice for NetWare... We're working on it, or something at least as interesting... ;-) > [VENT MODE ON] > Why are people constantly trying to fabricate holes in NetWare? Is it so > others think that NetWare has just as many security holes as other OS's? > Pound-for-pound, NetWare is more secure than other OS's I've seen bandied > about on BUGTRAQ. If you find a bug/hole, fine but let's not try to make > one up, ok? > [VENT MODE OFF] Assuming you believe most polls, around 80% of attacks are internal. Therefore any SPX-based attack is "valid". A lot of shops that have Novell products also have Unix, NT, and even mainframes -- personally I would not want ANY system to be compromised as you will more than likely find similiar account names and passwords across systems. It should also be pointed out that while my reported "bug" was not a system compromising bug, it is in fact a security concern. Half the Unix bugs pointed out on this list require local access. This implies at least SOME threat of internal legit users, but I would venture to say that most of the regular readers of this forum can see exactly where the placement of said bug fits into an attack profile and will adjust systems and policy accordingly. For example, Netware's TCP stack does predictive sequence numbering (ISS' scanner picks this up). Is this knowledge system compromising? Maybe not, but it is something that administrators need to consider when securing and implementing system solutions. The biggest mistake is assuming that because Netware isn't discussed on Bugtraq that much means it's more secure. Basically any modern network OS can be made fairly secure, some quicker and easier than others, some more complete than others. How Netware fits into that scenario is in the eye of the beholder (and the hands of the administrator). Simple Nomad // "When viewed as a metaphor for the human thegnomeat_private // condition, the humble GNU C compiler www.nmrc.org // becomes an endless enigma."
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:18:59 PDT