1. the DMZ

A “De-Militarised Zone” (DMZ) is an industry standard way of separating the Internet from a corporate intranet. Positioning externally facing servers in the DMZ is often seen as an excellent method of reducing the risk of an attack to the internal . Servers on the DMZ are effectively isolated from the internal , usually by a . The DMZ itself is often protected by rudimentary packet filtering at a screening router that connects to the wider Internet. Often, to limit cost, the DMZ-internal network is also only protected by a screening router. Whilst the concept of using a DMZ is sound, the implementation is often a cause for concern.

2. The Target Network

This article will not detail the information gathering requirements that an attacker needs to achieve to know the target network topology. It is assumed that the attacker has possession of the information provided in the picture.

dmz Hacking the DMZ

The target system is configured such that the Screening Router will block incoming and outgoing ICMP packets (e.g. PING). The firewall appears to be configured to allow nothing in, but any service outgoing.

3. Compromising the DMZ

The first stage of the hack is to compromise the DMZ. on the DMZ is only as strong as the weakest link. An attacker will try and target any machines accessible on the DMZ; therefore any machine positioned on the DMZ should be hardened. There are a range of ways that an attacker could gain access and control of machines on the DMZ. Some considered approaches might include:

3.1. Attack the Admin & Stats box.

This machine is an administration machine for the DMZ network. It might contain administrative onboard – perhaps including TFTP to service the router, or even access control functionality for a VPN. It may simply be a poorly configured statistics gathering machine with FTP and telnet servers left open. By port scanning the attacker can get an idea of services onboard. An attack may take the form of:

  • Direct access to guest/anonymous account.
  • Username/password guessing (perhaps using an automated guessing tool).
  • Buffer overflowing network services to gain access.

3.2. Attack the Test box.

The test box may be a web server mirror for experimental site builds; it may be the box on which the e-commerce solution is being built. But what is important is that it is more than likely that security on the test box will not be watertight! It may be that this machine is a Server with software that has been installed in a default mode, offering a wide range of network services. It is possible that there may be HTTP services running, possibly without access control. It is likely that a test box will have FTP and telnet services running as a minimum to allow uploading of prototype software – however at worst it is possible that the box is dual-homed with an address from the internal network to facilitate easy updates from the web developers. An attack may therefore take the forms:

  • Direct access to guest/anonymous account.
  • Username/password guessing (perhaps using an automated guessing tool).
  • Buffer overflowing network services to gain access.
  • Exploiting experimental web services. It is possible that these services may not be configured for security (or configured at all!). Perhaps a scan for perl / tcl / python / php / cgi-bin vulnerabilities may provide a route in or critical information out (e.g. usernames / passwords).
  • Access to any NETBIOS type information may yield network and user information. Depending on how the box is configured it may be possible to gather some of the dual homed information regarding the internal network.

3.3. Attack the Web Server.

The web server should be secure; however exploitable vulnerabilities appear on a daily basis. It is possible that the most securely configured web servers could suddenly be open to the world from a buffer overflow or information leakage vulnerability that has arisen from lazy coding. Hence, an attack on the web server will be in much the same way as the test server could be taken down. It is also likely that the web server will have some sort of direct access from the internal network, perhaps using dual homing, or perhaps a telnet or FTP account on the server. A secured architecture may have the screening router only allowing incoming HTTP IP traffic. This would preclude attacks on all incoming ports except Port 80. (Hence attacks on the Linux and Test Boxes could only occur if HTTP services were available). Common web servers (e.g. Apache and ) have recently suffered from the exposure of numerous exploitable vulnerabilities. A possible attack could exploit a web server vulnerability that creates the opportunity to run executables on the target. Perhaps the FTP client is started, pointed at either the attacking machine or a 3rd party software source. Note that the FTP session has been set up from inside – remember that the screening router will only allow Port 80 in, but anything out! Using the FTP session an attacker might insert Trojan files, or insert more network functionality to support further attack (e.g. uploading NETCAT to allow reverse Telnet sessions so that command line functionality is available to the attacker). Assuming that the attacker has the resourcefulness to gain access to one of the DMZ machines and gain root or administrative privileges, exactly what can be achieved? The attacker now has the ability do any of the following:

3.4. Deface the Website.

If the attacker controls one of the other machines on the DMZ (i.e. not the Web Server), there is still some way to go before the web server is compromised. However, it is possible that there may be NETBIOS shares between the Test Server and the Web Server that can be exploited, or perhaps use buffer overflow techniques to crash the Web Server and insert Trojanised code. There is a plethora of ways to compromise an adjacent machine on a network! Once the attacker has gained access to the Web Server, it is a trivial task to delete current web content and replace it with a calling card.

