Re: Packet Payload

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
------------------------------------------------------------------------

Relevant Pages

  • Vulnerability in encrypted loop device for linux
    ... An attacker is able to modify the content of the encrypted device ... considered a aim of the encryption mode, so most modes (e.g. ECB, CFB, ... As we need to authenticate the device across mounts and not while it is ... It slows down mount operations but they are ...
    (Bugtraq)
  • [UNIX] Vulnerability in Encrypted Loop Device for Linux
    ... Encrypting a disk device aims to protect against an off-line attacker who ... The encryption mode used by encrypted loop device is CBC. ... We propose 2 types of fixes: one that authenticate at mount time (see ...
    (Securiteam)
  • Re: Packet Payload
    ... IMHO even if encryption is used, there could be enough information still ... a bot or whatever, then you have a point to start a sniffer and trace ... When the attacker needs to execute one of these functions he will send ... > Cenzic Hailstorm finds vulnerabilities fast. ...
    (Pen-Test)
  • Re: Question about rsync
    ... The most important aspect of security is improving your weakest links - when you are at the stage that the easiest methodof attack is physical, or personal, then your job as IT security is pretty much done. ... It makes sense to take easy steps to increase security if you can - an attacker might not have the same opinion about the easiest methodof attack as you. ... but it contains information about an algorithm aimed precisely at transferring only those parts of a file that have changed. ... So unless you are doing a backup of a nuclear missile design, encryption on an rsync backup will only make a realistic difference if your network topology is such that the traffic is accessible by more people. ...
    (comp.os.linux.networking)
  • Re: How good an encryption algorithm is this?
    ... in the scenario I described. ... which the attacker gets her hands on that data. ... It's the fact that your algorithm makes it fairly easy to deduce the key ... And don't forget that you started by asking "How good an encryption ...
    (microsoft.public.dotnet.languages.csharp)