Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
- where such C&C networks then are easier to dismantle since only
need to bring down a single central point
====================
Brief summary (mine)
====================
A weakness of traditional centralized botnet C&C is the single point
of failure: an entire botnet can be dismantled by bringing down a
single node (the C&C server). While using P2P for C&C provides some
benefits in the form of resiliency to loss of single nodes, it also
presents some (surrmountable/manageable) challenges such as latency
and lack of reliability in message transmission. They note the
simultaneous though largely independent evolution of malicious bots
and peer-to-peer protocols. It is not expected that moving a botnet
from a centralized to decentralized C&C topology will fundamentally
alter how that botnet is used; it only affects the way in which
messages -- commanding the bots to do X, Y, or Z -- are delivered
to those bots.
--------
I. Intro
--------
In peer-to-peer architecture, theoretically no single point of failure.
--------------------
II. Bkgd and History
--------------------
peer-to-peer network: one in which any node can act as both a client
and a server
History of P2P:
---------------
1) P2P gained momentum with Napster
3) Freenet developed
- every file was associated with a key; files with similar keys
were clustered on a similar set of nodes(?)
----------------------
III. Goals and Metrics
----------------------
P2P botnets likely to have higher latency for message transmission than
centralized C&C would. Also, P2P protocols offer varying levels of
reliability of message transfer; clearly such reliability can be layered
on top of the particular P2P protocol however whereas the extra latency
introduced by P2P can be minimized (at the cost of additional state)
but is otherwise inherent in that architecture.
------------------------------
IV. Case Study: Trojan.Peacomm
------------------------------
Uses Overnet P2P protocol for C&C. The Overnet protocol implements a D
HT.
--> This 'initial bot' can connect to the P2P network and
consists of: a kernel driver (wincom32.sys)
--> The decryption key for this URL is hard-coded in the bot binary
--> Then the bot downloads the decrypted URL (from the web)
- have each bot continually poll the network for some static key
- the 'value' associated with that key may be NULL when there is
no command to be executed
(b) each bot downloads the new secondary injection (bot update)
which is analogous to executing a received command
Can also configure bot for periodic updates -- that is, for the bot
to periodically search for the 'key' associated with some 2ndary
injection -- where the 'value' of that key is the encrypted URL.
-------------------------------
Countermeasure: index poisoning
-------------------------------
- identify some set of target keys
- then inject bogus values into the P2P network for those keys
http://cis.poly.edu/~ross/papers/poison.pdf
- so when P2P users search for that 'key', they will get
bogus values for peers that were supposed to have been
storing the 'value' associated with that key: thus
impeding the users' ability to download the 2ndary injection