This chapter is from the book
This chapter is from the book
This chapter is from the book
Hacking Other Machines
We have now pierced the eggshell. At this point, the objective is to fully "own" the network and take over everything else. To start with, we need to gather some more information on our target. For that we use a utility that enumerates information from a system over a null session. A null session is an anonymous connection (i.e., one made without any authentication). By default, some Windows systems give out more information than others over such a port. Of course, in this case, we run it against localhost, meaning that anonymous restrictions do not apply to us.
C:\warez>dumpinfo 127.0.0.1 The Administrator is: PYN-SQL\Administrator Users on PYN-SQL: RID 1000 PYN-SQL\TsInternetUser a User RID 1001 PYN-SQL\SQLDebugger a User Share Type Comment IPC$ Unknown Remote IPC ADMIN$ Special Remote Admin C$ Special Default share Administrators: PYN-SQL\Administrator PYN-DMZ\_ids PYN-DMZ\Domain Admins
From this, we learn that there is not much on this system. It looks rather like a default system. Before we proceed with using this information, however, let's figure out the lay of the land:
C:\warez>ipconfig /all
Windows 2000 IP Configuration
Host Name . . . . . . . . . . : PYN-SQL
Primary DNS Suffix . . . . . . : PYN-DMZ.LOCAL
Node Type . . . . . . . . . . : Mixed
IP Routing Enabled . . . . . . : No
WINS Proxy Enabled . . . . . . : No
DNS Suffix Search List . . . . : PYN-DMZ.LOCAL
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix .:
Description . . . . . . . . .: Intel 21140 Based
PCI Fast Ethernet
Adapter
Physical Address . . . . . . .: 00-03-FF-03-3E-F0
DHCP Enabled . . . . . . . . .: No
IP Address . . . . . . . . .: 172.17.0.3
Subnet Mask . . . . . . . . .: 255.255.255.0
Default Gateway . . . . . . .: 172.17.0.1
DNS Servers . . . . . . . . .: 172.17.0.2
This tells us our IP address as well as some other useful information about the target network. Notice that the host has a private address, so our connection must be going through a NAT router at 172.17.0.1.
The objective now is to further the compromise to other hosts. To do that, the attacker starts by looking for the easy exploits. Perhaps the simplest is to use shared service accounts, if present. Service accounts are used on Windows to start up service, typically when those services need to run as some nonsystem user, or when they need access to particular network resources. For instance, a service may be able to connect to a particular network share on a remote host, or may need to execute code under a specific user context. The easiest way to configure such a service on multiple systems is to create a single domain account and then configure all the systems to run the service with the same account. This means that if we find any services running in regular user accounts (as opposed to system accounts such as LocalSystem, NetworkService, and LocalService), it is a sucker bet that those accounts have privileges on multiple systems. Network backup solutions, for instance, are notorious for using a single domain admin account to run the backup client on every single machine in the domain.
To find out whether this is a viable vector, let's check who is running services on the database server. To do that, we use a tool designed for that purpose:
C:\warez>serviceuser \\PYN-SQL IDS PYN-DMZ\_ids
There is a domain account used for the IDS service; presumably the intrusion detection service.
dumpinfo also told us earlier that it was an administrator. If the attacker is really lucky, the account is also a domain admin and the game would be over here. However, in this case, it appears unlikely that it is a domain admin since the account was explicitly listed in the Administrators group. To understand how to exploit this, we must understand how Windows operates. Services are applications that run when the system boots. Just like any other process on the system, they must run under some user identity. When the service starts, the operating system (OS) authenticates the account used for the service and for that it needs a username and password. The username and password are stored by the service control manager in a location called the Local Security Authority (LSA) Secrets. The LSA Secrets are maintained by the LSA to hold certain sensitive information required for the operation of the system. This information includes items such as the computer account credentials, encryption keys, and service account credentials.
The LSA Secrets are encrypted on disk and decrypted by the OS when the machine boots. They are then held in clear text in the LSA process memory space while the system is running. If you can debug the LSA process, you can read that memory space. That may sound daunting, but there are attacker utilities designed specifically for that purpose. To debug the LSA process, a user must have the SeDebugPrivilege, which is granted by default only to Administrators.
Since Administrators can do whatever they want anyway, the ability to debug the LSA process is not a vulnerability in and of itself. They own the system without that privilege, and could grant any user that privilege. The vulnerability is operational and happens when untrusted users have that privilege.
In our case, we actually do not need to use the SeDebugPrivilege. Recall that our remote shell is running as LocalSystem. In other words, we are running as the same identity as the LSA process, and therefore have an intrinsic right to attach a debugger to it, privilege or not. Running the tool to extract the secrets, we find the following:
C:\warez>lsadump2 $MACHINE.ACC 13 FE 4C 3A 04 F8 1F 94 75 C8 9B 0B 1C 35 45 7A ..L:....u....5Ez 52 7E 25 DF F8 17 F2 96 3A 35 81 C7 R~%.....:5.. DefaultPassword DPAPI_SYSTEM 01 00 00 00 C8 AA F8 8C 36 C7 69 CC DD 42 CB 15 ........6.i..B.. 3F 4E 07 6D 48 05 0A 4C FE 31 87 C9 F2 58 A3 AD ?N.mH..L.1...X.. B7 AD 13 20 26 11 24 24 FF 79 AE D3 ... &.$$.y.. ... _SC_IDS 69 00 64 00 73 00 50 00 61 00 73 00 73 00 77 00 i.d.s.P.a.s.s.w. 64 00 21 00 d.!.
The output has been truncated to make it easier to read, but the really interesting piece is right at the end, where the service account credentials are listed. The column on the right holds the service account password. We now know that the password for the PYN\_ids account is idsPasswd! (The output is in Unicode, hence the dots in between characters, signifying nulls.) The only thing left now is to find out where to use it. Running DiscoverHosts we find that there are only two other machines on this subnet, 172.17.0.1 (the gateway) and 172.17.0.2 (the DNS server). We need to learn more about them:
C:\warez>dumpinfo 172.17.0.1 Unable to look up the local administrator Unable to enumerate users because I could not get the Admin Sid Share Type Comment IPC$ Unknown Remote IPC ADMIN$ Special Remote Admin wwwroot$ Disk C$ Special Default share Administrators: Unable to enumerate administrators ERROR: Access Denied
We are not getting much information on this system. That is because it is a Windows Server 2003 member server. On Windows Server 2003 standalone and member servers, null session users will only be able to list the shares on the system, but not the user accounts by default. It is possible to restrict it even further so that no information is available at all. To learn how, turn to Chapter 12.
What we can tell from dumpinfo is that the default gateway is running a Web server, based on the fact that it exposes a wwwroot$ share. Notice also that we get a list of all the so-called hidden shares (shares postfixed with a $). The $ sign is actually just a notification to the client side of the application programming interface (API) not to display this item. The dumpinfo tool is written specifically to ignore that convention and displays the item anyway.
It would also be helpful to find out what endpoints are exposed on this system. To do that, we turn once again to our port scanner:
C:\warez>portscan 172.17.0.1 Port 172.17.0.1:80 open Port 172.17.0.1:135 open Port 172.17.0.1:139 open Port 172.17.0.1:445 open Port 172.17.0.1:3389 open
This really does not tell us much that we did not know. If SMB had been blocked, dumpinfo would have failed. We also discover that the host is running Terminal Services, but that is quite common. Turning our attention to the other system on the network, we get the following:
C:\warez>dumpinfo 172.17.0.2 The Administrator is: PYN-DMZ\Administrator Users on PYN-DMZ-DC: RID 1000 PYN-DMZ\HelpServicesGroup an Alias RID 1001 PYN-DMZ\SUPPORT_388945a0 a User RID 1002 PYN-DMZ\TelnetClients an Alias RID 1003 PYN-DMZ\PYN-DMZ-DC$ a User RID 1104 PYN-DMZ\DnsAdmins an Alias RID 1105 PYN-DMZ\DnsUpdateProxy a Group RID 1106 PYN-DMZ\Alex a User RID 1107 PYN-DMZ\Bob a User RID 1108 PYN-DMZ\Cecil a User RID 1109 PYN-DMZ\Denise a User RID 1110 PYN-DMZ\Eric a User RID 1111 PYN-DMZ\Fred a User RID 1112 PYN-DMZ\George a User RID 1113 PYN-DMZ\Henry a User RID 1114 PYN-DMZ\Irene a User RID 1115 PYN-DMZ\Julie a User RID 1116 PYN-DMZ\Kurt a User RID 1117 PYN-DMZ\Laura a User RID 1118 PYN-DMZ\Maggie a User RID 1119 PYN-DMZ\Teddy a User RID 1120 PYN-DMZ\Mike a User RID 1121 PYN-DMZ\PYN-SQL$ a User RID 1122 PYN-DMZ\PYN-WEB$ a User RID 1123 PYN-DMZ\_IDS a User Share Type Comment IPC$ Unknown Remote IPC NETLOGON Disk Logon server share ADMIN$ Special Remote Admin SYSVOL Disk Logon server share C$ Special Default share Administrators: Unable to enumerate administrators ERROR: Access Denied
This is obviously more interesting. This machine must be a DC because the account domains are PYN-DMZ, but the host name is PYN-DMZ-DC. A member server or standalone would have matching hostnames and account domains. By default, Windows Server 2003 Domain Controllers allow anonymous users to get all this information to allow down-level compatibility with Windows NT 4.0 and Windows 9x. The only thing the attacker cannot get is the membership in the Administrators group. This information can be restricted, but honestly, it is not particularly critical. First, an attacker could easily get this information by performing the request using any domain account. Second, if the only thing standing between you and a compromised network is the list of users on your domain, you are in for a rough time. The user list should simply not be particularly sensitive, even though we normally do not want to just hand it out.
For completeness, we also do a port scan:
C:\warez>portscan 172.17.0.2 Port 172.17.0.2:53 open Port 172.17.0.2:135 open Port 172.17.0.2:139 open Port 172.17.0.2:389 open Port 172.17.0.2:445 open Port 172.17.0.2:3268 open
Our ports can tells us something interesting. Since port 3268 is listening, this must be a Global Catalog server for the forest. This means that 172.17.0.2 is a highly valuable target. Interestingly, this system does not have Terminal Services enabled.
We still do not know where the _ids account is used. To find out, we enumerate the user accounts used to run services on the various hosts:
C:\warez>serviceuser \\172.17.0.1 IDS PYN-DMZ\_ids
Serviceuser also runs anonymously, and we find out what we already suspected—the IDS service is used on the Web server as well, using the account we already have. That is all the information needed to take over that host as well:
C:\warez>net use \\172.17.0.1\c$ /u:pyn-dmz\_ids idsPasswd! The command completed successfully.
We have successfully taken over the Web server! This is shown in Figure 2-1b.
)
Figure 2-1b We have successfully compromised two machines.
Here is a summary of the operational practices that got us to this point:
- We have complete connectivity between the database server and the Web server; there is no internal traffic filtering. In Chapter 9, we cover a technique to analyze what kinds of traffic you do need to allow and what to restrict on your internal network.
- We were able to retrieve a lot of information about the targets on the network over anonymous connections. This is enabled for down-level compatibility and is often not necessary in up-to-date networks. In fact, we consider killing Windows 9x and NT 4.0 to be of great security benefit! Not only are those systems insecure in today's environment, they require you to render your up-level systems insecure, too. Chapter 12 covers this in more detail.
- There was a service account dependency between the database server and the Web server. A service account dependency is where a system is dependent for its security on another system through a shared service account. Shared service accounts are a prime target for attackers because, contrary to password cracking, there is no time lag in retrieving them. Chapter 8, "Security Dependencies," covers service account dependencies in more detail.