RaDaJo (RAul, DAvid and JOrge) Security Blog

Assessing and Exploiting Web Applications with the open-source Samurai Web Testing Framework

2009-12-13T08:12:00.005+01:00

This week, December 10, I participated in the first OWASP international conference cellebrated in Spain, and specifically, in Iberia. IBWAS'09, the Iberic Web Application Security Conference, by the Spanish and Portuguese OWASP chapters, promoted the need of (web) application security controls and I predict it will be the conference of reference in upcoming years in the region. It was interesting to start by listening to Bruce Schneier talking about the present and future of the information security industry.

As an active member of the Samurai-WTF project, my presentation described Samurai-WTF main purpose plus its recent additions, available from the official SVN repository. I ended up with a hacking demo to demonstrate the power of integrating multiple attack tools in a single platform for web-app pen-testing exercises:

The Samurai Web Testing Framework (WTF) is an open-source LiveCD focused on web application security testing. It includes an extensive collection of pre-installed and pre-configured top penetration testing and security analysis tools, becoming the perfect environment for assessing and exploiting web applications. The tools categorization guides the analyst through the web-app penetration testing methodology, from reconnaissance, to mapping, discovery and exploitation.

This talk describes the actively developed Samurai WTF distribution, its tool set, including the recently created Samurai WTF Firefox add-ons collection (to convert the browser in the ultimate pentesting tool), the advanced features provided by the integration of multiple attack tools, plus the new tool update capabilities.

If you are interested on the project, start by checking the "Assessing and Exploiting Web Applications with the open-source Samurai Web Testing Framework" presentation, and join the project in sourceforge.net (and the mailing list).

Become a Samurai!

Hacking Challenges: Have Fun Improving Your Skills!

2009-12-12T08:53:00.009+01:00

Last week, December 3, I was presenting an @Night event during the SANS London 2009 conference, focused on hacking challenges and how they can be used to improve your skills and knowledge while having fun:

Hacking and security challenges are a great and effective training tool. They provide a platform to improve everyone's skills by forcing all candidates to devise an offensive or defensive tactic, apply different techniques, and squeeze the available tools to succeed. The acquired knowledge can be later on applied to real-world ventures.

This interactive session will guide the audience through some scenarios associated to penetration testing and hacking challenges published over 2009. Apply your technical skills and knowledge to solve these challenges while having fun!

The interactive session was very fun and people actively participated, and performed really well, to solve a compact version of the "Prison Break" challenge in one hour. This has been the first event where we have announced the birth of a new security company, called Taddong, focused on advanced security services. More details about it in the upcoming weeks...

The presentation is available here: "Hacking Challenges: Have Fun Improving Your Skills!".

During the session, on purpose, the last portion of the challenge remained unsolved, that is... what is the input required to generate the Scylla validation code (you already know it is a hash)?

6189db841f01413a05a53b7135137a17

For those attending the session in London, I recommend you to open the presentation, review the challenge details, and try to figure out how to generate the code without using Google ;), and before reading the official solution.

Have fun! Taddong is coming...

Security Book Review: Chained Exploits

2009-11-02T22:33:00.000+01:00

Chained Exploits: Advanced Hacking Attacks from Start to Finish
Author: A. Whitaker, K. Evans, J. B. Voth
Editorial: Addison-Wesley Professional
Publication date: March 9, 2009
ISBN-10: 032149881X
ISBN-13: 978-0321498816

Summary: A multi-scenario hacking adventure novel focused on combined real-world attacks.

Score: 5/5

Review:
The penetration testing (and criminal) field has focused during the last years on increasing the foothold on compromised systems, proving advanced pivoting and post-exploitation techniques that might help to expand the compromise to other systems or critical resources. This book is a novel that describes these reality by telling hacking stories where multiple techniques, tools and vulnerable input vectors are exploited in order to accomplish a variety of clearly defined attacks and goals.

Each chapter is a well structured story describing multiple attack scenarios. From credit card theft, to insider threat, going through corporate espionage focused on stealing confidential intellectual property, the launch of a DoS attack in a key point in time, the risk and exploitation of inter-corporation network connections, physical access to healthcare records, up to social networking and wireless break-ins.

The book is a modern fictional narrative with technical touches, covering attacks from start-to-finish in elaborated stories (my score evaluates the book from this perspective). However, by reading the book description, you might expect a deeply technical book that will teach you how to perform those attacks, and... it is not.

Every attack story is introduced by setting the stage and the overall attacker approach. Besides that, it is surrounded by a few final defensive tidbits and conclusions, describing countermeasures to mitigate the various attacks covered. This book may act as an excellent eye opener for managers and top level positions (see recommended audience below) in order to understand how small security investments and tweaks can definitely help to increase the overall protection of a target environment substantially.

Unfortunately, from a technical perspective, some of the technical details have not been thoroughly reviewed, such as the output of nmap (order of ports), the unexplained switching of target systems from Vista to XP, the targeting of RDP while not on the port scan (chapter 4) , or the coverage of some tools. Some attacks are a bit outdated, such as the silent winpcap installation to capture traffic from a target box. However, I must admit this book inspired some of the components of a recent "Prison Break" hacking challenge I released this summer (2009).

Specific portions of the book and, overall, the story plot, is well written from a novel perspective, and as particular attacks are progressing, it made me feel the common excitement we get when we are involved in a real penetration test and successfully progressing through the targets, getting the adrenalin going.

This book is highly recommended for people entering in the security field, and for experienced technical security pros in two ways. On the one hand, it's an enjoyable and entertaining novel for a weekend or vacation period. On the other hand, it is a very good reference to give to managers and CxO positions so that they can get a feeling of how real-world attacks look like nowadays and the kind of targeted threats they may face.

UPDATE: Amazon review.

Security Book Review: VMware vSphere and Virtual Infrastructure Security - Securing the Virtual Environment

2009-11-02T22:31:00.000+01:00

"VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment"
Author: Edward L. Haletky
Editorial: Prentice Hall PTR
Publication date: July 2, 2009
ISBN-10: 0137158009
ISBN-13: 978-0137158003

Summary: The reference for securing virtual environments, in particular, VMware-based.

Score: 5/5

Review:
In the first half of this year (2009), I was involved on extending my previous research on virtualization security, and specifically, I focused on securing and hardening VMware ESX environments. This stirred up my interest on this book. To sum up what this book is all about: "I would have loved to have this book handy back by that time, as it would have saved me tons of time" Instead, I had to read and compare multiple VMware security guides from VMware, CIS, NIST, etc, and perform an extensive hands-on research on my own.

The book offers a very solid and broad analysis of multiple security issues on virtual environments, covering not only the technical aspects associated to the virtualization hosts, virtual machines, and virtual data and storage networks, but also management and operational issues, availability concerns, and other common related tasks on newly deployed, or already established, virtualization setups.

The first two chapters focus on security threats and attacks, a basic foundation required for the cross-references available throughout the book, that can be skipped by the on-the-field security readers.

The next three chapters focus on offering best practices and security recommendations for different key components of any virtualization platform, such as the hypervisor, the storage network, and virtual clusters. The next couple of chapters cover most of the security aspects that must be considered on the design, deployment and operation of a virtual environment.

Although all these chapters provide a very good quality security advice, it is not complemented with hands-on examples. I think this could be improved by adding more detailed sections describing step-by-step how to complete the security recommendations exposed, not just what need to be done. However, I understand it is required to cut the size of the book at some point. A good example of how to extend this idea can be observed on chapter 6, where the integration between VMWare ESX and a directory service is covered in depth.

However, both the technical and operational aspects are integrated smoothly, offering a great in-depth overview. Apart from that, the whole recommended list of things to consider in order to get a more secure virtualization infrastructure is summarized in a useful set of boxes called "Security Notes" and spread all throughout the book. These boxes can be easily used as a checklist when deploying or assessing the security of virtual solutions.

My favourite chapters are chapter 8, and specially 9, where virtual machine and virtual networking security is analyzed, respectively. Chapter 9 offers a whole set of networking scenarios and discusses pros and cons to the number of (physical and virtual) network cards and its configuration. A very practical and thorough work!

The book ends up with three special chapters. Chapter 10 covers the new VMware virtual desktop infrastructure (VDI) and the security issues around it. Due to all the client-based attacks nowadays, most probably it is going to be a de-facto standard pretty soon, so getting involved on the virtualization of client systems is a must. Chapter 11 provides a detailed guide to harden VMware ESX and ESXi hosts, a mandatory initial process for every new virtual deployment. Finally, chapter 12 provides a quick and interesting introduction to digital forensics (and data recovery) on virtual enviroments, mainly focused on how to deal with virtual file systems, such as VMFS, VMDKs, and raw disks. A quick recommended read for forensic analysts interested on expanding their skills to virtual victims.

