The ELF file format
I recently wrote a tutorial on the ELF format. It's in Dutch, and can be found here:
http://hacking.certifiedsecure.com/showthread.php?63-Introductie-op-het-ELF-binary-format
It deals with the structure inside an ELF file, the use of sections in binaries, and goes to show how one can disssect the /bin/ls binary using the tools readelf and objdump.
DNS cache poisoning
I recently gave a short presentation on DNS and cache poisoning. The slides can be found here. Enjoy.
Pinta seems to be alive
Last year, I wrote a tool called Pinta. It's an AMF debugging utility. One can use it the place calls to AMF (ActionScript Message Format) services, and observe the results. Normally, you'd need to create a Flash/Flex app to send these requests, but this is much quicker and easier for debugging your server-side service.
I didn't bother with the project after placing an initial version on google code, but this week I thought I might pick up development again. It occurred to me that few people writing AMF services will think through the security aspects of their service. You don't make service calls by hand, so it's easy for a developer to assume that only his app will be making calls. Wrong.
At least, that would be nice. As it turns out, the tool (which I've spent only 2 days on developing) is already being recommended for pentesting of AMF services. Which attests to the complete lack of tools, but still is nice 
I'll be picking up development again and adding some fuzzing functionality. If you have any feedback, please leave it here or at the google code project!
Xen benchmark
Contents
Introduction
This post discusses the performance of Linux context switches under the Xen hypervisor. Presence of the Xen hypervisor has an impact on the context switching performance, as is shown by benchmarks. I was interested in these benchmarks since I had the feeling a Xen-enabled machine is in general running slower than a non-Xen machine.
nschaind updated
In my previous post I wrote about my new tool, nschaind (http://code.google.com/p/nschaind). It detects if a querying dns resolver is vulnerable to cache poisoning according to VU#252735. It's now been updated to also include VU#927905, BIND 8 cache poisoning vulnerability. BIND 8 has the same kind of weakness in its PRNG, although it has a different PRNG from BIND 9. Amit Klein discovered this vulnerability after discovering the one in BIND 9. These two vulnerabilities form the basis for Dan Kaminsky's now famous DNS flaw (VU#800113).
Anyway, the tool has been updated to detect weak BIND 8 and 9 resolvers, so go and check it out!
Bind cache poisoning scanner
As a part of my master on computer security, I've written a tool that detects if a certain resolver is vulnerable to cache poisoning according to CVE-2007-2926. This vulnerability report from 2007 describes a bad practice of bind, that wasn't fixed until July 2008, when Dan Kaminsky came out with his famous DNS vulnerability.
It comes down to this: bind versions up to 9.4.1 use a fixed source port for queries. This source port is determined at startup. Furthermore, they employ a bad PRNG for query IDs. This leads to predictability of the next query ID. One can exploit these two vulnerabilities together to send a resolver false DNS information, since all of the packet can be constructed and sent before a real server could: cache poisoning.
I found this whole thing very interesting, and decided that it would be nice to write a tool that could detect if a certain resolver was vulnerable to this vulnerability or not. In order to be vulnerable, a server would have a) the same source port for multiple requests and b) have predictable query IDs. To detect this, I followed the path Amit Klein described in his path: CNAME chaining. The tool acts as a DNS server. When a resolver sends a request for an A or MX record, it answers with a CNAME record within the domain, triggering another query from the resolver. And then, it does that again and again, up to 10 times. In these 10 times, the tool can determine if the source port was the same all the time, and if any of the IDs was predictable. Only when a query ID is even can the tool predict a range of 10 possible next query IDs (again, Amit Klein's approach).
The tool accepts MX requests. This is because most resolvers do not accept queries from outside their own network. To make them query your domain, one of the possible tricks is interact with the website of your target to find and make it send you email. To send you email, the resolver will perform an MX lookup, exposing it's resolver IP to you, and creating a possibility for fingerprinting. If the resolver is open to the world, you can use a tool like fpdns to fingerprint it further.
I used this project to learn C, so don't expect too much of the programming. The source is here, as a Google Code project. Of course, it's intended for legal penetration testing and research only!
A sample of the output:
chris$ sudo ./nschaind -c lab2.6core.net -f masteen.6core.net -m mail Chaining daemon listening on 0.0.0.0:53 ------------------------------ A mail.lab2.6core.net. ? 192.168.1.2:45682,18216 chaining (1) A chain00.lab2.6core.net. ? 192.168.1.2:45682,25421 chaining (2) A chain01.lab2.6core.net. ? 192.168.1.2:45682,33129 chaining (3) A chain02.lab2.6core.net. ? 192.168.1.2:45682,3140 chaining (4) A chain03.lab2.6core.net. ? 192.168.1.2:45682,34338 (p) chaining (5) A chain04.lab2.6core.net. ? 192.168.1.2:45682,41383 chaining (6) A chain05.lab2.6core.net. ? 192.168.1.2:45682,63194 chaining (7) A chain06.lab2.6core.net. ? 192.168.1.2:45682,31597 (p) chaining (8) A chain07.lab2.6core.net. ? 192.168.1.2:45682,64114 chaining (9) A chain08.lab2.6core.net. ? 192.168.1.2:45682,64825 (p) chaining (10) A chain09.lab2.6core.net. ? 192.168.1.2:45682,51181 answering (10) Target 192.168.1.2 correct prediction count: 3, different source ports: 1 TARGET IS VULNERABLE