Hacking other machines

The following excerpt is from Chapter 2 of "Protect Your Windows Network from Perimeter to Data" written by Jesper Johansson and Steve Riley. Click for the complete book excerpt series or purchase 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\AdministratorPYN-DMZ\_idsPYN-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-SQLIDS               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 administratorUnable to enumerate users because I could not get the AdminSid Share Type Comment IPC$ Unknown Remote IPC ADMIN$ Special Remote Admin wwwroot$ Disk C$ Special Default share Administrators:Unable to enumerate administratorsERROR: 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 administratorsERROR: 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 PYNDMZ- 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.1IDS                                 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. Click for the next excerpt in this series: Taking over the domain Click for the book excerpt series or visit Addison-Wesley to purchase the book.

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Vulnerabilities Scheduled security testing Ethical hacking Multiple new Sober variants spy on passwords Does your computer reboot when using PowerPoint? The 19 Deadly Sins of Software Security: Chapter 1, "Buffer Overruns" Buffer Overruns: Overview of the sin Buffer Overruns: Affected languages Buffer Overruns: The sin explained Buffer Overruns: Extra defensive measures Buffer Overruns: Other resources Authentication Reduce resistance to creating strong computer passwords Looking ahead to life without passwords Managing passwords and passphrases Security log data: Make the most of it Checklists: Harden access control settings Access control checklists Windows password management myths Protect desktop files and folders from inside snoops 10 tips in 10 minutes: Password policy considerations 7 tips in 7 minutes: Windows password creation Authentication Research Authentication Reduce resistance to creating strong computer passwords Looking ahead to life without passwords Setting 'log-on-to machines' in Active Directory Taking over the domain Managing passwords and passphrases Offline NT Password and Registry Editor Ultimate Boot CD Login Recovery John the Ripper Emergency Boot CD Authentication Research

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary