Re: Check Point Invented (R)(TM) the great sand-boxing and now protects you against "Day0"!

[H D Moore <hdm-daily-dave () digitaloffense net>]

Bahahaha, "wire-speed" executable code dissassembly and analysis, because 
*everyone* knows that executable code looks nothing like application 
data! Hey, wait, whats this ascii-encoded shellcode thing...

Some funny excerpts for those too lazy to scan through the PDF. Too bad 
their "design assumptions" cut their entire amazing idea out at the 
knees :-)

<quote>
Design Assumptions

As discussed earlier, buffer overflows attack the memory system of a 
target host using specially crafted malicious code. All buffer overflow 
attacks send executable code in the network payload of an attack. Buffer 
overflow attacks must contain code that will be run on the target 
computer; otherwise they can not perform any hostile actions. Based on 
the above, the following assumptions were made: 

1. All network-based malicious overflow attacks must contain executable 
code in machine language. 

2. Network traffic does not usually contain executable machine code. In 
the rare cases where a legitimate executable code is transferred over the 
network (e.g. download of an .exe file), it can be easily identified as 
such. Typically, EXE files are sent from servers to clients, while 
attacks are launched from clients to servers. 

3. It is possible to write an algorithm to detect machine code in network 
traffic with high accuracy, low false positives rates and high 
performance. Based on the assumptions above, Check Point created an 
algorithm that meets the design goals of the Malicious Code Protector. 
Since Malicious Code Protector can detect machine code in network 
traffic, and we know that each attack must have machine code from our 
assumptions, the algorithm can detect actual attacks regardless of the 
specific buffer overflow vulnerabilities an attack is exploiting.

Looking for Executable Code

 The heart of the Malicious Code Protector is a disassembler engine that 
can examine network traffic and detect executable code (i.e., disassemble 
binary data into machine assembly language). This ability to detect 
executable code is related to the assumption that executable code is 
normally not allowed to traverse a network, with the exception of a few 
well known cases, such as an FTP transfer of an executable (*.exe) file.

 Malicious Code Protector monitors data streams and looks for a sequence 
of data that the disassembler engine can translate into machine assembly 
language. This indicates the possible existence of executable code 
passing through a network. However, this alone is not sufficient when 
trying to determine whether a certain data stream contains executable 
code, let alone code of malicious nature. 

There are instances where nonexecutable data can generate an 
assembly-looking output. For example, a .gif file can in some cases 
produce machine assembly instructions even though it is not an 
application. Therefore, the Malicious Code Protector must be able to 
distinguish between the random "noise" of assemblylike data and a real 
executable in network traffic.
</quote>

-HD


On Wednesday 06 July 2005 18:15, Tiago Assumpcao wrote:
> Check Point has just achieved such a great technical advancement: think
> twice before sending your Evil Machine Code through the network pipe.
> No more "Day0" :<
>
> It is now Checking forward to getting a Point patented...
>
> Carry on, fellows -- http://whatever.org.ar/~module/mcp_whitepaper.pdf
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave