Tải bản đầy đủ
Chapter 12. Hypertext Transfer Protocol (HTTP)

Chapter 12. Hypertext Transfer Protocol (HTTP)

Tải bản đầy đủ

AU0888_C01.fm Page 10 Wednesday, October 1, 2003 5:43 AM









Viruses
Worms
Hoaxes
Backdoors
Logic bombs
Spyware
Adware

The chapter also details some of the programming and scripting languages and application facilities that are used to produce hostile code.
Chapter 15. Network Hardware
Chapter 15 addresses vulnerabilities in network hardware and associated
firmware, operating systems, and software. The chapter opens with a
broad discussion of the growing significance of network hardware (routers,
switches, etc.) as a target for hacking activity and by providing a broad
overview of the types of hacking exploits to which each hardware component (hardware, firmware, software) is susceptible:










Attacks against routing or switching infrastructures
Routing protocol attacks (RIP, OSPF, etc.)
Management attacks (SNMP, HTTP, etc.)
Operating system/Internet operating system (OS/IOS) attacks
Denial-of-service
Wireless hacking
Packet switching attacks
Remote access attacks
Attacks against redundant network components

The final chapter section addresses the security options in network
hardware, protocol, management, and operating system (OS) facilities that
can be leveraged to harden a network device or network, including packet
flooding controls, wireless network security, OS/IOS hardening, routing
protocol access control lists, and authentication controls.
Chapter 16. Consolidating Gains
Chapter 16 is the first of two chapters to address the tactics and tools
employed by attackers to consolidate their position on a system or network — essentially, the tasks that are undertaken by attackers to ensure
consistent, covert access to a system or network resource or to extend
their privileges as they relate to that resource. It demonstrates the effectiveness of the hacking community’s knowledge of common system
administration practices, standard system builds, and default application
configurations; the intent of this chapter is to attempt to inform the way
in which system and network administrators approach the management
of these facilities from a “counter-tactics” perspective.
© 2004 by CRC Press LLC

AU0888_C01.fm Page 11 Wednesday, October 1, 2003 5:43 AM

Consolidating Gains explores the use of standard operating systems and
network facilities for consolidation activities, in addition to the application
of “foreign” exploit code:
• Standard OS and network facilities
– Account and privilege management facilities
– File system and input/output (I/O) resources
– Service management facilities
– Process management facilities
– Devices and device management facilities
– Libraries and shared libraries
– Shell access and command line interfaces
– Registry facilities (NT/2000)
– Client software
– Listeners and network services
– Network trust relationships
– Application environment
• Foreign code
– Trojan horses
– Backdoors (including Trojan backdoors)
– Rootkits
– Kernel-level rootkits
The closing section of the chapter presents a collection of procedures
and tools that can be used to stem consolidation activities; the focus of this
material is cross-platform system hardening strategy.
Chapter 17. After the Fall
After the Fall addresses forensics evasion and forensics investigation.
From a hacking perspective, this includes the techniques and tools hackers employ to evade audit or logging controls and intrusion detection
mechanisms, as well as covert techniques used to frustrate investigative
actions and avoid detection. For the system or network administrator, a
considerable amount of material on the preparations that should occur
prior to a security incident is presented, along with measures for protecting audit trails and evidence.
The following types of hacking exploits are addressed:
• Logging and auditing evasion (by platform): NT/2000; UNIX; router;
authentication, authorization, and accounting (AAA) protocols, etc.
• Intrusion detection system (IDS) evasion (linked to material in
Chapter 5, “Your Defensive Arsenal”)
• Forensics evasion
– Environment sanitization
– File hiding (including steganography, cryptography) and file
system manipulation
– Covert network activities (including IP tunneling, traffic normalization)
© 2004 by CRC Press LLC

AU0888_C01.fm Page 12 Wednesday, October 1, 2003 5:43 AM

The chapter closes with an examination of the types of tools and tactics
security administrators can leverage to improve capabilities to detect and
investigate security incidents, including protections for log files and audit
trails, IDS, data correlation solutions, forensics technologies, and incident
handling capabilities.
Chapter 18. Conclusion
The final chapter of The Hacker’s Handbook reviews the case study material
presented in Chapter 2 in the context of the technical material presented
throughout the book. The case study is examined from the attacker’s perspective and from the perspective of a network administrator investigating
the incident.
The chapter concludes with a set of references that supplement the
references provided at the end of each chapter:





Security sites
“Underground” sites
Technical standards
Ongoing technical “themes” in hacking and security

© 2004 by CRC Press LLC

