4 – Perimeter

A. DEFENDERS: SI-2 FLAW REMEDIATION
[the italicized section below is a security control from NIST SP 800-53]

Control: The organization identifies, reports, and corrects information system flaws.

Guidance: The organization identifies information systems containing proprietary or open source software affected by recently announced software flaws (and potential vulnerabilities resulting from those flaws). Proprietary software can be found in either commercial/government off-the-shelf information technology component products or in custom-developed applications. The organization (or the software developer/vendor in the case of software developed and maintained by a vendor/contractor) promptly installs newly released security relevant patches, service packs, and hot fixes, and tests patches, service packs, and hot fixes for effectiveness and potential side effects on the organization’s information systems before installation. Flaws discovered during security assessments, continuous monitoring (see security controls CA-2, CA-4, or CA-7), or incident response activities (see security control IR-4) should also be addressed expeditiously. NIST Special Publication 800-40 provides guidance on security patch installation.

Control Enhancement 1: The organization centrally manages the flaw remediation process and installs updates automatically without individual user intervention.

Control Enhancement 2: The organization employs automated mechanisms to periodically and upon command determine the state of information system components with regard to flaw remediation.

[the following section is the PHA response to the control described above]
Implementation: PHA requires that operational units identify, report on, and correct information system flaws by installing updates, as appropriate.

Automated mechanisms are to be used to periodically determine the state of systems with regard to updates and to install the updates without individual user intervention. This includes security patches, service packs, and hot-fixes. They must be installed in a reasonable timeframe or in accordance with guidance as issued.

Documentation is to be maintained that shows compliance with the requirement that system updates are being identified and installed in a reasonable timeframe and expeditious manner, and that control responsibility has been assigned and specific actions taken to ensure implementation that consistently applies flaw remediation efforts and that all appropriate information is captured and recorded pertaining to the discovered flaws, including the cause, mitigation activities and lessons learned.

B. ATTACKERS: METASPLOIT
Metasploit is a framework with modular exploit and payload components used to compromise vulnerabilities and penetrate systems. Both command line and web based interfaces are available. Once a system vulnerability has been identified, exploit code that matches the vulnerability is selected from a list and some targeting parameters such as the IP address of the target are set.

metasploit - cli

metasploit - cli

[there are 191 exploits and 106 payloads in this version – the command line interface shown here]

metasploit exploits - cli

metasploit exploits - cli


[some of the exploits – command line interface again]

metasploit payloads - web interface

metasploit payloads - web interface

[some of the payloads – web interface shown here]

evasive options - web interface

evasive options - web interface

[In many cases, evasion options can be set – web interface again]

A payload is selected and configured and the exploit is launched. If the exploit successfully penetrates the system, the payload typically returns command prompt access to the attacker. Metasploit also includes a multi-function payload with advanced features called “Meterpreter”. It runs entirely in system memory and acts as a command interpreter. It can use encryption to remain stealthy, can transfer files, dump password hashes and many more functions. It is extensible and can load DLLs to provide more functionality.

payload options - web interface

payload options - web interface


[payload options – web interface shown]

C. Scenario (Perimeter)
The security updates were being handled fairly well. There was an automated mechanism in place to distribute them. There was no clear policy to establish in what time frame systems should be updated, but in most cases, critical servers were updated within 24-48 hours and most workstations were updated within 5-7 days. More problematic was the fact that in spite of using an automated distribution system, the defenders ability to know which systems had been updated and which had not been updated was sporadic and varied tremendously from site to site. During inspections, while somewhere around 80% of the systems tested had been updated within a week of the latest patch, there were also systems noted that were months out of date and on rare occasions, a system that was years out of date was discovered.

The basic reconnaissance already performed had produced a list of servers that were based on the edge of the perimeter defense. In some cases, the basic recon had provided enough information to allow for some kind of penetration. In other cases, it was simply a URL and an associated IP address.

More detailed reconnaissance was performed by running Nmap scans to identify ports that were open and sometimes the service that was running on the port. The Nmap scans were run with slow and stealthy settings to avoid attracting attention. The attackers had practiced this in the Academy against several different intrusion detection systems and knew what settings were needed to evade most default IDS settings. They also had a list of ports to avoid probing. This “hotlist” of ports was comprised mostly of ports related to classic known trojan programs (like SubSeven and BackOrifice2000) that would trigger an IDS response. An Nmap scan done with default settings will light up most intrusion detection consoles like a Christmas tree. As the hot ports are excluded and the speed and stealth settings are tinkered with, a port scan can be run without so much as a single IDS event being triggered. Through their training in the Academy laboratory, the attackers had become quite proficient at these stealthy tactics. Since perimeter systems are usually buried under a snowstorm of malicious packets of all types, this was probably an unnecessary precaution, but the attackers decided to err on the side of safety.

nmap port scan

nmap port scan


[a routine nmap port scan showing open ports in a laboratory environment]

A second layer of recon scanning was done using Nessus to identify vulnerabilities in the perimeter systems. While Nessus scans are usually quite noisy, again the team elected to do them as slowly and with options carefully selected to keep the chance of being noticed at a minimum. The map of ports open and services running produced by nmap gave the attackers a reasonably good idea of what OS was running on the target system and how to tune the scan to be most effective.

nessus report

nessus report


[the front page of Nessus scan showing holes found in a server that may be exploitable – note: the IP address was on a private network for lab exercises]

The perimeter attack team had defined many security holes in the edge defenses that would allow penetration, but they were worried that exploits against these old vulnerabilities would be noticed by any intrusion detection defenses and so alert the defenses to their penetration efforts. The value of knowledge to be gained by measuring the response and assessing the viability of any intrusion detection capability was weighed carefully against the need for caution and in the end they decided not to use the old exploits yet, but to wait until either a zero-day hole allowed them to slip through unnoticed, or one of the other teams had identified the defenses to a point where they knew they would not be detected. In the meantime, they continued probing whenever security updates were released (ones that did not offer penetration opportunities) to confirm the time frame in which the defenders normally did their patching and even identified a few sites that were slower than the rest. This could turn out to be very useful later.

Leave a Reply

You must be logged in to post a comment.