Securing New Technology
Dominique Brezinski
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
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
Who is in Attendance?
•
•
•
•
Security Auditors?
System Administrators?
Developers?
Others?
Agenda
• Some specifics of the NT security
architecture
• Failings from a security perspective
• Securing your NT systems
• Assessing your security practices
NT security Architecture
•
•
•
•
Console Logon Process
Network Logon Process
Object Access
Impersonation
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
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
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
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
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)
Vulnerabilities and Exploits
Exploits
•
•
•
•
Anonymous connections
Network Authentication attacks
Buffer overflows in privileged services
Trojan horses and other file permission
abuses
• Privilege escalation through architectural
deficiencies
Anonymous Connections
• Created by using null credentials - net use
\\target\IPC$ ““ /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
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)
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
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.
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.
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 ;)
Securing it
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.
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
Registry Permissions
• Make sure
HKLM\SYSTEM\CurrentControlSet\Control
\SecurePipesServers\Winreg 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
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
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
HKLM\SYSTEM\CurrentControlSet\Control
\Lsa\”Notification Packages”
• Use message signing NT to NT
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
Assessing Your Security
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.)
More Tools
•
•
•
•
•
DumpAcl
Cacls
Regedt32
Poledit
Caffiene
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
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
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
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
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)
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
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
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