AU0888_C02.fm Page 13 Wednesday, October 1, 2003 5:44 AM

Part I

Foundation
Material

© 2004 by CRC Press LLC

AU0888_C02.fm Page 15 Wednesday, October 1, 2003 5:44 AM

Chapter 2

Case Study
in Subversion
This case study — really the “chess game” at work — is unique among the
chapters presented in this book. The case study examines the actions of a
fictitious administrator, hacker, and investigator in the context of a series
of security events that beset a fictional company (Dalmedica). These
events are depicted from a “defensive” standpoint — from the standpoint
of the administrator and investigator trying to make sense of them — using
a “real” network. The network, systems, and application environment chosen for the case study is dynamic, transitions over the course of the study
timeline, and is representative of a reasonably sound security design. The
events that occur are illustrations of hacking exploits and attacks presented
in the remainder of the book but are represented from a “symptomatic” perspective; later chapters illuminate and explain the types of attacks alluded
to in the case study.
This chapter is paired with the Conclusion (Chapter 18) of the book,
which revisits the case study material from the attacker’s perspective.
Dalmedica
Dalmedica is a (fictitious) six-year-old public corporation that develops
software for the medical industry. Its most recent software development
venture — due for release at some point over the next three months —
involves a product called Medicabase that assists medical researchers in
analyzing, correlating, and securing patient data as part of clinical trial
management. Dalmedica has been aggressively marketing some of the
concepts behind Medicabase for some time, and the software has become
somewhat controversial because of the “hooks” it potentially provides third
parties into patient clinical data. Competitors have shown interest in the
product from a competitive standpoint because of its technological
advances and have been scouting for ways to further some of the “political”
controversy surrounding the product in the hopes that this will negatively
impact sales and market share once it goes to market.
Dalmedica operates a medium-sized network of some 650 nodes (see
Exhibit 1). The company went through a significant network efficiency

© 2004 by CRC Press LLC

AU0888_C02.fm Page 16 Wednesday, October 1, 2003 5:44 AM

INTERNET

ISP-Managed Router
.246

204.70.10.240/29 (Publicly Addressed IP Network)

IDS
.245

.241
Load Balancing Device
VPN Server

.224

Dial-up Server

Internet DMZ
204.70.10.224/28
(Publicly
Addressed IP
Network)

Stateful Packet Filtering
Firewall
.208
.193

Partner Extranet

IDS
Web Farm
.228, .229, .230

.194, .195

Extranet DMZ

204.70.10.192/28 (Publicly Addressed IP Network)
.221

204.70.10.208/28 (Publicly Addressed IP Network)
.210

.209

.211

Partner Network Connection
(Router ACLs)

Partner Net
SMTP Gateway
(Anti-Virus and
Content Filtering)

Application Proxy Firewall
(Primary (Public) DNS Server)
172.30.0.1

Web Content
Filtering
Gateway

Private LAN (172.30.0.0/16)

Corporate LAN
(Switched to the Desktop)

QA/Development LAN
(Fully Switched)
DNS Server(s)
(Primary and
Secondary)
IDS

Clients, Printers, etc.
(500 nodes)

Syslog
Server

Server Network
(Fully Switched)

Clients
Development Servers
(UNIX/NT)

Database
Servers
Corporate
Mail Server

Exhibit 1.

Active Directory/
Domain Controller
(and Backup Domain
Controllers)

Network Diagram

assessment and reorganization two years ago, and the internal network is
(for the most part) fully switched and organized into virtual local area networks (VLANs) that correspond with operational domains (development,
quality assurance [QA], finance, etc.). The security architecture consists of
© 2004 by CRC Press LLC

AU0888_C02.fm Page 17 Wednesday, October 1, 2003 5:44 AM