There are a few things I feel will improve the book contents. Unfortunately, due to the publication deadline, its coverage of the latest VMware vSphere virtual architecture is pretty limited, as the author clarifies. Besides that, considering the frequent security updates and patches released by virtualization vendors, I would have liked to find a better coverage of best practices to update the virtual infrastructure itself. Finally, as mentioned previously, about half of the book includes detailed how-to sections describing how to apply the recommended settings, but the other half misses that how-to portion. I understand this may be a limitation to make the book size manageable (it's over 500 pages now).

This book is highly recommended for IT and security architects, involved in the design of new virtual solutions, as well as virtualization administrators and anyone in charge of the maintenance of a virtual infrastructure. From a security perspective, people evaluating, assessing, and suggesting improvements for virtual solutions should read the book in order to have a full overview of all the security threats and possible countermeasures. Overall, the book is a must read for anyone already involved, or planning to get involved, in virtualization. It really helps to acquire a very broad and extensive knowledge of the security considerations that apply to such a complex and modern IT architectures.

UPDATE: Slashdot review, Amazon review.

Samurai Web Testing Framework (WTF) Firefox Add-ons Collection

2009-10-19T08:37:00.003+02:00

On June 2009 Mozilla released the add-ons collections feature on their add-ons web site. As a member and contributor to the SamuraiWTF project, I would like to announce the release of the SamuraiWTF Firefox add-ons collection!

The Samurai Web Testing Framework (WTF) is a LiveCD focused on web application testing. It contains a pre-installed collection of the top web application penetration testing tools, becoming the perfect environment for testing applications.

The goal of this Firefox collection is to include the best add-ons for web application penetration testing and offensive security analysis, to convert your browser in the ultimate pen-testing tool. It is aligned with the Samurai Web Testing Framework (WTK) LiveCD distribution. I plan to keep the collection updated with new web-app pen-testing add-ons, but I would like to carefully evaluate new additions (or replacements) so that the list doesn't grow to limits where it becomes unmanageable. It includes 19 add-ons at this time.

As of today, it seems it is not possible to install all add-ons from a collection with a single click. The current SamuraiWTF add-ons collection can be installed on the latest Firefox version, v3.5, with the exception of the "Add N Edit Cookies" add-on. Although this add-on works in Firefox 3.5.*, it cannot be directly installed. There is a quick hack you can apply to install it on Firefox 3.5 until the official version is updated by its developer:

Go to the "Add N Edit Cookies" add-on webpage with a compatible old Firefox version, or with a different browser like Internet Explorer, and download the add-on (XPI file).
Change the XPI extension on the file to ZIP.
Extract the "install.rdf" file from the ZIP archive.
Edit the "install.rdf" file and replace the following line (maximum version):

        <em:maxversion>3.0.*</em:maxversion>

        <em:maxversion>3.5.*</em:maxversion>

Put (drag & drop) the new "install.rdf" file back into the ZIP archive, and it will automatically replace the old version of the file.
Change back the ZIP extension on the file to XPI.
At this point, you can install the recently modified XPI add-on in Firefox 3.5.

Once you install all the add-ons within the SamuraiWTF collection, one by one, the look and feel of your Firefox browser will notably change. I recommend you to hide the add-ons toolbars visible by default. You can individually enable them at any time, such as when you are going to use each specific add-on:

Go to the "View" menu and select "Toolbars".
Deselect "Access Me Toolbar", "Web Developer Toolbar", and (specially) "HackBar".

Finally, the "DOM Inspector" add-on has been added to the collection as it is a requirement to enable all the capabilities of the "Web Developer" add-on.

Please, take a look at the collection, feel free to share your thoughts/comments (send me an e-mail), vote for this collection if you find it useful, and enjoy it!

Prison Break - Breaking, Entering & Decoding - Challenge Answers & Winners

2009-10-12T09:37:00.003+02:00

The answers and winners for the EH-net "Prison Break (Breaking, Entering & Decoding)" challenge (August 2009) have been published today.

The answers for this challenge were released in scoop to The Informer subscribers a few days ago. In Johnny Long words, "The Informer is a fund raising effort run by Hackers For Charity. It is designed to give subscribers a "backstage pass" to the world of Information Security. For $54 per year, subscribers get early, exclusive access to all sorts of goodies donated by the top names in the INFOSEC world. The industry's most recognized names will post blog entries here before they even post them to their own sites." The EH-Net contribution will be the answers to the Skillz H@ck1ng Challenges a few days before they are revealed on EH-Net.

It is an honor for me to drive this initiative, with the support of Don Donzal (EH-Net) and Ed Skoudis (Challenge Master), and start posting the official answers of this challenge on The Informer.

The “Prison Break – Breaking, Entering & Decoding” challenge winners have been announced on EH-net, and the answers are contained in a single PDF file (27 pages) plus three associated screencasts:

"BTv4 802.1q (VLAN) setup"

BTv4 802.1q (VLAN) setup from siles on Vimeo.
"Metasploit meterpreter Windump/Winpcap sniffer"

Metasploit meterpreter Windump/Winpcap sniffer from siles on Vimeo.
"Metasploit meterpreter built-in sniffer module"

Metasploit meterpreter built-in sniffer module from siles on Vimeo.

Thanks to everybody for participating on the challenge, and to Ed and Don for the opportunity. I hope you enjoyed working on it as much as I enjoyed designing and writing it!

Sqlninja & Metasploit Demo

2009-10-09T17:20:00.006+02:00

Last week I run the "Web App Pen-Testing" SANS webcast to provide a sneak preview of the SEC542 "Web Penetration Testing and Ethical Hacking" course I will be teaching in London later this year. At the end of the webcast I run a Sqlninja & Metasploit demo over the Hacme Bank vulnerable site using the recently released sqlninja patch.

This post includes a screencast of that demo (15:40 minutes):

You can access the archived version of the full SEC542 webcast from the SANS portal. Hope to see some of you, RaDaJo readers, in London!

Sqlninja & Metasploit

2009-09-25T14:59:00.019+02:00

Sqlninja is one of the best open-source tools to automate SQL injection exploitation against MS SQL Server databases. If you combine it with the best open-source network penetration testing framework, Metasploit, you get an extremely powerful web application pen-testing toolkit for total database p0wnage!

This week I have been preparing a sqlninja demo focused on its integration with Metasploit for next week "Web App Pen-Testing" SANS webcast, scheduled for October 1. During the webcast I'll cover a sneak preview of the SEC542 "Web Penetration Testing and Ethical Hacking" course I will be teaching in London later this year, and run a demo using the latest publicly available sqlninja version, 0.2.3-r1, including the quick fix detailed below (0.2.3-r1p).

Sqlninja is a Perl-based tool that can make use of Metasploit capabilities to upload and run a Meterpreter or VNC server payload on the target MS SQL server through SQL injection flaws on the target web application. The integration of these tools accepts both direct and reverse TCP connections to/from the database server and the pen-tester system. It uses the "msfpayload" tool to generate the payload that will be executed on the database server (metxxxxx.exe), and the "msfcli" tool to establish (or wait for) a connection with that payload.

Due to the extensive number of modules available in Metasploit nowadays, the msfcli execution takes around 20 seconds in a BTv4 virtual machine to load the whole Metasploit module tree:

# ./msfconsole -v
Framework Version: 3.3-dev
# ./msfconsole
=[ msf v3.3-dev [core:3.3 api:1.0]
+ -- --=[ 404 exploits - 248 payloads
+ -- --=[ 21 encoders - 8 nops
=[ 188 aux
...

# time /pentest/exploits/framework3/msfcli
[*] Please wait while we load the module tree...
...
real    0m18.568s
user    0m13.402s
sys     0m4.683s
#

As a result, the current sqlninja Metasploit module may fail due to a race condition mainly on reverse mode, and specifically, due to timing issues of when the module initiating the connection(client role) executes versus the module listening for the connection (server role).

The patch released in this post fixes this race condition by adding specific (client & server) timeouts to the bind_tcp and reverse_tcp connections. The timers for the bind case try to ensure that the server (msfpayload) starts before the client (msfcli) tries to establish a connection. The timers for the reverse case try to ensure that the server (msfcli) starts before the client (msfpayload) initiates the reverse connection. The values for the timers are conservative and set a difference of 25 seconds between the server and the client initialization.

Due to the fact the reverse Metasploit payload does not retry the client connection, if the other end is not listening when the connection is initiated, the connection never succeeds and cannot be established. Additionally, I've seen the CPU of the target DB system going up to near 100% (a non-desirable DoS condition during a professional pen-test).

The patch can be applied by renaming the original 0.2.3-r1 "sqlninja" Perl file to "sqlninja.original" and running:

$ patch sqlninja.original -i sqlninja.patch -o sqlninja

The new timers ($client_delay (30 secs) and $server_delay (5 secs)), defined at the beginning of the sqlninja main file, can be changed to accommodate future Metasploit startup delays, or even be converted into sqlninja configuration options within the sqlninja.conf file. The patch changes the sqlninja version to 0.2.3-r1p, to indicate the patch has been applied.

Enjoy it, (sql) ninja pen-testers!

Looking for the right event

2009-08-21T18:12:00.000+02:00

Not so long ago, during an incident investigation, I needed to reconstruct a series of events from several Windows systems. I needed to do so from the system that I was using to conduct the whole investigation which had Linux installed in it. That didn't make things easier because, as you will already know, Windows event logs are binary.

Two Google minutes later, I had downloaded a perl script written by Christophe Monniez that was able to do the work. The script turned out to be quite useful (Thanks Christophe!) but I need more. I had lots of events from several systems that were interrelated and needed to be interpreted to be able to understand the way the attack had been conducted, in order to add only the relevant stuff to the timeline. Going back and forward with such a big amount of events searching for the right one wasn't an option, so I decided to provide me with some search capabilities and add my own perl script to do so. The concept is trivial, I wanted to be able to search for some string with in the event, but I want the output to show the complete event instead of the line that matched the string only. You can do this easily with awk, but I rather use perl. Here is my little script in case it can also be helpful to you.

#!/usr/bin/perl
$/ = "\n\n\n";

die "Error: search string missing." if (@ARGV < 1);

while ($line = <stdin>) {

   if ($ARGV[0] eq "-v") {
       print $line if ($line !~ /$ARGV[1]/i);
   } else {
       print $line if ($line =~ /$ARGV[0]/i);
   }
}

This incident investigation was fairly successful and we had access to one laptop involved in the attack. However the system had been reformated and reinstalled, but some information could be recovered using the usual forensic tools. The event file was partially corrupted and I needed to recover the events that were still available. I rewrote the Christophe's code, that was available under the GPL license, and ended up with the following script that does exactly that.


#!/usr/bin/perl -w 

# Process Microsoft event file fragments.
#
# Copyright (c) Jorge D. Ortiz Fuentes, 2009
# Based on Monniez Christophe's code.
# - Added hability to process a fragmented event files.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
#

use strict;
use Getopt::Std;

#
# Help information
#
sub usage {
    print STDERR "\nUsage:\n\t$0 [-] \n";
    print STDERR "Options:\n";
    print STDERR "\t-d\tDebug information.\n";
    print STDERR "\t-l\tUse localtime instead of GMT.\n";
    print STDERR "\t-u\tPreserve unicode.\n";
    print STDERR "\t-h\tPrint this help and exit.\n";
    print STDERR "\nfile\tThe evt file to be analyzed.\n\n";
    exit 1;
}

#
# Search for the first record inside the file.
# It doesn't require that the signature is DWORD aligned 
#
sub next_signature {
    (my $debug, my $file) = @_;

    my $bytes_read;
    my $signature;
    my $sig_found = 0;

    do {
 $bytes_read = read($file, $signature, 1);
 die("End of file reached.\n") if ($bytes_read <= 0);
 if ($signature eq "L") {     
     $bytes_read = read($file, $signature, 3);
     die("End of file reached. Signature not found.\n")
  if ($bytes_read <= 0);
 }
 $sig_found = 1 if (($signature eq "fLe") && (tell($file) >=8));
    } while ($sig_found == 0);
    # Move the position in the file 8 bytes backwards, to 4 bytes before
    # the signature that is where the length of the record is stored.
    seek ($file, -8, 1);
    if ($debug) {
 print "Record starts in position ", tell($file), "\n";
    }
}


#
# Extract record information.
#
sub process_record {
    (my $debug, my $file, my $length, my $localtime, my $unicode) = @_;

    # Local variables
    my $record;
    my $t_gen;
    my $t_writ;
    my $rest;
    my $rest_reencoded;

    # Process the fixed part of the record (at least 56 bytes and
    # it is in position 4):
    read($file, $record, 52);
    $length -= 56;

    # Extract the data from the structure
    (my $reserved, my $record_nb, my $time_gen, my $time_writ,
     my $event_id, my $event_type, my $nb_strings, my $evt_category,
     my $reserved_flag, my $cl_record, my $string_offset,
     my $SID_leng, my $SID_offset, my $data_len, my $data_offset) =
  unpack "LLLLLSSSSLLLLLL" , $record;
    # The reserved field must be 1699505740 otherwise skip this record
    if ($reserved == 1699505740) {
 # Convert dates into strings
 if ($localtime) {
     $t_gen  = localtime($time_gen) . " localtime";
     $t_writ = localtime($time_writ) . " localtime";
 } else {
     $t_gen  = gmtime($time_gen) . " GMT";
     $t_writ = gmtime($time_writ) . " GMT"; 
 }
 # Print data 
 print "Record number:  $record_nb\n";
 print "Time generated: $t_gen\n";
 print "Time written:   $t_writ\n";
 print "Evt ID: $event_id  Evt type: $event_type Evt category: $evt_category\n";
 if ($debug) {
  print "* Reserved: $reserved\n"; 
  print "* $nb_strings strings\n";
  print "* String offset: $string_offset\n";
  print "* SID Len: $SID_leng SID offset: $SID_offset\n";
  print "* Data len: $data_len Data offset: $data_offset\n";
 }

 # Process the rest of the record: Source program, computer name, SID
 # and other strings
 if (read($file, $rest, $length) < $length) {
  die ("End of file reached while reading strings\n");
 }

 $rest_reencoded = pack "C*" , unpack "U0C*" , $rest;

 # Split into several strings
 my @strings = split(/\0\0/, $rest_reencoded);
 my $str;
 $str = $strings[0];
 # hack to suppress unicode
 $str =~ s/\0//g unless ($unicode);
 print "Program: $str\n";
 $str = $strings[1];
 # hack to suppress unicode
 $str =~ s/\0//g unless ($unicode);
 print "Computer: $str\n";
 my $i=0;
 while ($i < $nb_strings) {
  $str = $strings[$i+2];
  $str =~ s/\0//g unless ($unicode);
  print "String $i: $str\n";
  $i++;
 }
 print "\n\n";
    } else {
 print "Reserved: $reserved\n" if ($debug);
 print STDERR "RECORD REJECTED: reserved value fails to match!\n\n\n";
 # Searching continues from where it is since this is a corrupted record
    }
}


#
# Main program
#

# Variable declarations
my $evt_file = "";
my $record_sig;
my $record;
my $length;
my $dword;
# Option declarations
our ($opt_d, $opt_h, $opt_l, $opt_u);

# Process the command line parameters
getopts('dhlu');

# Debug option
print "\$opt_d:$opt_d\n" if (defined($opt_d));
# Help option
print "\$opt_h:$opt_h\n" if (defined($opt_d) && defined($opt_h));
# Localtime option
print "\$opt_l:$opt_l\n" if (defined($opt_d) && defined($opt_l));
# Unicode option
print "\$opt_u:$opt_u\n" if (defined($opt_d) && defined($opt_u));

# Obtain the file name
$evt_file = shift(@ARGV);
print "Event file: $evt_file\n" if (defined($opt_d) && defined($evt_file));

if ($opt_h) {
    &usage();
}

# Open the selected file in binary mode.
open(FILE, $evt_file) or die "ERR: Couldn't open file $evt_file: $!";
binmode(FILE);

do {
    &next_signature($opt_d, *FILE);

    # The following condition should never be met, because:
    # - A record has been found and the file has been rewinded 8 bytes
    # - Or EOF was reached and next signature ended the program
    die("End of file reached: Incomplete record.\n")
 if (read(FILE, $dword, 4) <= 0);
    # Obtain the length of this record
    $length = unpack "L", $dword;
    # A record should be at least 56 bytes long
    if ($length > 51) {
 # Read the record and process it
 &process_record($opt_d, *FILE, $length, $opt_l, $opt_u);
    } else {
 # Probably corrupted record
 print SDTERR "Record too short found and discarded! (Corrupted?)\n";
 if ($opt_d) {
     print "Record length was: $length\n";
 }
 # skip current signature to avoid infinite loop.
 seek(FILE, 4, 1);
    }
} while (!eof(FILE));
close FILE;

exit(0);

Enjoy!

Ethical Hacker Challenge: Prison Break - Breaking, Entering & Decoding

2009-07-27T09:59:00.003+02:00

DISCLAIMERSince our last post half a year ago, we have not forgotten, RaDaJo readers! No excuses :( It has been very hard for us to find time to publish new posts, as we have been involved in three very large projects, plus a few extra security services, during the first half of the year. We hope one of the projects becomes a relevant step towards the security of embedded devices and service provider infrastructures. It is just the beginning... "That's one small step for a man, a giant leap for mankind." The other two projects have been large, really enjoyable, and interesting penetration tests. Meanwhile, we had to deal with some presentations, training events, collaborations, new discovered vulns, ISC shifts, and small pen-tests. In the background, we have also found time to work out things like the one we present you in this new and long time awaited RaDaJo post...

A few months back, by the time I sent my submission to the "Santa Claus is Hacking to Town" challenge, Ed Skoudis gave me the opportunity to write one of his famous and always interesting security challenges. I couldn't say no ;)

As a result, a new challenge has been published on The Ethical Hacker Network. The challenge is adapted from the Prison Break TV show, and it has two main goals. On the one hand, the offensive one, improve your penetration testing skills, tool set, and force you to solve various real-world scenarios I have found along my pen-testing activities. On the other hand, the defensive one, make you think like an attacker, analyze some of the tools and offensive capabilities available today, and figure out ways to put in place countermeasures to mitigate this type of attacks.

I hope you enjoy thes new "Prison Break - Breaking, Entering & Decoding" security challenge during summer. It is ready right before BlackHat & Defcon, so you can try to solve it after the common depression following these two conferences. Go to the Ethical Hacker Network website, digest the challenge and... participate! (Submit your answer by August 31, 2009)
--
Raul Siles
www.raulsiles.com

Prison Break image obtained from “http://www.shockya.com/news/wp-content/uploads/prison_break_ver4_poster.jpg”.

Penetration Testing Challenge: Santa Claus is Hacking to Town

2009-01-22T00:52:00.002+01:00

This past holidays Ed Skoudis published one of his always interesting, amusing, and educational thematic security challenges at the Ethical Hacker Network: "Santa Claus is Hacking to Town". The last one I participated in was in mid-late 2006, although I was a huge fan of them since 2003. This time the challenge was penetration testing focused, rather than incident handling based, so I decided to play and enjoy it. Honestly, from all the security services I offer, penetration testing has taken an increasingly significant percentage of my time during the last years. There is a clear need in the industry for more pen-testers.

I suggest you to read the challenge wording and try to solve it before reading the official solution and answers. You can get some hints by reading the first paper referenced at the end of this post (Ed told me he published them there on purpose to help people out with the challenge), although it is funniest to solve it from scratch :)

You can find my submission here. I also generated (out of the contest) a second version of the paper that includes the challenge text, my official solution, and an appendix with a simpler and direct solution to the challenge, plus the reasons why it was not included as my final submission. Definitely, I could have been stealthier by providing the "-n" option to all the netcat relay instances in order to disable DNS resolution.

Complementary, my Inguardian's friends recently released two penetration testing papers you might be interested in: "Secrets of America's Top Pentesters" (Ed) and "Vista Wireless Power Tools for the Penetration Tester" (Joshua). I strongly recommend both!
--
Raul Siles
www.raulsiles.com

NMAP Trivia ANSWERS: Mastering Network Mapping and Scanning

2009-01-21T14:54:00.003+01:00

Three weeks ago I published the NMAP Trivia challenge. Thanks to all ISC readers that submitted their responses! A special mention goes to the winning entry from Jason DePriest, an extensive and elaborated submission, available here. Congratulations! The prize (technical book) is on his way! ;)

Jon Kibler provided an in-progress nmap idea for a new features, a scan proxy engine equivalent to the FTP bounce scan to scan through HTTP or SOCKS.

Now... it is time for the answers:

1. What are the default target ports used by the current nmap version (4.76)? How can you change the target ports list? What (nmap) options can be used to speed up scans by reducing the number of target ports and still check (potentially) the most relevant ones? How can you force nmap to check all target ports?

Fyodor performed a thorough port scan research this last summer to identify the most common ports available on the Internet [1]. The current nmap version scans by default the 1000 most popular ports. The popularity of each port is coded inside the nmap-services configuration file (by default under /usr/local/share/nmap).
... unknown 4/tcp 0.000477 rje 5/udp 0.000593 # Remote Job Entry unknown 6/tcp 0.000502 echo 7/tcp 0.004855 echo 7/udp 0.024679 unknown 8/tcp 0.000013 ...

Nmap provides an option for quick scans, "-F". It scans the 100 most popular ports, reducing the default load in one order of magnitude. Additionally, you can decide how many popular ports you want to scan through the "--top-ports N" option, where "N" is the top number of ports.

# ./nmap -F scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:44 GMT Interesting ports on scanme.nmap.org (64.13.134.52): Not shown: 95 filtered ports PORT STATE SERVICE 22/tcp open ssh 25/tcp closed smtp 53/tcp open domain 80/tcp open http 113/tcp closed auth Nmap done: 1 IP address (1 host up) scanned in 4.04 seconds # ./nmap --top-ports 5 scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:44 GMT Interesting ports on scanme.nmap.org (64.13.134.52): PORT STATE SERVICE 21/tcp filtered ftp 22/tcp open ssh 23/tcp filtered telnet 80/tcp open http 443/tcp filtered https Nmap done: 1 IP address (1 host up) scanned in 8.56 seconds
Finally, nmap allows you to define the specific set of ports to scan through the "-p" option, as in "-pT:22,80,443,U:53,69,514". All ports, including port 0, can be scanned by providing the "-p0-" option, meaning from 0 till the end of the range, that is, port 65535. You need to specify if they are TCP or UDP ports, or both ("-sSU").

# nmap -p0- scanme.nmap.org[1] http://insecure.org/presentations/BHDC08/

2. How can you force nmap to scan a specific list of 200 target ports, only relevant to you?

If you don't want to scan the most popular ports, you can tell nmap what particular list of ports to scan by specifying them with the "-p" option, one by one or in ranges, like in "-p 20-23,25,80,443". Because this can be too tedious for long lists of ports, the recommended way is to copy and edit the "nmap-services" file and create a custom version containing your list of interesting ports. The new custom file can be referenced using the "--servicedb" (for individual files) or "--datadir" (for the configuration files directory) options, as in:

# nmap --datadir ./myconfig scanme.nmap.org

If your custom file contains more than 200 target services, then you can use the "--top-ports 200" option again. The specific file and directory search order followed by nmap is detailed on page 370 of the nmap book: http://nmap.org/book/data-files-replacing-data-files.html.

3. What is the default port used by nmap for UDP ping discovery (-PU)? Why? If you don't know it from the top of your head ;), how can you easily identify this port without using other tools (such as a sniffer) or inspecting nmap's source code?

By default, nmap sends an empty UDP packet to port UDP/31338 for the UDP ping discovery method ("-PU"). The reason is that there is a high chance this random high port is closed. This is the preferred state expected by nmap trying to elicit an ICMP port unreachable packet in return and, as a result, identify the existence of a new host. The port number is defined in nmap.h, specifically in the DEFAULT_UDP_PROBE_PORT_SPEC constant. Did you notice it is 31337 plus 1, the elite port (31337 in haxor speech) plus one.

Currently, nmap provides the "--packet-trace" option to gather detailed information about the network traffic and individual packets sent and received during its operations. Effectively, this option acts as a built in sniffer, very useful to get details about what nmap is doing on the backstage.

# nmap -PU --packet-trace scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 10:58 GMT SENT (0.6580s) UDP 192.168.166.166:59676 > 64.13.134.52:31338 ttl=58 id=45958 iplen=28 SENT (1.6560s) UDP 192.168.166.166:59677 > 64.13.134.52:31338 ttl=59 id=46599 iplen=28 Note: Host seems down. If it is really up, but blocking our ping probes, try -PN Nmap done: 1 IP address (0 hosts up) scanned in 2.68 seconds

4. When nmap is run, sometimes it is difficult to know what is going on the backstage. What two (nmap) options allow you to gather detailed but not overwhelming information about nmap's port scanning operations? What other extra (nmap) options are available for ultra detailed information?

The first of the options has been mentioned and used on the previous question, "--packet-trace". It allows to get a tcpdump-like output about packets sent and received. Additionally, nmap provides the "--reason" option to display the reason why a port has been clasiffied on an specific state: open, closed, filtered, etc.

# nmap -F -sSU --reason scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:00 GMT Interesting ports on scanme.nmap.org (64.13.134.52): Not shown: 99 open|filtered ports, 96 filtered ports Reason: 194 no-responses and 1 admin-prohibited PORT STATE SERVICE REASON 22/tcp open ssh syn-ack 25/tcp closed smtp reset 53/tcp open domain syn-ack 80/tcp open http syn-ack 113/tcp closed auth reset Nmap done: 1 IP address (1 host up) scanned in 7.95 seconds # nmap -F -sU --reason scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:02 GMT Interesting ports on scanme.nmap.org (64.13.134.52): Not shown: 99 open|filtered ports Reason: 99 no-responses PORT STATE SERVICE REASON 520/udp filtered route admin-prohibited from 192.168.15.1 Nmap done: 1 IP address (1 host up) scanned in 15.90 seconds
For those interested on gathering as much information as possible about nmap's operations, the "-v" verbosity option, or the "-dN" debugging option are available. These options specify nmap to be verbose (multiple verbosity levels are allowed), or the nmap debug level for troubleshooting purposes, where N can have a value between 1 and 9. Be careful when you use it! Try it and be ready for a Matrix-like output 8-)

# nmap -p80 -sS -v scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:07 GMT Initiating Ping Scan at 11:07 Scanning 64.13.134.52 [2 ports] Completed Ping Scan at 11:07, 0.24s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 11:07 Completed Parallel DNS resolution of 1 host. at 11:07, 0.24s elapsed Initiating SYN Stealth Scan at 11:07 Scanning scanme.nmap.org (64.13.134.52) [1 port] Discovered open port 80/tcp on 64.13.134.52 Completed SYN Stealth Scan at 11:07, 0.26s elapsed (1 total ports) Host scanme.nmap.org (64.13.134.52) appears to be up ... good. Interesting ports on scanme.nmap.org (64.13.134.52): PORT STATE SERVICE 80/tcp open http Read data files from: . Nmap done: 1 IP address (1 host up) scanned in 6.13 seconds Raw packets sent: 3 (112B) | Rcvd: 2 (72B) # nmap -p80 -sS -d1 scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:08 GMT --------------- Timing report --------------- ... --------------------------------------------- Initiating Ping Scan at 11:08 Scanning 64.13.134.52 [2 ports] ... Nmap done: 1 IP address (1 host up) scanned in 0.74 seconds Raw packets sent: 3 (112B) | Rcvd: 2 (72B)

Try it by your own! ;)

5. What are the preferred (nmap) options to run a stealthy TCP port scan? Particularly, try to avoid detection from someone running a sniffer near the person running nmap and focus on the extra actions performed by the tool (assuming the packets required to complete the port scan are not detected)?

Most current network IDS can detect the default packets generated by nmap when port scanning a target. We are assuming here these cannot be detected, so a stealthier scan can be launched by using the "-n" option (not used in any of the Nmap Trivia examples), that is, disable all reverse DNS resolution at the nmap level. Most Unix-based security tools provide this same option for the same purpose.

# nmap -F -n scanme.nmap.org

However, this way you lose the sometimes valuable DNS information. You can use the "--dns-servers" option to indicate the DNS recursive servers to use as DNS proxies when analyzing the target IP address.
More stealthier details on answer number 12.

6. Why port number 49152 is relevant to nmap?

Port 49152 is the first of the ephemeral ports for dynamic usage based on IANA. However, the port assignment depends on the implementation of your tools or operating system. See http://www.iana.org/assignments/port-numbers:
- The Well Known Ports are those from 0 through 1023
- The Registered Ports are those from 1024 through 49151
- The Dynamic and/or Private Ports are those from 49152 through 65535

7. What is the only nmap TCP scan type that classifies the target ports as "unfiltered"? Why? What additional nmap scan type can be used to discern if those ports (previously identified as "unfiltered") are in an open or closed state?

The only nmap scan type that can show a port in the "unfiltered" state is the TCP ACK scan, "-sA" option. The reason is because this scan cannot differentiate between an open and closed port, as a target hosts (if unfiltered) will always reply with a RST packet. This is the standard behaviour for a closed port, and is also standar for an open port for which there is not a previously established connection to map the ACK packet to. Therefore, nmap's ACK scan cannot be considered a port scan, as it cannot differentiate between port states, but a host discovery scan.

The TCP Window scan, "-sW" option, is similar to the TCP ACK scan, but it can differentiate between open and closed ports is some scenarios.

8. When (and it what nmap version) the default state for a non-responsive UDP port was changed on nmap (from "open" to "open|filtered")? Why?

The default state for a non-responsive UDP port was changed (from "open" to "open|filtered") on nmap version v3.70 in 2004. The reason was accurancy, as extensive use of filtering devices by that time made filtered UDP ports always appear as open in previous nmap versions.

9. What is the default scan type used by nmap when none is specified, as in "nmap -T4 scanme.nmap.org"? Is this always the default scan method? If not, what other scan method does nmap default to, under what conditions, and why?

The current nmap version performs a TCP SYN scan ("-sS" option) by default when no scan type is specified. However, this is only the default behavior when nmap is launched as a privileged user (eg. root in Linux). The TCP connect scan, "-sT" option (connect() syscall), is used by default with non-privileged users as these cannot send raw packets (used by the SYN scan) or if there are IPv6 targets.

# ./nmap -PN -p80,81 --packet-trace scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:22 GMT ... SENT (0.3730s) TCP 192.168.166.166:56464 > 64.13.134.52:80 S ttl=50 \ id=8102 iplen=44 seq=1698869517 win=3072 SENT (0.3740s) TCP 192.168.166.166:56464 > 64.13.134.52:81 S ttl=43 \ id=48226 iplen=44 seq=1698869517 win=4096 RCVD (0.6120s) TCP 64.13.134.52:80 > 192.168.166.166:56464 SA ttl=48 \ id=0 iplen=44 seq=2849983456 win=5840 ack=1698869518 RCVD (1.9570s) TCP 64.13.134.52:80 > 192.168.166.166:40972 SA ttl=48 \ id=0 iplen=44 seq=2805666242 win=5840 ack=2103880733 SENT (2.5730s) TCP 192.168.166.166:56465 > 64.13.134.52:81 S ttl=55 \ id=14744 iplen=44 seq=1698935052 win=4096 Interesting ports on scanme.nmap.org (64.13.134.52): PORT STATE SERVICE 80/tcp open http 81/tcp filtered hosts2-ns Nmap done: 1 IP address (1 host up) scanned in 3.79 seconds $ ./nmap -PN -p80,81 --packet-trace scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 11:25 GMT ... CONN (0.1290s) TCP localhost > 64.13.134.52:80 => Operation now in progress CONN (0.1290s) TCP localhost > 64.13.134.52:81 => Operation now in progress CONN (2.3510s) TCP localhost > 64.13.134.52:81 => Operation now in progress Interesting ports on scanme.nmap.org (64.13.134.52): PORT STATE SERVICE 80/tcp open http 81/tcp filtered hosts2-ns Nmap done: 1 IP address (1 host up) scanned in 3.57 seconds

10. What nmap features (can make or) make use of nmap's raw packet capabilities? What nmap features rely on the OS TCP/IP stack instead?

Nmap makes use of the raw packet capabilities by default, "--send-eth" option, as demonstrated in the previous question for some features, such as TCP and UDP port scans launched by privileged users (except for the connect scan and the FTP bounce scan), or fragmentation probes. Other features like the Nmap Scripting Engine and version detection relay on the OS TCP/IP stack.

11. Nmap's performance has been sometimes criticized versus other network scanners. What (nmap) options can you use to convert nmap into a faster, stateless scanner for high performance but less accurate results?

If the congestion controls and packet loss detection algorithms are omitted, a scanner will run faster. Nmap can achieve a similar behaviour as stateless scanners, no code to track and retransmit probes, using the following options:

# ./nmap --min-rate 1000 --max-retries 0 ...

These indicate nmap to send at least 1000 packets per second (if your system or wire can) and disable retransmission of timed-out probes. However, take into account the impact this might have in the accurancy of the results.

# ./nmap -PN -n --min-rate 1000 --max-retries 0 -F scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 12:08 GMT Warning: Giving up on port early because retransmission cap hit. Interesting ports on 64.13.134.52: Not shown: 95 filtered ports PORT STATE SERVICE 22/tcp open ssh 25/tcp closed smtp 53/tcp open domain 80/tcp open http 113/tcp closed auth Nmap done: 1 IP address (1 host up) scanned in 1.06 seconds

12. What relevant nmap feature does not allow an attacker to use the decoy functionality (-D) and might reveal his real IP address?

Apart from the previously mentioned "-n" option to run stealthier scans and avoid IDS detection, there are other related options, such as "--data-length", to change the default empty packet used for some probes, "--ttl" to modify the TTL on the sent packets, timing options ("-T"), "--randomize-hosts" to change the order the target hosts are scanned, or "-D" to launch a decoy scan (simulate the scan is coming from multiple hosts).

Decoys are used in the ping discovery, port scanning, and remote OS detection phases. However, this feature does not apply when DNS queries or service version detection ("-sV" or "-A") are used, being the source IP address disclosed.

13. What are the (nmap) options you can use to identify all the steps followed by nmap to fingerprint and identify the Web server version running on scanme.nmap.org?

# ./nmap -sSV -p80 --version-trace scanme.nmap.org Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-21 12:17 GMT ... SCRIPT ENGINE: Initiating script scanning. SCRIPT ENGINE: Script scanning scanme.nmap.org (64.13.134.52). SCRIPT ENGINE: Initialized 4 rules SCRIPT ENGINE: Matching rules. SCRIPT ENGINE: Running scripts. SCRIPT ENGINE: Script scanning completed. Scanned at 2009-01-21 12:17:57 GMT for 8s Interesting ports on scanme.nmap.org (64.13.134.52): PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.2.2 ((Fedora)) Final times for host: srtt: 238764 rttvar: 179294 to: 955940 Read from .: nmap-rpc nmap-service-probes nmap-services. Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 8.17 seconds

The "-sSV" option allows you to focus on a TCP scan type (SYN scan in this case, "-sS"), and fingerprint the service ("-sV"). In order to just target the web server (supposing HTTP (TCP/80) is the target port, and not HTTPS (TCP/443)), the "-p80" option must be used.

The "--version-trace" option is similar to the "--packet-trace" option, but instead of dumping the network traffic, it dumps all the actions or steps performed by nmap during the execution of the service fingerprinting modules. Additionally, other debug options ("-dN") can be added to gather further details.

14. As an attacker, what port number would you select to hide a listening service backdoor trying to avoid an accurate detection by nmap's default aggressive fingerprinting tests? Would it be TCP or UDP? Why? What additional (nmap) options do you need to specify as a defender to fingerprint the hidden service backdoor?

If a port in the range of TCP/9100-9107 is selected for a backdoor, due to the fact these are common ports for printer services, nmap won`t fingerprint the service. These ports are excluded by default on the service fingerprinting tests ("-sV") or aggressive scan options ("-A") trying to save the planet, trees and forests specifically, by not making printers dump dozens of pages full of nmap probes and garbage as a result of the stimulous received from the scan.

If you want to enable service fingerprinting on all ports, there are two options. The "--allports" option can be specified, as in "nmap -A --allports", or the nmap-service-probes file can be modified to enable these ports by removing the "Exclude" directive.

15. What is the language used to write NSE scripts, and what two other famous open-source security tools/projects currently use the same language?

Nmap uses the LUA (www.lua.org) programming language. LUA (pronounced LOO-ah) means "Moon" in Portuguese, or "Luna" in Spanish ;) Other famous open-source security tools, like Wireshark and Snort use LUA to extend their capabilities.

16. What Linux/Windows command can you use to identify the list of NSE scripts that belong to the "discovery" category and will execute when this set of scripts is selected with the "--script discovery" nmap option?

By default, NSE scripts are available under the "scripts" directory (however, nmap searched in other locations too: --datadir, $NAMPDIR, etc), with the ".nse" file extension. All NSE scripts belong to one or more categories, define inside the script, and indexed by the scripts/script.db database (if updated through the "--script-updatedb" option).

Therefore a couple of options to search for discovery scripts in Linux are:

# grep discovery scripts/*.nse scripts/ASN.nse:categories = {"discovery", "external"} scripts/HTTP_open_proxy.nse:categories = {"default", "discovery", "external", "intrusive"} scripts/HTTPtrace.nse:categories = {"discovery"} ... # grep discovery scripts/script.db Entry{ category = "discovery", filename = "HTTPtrace.nse" } Entry{ category = "discovery", filename = "rpcinfo.nse" } Entry{ category = "discovery", filename = "SMTPcommands.nse" } ...
You can perform a similar search in Windows using the built-in search capabilities (searching by "A word or phrase in the file" to look inside the directory) or the find or findstr commands (to search within a file or set of files).

17. How can you know the specific arguments accepted by a specific NSE script, such as those accepted by the whois.nse script?

In order to identify the arguments that can be passed through the "--script-args" option to a NSE script, eg. whois.nse, check the documentation or code within the script file. If it is properly documented, search by "-- @args" to go to the arguments documentation section.

Finally, a couple of extra questions for the real nmap-lovers:

How can you get in real-time the open ports discoverd by nmap before the final report is displayed?
What happens when you run nmap in verbose mode on September 1?

That's all folks! Happy nmap discovery and scanning!

NOTE: This challenge has been published on the Internet Storm Center (ISC) diary too.

--
Raul Siles
www.raulsiles.com

Security Book Review: "Nmap Network Scanning"

2008-12-29T12:58:00.007+01:00

"Nmap Network Scanning"
Author: Gordon "Fyodor" Lion
Editorial: Nmap Project
Publication date: January 1, 2009
ISBN-10: 0979958717
ISBN-13: 978-0979958717

Summary: The Art of Network Mapping and Scanning Masterpiece.

Score: 5+/5

Review:
I could summarize this book review by saying this is THE nmap reference book, what in itself would be an obvious conclusion I already expected before reading a single page, just by looking at the author name. Fyodor is the creator of nmap, a tool he has carefully fed and taken care of during all these years, and slightly knowing him from the Honeynet project, I couldn't expect less.

"Nmap Network Scanning" is a masterpiece that teaches the reader the Art of Network Mapping and Scanning, and definitely, one of the best books I've read in years. Honestly, there are only a few minor things regarding network scanning you cannot accomplish with a single tool, the current nmap version. The book takes advantage of it.

The official nmap reference guide is simply included on chapter 15, while the rest of the book steers the reader through the nifty art of network mapping and scanning. It disects the network scanning phases and techniques, describing the different options and tool arguments available throughout practical examples and real-world usage tips, here and there, that will improve all your scanning techniques. This is a never-ending book that took Fyodor 5 years to write, and it clearly spreads his experience testing and analyzing networks. This is specially true in the "Solution" section at the end of some chapters, where real-world scenarios are efficiently solved.

Additionally, the book clearly pinpoints the limitations for the multiple platforms (eg. Windows vs Linux) and scenarios (eg. privileged vs non-privileged user) nmap can run on. Besides that, it summarizes most nmap internals without requiring you to dive deep into the source code, what is a challenge in itself. All this information is complemented with some real challenges you find as a penetration tester today, such as the limitations to spoof Internet traffic from legal ISP, a topic I've been researching about recently.

The most advanced and technical chapters are chapter 7 and 8, detailing the inner workings of the nmap service, application, and OS fingerprinting modules, and chapter 9, providing the NSE knowledge required to read and develop your own nmap scripts.

This is the type of book I recommend you to read in front of your computer, practicing simultaneously. Open a terminal, enable your network connection, and run the latest nmap version as you read throughout the book while testing the different options and examples. You can use multiple target virtual machines to experiment with, or if not available, the scanme.nmap.org site (use with caution). One thing is sure: you will have a lot of fun!

I have been using nmap since 1999, and found the book fits a broader audience, from the novice reader (please, do not get overwhelmed initially by all the available nmap options and scan types), that can learn the principles of the scanning techniques used (the packet flow diagrams on the port scanning chapter are specially helpful), up to the advanced professional, explaining what's behind the scenes of every technique and nmap argument, at the OS and network traffic level. The book applies to most security professionals, from security administrators that need to manage and secure their environments, to penetration testers interested on driving their skills to a new level.

This is the kind of book that feeds your creativity and research motivation. Fyodor, once again, promotes along the book the open-source philosophy, the need to share and contribute to the community, in this case in the form of OS and service fingerprints, NSE scripts, or just reporting nmap bugs.

Some minor things I would have liked to see mentioned for an extra finishing touch, offering my tiny contribution for a future version, are:

A statistical analysis of the most common ICMP types currenty allowed on the field, similar to the study for TCP and UDP ports Fyodor did. On my experience, for example, I find ICMP timestamps allowed much frequently than ICMP netmask requests today.
Extend the analysis of port knocking with the Single Packet Authorization (SPA) concept.
Finally, I would have loved to see specific sections for the new nmap-related tools, such as ndiff (the command line version), or ncat.

Respectfully, once I finished reading the book I feel like Raul "Fyodor" Siles..., you will do too! :)

Fyodor was generous enough to release an extensive portion of the book for free on the official nmap book website. Take a look at it and you won't doubt about getting your own full copy.

UPDATE: Amazon review.

NMAP Trivia: Mastering Network Mapping and Scanning

2008-12-28T10:35:00.005+01:00

Recently the official (and highly recommended) NMAP book, "NMAP Network Scanning" by Fyodor, was published. I will post its review here in the next few days. Meanwhile, I thought it would be very productive to challenge you with a NMAP Trivia. The main goal is providing some entertainment during the holiday season and the early days of 2009, and at the same time, force you to practice and play with the latest stable nmap version, v4.76, trying to increase your technical knowledge, skills, and mastering of the traditional and current features of such an important security tool.

What are the default target ports used by the current nmap version (4.76)? How can you change the target ports list? What (nmap) options can be used to speed up scans by reducing the number of target ports and still check (potentially) the most relevant ones? How can you force nmap to check all target ports?
How can you force nmap to scan a specific list of 200 target ports, only relevant to you?
What is the default port used by nmap for UDP ping discovery (-PU)? Why? If you don't know it from the top of your head ;), how can you easily identify this port without using other tools (such as a sniffer) or inspecting nmap's source code?
When nmap is run, sometimes it is difficult to know what is going on the backstage. What two (nmap) options allow you to gather detailed but not overwhelming information about nmap's port scanning operations? What other extra (nmap) options are available for ultra detailed information?
What are the preferred (nmap) options to run a stealthy TCP port scan? Particularly, try to avoid detection from someone running a sniffer near the person running nmap and focus on the extra actions performed by the tool (assuming the packets required to complete the port scan are not detected)?
Why port number 49152 is relevant to nmap?
What is the only nmap TCP scan type that classifies the target ports as "unfiltered"? Why? What additional nmap scan type can be used to discern if those ports (previously identified as "unfiltered") are in an open or closed state?
When (and it what nmap version) the default state for a non-responsive UDP port was changed on nmap (from "open" to "open|filtered")? Why?
What is the default scan type used by nmap when none is specified, as in "nmap -T4 scanme.nmap.org"? Is this always the default scan method? If not, what other scan method does nmap default to, under what conditions, and why?
What nmap features (can make or) make use of nmap's raw packet capabilities? What nmap features rely on the OS TCP/IP stack instead?
Nmap's performance has been sometimes criticized versus other network scanners. What (nmap) options can you use to convert nmap into a faster, stateless scanner for high performance but less accurate results?
What relevant nmap feature does not allow an attacker to use the decoy functionality (-D) and might reveal his real IP address?
What are the (nmap) options you can use to identify all the steps followed by nmap to fingerprint and identify the Web server version running on scanme.nmap.org?
As an attacker, what port number would you select to hide a listening service backdoor trying to avoid an accurate detection by nmap's default aggressive fingerprinting tests? Would it be TCP or UDP? Why? What additional (nmap) options do you need to specify as a defender to fingerprint the hidden service backdoor?
What is the language used to write NSE scripts, and what two other famous open-source security tools/projects currently use the same language?
What Linux/Windows command can you use to identify the list of NSE scripts that belong to the "discovery" category and will execute when this set of scripts is selected with the "--script discovery" nmap option?
How can you know the specific arguments accepted by a specific NSE script, such as those accepted by the whois.nse script?

Send your answers to radajo@gmail.com using "NMAP Trivia" as the subject by January, 15. The winner will get a copy of one of the latest technical security books I get access to.

NOTE: This challenge has been published on the Internet Storm Center (ISC) diary too.
NOTE: The image above belongs to the 2008 campaign against fire in Madrid, Spain.

Security Book Review: "Voice over IP Security"

2008-12-14T13:46:00.009+01:00

"Voice over IP Security"
Author: Patrick Park
Editorial: Cisco Press
Publication date: September, 2008
ISBN-10: 1587054698
ISBN-13: 978-1587054693

Summary: General VoIP security overview. Best chapters: SBC's and LI.

Score: 4/5

Review:
The book provides a good general overview of VoIP security, covering multiple topics involved on securing a VoIP infrastructure, from network devices to VoIP servers, plus secure VoIP protocols. In my opinion, the best chapters are chapter 8 and 10 & 11, Session Border Controllers (SBC's) and Lawful Interception (LI), respectively; it is difficult to find books covering these topics still today, although these are two of the major areas regarding VoIP security nowadays.

SBC's are the VoIP security element by design and therefore a key device in any VoIP infrastructure. The book covers SBC's types, access and peering, expected SBC functionality and capabilities (such as DoS protection, translation and NAT features, LI, high availability and load balancing, etc) and offers a brief introduction to its architecture design concepts.

Lawful Interception (LI) by law enforcement (LE), or LI by LE :), is one of the main VoIP research topics today, especially when strong security features are added, such as signaling and media encryption, that difficult the interception tasks. The last two chapters cover the fundamentals of LI on VoIP networks (following the Cisco model, as there are three other standards), describing the different elements, fucntions, and interfaces involved. It is a theoretical chapter followed by some practical advice to implement LI, very detailed and Cisco-based.

The book starts with an introductory overview of VoIP, its benefits and drawbacks, and some security concerns. Then it provides another VoIP threat taxonomy, a good generic overview that lacks some VoIP threats and complements (or simply provides another perspective to) the IETF draft and VOIPSA VoIP threat taxonomies. Unfortunately, I have not found yet a classification that consolidates all the different VoIP threats from (IMHO) the right perspective.

Chapter 3 offers an interesting summarized analysis of the main VoIP protocols, how they work, and their main security requirements and features. It covers H.323, SIP, and MGCP; I specially liked the SIP section, with descriptive message captures and flow diagrams. Chapter 5 complements the VoIP protocols with the main network devices in a VoIP environment, their role, and key security requirements. Although chapter 7 extends the security analysis of VoIP protocols, covering authentication and signaling and media encryption, it does not cover the latest key exchange solutions, such as DTLS, ZRTP or MickeyV2, as it is focused mainly on S/MIME.

All these chapters provide a lightweight analysis of VoIP security, not going very much in-depth into any of the topics covered. The book is a good overview reference for the VoIP security novice reader, I guess intended for network and system administrators, law enforcement, or security pros new to VoIP.

VoIP threats, including some attack types and tools, are analyzed on chapter 6. This chapter covers in detail a few VoIP attacks, providing simulation, examples and command line options for widely available attack tools. It allows the reader to see some real attacks in action, although it only shows the tip of the iceberg regarding all the tools and attacks that are possible; please, do not get the feeling that this is all you can do.

Chapter 4 covers cryptography, and in my opinion, it doesn't fit on the book; although crypto is a key aspect to protect VoIP infrastructures, the novice reader can get this info from other sources.

As the book is from Cisco Press, chapter 9 focuses on specific Cisco features and syntax, specially for practical sections that provide configuration details for firewalls, access devices, and the Unified Communication Manager (& Express), formerly CallManager. The info is useful to get an overview of the implementation steps, but do not apply to you if you are using equipment from other vendors.

Overall, it is a generic reference book to start getting involved into the VoIP security world, acquire a general understanding of the main VoIP security threats, target network elements, VoIP protocols, and security solutions. Once again, the SBC and LI sections are my favorites.

UPDATE: Amazon review.

NOTE: I will not publish my reviews on Bookpool anymore due to their hard-to-use interface and review rules.

To Blue, ot not to Blue: That is the Question

2008-12-13T14:23:00.004+01:00

I spent part of last and this year researching about Bluetooth security, and recently I have been promoting the need to focus on securing Bluetooth technologies at a personal and enterprise level. I've presented about it in several private and public events all over the world, such as Meitsec 2008, II Jornadas CCN-CERT, or SANS London 2008.

An event-independent English version of the presentation (requested by multiple attendees) is available here!

The most critical aspect is that Bluetooth devices are being extensively used to exchange private and sensitive information in the form of data and voice, and the control is mainly on the hands of end users. If you do not enable an enterprise (or even personal) security program for these devices and communication channels at the same level you do with the rest of your infrastructure, you will be dealing against Bluetooth-related security incidents soon, especially on targeted attacks. Start by adding Bluetooth detection capabilities, and integrate this technology in your penetration tests and incident handling procedures.

Although it has been tough traveling around with two laptops, plus the USRP, multiple omni and directional antennas, cables, several Bluetooth dongles, plus the victim cellphones and headsets... just to run the demo, it has been a well worth experience! The demonstration focuses on showing the audience the Bluetooth activity around, discovering the undiscoverable (Bluetooth hidden devices), and injecting and eavesdropping audio from a headset The initial threat was published by Spill and Bittau, then popularized by Josh Wright, and in my opinion it is not getting enough attention. A demo is well worth a thousand words! ;)

Something that took my attention in one of the events was the little impact the presentation and demo had on part of the audience, as it seems it didn't increase the awareness and paranoid level about the current threats. It is in our hands (as end users and organizations) to improve the security capabilities we demand from the Bluetooth vendors. Most of the time, I see the audience changing the Bluetooth settings on their phones and PDA's as I move through the material ;)

This time, the security recommendations are not based on expensive or complex solutions, such as the latest and greatest Bluetooth IDS/IPS that costs more than 100K €. You simply need to follow common sense practices and precautions to get a reasonable level of protection (check the last part of the presentation), and understand the major threats and weaknesses, especially on Bluetooth devices with limited capabilities, such as car kits, headsets, keyboard and mouse, etc.

Enjoy it and... Happy Blue Christmas!
--
Raul Siles
www.raulsiles.com

WPA/TKIP ChopChop Attack

2008-11-08T01:21:00.011+01:00

Probably at this point you have heard that "WPA has been cracked" all over the Internet and the Blogosphere. As the specific details will be fully disclosed on PacSec 2008 next week, and in an upcoming whitepaper on the aircrack-ng website (check it during the weekend or early next week), I considered relevant to provide technical details (summarizing facts) about what's going on and clarify some of the FUD out there.

UPDATE: The "Practical attacks against WEP and WPA" whitepaper has been released (08/11/2008 - 21:00 CET). The paper mentions the attack could be run on non-QoS wireless networks, although no extra details are provided.

First of all, you have a technical overview on this post (thanks Erik for the reference), and thanks to Della Lowe and Rick Farina (from AirTight Networks) for the early warning notification, spreading the word to create awareness on the community, and the detailed technical conversation we had about the topic, respectively.

Why is this relevant? Because it is the first cryptographic attack against WPA(2), and TKIP specifically. Previously we only knew about dictionary attacks on WPA or WPA2 pre-shared keys (Personal mode), or RADIUS impersonation attacks in Enterprise mode.

The attack:

This security research has been discovered by Erik Tews (the T on the PTW WEP attack) and Martin Beck, members of the aircrack-ng team.
The new attack only affects the TKIP encryption algorithm used by WPA (and WPA2, optionally).
The attack allows an attacker to decrypt individual 802.11 wireless frames, similarly to the old WEP chopchop attack, as it discloses the keystream (or PRGA), that is, the cryptographic material used to encrypt a single wireless frame.
The attack also allows to inject new frames using the info of the disclosed keystream and other tricks (see below).
The keystream is disclosed by attacking the integrity algorithm (MIC) used in TKIP, called Michael.
TKIP implements specific built-in countermeasures around Michael to avoid frame manipulation, and blocks replay attacks using sequence number enforcement.
The attack takes advantage of the message notification about MIC failures in order to identify valid injected frames, in the same way the WEP chopchop attack used the ACK frames to confirm valid frames.
Frames can only be injected when the wireless multimedia extensions (802.11e or WMM) are used, as these allow to break the sequence enforcement mechanism. The injected (and forged) frame is sent over a different QoS queue. This effectively limits the amount of injected frames that can be sent (around 7).
Some access points, or standards like 802.11n, require WMM. It cannot be disabled. The 802.11n standard does not accept TKIP, but some 11n vendors allow you to enable it.
The attack combines the new chopchop techniques, plus the QoS queue change, to decrypt and inject new frames. This is were the meat of the research and whitepaper is!
The attack only allows to decrypt and inject frames that go from the AP to the client, as the client generates the MIC failures (required to confirm the validity of an injected frame).
The current research allows to decrypt the frame at a rate of about one bit per minute on average, that is the reason why the current attack is effective against small packets, such as ARP, DNS, or TCP SYN packets. However, spending a bigger amount of time it would be possible to decrypt larger packets.
Every time a new valid frame is injected (confirmed by the generation of a MIC failure message), a new bit value is discovered (like in chopchop), but with TKIP, the attack must stand-by for 60 seconds in order not to trigger the Michael countermeasures, what will renew the keys (and invalidate the attack).
The reason why it is being said that it takes 12-15 minutes (or 900 seconds) is because the goal of the sample test is to decrypt two bytes (16 bits) of an IP address (considering the other two bytes are known, subnet portion on a class B) inside an ARP packet.
By looking at the source code of the PoC tool, it checks the IP private address ranges: 192.168, 10.x (10.0), 172.16-31 (172.16).
For those interested on the in-depth technical details (see the source code), there is a new tool that implements the attack, called tkiptun-ng, and it is available on the aircrack-ng SVN repository (current copy, rev.1208).

This new research opens the door to new WPA(2)/TKIP attacks and future enhancements, so it is time to start applying and planning the appropriate security countermeasures to remove or mitigate this and similar future threats.

The countermeasures (for wireless vendors, businesses, and end users):

[users and businesses] Switch to AES and WPA2, as more TKIP attacks are going to come! AES is the best solution (if your equipment supports it, mandatory since 2006 from a WiFi Alliance perspective) as it is more efficient and secure than TKIP.
[vendors] There are a few ideas around to fix the vulnerability from a TKIP perspective:

Rotate keys every two minutes, but this will have a significant performance impact, specially on the devices that do not support AES (with limited hardware capabilities). [1]
Don't send the early warning message notifying about the first MIC failure, what will break the current 802.11i standard.
Activate the MIC countermeasures with a single MIC failure, what will break the standard again, and activate the built-in DoS capabilities within TKIP in non-evil scenarios where a single packet has an invalid MIC. Very risky!

[businesses] If your hardware do not support AES and cannot be easily replaced, complement the security mechanism provided by TKIP encryption with other capabilities, such as detection. This attack generates a significant amount of MIC failure messages that must be detected by your wireless IDS (WIDS).

[1] This reminds me about the old (and almost useless) Dynamic WEP (DWEP) implementations.

Remember, TKIP was a temporary solution to mitigate WEP security issues. It is time to switch to AES, so start planning the migration now!

NOTE: If there is an incorrect statement above, as all the details are not known yet, please let me know in order to clarify or fix it.

Security Book Review: "Google Hacking for Penetration Testers - VOLUME 2"

2008-11-01T11:45:00.008+01:00

"Google Hacking for Penetration Testers - VOLUME 2"
Authors: Johnny Long et. al.
Editorial: Syngress
Publication date: November, 2007
ISBN-10: 1597491764
ISBN-13: 978-1597491761

Summary: New updates and material for the second edition of the Google Hacking masterpiece. Volume 2 is today's reference.

Score: 4/5

Review:
This review mainly focuses on evaluating how valuable is to get a copy of "Google Hacking for Penetration Testers - VOLUME 2" if you already own a copy of the first edition, and the scores rates exactly that. If you don't have neither of them, I strongly encourage you to acquire Volume 2 (see details below), no matter what area of the information security field you work in (and specially if you are a penetration tester), as the contents affect to you in multiple ways. On my day-to-day security consulting practice, I'm still very surprised about how many IT people don't know about these techniques. The book is a masterpiece for information disclosure and mining from public sources, such as (but not only) Google. If I had to evaluate the book on itself, not comparing between editions, it would definitely get a score of 5/5.

The first edition was released in 2005 and opened the world of the Google Hacking techniques to the general public, together with the GHDB. The second edition title is (at least) confusing, as Volume 2 seems to denote it is a complementary book to the first edition. It is not, so I do not recommend you to get the first edition today. Volume 2, or the second edition as it should have been called, has been thoroughly updated (including most of the screenshots) to cover the latest changes and Google applications. I did a major update to the SANS "Power Search with Google" course on the first half of 2006, when some of the new Google functionality (not in the first edition) was already available. The second edition reflects those updates I identified and put back together then, even the tiny ones, such as the maximum search terms, that changed from 10 to 32. Additionally, all the statistical references, covering number of results returned by Google, and main contents have been reviewed and updated to reflect the current state of the art.

Some chapters have been kept from the previous edition (chapters 1 to 3, and chapters 6 to 9, and chapter 12), although they have suffered updates. Others have been moved (such as the old chapter 10, now chapter 4) or redesigned (like the new chapter 5). Besides, there are brand new chapters, like 10 and 11.

I specially like the updates on chapter 5, with the new tools and scripts to query Google and, specially, to parse and process the results, including several Perl and User-Agent tricks. The book, obviously, covers the Google API changes and provides solutions to overcome them, such as Aura. Chapters 6 and 8 include relevant updates to the Google code search engine and new capabilities to locate malware and binaries, plus new techniques to track down login portals and network embedded devices and reports, respectively.

The new chapter 10 is a great reference covering the new Google services from a hacking and "malicious" perspective. It is a required update given the pace Google releases new functionality and information sources, such as the AJAX capabilities and API, the source code search engine, calendar, blogger, and alert services.

The new chapter 11, "Google Hacking Showcase", includes the real-world Google Hacking samples and cases Johnny Long has been presenting in several hacking conferences during the last years. A found having a printed copy of it within the book very valuable, as it is an eye-opener, and it is a fun read. Definitely, if you have not seen Johnny's presentations and talks, I encourage you to access the archives from BlackHat and DefCon and enjoy them.

Finally, chapter 12 (the old chapter 11), covers new techniques and tools from a defensive perspective. The new additions increase the defender arsenal in order to mitigate the old and new threats covered throughout the book.

The influence of multiple authors in this edition is evident, something good for the new contents and material, but not so good for the chapter layout, as some do not follow the original format with a final summary, solutions, links and FAQ. Chapter 10 is a good example of both.

The complementary appendixes from the first edition, not directly relevant to the book topic from my perspective, have been removed. Overall, I feel some of the waffle has been left out, a smart decision (but not always easy) in order to keep the book size reasonable, and make room for the new contents.

I would like to see some of the pages that simply provide long listings from the GHDB moved to an appendix and simply referenced from the associated chapter. It might be useful to have these lists full of query samples on the book, but not just in the middle of a chapter. Another improvement would be to have a book webpage consolidating all the code samples, such as the Blogger submission script, as I'm not sure they are all available on a single website.

To sum up, if you don't have a copy of this book, go and buy Volume 2! (not to mention Johnny's involvement with charities). If you are a professional penetration tester, the new material in this second edition is highly recommended, so update your shelves and start applying the new contents on your daily practice. If you are an infosec pro, not directly involved in Google Hacking tasks, and you already own a copy of the first edition, I think you do not need Volume 2, as you already understand the threat, risks, and what is all this about.

At some point I was almost involved in co-authoring this 2nd edition, but finally it didn't happened. A pity, as definitely, this is one of today's reference books that should be on any infosec shelves.

UPDATE: Amazon review and Bookpool review (1st).

nc2 : Netcat without a couple of annoyances

2008-09-28T20:24:00.005+02:00

Netcat is without doubt one of the most useful tools I know. For years I've used it almost every day, and I still do, in different platforms. Its simplicity is its beauty.

All this time, however, two small details have kept the experience from being absolutely perfect for me. I know there are many rewrites of nc out there nowadays and some versions may not show the behavior I'm about to describe. I'm talking here about code based on that original from Hobbit, both for Linux (v1.10) and for Windows (v1.11).

The first annoyance is (was) in the Linux version. While in the Windows version there is a "-L" option ("listen harder") to make netcat continue listening for new connection attempts after a connection is terminated, there is no such option in the Linux version. You can get around it by launching netcat inside a "while" shell loop, but personally I've always found that to be a pain in the neck, especially when you compare it to simply invoke netcat with a capital "L" instead of lowercase "l", as you do in the Windows version.

The second annoyance is (was) in the Windows version. If you send a file through the client netcat's standard input (e.g. "cat(or type) file.txt ¦ nc target_ip target_port"), in Linux netcat terminates the connection as soon as it is finished sending the file, but in Windows the connection stays active until you tear it down manually, pressing CTRL-C, when you think the transfer is finished. That simply sucks.

Well, I decided to put an end to it. I downloaded the source code, which fortunately is distributed under the GPLv2 license, made a couple of tiny modifications (yes, you may call them quick and dirty hacks, I won't be offended) et voilà, "nc2" was born. Thus, let me make it clear that "nc2" is nothing more than "nc" with two little hacks that eliminate the small annoyances I just described.

I made it for myself, but I decided to publish it in case someone else finds it useful. The zip file (nc2-all-080925.zip, MD5 b26fd6bab7b4a4d89a76fa52dca0f64b, SHA1 b8639b450974a182b67fa637aa9484d111bff534) contains binaries for both platforms ("nc2" and "nc2.exe", respectively), their source code, and a copy of the original source code I derived nc2 from. I downloaded the Windows version from http://joncraton.org/files/nc111nt.zip and for Linux I used the source code of the netcat package that comes with openSUSE 10.3 (yes, you got me, I used NETinVM for this too :-) ).

Finally, and before you ask... I renamed it to "nc2" because this way it is easier for my feeble mind to distinguish when I'm running my own version or some other. For those of you with stronger minds that may feel outraged by this fact, I only have two words: "mv" and "move" ;-).

David Perez.

Security Book Review: "Applied Security Visualization"

2008-09-08T16:24:00.020+02:00

"Applied Security Visualization"
Authors: Raffael Marty
Editorial: Addison-Wesley Professional
Publication date: August, 2008
ISBN-10: 0321510100
ISBN-13: 978-0321510105
http://safari.awprofessional.com/9780321510105

Summary: Definitely Security Visualization is one of the most relevant present and future topics in the security field, and this book is simply THE reference.

Score: 5/5

Review:
When security professionals are dealing with huge amounts of information, and who is not nowadays, correlation and filtering is not the easiest path (and sometimes enough) to discern what is going on. The in-depth analysis of security data and logs is a time consuming exercise, and security visualization (SecViz) extensively helps to focus on the relevant data and reduces the amount of work required to reach to the same conclusions. It is mandatory to add the tools and techniques associated to SecViz to your arsenal, as they are basically taking advantage of the capabilities we have as humans to visualize (and at the same time analyze) data. A clear example is the insider threat and related incidents, where tons of data sources are available.

The best sentence (unfortunately it is not an image ;) that describes SecViz comes from the author:

A picture is worth a thousand log entries.

This is a great book that joins two separate worlds, visualization and information security (infosec). The first chapter is an excellent introduction to the human perception system, its basic principles, and how we analyze, discern, and assimilate information. It is an eye opener for those new to the field. Chapter two is similar from an infosec perspective, and summarizes the main challenges and data sources, such as packet captures, traffic flows, and firewall, IDS/IPS, system, and application logs. The third chapter details different graph properties and chart types, including some open-source and online tools for chart and color selection. Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps. The chapter includes a really useful table to select the right graph based on the purpose of the analysis and the data available.

Then, the previous chapters are smoothly mixed together through a reference methodology that defines what is the problem to solve, and the process to manipulate the available data and generate a (or set of) graph(s) that allow gathering relevant conclusions and answers. The methodology is complemented with an introduction to the standard Unix-based text processing tools (grep, awk, Perl, etc). This methodology is later on applied, with a strong hands-on and how-to spirit, to an extensive set of common security use-cases, such as the perimeter threat, compliance, and the insider threat.

The perimeter chapter offers a deep insight into common attack scenarios, such as worms, DoS or anomaly detection, and operational tasks, like firewall log and ruleset analysis, IDS tuning, or vulnerability assessments. I could never forget how useful were SecViz techniques for anomaly detection on a huge DNS-related incident I was involved about 5 years ago. Thanks to the performance and statistical graphs we had available at that time, we were able to easily identify and solve a very complex and critical security incident.

When I saw this chapter included a wireless section I got really excited due to personal interest. However, I was disappointed as it was just a couple of pages. I think it could be extended to gather a whole set of useful information about complex wireless attacks and client and access points relationships, just by inspecting the different 802.11 management, control, and data frames, and even radio-frequency signals (from a spectrum analyzer). SecViz opens the door to a whole new wireless research area!

The compliance chapter offers a whole methodology to check and manage regulations, control frameworks, auditing, and risk monitoring and management from a visual perspective.

The same applies to the insider threat chapter, as it provides an impressive framework, not only visualization-based, to deal with malicious insiders. It is based on setting up scores for certain behaviors and activities (precursors), generating lists of suspicious candidates, and apply thresholds to accommodate exceptions. It also contains an extensive and directly applicable precursor list at the end to detect suspicious insider activities.

Finally, the book contains a whole chapter, full of references and comparison tables, of open-source and commercial visualization tools and libraries that allow the reader to select the appropriate tool for specific tasks and scenarios.

Although the book hands-on component is very significant, with lots of detailed examples of commands, scripts, and tool options to generate the different graphs, I would have liked to see a thorough usage of the how-to portions, as for some sections there are no specific details about how the graphs have been generated. The book layout makes it the perfect candidate to become a fully interactive technical book. I would suggest to add (for a 2nd edition ;)) practical sections to each chapter where the reader could reproduce all the steps discussed. The book CD is the perfect tool to provide the reader with all the (sanitized) data sets and logs used to generate the graphs, and even allow to include some challenges where the reader needs to analyze the data and answer some questions after generating the appropriate graphs.

To sum up, this book is a mandatory reference for anyone involved in the operational side of infosec, doing intrusion detection, incident handling, forensic analysis, etc, and it can be applied to both, historical analysis and real-time monitoring. Additionally, I found it useful too for auditing and pen-testing professionals, as it provides great tips to generate relevant and efficient graphs for the associated reports.

The accompanying DAVIX Live CD is an excellent resource to start applying the techniques covered throughout the book through open-source tools, SecViz is the Web portal to expand your knowledge on this topic, and AfterGlow is (one of) the most relevant SecViz open-source tools.

UPDATE: Amazon review and Bookpool review (1st)

The Evidence was in your Monthly Cell Phone Bill!... Bluetooth?

2008-09-08T15:57:00.003+02:00

About 11 months ago I posted a kind of security challenge about my cell phone. Sorry about the delay, we have had some readers (Thanks Robin! et al) reminding me and asking "what happened". You deserve the information ;), so finally, here it is!

Answers to the questions raised in the previous blog post:

1) What are the incident response steps you would follow to discern what happened?

On purpose, I'm not going to be too formal following the recommended 6-step Incident Handling process we use and teach in the SANS Security 504 course. The first think to consider is this post itself... eh? You need to go through a final "Lessons Learned" phase, summarize, agree on, and report what happened and how to avoid similar incidents in the future. No matter how busy you are after the incident, and it is better late than never (this post is the best example), you need to do it.

First of all, you need a good detection mechanism, anomaly-based in this case, to detect deviations from the norm. After being aware of the extra charges, I started analyzing in-depth the logs, that is, the cell phone bill details. I focused on the specific date and time the messages were sent. Let's say September 9, between 21:50 and 22:05 (16 minutes). I focused on remembering where I was on that date, what I was doing at that time, and where my cell phone was on that specific moment :) I checked with the people around me at that date and time to double check my memories (team work).

I also tried to identify a pattern in the timing for the message generation during the 16 minutes period without success. There were minutes without messages, minutes with a single message, and minutes with up to five messages. The number of messages per minute in the 16 minutes period were: 1 3 1 3 2 0 1 0 1 5 1 0 1 0 3 2.

Additionally, I inspected the list of sent messages on the cell phone, trying to gather more evidence about the incident. Unfortunately, the list was empty. I checked the phone settings and discovered that the "Save all sent messages" option was off :( Time to change it for future incidents and reflect it into the "Lessons Learned" report. Check your phone at this point, exercising the "Preparation" phase, and be sure you enable as much logging as possible (if the phone memory can support it), so that you can have all the evidence available in future incidents.

I made a call to the telecommunication provider just to notify them about the incident and get them involved in reviewing the case. The person taking care of my call checked the description and classified it as "consecutive SMS messages sent" event. It seems it is something they already have categorized ;) The reason they initially argued was that my cell phone brand (of course, they know my cell phone brand) sometimes present this misbehavior. Amazing! ;) It is the first time I see this and I was tempted to ask: Does it apply to all models from the same manufacturer? (BTW, the brand was one of the major cell players world-wide)

Finally, I was following the incident with the provider, and three months later (one of the reasons that delayed this post), they agreed that it was a misbehavior on their billing system and decided to return my money back. From a technical perspective, unfortunately, it was not due to a new cutting-edge hacking technique ;)

2) What do you think is the most probable security threat/vulnerability/exploit that could explain this type of incident?

Being wireless one of my preferred security topics, the first thing that came to my mind was... Bluetooth!! Perhaps I left the Bluetooth radio enabled by mistake and someone was able to take advantage of it through a bluebugging attack (sometimes referred as bluesnarfing). Sometimes people mix these two types of Bluetooth attacks as they are very similar.

Both anonymous attacks allow an intruder to exploit a vulnerability in the phone firmware and get unauthorized access to the cell phone capabilities and run commands through Bluetooth without notifying or alerting the user, that is, evading any authentication and authorization mechanism:

Bluebugging uses the RFCOMM and Serial Port profile to get control of the phone telecom capabilities through AT commands, that is, the attacker can send make and forward calls, establish data connections, send and receive text messages (SMS) - this is what I thought - and even turn the device into a listening bug. View an example from The Real Hustle.

Bluesnarfing uses the OBEX Object Push profile to get access to the storage capabilities of the device, including the list of contacts, calendar, SMS boxes, files (images, audio, video, etc), IMEI, etc.

Although these are old Bluetooth attacks, I'm sure we still are going to see similar vulnerabilities in new phone models, as it is an implementation bug. If you want to test your device, I suggest you to port and service scan it from a Bluetooth point of view using the psm_scan (1-65535) and rfcomm_scan (1-30) tools.

Another option, as Robin pointed out, could have been someone around me, like the kids (it is always good to have kids around to blame them for it ;)), playing with my phone and impulsively voting through SMS in any of the popular TV programs. It was not the case :)

Finally, do not forget to add all your mobile, and especially Bluetooth devices, to your common detection, incident handling, and computer forensics best practices, as well as to your auditing and pen-testing capabilities. It is time to do so, as these devices are used for really sensitive information and tasks! For this same reason, new cutting-edge Bluetooth sections and labs have been recently added to the SANS "Wireless Ethical Hacking, Penetration Testing, and Defenses" course.

Autoimmunity disorder in Wireless LANs

2008-08-03T20:50:00.009+02:00

It is August 2008, that is, famous US hacking conference time once again! This time BlackHat and Defcon are surrounded by the recent Dan Kaminsky's DNS vulnerability. You can get most of the details from the July's posts on his blog, and on the Metasploit blog. Test your DNS, retest, and patch! I couldn't miss not to blog about it! ;)

But not only of DNS we live, so Airtight Networks, as they did last year too with WEP cloaking, is presenting on Defcon 16 about something they called "Autoimmunity disorder in Wireless LANs". The name comes from biology: autoimmune disorder is a malfunction of the body's immune system that causes the body to attack its own tissues. The vulnerability found in WiFi access points allows an attacker to inject specially crafted packets that influence the AP behavior, creating a kind of self-DoS scenario.

It basically exploits one of the major threats against wireless technologies, Denial of Service (DoS), and becomes a new way of launching a DoS attack. It's not a new cutting-edge flaw, and although it is not a 802.11 design vulnerability, it's an AP implementation vulnerability we need to pay attention. The main reason behind it is the complexity of the 802.11 specification. The original 802.11-1999 is a 528 pages document, the 802.11i-2004 spec adds 190 pages, the new 802.11-2007 spec is 1232 pages in length, and now you need to add 802.11n (MIMO), 802.11e (WMM), 802.11w, 802.11f, 802.11k, 802.11r, as well as all the other upcoming IEEE extensions. Do you see how complex the development of an 802.11 AP or client driver can be?

The vulnerability has been found in all kinds of 802.11 APs, SOHO/home, open source and commercial. Each of them is vulnerable to different stimulus, based on their own 802.11 implementation, but with a similar end result. You need to wait till Defcon to get the details, where different malformed crafted frame samples will be demonstrated. Basically, referring back to biology, they have found different antigens (the crafted packets) for different AP implementations, that is, different substances that can stimulate an immune response.

The following scenario demonstrates the issue: Every time a WiFi client connects to an AP, it follows the authentication and association process, it gets an Association ID (AID), and a new entry is created for that client in the AP's association table. When an AP gets a new 802.11 wireless frame, before forwarding it, it checks that the source address is on the association table and therefore belongs to an existent client. If it is not, the AP takes actions using management frames to notify the client about it, and potentially ensures the client is not allowed any access. What if the source address of the 802.11 frame is the broadcast address (ff:ff:...:ff)? The source address can never be the broadcast address, but if the AP has not been implemented with the proper sanity checks, it may try to ensure that "this client" is not allowed to connect to the network. As a result, it disassociates "this client", that is, all clients (broadcast address). A single frame can trigger autoimmunity disorder and cause the AP to turn hostile against its own clients.

Since these are new malicious frames, not available in the current WIDS signature databases (time to update them!), plus it is the AP the final device originating the DoS over the legitimate clients, and because the attacker needs a lower injection rate to keep the DoS going on (vs. the standard deauthentication or disassociation DoS floods), it might be slightly more difficult to detect these attacks.

The second part of the presentation demonstrates a similar scenario against 802.11w-aware AP's. 802.11w (or MFP, Management Frame Protection) is an upcoming specification that promises to protect (through authentication, encryption and integrity) non-data 802.11 frames. Unfortunately, some time ago we discovered that only a few management frames will be protected by it, leaving other management frames and control frames unprotected, still exposing WiFi networks to DoS attacks. Additionally, autoimmunity disorder opens a new door through which DoS attacks can still be launched due to 802.11w-aware AP's with implementation flaws.

A very brief preview of the presentation can be found here.

Although some people still think deploying a wireless network using WPA or WPA2 is enough to protect the network, you can easily learn this is not the case. Check the latest papers on my wireless security Web page, or the recently updated SANS "Wireless Ethical Hacking, Penetration Testing, and Defenses" course I teach in Europe (a whole new set of contents has been added, including lots of new labs, the new FreeRadius-WPE attacks, wireless fuzzing, attacks against other wireless technologies, new sections covering Bluetooth, and a full update to the complementary SWAT kit). We need to deal with lots of recent wireless threats, complex and advanced rogue devices, 802.11n intrusion detection constraints and new attacks, extended wireless client attacks, new EAP implementation flaws, as well as multiple DoS scenarios, and protect other common wireless technologies, like Bluetooth. In the case of autoimmunity disorder, we definitely need a better secure software development cycle for all 802.11 products, including AP's and client software, such as wireless card drivers.

As complementary information (for those reading till the end of my long posts ;), there is a new free online wireless tool to simulate 802.11n coverage, called 802.11n WLAN Coverage Estimator.

P.S: Thanks to Della Lowe and Pravin Bhagwat, CTO, for bringing up this issue to my attention and for the first hand Defcon preview.

WebDAV with SSL on VISTA

2008-08-03T12:39:00.012+02:00

A while ago I posted an article about WebDAV and SSL on Windows and in the comments some debate was raised about whether Vista supported SSL for WebDAV or not. I hope this article clarifies the question.

In short, Windows Vista DOES support SSL for WebDAV, at least with SP1 and fully patched through Windows Update as of July 26, 2008.

This is the setup I have tested.

Server:
IIS 6.0 running on Windows Server 2003 R2 Ent. Edition. Service Pack 1. English version. Serving www.example.org on port 80 (HTTP) and on port 443 (HTTPS). Server certificate signed by a Windows enterprise root CA ("Example Root CA"). Sharing through WebDAV the following folder: http(s)://www.example.org/shared-webdav. Anonymous access allowed.

Client:
Windows Vista Ultimate Service Pack 1. English version. Certificate of the root CA ("Example Root CA") imported on the local computer Trusted Root Certification Authorities certificate store (this is important, see note below about a "Select Certificate" dialog box).

Command used to map the webdav folder:

net use * https://www.example.org/shared-webdav

Output from that command: (blank lines removed)

---
C:\Users\admin>net use * https://www.example.org/shared-webdav
Drive Z: is now connected to https://www.example.org/shared-webdav.
The command completed successfully.
C:\Users\admin>net use
New connections will be remembered.
Status Local Remote Network
------------------------------------------------------------------
Z: file://www.example.org@ssl/shared-webdav Web Client Network
The command completed successfully.
C:\Users\admin>type z:\hello1.txt
This is file hello1.txt
C:\Users\admin>
---

The network traces showed all traffic going through SSL, as expected.

If, however, the certificate presented by the web server is not signed by a CA trusted by the client, you are presented with a "Select Certificate" dialog box with an empty list of certificates, with only the option "Cancel" available:

As soon as you click Cancel the command fails with the following error message, which, granted, doesn't give much of a clue as to what the real problem is:

---
C:\Users\admin>net use * https://www.example.org/shared-webdav
System error 1223 has occurred.
The operation was canceled by the user.
C:\Users\admin>
---

I hope this helps.

David.

NETinVM: A whole network in a single virtual machine

2008-07-23T09:49:00.009+02:00

Have you ever wished you had a full network lab available to you, full with different networks and systems, where you could try out different tools and techniques whenever you wanted? Maybe to learn about some tool, or to teach or demonstrate some tool to others, or to develop and test a new tool?

Well, we have, and that's why we developed NETinVM.

Consider the following network diagram:

The system labeled "VMWARE" (base.example.net) is a VMware virtual system running in the system labeled "REAL COMPUTER". All other computers depicted in the diagram are User Mode Linux virtual systems running inside the VMWARE system (base.example.net).

Here is the beauty of it: all you need to set up and run this whole network environment is just one real computer running VMware Player (or Workstation or Server) and a copy of the image of the VMWARE system (base.example.net). That image is what we call NETinVM and we have made it publicly available. You can download a copy of NETinVM from http://www.netinvm.org, where you will also find documentation and more details about the tool.

In future posts I'll describe some of the features of NETinVM but if you can't wait you are most welcome to go ahead, download and start using it, and, if you are kind enough, let us know what you think of it via e-mail or blog commment.

We hope you find it useful.

David Perez
Carlos Perez

Security Book Review: "Penetration Tester's - Open Source Toolkit Volume 2"

2008-07-18T17:14:00.006+02:00

"Penetration Tester's - Open Source Toolkit Volume 2"
Authors: Aaron Bayles, et. al.
Editorial: Syngress
Publication date: October 12, 2007
ISBN-10: 1597492132
ISBN-13: 978-1597492133
http://www.elsevierdirect.com/product.jsp?isbn=9781597492133

NOTE: My copy of the book is not authored by Chris Hurley, as other book references on the Internet show, although they have the same ISBN, ¿?.

Summary: A good generic penetration testing reference guide. It includes a wide range of topics, and it is just based on open-source tools.

Score: 4/5

Review:
Penetration testing is definitely a recommended security discipline that helps you find real vulnerabilities and security wholes before the adversary does. This book is a reference guide of the different penetration testing stages and considerations, covering a wide range of technologies and tools. It is just focused on open-source and freely available tools, and do not include any commercial counterparts, like Core Impact or the specialized Web application testing suites. Perhaps this is a good addition for a future edition without the "open-source" term on its title.

The wide scope of the book is one of the reasons why it is not extremely cutting-edge and does not go into the deep details required to master each topic covered. I completely understand it is not possible to create such a book (at least with less than 9999 pages), covering a wide range of topics and including in-depth details. Overall, this book is a good reference guide (in fact one of the few generic references) that will open the door for more advanced knowledge from other books focused on specific areas, such as wireless, Web applications, databases, etc.

Something that can be quickly appreciated is the involvement of multiple authors, as the quality and look and feel of chapters varies. I specially liked the first two chapters, focused on Recon, Enumeration and Scanning. Even if you're an experience pen-tester, I've been doing penetration tests since 2000, you can easily identify the positive SensePost influence on these chapters, and the section contains valuable tips and tricks. At some extent, the "you always have something new to learn" principle applies here.

The book is really good emphasizing best practices and suggestions from a professional pen-testing perspective. When running tests over production environments, there are lots of considerations to need to have in mind, beyond the pure attack techniques. The book does an excellent work on this area, and this is also ratified by the final chapter detailing how to build your own pen-testing lab, including common political and technical issues (I can confirm I've seen lots of them in real world situations). Once you run pen-tests frequently, you need to customize and build your own scripts and tool set. The book also emphasizes this by explaining how to customize the Backtrack CD with your own additions. Definitely, it is a good approach as Backtrack is the reference pen-testing Linux Live CD distribution nowadays.

At first sight, the book structure is a bit strange and it seems there is a lot of repetition on each and every chapter, but once you get used to it, I think is a great approach. Each chapter introduces the goals and scope, then covers the technologies (or pen-testing phases) analyzed, plus the hacking techniques and vulnerabilities involved, and after that it focuses on the tools required to implement the attacks and how to use them, with practical and detailed examples.
It is crucial to differentiate between the techniques and foundations, and the tools, as multiple tools can be used for the same attack, sometimes you do not even need any hacking tool, and new tools will come in the future. I recommend you to master the techniques, the attack principles, and understand the vulnerabilities, and from there, select the best tool on each case. All this structure is complemented with a final case studies subsection on each chapter that exemplifies real-world situations where the techniques and tools can be applied, and how.

The databases, wireless and network devices hacking chapters are good. They provide some insight in the methodology, hacking tools and techniques available for these type of targets. The database hacking focuses on MS SQL Server and Oracle, for sure the most common DB's available out there. The wireless section mainly focuses on WiFi, and Bluetooth is barely mentioned; not enough. And finally, the network devices chapter is a must, as these systems are typically forgotten, although they manage all the network traffic and are a critical IT component of any organization.

In particular, I didn't like too much the Web application chapter. Although it contains lots of tools references, the structure and methodology presented is not very clear, and there is a kind of mix of tools to perform different tasks. Because Web application pen-testing is one of the cutting-edge areas we are dealing with today, I'd have liked to see more quality and in-depth material on it.

From my point of view, the forensic chapter is not related at all with the book and I would completely remove it. There are other very good forensic books available, so I guess it has been included because the tools and infrastructure for basic forensic analysis is available on Backtrack.
Instead, I would have liked to see more details, practical examples, and resources about vulnerable testing environments, such as the DVL (Damn Vulnerable Linux) distro, WebGoat, the Foundstone hackme suites; just to name a few, as well as Capture-the-Flag scenarios and conference references. It would be great to provide an overview on how to build and break into these testing environments using the tools and techniques covered throughout the book.

I strongly recommend this book to people thinking about, or starting on, the penetration testing field. It provides a good and wide overview of topics you need to master, tools available to launch the appropriate attacks, and other pen-testing best practices. As the book is directly aligned with the Backtrack CD, unfortunately version 2 and not the latest version 3 (time for a new edition, including more Bluetooth stuff and adding VoIP hacking ;)), it has a direct and very strong hands-on component, that allows the reader to test the different tools and examples, and makes it very valuable.

UPDATE: Amazon review (1st) and Bookpool review (1st)