- The document discusses securing Windows NT systems by reviewing the NT security architecture, known vulnerabilities, and methods for exploiting them. It provides guidance on hardening NT security through measures like reducing unnecessary services, restricting file and registry permissions, and enforcing stronger passwords. System administrators can assess their security posture using various scanning and auditing tools to detect vulnerabilities, non-compliant configurations, and potential security breaches.

1. Securing New Technology
Dominique Brezinski

2. Introduction
We all have a few questions about
Windows NT security:
• Is it really secure
• Should we be deploying Internet
connected Windows NT systems
• What are the current vulnerabilities in NT

3. Summary of Course
• Security vulnerabilities in the NT
architecture and implementation
• Methods for addressing the existing
and future security vulnerabilities
• Techniques and tools for assessing
security posture

4. Who is in Attendance?
• Security Auditors?
• System Administrators?
• Developers?
• Others?

5. Agenda
• Some specifics of the NT security
architecture
• Failings from a security perspective
• Securing your NT systems
• Assessing your security practices

6. NT security Architecture
• Console Logon Process
• Network Logon Process
• Object Access
• Impersonation

7. Console Logon Process
• Interact with the GINA to give credentials
• GINA is the extensible part of WinLogon
• WinLogon talks to Authentication
Packages through LSA (Local Security
Authority) using LogonUser()
• Current Authentication Package is
MSV1_0 (NT LM Security Provider)
• Authentication Package returns security
token if credentials are correct

8. Network Logon Process
• Make connection to Server Service (SMB)
• Server Service generates a MSV1_0
compatible challenge and sends it to the
client (in a SMB_COM_NEGPROT
message)
• Client responds by encrypting the
challenge, using the password as the
encryption key, and sending it back to the
server

9. Network Logon Process Cont.
• Server Service passes the client’s
response and the original challenge to
MSV1_0 by calling
LsaCallAuthenticationPackage() with the
message type MsV1_0Lm20Logon
• The LsaCallAuthenticationPackage()
returns a security token to the Server
service if everything is successful

10. Object Access
• Each object has a DACL (Discretionary
Access Control List)
• Each Process has a security token (from
logon process) attached which contains
the identity and privileges of the user
context it is executing under
• When a process attempts to access an
object, the Security Reference Monitor in
the kernel checks to see if the identity or
privileges in the token match an ACL entry

11. Impersonation
• Process obtains a security token for the
user to be impersonated through the
LogonUser() function or a direct call to a
authentication package with
LsaCallAuthenticationPackage()
• The process can use this token to
temporarily change the user context of a
thread to execute as the user
(impersonate)

12. Vulnerabilities and Exploits

13. Exploits
• Anonymous connections
• Network Authentication attacks
• Buffer overflows in privileged services
• Trojan horses and other file permission
abuses
• Privilege escalation through architectural
deficiencies

14. Anonymous Connections
• Created by using null credentials - net use
targetIPC$ ““ /user:””
• Prior to SP3 could remotely access the
Registry on workstations and some
servers
• Can enumerate users, groups, and get
SIDs
• Possibly other unknown ramifications

15. Network Authentication Attacks
• Man in the middle attack on authentication
sequence to gain remote access as
arbitrary user (fixed in SP3 if message
signing is used)
• Password hash grabbing attacks using a
known challenge (not fixed in SP3) or
brute-force
• Protocol downgrade attacks to obtain
plaintext password (fixed in SP3 by
default)

16. Buffer Overflows
• They can happen in NT
• WebSite 1.0 had a couple nifty CGI
programs that could be overflowed
• The egg (shell code) has been written and
published, so the hard work has been
done.
• Services running as SYSTEM or
Administrator are the primary targets

17. Trojan Horses and File
Permissions
• Targets: files (.exe, .dll, .reg) that will get
executed by a privileged user -
Administrator or System
• Extensible portions of the security system
are key easy targets - Notification
Packages, Password Filters, and GINAs all
run under the System context
• FPNWCLNT.DLL is a great example:
default Registry entry, but the DLL does
not exist on NT 4.0 Workstations.

18. File Permissions Cont.
• Group Everyone has write permission to
%SystemRoot%system32 by default, so
therefore any local user can add a
notification package Trojan called
FPNWCLNT.DLL that will get called in the
System context.
• Group Everyone has FULL CONTROL of
%SystemRoot% by default, so even files
like poledit.exe and explorer.exe which are
(RX) can be changed by anyone.

19. Privilege Escalation
• On July 4, GetAdmin was released on
Usenet.
• GetAdmin gains privilege to attach to
another process (SeDebugPrivilege)
through a broken kernel API and then
creates a thread in the Winlogon process
that executes code in GASYS.DLL which
adds an arbitrary user to the
Administrator’s group. Very naughty ;)

