Network Security Assessment, 3rd Edition

Chapter 1. Introduction to Network Security Assessment

This chapter introduces the underlying economic principles behind computer network exploitation and defense, describing the current state of affairs and recent changes to the landscape. To realize a defendable environment, you must adopt a proactive approach to security—one that starts with assessment to understand your exposure. Many different flavors of assessment exist, from static analysis of a given application and its code to dynamic testing of running systems. I categorize the testing options here, and list the domains that this book covers in detail.

The State of the Art

I started work on the first edition of this book almost 20 years ago, before computer network exploitation was industrialized by governments and organized criminals to the scale we know today. The zero-day exploit sales business was yet to exist, and hackers were the apex predator online, trading warez over IRC.

The current state of affairs is deeply concerning. Modern life relies heavily on computer networks and applications, which are complex and accelerating in many directions (think cloud applications, medical devices, and self-driving cars). Increasing consumer uptake of flawed products introduces vulnerability.

The Internet is the primary enabler of the global economic system, and relied on for just about everything. An International Institute for Applied Systems Analysis (IIASA) study predicted that total loss of Internet service in a country would lead to a failure of the food supply chain within three days.¹

Victims of attack often realize acute negative economic impact. In 2009, the Stuxnet worm sabotaged an Iranian uranium enrichment facility in Natanz, reducing operational capacity by 30 percent for a period of months.² In 2012, the world’s most valuable company, Saudi Aramco, suffered a malware outbreak that paralyzed the company for a 10-day period.³ Crippling attacks have continued into 2015 and 2016, as Sony Pictures Entertainment and the Hollywood Presbyterian Medical Center suffered outages.⁴

A glaring gap exists between resourceful adversaries and those tasked with protecting computer networks. Thanks to increasing workforce mobility, adoption of wireless technologies, and cloud services, the systems of even the most security-conscious organizations, including Facebook,⁵ can be commandeered. To make matters worse, critical flaws have been uncovered in the very technologies and libraries we use to provide assurance through cryptography, including:

• RSA BSAFE, using the flawed Dual_EC_DRBG algorithm by default⁶

• The OpenSSL 1.0.1 heartbeat extension information leak⁷

Defendable networks exist, but are often small, high-assurance enclaves built by organizations within the defense industrial base. Such enclaves are tightly configured and monitored, running trusted operating systems and evaluated software. Many also use hardware to enforce one-way communication between particular system components. These hardened environments are not unassailable, but can be effectively defended through active monitoring.

The networks most at risk are those with a large number of elements. Multiple entry points increase the potential for compromise, and risk management becomes difficult. These factors create the defender’s dilemma—by which a defender must ensure the integrity of an entire system, but an attacker only needs to exploit a single flaw.

Threats and Attack Surface

Adversaries who actively compromise computer systems include state-sponsored organizations, organized criminals, and amateur enthusiasts. Benefiting from deeper resources than the other groups combined, state-sponsored attackers have become the apex predator online.

Upon understanding attack surface, you can begin to quantify risk. The exposed attack surfaces of most enterprises include client systems (e.g., laptops and mobile devices), Internet-based servers, web applications, and network infrastructure (e.g., VPN devices, routers, and firewalls).

Attacking Client Software

Desktop applications and client software packages (e.g., Microsoft Office; web browsers, including Google Chrome; and utilities such as PuTTY) can be attacked directly by an adversary with network access, or indirectly by an attacker sending malicious content to be parsed (such as a crafted Microsoft Excel file).

To demonstrate the insecurity of client software packages, you only need to look at the results of Pwn2Own competitions. In 2014, the French security firm VUPEN⁸ won $400,000 after successfully exploiting Microsoft Internet Explorer 11, Adobe Reader XI, Google Chrome, Adobe Flash, and Mozilla Firefox on a 64-bit version of Windows 8.1. The company used a total of 11 distinct zero-day exploits to achieve its goals.⁹

Attackers with network access commonly exploit browser flaws to target high-value assets (e.g., systems administrators of organizations such as OPEC¹⁰) by injecting malicious content into a plaintext HTTP session via man-in-the-middle (MITM), as demonstrated by Figure 1-1.

Figure 1-1. Network access used to deliver malicious content

Warning

MITM attacks are not constrained to plaintext network sessions. A resourceful attacker with network access could compromise a legitimate encrypted session (such as HTTPS) upon obtaining private key material through a software flaw or by exploiting operational security shortcomings.

Attacking Server Software

Server software has not fared any better, thanks to increasing layers of abstraction and adoption of emerging technologies. The Rails application server and Nginx reverse proxy both suffered from severe code execution flaws in 2013, as follows:

• Rails 2.3 and 3.x Action Pack YAML deserialization flaw¹¹

