06.19.08
Posted in CDVT - Version Tracker, IT, Tools at 12:59 am by Tyler Reguly
Greetings All,
First... I'm definitely not dead... that first month of marriage kept me busier than I'm used to being, but I definitely plan on posting more.
This post is actually rather exciting for me. If you read back through my blog, my iniital posts (and the reason I registered a domain) were because I wanted an easy way to keep track of new versions of software. I happened to register this domain, so I wanted to call it the Computer Defense Version Tracker (CDVT). My plan was to develop a file scheme, where software authors could place a small cdvt file in their root and I would fetch and parse the file, creating an updated list of versions of software. A number of authors were on board with the idea, but it never built much steam.
Having progressed my development skills quite a bit in the past two and half years (or at least I like to think I have), I realized I could write a simple screen scraper to do the work. So here's the "new and improved" CDVT, which I'm currently calling version 0.1. The download consists of two files, cdvt.py and cdvt.xml. The XML file contains references to each piece of software that is being checked. The python does the work. You can provide a couple of inputs when you run the file, and if you provide incorrect input, you'll get this error:
htregz@securitysentience:~/cdvt$ python cdvt.py
CDVT 0.1 by Tyler Reguly (ht@computerdefense.org)
Error: Output Type not provided
Usage: cdvt.py <output type> <output interface>
output type: csv or text
output interface: stdout or file
This should be fairly straight forward, you can generate csv or plain text and either print to the screen or write to a file. The next version will parse proper arguments and allow you to specify a filename. Right now the filename will be either versions.csv or versions.txt (depending on the output type).
Output from the text mode looks like this:
htregz@securitysentience:~/cdvt$ python cdvt.py text stdout
2.4 Kernel: 2.4.36.6
2.6 Kernel: 2.6.25.7
Aircrack-ng: 1.0-rc1
Cain & Abel: 4.9.14
ettercap: NG-0.7.3
Kismet: Kismet-2008-05-R1
Metasploit Release: 3.1 Release
Metasploit SVN Revision: 5533
NetStumbler: Version Info Not Available
Nikto: 2.02
nmap: 4.65
Notepad++: 4.9.2
Pass the Hash: 1.3
PsTools: 2.44
PuTTy: 0.60
Snort: 2.8.2.1
TCPDump: 3.9.8
VMWare Server: 1.0.6
VMWare Workstation: 6.0.4
Wireshark: 1.0.0
Since I do perform screen scraping, it isn't the fastest process in the world, but it isn't overly slow either. When you see the message 'Version Info Not Available', that means that the page that's scraped wasn't available or the regex couldn't match. In the above case, the NetStumbler download page is currently returning a 404 error.
I would love feedback, suggestions of apps to add and anything else. Feel free to email me or leave a comment.
Permalink
Digg this post
04.14.08
Posted in IT, Tools at 8:06 pm by Tyler Reguly
This morning I talked about W3AF beta6 being available. Only now did I finally get time to install it... I wanted to test drive the UI, and it ended up being quite the task to get it installed. Part way through I realized that this would be a someone time consuming process and started documenting everything I had to do. I figured that others will most likely want to play with the UI on Windows XP so I'm going to share my documentation:
Installing w3af with UI on Windows XP with Python 2.5
Download pygoogle
Extract pygoogle
From your extracted directory run 'python setup.py install'
Download fpconst
Extract fpconst
From your extracted directory run 'python setup.py install'
Download SOAPpy
Extract SOAPpy
Edit <extractdir>\SOAPpy\Client.py; move the import __futures__ line to Line 1
Edit <extractdir>\SOAPpy\Types.py; move the import __futures__ line to Line 1
Edit <extractdir>\SOAPpy\Server.py; move the import __futures__ line to Line 1
From your extracted directory run 'python setup.py install'
Download gtk+ runtime
File: gtk2-runtime-2.12.1-2007-10-28-ash.exe
Install
Update gtk+ runtime
File: glib-2.16.2.zip
Extract Files
Copy files from \bin over gtk2-runtime install (default: C:\Program Files\GTK2-Runtime\lib)
Install pyGTK files
PyGTK 2.12.1-2
PyGobject 2.14.1-1
PyCairo 1.4.12-2
Download pyOpenSSL
Current Version: 0.7
Install
Download OpenSSL
Current Version: 0.9.8g Light
Install
Download w3af
Extract to directory
Browse to the w3af folder, create a shortcut to file w3af.
Modify shortcut target -- path\to\python25 path\to\w3af -g
Double Click shortcut
Permalink
Digg this post
03.08.08
Posted in IT, Tools at 1:27 am by Tyler Reguly
I just discovered this today when Komodo Edit said it had an update available... the release notes lead me to OpenKomodo and I eventually stumbled across an ActiveState press release.
ActiveState today announced an updated, open-sourced release of Komodo Edit, the popular and free editor for dynamic languages including Perl, PHP, Python, Ruby, and Tcl, plus support for browser-side code including JavaScript, CSS, HTML, and XML.
Komodo Edit, based on the award-winning Komodo IDE, offers sophisticated support for all major scripting languages, including in-depth autocomplete and calltips, multi-language file support, syntax coloring and syntax checking, Vi emulation, and Emacs key bindings. Komodo Edit is built on the Mozilla code base, and is now licensed under the same terms as Firefox: Mozilla Public License (MPL), GNU General Public License (GPL), and GNU Lesser Public License (LGPL).
This an amazing product, and this is huge news. The plugin system is also great and there are already a few cool plugins available.
Permalink
Digg this post
02.04.08
Posted in IT, Security, Tools at 4:27 am by Tyler Reguly
The other day I posted the Port Scanner Challenge, and a follow-up article declaring a winner.
This lead to a couple of things...
First, Robert E. Lee (who is associated with UnicornScan) started a blog to perform his own independent tests. I encourage everyone to look at the results... but I remind everyone that Robert is tied to UnicornScan and therefore you may have to take some of the results with a grain of salt.
Second, Fabian, of Recurity Labs (Author's of PortBunny), contacted me regarding the results I had seen, specifically the Vista results. They had reproduced the results in their lab, and ended up releases an update to PortBunny. The updated version showed significant improvements. On the Vista host, with default settings, PortBunny scan times were reduced from ~18.3 seconds to ~1.2 seconds, and on a full port scan (1-65535), scan times were reduced from ~642.5 seconds to ~30 seconds. The updated version of PortBunny can be downloaded here.
Additionally, Fabian included an explanation of how packet retransmission works with PortBunny, which I found rather interesting:
PortBunny sends so called packet-batches which consist of a couple of
probes (usually 9) and a trigger-packet. If a trigger-drop is detected
either because a timeout-clock is hit or due to the fact that 3 later
trigger-responses have been received, all probes which did not get
responses are retransmitted. This is done to acknowledge that, when
firing at this rate, the trigger dropped, so its possible that any other
packet of the batch may have dropped as well.
However, retransmission is not done straight away: That wouldn't be too
wise because the response may just be a couple of milliseconds away.
Instead, we just add the port to the back of the list of ports to scan.
As a result, we can wait the maximum amount of time for the response to
still reach us before we resend.
We only assume that a port is filtered if no response is received for
the probe but the trigger-response for the batch the probe was in was
received.
Now, we do this until all ports have results and then we check whether
the total amount of filtered ports is smaller than 30% of the total
number of ports. If this is so, we perform two rounds of rescanning of
the filtered ports.
Lastly, Fabian also included some of the more interesting changes in this updated version of PortBunny:
(1) The Python-UI contained a Bug which drastically decreased
performance on gigabit-ethernet: To query the device-file, a python
FileObject was used and its read-method was called without specifying a
buffer-size. In fast networks (such as gigabit-ethernet) this lead to
the situation were a huge amount of results was delivered to userspace
in a single read. The information was then parsed using a regular
expression which, due to the size of the buffer, took way longer to
complete than the actual scan 
(2) The development-version now discards bad triggers as soon as better
ones are found. This means that ICMP or UDP-triggers as well as
TCP-SYN-triggers which produce TCP-SYN-ACK responses are discarded as
soon as a single closed port is found (in which case we can use this
port for triggering). This increases performance on the one hand (when
ICMP-traffic is limited which is quite frequently the case for
destination-unreachable messages) and accuracy on the other hand because
triggers are preferred by the scanner which are handled just like the
probes so rate-limitations on TCP-SYNs are detected correctly.
(3) Scans were too "bursty" for many setups which included
burst-limitations. Especially when the round-trip-time was small, the
target would feel like it was processing an (almost) never ending burst
of data. We've made some changes to reduce the "burstiness" as you can
see in the Vista example.
(4) TCP-Reno was taken a little to literally: Reno says that the initial
congestion threshold should be close to infinity so that the sender can
find the limitations of the network quickly (and "muscle" itself into
the connection). NMAP chooses 50 as an initial congestion threshold,
PortBunny chose 80000. While 80000 was closer to infinity than 50, it
doesn't seem like a good choice in many environments when using Reno for
port-scanning because the accuracy of the start-phase of the scan is
reduced drastically. NMAP was totally right to choose a lower number so
we've changed that as well.
(5) We've included a new trigger: The TCP-ACK trigger. This works in
many situations where we had to use fallback-triggers such as the
UDP-trigger in the past.
Permalink
Digg this post
01.14.08
Posted in IT, Reviews, Security, Software, Tools at 11:33 pm by Tyler Reguly
The other day I posted raw data comparing nmap, PortBunny and Unicornscan... I thought today I'd provide some of my thoughts on what the data shows us.
In the end I scanned 5 hosts running a variety of operating systems and I think I gave a fairly decent small scale spread and one initial comment I'd like to make is on the scanning of the HP LaserJet 4MV... While not all scanners found all the ports, they were all able to scan it... which I found fairly impressive... especially considering I've crashed it numerous times in the past playing with advanced options in port scanners and packet creation programs.
Now for the anlysis... Was there a winner? At first I didn't think so... but once I created the graph it became fairly evident that there was. Before I declare the winner... let's take a look at what we saw.
Unicornscan
I was fairly impressed with unicornscan the first time it ran... at least from a speed standpoint. That is until I ran nmap and PortBunny. While unicornscan (on a standard scan, default ports) was able to provide consistent speeds... it was clear that on systems with fewer open ports... there was a huge disadvantage in the design of unicornscan... The consistent speeds were still occurring. If we look at my shell box for example (Ubuntu 6.06 PPC on an old 350Mhz iMac), we see that unicornscan took what appears to be a respectable 9.2 seconds. However, nmap took only 1.5 seconds and PortBunny was less than a second at 0.7 seconds.
The full port scan also didn't bode well for unicornscan. On two hosts, the printer and the gateway, it failed to find any open ports... These are both slower systems (the older printer, and a soekris 486 for the gateway) so perhaps they couldn't keep up with the speed of the scan... or perhaps unicornscan was scanning too fast even for itself.
In the end, after seeing the results of nmap and PortBunny I was rather unimpressed with unicornscan.
nmap
I was quite impressed with nmap. During the default scan it tied PortBunny with lowest number of missed ports (of course this is due primarily to the various scanners default port list) and on a full port scan, it was the only scanner to find all open ports. In addition to having the lowest miss port rate... it boasted the fastest times... coming in 17.5 minutes faster than PortBunny on a full port scan, and 16 seconds faster on a default scan.
Additionally when I provided nmap with the '-T5 --max-retries 0' options, it blew PortBunny out of the water... it missed two additional ports over PortBunny on one of the 5 hosts, however the time difference was 5.3 seconds to 74 seconds... nmap was 68.7 seconds faster.
PortBunny
Given all the hype surrounding PortBunny and the fast that is is a "Linux Kernel-Based Port Scanner" (which is supposed to work to it's benefit), I was expecting great things... instead I was seriously disappointed. There wasn't a single scan where PortBunny fully out performed nmap... You have to set nmap to get ridiculous scan speed (scanning "almost too fast") in order for PortBunny to even manage to find more ports than nmap and then it takes ~15 times longer to find those 2 extra ports... Without those "almost too fast" options, nmap still performs faster than PortBunny and with more accuracy.
There was one host where PortBunny was able to outperform nmap, however that was with nmap doing a default scan... when timing options were adjusted, once again PortBunny failed to beat nmap.
Decision
When I started this challenge, I wasn't sure what the outcome would be... the only prediction I had was that unicornscan would be defeated by both PortBunny and nmap. This proved to be true... Between nmap and PortBunny, due to the hype around PortBunny and the claims that I had seen... I really wasn't sure. I expected it to be a close battle between the two... at most a TKO... but in the end it was a straight-up KO and in reality PortBunny was never really a contender.
Winner: nmap
Permalink
Digg this post
01.13.08
Posted in IT, Reviews, Security, Software, Tools at 11:33 pm by Tyler Reguly
There's been quite a bit of mention lately of PortBunny, the new port scanner from Recurity Labs. The scanner is Linux kernel-based and provides a TCP SYN Scan. I figured that I'd put the scanner to the test against nmap and Unicornscan.
Here's the rundown of the setup used:
Software + Version:
Scanning Host:
OS: Ubuntu 7.10
Kernel: 2.6.22-14-generic
Processor: Intel Pentium M 2.13Ghz
RAM: 1GB
Install Process:
- Obtain archive
- Extract archive
- ./configure *No custom config options used for any of the software*
- make
- make install
Tested via Python:
Test Script (Note: I can't get my lines to tab properly, so tab over the four lines following def test):
import time, os
def test ( prog ) :
startTime = time.time()
os.system( prog )
endTime = time.time()
print ( 'Execution Time: %f' % ( endTime - startTime ) )
Targets:
- vista - Vista Home Premium
- shell - Ubuntu 6.06.1 LTS (2.6.15-28-powerpc)
- minibox - OS X 10.4.11
- printer - HP LaserJet 4MV
- gateway - m0n0wall 1.231
Scan Notes:
- PortBunny requires an IP Address, it won't run against hostnames.
- PortBunny doesn't sort the results list.
- Unicornscan missed all ports on printer and gateway when scanning ports 1 - 65535.
- PortBunny missed a port on printer when scanning ports 1 - 65535.
- nmap missed 2 ports on printer when scanning with -T5 --max-retries 0.
Results:
Raw Data, including ports found, after the jump.
Read the rest of this entry »
Permalink
Digg this post
01.10.08
Posted in IT, Security, Tools at 12:40 pm by Tyler Reguly
This is actually pretty cool... It's a new tool (Web-based) that came across the Web Application Security Consortium mailing list. Let's take a look at the tool in action first, example with ComputerDefense.org.
Showing records 1 - 13 out of 13 for www.computerdefense.org (82.165.158.149).
| capri-beauty.com |
computerdefense.org |
| hometownssm.com |
hometowntoronto.com |
| htregz.com |
korahgrads.com |
| numerophobe.com |
pythongod.com |
| reguly.org |
securitybloggers.net |
| spammailbag.com |
themoviegeeks.net |
| topsykrett.com |
Those are indeed the domains I own, that reside on the same IP as ComputerDefense.org. Currently the database is restricted to .com, .net and .org but it's still fairly impressive. A method of determining vhosts is a great asset to penetration testers and security researchers.
The tool is available from a group called CRUSH. It requires that you validate you aren't a bot via a text / colour based CAPTCHA, however after the first time, you are good to make subsequent requests.
I'm going to have fun playing with this tool, taking a look at certain companies / websites and seeing what other domains they host on the same server...
Permalink
Digg this post
11.18.07
Posted in IT, Tools at 1:12 am by Tyler Reguly
I was attempting to grab a web page via netcat the other day, and my GET / HTTP/1.0<enter><enter> appeared to simply hang. I mentioned this to a colleague who pointed out that netcat only sends line-feed (LF / 0x0A), not carriage-return line-feed (CRLF / 0x0D0A). I did some playing around and it turns out that you can simulate CRLF while using *nix by sending the following Ctrl+V<enter><enter>. Ctrl+V<enter> is translated into CR and then <enter> alone sends the expected LF.
This unfortunately doesn't work in Windows, so I'll pose a question to my readers. Does anyone know of a way to simulate CRLF using netcat in Windows?
Permalink
Digg this post
11.03.07
Posted in IT, Security, Tools at 1:10 am by Tyler Reguly
Previously, I've written about IDA Pro freeware, which at the time was IDA Pro 4.3. It seems that the folks at DataRescue have decided to release a new version. IDA Pro 4.9 is now available as freeware and as they point out, it lacks the functionality of IDA Pro 5.x but it's still a fairly recent version to work with. Anyone interested can grab it from the DataRescue IDA Pro Freeware page. It'll go quite nicely with the new Reverse Engineering Code with IDA Pro book that was recently released by Syngress. Unfortunately, it won't be available in Canada until mid-November (at least via Chapters.ca) and that was who I had ordered it with, so I'll be waiting a little bit still. Either way, happy reversing with IDA Pro 4.9 Freeware.
Permalink
Digg this post
10.05.07
Posted in IT, Tools at 3:43 am by Tyler Reguly
I decided to buy a hosted VPS the other day and I'm still in the process of setting everything up and ironing out the kinks. I finally got around to installing some software, which included silc. For those of you that don't know, silc is like encrypted IRC.
So when you get a VPS they give you root access and it's up to you to configure / lockdown the system however you want. So the first thing I did was create a user account. I created the account htregz (some of you may remember it's what I originally posted under here, and it's a name I generally use)... I setup silc (which involves providing a passphrase so that a keypair can be generated) . It worked without a hitch and I connected to a few of the silc networks I occasionally visit. However, I decided that I'd use ht instead of htregz, so I created a new account, removed the htregz account and connected as ht. Again I went to run silc, so that I could provide a passphrase... however this time errors were generated. I tried a couple of things but nothing was successful, so I removed the ht account and recreated the htregz account. Again with the htregz login I was able to get silc up and running without a hitch. At this point I was intrigued so I created a dummy account with a two letter username (te for test). The te account was created exactly the same as the htregz account.
[root@XXX/]# useradd -G wheel -m -s /bin/bash htregz
[root@XXX /]# passwd htregz
Changing password for user htregz.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[root@XXX /]# useradd -G wheel -m -s /bin/bash te
[root@XXX /]# passwd te
Changing password for user te.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[root@XXX /]#
I logged in as te and once again, I couldn't get silc up and running... the error message was:
[te@XXX ~]$ silc
Could not create public key identifier: Success
Could not create public key identifier: Success
Wrong permissions in your private key file `/home/te/.silc/private_key.prv'!
Trying to change them ... Failed to change permissions for private key file!
Permissions for your private key file must be 0600.
Apparently silc cannot successfully handle two-character usernames.
For those that are wondering about my version of silc, it is:
SILC Client 1.1.2 (Irssi base: 0.8.11+ - SILC base: SILC 1.1.2) (20070704 20070704)
Permalink
Digg this post
« Previous entries