Dominique

521 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
521
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dominique

  1. 1. Securing New Technology Dominique Brezinski
  2. 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. 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. 4. Who is in Attendance? • Security Auditors? • System Administrators? • Developers? • Others?
  5. 5. Agenda • Some specifics of the NT security architecture • Failings from a security perspective • Securing your NT systems • Assessing your security practices
  6. 6. NT security Architecture • Console Logon Process • Network Logon Process • Object Access • Impersonation
  7. 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. 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. 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. 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. 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. 12. Vulnerabilities and Exploits
  13. 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. 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. 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. 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. 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. 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. 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. 20. Securing it
  21. 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. 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. 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. 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. 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. 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. 27. Assessing Your Security
  28. 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. 29. More Tools • DumpAcl • Cacls • Regedt32 • Poledit • Caffiene
  30. 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. 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. 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. 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. 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. 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. 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. 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

×