SWAT MAGAZINE ISSUE SIXTEEN: APRIL 1999 ============================================ NT SECUIRTY PAPER ============================================ Author : Netw0rk Bug E-Mail : bug@netw0rk.freeserve.co.uk Date : FEB-MARCH 1998 =============================================-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= First I would like to explain about Nt domains. So... first of all. he following M1crosoft products can share their resources in workgroups: Windows for Workgroups Windows 95/98 Windows NT Workstation Windows NT Server Organizations that are large or that want more control over their networks need something more than workgroups. Therefore, M1crosoft has incorporated the domain concept into Windows NT Server. ======= DOMAINS ======= Domains borrow concepts from workgroups and from directory services. Like workgroups, domains can be fairly informal and can be administered using a mix of central and local controls. Domains can evolve fairly easily and can be set up with less planning than typically is required for a directory. Like a directory, a domain organizes the resources of several servers into one administrative structure. Users are given logon privileges to a domain rather than to each individual server. Because a domain controls the resources of several servers, it is easier to administer than a network with many stand-alone servers. Servers within the domain advertise their services to users. Users who log on to a domain gain access to all resources in the domain for which they have been granted access. They can browse the resources in a domain much as they would browse the resources in a workgroup; however, domains are hosted by Windows NT Servers and can be made more secure than workgroups. When networks become large enough to require several domains, administrators can establish trust relationships among domains. Trust relationships simplify administration because a user is required to have an account in only one domain. Other domains that trust the user's logon domain can rely on the logon domain to authenticate the user's logon. Windows NT Server domains are not the same as domains found on TCP/IP networks. TCP/IP domains are discussed in Chapter 16, "Using TCP/IP." =============================== Domains and Trust Relationships =============================== Domains are essentially improved workgroups. Access to domain resources is controlled by a domain controller. The user is assigned a single domain account and a password that is used to control access to all domain resources. Windows NT Server domains also support the use of groups that enable administrators to assign and change permissions for large numbers of users more efficiently. You will learn about managing users and groups in Chapter 11, "Managing Users and Groups." ========================== Domains and Domain Servers ========================== A server in a domain has one of three roles: One Windows NT Server stores the master copy of the domain's user and group database. The PDC is responsible for synchronizing the account database with all BDCs. Other Windows NT Servers can store backup copies of the domain's user and group database. Servers can participate in a domain without being designated as primary or backup domain controllers. Each of these roles is described more fully in the following sections. ============================= The Primary Domain Controller ============================= The first Windows NT Server in the domain is configured as a primary domain controller (PDC). The User Manager for Domains utility is used to maintain user and group information for the domain. This information is stored in a domain security database on the primary domain controller. ========================= Backup Domain Controllers ========================= Other Windows NT Servers in the domain can serve as backup domain controllers (BDC). Each backup domain controller stores a replica of the database on the primary domain controller, which is replicated periodically to distribute changes made to the main database on the PDC. Replication of the database has several advantages. If the primary domain controller experiences a hardware failure, one of the backup domain controllers can be promoted to the primary role. Having one or more backup domain controllers builds a degree of fault tolerance into your network. Each domain should have at least one BDC. Backup domain controllers also can participate in the logon process. When a user logs on to a domain, the logon request can be handled by any primary or backup domain controller. This spreads the logon processing load across the available servers and improves logon performance. This can be an important benefit in domains with large numbers of users. Changes cannot be made to the domain database unless the PDC is functioning. If the PDC fails or is shut down for maintenance, you can promote a BDC to function as the PDC. Although the PDC is required to make changes to the domain database, other domain operations are not dependent on the PDC. Users can log on to the domain using a BDC if the PDC is unavailable. ======= Servers ======= Computers running Windows NT Server can also function as independent or stand-alone servers, which may or may not participate in domains. The term servers represents member server or stand-alone server. These servers do not function as primary or backup domain controllers. They can take advantage of the user and group databases, however, that are maintained for a domain, and you can assign user and group permissions for the server using the User Manager for Domains. The server also can maintain its own database of users, and users can log on to the server independently of the domain. When this is done, the server cannot utilize the user and group database of a domain, and the server handles accounts much like computers running Windows NT Workstation. You might choose to configure a stand-alone Windows NT Member Server for several reasons: The server can be administered by different staff members. Many Windows NT Servers are used for application servers, such as SQL databases. If you configure a database server as an independent server, you can assign a member of your database staff as the server administrator. Attending to logon requests can use a significant part of a server's processing capability. If you configure the server as an independent server, it can concentrate on servicing a single function, such as providing application services. When a server is functioning as a primary or backup domain controller, it is difficult to move the server to a new domain. If there is a chance the server will move to a different domain, configure it as an independent server. ============= Domain Models ============= Proper use of trust relationships enables organizations to build enterprise networks that still require only a single logon procedure for resource access. Windows has defined four models for domain trust relationships. If you are configuring a multi-domain network, you will want to consider the merits and disadvantages of each model. There are two reasons for adding domains: For organizational reasons To improve network performance Regarding network performance, you will find that Microsoft's descriptions are a bit vague. You can use a single domain model, for example, "if your network doesn't have too many users..." That doesn't give you much help during the planning stages. Unfortunately, there are many variables, and it is difficult to come up with a simple prescription for adding domains. W1nd0wz NT Server can, after all, run on everything from an Intel 80486 PC to a multiprocessor RISC system. Such a broad range of hardware makes performance generalizations difficult. Fortunately, W1nd0wz NT Server domains make it easy to reorganize the LAN as it grows. The four domain models defined by microsoft follow: Single domain Master domain Multiple-master domains Complete trust A single domain network has several advantages: It is easier to manage because resources are centralized. No trust relationships are required. Group definitions are simpler. You need to consider a multi-domain model in the following situations: If browsing is slow If too many users are degrading performance If your organization wants to assign domains to departments If you want to have some resources in their own domains ======================= The Master Domain Model ======================= The master domain model designates one domain to manage all user accounts. The master domain also supports global groups. Global groups can export group information to other domains. By defining global groups in the master domain, other domains can import the group information easily The master domain is named Keystone, and is managed centrally by the MIS staff. All users are defined in Keystone, as well as some groups that will make administration easier. Only the primary and backup domain controllers in the Keystone domain are used to store user and group account information. Because users cannot log on to the network without a working domain account database, a master domain always should include at least one backup domain controller in addition to the primary domain controller When users log on to the network, they always log on to the Keystone master domain. After they have logged on, they can access resources in other domains that trust Keystone ================================ The Multiple Master Domain Model ================================ Each master domain supports about half the user accounts. This spreads the processing of logons over several domains. Each domain supports some of the groups that are accessed by the department domains. Under this model, each master domain trusts every other master domain. This is a convenience for administrators, but is necessary for users only if they actually will be using resources on one of the master domains, which is not ordinarily the case. To reduce the likelihood of security holes, only administrators should be given permissions to access resources in the master domains. Users should be given permissions only in the department domains. Each department domain trusts each master domain. It is not necessary for department domains to trust each other Because users are granted most privileges based on their memberships in master domain groups, it is a good idea to group related users into the same master domains. All your users in Accounting should log on to the same master domain, for example. Otherwise, you are forced to establish similar groups in each master domain. With more groups, it becomes far more difficult to establish privileges in the department domains The multiple master domain model has many desirable features: It is scalable to any organizational size. Security is managed centrally. Departments can manage their local domains, if desired. Related users, groups, and resources can be grouped logically into domains. Disadvantages of the multiple master domain model include the following characteristics: The number of groups and trust relationships multiply rapidly as the number of domains increases. User accounts and groups are not located in a single location, complicating network documentation. ======================== The Complete Trust Model ======================== The master domain models assume that a central department exists that can take responsibility for managing user and group security for the complete organization In the complete trust model, every domain is configured to trust every other domain. Users log in to their department domains and then access resources in other departments by means of trust relationships. As with the multiple master domain model, the number of trust relationships required increases rapidly as domains increase. Three domains require six trust relationships (two between each pair of domains), whereas five domains require 20 trust relationships. If n is the number of domains, then the network requires n ¥(n-1) trust relationships If your organization does not have a central MIS department, networking is a great reason for establishing one. Besides the need to maintain tight security, several other functions are best when centralized. Here are some examples: File backup Communications services E-mail maintenance Management of the network infrastructure (media, hubs, and so on) Few departments have personnel who possess the expertise to do these jobs well. Also, network management in a large organization calls for personnel who are devoted completely to the task. Therefore, I don't put much credibility into the advantages that Microsoft attributes to the complete trust model, but here they are nevertheless: No central MIS department is required. The model scales to any organizational size. Departments retain control of their users and resources. (But, it can be argued, they surrender that control by trusting everybody.) Users and resources are grouped logically by departments ========================== Estimating Domain Capacity ========================== All the issues come down to the size of the file that is used to store the Security Accounts Manager (SAM) domain database. The size of the SAM database file matters because the entire database is made resident in a domain controller's RAM. Large SAM databases have two effects: they hog a lot of the domain controller's RAM, and they take a long time to load, prolonging the process of booting the computer. Three types of objects are stored in the SAM domain database: · User accounts use 1,024 bytes (1 KB) each. · Computer accounts use 512 bytes (0.5 KB) each (only W1nd0wz NT computers require computer accounts). · Global group accounts use 512 bytes plus 12 bytes per users. · Local group accounts use 512 bytes plus 36 bytes per user. Assume that you have 1,000 users and 500 NT computers that require accounts. To organize the domain, you require 10 global groups with an average membership of 200 users. You also require 10 local groups with an average membership of 20. How large a SAM database would that generate? 1,000 users ¥ 1,024 bytes=1,024,000 bytes 512 computer accounts ¥ 512 bytes=262,144 bytes 10 global groups ¥ 512 bytes=5,120 bytes 2,000 global group members ¥ 12 bytes=24,000 bytes 10 local groups ¥ 512 bytes=5,120 bytes 200 local group members ¥ 36 bytes=7,200 bytes Total SAM database size=1,324,589 bytes The total size of the SAM database would be approximately 1.5 MB. That's not particularly large as SAM databases go, and you can easily support this network in a single domain. Depending on its processing power and on the services it provides, a domain controller can support between 2,000 and 5,000 users. A domain with 26,000 users, therefore, might require from 6 to 13 domain controllers to ensure adequate performance ============================================= Now Let US do some NT Administration GOAL ONE: ============================================= Gain Access to the SAM Users can gain access to the SAM and Security hives in several ways. Microsoft says the best way to protect your NT systems is to protect the administrator accounts, but administrators are not the only users who can access the SAM and Security hives. Server operators, backup operators, and even ordinary domain users can view and dump hash codes from the Registry. Protecting administrator accounts is not enough. By default, no user has the proper permissions to access or even view the NT SAM. However, the SAM and Security hives are like other files. Users who have permission to copy the Registry files--such as users who might have to back up the Registry--can copy and manipulate these files on a whim. If you log on as a backup operator, however, you can't just copy the SAM and Security hives. The Registry is open while NT is running, and a sharing violation occurs when you attempt to copy the files. However, the Regback utility on the W1nd0wz NT resource kit CD-ROMs lets anyone in the administrator, server operator, or backup operator local groups copy the open Registry. The list of potentially dangerous users, however, includes more than these three groups. Regular domain users can invade NT security if NT is on a FAT volume and they have permission to restart the machine. All they have to do is boot to DOS, copy the SAM and Security hives from the %SystemRoot%\System32\ config directory, and they're in business. In general, if NT is on an NTFS volume, domain users can't boot DOS and copy the hives. But NTFSDOS, a utility written by Mark Russinovich and Bryce Cogswell, lets users mount the NTFS volumes in DOS. (Mark Russinovich and Bryce Cogswell present one view of NTFSDOS and Joel Sloss another view in point and counterpoint articles in the September 1996 issue.) Run NTFSDOS, go to the %SystemRoot%\System32\config directory, and copy the hives. Microsoft says that true security is physical security. Following Microsoft's advice, lock the machines away, and remove ordinary users' permissions to restart the computers. If users can't restart the machines, the possibility of rebooting to DOS on a FAT volume or using NTFSDOS is no longer a threat. Is NT secure now? Ordinary domain users can't copy the open Registry because the action will cause a sharing violation. Nor can users back up the system because they don't have permissions associated with administrator, server operator, or backup operator accounts. But a fundamental feature of NT's built-in availability is the Repair directory. After a successful installation and each time you run the Rdisk utility, NT stores a backup of the Registry in %SystemRoot%\Repair. The backup files aren't open, and users can easily copy them if they can log on locally or if the directory is shared. By default, the NTFS permissions don't protect the Repair directory. All users have read control, and read control offers enough permission to copy files. For ordinary users to obtain the SAM hive that contains passwords, they must access the current version of the Registry. The Registry is vulnerable in at least two ways. First, even though NT doesn't back up the Security and SAM hives by default when you run Rdisk, a copy of the SAM from the original NT installation remains in the Repair directory. If the administrator has not changed the administrative password since the original installation, the password is at risk. Second, many administrators use the rdisk /s command, which includes the Security and SAM hives in a backup to an unprotected Repair directory (for more information about the Rdisk utility, see Michael D. Reilly, "The Emergency Repair Disk," January 1997). In summary, here's how you can prevent an ordinary domain user from gaining access to the SAM and Security hives on your servers: * Don't permit local logon to servers. * Use NTFS volumes instead of FAT volumes. * Physically secure the servers. * Change the default permissions of the Repair directory. * Secure your Emergency Repair Disks and tape backups. Remember, users can still access their local machine's Registry through the Repair directory or an Emergency Repair Disk and attempt to crack the local machine's administrator password. One way to prevent this attack is to convert to NTFS and set more restrictive permissions on each workstation's Repair folder. GOAL TWO: Dump the Hash Codes Even after users have copies of the SAM and Security hives, they can't easily view hash codes. They have to log on to an NT machine as Administrator and dump the hash codes with PWDUMP. If they manually copy both Registry files into their own Registry, NT will use the hijacked SAM. Although users don't have administrative privileges at work, they are administrators on their home PC. From their home PC, they can dump the hash codes and, at their leisure, perform as many dictionary attacks as they need to find the passwords. To copy the hijacked SAM to a local Registry when NT is on a FAT volume, users just boot to DOS and copy the file. If NT is on an NTFS volume, users can use Regrest, another utility on the resource kit CD-ROMs. However, the hives in the Repair directory or from an Emergency Repair Disk are compressed, and a compressed Registry doesn't work in NT. But the compression algorithm isn't difficult; you can easily uncompress those files with the Expand command in %SystemRoot%\System32. If users replace the SAM and attempt to log on as the hijacked Administrator, they overwrite their personal administrative password and don't know the new stolen password. However, the utility NT Locksmith, available at http://www.winternals.com, lets you change the local administrator password. Running this utility requires physical access to the NT machine. Most people do not have physical access to servers at work, but they have access to their home PC. After users change the password, they can log on locally and dump the hash codes from the hijacked SAM. GOAL THREE: Crack NT's Passwords Once users have the hash codes, they can use NT Crack, L0phtCrack, or a similar utility to perform a dictionary attack against NT.The outcome of the password crack depends on the quality of the wordlist, or dictionary, hackers use to perform the crack. The more words, dates, numbers, and wordplays that are in the list--and the more complex they are--the better the chance for a successful crack. Therefore, a good password security policy greatly reduces the likelihood of a successful crack. For good password security, you can prohibit blank passwords and require a certain password length, for example a six-character minimum. Require complex passwords, usually a random selection of letters and numbers. NT's User Manager won't let you force complex passwords. However, you can set all your users' passwords manually and not let users change them. Now Let US have Fon with da SID. Originally this was found by David LeBlanc and Dominique Brezinski. Evgenii Borisovich Rudnyi pointed this out again.He wrote two utilities, user2sid and sid2user, which are actually command line interfaces to WIN32 functions, LookupAccountName and LookupAccountSid. So, no hacking, just what is permitted by MS. Now, it happens that to use these function a user have just to be EVERYONE. It means that an ordinary user can find without a problem a built-in domain administrator name, which MS recommends us to rename from administrator to something else (see for example, course 803, Administrating W1nd0wz NT 4.0). Assuming that user's computer is in the domain, the task is solved by two steps. 1) Looking up a SID of any domain account, for example Domain Users user2sid "domain users" S-1-5-21-201642981-56263093-24269216-513 Now we know all the subauthorities for the current domain. All the domain account SIDs are different by the last number only (so called RID). 2) Looking up an built-in administrator name (RID is always 500) sid2user 5 21 201642981 56263093 24269216 500 Name is SmallUser Domain is DomainName Type of SID is SidTypeUser Now it is possible to look up all the domain accounts from the very first one (RID = 1000 for the first account, 1001 for the second and so on, RIDs are never used again for the current installation). sid2user 5 21 201642981 56263093 24269216 1000 sid2user 5 21 201642981 56263093 24269216 1001 ... It should be interesting for everyone to know the history of developing the domain account database. Well, this is not the end of the story. The anonymous logon is also in the EVERYONE group. This means that actually it is possible to find out who is a built-in administrator and to see the history of the SAM at any domain into which you can run the anonymous session. Note that anonymous sessions are not audited by logon/logoff category. Below is an example of what you can learn provided the netbios ports are open (the listing is fictional). nslookup www.xyz.com Non-authoritative answer: Name: www.xyz.com Address: 131.107.2.200 net use \\131.107.2.200\ipc$ "" /user:"" The command completed successfully. user2sid \\131.107.2.200 "domain users" S-1-5-21-201642981-56263093-24269216-513 Number of subauthorities is 5 Domain is XYZ_domain Length of SID in memory is 28 bytes Type of SID is SidTypeGroup sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 500 Name is XYZAdmin Domain is XYZ_domain Type of SID is SidTypeUser sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 1000 Name is Domain is XYZ_domain Type of SID is SidTypeDeletedAccount sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 1001 Name is Simpson Domain is XYZ_domain Type of SID is SidTypeUser sid2user \\131.107.2.200 5 21 201642981 56263093 24269216 1112 LookupSidName failed - no such account For those who would like to try it, the utilities can be found at: http://www.ntbugtraq.com and follow the links to the new downloads page where you'll find his usage page with a link to the zip. SOLUTION SP3 does not prevent this to happen. At this time, there is no fix for this, except to filter connections to port 139. So, at the moment, if you can get a null session, you can dump all the users, groups, and machine accounts. Linkz and Ulilities Needed? Well, most of them can be found On Target Security http://www.predator.force9.co.uk BUGTRAG Archive > http://www.geek-girl.com/bugtraq/search.html C2MYAZZ SMB Downgrade When a Microsoft networking client creates a new connection to an NT Server, it is possible for another computer on the same physical network to `spoof' the Microsoft client into sending a clear-text password to the NT Server, bypassing all password encryption and allowing the client's clear-text password to be discovered by any other device on the same physical network. his program actually runs on a W1nd0wz based system loaded with Novell ODI style drivers running in promiscuous mode. Once active, the software listens for SMB negotiations, and upon detecting one, the software sends a single packet to the client instructing it to downgrade its connection attempt to a clear text level - at which point the client silently obeys by sending its password in clear readable text. Once this happens this little piece of software actually grabs the password as it travels over the wire and displays it on the screen. The client is successfully connected to the NT Server, and the user remains none-the-wiser that its password has just been grabbed GETADMIN Getadmin.exe works because of a problem in a low-level kernel routine that causes a global flag to be set which allows calls to NtOpenProcessToken to succeed regardless of the current users permissions. This in turn allows a user to attach to any process running on the system, including a process running in the system's security context, such as WinLogon. Once attached to such a process, a thread can be started in the security context of the process. In the specific case of GetAdmin, it attaches to the WinLogon process, which is running in the system's security context, and makes standard API calls that add the specified user to the administrators group. It is important to note that any account which has been granted the rights to "Debug Programs" will always be able to run Getadmin.exe successfully, even after the application of the hotfix. This is because the "Debug Programs" right allows a user to attach to any process. The "Debug Programs" right is initially granted to Administrators and should be only granted to fully trusted users. Also, if Getadmin.exe is run with an account that is already a member of the administrators local group, it will still work (even after applying the hotfix). This is by design. Members of the administrators group always have the rights to make the calls GetAdmin needs in order to succeed SECHOLE Sechole.exe allows a non-administrative user to gain debug-level access on a system process. Using this utility, the non-administrative user is able to run some code in the system security context and thereby grant himself for herself local administrative privileges on the system. Sechole.exe locates the memory address of a particular API function (OpenProcess) and modifies the instructions at that address in a running image of the exploit program on the local system. Sechole.exe requests debug rights that gives it elevated privileges. The request is successful because the access check for this right is expected to be done in the API that was successfully modified by the exploit program. Sechole.exe can now add the user who invoked Sechole.exe to the local Administrators group NTFSDOS v2.0 Allows you to boot a DOS diskette and READ an NTFS Partition Linux NTFS Driver NT secured filesystem (NTFS) can be read from Linux, bypassing filesystem security