Other Security Dependencies

Other Security Dependencies

There are other forms of security dependencies as well, some of which are mitigated in particular ways. For instance, any time a machine authenticates to another it may create a security dependency. To understand how, you need to understand an ordinary challenge-response transaction:

1.	Machine A connects to machine B.
2.	Machine B sends a challenge to machine A.
3.	Machine A computes the response to the challenge (for details on how this works, see Chapter 11) and sends it to machine B.
4.	Machine B, having performed the same calculation as A using the credentials it has stored, now compares the response to its own calculated value. If the two match, the connection is a success.

Now consider this flow instead. For this to work, the attacker needs to convince the victim to initiate an SMB connection to the attacker. This e-mail may be part of a social engineering (see Chapter 5, "Educating Those Pesky Users") attack.

1.	Victim connects to the attacker.
2.	At this point, the attacker's system is supposed to send a challenge to the victim to allow the victim to authenticate. Instead, the attacker initiates a connection to the victim.
3.	Victim generates a challenge for the inbound connection from the attacker and sends it to the attacker.
4.	The attacker takes the challenge it received in Step 3 and sends it to the victim as the challenge for the connection the victim initiated in Step 1.
5.	The victim computes the response to the challenge and sends it to the attacker.
6.	The attacker takes the response received in Step 5 and returns it to the victim as the response to the connection it initiated to the victim in Step 2.

Figure 8-2 demonstrates the complete flow.

Figure 8-2. The SMB reflection attack.

At this point, the attacker has a successful inbound connection to the victim with the privileges of the user that connected to the attacker. This attack is a special form of a man-in-the-middle attack known as a reflection attack . There are tools in the wild available to perpetrate this. By default, it works on all systems released prior to Windows XP Service Pack 2.

For systems prior to Windows XP Service Pack 2 (and Windows Server 2003 Service Pack 1), you need to enable the SMB Message Signing switch to mitigate this problem. Keep in mind that it is primarily systems acting as clients that are subject to this problem, therefore, you need to enable the "Microsoft Network Client: Digitally sign communications (always)" setting in Group Policy. If you just do that, you just turned off those clients ability to get to anything. The reason is that SMB Message Signing on the server side is disabled by default to mitigate the potential 5 percent or so performance overhead it may create. Therefore, to allow the clients to actually connect to anything again, you need to configure either the "Microsoft Network Server: Digitally sign communications (always)" or "Microsoft Network Server: Digitally sign communications (if client agrees)" setting on all systems that should act as servers. Note here also that if you have Windows 9x systems in your environment that should act as servers, you cannot use this setting because they do not support it. On the other hand, if you have Windows 9x systems in your environment, you probably do not care much about security anyway and would not be reading this book, or you have a boss who will not let you do what you want because "security does not provide sufficient ROI" (our sympathies).

Systems that are managed by other systems are obviously dependent on those systems. For instance, a member workstation or server is dependent on all the domain controllers that provide its group policy. In fact, all systems in a domain are dependent on the domain controllers for their security. This is not particularly earth-shattering, but it is important to remember. Likewise, any machine managed by an EMS is dependent on the EMS management systems. Again, this is to be expected, but needs to be pointed out.

Perhaps less obvious is that any system that is trusted for delegation creates a dependency. A user or computer that is trusted for delegation can access network resources on a client's behalf , using a security token for the client. In other words, clients are completely dependent on the computer or user that is trusted for delegation. If a system that is trusted for delegation is compromised, anyone connecting to it may also be compromised because the system can now act as that user or computer. The best option is to avoid trusting systems for delegation at all cost. Windows Server 2003 has a new "constrained delegation" feature that is considerably more secure. Use that instead if possible.

There are also various types of intermediate device dependencies. For instance, a proxy server can act on behalf of a client. Consider, for instance, Figure 8-3.

Figure 8-3. A normal SSL initiation.

Figure 8-3 depicts a normal SSL transaction through a proxy server. The proxy server, in this case, simply repeats all the traffic sent by the client such that the client ends up with an encrypted connection through the proxy server to some server using SSL. After the SSL connection is established, all traffic is opaque to the proxy server.

Now take a look at Figure 8-4. In this case, the proxy server administrator has decided to inspect SSL traffic. The key difference is in the numbers of the flows. Notice that when the client initiates the connection to the proxy server, the proxy server generates a certificate with the name of the server the client requested . The proxy server then sets up and negotiates an SSL connection with the client using that certificate. As long as the client trusts the certificate the proxy server issued, it will happily generate a private key and send it to the proxy server. Now the client has an encrypted channel to the proxy server. Although this is happening, the proxy server creates a separate connection to the server the client desired. However, for this connection, the proxy server generates the session key. In the end, there are two encrypted channels, one from the client to the proxy server and the other from the proxy to the server. Now the proxy server has the ability to decrypt all traffic to and from the client and inspect it. This is the concept used in Microsoft ISA Server's SSL proxy feature, which bridges inbound proxy server traffic, for example, to Exchange front-end servers. The same functionality is also used for monitoring purposes in other products, such as NetIntercept from Sandstorm Enterprises. NetIntercept is capable of monitoring and reconstructing all SSL traffic your users initiate to the outside. This can create a dependency on the proxy server as long as the client is configured to trust the certificates issued by the proxy server.

Figure 8-4. A " legitimate " man-in-the-middle attack.

Non-Windows systems sometimes have dependencies that are almost comical. For instance, the original design of the UNIX operating system included the concept of privileged ports. All network ports numbered below 1024 were privileged ports. That is why we still today use those ports for "well-known" ports, denoting services that are almost always on the same network port. The idea behind the privileged ports, however, was not the well-known ports issue. The idea was for other systems to know whether they trusted a system that connected to them or not. Only the root user (the most privileged user) could initiate traffic over a privileged port. Therefore, if a system received traffic originating from a port numbered below 1024 it must have been originated by the root user on the source system, and might therefore be considered trustworthy. Although we think this is laughable today, every so often, bugs based on this or similar concepts crop up in UNIX-based operating systems. For instance, in 2003 a vulnerability was discovered in Mac OS X that worked very much like this. An attacker who owned one system could initiate a connection to another system, the victim system. By formatting the request in a particular way, the attacker could make the victim require authorization of the action the attacker was attemptingfrom the attacker's own system! That's right, the victim system would connect to the attacker's system to validate whether the attacker was indeed root on that system and if so granted him root access on the victim system as well.

It is hard to say for sure how to mitigate these types of problems. We could tell you not to use UNIX, but that would not be realistic, nor would it be fair. UNIX by and large is a good operating system, and in the hands of a competent administrator, any system can be protected. The only difference is (a) how long it takes to protect a platform and (b) how much functionality you gave up in the process of doing so. The realistic advice is to simply understand the threats as they apply to the system you have chosen (or been forced) to implement and mitigate them with measures appropriate for that system.

One final form of dependency that we are sure you do not have in your environment, but which is nevertheless important, is worth mentioning. Once in a penetration test, we discovered a directory on a system we had just taken over called "subwaypass." We thought that was a very odd name for a directory, particularly considering we do not have a subway in Seattle, where this system was located. Out of curiosity , we decided to see what was in it. To our great surprise, we were denied access to the directory, in spite of the fact that the account we used was an administrator on the system. A quick check revealed that auditing was turned off, so we just granted ourselves access. The directory contained a text file listing all the Administrator passwords for the entire environment. The security of more than 2,000 systems depended on the security of a single directory on a single server, protected by an access control list, but no monitoring. Again, we sure do hope this type of dependency does not apply to you, but it is worth mentioning it nevertheless.