Cautionary Tales: Stealth Coordinated Attack HOWTO
by Dragos Ruiu <dr@netsentry.net>
Wed Aug 25 1999
This article was originally published in Digital Mogul Volume 2-7, July 1999.
Copyright 1999 uberbabe media inc. All rights reserved.
A lot has been written in the popular media about the effects of hostile coordinated
traffic attacks (hacking), and, as a sysadmin, I find my systems increasingly under
attack by hostile sources. Two years ago, we got mapped and port-scanned for vulnerabilities
once a month. One year ago the scan frequency was up to once a week, and these days we get
scanned several times a day with real attack attempts at least once a week.
The Internet is becoming an increasingly hostile place and the traditional defenses
and documentation of attack systems seems woefully inadequate. With this article,
I hope to remedy some of the false misconceptions of security that some admins have.
Yes, I hope that descriptions of these attack techniques scare you into beefing up security
on your home PC, at your office, everywhere. Over the last fifteen or so years,
as a sysadmin of network connected systems, I have seen the knowledge of computer technologies
propagate across the spectrum of human population, bringing with it the traditional demographic
including the stupid people, the malicious people as well as the helpful and the apathetic people.
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?
Credits
-- UnKnown --
|