Penetration Testing mailing list archives
Re: Packet Payload
From: Ariel Waissbein <core.lists.pentest () coresecurity com>
Date: Wed, 30 Aug 2006 14:42:54 -0300
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 ------------------------------------------------------------------------
Current thread:
- Re: Packet Payload, (continued)
- Re: Packet Payload xelerated (Aug 29)
- RE: Packet Payload Remad (Aug 29)
- Re: Packet Payload xelerated (Aug 29)
- Re: Packet Payload Peter Van Epp (Aug 29)
- RE: Packet Payload Clemens, Dan (Aug 29)
- RE: Packet Payload Javier Romero (Aug 29)
- Message not available
- Message not available
- Re: Packet Payload Mike Klingler (Aug 30)
- Message not available
- Re: Packet Payload David J. Bianco (Aug 30)
- Re: Packet Payload Security (Aug 30)
- RE: Packet Payload Robert D. Holtz - Lists (Aug 30)
- Re: Packet Payload griffkc (Aug 31)
- RE: Packet Payload Robert D. Holtz - Lists (Aug 30)
- Re: Packet Payload Ariel Waissbein (Aug 30)
- Re: Packet Payload xelerated (Aug 30)
- RE: Packet Payload Hirsch, Adam (Aug 29)
- RE: Packet Payload Clemens, Dan (Aug 29)
- Re: Packet Payload xelerated (Aug 29)
- Re: Packet Payload Joey Peloquin (Aug 30)
- RE: Packet Payload Clemens, Dan (Aug 29)