• Nginx 1.3.9 to 1.4.0 chunked encoding stack overflow¹²

The Nginx chunked encoding flaw is similar to that found by Neel Mehta in 2002 within the Apache HTTP Server¹³—demonstrating how known issues appear within new packages as developers fail to look backward.

Attacking Web Applications

Vulnerability within web applications stems from additional feature support and increasing exposure of APIs between components. One particularly severe class of problem is XML external entity (XXE) parsing, by which malicious content is presented to a web application and sensitive content returned. In 2014, researchers uncovered multiple XXE parsing flaws within the Google production environment. In one case, XML content was uploaded to the Google Public Data Explorer utility,¹⁴ defining an external entity:

<!ENTITY % payload SYSTEM "file:///etc/">
<!ENTITY % param1 '<!ENTITY &#37; internal SYSTEM "%payload;" >' >
%param1; %internal;

Example 1-1 shows the malicious XML parsed server-side, revealing the contents of /etc/.

Example 1-1. Exposed files within Google’s environment via XXE parsing

XML parsing error. Line 2, Column: 87: no protocol: bash.bashrc bashrc bashrc.google borgattrs.d 
borgattrs-msv.d borgletconf.d capabilities chroots chroots.d container.d cron cron.15minly 
cron.5minly cron.d cron.daily cron.hourly cron.monthly cron.weekly crontab csh.cshrc csh.login 
csh.logout debian_version default dpkg fsck.d fstab google googleCA googlekeys groff group 
host.conf hosts hotplug init.d inittab inputrc ioctl.save iproute2 issue issue.net kernel 
lilo.conf lilo.conf.old localbabysitter.d localbabysitter-msv.d localtime localtime.README 
login.defs logmanagerd logrotate.conf logrotate.d lsb-base lsb-release magic magic.mime mail 
mail.rc manpath.config mced mime.types mke2fs.conf modprobe.conf modprobe.d motd 
msv-configuration msv-managed mtab noraidcheck nsswitch.conf passwd passwd.borg perfconfig 
prodimage-release-notes profile protocols rc.local rc.machine rc0.d rc1.d rc2.d rc3.d rc4.d 
rc5.d rc6.d rcS.d resolv.conf rpc securetty services shadow shells skel ssdtab ssh sudoers 
sysconfig sysctl.conf sysctl.d syslog.d syslog-ng_configs_src syslog-ng.conf sysstat 
tidylogs.d vim wgetrc

Exposed Logic

One way to understand attack surface within a computer system is to consider the exposed logic that exists. Such logic could be part of an Internet-accessible network service (e.g., support for compression or chunked encoding within a web server), or a parsing mechanism used by a client (such as PDF rendering). Locally within operating systems, privileged kernel components and device drivers expose logic to running applications.

Attack surface is logic (usually privileged) that can be manipulated by an adversary for gain—whether revealing secrets, facilitating code execution, or inducing denial of service. Exposed logic is targeted by network-based attackers in two ways:

• Directly via a vulnerable function within an exposed network service.

• Indirectly, such as a parser running within a client system that is provided with malicious material through MITM attack, email, messaging, or other means.

Exposed logic examples

A useful example is the GNU bash command execution flaw known as shellshock.¹⁵ Many applications within Unix-based systems (including Linux and Apple OS X) use the bash command shell as a broker to perform low-level system operations. In 1989, a flaw was introduced which meant that arbitrary commands could be executed by passing malicious environment variables to bash. The issue was uncovered 25 years later by Stéphane Chazelas.¹⁶

To exploit the flaw, an attacker must identify a path through which user-controlled content is passed to the vulnerable command shell. Two examples of remotely exploitable paths and preconditions are as follows:

Apache HTTP Server

Presenting a User-Agent header containing a malicious environment variable to a CGI script via mod_cgi results in command execution, as demonstrated by Metasploit.¹⁷

DHCP

Many DHCP clients pass and execute commands through bash when configuring network interfaces. Upon configuring a rogue DHCP server to send malicious environment variables within DHCP responses to clients, arbitrary commands are executed on vulnerable systems, as demonstrated by Metasploit.¹⁸

Exploiting exposed logic

The security research industry is built upon the exploitation of exposed logic to perform a valuable action. Most browser exploits rely on the chaining of multiple defects to bypass security protections and execute arbitrary code.

In 2012, renowned hacker Pinkie Pie developed a Google Chrome exploit that used six distinct flaws to achieve code execution.¹⁹ He found exploitable conditions within components including Chrome prerendering, GPU command buffers, the IPC layer, and extensions manager.

Low-level software assessment is an art form, by which a relatively small number of skilled researchers uncover subtle defects in software and chain them together for gain. During each iterative testing step, the available attack surface is evaluated to identify risks to the larger system.

Assessment Flavors