20. Securing it

21. Reduce Services
• Only services that are needed should be
running - everything else should be
disabled.
• NT needs the following services to be
started to function correctly: EventLog,
Plug and Play, and Remote Procedure Call
Service (TCP port 135 will be listening).
• Experiment - start with the above services
and only add as needed.

22. File Permissions
• Don’t give the Everyone group FULL
CONTROL of anything
• Check “Guidelines for securing Windows
NT-based networks and systems” on
www.microsoft.com
• %SystemRoot% and %SystemRoot
%system32 can be (RX) for non admin
users
• Removal of execute permission on all
executables not needed is a good thing

23. Registry Permissions
• Make sure
HKLMSYSTEMCurrentControlSetControl
SecurePipesServersWinreg exists and
only Administrators have permission to it
• Again, check “Guidelines for securing
Windows NT-based networks and
systems” on www.microsoft.com
• Use David LeBlanc’s suggestions in the
NT Security FAQ

24. General
• Use a password filter to enforce strong
passwords (PASSFILT.DLL from SP2 or
write your own)
• Use passprop.exe from the Resource Kit
to enable account lockout on
Administrator
• Disable Network Logons for administrator
equivalent accounts
• Turn on auditing for security events

25. Specific Fixes for Exploits
• Install SP3 and set the RestrictAnonymous
registry value
• Change the DACL of NTOSKRNL.EXE to
System and Administrator FULL
CONTROL and Everyone EXECUTE (temp
hack to fix GetAdmin - not long term)
• Remove FPNWCLNT from
HKLMSYSTEMCurrentControlSetControl
Lsa”Notification Packages”
• Use message signing NT to NT

26. More Fixes
• Use the TCP/IP Advanced Security
options to block all TCP and UDP
ports not being used - specifically
TCP 135 if not using remote RPC
• Disable the WINS TCP/IP binding
under the protocol tab and the
Server service if the machine is a
single purpose server - WWW, FTP

27. Assessing Your Security

28. Tools
• Your security policy
• ISS 4.31 for NT
• Ballista
• Kane Security Analyst
• NAT without #define SCANNER (see
*hobbit’s presentation)
• A good TCP and UDP port scanner
• The Resource Kit(s)
• Homebrew (C, TCL, Perl, etc.)

29. More Tools
• DumpAcl
• Cacls
• Regedt32
• Poledit
• Caffiene

30. Port Scanning
• Do a full TCP and UDP port scan
• Take note of all listening ports and
reference them against what you
would expect for the services the
machine is suppose to be running
• Common listening ports are TCP 135,
137, 138, 139, and several ephemeral
ports and UDP 135,137,138, and 139

31. Service Checks
• Tools like ISS, Ballista, and NAT are very
helpful
• Remember port 139 is used by many
services: file sharing and services using
RPC over named pipes
• Check for all known bugs
• Look for unknown or excessive services
• See what information can be obtained
through SNMP, netstat, RPC end-point
mapper, and remote Registry access

32. File Permission Checks
• Print out list of all users and groups
• Use a tool like DumpAcl or Cacls to print
out a list of all file and directory
permissions
• Use your security policy as the basis for
ACL checks
• Look for situation like directories with
FULL CONTROL granted to a group that
should not have access to some files
within the directory

33. Registry Permission Checks
• Use Regedt32 or DumpAcl to list ACLs for
HKEY_LOCAL_MACHINE and
HKEY_CLASSES_ROOT
• Again, use your security policy as a basis
for your checks
• Look for situations where users can read
or write sensitive keys and values
• The SNMP community name and
AutoLogon password are viewable by
everyone by default

34. Known Vulnerability Checks
• Check for all know vulnerabilities
• Look for potentially exploitable conditions
like the ability to overwrite executables
and dynamic link libraries
• Check for Registry keys and values
writeable by non-administrators - there are
several places by default that everyone
can change which can lead to Trojan
horses (.reg associations)

35. Policy Enforcement
• Is auditing enabled?
• Are password length and lifetime
checks enabled?
• Do users belong to the correct
groups?
• Kane Security Analyst is a good tool
for this stuff

36. Summary
• We have covered the basics of how
NT security operates, what some
major problems are, strategies to
tighten up security, and some
methods for checking your risks
• Experiment with this knowledge -
use it as a starting point and take
tangents

37. Where to get more information
• http://www.microsoft.com/workshop/prog/
security/guidesecnt.htm
• http://www.ntsecurity.net
• mailing list at ntsecurity@iss.net
• mailing list at ntbugtraq@rc.on.ca
• mailing list at bugtraq@netspace.org
• dominique.brezinski@cybersafe.com