Embed Size (px)
Citation preview
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 [email protected]• mailing list at [email protected]• mailing list at [email protected]• [email protected]
