From: Ariel Waissbein (core.lists.pentest@coresecurity.com)
Date: Wed Aug 30 2006 - 13:42:54 EDT
Hi all,
Together with Gera Richarte and Ariel Futoransky, we are currently
working on a paper that describes what an attacker can do in the
scenario you describe, e.g., when network traffic is logged. Our main
result is that attackers can conduct their actions using crypto
intelligently and as a result analyzes that combine network traffic logs
with N-IDS/IPS will reveal no information about the attack. It appears
that all syscalls in each system should also be logged. This is what we
think that will start to happen in the future.
To be more explicit, let me give one simple but meaningful example that
we included in the paper. Imagine a bot that has several functions and
each is encrypted with a different symmetric key (say, AES). The bot
listens in a prescribed port, and when it receives an input it matches
its hash with a list of prefixed hashes, if it match any of these then
it uses the input as a key to decrypt the function associated with the
match. (If the function uses parameters, then the parameters might be
sent encrypted with a key that is inside the encrypted function.)
When the attacker needs to execute one of these functions he will send
the key (and encrypted parameters) and the bot will (magically) decrypt
and execute the function. The attacker might have included a way to
delete the code after its usage. All the information returned by the bot
is encrypted, say, using a public key generated by the attacker a priori
that is inside each of the encrypted functions.
In order to know what has the attacker done (or find out what
information was sent back to the attacker), the forensic analyst must
recover the "original bot" from the logs, and break AES or retrieve the
keys from the logs (in case they have been used). So first, only those
functions that have been executed can be reversed. Second: If only the
first m bytes are logged, then the bot can be made to parse every
incoming packet in 16-byte long strings and try to match each of these
as a possible key; hence the key will not be logged. If everything is
logged then 266g of data a day for a space of one month makes 266g*30/16
=~2^39 checks, per executed function. One could easily rise this upper
bound so that it is infeasible to break the scheme. More complex ideas
will be described in the paper. One quick trick which would raise the
bound to 2^50 would be to have a list of 2^11 possible entry points for
the input (e.g., 2^11 many functions that receive a possible key as
input, and attempt to use it to decrypt a piece of code that contains
one of the encrypted functions); these ideas are also discussed in the
[BFNSW] paper cited below. Hence to discover what has(2^11)*(2^39) = 2^50.
To add further complications in the key-reconstruction/key-derivation
process you can use password schemes that resist offline attacks, or
other implementations of the encryption functionality demonstrated
above, that we chose to call triggers; e.g., see
Futoransky, Kargieman, Sarraute, Waissbein. "Foundations and
applications for secure triggers." ACM TISSEC 9(1), 2006. and
Bendersky, Futoransky, Notarfrancesco, Sarraute, Waissbein. "Advanced
Software Protection Now" Corelabs technical report, Core Security
Technologies. 2003
Obtainable at my homepage http://community.corest.com/~wata or
http://www.coresecurity.com/corelabs/papers/index.php or wait for the
paper that will be ready in a coupla weeks :(
Cheers,
Ariel
xelerated wrote:
> Im posrting this to the pen-test group, rather than firewall or IDS
> because it covers many areas.
>
> Id like to see what the pro's think about capturing and storing packet
> payloads from firewalls, ids, etc... everything rather than just
> loggin the incidents.
>
> Im trying to explain to my management how useful the payloads could be
> if we were ever to
> really need them, say from a forensics point of view.
> To give another example, one time I was seeing lots of firewall drops,
> I could tell what ports, src and dest. but no packet data. To everyone
> involved it looked like a worm trying to spread.
> Well in the end it wasnt, infact is was something that was nice to
> know about, but it was not hostile traffic. But if I had been able to
> see the payloads i could have seen the data request and known from the
> start what it was, or was not.
>
> What would be really great, is a whitepaper covering this, or enough
> info/facts that I could throw one together.
>
> thanks!
> Chris
>
> C|EH, CISSP
>
> ------------------------------------------------------------------------
> This List Sponsored by: Cenzic
>
> Need to secure your web apps?
> Cenzic Hailstorm finds vulnerabilities fast.
> Click the link to buy it, try it or download Hailstorm for FREE.
> http://www.cenzic.com/products_services/download_hailstorm.php
> ------------------------------------------------------------------------
>
-- Ariel Waissbein RESEARCHER CORE SECURITY TECHNOLOGIES Tel./Fax: (54-11) 5556-2673 Humboldt 1967, 2do piso Capital Federal, Argentina http://www.coresecurity.com/corelabs ------------------------------------------------------------------------ This List Sponsored by: Cenzic Need to secure your web apps? Cenzic Hailstorm finds vulnerabilities fast. Click the link to buy it, try it or download Hailstorm for FREE. http://www.cenzic.com/products_services/download_hailstorm.php ------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:52 EDT