To map and test the exposed logic paths of a system, organizations adopt a variety of approaches. In the marketplace today, there are many vendors providing static and dynamic testing services, along with analysis tools used to identify potential risks and vulnerabilities.

Static Analysis

Auditing application source code, server configuration, infrastructure configuration, and architecture might be time consuming, but it is one of the most effective ways of identifying vulnerabilities in a system. A drawback of static analysis within a large environment is the cost (primarily due to the sheer volume of material produced by these tools, and the cost of tuning out false positives), and so it is important to scope testing narrowly and prioritize efforts correctly.

Technical audit and review approaches include:

• Design review

• Configuration review

• Static code analysis

Less technical considerations might include data classification and labeling, review of the physical environment, personnel security, as well as education, training, and awareness.

Design review

Review of system architecture involves first understanding the placement and configuration of security controls within the environment (whether network-based controls such as ACLs or low-level system controls such as sandboxes), evaluating the efficacy of those controls, and where applicable, proposing changes to the architecture.

Common Criteria²⁰ is an international standard for computer security certification, applicable to operating systems, applications, and products with security claims. Seven assurance levels exist, from EAL1 (functionally tested) through EAL4 (methodically designed, tested, and reviewed) to EAL7 (formally verified design and tested). Many commercial operating systems are typically evaluated at EAL4, and operating systems that provide multilevel security are evaluated at a minimum of EAL4. Other programs exist, including the UK’s CESG CPA scheme.

Formally verifying the design of a system can be a costly exercise. Often, a cursory architecture review by an experienced security professional will highlight potential pitfalls and issues that should be mitigated, such as poor network segmentation, or insufficient protection of data in-transit.

Configuration review

Low-level audit of system components can include review of infrastructure (i.e., firewalls, routers, switches, storage, and virtualization infrastructure), server and appliance operating system configuration (e.g., Windows Server, Linux, or F5 Networks hardware), and application configuration (such as Apache or OpenSSL server configuration).

Organizations such as NIST, NSA, and DISA provide checklists and configuration guidelines for operating systems, including Apple OS X, Microsoft Windows, and Linux. These resources are available online:

• NIST’s “National Checklist Program Repository”

• NSA’s “IA Guidance”

• DISA’s “Security Technical Implementation Guides (STIGs)”

By performing gap analysis against these standards, it is possible to identify shortcomings in operating system configuration, and work to ensure a uniform hardened configuration across an environment. Bulk vulnerability scanners (including Rapid7 Nexpose) include DISA STIG scan policies, and so identification of gaps is straightforward through authenticated testing.

Static code analysis

NIST and Wikipedia maintain lists of code analysis tools, as follows:

• NIST’s “Source Code Security Analyzers”

• Wikipedia’s “List of Tools for Static Code Analysis”

Such tools identify common flaws in software written in languages such as C/C++, Java, and Microsoft .NET. The HP Fortify team published a taxonomy of software security errors²¹ that can be identified through static code analysis, including input validation and representation, API abuse, flawed security features, time and state vulnerabilities, and error handling flaws. Chapter 3 discusses these categories in detail.

Static code analysis tools require tuning to reduce noise within their results and focus findings around accessible code paths (e.g., flaws that can be practically exploited). Such low-level static analysis is suited to critical system components, as the cost of reviewing the output can be considerable.

Dynamic Testing

Exposed logic is assessed through dynamic testing of running systems, including:

• Network infrastructure testing

• Web application testing

• Web service testing (e.g., APIs supporting mobile applications)

• Internet-based social engineering

As testing is undertaken from the perspective of an assailant (e.g., an unauthenticated network-based attacker, an authenticated application user, or a mobile client), findings are aligned with legitimate threats to the system.

Network infrastructure testing

Scanning tools (e.g., Nmap, Nessus, Rapid7 Nexpose, and QualysGuard), map and assess the network attack surface of an environment for known vulnerabilities. Manual assessment cycles are then applied to investigate the attack surface further, and evaluate accessible network services.

Internal network testing can also be undertaken to identify and exploit vulnerabilities across OSI Layers 2 and 3 (such as ARP cache poisoning and 802.1Q VLAN hopping). Chapter 5 discusses network discovery and assessment techniques that should be adopted locally to identify weaknesses.

Web application testing

Web application logic is commonly assessed in an unauthenticated or authenticated fashion. Most organizations opt for authenticated testing of applications, emulating assailants with valid credentials or session tokens who seeks to elevate their privileges.

The Open Web Application Security Project (OWASP) Top 10 is a list of common web application flaws. Tools that can reliably test for such flaws include Burp Suite, IBM Security AppScan, HP WebInspect, and Acunetix. These tools provide testing capabilities that let organizations broadly scan their exposed web application logic for common issues, including cross-site scripting (XSS), cross-site request forgery (CSRF), command injection session management flaws, and information leak bugs. Deep web application testing is out of scope for this book; however, Chapters 12 through 14 detail assessment of web servers and application frameworks.

