mirror of https://github.com/fdiskyou/Zines.git
573 lines
28 KiB
Plaintext
573 lines
28 KiB
Plaintext
Social Zombies - Aspects of Trojan Networks
|
|
May, 2005
|
|
warlord
|
|
warlord / nologin.org
|
|
|
|
|
|
1) Introduction
|
|
|
|
|
|
While I'm sitting here and writing this article, my firewall is
|
|
getting hammered by lots and lots of packets that I never asked for.
|
|
How come? In the last couple of years we saw the internet grow into
|
|
a dangerous place for the uninitiated, with worms and viruses
|
|
looming almost everywhere, often times infecting systems without
|
|
user interaction. This article will focus on the subclass of malware
|
|
commonly referred to as worms, and introduce some new ideas to the
|
|
concept of worm networks.
|
|
|
|
2) Worm Infection Vectors
|
|
|
|
|
|
The worms around today can mostly be put into one the four
|
|
categories discussed in the following sections.
|
|
|
|
2.1) Mail
|
|
|
|
The mail worm is the simplest type of worm. It's primary
|
|
mode of propagation is through social engineering. By sending large
|
|
quantities of mail with content that deceives people and/or triggers
|
|
their curiosity, recipients are tricked into running an attached
|
|
program. Once executed, the program will send out copies of itself
|
|
via email to recipients found in the victims address book. This type
|
|
of worm is usually stopped quickly when antivirus companies update
|
|
their signature files, and mail servers running those AV products
|
|
start filtering the worm mails out. Users, in general, are becoming
|
|
more and more aware of this type of malware, and many won't run
|
|
attachments sent in mail anymore. Regardless, this method of
|
|
infection still manages to be successful.
|
|
|
|
|
|
2.2) Browser
|
|
|
|
Browser-based worms, which primarily work against Internet Explorer,
|
|
make use of vulnerabilities that exist in web-browsers. What
|
|
generally happens is that when a users visits a malicious website,
|
|
an exploit will make Internet Explorer download and execute code. As
|
|
there are well known vulnerabilities in Internet Explorer at all
|
|
times that are not yet fixed, the bad guys usually have a couple of
|
|
days or weeks to spread their code. Of course, the infection rate
|
|
heavily depends on the number of visitors on the website hosting the
|
|
exploit. One approach that has been used in the past to gain access
|
|
to a wider 'audience' involved sending mail to thousands of users in
|
|
an attempt to get the users to visit a malicious website. Another
|
|
approach involved hacking advertisement companies and changing their
|
|
content in order to make them serve exploits and malware on high
|
|
profile sites.
|
|
|
|
|
|
2.3) Peer to Peer
|
|
|
|
The peer to peer worm is quite similar to the mail worm; it's all
|
|
about social engineering. Users hunting for the latest mp3s or
|
|
pictures of their most beloved celebrity find similarly named
|
|
programs and scripts, trying to deceive the user to download and
|
|
execute them. Once active on the users system, the malcode will make
|
|
sure it's being hosted by the users p2p application to spread
|
|
further. Even if downloaded, host based anti-virus scanners with
|
|
recent signatures will catch most of these programs before they can
|
|
be run.
|
|
|
|
|
|
2.4) Active
|
|
|
|
This one is the most dangerous worm, as it doesn't require any sort
|
|
of user interaction at all. It also requires the highest level of
|
|
skill to write. Active worms spread by scanning the internet for one
|
|
or more types of vulnerabilities. Once a vulnerable target is
|
|
found, an exploit attempt is made that, if successful, results in
|
|
the uploading of the worm to the attacked site where propagation can
|
|
continue in the same form. These worms are usually spotted first by
|
|
an increasing number of hosts scanning the internet, most often
|
|
scanning for a single port. These worms also usually exploit
|
|
weaknesses that are well-known to the public for hours, days, weeks
|
|
or months. Examples of this type of worm include the Wank worm,
|
|
Code Red, Sadmind, SQL Slammer, Blaster, Sasser and others. As the
|
|
use of firewalls and NAT routers increases, and as anti-exploit
|
|
techniques like the one employed by Windows XP SP2 become more
|
|
common, these worms will find less hosts to infect. To this point,
|
|
from the time of this writing, it's been a while since the last big
|
|
active worm hit the net.
|
|
|
|
|
|
Other active infection vectors include code spreading via unset or
|
|
weak passwords on CIFS Common Internet File System. The
|
|
protocol used to exchange data between Windows hosts via network
|
|
shares. shares, IRC and instant messaging networks, Usenet, and
|
|
virtually every other data exchange protocol.
|
|
|
|
3) Motives
|
|
|
|
3.1) Ego
|
|
|
|
Media attention often is a major motivation behind a worm. Coders
|
|
bolstering their ego by seeing reports on their worm on major sites
|
|
on the internet as well as tv news and newspapers with paniced
|
|
warnings of the latest doomsday threat which may take down the
|
|
planet and result in a 'Digital Pearl Harbor' seems
|
|
to be quite often the case. Huge media attention usually also means
|
|
huge law enforcement attention, and big efforts will be made to
|
|
catch the perpetrator. Though especially wide open (public) WIFI
|
|
networks can make it quite difficult to catch the perpetrator by
|
|
technological means, people boasting on IRC and, as in the case of
|
|
Sasser, bounties, can quickly result in the worm's author being
|
|
taken into custody.
|
|
|
|
|
|
3.2) DDoS
|
|
|
|
The reason for a DDoS botnet is usually either the wish to have
|
|
enough firepower to virtually shoot people/sites/organizations off
|
|
the net, or extortion, or a combination of both. The extortion of
|
|
gambling websites before big sports events is just one example of
|
|
many cases of extortion involving DDoS. The attacker usually takes
|
|
the website down for a couple of hours to demonstrate his ability to
|
|
do so whenever it pleases him, and sends a mail to the owner of the
|
|
website, asking for money to keep the firepower away from his site.
|
|
This sort of business model is well known for millenia, and merely
|
|
found new applications online.
|
|
|
|
|
|
3.3) Spamming
|
|
|
|
This one is also about money in the end. Infected machines are
|
|
(ab)used as spam zombies. Each machine sends their master's
|
|
unsolicited mail to lots and lots of unwilling recipients. The
|
|
owners of these systems usually offer their services to the spam
|
|
industry and thus make money of it.
|
|
|
|
|
|
3.4) Adware
|
|
|
|
Yet another reason involving money. Just like on TV and Google,
|
|
advertisements can be sold. The more people seeing the
|
|
advertisement, the more money can be requested from the people that
|
|
pay for their slogan to be displayed on some end users Windows. (Of
|
|
course, it could be Linux and MacOS too, but, face it, no adware
|
|
attacks those)
|
|
|
|
|
|
3.5) Hacking
|
|
|
|
A worm that infects and backdoors a couple thousand hosts is a great
|
|
way to quickly and easily obtain data from those systems. Examples
|
|
of data that may be worth stealing includes accounts for online
|
|
games, credit card numbers, personal information that can be used in
|
|
identity theft scams, and more. There has even been a report that
|
|
items of online games were being stolen to sell those later on
|
|
E-bay. Already having compromised one machine, enhancing the
|
|
influence into some network can be much easier of course. Take for
|
|
example the case of a heavily firewalled company. A hacker can't get
|
|
inside using an active approach, but notices that one of his malware
|
|
serving websites infected a host within that network. Using a
|
|
connect-back approach, where the infected node connects to the
|
|
attacker, a can tunnel can be built through the firewall thereby
|
|
allowing the attacker to reach the internal network.
|
|
|
|
4) Botnets
|
|
|
|
While I did mention DDoS and spam as reasons for infection already,
|
|
what I left out so far was the infrastructure of hundreds or
|
|
thousands of compromised machines, which is usually called a
|
|
botnet. Once a worm has infected lots of systems, an
|
|
attacker needs some way to control his zombies. Most often the nodes
|
|
are made to connect to an IRC server and join a (password protected)
|
|
secret channel. Depending on the malware in use, the attacker can
|
|
usually command single or all nodes sitting on the channel to, for
|
|
example, DDoS a host into oblivion, look for game CD keys and dump
|
|
those into the channel, install additional software on the infected
|
|
machines, or do a whole lot of other operations. While such an
|
|
approach may be quite effective, it has several shortcomings.
|
|
|
|
- IRC is a plaintext protocol.
|
|
|
|
Unless every node builds an SSL tunnel to an SSL-capable IRCD,
|
|
everything that goes on in the channel will be sent from the IRCD to
|
|
all nodes connected, which means that someone sniffing from an
|
|
infected honeypot can see everything going on in the channel,
|
|
including commands and passwords to control the botnet. Such a
|
|
weakness allows botnets to be stolen or destroyed (f.ex. by issuing
|
|
a command to make them connect to a new IRCD which is on IP
|
|
127.0.0.1).
|
|
|
|
- It's a single point of failure.
|
|
|
|
What if the IRCD goes down because some victim contacted the admin
|
|
of the IRC server? On top of this, an IRC Op (a IRC administrator)
|
|
could render the channel inaccessible. If an attacker is left
|
|
without a way to communicate with all of the zombie hosts, they
|
|
become useless.
|
|
|
|
A way around this dilemma is to make use of dynamic DNS sites like
|
|
www.dyndns.org. Instead of making the zombies connect to
|
|
irc.somehost.com, the attacker can install a dyndns client which
|
|
then allows drones to reference a hostname that can be directed to a
|
|
new address by the attacker. This allows the attacker to migrate
|
|
zombies from one IRC server to the next without issue. Though this
|
|
solves the problem of reliability, IRC should not be considered
|
|
secure enough to operate a botnet successfully.
|
|
|
|
|
|
The question, then, is what is a better solution? It seems the
|
|
author of the trojan Phatbot already tried to find a way
|
|
around this problem. His approach was to include peer to peer
|
|
functionality in his code. He ripped the code of the P2P project
|
|
``Waste'' and incorporated it into his creation. The problem was,
|
|
though, that Waste itself didn't include an easy way to exchange
|
|
cryptographic keys that are required to successfully operate the
|
|
network, and, as such, neither did Phatbot. The author is not aware
|
|
of any case where Phatbot's P2P functionality was actually used.
|
|
Then again, considering people won't run around telling everyone
|
|
about it (well, not all of them at least), it's possible that such a
|
|
case is just not publicly known.
|
|
|
|
|
|
To keep a botnet up and running, it requires reliability,
|
|
authentication, secrecy, encryption and scalability. How can all of
|
|
those goals be achieved? What would the basic functionality of a
|
|
perfect botnet require? Consider the following points:
|
|
|
|
- An easy way to quickly send commands to all nodes
|
|
- Untraceability of the source IP address of a command
|
|
- Impossibile to judge from an intercepted command packet which node it was
|
|
addressed to
|
|
- Authentication schemes to make sure only authorized personnel operate the
|
|
zombie network
|
|
- Encryption to conceal communication
|
|
- Safe software upgrade mechanisms to allow for functionality enhancements
|
|
- Containment; so that a single compromised node doesn't endanger the entire
|
|
network
|
|
- Reliability; to make sure the network is still up and running when most of
|
|
its nodes have gone
|
|
- Stealthiness on the infected host as well as on the network
|
|
|
|
At this point one should distinguish between unlinked and
|
|
linked, or passive, botnets. Unlinked means each node is on
|
|
its own. The nodes poll some central resource for information.
|
|
Information can include commands to download software updates, to
|
|
execute a program at a certain time, or the order a DDoS on a given
|
|
target machine. A linked botnet means the nodes don't do anything by
|
|
themselves but wait for command packets instead. Both approaches
|
|
have advantages and disadvantages. While a linked botnet can react
|
|
faster and may be more stealthy considering the fact that it doesn't
|
|
build up periodic network connections to look out for commands, it
|
|
also won't work for infected nodes sitting behind firewalls. Those
|
|
nodes may be able to reach a website to look for commands, which
|
|
means an unlinked approach would work for them, but command packets
|
|
like in the linked approach won't reach them, as the firewall will
|
|
filter those out. Also, consider the case of trying to build up a
|
|
botnet with the next Windows worm. Infected Windows machines are
|
|
generally home users with dynamic IP addresses. End-user machines
|
|
change IPs regularly or are turned off because the owner is at work
|
|
or on a hunting weekend. Good luck trying to keep an up-to-date list
|
|
of infected IPs. So basically, depending on the purpose of the
|
|
botnet, one needs to decide which approach to use. A combination of
|
|
both might be best. The nodes could, for example, poll a resource of
|
|
information once a day, where commands that don't require immediate
|
|
attention are waiting for them. On the other hand if there's
|
|
something urgent, sending command packets to certain nodes could
|
|
still be an option. Imagine a sort of unlinked botnet. No node knows
|
|
about another node and nor does it ever contact one of its brothers,
|
|
which perfectly achieves our goal of containment. These nodes
|
|
periodically contact what the author has labeled a resource
|
|
of information to retrieve their latest orders. What could such a
|
|
resource look like?
|
|
|
|
The following attributes are desirable:
|
|
|
|
- It shouldn't be a single point for failure, like a single host that makes
|
|
the whole system break down once it's removed.
|
|
- It should be highly anonymous, meaning connecting there shouldn't be
|
|
suspicious activity. To the contrary, the more people requesting information
|
|
from it the better. This way the nodes' connections would vanish in the
|
|
masses.
|
|
- The system shouldn't be owned by the botnet master. Anonymity is one of the
|
|
botnet's primary goals after all.
|
|
- It should be easy to post messages there, so that commands to the botnet can
|
|
be sent easily.
|
|
|
|
There are several options to achieve these goals. It could be:
|
|
|
|
- Usenet: Messages posted to a large newsgroup which contain
|
|
steganographically hidden commands that are cryptographically signed
|
|
achieves all of the above mentioned goals.
|
|
- P2P networks: The nodes link to a server once in a while and, like hundreds
|
|
of thousands of other people, search for a certain term (``xxx''), and find
|
|
command files. File size could be an indicator for the nodes that a certain
|
|
file may be a command file.
|
|
- The Web itself: This one would potentially be slow, but of course it's also
|
|
possible to setup a website that includes commands, and register that site
|
|
with a search engine. To find said site, the zombies would connect to the
|
|
search engine and submit a keyword. A special title of the website would
|
|
make it possible to identify the right page between thousands of other hits
|
|
on the keyword, without visiting each of them.
|
|
|
|
|
|
|
|
Using those methods, it would be possible to administer even large
|
|
botnets without even having to know the IP adresses of the nodes.
|
|
The ``distance'' between botnet owner and botnet drone would be as
|
|
large as possible since there would be no direct connection between
|
|
the two. These approaches also face several problems, though:
|
|
|
|
|
|
How would the botnet master determine the number of infected hosts
|
|
that are up and running? Only in the case of the website would
|
|
estimation of the number of nodes be possible by inspecting the
|
|
access logs, even logging were to be enabled. In the case of the
|
|
Usenet approach a command of ``DDoS Ebay/Yahoo/Amazon/CNN'' might
|
|
just reach the last 5 remaining hosts, and the attacker would only
|
|
be left with the knowledge that it somehow didn't work. The problem
|
|
is, however, that the attacker would not know the number of zombies
|
|
that would actually take part in the attack. The same problem occurs
|
|
with the type and location of the infected hosts. Some might be high
|
|
profile, such as those connecting from big corporations, game
|
|
developers, or financial institutions. The attacker might be
|
|
interested in abusing those for something other than Spam and DDoS,
|
|
if he knew about them in particular. If the attacker wants to bounce
|
|
his connections over 5 of his compromised nodes to make sure he
|
|
can't be traced, then it is required that he be able to communicate
|
|
with 5 nodes only and that he must know address information about
|
|
the nodes. If the attacker doesn't have a clue which IP addresses
|
|
his nodes have, how can he tell 5 of them where to connect to?
|
|
Besides the obvious problem of timing, of course. If the nodes poll
|
|
for a new command file once every 24 hours, he'd have to wait 24
|
|
hours in the worst case until the last node finds out it's supposed
|
|
to bind a port and forward the connection to somewhere else.
|
|
|
|
|
|
4.1) The Linked Network
|
|
|
|
Though I called this approach a passive network, as the nodes idle
|
|
and wait for commands to come to them, this type of botnet is in
|
|
fact quite active. The mechanisms described now will not (easily)
|
|
work when most of the nodes are on dynamic IP addresses. It is thus
|
|
more interesting for nodes installed after exploiting some kind of
|
|
server software. Of course, while not solving the uptime problem, a
|
|
rogue dyndns account can always give a dynamic IP a static hostname.
|
|
|
|
|
|
|
|
This kind of network focuses on all of its nodes forming some kind
|
|
of self-organizing peer to peer network. A node that infects some
|
|
other host can send over the botnet program and make the new host
|
|
link to itself, thus becoming that node's parent. This technique can
|
|
make the infected hosts form a sort of tree structure over time, as
|
|
each newly infected host tries to link to the infecting host.
|
|
Updates, information, and commands can be transmitted using this
|
|
worm network to reach each node, no matter which node it was sent
|
|
from, as each node informs both child nodes as well as its parent
|
|
nodes. In its early (or final) stages, a network of this type might
|
|
look like this piece of ascii art:
|
|
|
|
Level
|
|
0 N
|
|
/ \
|
|
1 N N
|
|
/ \ /
|
|
2 N N N
|
|
|
|
To make sure a 'successful' node that infects lots of hosts doesn't
|
|
become the parent of all of those hosts, nodes must refuse link
|
|
requests from child nodes after a certain number have been linked
|
|
(say 5). The parent can instead in form the would-be child to link
|
|
to one of its already established children instead. By keeping track
|
|
of the number of nodes linked to each location in the tree, a parent
|
|
can even try to keep the tree thats hierarchically below it well
|
|
balanced. This way a certain node would know about its parent and up
|
|
to 5 children, thus keeping the number of other hosts that someone
|
|
who compromises a node rather low, while still making sure to have a
|
|
network that's as effective as possible. Depending on the number of
|
|
nodes in the entire network, the amount of children that may link to
|
|
a parent node could be easily changed to make the network scale
|
|
better. As each node may be some final link as well as a parent
|
|
node, every host runs the same program. There's no need for special
|
|
'client' and 'server' nodes.
|
|
|
|
|
|
Whats the problem with a tree structure? Well, what if a parent
|
|
fails? Say a node has 3 children, each having 2 children of its own.
|
|
Now this node fails because the owner decides to reinstall the host.
|
|
Are we left with 3 networks that can't communicate with each other
|
|
any more? Not necessarily. While possibly giving a forensics expert
|
|
information on additional hosts, to increase reliability each node
|
|
has to know about at least one more upstream node that it can try to
|
|
link to if its parent is gone. An ideal candidate could be the
|
|
parent's parent. In order to make sure that all nodes are still
|
|
linked to the network, a periodic (once a day) sort of ``ping''
|
|
through the entire network has to happen in any case. By giving a
|
|
child node the IP of its ``grandparent'', the direct parent of the
|
|
child node always knows that the fail-over node, the one its kids
|
|
will try to link to if it should fail, is still up and running.
|
|
|
|
|
|
Though this may help to address the issue of parent death, another
|
|
issue remains. If the topmost node fails, there are no more
|
|
upstream nodes that the children could link to. Thats why in this
|
|
case the children should have the ip of one(!) of its siblings as
|
|
the fail-over address so that they can make this one the new top
|
|
node in the case of a fail-over condition. Making use of the
|
|
node-based ping, each node also knows how many of its children are
|
|
still up and running. By including this number into the ping sent to
|
|
the parent, the topmost node could always tell the number of linked
|
|
hosts. In order to not have to rely on connecting to the topmost
|
|
node to collect this type of information, a simple command can be
|
|
implemented to make the topmost node report this info to any node on
|
|
the network that asks for it. Using a public key stored into all the
|
|
nodes, it's even possible to encrypt every piece of information
|
|
thats destined for the botnet owner, making sure that no one besides
|
|
the owner can decrypt the data. Although this type of botnet may
|
|
give a forensics expert or someone with a sniffer information on
|
|
other nodes that are part of the network, it also offers fast
|
|
response times and more flexibility in the (ab)use of the network
|
|
compared to the previous approach with the unlinked nodes. It's a
|
|
sort of trade off between the biggest possible level of anonymity on
|
|
one hand, and flexibility on the other. It is a huge step up
|
|
compared to all of the zombies sitting on IRC servers right now,
|
|
where a single channel contains the zombies of the entire botnet. By
|
|
employing cryptography to store the IPs of the child and parent
|
|
nodes, and keeping those IPs only in RAM mitigates the problem
|
|
further.
|
|
|
|
|
|
Once a drone network of this type has been established with several
|
|
hundreds of hosts, there are lots of possibilities of putting it to
|
|
use. To conceal the originating IP address of a connection, hopping
|
|
over several nodes of the drone network to a target host can be
|
|
easily accomplished. A command packet tells one node to bind a port.
|
|
Once it receives a connection on it, it is told to command a second
|
|
node to do the same, and from then on node 1 forwards all the
|
|
traffic to node 2. Node 2 does the same, and forwards to node 3,
|
|
then 4, maybe 5, until finally the last node connects to the
|
|
intended destination IP. By encrypting the entire connection from
|
|
the original source IP address up to the last node, a possible
|
|
investigator sniffing node 2 will not see the commands (and thus the
|
|
IP addresses) which tell node 3 to connect to node 4, node 4 to node
|
|
5, and of course especially not the destination host's address. An
|
|
idle timeout makes sure that connections don't stay up forever.
|
|
|
|
|
|
As manually updating several hundreds or thousands of hosts is
|
|
tedious work, an easy updating system should be coded into the
|
|
nodes. There are basically two possible ways to realize that. A
|
|
command, distributed from node to node all over the network, could
|
|
make each node replace itself with a newer version which it may
|
|
download from a certain HTTP address. The other way is by updating
|
|
the server software on one node, which in turn distributes this
|
|
update to all the nodes it's linked to (children and
|
|
parent), which do just the same. Cryptographic signatures are a must
|
|
of course to make sure someone doesn't replace all of the precious
|
|
nodes with SETI@home. Vlad902 suggested a simple and effective way
|
|
to do that. Each node gets an MD5 hash hardcoded into it. Whenever
|
|
someone offers a software update, it will download the first X bytes
|
|
and see wether they hash to the hardcoded value. If they do, the
|
|
update will be installed. Of course, a forensics expert may extract
|
|
the hash out of an identified node. However, due to the nature of
|
|
cryptographic hashes, he won't be able to tell which byte sequence
|
|
generates that hash. This will prevent the forensics export from
|
|
creating a malicious update to take down the network. As the value
|
|
used to generate the hash has to be considered compromised after an
|
|
update, each update has to supply a new hash value to look out for.
|
|
|
|
|
|
Further security mechanisms could include making the network
|
|
completely memory resident, and parents keeping track of kids, and
|
|
reinfecting those if necessary. What never hit the hard-disk can
|
|
obviously not be found by forensics. Also, commands should be
|
|
time-stamped to make sure a certain command will only work once, and
|
|
replay attacks (sending a sniffed command packet to trigger a
|
|
response from a node) will fail. Using public key cryptography to
|
|
sign and encrypt data and communication is always a nice idea too,
|
|
but it also has 2 disadvantages:
|
|
|
|
- It usually produces quite a big overhead to incorporate into the code.
|
|
- Holding the one and only private key matching to a public key thats been
|
|
found on hundreds of hacked hosts is quite incriminating evidence.
|
|
|
|
An additional feature could be the incorporation of global unique
|
|
identifiers into the network, providing each node with a unique ID
|
|
that's set upon installation on each new victim. While the network
|
|
master would have to keep track of host addresses and unique IDs, he
|
|
could use this feature to his advantage. Imagine a sort of
|
|
traceroute within the node network. The master wants to know where a
|
|
certain host is linked to. Every node knows the IDs of all of the
|
|
child nodes linked hierarchically below it. So he asks the topmost
|
|
node to find out the path to the node he's interested in. The
|
|
topmost node realizes it's linked somewhere under child 2, and in
|
|
turn asks child 2. This node knows it's linked somewhere below child
|
|
4, and so on and so on. In the end, the master gets his information,
|
|
a couple of IDs, while no node thats not directly linked to another
|
|
gets to know the IPs of further hosts that are linked to the
|
|
network.
|
|
|
|
|
|
Since a portscan shouldn't reveal a compromised host, a raw socket
|
|
must be used to sniff command packets off the wire. Also, command
|
|
packets should be structured as unsuspicious as possible, to make it
|
|
look like the host just got hit by yet another packet of ``internet
|
|
background noise''. DNS replies or certain values in TCP SYN packets
|
|
could do the trick.
|
|
|
|
|
|
4.2) The Hybrid
|
|
|
|
There is a way to combine both the anonymity of an unlinked network
|
|
with the quick response time of the linked approach. This can be
|
|
done by employing a technique first envisioned in the description of
|
|
a so-called ``Warhol Worm''. While no node knows anything about
|
|
other nodes, the network master keeps track of the IPs of infected
|
|
hosts. To distribute a command to a couple or maybe all of the
|
|
nodes, he first of all prepares an encrypted file containing the IPs
|
|
of all active nodes, and combines that with the command to execute.
|
|
He then sends this commandfile to the first node on the list. This
|
|
node executes the command, takes itself from the list, and goes top
|
|
to bottom through the list, until it finds another active node,
|
|
which it transmits the command file to. This way each node will only
|
|
get to know about other nodes when receiving commandfiles, which are
|
|
subsequently erased after the file has been successfully transmitted
|
|
to another node. By calling certain nodes by their unique IDs, it's
|
|
even possible to make certain nodes take different actions than all
|
|
the others. By preparing different files and sending them to
|
|
different nodes at start already, quite a fast distribution time can
|
|
be achieved. Of course, should someone accomplish to not only sniff
|
|
the commandfile, but also decrypt it, he has an entire list of
|
|
infected hosts. Someone sniffing a node will still also see an
|
|
incoming connection from somewhere, and an outgoing connection to
|
|
somewhere else, and thus get to know about 2 more nodes. Thats just
|
|
the same as depicted in the passive approach. Whats different is
|
|
that a binary analysis of a node will not divulge information on
|
|
another host of the network. As sniffing is probably more of a
|
|
threat than binary analysis though, and considering a linked network
|
|
offers way more flexibility, the Hybrid is most likely an inferior
|
|
approach.
|
|
|
|
|
|
5) Conclusion
|
|
|
|
When it comes to botnets, the malcode development is still in it's
|
|
infancy, and while today's networks are very basic and easily
|
|
detected, the reader should by now have realized that there are far
|
|
better and stealthier ways to link compromised hosts into a network.
|
|
And who knows, maybe one or more advanced networks are already in
|
|
use nowadays, and even though some of their nodes have been spotted
|
|
and removed already, the network itself has just not been identified
|
|
as being one yet.
|
|
|
|
|
|
Bibliography
|
|
|
|
The Honeypot Project. Know Your Enemy: Tracking Botnets.
|
|
http://www.honeynet.org/papers/bots/
|
|
|
|
Weaver, Nicholas C. Warhol Worms: The Potential for Very
|
|
Fast Internet Plagues.
|
|
http://www.cs.berkeley.edu/ nweaver/warhol.html
|
|
|
|
Paxson, Vern, Stuart Staniford Nicholas Weaver. How to
|
|
0wn the Internet in Your Spare Time.
|
|
http://www.icir.org/vern/papers/cdc-usenix-sec02/
|
|
|
|
Zalewski, Michael. Writing Internet Worms for Fun and
|
|
Profit.
|
|
http://www.securitymap.net/sdm/docs/virus/worm.txt
|