370 likes | 390 Views
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.
E N D
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)
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 ;)
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
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