Home page logo
/

pen-test logo Penetration Testing mailing list archives

Re: Packet Payload
From: xelerated <xelerated () gmail com>
Date: Wed, 30 Aug 2006 13:53:14 -0400

I see your point. But also, if in your enterprise normally the only
encrypted traffic should be SSH and HTTPS, but you catch alot of
other random port encrypted traffic, that would atleast be enough to raise
the red flag.
In my situation, i have a list of all the outsider IPs i may see, they have been
granted access. If i see an IP that does not match on that list, sure
my list "could"
be slightly outdated, but atleast i know to go check on it.

IMHO even if encryption is used, there could be enough information still
to know something just is not right and it could well be an attack.

And if you see lots of traffic which after some research could be
remote commands to
a bot or whatever, then you have a point to start a sniffer and trace
where/if the data is passed unencrypted.

Network security isnt easy, but it sure is fun.



On 8/30/06, Ariel Waissbein <core.lists.pentest () coresecurity com> wrote:
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
------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]