3.5. Denial of Service.

The attacker may use the DMZ network services to provide further hardware support for an attack on a 3rd party. The attacker may use the platform to attack the Screening Router or Firewall – hence denying Internet services to the target organisation.

3.6. Corruption of Services.

The attacker rather than causing a denial of service attack, where the target suddenly becomes aware of network failure, the target of attack may be the Network Quality of Service (QoS), – an attacker may install a tool that grabs incoming packet headers and sends similar headers with garbage payloads at a random rate.

3.7. Insertion.

The first two attacks are highly overt, the previous attack less so. Insertion is a covert attack and can be targeted at either the Website audience or the internal network. In this scenario malicious code is used directly to create the desired effect. A typical example of a Trojan might be BO2K.

3.8. Staging post.

This attack is again covert – the attacker does not wish to alert the target system administrator that the DMZ is compromised. Instead the attacker will use the DMZ as a staging post to gain access through the firewall into the target internal network. This can be achieved partly by the insertion of code and partly by the state of the compromised system. The latter two attack types are described in more detail in the next section.

4. Extinguishing the Firewall

The firewall itself is not the issue; protection offered by a firewall is governed by its internal configuration (i.e. rule-base and policy settings) and the security of the network that they serve. Is understandable therefore that the two major failings of security in architectures that rely on firewalls are:

  • Badly constructed firewall rules and policy allowing an intruder to gain access.
  • Firewall short-circuiting – where users either physically connect their way around the firewall or use legitimate firewall access to create illicit network access (more or less directly through the firewall!). Short-circuits are often observed where networked computers are illicitly connected to phone lines by modems. Other short-circuits can be caused by dual homing of DMZ machines and tunnelling of services through firewalls.

The potential exploitation scenarios are:

  • Using malicious code to gather information
  • Using malicious code to gain access
  • Using malicious code to trigger an attack
  • Direct access by exploiting vulnerabilities found on DMZ machines.
  • Direct access by exploiting vulnerabilities in firewall and architecture configuration.

4.1. Using malicious code to gather information

Installing a packet sniffer on the DMZ will allow some information capture. This is particularly true if any of the devices on the DMZ are either used for access control or provide services that need contact with internal machines. If the firewall is doing its job it is unlikely that much internal information will be available for gathering. However, in many cases, firewall rules have been weakened for administrative or business expediency. Information that can be gathered may include usernames, cleartext passwords, hashed passwords, and internal host names for applications such as and database servers. These can provide a direct access into the internal network. The DMZ is also an ideal position to sniff SMTP/POP3 and monitor corporate e-mails content. This can then provide the attacker with some internal details of the network. A more likely scenario is that the attacker could monitor addresses and related personal information enabling either a direct attack as detailed in the following section or a social engineering attack to cheat people out of usernames/passwords for direct access. The attacker is more likely to just gather e-mail addresses (both sender and receiver) for use to gain direct access.

4.2. Using malicious code to gain access

An attacker can send a Trojanised e-mail attachment to an address with the sender address spoofed to be from an expected source. A typical Trojan might be DeepThroat or Qaz, both of which can be disguised in an amusing executable payload – e.g. a small freeware game or the latest joke! The Trojan will open pre-selected listening ports and allow direct connection for an attacker on a particular high numbered port. Qaz will even e-mail the attacker details of the infected machine. Typical “Remote Control” Trojan functionality includes the ability to:

  • Create and delete directories
  • Copy, delete, rename, upload, and download files
  • View, terminate, and set priority for processes
  • Execute program
  • Create and delete registry keys
  • Set registry values
  • Perform a shutdown, log off, restart, and power off
  • Get a snapshot of an entire screen or for a specific window
  • Send messages to a specific window
  • Look at the contents of the buffer where the keyboard input is stored
  • Re-map and disable keys on the keyboard
  • Open and close the CD-ROM tray
  • Turn the monitor on and off
  • Play wave (.WAV) files
  • Chat with other people
  • Obtain CMOS and screensaver passwords

The trojanised machine will be on the target internal network, but may not be the actual target machine. The attacker, using the Trojan functionality will be able to take control of the internal machine to use any installed client software to log onto the target machine. In the absence of any bespoke client software the attacker can use the trojanised machine as a staging post to telnet or web-browse onto the target.

4.3. Using malicious code to trigger an attack

There are two types of attack that can be achieved using malicious code as a trigger. First is purely defacement and is similar to infecting with a time-triggered virus – except that it is the Website users that trigger the virus. There have been some server side viruses that exploit both the server software (e.g. IIS) and web supporting software. These can certainly be used to trigger on particular requests (e.g. infection of a search engine might only give a particular response when a particular subject is requested). It is feasible, particularly with websites that offer downloadable products, e.g. demonstration software, that clients can be infected with either Trojans or viruses when the Website is infected. Proof of concept viruses exist using Java and php that infect the web server so that particular pages / services will be disrupted. This may in the future provide the means by which an attacker, who has compromised a web server, may directly attack both web surfers and administrators – although no compromise route has yet been proved.

