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 %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 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 security/guidesecnt.htm mailing list at mailing list at mailing list at