We will draw our examples for this chapter from practical assignments that GIAC students produced as part of the requirements for their GIAC Certified Firewall Analyst (GCFW) certification. The students were asked to create a secure network for a fictitious entity named GIAC Enterprises (GIACE), which is in the business of selling fortune cookie sayings. This is the same source we used for Case Study 4 in Chapter 18, "Sample Designs." In Chapter 18, we explored the major security features for one of the GCFW student's practicals. In this chapter, we will take a different approach when reviewing their designs.
The GCFW students have produced a wide variety of designs for us to choose from. We have chosen to discuss two of them that were awarded honors by the GCFW Advisory Board. During each review, our goal will be to determine if a reasonable scenario exists that would allow an attacker to gain access to the fortune sayings database. As a secondary goal, we will attempt to gain control of as many GIACE systems as possible. Also, both reviews will assume a starting viewpoint of an Internet attacker. A listing of completed practical assignments can be found at http://www.giac.org/GCFW.php.
Practical Design 1
The first design we look at is the security architecture created by Angela Orebaugh. Angela's design is shown in Figure 23.1 and can be downloaded at http://www.giac.org/practical/Angela_Orebaugh_GCFW.zip. It has several interesting features, including the following elements:
Figure 23.1. Angela Orebaugh's GIACE secure network architecture makes extensive use of redundancy.
As previously mentioned, our goal is to determine if a reasonable scenario exists that would allow an attacker to gain access to the fortune sayings database. Our review will assume that the attack originates from the Internet. Because steps 1 and 2 of the adversarial review process have already been determined, our adversarial review of Angela's design will begin with step 3: determining the access that remains. By examining the security settings of each security device that stands between the Internet and the fortune database, we will determine whether an external attacker can access the fortune database. Looking at Figure 23.1, you can see that this will require us to examine the screening filtering routers at the border of the network, the external firewalls, the internal firewalls, and the database server. After we have finished discussing a device's configuration, we will perform step 4 for that device: determining the impact. After all the devices have been discussed, we will then show how step 5repeat as necessarycan be used to combine the discovered vulnerabilities to reach our review goal.
Determining the Access That Remains: Screening Filtering Routers
Our discussion begins at the interface between the GIACE network and the Internet. At the border of the network are two Cisco 7200 series routers running IOS 12.x. They connect the GIACE network to the Internet and are configured to use Cisco's proprietary Hot Standby Routing Protocol (HSRP) to enable one of the routers to take over should the other fail. The routers also provide the first opportunity to protect the GIACE network from external attackers by implementing ingress and egress filters. Because the exact filter settings are essential to the implementation of the security architecture, we spend some time going over them.
The Ingress Filter
An ingress filter on the border router of a network can be an effective first step toward securing it. Properly implemented, an ingress filter can block potentially damaging packets before they enter the network. Here is a summarization of the ingress rules for this design, which are applied to the serial interface that is connected on the border routers to the WAN link to the Internet:
The Egress Filter
The egress filter can prevent the site from being used to attack other sites should an attacker manage to gain control of internal systems. The egress filter prevents spoofed packets from leaving the network and is applied on the Ethernet interface that connects the border routers to the interior network:
As mentioned in Chapter 2, "Packet Filtering," it is a shame that more sites do not implement egress filters. If they did, the opportunity for an attacker to launch attacks on other networks, including distributed denial of service (DoS) attacks, would be sharply limited.
In addition to the ingress and egress filters, the router also has been configured using the following settings to prevent other activities that can cause security problems:
The first setting, No Source Routing, prevents the router from accepting packets with source routing enabled. If you allow source-routed packets, an attacker can more easily circumvent your ingress filters by spoofing packets with addresses that are allowed by the router. Normally, replies to spoofed packets will not make it back to the attacker. However, with source-routed packets, the attacker can define the return path for the reply. This allows the attacker to set up full TCP connections that appear to originate from a trusted external host. Preventing source-routed packets is a setting that should be used on all border routers.
The second setting, No IP Directed Broadcasts, prevents IP-directed broadcasts. This setting is important for preventing the network from being used in a Smurf attack. Without this setting in place, it is possible that the GIACE network could be used to launch a DoS attack on another network. To prevent this, the routers have been configured to drop packets destined to broadcast addresses.
The third setting, No IP Unreachable Messages, helps prevent network discovery activities by telling the router not to generate ICMP unreachable messages. A router generates ICMP unreachable messages on two occasions: when it receives a packet that is destined for itself on a port that it is not listening to, and when it receives a packet that it does not know how to deliver.
Shutting off ICMP unreachable messages makes it harder for an attacker to determine what services are running on the router. It also prevents inverse network scans. If a router generates an ICMP unreachable message when it receives a packet destined for a host that does not exist on a network that the router is directly connected to, an attacker can map the network for live hosts by sending a packet to each address on the network and then watch to see which addresses result in an ICMP unreachable message. A probe that does not return an ICMP packet indicates a live host at that address.
The last setting, No Cisco Discovery Protocol (CDP) Messages, prevents the generation of CDP messages. Cisco routers use CDP to discover information about other neighboring Cisco routers. This information is also useful to attackers, so it has been disabled in this design.
Protecting the Routers
Any device that enforces the security policy of a network is a tempting target, and this definitely includes the border routers. Cisco routers have a few popular ways that attackers can attempt to gain access. These include logging in to the router using Telnet, downloading or modifying the router's configuration using SNMP, and accessing the router through its HTTP administrative interface. The following steps were taken to prevent these types of accesses:
Now that we have described the security settings of the routers, let's see if we can figure out a way they might be compromised.
Determining the Impact: Routers
We start step 4 of our adversarial review of the screening filtering routers by looking at the access that remains after all of the routers' filter settings are considered. The major items we note are the settings that allow outside users access to the web, mail, DNS, and VPN servers. This information will be useful to us later when we look at the security of those devices. Meanwhile, some additional items are worth noting about the routers.
The security settings of the border routers are relatively good, and little access remains after the filters and other configuration settings are considered. However, a few areas remain that we should take note of during the review:
To start with, the ingress filter is allowing established packets through. This allows an attacker to use ACK scanning to discover services on computers behind the routers. In this design, depending on how the external firewalls are configured, this might not be a problem. However, if a firewall was not between the routers and the GIACE network, better filtering settings would be needed at the router. Cisco supports two additional filtering technologies that can help. The first is reflexive access lists (covered in Chapter 2). These allow the router to filter incoming packets based on whether a matching outgoing packet was seen previously. Although this is effective for many types of TCP connections, certain protocols cannot be supported using reflexive lists. For these other protocols, Cisco supports context-based access control (CBAC) filters. CBAC filters can be CPU intensive, so be careful when using them that you do not adversely affect the router's primary purposeto route packets. More details about CBAC can be found in Chapter 6, "The Role of a Router."
The next area to look at is the egress filter. It allows any internally generated packet to leave the network as long as its source address is valid. This is overly permissive. A number of ICMP packet types should probably be blocked at the egress filter to prevent certain types of discovery activities. For example, ICMP TTL exceeded messages should be dropped to prevent the attacker from using traceroute to discover the structure of the network. In addition, most types of ICMP destination unreachable messages should be dropped to prevent attackers from learning what hosts and services are running on the network.
One type of ICMP destination unreachable message that should not be filtered is code 4 (fragmentation needed and don't fragment are set). RFC 1191compliant systems use this destination unreachable message to set the optimum maximum transmission unit (MTU). See Chapter 6, "The Role of a Router," and Chapter 17, "Tuning the Design for Performance," for more details.
In addition to filtering ICMP messages, it is worthwhile to block other types of outbound traffic that are unnecessary to the operation of the network. If an attacker were to gain control of an internal system, this would make it harder for him to use the system to attack other systems outside the network. It can also complicate the attacker's ability to download additional exploit tools. In the case of a live attacker, this is probably just an inconvenience. However, if the attacker actually sends a piece of malicious code, such as a worm or virus, egress filtering can prevent the attack from working.
Beyond these issues with the filters, certain problems might allow an attacker to gain control of the actual router. The first of these is the use of SNMP. An attacker who knows the read-only SNMP community name and has access to the SNMP service on the router can learn substantial information about the configuration of the router. An attacker who knows the read-write SNMP community name can change the configuration of the router, including the access control lists (ACLs). To prevent this from happening, the routers have been configured to accept SNMP requests only from the management console. In addition, community names have been chosen that might be hard to guess. Accepting connections that originate from the only monitoring server's address is effective at blocking requests from outside the network. If the attack originates from inside the network, though, the attacker might be able to successively impersonate the monitoring server, allowing him to access the SNMP service if he knows a valid SNMP community name.
Discovery of the community names might be relatively easy. First, the read-only community name was set to "giacpublic." It is realistic to expect that a determined attacker might guess this community name. Second, SNMP version 1 does not encrypt its packets. An attacker who manages to take control of a system that is on the network path between the management server and the router might be able to sniff the community names (including the read-write community name) as they are transmitted to the router. This would allow the attacker to completely compromise the border routers. It is important to mention that the community name weakness has been eliminated in version 3 of the SNMP protocol. Cisco routers fully support this version of SNMP; unfortunately, many SNMP management tools have not been updated to support this enhanced version of the protocol.
The second way that an attacker might be able to gain control of the routers is by logging in to them. Similar to the technique used to protect SNMP, the routers accept login only from the monitoring server, and again, similar to SNMP, an internal attack might be able to bypass this restriction. Additional security has been added by changing the login protocol from Telnet to SSH. Because SSH encrypts the network conversation, an attacker won't be able to sniff a valid password from the network when a login to the routers occurs. However, an attacker could still guess the password. No strong authentication system (such as SecurID) is being used. A simple (weak) username/password combination is all that is needed to access the router. Brute force techniques can be used to guess this password, although the monitoring server would log this activity.
It is also possible that vulnerabilities in the SSH version 1 protocol might be used to gain access to the routers (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0144). In particular, SSH version 1 has a vulnerability that might allow an attacker to recover a session key and allow the session to be decrypted. This could reveal the username and password of the administrator, allowing the attacker to log in to the router.
The SSH protocol supports public key authentication. However, not all SSH servers implement this feature. This includes the implementation on Cisco routers.
Mention of SSH vulnerabilities is not meant to imply that you should not use SSH to protect your Cisco logins. It is still a useful technique to protect the routers. To make it more effective, consider implementing stronger authentication methods than are used in this design.
Determining the Access That Remains: The External Firewalls
The next layer of defense is a pair of stateful packet filter firewalls being used to implement the external firewall and to terminate the VPNs that allow the business partners and the suppliers to connect to the internal network. The products being used are two NetScreen-100 security appliances. Like the border routers, these appliances are running a high availability protocol to allow one to take over should the other fail.
The NetScreen-100 is no longer produced. Service for this device ends on January 14, 2006. After this date, no additional support, including patches, is available. It is important that you consider end-of-service issues when selecting security products because once the product reaches its end of service, you will no longer be able to keep the device secure. This problem is not specific to NetScreen. Most manufacturers will eventually stop support for their older products.
The NetScreen-100 comes with three network interfaces: untrusted, trusted, and DMZ. In this design, the untrusted interface is connected to the border routers, the trusted interface is connected to the internal network, and the DMZ interface is connected to the screened service network. It uses four different rulebases to control which packets to allow, based on the interface at which the packet arrives. These rulebases are incoming, outgoing, "to DMZ", and "from DMZ". For example, packets that come from the untrusted network and are destined to the internal network are filtered based on the incoming rulebase. Packets that enter the untrusted network and are destined for the DMZ are handled by the "to DMZ" rulebase, and so on. The following sections present the configurations for each rulebase.
Table 23.1 shows the rulebase that controls packets heading from the untrusted interface to the trusted interface.
The rulebase in Table 23.2 controls the traffic entering from the trusted interface and destined for the untrusted interface.
The rulebase in Table 23.3 controls the traffic heading for the DMZ network regardless of which interface the traffic entered from (untrusted or trusted).
The last rulebase, shown in Table 23.4, defines what traffic is allowed to leave the DMZ network.
Determining the Impact: The External Firewalls
The cumulative effect of these rulebases is to dramatically limit what type of traffic can flow between the three network zones. It is our job as adversarial reviewers to look for any access that remains after all the rules on the firewalls are put into place and for any vulnerabilities that might exist in the firewalls that an attacker could make use of. A careful review of these settings reveals the following issues:
As stated at the beginning of this chapter, attackers target what they can talk to. In this case, the web server and mail server must be accessible to outside users. If the web server software or the mail server software contains vulnerabilities, this design would not prevent it from being taken over, which is a major concern because services that have had the worst history for security vulnerabilities include web and mail server software. Stateful packet filtering firewalls rely primarily on the contents of the packet header to make their security decision, so they would be unable to detect an attack that uses malformed requests targeted at the web or mail server software. The use of a web proxy and a mail proxy would provide the ability to look at the application data in the packet to determine whether an invalid request is being made. Although this method is not perfect, it would provide better security than relying entirely on the packet header to make the security decision.
The next potential problem is the permissive setting between the web server and the database server. An attacker who managed to gain control of the web server could use it to attack any TCP service running on the database server. This rule should be more restrictive, permitting only the minimum TCP traffic necessary to allow the web server to make the necessary database queries. It is worth noting that the internal firewall does provide this restriction. It only allows the web server to send SQLnet1 (TCP Port 1521) traffic to the database server. You might ask why it is important to restrict the traffic between the web server and the database server at the external firewall when the internal firewall is going to accomplish the same thing. As was stated previously, whenever you can stop a particular problem with multiple defensive techniques, you increase the resiliency of the network to attack.
The last items worth talking about are potential vulnerabilities in the NetScreen devices. Some versions of the NetScreen software are vulnerable to an attack that allows packets into the DMZ that should have been filtered (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0589). Ensuring that version 2.5r6 or higher is installed on the NetScreen devices will prevent this attack.
Determining the Access That Remains: The Internal Firewalls
The internal firewalls are the last line of network filters for the GIACE network. Their purpose is to provide design redundancy for the NetScreen appliances while protecting the internal and management networks.
The internal firewalls are implemented using a pair of Nokia IP330 firewall appliances running Check Point FireWall-1 version 4.1. Like the NetScreen-100s, the Nokias are stateful inspection firewalls; however, unlike the NetScreen configuration, the Nokias have a single rulebase to control all filtering decisions. Table 23.5 is the configuration of this rulebase.
Determining the Impact: The Internal Firewall
This filtering layer provides additional protection for the internal network over and above that provided by the external firewalls. Separation of the management network and the internal network is a particularly good idea. As with the external firewalls, though, some access remains after the firewall's security controls are considered. Here are three issues that should be addressed:
The first issue to address is the protection of the management network. Separating the management network from the rest of the network is a good security precaution. As is the case in this design, management systems frequently have more access rights to the network than other systems, which makes them tempting targets. An attacker who manages to gain control of the monitoring server, for example, would be able to attack most of the security devices on the network. For this reason, the management network needs to be carefully protected; yet this rulebase allows internal systems free access to the management network. Rules 4 and 5 are meant to restrict the internal networks' access to the screened services network while allowing them free access to the Internet, but the rules are more permissive than necessary. Rule 5 says that as long as the destination address is not the screen services network, then the packetsincluding packets destined for the management networkare allowed.
The next issue to talk about is the control of traffic between the screened services network and the internal network. This rulebase does a good job of limiting screened service systems access to the bare minimum required to allow the network to function; however, any time you allow communication between networks at different trust levels, you need to be extremely careful. To allow logging and time synchronization, the screen services network hosts are allowed to send Syslog entries to the log server and make NTP requests from the NTP server. Both of these systems are located on the management network. If either of the daemons (Ntpd or Syslogd) contains security vulnerabilities, an attacker could gain a foothold on the management network. Because of this, special care should be taken to harden these services.
The rulebase also allows the web server to establish connections with the database server over the SQLnet1 protocol. Again, as with the Ntpd and Syslogd daemons, if the service, which handles the SQLnet1 requests, contains vulnerabilities, it is possible for an attacker to gain control of the database server. In addition, even if the service contains no vulnerabilities, the web server has a normal amount of access to the database service running on the database server. An attacker who controls the web server could cause the database server to perform malicious transactions, such as creating fake supplier invoices. These transactions would be hard to prevent if the web server is normally allowed to request them. Only careful application design that includes substantial validity checks on each transaction could help mitigate this problem.
The last issue to discuss is the reliance on the SSH protocol to administer the firewalls. The Nokia IP330s prior to release 3.4.1 have the same SSH vulnerability we described for the Cisco routers. IP330s running older versions of software that require SSH support should be upgraded.
Repeating as Necessary: Attacking the Whole Network
So far, we have talked about the individual devices that make up the security of the network and how their configurations might open up the network to attack. Let's see what might be possible if we combine all of this information.
Our attack will start by looking for vulnerabilities in the web server, the mail server, and the DNS server. The reason for this is simple; after the routers and firewalls have done their jobs, these are the only systems we can still establish connections to. If any of these systems contain vulnerabilities, we might be able to gain access. For example, if we assume that the web server is running Internet Information Server 5.0, it is possible that the web server is vulnerable to a buffer overflow attack.1 A successful attack would place us in complete control of the web server.
But wait! Look back at the network diagram in Figure 23.1. Isn't there an IDS located on the screened services network that might detect the attack? The important word here is might. Most IDS tools are signature based. If the attack is new or the IDS has not been updated, it is possible that the IDS does not contain a signature for the attack, in which case it would not be able to produce an alert2. In addition, in some cases, attacks can be reengineered to specifically avoid detection by IDS tools.3
Assuming that we are now in control of the web server, what should we do? This depends on the review goals. If the goal is to embarrass GIACE, we now have enough privileges to deface the website. If we are trying to steal data, we are in a good position to accomplish this as well. The web server needs to be able to query the database server to fulfill its role. We could potentially use this access to query customer account information, steal fortune sayings, or capture any other information that the web server would normally have access to on the database. We could also Trojanize the web server, replacing the scripts that implement the website (CGIs, JSPs, and so on) with versions that record the transactions between the users and the site.
If we want to gain control of more hosts on the GIACE network, the other screened service network systems would be good targets. By using the web server to launch the attacks, we can circumvent the external firewalls and attack any system on the screened service network. What about attacking systems on the internal network?
We still have two layers of firewalls between the internal networks and us. The result of both layers leaves us with limited access from the screened services network. We can send Syslog packets to the log server, NTP packets to the NTP server, and SQLnet1 packets to the database server. As with the web server, we need a vulnerability in the service software if we want to continue the attack. In this case, if GIACE is running Oracle 8i on the database server, it might be possible to proceed. Some versions of Oracle 8i's listener services contain a buffer overflow vulnerability that allows an attacker to gain remote access to the server (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0499).
Taking over the database server allows us direct access to any of the internal systems, including user workstations. In addition, it allows us to attack any of the systems on the management network. Remember: The internal firewalls do not prevent hosts on the internal network from communicating with the management network. The likely reason for this is that the administrator is using a workstation located on the internal network to log in to management network systems. As was mentioned in Chapter 13, "Separating Resources," using ARP poisoning techniques makes it possible to eavesdrop on the conversations between the internal network and other networks, even though the network is implemented using a switch instead of a hub. If the administrator wants to access management network systems by using Telnet, FTP, or any other protocol that does not encrypt authentication information, we will be able to capture the administrator's username/password combination and use it to log in. This would pretty much be game over because we would then have control of every major system on the network.
You might be asking yourself how realistic this sample attack is. We had to rely on vulnerabilities on the web and database servers to accomplish the attack, and we had to assume that the IDS would not pick up the attack. This is a key point to consider when performing your review. Even when you cannot find a vulnerability for a particular service or system you are running, it can still be useful to assume the existence of a vulnerability to discover the impact it could cause should one be discovered in the future. It is almost beside the point that the products we chose to use to illustrate the example actually contained exploitable vulnerabilities. It is much more important to recognize that even good security architectures can be improved.
These additional steps can be used to improve this design:
Practical Design 2
The second design we will look at is the security architecture created by Sam Campbell. Sam's design is shown in Figure 23.2 and can be downloaded at http://www.giac.org/practical/Sam_Campbell_GCFW.zip. This is an interesting design that has many sophisticated security features:
Figure 23.2. This security architecture uses a security-hardened version of UNIX to protect the web server.
Sam's design has five security devices that need to be examined: the border router, the external firewall, the public web server, the internal firewall, and the extranet server. Each of these devices plays a role in determining how much access we can get to the GIACE network. Just as in the previous case study, we provide a discussion of the access that remains for each of these devices and what impact this access would have to the network's security. We wrap up our discussion by showing how all the vulnerabilities can be combined to reach the review goals as well as provide recommendations to improve the security of the design.
Determining the Access That Remains: The External Firewall
As in the previous review, we want to look at each security device to determine what access remains to the attacker after the device is added to the network and find any additional vulnerabilities that might exist in the device. Where appropriate, we assume vulnerabilities so that we can analyze where additional security measures might be warranted.
Because this design's border router is set up similarly to the first design we looked at, we will not spend time discussing it. Beyond the border router, there are two paths into the network: toward the external firewall and toward the public web server. We will begin our discussion by looking at the security implemented by the external firewall.
The design uses a Symantec firewall to provide access control between the Internet and the internal networks. Unlike the stateful firewalls used in the previous design, the Raptor is a proxy firewall. As was covered in Chapter 4, "Proxy Firewalls," this type of firewall acts as a go-between for network connections. This method provides some security benefits, including the ability to hide the structure of the internal network and to make security decisions based on the content as well as the header of the packet.
Proxy firewalls can hide the structure of the network because they act as a middleman for all the network connections. All incoming connections are negotiated at the firewall, which then negotiates a second connection with the system that will actually handle the transaction. This configuration makes it difficult for an attacker to discover details about the host he is attempting to attack. As an example, if an Nmap scan with operating system detection was conducted against a network protected by a Symantec firewall, the result would look like all the public servers were Symantec firewalls.
The method that proxy firewalls use to protect networks also allows for inherent Network Address Translation (NAT). Because the firewall will act as the public front for all the protected systems, it is the only one that needs to have any public IP addresses. The protected systems can be numbered using any private addressing scheme. This does require that the firewall know which system will handle a particular incoming request. Table 23.6 shows the translation settings used to allow external requests to reach the appropriate internal system.
Because these systems are the only servers that have an external IP address, they are the only systems protected by the firewall that an external attacker will be able to directly communicate with. In our review, we will want to look at the chance that an attacker could use this capability to attack these systems.
Hosts on the inside of the network that will require the ability to initiate external network connections must also have translation rules established on the firewall. Table 23.7 shows the rules for this design.
The implication of this table is that these are the only hosts (besides the public web server, border router, and external IDS) on the GIACE network that will be allowed to initiate connections to the Internet. This means that any attempts to attack the Internet from the service network need to be launched from one of these systems.
Of course, the main purpose for the firewall is to provide access control. Table 23.8 shows the access control settings used in this design.
The Symantec firewall that was used in this design includes the incoming and outgoing interface in each access rule. The names of the interfaces are configured during installation of the firewall. Although the interface names are pretty self-evident, it is worth noting that the corporate interface is the one connected to the internal firewall.
Determining the Impact: The External Firewall
This external firewall implementation doesn't give us much to complain about. Assuming that the firewall does not contain vulnerabilities that would allow us to circumvent its security rules, the only systems protected by the firewall that an external attacker could initiate a connection with are the mail relay server, the external DNS server, the internal firewall, and the extranet server. For an attack to succeed, one of these servers would have to be vulnerable. However, even if one of the servers is vulnerable to some exploit, the proxy nature of this firewall might prevent the attack from succeeding. As an example, suppose that the Qmail software running on the mail relay server had a buffer overflow vulnerability in its handling of the SMTP HELO command. The firewall's mail proxy limits the format and length of the data that the HELO command supplies. It is unlikely that the data the attacker would need to provide to successfully attack this system would meet these length and format restrictions. This does not mean that this solution is bulletproof. Remember that we should also consider vulnerabilities in the security device. In this case, a quick search on the vulnerability database at http://www.securityfocus.com reveals several problems that could affect its security:
Neither of these vulnerabilities would help an attacker gain unauthorized access to this network. If no other potential access paths were available for an attacker to use, we might decide to analyze the impact that adding an artificial vulnerability to the network would have. In this case, though, other areas in the network show a greater potential for problems, including the public web server.
Determining the Access That Remains: The Public Web Server
This design uses the highly unorthodox approach of locating the public web server on a host connected directly to the Internet with no firewalls in-between. This host is also acting, for all intents and purposes, as a proxy firewall between the Internet and the Fortune Application LAN. The designer felt comfortable doing this because this is no ordinary web server. The product he has used is an HP Virtual Vault Server. HP Virtual Vault is an HP UNIXbased system that has been heavily modified to increase its security. The biggest change is the absence of an all-powerful root account. Instead, the power of the root user has been separated into 50 distinct privileges. These privileges can be granted or revoked as needed on a per-user, process, or file basis. This provides tremendous power in limiting the impact of service vulnerabilities. Even if an attacker can successfully take over a service on a Virtual Vault, the service might not have enough privileges on the Virtual Vault to allow the attacker to do anything useful. In addition, the Vault comes installed with nothing activated by default. You must manually add interface cards, the web server, and so on, which eliminates the possibility that a vulnerability in a service that is not being used could be used to compromise the Vault. More information on trusted OSs such as the Virtual Vault can be found at http://csrc.nist.gov/secpubs/rainbow/std001.txt.
Multilevel security operating systems, such as HP Virtual Vault Server, have clear security advantages over standard servers and seem easy to recommend from a functionality standpoint. However, before you rush out to implement one, you must carefully consider the additional effort required to install and maintain these systems. These servers can be tricky to configure correctly. The added flexibility in permissions adds complexity in implementation.
The version of Virtual Vault being used for this design comes with an integrated Netscape Enterprise web server. This web server hosts the public website for the GIACE network and is the primary public interface between GIACE and its customers. To perform this role, the web server connects to the Fortune Application Server using its second network interface, which is connected directly to the Fortune Application LAN. This application server implements the back-end processing for the site, including storing and retrieving transaction information in the corporate database and authenticated customers by querying the corporate LDAP server.
Determining the Impact: The Public Web Server
This is an interesting way of implementing the public web server for this site, but it is also somewhat risky. The security of the most critical parts of the GIACE network depends on the strength of a single product: the Virtual Vault. If the Virtual Vault security should fail, an attacker would have access to the "crown jewels" of this network. Placing the public web server behind the external firewall, while increasing the load on the firewall, would provide some additional protection for this critical GIACE resource.
Determining the Access That Remains: The Extranet Server
The extranet server allows partners and suppliers access to the hosts on the Fortune Application LAN. The extranet server is implemented using an Aventail extranet server. The Aventail extranet server is a form of reverse proxy that allows external users, after they have authenticated, to connect to internal systems. To protect the confidentiality of these transactions, including the exchange of authentication data, the Aventail solution encrypts these conversations.
Table 23.9 shows the configuration details for the extranet server.
As you can see from this information, two classes of access are available. Suppliers are granted access to the application server by providing a valid username/password. After this is performed, the supplier is granted access to port 5656 on the application server, which is where the customer GIACE fortune application is hosted. Partners are granted additional access to the network, but they are required to also provide a client certificate in addition to a valid username/password. All authentication data, including the client certificates, is held on the corporate LDAP server.
The added access granted to the partners includes the ability to connect to a web service located on the application server as well as to connect to the NetBIOS ports on the shares server. This shares server is not shown on the network diagram, but it is located on the Fortune Application LAN. It is used as a place to share files between GIACE and its partners.
Determining the Impact: The Extranet Server
This solution does allow secure access from partners and suppliers, but there are still a few points to be made:
Determining the Access That Remains: The Internal Firewall
The internal firewall protects the desktop and corporate LANs while allowing remote users to establish IPSec tunnels to the GIACE network. These remote users are authenticated using SecurID tokens. The firewall is implemented using a Nokia IP440 appliance running Check Point FireWall-1 version 4.1. Table 23.10 shows its configuration.
Determining the Impact: The Internal Firewall
This is a reasonably secure rule set, especially considering all the other security measures in effect on this network. One point of concern is worth discussing, though.
The use of SSH might allow an internal attacker access to the corporate network. The internal firewall allows the desktop LAN to communicate with the corporate LAN using several protocols, including IMAP and SSH. The use of SSH is probably to allow an administrator, while he is at his desk, to administer corporate LAN systems. At the same time, protocols that allow unencrypted authentication, such as IMAP, are also allowed between the two networks, which might create an opportunity for an internal attacker to gain administrative access to corporate servers.
This access would rely on a couple of configuration details. First, the SSH daemons on the corporate network would need to accept username/password authentication (their default configuration). Second, an administrative user would need to have used the same password for his mail account and his user account on a corporate server. We'll leave it up to you to decide how realistic you think this would be.
To implement the attack, the internal attacker would first use ARP poisoning techniques to convince the local systems that the MAC address of the local interface of the firewall is actually the MAC address of the attacker's system. This method results in all the desktop LAN traffic destined for other networks to be redirected to the attacker's machine. By eavesdropping on all this traffic, the attacker can capture the IMAP authentication session when the administrator goes to retrieve his mail. Using the username/password from this session, the attacker would be able to use SSH to log in to any corporate servers in which the administrator has used the same password.
Prevention of this attack is simple. Make sure all SSH servers are configured to only accept public key authentication and make sure the SSH private keys are well protected. Also, if you must use the nonencrypted mail access protocols (as opposed to IMAP+SSL, for example), create a different set of usernames/passwords just for mail access.
Repeating as Necessary: Attacking the Whole Network
All in all, this is a good security design that would be extremely difficult to attack from the outside. An attack is not impossible, though. Here is a potential scenario that might grant access to the "crown jewels."
As previously mentioned, an inordinate amount of trust has been placed in a single server. If the HP Virtual Vault contained sufficient vulnerability, an attacker would have free access to the Fortune Application LAN. As luck would have it, the version of Virtual Vault that was used contains two key vulnerabilities that might be useful to an attacker.
The first is a buffer overflow in the publisher module of the Virtual Vault's web server. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0746). If the web-published module were installed on the Vault, it is possible that an attacker could use this vulnerability to execute arbitrary code at the privilege level of the web server, although this is somewhat unlikely because HP rated the publisher module as "high risk" and did not include it as part of the standard distribution.
The second vulnerability is in Virtual Vault's mkacct command, which creates a new account on the server (http://www.securityfocus.com/bid/1843). This program contains a vulnerability that can allow a local user to add privileges to his account. Using these in combination might allow an attacker to gain control of the web server's account and then elevate his privileges to the point where he is as close to root equivalent as is possible on a Virtual Vault system.
Unfortunately for the attacker, it is unlikely that the web server would have the mkacct privilege, making the second half of this attack impossible. This is the strength of the Virtual Vault system. By limiting permissions to just those required for the job at hand, you drastically reduce the risk of exploitation.
All is not lost for our attacker, though. The web server must have sufficient rights to perform its normal activities. This includes the ability to retrieve customer data, retrieve fortunes, and capture other sensitive data that the web server would normally have access to. In this case, even web server access might meet the goals of the attacker. The lesson here is never to rely too heavily on one solution. Moving the web server behind the external firewall would prevent this attack from succeeding.