荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: Lg (创造人生的传奇), 信区: Linux
标 题: Anatomy of a Network Intrusion
发信站: BBS 荔园晨风站 (Sun Dec 12 16:02:16 1999), 站内信件
Greg Shipley
Empty Red Bull cans litter the floor, reflecting the warm
glow of the monitors.
Alongside the sketch boards lie drained liters of Mountain
Dew, partially eaten
burritos and dozens of 486 machines configured as Linux
Beowulf clusters. A
Pentium II machine plugged into a seemingly endless line of
surge suppressors
hums as it continues to brute-force password guesses at a
rate of 10 million per
second. Only 12 more hours to go...
All the machines have their lids off-no hard-core geek is
ever satisfied with the
state of a system. Legal pads are covered with IP addresses,
penciled network
maps and port numbers. As the attackers' scripts relentlessly
scan for the
presence of the recently identified CGI vulnerability, they
continue to exchange
notes with the crew on IRC (Internet Relay Chat). They figure
once they've
compromised a few dozen ISPs-creating a network of "stepping
stones"-they
can forge ahead to their target.
It's all about buffer space-a disposable safety net with a
redo button. If they
"own" a dozen machines between them and their target, they
can attack with
the confidence that only a cyborg in a time machine could
ever gather enough
info to snag them-only a handful of organizations have the
manpower or
expertise to catch intruders who leave no trail. Attack,
clean, reattack-and gain
as much net space as possible.
Auditor? Cracker? Strung-out administrator? The roles can be
interchanged and
the distinction blurred, with one exception: The crackers
have the easiest task.
They need find only one open doorway; the defenders must
check every lock.
"It takes one to know one" may be cliche, but it holds up in
the network security
arena. Understanding how attackers operate is invaluable-in
fact, it's your best
defense. The concept of "hacking" into your own network for
security purposes
isn't new. Dan Farmer published a paper in 1995 entitled
"Securing Your Site by
Breaking Into It" (www.fish.com/security/admin-
guide-to-cracking.html).
Network Computing published a similar article a few years ago
(see "Intrusion
Detection Provides a Pound of Prevention" at
www.networkcomputing.com/815/815ws1.html).
Many of the time-tested security principles still hold true.
However, attackers'
tools and talent have taken giant leaps. Each time security
products mature, so
do attack methodologies, and if you fall behind on either,
you're setting yourself
up for a nightmare.
Cracking Some Myths
Before we even think about sitting down in front of a
computer, let's debunk
some common assumptions about crackers and excuses for
reduced vigilance.
- "We are not a high-profile company-no one is targeting us."
You may
manufacture industrial-strength toilet seats, but be "next
door," in Internet terms,
to an e-commerce site performing credit-card processing. Or
maybe you have
great bandwidth or juicy servers, or maybe your domain name
just sounds cool.
It often doesn't matter what your company is or does,
intruders can make use of
your network even if it isn't their final target.
- "That is a really complicated attack-it would never happen
to us." Although
experts agree that the successful cracker lies somewhere
between script kiddy
(able to execute prewritten code, but unable to manufacture
new exploit code)
and elite programmer, most are able to pull off fairly
sophisticated attacks.
Think back to your college years. Imagine spending less time
drinking beer and
more time in front of your terminal. What level of mischief
could you achieve?
Now add the declining prices of bandwidth and hardware and it'
s no wonder
14-year-olds are drawing visits from the Secret Service.
- "That would take incredible persistence and coordination-I
don't think the
average cracker could pull that off." Been on IRC lately?
Ever pop into a
channel where all transmissions were client-encrypted? Ever
wonder why?
Grab a copy of ADMhack, ADMworm or whisker. Check out www.
hackers.com, ftp.technotronic. com or the packet-storm
security site
(packetstorm.securify.com). Glance at the code of Back
Orifice 2000
(www.bo2k.com), or the modifications and plug-ins that have
followed. Then
let's discuss attack complexity. Granted, attacks to deface
Web sites for the
White House, CIA, FBI, C-SPAN and Wired haven't been rocket
science, but
these organizations aren't exactly sleeping at the switch,
either. Crackers are
becoming more persistent, automating tasks and working in
teams. They can,
and do, "pull that off."
- "We run NT, not Unix-the chances of us getting cracked are
reduced." Groups
like Rhino9 and the L0pht have proven that this statement is
borderline absurd.
Look at recent exploit trends: NT exploits and trojan
development efforts have
far surpassed those of their Unix counterparts.
As state and federal law enforcement officials haul in young
crackers for
Web-defacement stunts, many of the "good" crackers go
unnoticed. They're
smarter. They don't leave tracks. The smart ones have defined
goals and very
targeted, methodical approaches. This breed is the true
threat.
Warning!
What follows are details of an actual attack, on a real
network (audited by
permission, of course) with identities masked to protect the
innocent. We want
to give you a glimpse of an attack methodology, and present
tangible solutions.
Understand that these methods are not all-encompassing.
We'll call our target somedomain.com. We know little about
somedomain.com
other than its registered Internet domain name, so we start
this cracking session
with a reconnaissance mission. Our first objective: Identify
hosts and IP ranges
of the target network(s) by querying "public" services like
DNS.
Using common tools, such as nslookup, dig and whois, we
gather a wide-ranging
amount of information. Starting with a whois query, we get
information about
the location and addresses of the name servers. Using the DNS
tool nslookup
we attempt to initiate an unauthorized DNS zone-transfer,
which could give us a
clear road map of available machines. Although this may seem
trivial, even
some "e-commerce" providers forget to lock this down (see
screen on page
124).
Simply by using DNS queries, we can deduce the following:
- The primary DNS server is most likely on site; the
secondary server appears
to be at somedomain.com's ISP. This tells us the company has
at least some
dependence on its provider.
- It has more than one IP range (multiple Class Cs). This
informs us of possible
nonproduction segments that may not be closely guarded.
- Based on the machine names, it seems the
development/staging area is on that
second Class C.
- The mail server is not on the same network as the Web
server. This could
mean the company outsources its Web-hosting needs, or that
there might be a
third Class C.
Onto stage two-scanning for actual targets, which involves
port scanning and
banner grabbing. Port scanners check for active services (Web,
ssh, ftp) and
"ports"; banner grabbing is the art of identifying service
versions. Port
scanners-such as strobe-have been popular, but Fyodor's nmap
is the new tool
of choice (see www.insecure.org). In addition to scanning
machines and
networks for listening services, nmap is capable of guessing
a host's OS purely
based on unique IP stack implementations. Although nmap's
OS-detection ability
can be thrown off by packet filters and firewalls, it's a
powerful tool.
We could target front-line systems-the main Web or e-mail
servers, for
instance-but instead we'll attack the development servers,
where we have a
better chance of success. They typically don't get the same
attention as
production machines, but they frequently have equivalent
levels of access. A
quick port scan (see screen below) shows two servers are
running Web and ftp
services, and based on banner checks and nmap's OS detection,
we can guess
at the running environment.
Using what we've gathered thus far, we now know the
following-which is
basically everything we need to know:
- The target network is a mixed environment of NT and various
Unix versions.
- It is running Microsoft Internet Information Server and
wu-ftpd, among other
services.
- It appears to have a firewall in place.
A little more research and it's time to move in. This is
where the Internet comes
in handy. Using anything from friends on IRC to Web resources
like
www.rootshell.com and ftp.
technotronic.com, we can look for remote NT and Solaris
exploit information.
There are generally two types of exploitable holes: local and
remote. Both are
usually the result of poor programming. Local vulnerabilities
are only exploitable
after first gaining some level of authenticated access. In
the Unix world, this is
often a login shell. Once a minimal level of access is
achieved, a hostile program
is executed that attempts to gain a heightened (unauthorized)
level of access.
Remotely exploitable holes can be any assortment of OS and
service flaws that
are accessible via the network. In this case, we do not have
any preliminary
access, so we're forced to stick with remote exploits.
For this network we identified Microsoft IIS version 4, and
the development
machines most likely have a fair amount of tools and database
connectivity
solutions. Looking at Bugtraq archives (www.securityfocus.
com), we come
across a Remote Data Services (RDS) hole that is dependent on
the presence
of a single DLL. Within 10 minutes we exploit the hole and
can execute any
command on the NT machine as SYSTEM_ LOCAL (administrator
equivalent). We're in.
Digging Deeper
Most auditing firms and "tiger teams" will stop here. They'll
identify the hole and
move on. For most purposes, this is perfectly acceptable, but
for those who
have never been "owned," let's continue down this dark and
scary road, for the
intruder will probably not stop here.
After entry is achieved, the first order of business is the
cleanup. Skilled
intruders know not only how to break in, but how to cover
their tracks.
Assuming that they've gained root/administrator access, on
Unix machines
clearing all tracks is usually as simple as editing text
files. NT machines, by
default, log even less than Unix-based machines and they are
even easier to
cleanse. Without some sort of external or secure logging
mechanism, host logs
on any type of compromised machines become worthless.
Next, the intruder will most likely snag the Unix password,
shadow or NT SAM
(Security Accounts Manager) files. SAM files store all of the
encrypted NT
passwords. This may not seem like a big deal, until you
consider having to force
everyone to change his or her password. Also consider the
inherent weakness
found in NT password storage. Unless you've disabled LAN
Manager
passwords, which are enabled by default, you have a very weak
encryption
implementation guarding your user passwords.
Once the intruders have a few user names and passwords, they'
ll try leveraging
those across multiple machines. Usually user and
administrative passwords are
common across all machines and platforms. Your NT
installation may be
secure, but if your Unix and NT accounts use the same
passwords, and the
intruders nail the Unix systems, you're still hosed.
From here, depending on what type of access is allowed
through the firewall,
intruders may be able to upload and execute some sort of
trojan or backdoor
program. Everything from modified inetds, to trojaned ping
replacements, to
netcat, to Back Orifice 2000 can be used with very little
trouble. Once these
programs are installed, intruders can create multiple entry
points into the
network and continue gaining turf. The scary part is that
even if you detect the
break-in and change every password, if your system's been
back-doored and
you don't detect those modifications, the crackers still own
you.
Using What You Know
What can we learn from this? As attackers, we inquired about
the target
network via DNS. While you can't mask InterNIC entries, you
can ensure that
your DNS servers are configured in a secure manner. In our
example, we found
our targets based on knowledge we shouldn't have been able to
gain from DNS.
Next, we ran basic port scans and logged banners on known
machines. While
frequently you can't shield the banners of public services,
like Web and mail
servers, you can make sure they are properly "hardened" and
patched to the
latest versions. In addition, many intrusion-detection
systems will alert you to
such scanning attempts.
We then researched exploit data specific to our target. This
is why it's critical to
keep current with known holes. If you can keep up with Cert,
SANS, Bugtraq
and vendor warnings, do so. If not, look to someone who can,
or subscribe to
services like our Security Express (www.security-express.com)
. Regardless of
where you get your security information, timeliness is
everything. We've seen
servers get hit within 24 hours of an alert posting-and those
are with known
exploits. Staying on top of the information gives you a
better chance to protect
yourself.
Full disclosure lists and sites such as Bugtraq, Security
Focus and technotronic
(www.technotronic.com) help immensely, but many security
holes are
discovered by "underground" organizations. Some report them
immediately,
others sit on them for weeks or months before releasing them
to the public.
While it is virtually impossible to head off many of these
"unknown" holes,
reducing the overall exposure of your network and services
helps reduce the
number of doorways.
Security-conscious managers should use logs-securely and
religiously. If you
can't trust your logs and someone gets in, your world will be
rocked even
harder. And make sure that you process those logs-they're
worthless if you
don't look at them. Turn off everything you aren't using and
know what
information can be gathered externally. However, no matter
what you do, odds
are you'll have services exposed to the outside world. You
must know what
they are, know what they do, know what their versions are,
know their children,
pets and uncles, and embark on an unparalleled level of
intimacy with every
aspect of their existence. You must know your exposure points,
and know your
network.
Limit the use of third-party and/or untrusted products on
exposed machines.
Many OS vendors are starting to take security seriously, but
smaller companies
that design products to run on those OSes often do not. An
increasing number
of attacks are being launched on third-party deficiencies. If
you aren't
100-percent comfortable with what's running on your machines,
particularly in
the Web arena, force your vendor to earn your confidence or
switch products.
Ensure good backups and consider implementing a binary
integrity checker such
as Tripwire (www.tripwiresecurity.com/). No single product
will satisfy all your
security needs, but programs like this can identify modified
services and binaries
when all else fails.
Make it standard procedure to examine your network externally
several times a
year. Ideally, all exposed services and machines should be
scrutinized on a
regular basis. Once secured to an acceptable level, the same
procedures should
be used to lock down internal machines. Avoid the "magic
shell" model of
firewalling; don't be soft on the inside! Pay attention to
internal machines and
create a DMZ or atrium model for cleansing (see "DMZ or '
Atrium' Models" on
page 125 and "Divide and Conquer" at left). Limit and secure
any interaction
between exposed machines and internal resources.
Finally, security technology is toothless without strong
procedures and policies.
Make sure your policies are in line with your security goals
and with any luck
you won't be the next highlight on attrition.org.
Greg Shipley is a Chicago-based consultant. Send your
comments on this article
to him at gshipley@neohapsis.com.
--
☆ 来源:．BBS 荔园晨风站 bbs.szu.edu.cn．[FROM: bbs@210.39.3.71]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店