Tuesday, October 25, 2011

Book review: Penetration Tester's Open Source Toolkit, Third Edition

This book is a rather ok book for people new to the penetration testing and average for the more experienced ones. The chapters of the book follow the same methodology: Objectives, approach/technologies/tools, case study, hands-on challenge and close with a summary and an end note. This leads to some boring/useless repetition in some chapters.

Chapter 1 is a general introduction to the use of tools, but 29 pages is a bit too much given that it has a lot of filler text (why discuss LiveCD/LiveUSB creation and modification in details ?)

Chapter 2 Reconnaissance is probably the best written chapter of the book. It discusses the theory and the tools used to gather information in a solid way and covers many small and often forgotten details.

Chapter 3 Scanning and enumeration is average. that mostly looked like an average Nmap manual with listings on many pages and man pages copy pasting but still couldn't cover NSE in more than half a page. Oh, and the chapter (and whole book) has no reference to Scapy at all ? that's shameful ;)

Chapter 4 Client-side attacks and human weaknesses is an ok chapter. As expected it introduced to phishing attacks and how to make them more effective. The main discussed tool is with no surprise the Social-Engineering Toolkit. Nothing exceptional.

Chapter 5 Hacking databases services includes some good theory on MS SQL and Oracle RDBMS. Beside Nmap, the discussed tools are mainly Metasploit auxiliary modules.

Chapter 6 Web Server and Web Application testing. This is the worse chapter by a large margin. For such a large topic and a short number of pages (~40), it discusses stack and heap based buffer overflows... Not only this, but rather than a good introduction to HTTP and manual testing with intercepting proxies like ZAP/Webscarab/W3af, it briefly discusses the common web application vulnerabilities in a paragraph or two each and then goes on talking about tools: WAF detection with WAF00F (who's the audience again ?) and automatic scans with Nikto, Grendel and fimap, SQLiX etc... there are also some filler Nmap scans screenshots again.

Chapter 7 Network Devices has some rather ok theory on different networking protocols and use of different tools. Again, there's some Nmap filler...

Chapter 8 Enterprise application testing has good information on enterprise applications, the architecture and technologies used. Beside the Nmap filler that adds nearly nothing new, it discusses the use of tools like sapyto and soapUI.

Chapter 9 Wireless penetration testing covers well both theory and use of tools for wifi technologies. It also discusses briefly the bluethooth technology. Finally, a chapter with no Nmap filler.

Chapter 10 Building penetration test labs should have been moved to the beginning of the book or be a pointed to annexe. it discusses building home labs with virtualization tools, safety, reporting and penetration testing frameworks.

Rating: 3/5

Sunday, October 23, 2011

Library preloading for reverse engineering

  Many times when reversing a dynamically linked executable, we could benefit from knowing when calls to certain functions are made or/and alter its behavior in a faster and more elegant way without modifying the executable.
Library preloading is a great feature that allows us to inject functions from our own libraries in a program and override the duplicated functions.

  Let's take for example Wireshark. 

  ldd is a tool that outputs a program's dynamically linked dependencies, known as shared objects (.so) on *nix systems.
hani@JustD:~$ ldd /usr/bin/wireshark  
    linux-vdso.so.1 =>  (0x00007fff3f7ff000)
    libwiretap.so.1 => /usr/lib/wireshark/libwiretap.so.1 (0x00007f4b095b5000)
    libwireshark.so.1 => /usr/lib/wireshark/libwireshark.so.1 (0x00007f4b060d9000)
    ...
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b03d57000)
    ...
Better yet than replacing a whole library, we could override only one or certain functions.
Let's replace getenv which is a function from stdlib.h that returns the value of an environment variable. We use the same original source code of getenv and only add a printf at the beginning to show us what variable is being looked for.
char *getenv(const char *name)
{
        printf("%s\n",name);
    ...
We then compile it and explicitly specify that we want it to be a shared object.
hani@JustD:~/space$ gcc -shared -fPIC mygetenv.c -o mygetenv.so 
hani@JustD:~/space$ file mygetenv.so
space/mygetenv.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
and finally we use the environnement variable LD_PRELOAD to preload our shared object
hani@JustD:~/space$ LD_PRELOAD=mygetenv.so /usr/bin/wireshark
WIRESHARK_RUN_FROM_BUILD_DIRECTORY
G_DEBUG
G_SLICE
U3_HOST_EXEC_PATH
HOME  
...
That's it! There are many variantes and uses to this technique that would could prove useful in many situations.