a two-tier firewall environment (stateful perimeter firewall, applicationlevel local area network [LAN] firewall), with network-based intrusion
detection systems (IDSs) in place at the Internet connection, on the Web
demilitarized zone (DMZ), and on the private LAN. Dalmedica uses a splitlevel (public vs. private) Domain Name System (DNS) configuration1 and
has implemented a mail gateway and content scanning gateway that scan
all mail and Web content exiting or entering the main corporate LAN. Logging is centralized via a syslog server (although local logging is still performed on a number of systems) and a Microsoft Active Directory/Domain
architecture has been established to authenticate users to specific
resources on the network.
From an administrative perspective, network, systems, and application
administration is divided among several technical groups that fall under the
corporate information technology (IT) function. Security management is
performed by a parallel organization that consists of policy and technology
branches and interfaces with respective groups within IT. IT and security
operations are primarily integrated via the corporate incident handling
team, which meets on a regular basis to inspect and respond to vulnerability
reports and security threats. Web and operations application development
is considered a development function and is managed within the development organization, subject to the same development and QA process as
product software development.
Dalmedica leverages consultants for specific project tasks and contracts
an outside security consulting firm to perform a periodic annual security
risk assessment and to conduct external and extranet penetration testing, as deemed appropriate. Dalmedica security management also has the
ability to call in specialists, such as forensic specialists or criminal investigators, where necessary, although the company has never had cause to
do this.
The Dilemma
Scott Matthews was confused by what was happening. Within the last ten
minutes, two critical problems had emerged on the network: no network
clients could get out to the Internet, and Internet users were having problems accessing Dalmedica’s Web servers. His first instinct was that it was
a connectivity problem, and so he telnet-ed to Dalmedica’s Internet
router, ran a series of ICMP connectivity tests to the next hop router and
arbitrary Internet sites, and placed a call to EnterISP, Dalmedica’s Internet
service provider.
“Hi, this is Scott Matthews, network operations manager for Dalmedica.
We’re seeing some Internet connectivity problems that I was wondering if
you could help me investigate?” The technician worked with Scott in
inspecting packet response times to and from Dalmedica’s Internet handoff

© 2004 by CRC Press LLC

AU0888_C02.fm Page 18 Wednesday, October 1, 2003 5:44 AM

and identified that there was some latency and congestion not just on
Dalmedica’s Internet link but also on associated areas of EnterISP’s network.
Traceroutes to Dalmedica’s Internet router revealed the following:
$ traceroute gw.dalmedica.com
tracing route to gw.dalmedica.com (204.70.10.246), 30 hops
max
1 gw1.enterisp.net (211.198.12.30) 5.412ms 5.112ms 5.613ms
2 core1.enterisp.net (211.197.22.15) 30.160ms 34.576ms
34.180ms
3 core2.enterisp.net (210.105.60.17) 770.433ms 890.899ms
920.891ms
4 gw.Dalmedica.com (204.70.10.246) * * * Request timed out.

“Scott, let me examine this a little further, and I’ll get back to you,” the
technician responded. Scott and the technician exchanged contact information and hung up. Scott sat back in his chair, paged through the messages on
his pager and thought for a second. Returning access to the corporate Web
servers was probably the highest priority — perhaps it was worthwhile
taking a couple of seconds to examine the firewall log files. He started a
session to the corporate application proxy firewall using a firewall management client and inspected the current log file. What he saw startled him —
hundreds of DNS connection requests for domains for which the firewall
(Dalmedica’s primary/public DNS server) was not authoritative. “**?%~!,”
he exclaimed, “a denial-of-service attack?”2 A bevy of source addresses
was associated with the recursive DNS requests; Scott performed a couple
of DNS IP-to-hostname lookups using nslookup to try to identify some of
them. A portion returned hostnames:3
nslookup
Default server: ns1.enterisp.net
Address: 210.10.10.249
> set q = ptr
> 8.60.122.199.in-addr.arpa
8.60.233.199.in-addr.arpa Name = bandit.mischevious.com
> 9.150.17.66.in-addr.arpa
9.150.17.66.in-addr.arpa Name = rogue.outasitecollege.edu

“Oh, this looks worse and worse.” He was just considering his next move
(and expletive) when his manager popped his head around the door.
“Scott, what’s going on?” questioned Bob.
Scott responded with “Someone is mounting what appears to be a
denial-of-service against us, but I think I can stem it by turning off support
for Internet recursion at the firewall.3 I’ll still need to contact EnterISP to

© 2004 by CRC Press LLC

AU0888_C02.fm Page 19 Wednesday, October 1, 2003 5:44 AM