Note

During 2012 and 2013, I performed incident response and forensics work for companies that had fallen victim to attack by Alexsey Belan. In each case, he compromised internal web applications to escalate privileges and move laterally. This highlights the importance of testing and hardening web applications within your environment that are not Internet-accessible.

Web service testing

Mobile and web applications use server-side APIs and perform an increasing amount of processing on the client system. APIs are often exposed to end users (such as a user with a mobile online banking client), third parties (such as business partners or affiliates), and internal application components, as shown in Figure 1-2.

Figure 1-2. Web services used within web applications

REST APIs are used in many applications that take advantage of mature HTTP functionality (including caching and keep-alive features). Web service testing involves using an attack proxy to analyze and manipulate messages and content flowing between the client and server endpoint. You also can undertake Active fuzzing of REST API services to identify security flaws.

Internet-based social engineering

During my career, some of the largest compromises I’ve accomplished during testing have come about through Internet-based social engineering. Two effective attack scenarios are as follows:

• Configuring an Internet-based web server masquerading as a legitimate resource, and then emailing users with material including a link to the malicious page.

• Sending malicious material (e.g., a crafted document to exploit Microsoft Excel or Adobe Acrobat Reader) directly to the user via email, messaging, or other means, from a seemingly trusted source, such as a friend or colleague.

I recently undertook an Internet-based spear phishing exercise against a financial services organization, involving a fake SSL VPN endpoint and instructions to log into the “new corporate VPN gateway” emailed to 200 users. Within two hours, 13 users had entered their Active Directory username, domain password, and two-factor authentication token value. Chapter 9 details phishing tactics and tools.

What This Book Covers

This book covers dynamic testing of network devices, operating systems, and exposed services in detail, but avoids static analysis and auditing topics. Web application testing is out of scope, along with Voice over Internet Protocol (VoIP), and assessment of 802.11 wireless protocols. These three topics already fill entire books, including the following:

• The Web Application Hacker’s Handbook, by Dafydd Stuttard and Marcus Pinto (Wiley, 2011)

• Hacking Exposed Unified Communications & VoIP, by Mark Collier and David Endler (McGraw-Hill, 2013)

• Hacking Exposed Wireless, by Johnny Cache, Joshua Wright, and Vincent Liu (McGraw-Hill, 2010)

¹ Leena Ilmola-Sheppard and John Casti, “Case Study: Seven Shocks and Finland”, Innovation and Supply Chain Management 7, no. 3 (2013): 112–124.

² Kim Zetter, “An Unprecedented Look at Stuxnet, the World’s First Digital Weapon”, Wired, November 3, 2014.

³ John Leyden, “Hack on Saudi Aramco Hit 30,000 Workstations, Oil Firm Admits”, The Register, August 29, 2012.

⁴ Peter Elkins, “Inside the Hack of the Century”, Fortune.com, June 25, 2015; Robert Mclean, “Hospital Pays Bitcoin Ransom After Malware Attack”, CNN Money, February 17, 2016.

⁵ Orange Tsai, “How I Hacked Facebook, and Found Someone’s Backdoor Script”, DEVCORE Blog, April 21, 2016.

⁶ Joseph Menn, “Secret Contract Tied NSA and Security Industry Pioneer”, Reuters, December 20, 2013.

⁷ See CVE-2014-0160.

⁸ In 2015, VUPEN ceased operations and its founders launched ZERODIUM.

⁹ Michael Mimoso, “VUPEN Discloses Details of Patched Firefox Pwn2Own Zero-Day”, Threatpost Blog, May 21, 2014.

¹⁰ SPIEGEL Staff, “Oil Espionage: How the NSA and GCHQ Spied on OPEC”, SPIEGEL ONLINE, November 11, 2013.

¹¹ See CVE-2013-0156.

¹² See CVE-2013-2028.

¹³ See CVE-2002-0392.

¹⁴ See http://examples.oreilly.com/networksa/tools/google-xxe.pdf.

¹⁵ See CVE-2014-6271.

¹⁶ Nicole Perlroth, “Security Experts Expect ‘Shellshock’ Software Bug in Bash to Be Significant”, New York Times, September 25, 2014.

¹⁷ Metasploit apache_mod_cgi_bash_env_exec module.

¹⁸ Metasploit dhclient_bash_env module.

¹⁹ Jorge Lucangeli Obes and Justin Schuh, “A Tale of Two Pwnies (Part I)”, Chromium Blog, May 22, 2012.

²⁰ See ISO/IEC 15408.

²¹ See https://vulncat.hpefod.com.