Cautionary Tales: Stealth Coordinated Attack HOWTO
by Dragos Ruiu <dr@netsentry.net> Thu Aug 19
Thu Aug 19 1999 1999
Cautionary
Tales:
Stealth
A lot has been written in the popular media about the Coordinated
effects of hostile coordinated traffic attacks (hacking), Attack
and, as a sysadmin, I find my systems increasingly under HOWTO
attack by hostile sources. Two years ago, we got mapped
and port-scanned for vulnerabilities once a month. One Wed Aug 11
year ago the scan frequency was up to once a week, and 1999
these days we get scanned several times a day with real The
attack attempts at least once a week. The Internet is
becoming an increasingly hostile place and the traditional Internet
Auditing
defenses and documentation of attack systems seems Project
woefully inadequate. With this article, I hope to remedy
some of the false misconceptions of security that some Thu Jul 29
admins have. Yes, I hope that descriptions of these attack 1999
techniques scare you into beefing up security on your home Broadening
PC, at your office, everywhere. Over the last fifteen or the Scope
so years, as a sysadmin of network connected systems, I of
have seen the knowledge of computer technologies propagate Penetration
across the spectrum of human population, bringing with it Testing
the traditional demographic including the stupid people, Techniques
the malicious people as well as the helpful and the
apathetic people. [ more ]
With the burst of Internet technology over the last few
years there has also been a burst of new computer
adoption, increasing pervasiveness of computing and
networks and increasing occurrences and danger/damage
caused by hostile computer use. While I don't believe for
a second the over-inflated, hyped-up estimates of the cost
of these hacker intrusions bandied in the media, I can
vouch that the problem is real. As the chief technical
weenie of our company, NetSentry Technology, I've been
manning the front line defenses of our company net
equipment. I've also been documenting the increasingly
hostile nature of attacks on our network and would like to
share some of my experiences in this area. The technical
level of the attacks is increasing at an alarming pace,
and I haven't seen any documentation of these new attack
techniques yet, so here are some cautionary tales culled
from our real-life experiences. My hope is that after
reading this you will re-examine your own network
security. Most organizations are woefully under-protected.
The ISPs are having increasing difficulties in responding
to customer requests for assistance in intrusion cases and
the police are even further under-staffed and out-gunned
technologically. So increasingly, it leaves companies to
fend for themselves to secure their systems. Here is what
you have to worry about.
I wish I could take credit for all the techniques
described here, but a majority of them were derived from
analysis of traffic used for hostile attacks on us. Credit
belongs to the anonymous hackers that have taken a run at
our defenses. I write the following from the point of view
of the attacker to emphasize the point that security is
vastly neglected at most sites and because I want to ask,
what will you do when faced with these attacks? And what
can you do with your current defensive equipment? Not
much, I wager.
The phases of a successful attack are A) Reconnaissance,
B) Vulnerability identification, C) Penetration, D)
Control, E) Embedding, F) Data extraction/modification,
and G) Attack relay.
A) Reconnaissance
The first part of a successful attack is to get to know
the network topology in the region surrounding your target
and the parties it communicates to. This is also an
important part of the penetration of each successive layer
of your target's networks. Currently, the best publicly
available tool for net topology identification is Fyodor's
excellent "nmap" program and derivatives. The objective of
the reconnaissance is to understand as much about the
target and to identify attack destinations defenses and
potential attack relay bases.
In private circulation, the following tools exist or will
soon exist:
Attack Tool: Coordinated multi-site scanners. Mapping
software that distributes the mapping "probe" packets to
be sent to the destination addresses and nearby sites over
a number of geographically dispersed attack sites, and
trickles them out at low rates to avoid detection so that
there never is a lot of traffic at any one time or from
any particular site (see stealth section). The results of
the pokes and probes at the target that these systems send
is summed and collated to build a picture of what
equipment the target has installed. There was a lot of
noise in the press earlier this year as some of the crude
versions of these coordinated scan tools were aimed at US
military sites, but either the operators of these tools
have improved them to the point where the relatively
immature military defense systems no longer identify these
scans, or the military has found some other threat to
highlight in the press and use to get funding.
Attack Tool: Sniffer Detectors. Sniffers produce unique
traffic patterns that may be detected. They also provide
some interesting penetration vulnerabilities, as their
network interfaces are placed in promiscuous mode,
allowing all packets past the address filters to be
processed by network stacks and applications. Some attack
methods directly target security systems, which,
ironically enough, are often notoriously insecure
themselves. Once the security system is penetrated, all
kinds of nice information like traffic patterns and
passwords may be gleaned, and evidence of your attacks can
be conveniently removed. And because of promiscuous
listening in the sniffer you can even take it out with
traffic destined for a different system.
Attack Tool: DNS Zone transfer. A DNS zone lists the
externally accessible points a company maintains. A nice
map of the externally visible systems that your target has
put on the Internet and a great attack point list. Not
many sysadmins go over the name server records closely
enough to detect this, however the more advanced intrusion
detection systems are getting better at identifying these
kinds of transfers as pre-cursors to an attack.
The important information to gather is the DNS names and
addresses of the target's hosts and neighbors. Then you
must further identify the OS and open port configuration
of each of your target's systems. The latter is determined
using site scanners and analyzing the responses that a
site delivers. Current tools such as "nmap" and "queso"
are getting very good at determining device, OS version
and some network application configuration information
from careful analysis of the timing and contents of
responses to probing or mapping traffic. The OS and port
configuration are used to identify systems that could have
software packages with vulnerabilities and bugs open for
exploits.
Knowing who your target's ISPs are by analysis of address
use can provide useful attack bases for your onslaught.
Getting into their ISP's equipment and servers first could
enable you to get important information about them and if
you can subvert equipment installed on the same network
links as your target can let you glean important
information such as traffic patterns of your target. All
without your target even suspecting. It may also be easier
to penetrate the ISP than a secure target. Some ISPs such
as @Home even keep extensive (but often out of date)
databases listing customer's hardware and software
configurations as well as other info, which if accessed
can mitigate some of the dangers of triggering intrusion
detection systems with your site scanning traffic.
Once the traffic patterns of the target's external traffic
are known, a basic technique to take out a secure target
is to first take over a less secure target that your main
target talks to, and then come in to your main target
under the cover of that site's usual traffic. Any site
your target talks to periodically, including popular web
sites, employee's dial-up accounts, and system traffic,
such as network time protocol (NTP) clocks, are all
candidates for attack relays. Sprinkling in your attack
traffic with large web downloads and ftp transfers will
make it more difficult for security personnel to use
sniffing and detection tools to identify your attack, as
scrolling through reams of logs and captured data can
often be more time consuming than possible with most
network staffing levels. Taking out and controlling your
target's conversation peers can provide you with useful
channels through your target's defensive firewalls and
detection systems. Your traffic will look on all the
scanners like that web-site the Joe in IT is surfing to,
but will provide you with a nice channel right past all
the firewalls to a machine inside the core of your
target's net.
One useful target is the DNS caches and servers that your
target uses at your ISP. Accessing the DNS logs can give
you the addresses of all the sites that your target talks
to, and furthermore, careful analysis can even give
indication of when the activity happened, or is happening,
offering excellent potential for cover.
As we'll talk about later, owning the DNS server can have
many benefits. In general the DNS servers are ripe with
hacking opportunities.
Another useful target is the ISP DHCP server, which is
used to dynamically assign IP addresses to clients on
connection, as it can be used to identify periods of
system activity from the logs, and also periodically
establishes connections to the client systems as the
address leases expire. A common DHCP vulnerability also
allows client system takeover from this ISP host. DHCP
address lease expiry also provides a nice way to signal
embedded attack software at pre-determined times to do
things like wake up in the middle of the night and send
data when no-one is looking.
An often available source of useful relay bases for
attacks is other systems in the same ISP client pool (on
the same modem bank, other ADSL users on the same DSLAM,
or cablemodem users on the same segment), which are in
many cases default configuration, open like Swiss cheese,
Windows systems - typically with file-sharing turned on
and personal web services enabled, a combination that
sports a plethora of available vulnerabilities to exploit.
After taking out the easy "marshmallow" soft client PC,
the adjacent main target can then be attacked using local
subnet attacks, offering again some potentially powerful
techniques for hiding from and exploiting your target's
security systems. In easy cases, the equipment rack will
bridge broadcast traffic between the "marshmallow" and the
target, allowing use of address resolution traffic such as
ARP and DHCP to be used for system attacks and control.
For stealth, these kinds of attack bases are excellent
too, because the broadcast traffic is largely repetitive,
very voluminous, and mostly uninteresting, which, combined
with a great immaturity among the security tools for this
kind of traffic, make it a ripe vulnerability area. Local
area broadcasts can also be used as another "mapping"
system too, even in passive listening to traffic at the
nearby "marshmallow". By recording the address lookup
broadcasts from your target, you can build up that traffic
pattern information so that you can sneak into the site
undetected.
Another often overlooked source of mapping and
reconnaissance information (and break-ins) is the
management systems the ISP may be maintaining. The Simple
Network Management Protocol (SNMP) that most of these
systems use is a bit too simple and is ripe with
vulnerabilities, rich with information (including complete
remote sniffers useable to pick up passwords in some RMON
MIB equipment) and lame about security.
The most powerful relay base for attacks is the ISP's
router system. Once you control the paths of your target's
packets, you really have them at your mercy, as you can
silently redirect any of their traffic to your attack
relay bases without them knowing, and other fun tricks.
However, most ISPs guard their Ciscos and other routers as
the most valuable resource with the most defenses, so this
is really a target for the most daring and brilliant
attacks.
B) Vulnerability Identification
The objective of the mapping phase is to find externally
accessible traffic paths into your target's net systems.
Over the last year it has been easy to see what are the
most popular scriptware for the so called script-kiddies:
the low-tech, mostly teen, hackers who just download
pre-compiled exploits and run it blindly against targets.
The standard script-kiddy technique is to set up a broad
address sweep broadcast of probe traffic, to the whole
section of the Internet that seeks some sort of response
from the target, that would indicate that software is
installed with the vulnerability the exploit is using.
The classic vulnerabilities that we frequently see sweeps
for are:
* FTP Server Exploits. Especially vulnerable are servers
with
anonymous write access.
* NFS and SMB share vulnerabilities.
* Holes in POP and IMAP mail delivery servers.
* Vulnerabilities in the "bind" name daemon software.
* Web server CGI exploits (Apache, MS IIS).
* Installed control daemons such as BackOrifice.
The scans for these holes are so common these days that it
is difficult for most sites to even catalog origins of
such scans. These kinds of scans are so commonplace that,
as long as traffic volume and frequency is controlled, it
is possible to conduct them with relative impunity. But
the attacker has to be prepared for the case of zealous
sysadmins who contact ISPs and complain about port-scans.
Never port-scan from a node you are not prepared to have
disconnected, seized or otherwise lost. Here, the best
policy is to use the least useful and network connected
systems in your attack fleet of controlled systems as they
may be lost or jammed and blocked by firewall software
when the hostile mapping probe traffic is detected.
Mapping traffic stands out like a sore thumb when pointed
at systems not running the vulnerable software - if the
target has the tools to analyze this kind of attack (i.e.
Abacus Sentry). If attacking a net-savvy sysadmin, he will
be able to detect things like IMAP probes against servers
not running mail software. However, even these days,
targets with effective intrusion detection systems are few
and far between. And sysadmins with enough time to
examine, properly and frequently, all their logging
systems are even fewer.
At the sites that have management and security systems,
these are ripe targets too. Penetrating the security
system has the best advantage of rendering the target
effectively blind. I have seen experienced sysadmins
dismiss unquestionable, hard evidence of tampering because
their beloved and trusted, but thoroughly compromised,
security sniffer shows them that there is nothing to worry
about - or doesn't even show that kind of data at all. The
other factors in the attacker's favor are the egos of the
network designer and IT group. Every sysadmin thinks their
defensive plan is carefully thought out and "their" system
couldn't possibly be penetrated. Here at NetSentry we used
to contact operators of systems that had been compromised
and were now being used for attacks against us. But after
many hours of fruitless attempts to convince maintenance
personnel, who, if you did reach them, often didn't even
understand the attack traffic their own site was
launching, insisted that it "couldn't possibly be our
system, it must be your equipment or monitors that are
wrong."
I remember very vividly one ISP we contacted: when we were
watching, in pretty much real time, as the attackers were
compromising system by system at their site and using each
as a base for attacks against us, how their support person
and security specialist looked at some local system when
we called and decided that we couldn't possibly be
correct. An hour later, as the ISP's systems being used as
attack relays switched from probing to all out denial of
service flooding and attacks, we called back and everyone
had happily gone home for the night there. We never did
bother to call them again and as far as we know the
attacker still owns all their systems. The only guys who
really took one of our attempts at warnings seriously was
the security department at a regional bank, who came in on
a Saturday to put sniffers on the line - but they were a
notable exception.
The best targets are those that are the most widely known,
used, and difficult to take off-line or re-locate. Mail,
DNS, Web and FTP servers all fall into this category. With
these servers, sites that notice suspicious traffic will
often not off-line them because they are critical to
network operations. And even if they take them off line
and restore them from backup, or otherwise keep you out,
they are often forced to bring the servers back with the
same vulnerability as was available for initial entry
because user complaints about the unavailability of
network resources override the attempts to identify and
close the hole.
Like penetrating the sniffer and management systems, the
mail servers also provide excellent opportunities at
invisibility, by letting you monitor internal
conversations, what aspects of the intrusion have been
detected and what countermeasures are being mandated.
C) Penetration
The most successful hack is the one where the target
doesn't even know it has been penetrated. The next best
thing is that when the intrusion is detected, they won't
know where it's coming from. Since the source may be
detected, it's better to use attack relays so the
attacker's anonymity can be maintained. The general
technique is to quickly find some clueless newbie who has
put his home system or office server on the net with major
vulnerabilities, and use that as a relay. Never use a
system with your name or organization attached to it to
attack.
Use several levels of indirection and make sure you cross
several geographical and political boundaries to hide your
trail. ISPs in the same country often will not share log
information and this gets even more difficult across
borders. I listened with sympathy when I heard a poor
overworked security colleague who works for the Canadian
RCMP describe the nine month process (!) for the paperwork
to request log files from U.S. ISPs. The police and ISP
security departments often have their hands tied by
procedure and policy and general understaffing. The more
organizational and geographic boundaries that your attack
redirection trail can cross, the more safe and anonymous
you will be.
People complain about the lack of anonymity on the net,
but for those that cross that line into unauthorized
systems use, there is altogether too much anonymity. It's
often almost impossible to follow a chain of connections
through multiple ISPs and countries. The hidden are truly
anonymous on the net. Sysadmins should give up now on the
romantic idea that you will be able to track down who is
attacking you - it's just another bunch of random numeric
addresses, and even if you trace it down to an ISP, their
logs will only point to another ISP and so on.
If the attacker can knock out the target's intrusion and
sniffing facilities then you can proceed the rampage
though their network with relative impunity, but even if
you don't have the technology to compromise such systems,
there are a number of techniques you can use to make your
attack more stealthy.
Attack Tools: Firewall tunnels. There are a wide variety
of virtual private network and proxy programs, which you
can use to relay your traffic to inside a protected
network and not make the traffic appear on an intrusion
detection system. Literally dozens of such firewall
"borers", such as HTTPtunnel, are available now in source
and binary form. These tunnel programs relay your traffic
through the firewall and IDS systems by making it look
like innocuous transfers to and from your "mole" system to
common web-sites and other forms of traffic "chameleoning"
to make it look unexceptional. These tunnels embed your
attack and control traffic inside this relatively innocent
looking traffic to seem like HTTP or partial TCP
fragments. These tunnels can also encrypt your traffic,
making it more difficult for your target to identify the
penetration methods.
Most sites employ hard-shell, layered network security.
That is to say the links external to the organization have
firewalls and net proxies to restrict access to the inside
network. The standard technique is to have a hardened
Demilitarized Zone (DMZ) made up of firewalls and security
IDS systems. The most secure sites will have multiple
servers and systems dedicated to these roles, but the
majority of installations often rely on one inadequate
server for this gatekeeper function. And once you are
through this shell, which is checked most often by
maintenance personnel, you are usually into the internal
network that has almost no security. Another often
overlooked security breach is to use floppy based Linux
distributions such as the Trinux project, or client
software for common Windows and NT systems, to carry in
such a tunnel program physically into the organization
where it can be surreptitiously installed on a system
inside the "hard" shell. This "mole" or tunnel can then
penetrate the security from the inside where
vulnerabilities are seldom checked. From this attack relay
base, you can proceed to scan the internal systems and
take over other servers, further embedding your control of
their infrastructure.
Firewalls are hardened quite well these days. But even so,
some firewall operations can be predicted and broken, in
areas like the port number sequences of outbound
connections. With predictable sequence number connections,
firewall connections can be hijacked and attack sequences
passed through the defenses. And while firewalls are often
tough, many sysadmins make mistakes and leave
vulnerabilities open on the host the firewall runs on
(like running Microsoft IIS on the firewall), allowing
penetration and access to both the internal and external
Ethernet interfaces on the box for malicious software to
bridge packets between the two. Once the host with network
interfaces on both segments is penetrated, packet hijack
software can grab the packet and relay it to the other
interface before the firewall software even sees it,
essentially providing you with an invisible back-door into
the target.
Some forms of firewall penetration do not even involve
bypassing the firewall. One interesting attack technique
it to identify frequently visited sites by the target,
taint the DNS database with a forged update to their DNS
server or cache so that the next time the target client
contacts the frequently visited site, the traffic is
pointed to one of your attack systems instead. This attack
relay system can conveniently embed your attack exploit in
relayed copies of the original web site. With modern Java
enabled browsers, the client naively executes any code the
supposedly well known site, which is in reality your
attack relay, sends. The data is sent in response to a
client's request through the firewall and walks right past
the intrusion detectors, virtually indistinguishable from
ordinary data. This attack mode is also available by
taking over the target ISP's router or DNS server.
Other forms of stealth involve penetrating SNMP traffic
statistics or nearby systems at their ISP or other peer
clients to identify traffic activity. The design flaw of
the Internet that makes identifying forged source
addresses a difficult problem can also let you hide the
origin of the attacks (so called "spoofing"). If attack
traffic is sent from (or spoofed to look like) a source
that is currently sending a lot of data to the target, it
makes it that much more difficult to spot the attacks.
This buries the attack packet amongst reams of other
voluminous data. It quickly scrolls the attack packets off
the screen of sniffers and makes network security staff at
the other end go through the tedious "find the needle in
the haystack" procedure of sorting and filtering megabytes
and megabytes of capture data if they suspect the attack.
Most of the time they will not have the patience to
exhaustively search for attacks by scrolling though the
captures and logs, again rendering you invisible.
After penetration, further attack software can be embedded
in ordinary traffic to transfer it into the target's
systems. Patience is the key here. The lower the data rate
that can be used to get the information in and out, the
lower your chances of being detected are. Spreading out
your packets, so only a few per hour are transmitted,
makes your hack very difficult to detect with today's
tools. (However, we have developed some special tools to
counter this kind of attack.)
One of the more devious penetration methods we observed
was a system that trickled data in and out in the normally
unused padding at the end of user data packets. On normal
sniffers and detectors, the packets looked completely
innocent, as even those tools did not display the padding
"garbage" used for the hack. This padding was used to
install malicious software by trickling the attack
executable into the target a little bit at a time, a few
bytes with every packet.
Another interesting stealthy attack system that will
negate most firewalls is to embed your hacking control
channel for your attack bot software and results and
information back from the bot in addressing translation
requests, that by definition need to be passed on by
firewalls. One such clever system we experienced was an
attacker who penetrated another nearby client node on an
ADSL system. They then penetrated one of our systems (a
sniffer of all things) and installed a key-stroke logger
that encoded the keystrokes typed at the console into the
address field of Address Resolution Protocol (ARP) lookup
messages, which were happily passed through the firewall
and relayed to the attacker at the nearby system outside
the firewall on the same subnet that received the ARP
encoded keystrokes. This key logger even delayed,
encrypted and grouped keystroke transmissions to make
detection more difficult. We have also seen keyboard
loggers that were clever enough to store your keystrokes
on disk, in case the system was disconnected from the
network (like a laptop) for a while and then trickled them
out later when the net connection was re-established. Key
loggers provide easy access to most authentication tokens,
scrambling keys and passwords.
The basic form of penetration is to use stack smashes
which take advantage of basic low level coding bugs in a
piece of applications software or an operating system
component. The form of a stack smash exploit is to utilize
a data coding that allows variable length data that you
send to be erroneously copied into fixed length buffers or
variables, and writing into data past the end of the
buffer. Since this data can overrun the stack, you can
overwrite a return address for the currently executing
function and make the processors CPU jump to and execute
arbitrary code of your choosing. If the bug exists in a
privileged piece of software, these instructions that you
jump to are virtually unlimited, allowing you to do
literally anything with the penetrated computer.
The problem with this form of attack is that it often
requires detailed knowledge of the operating system and
memory map of the target. Often this form of attack will
have to be coded in multiple ways to account even for the
version of OS and software package being penetrated. The
drawback for the attacker and the advantage for the
defender is that usually stack smashes involves "groping"
around blindly, sending multiple variants with different
offsets and values until the appropriate magic version
number that works correctly and responds back is found. In
some cases an incorrect variant can crash software and
systems, necessitating lots of patience and long time
delays between variants tried.
A common target for stack smashes are recent and older
variants of the "bind" name daemon that is in almost
universal use to translate from symbolic DNS names and
URLs into numeric IP addresses. The code and traffic
structure of this program is very complicated, difficult
to debug and ripe with vulnerabilities and bugs. One 17
year-old hacker managed to take over more than 12,000
systems over two years - before he was caught with an
automated "bind" takeover worm.
Another common form of attack is to exploit the
increasingly complex and powerful native data types of
applications software (especially Microsoft products that
often contain several complete programming languages in
things like word processors and mail readers). Web server
script exploits also fall into this category. The basic
technique here is to either hijack an existing connection
and inject malicious data or to send unsolicited attack
traffic that will take over the application and eventually
the system.
D) Control
Once you are into the system and have compromised a piece
of software, the next bit of work is to get control of the
host. This is usually a bootstrap process, where a piece
of small code, "the exploit", is first gotten into the
target and the vulnerability is used to execute the code.
This code needs to contact one of your attack relay
systems and download further code and instructions. The
simplest form of bootstrap is to allow remote access to a
command shell that can execute arbitrary operating system
commands.
There are many forms of bootstraps, as they are often
linked to the exploit itself, and some, like BackOrifice,
include a whole command interpreter. But those more
advanced download a minimum of code and use existing
portions of the operating system code to build a remote
control system attack bot. These advanced exploits can, in
object oriented fashion, build whole parallel network
stacks and control systems that run invisibly in the
background on the machines using software already
installed on the machine.
A portion of the bootstrap process during attack is to
restart or patch the application that was crashed so that
the intrusion is not noticeable. Other important parts of
this process include cleaning up the log files to remove
intrusion messages and hiding the attack bot so that it
isn't listed in the task viewer or process list.
"Scrubbing" the log files can be easily accomplished by
recording the file pointers to important log files at
exploit time, installing and bootstrapping your attack bot
and then "rewinding" the log files to their pre-attack
positions to erase any evidence of the installation by
overwriting the operating system file pointers in memory
with your pre-attack copies. Subsequent log entries will
overwrite the evidence of the attack. Log files to be
cleaned up include sniffer capture files, system event
logs, DNS and other daemon diagnostic files, IDS systems
files and file integrity checkers like Tripwire. The good
attack bots make log-files almost useless for intrusion
detection.
Your attack bot can control the machine up to the
privilege level of the software that has been penetrated.
It can access any resource that the original software
could. In many cases, this will not include super-user
"root" or "administrator" privileges and you will need to
use another local exploit to break in further. One
alternative approach is to download a password cracker and
dictionary to be stored in invisible files or unused
portions of the disk and let this cracker run in the
background on the machine (invisibly off any task list of
course), using a brute force search for the password on
the same machine. This generates little traffic, and is
very difficult to detect by the target, as the machine
will work silently to crack the password for you when
idle. One such attack system that was used against us used
a remarkably compact word-list and a very patient brute
force cracker - to good success.
Super-user privileges are not needed all the time. Even in
cases where the cracked software has been limited to
accessing only a few resources, it is often enough to use
the system as an attack relay base. One of our attackers
used a "bind" exploit once on a firewall system where we
had purposefully confined the non-privileged version of
"bind" program to a "chroot" jail that limited filesystem
access to a very small subset of files. This didn't stop
the sophisticated attacker much, as even the ordinary user
privilege "bind" already had permission to access both
internal and external Ethernet interfaces and bridge
packets between the two to bypass the firewall software.
With careful design, your attack bot can allow you to
encrypt, hide, download, remotely install and run
arbitrary software packages, and send traffic so that even
sniffers installed on the target do not see the packets.
It is relatively straightforward to insert and remove
packets from the network card, transmit and receive
queues, so that normal OS security and logging measures on
the penetrated host never even detect the traffic
(including bypassing low-level transmit and receive
counters). Similarly, it isn't a major technical feat to
hide the bot tasks so that they don't show up on system
diagnostics. You can completely remotely control a machine
and run programs on it, upload and download data, without
any indication to the user other than occasional sporadic
slowness - which on Windows is almost indistinguishable
from normal performance, and Linux and NT aren't much
better.
E) Embedding
After you have gotten in and have control of the target,
the next step is ensuring that you can retain control even
if your actions are discovered. You need to quickly map
the local net and penetrate any other system suspected of
being a sniffer or key communications links, such as mail
servers, to observe any suspicion of intrusion on the part
of the target's IT staff.
The next portion of clean up is to trickle in any
additional attack code into the target and whatever is
needed to make your controlling attack bot install and
hide itself on disk. The point here is to allow your bot
to survive a system re-boot and retain control so that you
do not have to go through the dangerous - and detectable -
attack and clean-up sequence again. Several techniques
have been observed for doing this. One is to overwrite
existing and little used OS files that exist in nice,
known predictable places/paths, but are seldom used (the
more marginal games that come with OS distributions, and
terminal definitions for obscure terminals quickly come to
mind for this purpose). A sophisticated variation on this
is to encrypt and spread your binary over many files
(sometimes called steganography). Another alternative that
requires more low level programming is to use unused,
empty portions of local disks. The system then has to be
modified to re-enable your bot after rebooting.
A variation on this hidden attack bot is to install a
back-door that will lie dormant on the disk and install a
small, difficult to detect bot that waits until receipt of
a special traffic trigger which will then set off
re-assembly from code pieces spread out on disk files and
activation of the more powerful attack relay bot. This
kind of traffic trigger system could also be used to
render the traffic invisible. One attack system installed
itself across multiple systems and suspended normal OS
operations and triggered execution of the loaded command
in the attack bot upon receipt of a multicast trigger. The
OS remained suspended until a time out or reset trigger
was received, allowing the exploit to run without any
normal security and logging active. By using a multicast
trigger, multiple systems can be triggered and momentarily
suspended simultaneously, and if the control bot is
installed on any sniffer systems, data recording was
suspended while the attack bots execute their commands in
this suspended state and send their traffic, again
rendering the whole attack invisible. Multicast traffic
also has the added advantage of being not reported in the
default configuration of most sniffers, so unless the IT
staff explicitly enables reporting, they will not usually
be aware of it. This kind of attack is very difficult to
detect unless an operator is paying very close attention
to traffic LEDs.
One condition for the attacker to plan for is what happens
to your bot if it is discovered. One attacker once used a
system that erased itself if it lost contact with the
attack relay base for more than a certain period of time,
or if the system was re-booted (as would happen when a
system gets off-lined because breaches are suspected). In
this way any evidence was erased whenever a penetration
was suspected.
The Perl language, if installed on the target, provides a
nice compact way to download very powerful programs with a
minimum of data transferred, and the standard Perl kit
includes routines for embedding (hiding) your Perl script
into other binaries.
Another clever exploit is to store a piece of your attack
bot bootstrap sequence on the network card itself. Most
modern network cards have 64 bytes (or more) of EEPROM
that are used to store the 6 byte hardware MAC address,
leaving the majority of the space unused. More
sophisticated server network cards even have more space
for downloadable firmware. The mostly unused network card
EEPROM is typically loaded by OS drivers in its entirety -
usually to a fixed address static buffer. A small segment
of code could be programmed into the card and executed
from this buffer by an exploit. The advantages to storing
a portion of the attack code in the NIC is that it makes
tracing the activity of the exploit difficult for someone
trying to reverse engineer the code, and more importantly,
a short program installed here will survive a disk
formatting and OS re-install. This kind of exploit will
lead to a lot of head scratching and questions about "How
the hell do they keep getting back in after a disk wipe?"
at the target.
F) Data extraction/modification
After you have established control, then you can get on
with your nefarious purposes. Typically this will be data
extraction and modification on the target system. On
Microsoft systems, the registry and Microsoft's own system
information utility, enable rapid gathering and dense
transmission of key system configuration back to your
attack relay. Under Linux, the /proc filesystem provides
the most rapid clues as to system configuration, allowing
your attack bot to build a summary of what it found on the
newly penetrated server and transmit it to the relay.
Important attributes of data extraction and control of
modifications for attack bots are to hide and encrypt this
data stream. It will be beneficial to spread these
transmissions out over several relay destinations and have
them happen at low rates. One of the safer, stealthier
data extraction systems is to embed the data in HTTP web
transfers that make up a large percentage of most site
traffic these days. Putting your encrypted data deep into
packets and disguising it as JPEG or GIF binary data will
help hide it. Most traffic loggers and sniffers usually
capture only the beginning of most packets, so embedding
your data deep into the packet will make it all that much
more difficult to see, depending on what security tools
your target is equipped with.
As was mentioned above ARP and DNS also provide methods of
hiding your data transmissions. A key piece of information
on the path to hiding your attack bot data traffic amongst
the target's traffic is understanding your target's
traffic patterns. You need to know when, how (what
protocol) and who the target is talking to. Both
Linux/Unix and Windows come with some pre-made system
tools that you can use to record these traffic patterns,
without downloading much additional software. The more
sophisticated network cards under Windows come with RMON
and other MIBs that can be used to gather traffic pattern
information, so that your traffic can be spoofed and
modified to look like client traffic requested by users at
the target site. RedHat Linux contains many pre-installed
mapping tools including arpwatch and SNMP that can be used
to monitor local traffic to see what kinds of traffic will
likely escape detection. Penetrations of the target's ISP
to get traffic stats can be a boon here too.
Another important kind of data hiding is to send your data
in little bursts, and follow that data with a burst of
legitimate addressing or ARP traffic to scroll your attack
data off the display screen of any sniffers in case you
encounter a fairly quiet traffic level at the target's
system. Doing this kind of data transmission in the wee
hours of the morning will also lower the chances that
there are any humans looking at status screens at the
network control center and noticing anomalies.
G) Attack Relay
The final step in attacking is to successfully use your
new system as a relay base for other attacks. Building up
a large "fleet" of attack bases is its own reward - with
more systems to attack from your subsequent conquests will
be more stealthy and difficult to track. But now your
target relay site will likely notice if you start
port-scanning "trantor.army.mil" or other such contentious
targets, so be careful (this is another real-life example
scenario used on us here). Most sysadmins will not take
kindly to the possibility of getting phone calls from the
U.S. military asking why their servers are attacking them.
But then again, most won't notice.
Attack-Tool: One clever exploit a hacker used on one of
the "honey-pot" decoy systems we use as hacker-bait for
analysis was an SNMP triggered attack reflector. This
system used two SNMP triggers to effectively hide the
out-bound attacks. The first trigger put the system into
listen mode. After sending the trigger, the attacker
quickly sends a spoofed attack packet containing the
attack to the relay system. The spoofed attack packet is
coded to look like a packet from the attack destination to
the relay. Upon receipt of the second SNMP trigger and
after a delay, the recorded attack packet is sent back to
the actual attack target with the original source and
destination reversed. In this way the sequence of the
attack is seemingly reversed, with the local relay system
responding with a single packet after receipt of the
single packet from the target. Unless you look carefully
on most sniffers and IDS systems, it looks like the target
is attacking the relay system instead of the other way
around.
A good ploy to avoid detection is to use many different
attack relay or mapping systems and to avoid using the
same attack relay system twice in the same day or week
with a particular target. An isolated packet here and
there destined for a strange system will not arouse many
suspicions, but repeated transmissions to the same target
could possibly trigger off alarms at the relay or target -
however unlikely that may be with most sysadmins asleep at
the security wheel.
Conclusion
I hope the above attack techniques scare any sysadmins
reading this. As they should. Too may people these days
feel that security is keeping out the script-kiddies or
installing a firewall. There are a lot of nastier things
out there on the net than the mindless script-hordes, so
beware. I hope you can use this article to justify better
security measures to your boss. This stuff is out there -
it's been used on us. Odds are these kinds of exploits
have been used on you and you have no knowledge of it.
There are malicious minds developing new attack bots, and
communities of people dedicated to the breaching of
security measures. I would even surmise that there are now
organized and funded efforts on the part of military and
intelligence agencies to further develop such offensive
software. One of these days, organized crime may even wake
up to this. As we are discovering, it's the law of the
jungle out there on the Net, and there are few places to
turn to for assistance in case you get some malicious bozo
attacking you. Often you are left to your own devices, and
with little support from your own organization, that may
be technically illiterate when it comes to network
security. The only defense seems to be to stay
technologically ahead of the attackers - a constant and
resource intensive process. The good news is that it's
easier to play defense than offence. Good luck.
P.S. You do have good backups, don't you?
[ Post a reply ]
[Image]
Discussion
organized crime Anonymous
Cautionary Tales: Stealth Coordinated Attack HOWTO Larry
Cashdollar <lwc@vapid.dhs.org>
copyright
Interested in advertising with us?