see if they can help me stem any associated packet flooding. Also, our desktops don’t seem to be able to get out to the Internet; this may be a related
problem due to the link congestion.”
“Well, whatever it is, we need to get to the bottom of it quickly,” stated
Bob, “Tom Byrd just informed me that marketing is getting ready to put out
a preliminary press release on Medicabase this morning, and they’ll be
posting a link to additional information on our Web site. Let me know if you
get stalled with this…”
Scott visibly sank in his chair — it was days like this when he wished
he had abandoned a technical career and taken up something “safe” such
as vertical freefall skydiving. He focused, turned back to the firewall, and
disabled support for Internet recursion — this would have no impact on
Dalmedica Web site access but would prevent the attacker from being
able to force the firewall/name server to perform exhaustive Internet
lookups on behalf of anonymous hosts. Performance at the firewall
seemed to leap as the change was successfully written out.
Scott turned to his phone and called the head of the security incident
handling team — Mike Turner — and informed him that he thought he had a
security incident on his hands. “OK, keep calm,” stated Mike (in a panicked
voice), “I’ll contact a couple of people and we’ll start an investigation to
determine if this is a legitimate incident.”
Dalmedica’s LAN clients were still experiencing problems accessing the
Internet — Scott noted that there was an absence of the general HTTP
“clutter” he was used to seeing in the firewall log files. He waited a minute,
willing the screen to start popping client HTTP requests — nothing. “Ah,
there’s one,” he exclaimed, as a lone entry populated the log file, “Hmmm…
something’s not right here...” He swung around in his seat to a server
sitting next to him, and started a browser session to an Internet Web site
(see Exhibit 2).
Scott was confounded. He went to the command prompt on the system,
fired up nslookup and tried performing DNS lookups for some well-known
Internet sites:
C:\>nslookup
DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 210.10.10.249: Timed
out
*** Default servers are not available
Default Server: UnKnown
Address: 210.10.10.249

© 2004 by CRC Press LLC

AU0888_C02.fm Page 20 Wednesday, October 1, 2003 5:44 AM

Exhibit 2.

Failed Attempt to Connect

> set q = any
> www.enterisp.net
Server: UnKnown
Address: 210.10.10.249
*** UnKnown can't find www.enterisp.net: No response from
server
>

As each successive DNS request failed, he sagged. Scott swung back to
the firewall, launched a command prompt, and used nslookup to perform
some DNS lookups. Every DNS request he issued from the firewall received
a successful response. Intrigued, Scott pondered the problem for a second.
He checked the resolver configuration on the “test” client as a sanity check
and concluded that it was possible that this was a separate problem from
the DNS denial-of-service and that it was worth inspecting the configuration and logs on the internal DNS server. The log on the internal DNS server
revealed the following:
a.root-servers.net.

198.41.0.4

Can’t contact root NS:
a-root.servers.net

b.root-servers.net.

128.9.0.107

Can’t contact root NS:
b-root.servers.net

c.root-servers.net.

192.33.4.12

Can’t contact root NS:
c-root.servers.net

© 2004 by CRC Press LLC

AU0888_C02.fm Page 21 Wednesday, October 1, 2003 5:44 AM

Scott shook his head. What was this? Had anyone performed any recent
updates to the DNS server? A cursory inspection of the log didn’t reveal
anything. He placed a call to the group responsible for DNS and IP management within IT/systems and requested some assistance in investigating the
problem. “Check the root name server hints file, which is located at
c:\winnt\system32\dns,” responded the administrator. “It should point to
the corporate firewall because we’re proxying DNS connections to the
firewall.” Scott reviewed the contents of the file.
“It looks like a standard root name server hints file to me,” he stated.
“It contains a list of all of the Internet Root name servers and their respective IP addresses.”
The DNS administrator was perplexed. “Well, there’s your problem.
I don’t know who would have reverted the configuration, but you need to
stop the DNS server, rename that file, and replace it with a file that uses the
firewall’s inside interface as a root NS — that should solve the problem.”
Scott accomplished the necessary changes and saw the firewall log file
“leap” with the familiar HTTP clutter. He breathed a sigh of relief and
picked up the phone to call his manager and report a successful return to
normal operations. At that moment, Mike Turner, the head of the security
incident team, appeared behind him. “So Scott, how are we doing?”
“Well, we’re back to normal,” stated Scott, “…but I’d be grateful if you’d
work with our ISP to try to determine who was mounting the DNS denial-ofservice — I’m going to grab some coffee.”
***
Later that day, as Scott was returning from a long lunch and passing the
development lab, he spotted a number of engineers and the development
lab administrator crouched around a single terminal. He swiped his badge
at the lab card reader and swept into the lab. “Hi guys, what’s going on?” he
asked cheerfully, to the pained expressions in front of him.
“We’re not sure yet,” replied one of the engineers. “It looks like we’re
having a problem with some library corruption in one of the libraries on
the source code server.”
“Can we recover?” asked Scott.
“Well, we can…” the source code librarian, Neil Beck responded, “…but I’d
like to figure out how it happened so that we can prevent it from recurring.”
Scott nodded. He exited the server room and headed to a nearby conference room for a management meeting to discuss the morning’s events. The
ISP had not been able to trace the absolute source of the denial-of-service
attack that occurred that morning but had gathered sufficient information
to indicate that the attack was well organized and executed, and that it

© 2004 by CRC Press LLC