Yesterday, I was discussing with Jcran the risk associated with Cross Site Scripting and Redirects. First let me say, I know that URL redirects are an example of XSS. The type of Cross-Site Scripting vulnerability we were discussing is the reflective XSS. To clarify, URL redirects I mean taking a parameter which could be modified by the client, usually in a GET parameter being passed to a page which redirects to the parameter passed in.

Both of these vulnerabilities provide similar types of attack vectors against the client. Jcran took the view that reflective XSS has a greater risk associated with it since it does not require the client to navigate to another page the client may not trust. This is a fair assumption, however having software that does this sort of restriction is not very common in my opinion. If the client is restricting the browser to only pages that they "trust" then reflective XSS in this case is ideal.

However, it is not always the case that the client is performing such restrictions on the browser. If the page is performing some validation which restricts the type of input that can be done, this will limit the attack vectors. For example, if the page does not allow various Javascript related functions. These types of restriction can be bypassed in certain cases but this is not possible or practical due to time frame limitations.

If the attackers were to use a redirect then they would have no limitations on the type of attack that could be performed against the client. They would only need to bypass the software limiting the pages the client can navigate to. If the attacker uses this then they are not restricted in the type of attacks they can perform against the client.

It is interesting that there have not been a larger number of redirect vulnerabilities being disclosed in the security community. This may be due to the fact that some consider XSS to be a "lame" attack which should not be discussed on FD etc etc. I dunno just a few thoughts I have had.

So this November Nikto 2.0 was released. Having used Nikto 1.0 in the past, I decided to give version 2.0 a try and I was very impressed. I was so impressed that I decided that I would contribute to the project.

In mid December, I had sometime to take another look at Nikto 2.0 and dive into some code. One thing that I thought was missing was the lack of XML support. Therefore, I wrote an email to Sullo (Nikto's author) and asked him if he had any plans to add XML support. He told me that if I wanted to add XML support he would apply the patch(es) to Nikto.

One of the main changes for 2.0 was adding HTML template files which separated the HTML formating from the data. I decided that this would be ideal for adding XML, because I would only need to pass the data to the template. So I did some research on building a DTD and built a DTD that I would base the XML on. Once I completed the DTD, I used the HTML templates as a base for building the XML templates. I configured the XML templates to meet the DTD specification. I added the XML format to the nikto_core.plugin so that it would execute the appropriate subroutines.

Next, I added a few subroutine to write the XML in nikto_reports.plugin. I spoke with Jon and he suggested that each item that Nikto finds should have a unique ID. The reason for this is that it would be easy to determine the changes between two scans if everything had a unique ID (think PBNJ heh). I suggested this to Sullo and he added the IDs for everything in Nikto. Then I updated the DTD and XML templates to include the IDs.

Finally, the patches were done and with that, Nikto 2.02 was released.

I am very happy that I could contribute to Nikto. I look forward to using Nikto and the new XML output in the future.

So many people use either Google or tools like goog-mail.py to generate email lists when performing a penetration test. However, goog-mail to be frank, sucks. So I have thought about a smarter way to gather email lists. It occurred to me that if you knew the scheme which a company uses to generate the email addresses, you could simply generate email addresses using a list of names.

Therefore, instead of scraping Google all day, we only need to find a list of names and generate the email address lists ourselves.

Sometimes, we don't know the scheme and therefore, we can attempt a bunch and determine the scheme based on error responses from sending an email.

Here are a few examples 

Basic examples:

$ perl genemailaddrs.pl -d google.com -n names.txt -s 1
bobbytables@google.com
johnsmith@google.com

$ perl genemailaddrs.pl -d google.com -n names.txt -s 3
bobby_tables@google.com
john_smith@google.com

Multiple schemes 

$ perl genemailaddrs.pl -d google.com -n names.txt -s 1,3
bobbytables@google.com
bobby_tables@google.com
johnsmith@google.com
john_smith@google.com


Example with a specific group:
$ perl genemailaddrs.pl -d google.com -n names.txt --group 1
bobbytables@google.com
bobby-tables@google.com
bobby_tables@google.com
bobby.tables@google.com
johnsmith@google.com
john-smith@google.com
john_smith@google.com
john.smith@google.com


Example with a specific type:
$ perl genemailaddrs.pl -d google.com -n names.txt --type 2
bobby-tables@google.com
b-tables@google.com
bobby-tables@google.com
b-table@google.com
john-smith@google.com
j-smith@google.com
john-smith@google.com
j-smith@google.com

The code can be found at http://spl0it.org/files/genemailaddrs.pl

Enjoy!

So I have written a normal DNS BruteForcing tool a few times before. However, I have yet to write an extension Brute Force tool so I wrote one.

http://spl0it.org/files/ext_brutedns.pl

$ perl ext_brutedns.pl -d google.com
google.com      64.233.167.99
google.net       64.233.167.99
google.org       72.14.207.104
google.co.uk   66.249.93.104
google.de        216.239.59.104
google.info      66.249.93.104
google.tv         72.14.207.104
google.biz       72.14.207.104
google.cc        72.14.207.104
google.cn        64.233.161.99
google.name   193.109.220.143
google.us        64.233.161.104
google.la         64.233.161.104

I have also added a module to do this to the next version of Fierce!

I was working on a WhoisLookup module for Fierce tonight. I got it working but there was a minor issue with returning elements that were not defined. If one of the elements of the query was not defined, it croaked with an undefined messaged in AUTOLOAD.

Therefore, I fixed this by replacing this with the return of undef.

http://rt.cpan.org/Ticket/Display.html?id=31839

An here is an example to demonstrate this bug:

#!/usr/bin/perl -w
# 
# Net::Whois::ARIN undefined / undef bug
#
# Joshua D. Abraham < jabra@spl0it.org > 
# Sun Dec 23 23:53:48 EST 2007
#
use strict;
use Net::Whois::ARIN;
my $w = Net::Whois::ARIN->new(
              host    => 'whois.arin.net',
              port    => 43,
              timeout => 30,
          );
my @output = $w->network( gethostbyname('google.com') );
foreach my $net (@output) {
      print "OrgName is " . $net->OrgName  . "\n" if ( defined($net->OrgName));
      print "NetHandle is " . $net->NetHandle . "\n" if ( defined($net->NetHandle));
      print "NetRange is " . $net->NetRange . "\n" if ( defined($net->NetRange));
      print "NameServer is " . $net->NameServer . "\n" if ( defined($net->NameServer));
}