From: xelerated (xelerated@gmail.com)
Date: Wed Aug 30 2006 - 13:53:14 EDT
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
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:52 EDT