Dangling Pointer … Jonathan Afek
Dangling pointers are pointers that do not point to a valid object of the appropriate type, or to a distinguished null pointer value in languages which support this. It can be caused when an object is deleted or de-allocated, without modifying the value of the pointer, so that the pointer still points to the memory location of the de-allocated memory.
If the pointer is used to make a virtual function call, a different address (possibly pointing at exploit code) may be called due to the vtable pointer being overwritten. Alternatively, if the pointer is used for writing to memory, some other data structure may be corrupted.
Nevertheless, Java-based applications are not vulnerable to this exploit because the language has a built-in mechanism for de-allocating memory.
Jonathan and Adi found that they could cause the crash Web server intentionally by sending a specially crafted URL to the server and found a way to run their own code on the target machine.
Tactical Exploitation HD Moore & Valsmith
One of the most popular briefings was “Tactical Exploitation” by H.D. Moore of Metasploit , and Valsmith from offensive-computing (No place to sit or stand).
They talked about how to correctly pen-test an organization – not just by blindly using exploit code. They presented a number of tools that are not available yet but should be soon as new modules for Metasploit.
The first half of the talk focused on some lesser-known discovery and fingerprinting method, and more-known tools. They showed how to collect information (reconnaissance) on the target (person/network) as the first step of the penetrating testing process. A few examples were shown, using third-party services, such as DomainTools.com and others (such as using the web interface to Paterva’s – http://www.paterva.com/evolution.html ).Old techniques (such as reverse DNS, zone transfer) and more active technique (using SMTP bounces, brute force HTTP virtual host)
The first half ended up with some examples of real-life service fingerprinting, including graphing the traffic activity for a particular web site.
They discussed firewall discovery, client applications discovery, and even process discovery.
The second half of the talk discussed some topics, such as entry points into the external network, and issues caused by using NAS devices as file servers. It led into a discussion of NTLM hijacking, NFS tricks, abuse of the OpenSSH master mode, and a demo of stealing Kerberos tickets.
More technical stuff – http://metasploit.com/confs/blackhat2007/tactical_paper.pdf
Building and Breaking the Browser (Window Snyder)
The Mozila security crew selected a transparent approach and shared their knowledge regarding the weaknesses of their software.
One of the values from this approach can be seen by the release of tools such as the http fuzzer they have spoken about in the convection. The fuzzer is used against JavaScript.
They claim that the fuzzer has already produced some findings and released it to the public after the meeting.
One of the points mentioned in the talk was the plan to create a “blocking page” much like other security products currently offer. This is due in the next version they will release.
CaffeineMonkey: Automated Collection, Detection and Analysis of Malicious JavaScript
Ben Feinstein, Daniel Peck
The authors present a software framework for the automated collection of JavaScript from the wild that they have developed. The goal is identification of malicious code, and characteristic analysis of malicious code once identified.
The focus of the lecture was on attacks using JavaScript for obfuscation or exploitation, such as “white spaces randomization, string encoding, string splitting, and integer obfuscation.”
They presented findings & analysis based on the deployment of a distributed network of “CaffeineMonkeys”, and their method using honey clients and “behavior analysis” that was not detailed, to identify malicious code.
This was a rather reassuring lecture for us – as we know obfuscated code as highly sophisticated decryption functions that process extremely jumbled inputs that turn into malicious code (see the recent analysis of such obfuscators in the latest Malicious Page of the Month, and a couple of posts by other MCRC members). Seems like we are still ahead of the curve…
Posted by Amir Davidi