4.4. Direct access by exploiting vulnerabilities found on DMZ machines.

This is a more “conventional” approach to gaining access to the internal network. DMZ hosts may have a number of vulnerabilities onboard that allow direct connection to the internal network.

As previously mentioned, if either Test Server or the Web Server (on the example) were dual-homed, once the machine is compromised there may well be a direct connection (e.g. by network share using NETBIOS) straight through the firewall to a machine on the internal network. The use of sharing using SAMBA (SMB) or NETBIOS is very common due to the prevalence of operating systems.

Amongst other common vulnerabilities are old passwords left on machines, perhaps even the network administrator’s password? Or perhaps the Test Server may have originally been connected to the internal network and has internal passwords left on it. Is the external router managed using SNMP, are the community strings guessable – can the router be directly accessed? Is the router being managed from the DMZ or the internal network – is there a way into the internal network by using SNMP? The attacker will ultimately seek out a suitable and exploitable attack route to traverse the firewall.

Popular use of web “shopfronts” with a database “back-office” often present attack routes. SQL and Oracle have had a particularly high number of exploitable vulnerabilities recently. The abuse of a SQL vulnerability might be exactly how the attacker traverses from the web server to the internal SQL server and gets all your customer’s credit card numbers!

Direct access by exploiting vulnerabilities in firewall and architecture configuration

A poorly configured firewall might as well not be there! Firewalls are only useful when with a tight rule-base and policy that reflects actual secure business needs.

At worst the firewall machine (not the external port but the IP address of the machine on which the firewall resides) may be directly accessible from the DMZ. If this is the case, then the firewall can be crashed – failsafe will cause a denial of service event. Some firewalls remove the default IP stack and replace it with a secure “bespoke” stack – this will disallow any access to the firewall machine as a network host.

The firewall rule-base may still include test rules that were put in place to allow successful installation (e.g. may still allow incoming ICMP or telnet!). Being too long may flaw the firewall rule-base and confused logic creates a loophole that allows what would normally be disallowed network services. Network Address Translation may not be set up correctly allowing an attacker to mask an intrusion. Should the firewall management be accessible from the outside (e.g. an outsourcer managing a firewall from a remote site) it is possible that an attacker could IP spoof the firewall and begin guessing the management passwords – success depends on the quality of security on the firewall! Usually, the attacker will not challenge a firewall head on, but will look for routes “around the back”. Poor or no thought put into architecture design can lead to situations where a firewall can be circumvented. Perhaps a machine on the DMZ has a second network card that is connected directly to the internal network – a web designer tired of burning CD’s to upload his prototypes has sorted out a quick solution? Or perhaps a legacy system is still connected to the Internet by a different gateway or modem.

5. Conclusions

The routes by which an attacker can compromise the DMZ are numerous and are dependent on installed software, configuration and network architecture. Existing systems are vulnerable to many of the generic types of attack described here. All systems can become immediately vulnerable due to the nature of the changing threat and the exposure of new exploits on a daily basis. Keeping ahead of the hacker is very difficult with complex network systems that demand high availability as well as strong security in terms of confidentiality and integrity.

5.1. Are there any solutions?

Practical information security both in terms of policy and technology need to be developed and adhered to. Some security software can lighten the load, however users and managers need to be pragmatic since firewalls need careful installation, management (software updates, rule base changes – and associated audit checks), intrusion detection systems need to be installed and managed to maximise their value and require incident handling processes – with people on 24×7 callout in the event of an alert. How can the day-to-day security of an Internet facing enterprise be examined? There are a range of penetration testing activities that can be focused towards checking external access and their potential compromise and also internal security functionality – including human factors. There are ranges of intensities that can be employed in testing from vulnerability scanning through to “Black Hat” intrusion tests that can optionally include the use of malicious code – used exactly in the way an attacker would employ such applications. Security is a process not a product. Information security pervades everything commercially associated with the Internet. Security must be involved in planning, design, construction, configuration, management and support of an information enterprise if it will stand the ultimate test of customer credibility and trust. Defence in depth, like DMZ’s is a military paradigm meaning put as many layers of security between your high value assets and your attacker. A DMZ as a hard-shell, with the soft internal network is not a strong security solution. All hosts on the internal network should be security hardened, monitoring should be carried out on the DMZ and internal network and high value assets should be domain segregated. Remember that enterprise security is only as strong as its weakest link.