Friday, May 08, 2009

Mount EWF (E01) on Linux

Mounting Expert Witness Format (EWF) / EnCase (E01) using the latest software.

I see that the links I included in my last blog posting are no longer available:
http://stephenventer.blogspot.com/2009/02/mount-ewf-e01-on-linux.html

So here's a quick update on getting EWF mounting capabilities installed on a new Ubuntu install [in this case the 64-bit version of Jaunty Jackalope Ubuntu 9.04]

The libewf software is now available at:
http://sourceforge.net/projects/libewf/

The files I downloaded were:
steve@jj:~/software/EWF$ ls -1
disktype-libewf.patch
EWF_file_format.pdf
libewf-20080501.tar.gz
libewf-beta-20090506.tar.gz
mount_ewf-20080513.py


== Install the required build dependencies
-- the
required Debian packages in Ubuntu are: zlib1g-dev libssl-dev uuid-dev
$ sudo apt-get install zlib1g-dev libssl-dev uuid-dev

== Create Debian (.deb) packages to install
Since the downloads are now standard source code format, I tried to create Debian (.deb) packages using the guidance here: http://www.quietearth.us/articles/2006/08/16/Building-deb-package-from-source

Step 1: Install required dependency packages:
$ sudo apt-get install autotools-dev fakeroot dh-make build-essential

Step 2: Copy the source code tarball to /tmp and extract the contents there steve@jj:~/software/EWF$ cp libewf-beta-20090506.tar.gz /tmp/
steve@jj:~/software/EWF$ cd /tmp/
steve@jj:/tmp$ tar -zxf libewf-beta-20090506.tar.gz
steve@jj:/tmp$ cd libewf-20090506/
steve@jj:/tmp/libewf-20090506$

Step 3a: No need to make the debian control files, since they are already there [in the debian/ sub-folder]

Step 3b: Build the debian package:
steve@jj:/tmp/libewf-20090506$ sudo dpkg-buildpackage -rfakeroot
** this ended with the following output:
signfile libewf_20090506-1.dsc
gpg: WARNING: unsafe ownership on configuration file `/home/steve/.gnupg/gpg.conf'
gpg: skipped "Joachim Metz ": secret key not available
gpg: [stdin]: clearsign failed: secret key not available

dpkg-genchanges >../libewf_20090506-1_amd64.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload (original source is included)
dpkg-buildpackage: warning: Failed to sign .dsc and .changes file
steve@jj:/tmp/libewf-20090506$

Step 3c: List the newly created files:
steve@jj:/tmp/libewf-20090506$ cd ..
steve@jj:/tmp$ ls -ld libewf*
drwxr-xr-x 15 steve steve 4096 2009-05-08 18:41 libewf-20090506
-rw-r--r-- 1 root root 2262 2009-05-08 18:42 libewf_20090506-1_amd64.changes
-rw-r--r-- 1 root root 177340 2009-05-08 18:42 libewf_20090506-1_amd64.deb
-rw-r--r-- 1 root root 511 2009-05-08 18:40 libewf_20090506-1.diff.gz
-rw-r--r-- 1 root root 826 2009-05-08 18:40 libewf_20090506-1.dsc
-rw-r--r-- 1 root root 810174 2009-05-08 18:40 libewf_20090506.orig.tar.gz
-rw-r--r-- 1 steve steve 809523 2009-05-08 18:22 libewf-beta-20090506.tar.gz
-rw-r--r-- 1 root root 222562 2009-05-08 18:42 libewf-dev_20090506-1_amd64.deb
-rw-r--r-- 1 root root 195290 2009-05-08 18:42 libewf-tools_20090506-1_amd64.deb

== Install the newly created .deb packages:
steve@jj:/tmp$ sudo dpkg -i libewf*.deb
Selecting previously deselected package libewf.
(Reading database ... 109479 files and directories currently installed.)
Unpacking libewf (from libewf_20090506-1_amd64.deb) ...
Selecting previously deselected package libewf-dev.
Unpacking libewf-dev (from libewf-dev_20090506-1_amd64.deb) ...
Selecting previously deselected package libewf-tools.
Unpacking libewf-tools (from libewf-tools_20090506-1_amd64.deb) ...
Setting up libewf (20090506-1) ...

Setting up libewf-dev (20090506-1) ...
Setting up libewf-tools (20090506-1) ...
Processing triggers for man-db ...
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
steve@jj:/tmp$


== To use the mount_ewf script, need to install python-fuse:
steve@jj:/tmp$ sudo apt-get install python-fuse


== Create a mount.ewf executable in the /sbin directory and grant it "execute" permissions:
steve@jj:/tmp$ cd
steve@jj:~$ cd software/EWF/
steve@jj:~/software/EWF$ cp mount_ewf-20080513.py /sbin/mount.ewf
cp: cannot create regular file `/sbin/mount.ewf': Permission denied
steve@jj:~/software/EWF$ sudo cp mount_ewf-20080513.py /sbin/mount.ewf
steve@jj:~/software/EWF$ sudo chmod +x /sbin/mount.ewf


== And that's it - ready to go:
steve@jj:~/software/EWF$ mount.ewf
Using libewf-20090506. Tested with libewf-20080501.
Usage:
mount.ewf [options]

Note: This utility allows EWF files to be mounted as a filesystem containing a flat disk image. can be any segment of the EWF file. To be identified, all files need to be in the same directory, have the same root file name, and have the same first character of file extension. Alternatively, multiple filenames can be specified in different locations in the order to be reassembled.


ewf segment filename(s) required.
steve@jj:~/software/EWF$

== Refer to this blog posting for how to mount the EWF files: http://stephenventer.blogspot.com/2009/02/mount-ewf-e01-on-linux.html

Monday, February 09, 2009

Mount EWF (E01) on Linux

Note: also refer to http://stephenventer.blogspot.com/2009/05/mount-ewf-e01-on-linux.html

To mount and view the contents of a forensically acquired hard disc drive or partition image in an Expert Witness Format (EWF) file, i.e. EnCase (E01) format (including compressed and / or split files), on an Ubuntu Linux system, try the following:

Download the libewf packages
These packages were obtained from: https://www.uitwisselplatform.nl/projects/libewf/
The download location is: https://www.uitwisselplatform.nl/frs/?group_id=53&release_id=369

The current ones I used were:
libewf_20080501
libewf-devel_20080501
libewf-tools_20080501 and
mount_ewf-20080513.py

For ease of installation on an Ubuntu system, create Debian package files (.deb) from the Red Hat Package (.rpm) files

This can be done using the Alien package tools on Ubuntu: http://www.howtoforge.com/converting_rpm_to_deb_with_alien

Install the packages

There are various dependencies that are needed for these packages, but the package installer application (dpkg) should help you identify and install those.

The "Install instructions for mount_ewf" are here: https://www.uitwisselplatform.nl/docman/view.php/53/169/readme.txt
Note: the FusePython package in Debian is called "python-fuse", so to install it execute this instruction at a command line: sudo apt-get install python-fuse
Also, in the example below I used the originally downloaded Python script (mount_ewf-20080513.py), but the instructions referenced in the readme.txt above would allow you to use the version copied to the new file: /sbin/mount.ewf

Mount the E01 / EWF contents to the folder
Note: For this example I will created the folder /mnt/e01 and used it as the mount location to view the contents of the image split files (in this case the image was obtained in thirteen files: imaged-drive.E01 throuth imaged-drive.E13 - so the command executed makes a reference to these files using the wildcard character "*", i.e. "imaged-drive.E*").
steve@ubuntu:/media/source/img$ sudo mkdir /mnt/e01
steve@ubuntu:/media/source/img$ sudo /home/steve/software/ewf/mount_ewf-20080513.py imaged-drive.E* /mnt/e01
steve@ubuntu:/media/source/img$ sudo ls -l /mnt/e01
total 38993865
-r--r--r-- 1 root root 40020664320 1970-01-01 01:00 imaged-drive
-r--r--r-- 1 root root 339 1970-01-01 01:00 imaged-drive.txt

View the partition table structure of the newly mounted image file to identify the start sector location of the partition(s) you want to mount
Note: in the example below, the drive image file has only one partition ("imaged-drive1") which starts at sector number 63 - when this is multiplied by the number of bytes per sector of 512, gives you the byte offset value of the start of that partition as: 63*512=32256
steve@ubuntu:/media/source/img$ sudo fdisk -lu /mnt/e01/imaged-drive
You must set cylinders.
You can do this from the extra functions menu.

Disk /mnt/e01/imaged-drive: 0 MB, 0 bytes
240 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xd6b5d6b5

Device Boot Start End Blocks Id System
/mnt/e01/imaged-drive1 * 63 78155279 39077608+ 7 HPFS/NTFS
Partition 1 has different physical/logical endings:
phys=(1023, 239, 63) logical=(5168, 239, 63)


Associate the image file (per the EWF contents) with a loop device using losetup

Note: you should mount this in "read-only" mode (i.e. specify the switch "-r") and per the calculation above, the starting byte offset of this partition, within the drive image, is at: 63*512=32256; If you try this and get the response "Permission denied", check to see you specified "-r"; In this case no loop devices are used, so the first one available for use is "loop0"
steve@ubuntu:/media/source/img$ sudo losetup -o32256 -r /dev/loop0 /mnt/e01/imaged-drive

Mount this loop device to a directory
Note: remember to mount this as "read only", i.e. with option "ro"; The "loop" option will also be needed here to mount this as another loop device on the local system; The next available loop device will automatically be allocated - in this case it was "loop1"; First I created a new directory (/mnt/imaged-drive_c) to use as a mount point location for this step.
$ sudo mkdir /mnt/imaged-drive_c
$ sudo mount /dev/loop0 /mnt/imaged-drive_c/ -o loop,ro
$ df -h
..
/dev/loop1 38G 31G 7.1G 81% /mnt/imaged-drive_c
$ mount
..
/dev/loop1 on /mnt/imaged-drive_c type fuseblk (ro,nosuid,nodev,allow_other,blksize=4096)

The file system (NTFS in this case) is now viewable and available for things like anti virus scans, exploring, etc
$ ls -l /mnt/imaged-drive_c/
total 964001
-rwxrwxrwx 1 root root 0 2004-02-06 13:47 AUTOEXEC.BAT
-rwxrwxrwx 1 root root 176 2005-09-12 11:09 boot.ini
-rwxrwxrwx 1 root root 241 2004-09-30 17:10 BOOTLOG.TXT
...snip...


Note: These steps should work on other Linux distributions, e.g. Fedora, but I have not personally tested it on them yet.

Monday, December 22, 2008

Getting WPA-PSK working on PS3 - YellowDog 6.1

I recently got YDL 6.1 going and was struggling with getting WPA encryption working when connecting to my WiFi router.

I found that it worked for me when I ran the wpa_supplicant command as follows, and left it running:
[root@ps3ydl devices]# wpa_supplicant -dd -Dwext -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf &

Then when I did a restart of networking with "service network restart", now everything stayed connected. So I found that the best way for me to get my wifi connecting correctly at boot time, was by modifying the startup script for the wpa_supplicant service.

When using "ps" to list processes with "wpa" as part of their name, I saw:
[root@ps3ydl devices]# ps -ef |grep wpa
root 16427 1 0 00:33 ? 00:00:00 wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log
root
17223 29728 0 00:35 pts/1 00:00:00 wpa_supplicant -dd -Dwext -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

That first one (process ID 16427 above) was started by the /etc/init.d/wpa_supplicant script (this is effectively the same as running: service wpa_supplicant restart )

While the second process (17223) is clearly the one I executed myself and left running.

But the moment I reboot my machine, I obviously only have a process like that first one (i.e. 16427) and the wireless LAN connection keeps failing to connect properly.

So I modified the "daemon" line in the "start()" section of my /etc/init.d/wpa_supplicant file so that it creates a process with options like the one I ran manually.
This is what the "daemon" line in the "start()" section was BEFORE I changed it:
daemon $prog -c $conf $INTERFACES $DRIVERS -B $OTHER_ARGS

This is what it looks like now:
daemon $prog -Dwext -iwlan0 -c $conf $INTERFACES $DRIVERS -B $OTHER_ARGS

And now when I list the processes I get:
[root@ps3ydl devices]# ps -ef |grep wpa
root 20247 1 0 00:42 ? 00:00:00 wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log

== I also had to set the wpa_supplicant service to start at boot time in the two primary runlevels (3 for normal multi-user mode, without graphics; and 5 for full graphical multi-user mode - this is the init default mode):
-- 1. Created the startup link in runlevel 3 startup rc folder - I chose to start it at number 60 because if I started it too early, it didn't seem to work (the default starting number for networking is 10 - but I changed that to start later too):
[root@ps3ydl ~]# cd /etc/rc3.d/
[root@ps3ydl rc3.d]# ln -s ../init.d/wpa_supplicant S60wpa_supplicant
[root@ps3ydl rc3.d]# ls -l S60wpa_supplicant
lrwxrwxrwx 1 root root 24 Dec 21 16:39 S60wpa_supplicant -> ../init.d/wpa_supplicant
[root@ps3ydl rc3.d]#

-- 2. I moved the startup script for Networking, from starting at number 10, to rather starting later, in this case at number 99:
2008-12-31 Edit: Initially I had set this to start at number 61, i.e. as S61network, but I do get my wireless / wifi networking to start up more reliably if I have it set to start even later during the boot sequence, i.e. rather as S99network
[root@ps3ydl rc3.d]# ls -l S10network
lrwxrwxrwx 1 root root 17 Dec 21 14:00 S10network -> ../init.d/network
[root@ps3ydl rc3.d]# mv S10network S99network
[root@ps3ydl rc3.d]# ls -l S99network
lrwxrwxrwx 1 root root 17 Dec 21 14:00 S99network -> ../init.d/network
[root@ps3ydl rc3.d]#

-- 3. Similarly, for runlevel 5, I created a startup link to get wpa_supplicant started:
[root@ps3ydl rc3.d]# cd ../rc5.d/
[root@ps3ydl rc5.d]# ln -s ../init.d/wpa_supplicant S60wpa_supplicant
[root@ps3ydl rc5.d]# ls -l S60wpa_supplicant
lrwxrwxrwx 1 root root 24 Dec 21 16:40 S60wpa_supplicant -> ../init.d/wpa_supplicant
[root@ps3ydl rc5.d]#

-- 4. And moved the networking to start after the wpa_supplicant service:
[root@ps3ydl rc5.d]# ls -l S10network
lrwxrwxrwx 1 root root 17 Dec 21 14:00 S10network -> ../init.d/network
[root@ps3ydl rc5.d]# mv S10network S99network
[root@ps3ydl rc5.d]# ls -l S99network
lrwxrwxrwx 1 root root 17 Dec 21 14:00 S99network -> ../init.d/network
[root@ps3ydl rc5.d]#

== This is my wpa_supplicant.conf file ("wifi pre shared key" is obviously not my real WPA key):
[root@ps3ydl ~]# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
ssid="BeBox"
scan_ssid=1
key_mgmt=WPA-PSK
#proto=WPA2
#pairwise=TKIP
#group=TKIP
psk="wifi pre shared key"
}

[root@ps3ydl ~]#

== In my ifcfg-eth0 I told the system to not start up the eth0 (ethernet LAN port) at boot time, coz without a cable plugged in it wastes time waiting to receive an IP address to be received, by setting this value / option: ONBOOT=no

== My ifcfg-wlan0 looks like this:
[root@ps3ydl ~]# cat /etc/sysconfig/networking/devices/ifcfg-wlan0
DEVICE=wlan0
BOOTPROTO=dhcp
ESSID=BeBox
HWADDR=00:19:C5:A1:B2:C3
IPADDR=
IPV6ADDR=
IPV6PREFIX=
IPV6_AUTOCONF=yes
ONBOOT=yes
DHCP_HOSTNAME=ps3ydl
DOMAIN=
NETMASK=
TYPE=Wireless
USERCTL=no
IPV6INIT=no
PEERDNS=yes
CHANNEL=1
#MODE=Master
MODE=Auto
RATE=Auto

[root@ps3ydl ~]#

== My keys-wlan0 has the same network password. It doesn't look like i need that IWPRIV line, so that is why it is commented out (there are no spaces in my actual pre shared key value!):
[root@ps3ydl ~]# cat /etc/sysconfig/networking/devices/keys-wlan0
KEY=s:wifi pre shared key
#IWPRIV="set_alg 2"
[root@ps3ydl ~]#

== now when I restart the wpa_supplicant service I see this:
[root@ps3ydl ~]# service wpa_supplicant restart
Stopping wpa_supplicant: [ OK ]
Starting wpa_supplicant: /etc/wpa_supplicant/wpa_supplicant[ OK ]

[root@ps3ydl ~]#

== and then when I restart networking I see this at the command line - not sure why I see all those lines of error messages.. but at least I now get an "OK" and no longer get a "FAILED" for the "Determining IP info..." line:
[root@ps3ydl ~]# service network restart
Shutting down interface wlan0: [ OK ]
Shutting down loopback interface: [
OK ]
Bringing up loopback interface: [
OK ]
Bringing up interface wlan0: Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Operation not supported.
Error for wireless request "Set Frequency" (8B04) :
SET failed on device wlan0 ; Operation not supported.
Error for wireless request "Set Bit Rate" (8B20) :
SET failed on device wlan0 ; Operation not supported.


Determining IP information for wlan0... done.
[
OK ]

== While making the changes above, I was monitoring my system messages file in a different terminal window using: tail -f /var/log/messages

== These are some of the interesting lines of log messages I saw during the execution of "service wpa_supplicant restart":
..
Dec 22 01:14:55 ps3ydl avahi-daemon[4085]: Interface wlan0.IPv4 no longer relevant for mDNS.
..
Dec 22 01:14:55 ps3ydl avahi-daemon[4085]: Withdrawing address record for 192.168.1.69 on wlan0.
Dec 22 01:14:56 ps3ydl avahi-daemon[4085]: New relevant interface wlan0.IPv4 for mDNS.
..
Dec 22 01:14:56 ps3ydl avahi-daemon[4085]: Registering new address record for 192.168.1.69 on wlan0.
Dec 22 01:14:57 ps3ydl kernel: gelic_eurus_sync_cmd_worker: cmd issue failed
..
Dec 22 01:14:58 ps3ydl kernel: gelic_eurus_sync_cmd_worker: cmd issue failed
Dec 22 01:14:58 ps3ydl kernel: gelic_eurus_sync_cmd_worker: cmd issue failed
Dec 22 01:14:59 ps3ydl kernel: gelic_wl_associate_bss: connected


== before doing the network restart, i see the network is down:
[root@ps3ydl ~]# ping google.com
connect: Network is unreachable
[root@ps3ydl ~]#

== And then when doing a network restart with "service network restart" I saw the following interesting system messages:
..
Dec 22 01:25:19 ps3ydl avahi-daemon[4085]: Withdrawing address record for 192.168.1.69 on wlan0.
..
Dec 22 01:25:19 ps3ydl avahi-daemon[4085]: iface.c: interface_mdns_mcast_join() called but no local address available.
Dec 22 01:25:19 ps3ydl avahi-daemon[4085]: Interface wlan0.IPv4 no longer relevant for mDNS.
..
Dec 22 01:25:19 ps3ydl avahi-daemon[4085]: iface.c: interface_mdns_mcast_join() called but no local address available.
..
Dec 22 01:25:24 ps3ydl kernel: gelic_wl_assoc_worker: no bss matched. association failed
Dec 22 01:25:24 ps3ydl kernel: gelic_wl_assoc_worker: no bss matched. association failed
Dec 22 01:25:24 ps3ydl kernel: gelic_wl_associate_bss: connected
Dec 22 01:25:25 ps3ydl dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
Dec 22 01:25:25 ps3ydl dhclient: DHCPACK from 192.168.1.254
Dec 22 01:25:25 ps3ydl avahi-daemon[4085]: New relevant interface wlan0.IPv4 for mDNS.
..
Dec 22 01:25:25 ps3ydl avahi-daemon[4085]: Registering new address record for 192.168.1.69 on wlan0.
Dec 22 01:25:25 ps3ydl NET[427]: /sbin/dhclient-script : updated /etc/resolv.conf
Dec 22 01:25:25 ps3ydl
dhclient: bound to 192.168.1.69 -- renewal in 39187 seconds.

== and finally when I ping google I get a response.. confirming my wifi network is up and working:
[root@ps3ydl ~]# ping google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=1 ttl=243 time=113 ms


P.S. I originally started adding this as a comment to the following blog post, but decided to publish it here too, with additional details. This one may be helpful in providing you with further background or suggestions if you are having troubles like I was having: http://dachaac.blogspot.com/2007/08/guide-to-get-wpa-psk-working-on-ps3-ydl.html

Thursday, March 29, 2007

Using [Alt]-[Prnt Scrn]

Using [Alt]+[Prnt Scrn] to capture or copy & paste an active window instead of the whole screen

In case anyone has not yet learnt this nifty little trick within MS Windows..

I find it very useful in the documentation I create, or for adding images to things like emails, etc. It makes referring to things so much easier when a picture of only the most relevant window is what is needed. A picture of the whole desktop can distract from what you are specifically trying to point out.. or for various other reasons.

Normally to capture a copy of your whole desktop screen, press the [Prnt Scrn] button and then in whatever application you want to paste that image, like MS Word for instance, simply use:

Edit -> Paste

or use the short-cut key sequence on your keyboard:

[Ctrl]+[V]

So now all you do to capture only the currently highlighted / active window (instead of the whole desktop) is:

[Alt]+[Prnt Scrn]

and in the target word / email / whatever app:

Edit -> Paste

or use the short-cut key sequence on your keyboard:

[Ctrl]+[V]

Voila.

Wednesday, July 19, 2006

Public DNS & Network record queries

One of the first steps in a security review conducted via the public Internet networks, is to gather the information available publicly about the target of the test.

You might also want to query these records to confirm that the information that needs to be publicised about a network is in fact publicly available, or being publicised correctly.

This information is freely available since it is necessary for devices to be able to resolve IP address details and plot the routes to get to the servers as part of normal communications via the Internet.

There are many places where you can get the information, but I like to make use of these two services:

Here are some examples of the outputs obtained from them. I will pick on google.com again for my examples:

http://nwtools.com

  • There are a number of individual utilities available (e.g. Ping, Lookup, DNS Records, Network Lookup, etc), but they also have a handy one which executes them all at once to give you a nice complete output to work with - they call it Express. The example below is what resulted upon submitting this request for "google.com":

    http://nwtools.com/default.asp?prog=express&host=google.com

IP address: 64.233.167.99
Host name: google.com

TraceRoute to 64.233.167.99 [google.com]
Hop (ms) (ms) (ms) IP Address Host name
1 0 0 0 66.98.244.1 gphou-66-98-244-1.ev1.net
2 0 0 0 66.98.241.16 gphou-66-98-241-16.ev1.net
3 0 0 0 66.98.240.14 gphou-66-98-240-14.ev1.net
4 1 1 1 129.250.11.141 ge-1-3-0.r02.hstntx01.us.bb.gin.ntt.net
5 9 7 7 129.250.5.30 as-0.r20.dllstx09.us.bb.gin.ntt.net
6 8 7 6 193.251.241.189 so-0-1-0-0.dalcr2.dallas.opentransit.net
7 32 32 30 193.251.128.114 po0-0.chicr2.chicago.opentransit.net
8 29 29 27 193.251.249.30 -
9 27 29 29 66.249.95.253 -
10 29 27 27 66.249.95.247 -
11 30 29 30 66.249.94.133 -
12 41 35 37 64.233.175.42 -
13 29 29 30 64.233.167.99 -

Trace complete

Xwhois query for google.com...
Results returned from whois.markmonitor.com:

MarkMonitor.com - The Leader in Corporate Domain Management
----------------------------------------------------------
For Global Domain Consolidation, Research & Intelligence,
and Enterprise DNS, go to: www.markmonitor.com
----------------------------------------------------------

The Data in MarkMonitor.com's WHOIS database is provided by MarkMonitor.com
for information purposes, and to assist persons in obtaining information
about or related to a domain name registration record. MarkMonitor.com
does not guarantee its accuracy. By submitting a WHOIS query, you agree
that you will use this Data only for lawful purposes and that, under no
circumstances will you use this Data to: (1) allow, enable, or otherwise
support the transmission of mass unsolicited, commercial advertising or
solicitations via e-mail (spam); or (2) enable high volume, automated,
electronic processes that apply to MarkMonitor.com (or its systems).
MarkMonitor.com reserves the right to modify these terms at any time.
By submitting this query, you agree to abide by this policy.

Registrant:
Google Inc. (DOM-258879)
Please contact contact-admin@google.com 1600 Amphitheatre Parkway Mountain View CA 94043 US

Domain Name: google.com
Registrar Name: Markmonitor.com
Registrar Whois: whois.markmonitor.com
Registrar Homepage: http://www.markmonitor.com

Administrative Contact:
DNS Admin (NIC-14290820) Google Inc.
1600 Amphitheatre Parkway Mountain View CA 94043 US
dns-admin@google.com +1.6506234000 Fax- +1.6506188571
Technical Contact, Zone Contact:
DNS Admin (NIC-1340144) Google Inc.
2400 E. Bayshore Pkwy Mountain View CA 94043 US
dns-admin@google.com +1.6503300100 Fax- +1.6506181499

Created on..............: 1997-Sep-15.
Expires on..............: 2011-Sep-14.
Record last updated on..: 2006-May-17 11:10:55.

Domain servers in listed order:
NS3.GOOGLE.COM
NS4.GOOGLE.COM
NS1.GOOGLE.COM
NS2.GOOGLE.COM

MarkMonitor.com - The Leader in Corporate Domain Management
----------------------------------------------------------
For Global Domain Consolidation, Research & Intelligence,
and Enterprise DNS, go to: www.markmonitor.com
----------------------------------------------------------

Retrieving DNS records for google.com...
DNS servers
ns4.google.com [216.239.38.10]
ns3.google.com [216.239.36.10]
ns2.google.com [216.239.34.10]
ns1.google.com [216.239.32.10]

Answer records
google.com 1 A 72.14.207.99 300s
google.com 1 A 64.233.187.99 300s
google.com 1 A 64.233.167.99 300s
google.com 1 TXT v=spf1 ptr ?all 300s
google.com 1 MX
preference: 10
exchange: smtp1.google.com
3600s
google.com 1 MX
preference: 10
exchange: smtp2.google.com
3600s
google.com 1 MX
preference: 10
exchange: smtp3.google.com
3600s
google.com 1 MX
preference: 10
exchange: smtp4.google.com
3600s
google.com 1 NS ns1.google.com 345600s
google.com 1 NS ns2.google.com 345600s
google.com 1 NS ns3.google.com 345600s
google.com 1 NS ns4.google.com 345600s
google.com 1 SOA
server: ns1.google.com
email: dns-admin@google.com
serial: 2006071803
refresh: 7200
retry: 1800
expire: 1038800
minimum ttl: 60
86400s

Authority records
google.com 1 NS ns1.google.com 345600s
google.com 1 NS ns2.google.com 345600s
google.com 1 NS ns3.google.com 345600s
google.com 1 NS ns4.google.com 345600s

Additional records
smtp1.google.com 1 A 216.239.57.25 600s
smtp2.google.com 1 A 64.233.167.25 600s
smtp3.google.com 1 A 64.233.183.25 600s
smtp4.google.com 1 A 66.102.9.25 600s
ns1.google.com 1 A 216.239.32.10 345600s
ns2.google.com 1 A 216.239.34.10 345600s
ns3.google.com 1 A 216.239.36.10 345600s
ns4.google.com 1 A 216.239.38.10 345600s

Network IP address lookup:

Xwhois query for 64.233.167.99...
Results returned from whois.arin.net:
OrgName: Google Inc.
OrgID: GOGL
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: US

NetRange: 64.233.160.0 - 64.233.191.255
CIDR: 64.233.160.0/19
NetName: GOOGLE
NetHandle: NET-64-233-160-0-1
Parent: NET-64-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.GOOGLE.COM
NameServer: NS2.GOOGLE.COM
Comment:
RegDate: 2003-08-18
Updated: 2004-03-05

RTechHandle: ZG39-ARIN
RTechName: Google Inc.
RTechPhone: +1-650-318-0200
RTechEmail: arin-contact@google.com
OrgTechHandle: ZG39-ARIN
OrgTechName: Google Inc.
OrgTechPhone: +1-650-318-0200
OrgTechEmail: arin-contact@google.com

# ARIN WHOIS database, last updated 2006-07-18 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database

http://geektools.com

; <<>> DiG 8.2 <<>> @ google.com ANY
; Bad server: -- using default server and timer opts
; (3 servers found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 0 ;; QUERY SECTION: ;; google.com, type = ANY, class = IN

;; ANSWER SECTION:
google.com. 3d13h49m20s IN NS ns4.google.com.
google.com. 3d13h49m20s IN NS ns1.google.com.
google.com. 3d13h49m20s IN NS ns2.google.com.
google.com. 3d13h49m20s IN NS ns3.google.com.

;; AUTHORITY SECTION:
google.com. 3d13h49m20s IN NS ns4.google.com.
google.com. 3d13h49m20s IN NS ns1.google.com.
google.com. 3d13h49m20s IN NS ns2.google.com.
google.com. 3d13h49m20s IN NS ns3.google.com.

;; Total query time: 0 msec
;; FROM: gp.centergate.com to SERVER: default -- 204.74.68.5
;; WHEN: Wed Jul 19 04:26:09 2006

;; MSG SIZE sent: 28 rcvd: 15

Friday, July 14, 2006

OpenSSL – cipher strength

A vulnerability scanner may identify that the target website supports weak or Null strength ciphers.

Vulnerability Scanner

Scanner check Information

Nessus

Nessus Plugin 10863 “SSL ciphers”

Nessus Plugin 21643 “Supported SSL Ciphers Suites” may report “The remote service supports the use of weak SSL ciphers” and “Solution : Reconfigure the affected application if possible to avoid use of weak ciphers”


OpenSSL can be used to perform manual tests to confirm what sorts of cipher strengths a website is configured to support. In the examples below, I have only used a few of the cipher categories available to demonstrate the differences in the responses received.


Testing connections with Null ciphers

When the Null cipher suite is used, there is no encryption taking place, i.e. the messages are being sent in plain text.

The examples below show how neither google.com nor the natwest.com site support Null ciphers


$>
openssl s_client -connect www.google.com:443 -cipher NULL

CONNECTED(00000003)

3716:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:562:

$>

$>
openssl s_client -connect www.natwest.com:443 -cipher NULL

CONNECTED(00000003)

4088:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

$>


Testing support of LOW encryption (up to 64 bit) ciphers

These examples show that google.com does support weak ciphers, but natwest.com does not.


$> openssl s_client -connect www.google.com:443 -cipher LOW

CONNECTED(00000003)

depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
[..snip..]


$> openssl s_client -connect www.natwest.com:443 -cipher LOW


CONNECTED(00000003)

1412:error:140920F8:SSL routines:SSL3_GET_SERVER_HELLO:unknown cipher returned:s3_clnt.c:728:

$>


Testing support of MEDIUM encryption (128 bit) ciphers

Here you can see that both sites support medium strength ciphers.


$> openssl s_client -connect www.google.com:443 -cipher LOW


CONNECTED(00000003)

depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
[..snip..]


$> openssl s_client -connect www.natwest.com:443 -cipher MEDIUM


CONNECTED(00000003)

depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CP
S Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=GB/ST=Lothian/L=Edinburgh/O=Royal Bank of Scotland Group/OU=E-Services/OU=Terms of use at www.verisign.co.uk/rpa (c)05/OU=Authenticated by VeriSign/OU=Member, VeriSign Trust Network/CN=www.natwest.com
i:/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
1 s:/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
[..snip..]


Testing support of HIGH encryption (greater than 128 bit) ciphers

Obviously both these sites support encryption ciphers of greater than 128 bits in strength.


$> openssl s_client -connect www.google.com:443 -cipher HIGH


CONNECTED(00000003)

depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
[..snip..]


$> openssl s_client -connect www.natwest.com:443 -cipher HIGH


CONNECTED(00000003)

depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CP
S Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=GB/ST=Lothian/L=Edinburgh/O=Royal Bank of Scotland Group/OU=E-Services/OU=Terms of use at www.verisign.co.uk/rpa (c)05/OU=Authenticated by VeriSign/OU=Member, VeriSign Trust Network/CN=www.natwest.com
[..snip..]


For further information, you may want to refer to the OpenSSL ciphers manual page:

http://www.openssl.org/docs/apps/ciphers.html

Tuesday, July 11, 2006

Using OpenSSL

The OpenSSL command-line utility is very useful for testing various aspects of connecting to a website that implements Secure Socket Layer or Transport Layer Security encryption.

From a security testing perspective, I use OpenSSL in the following ways:

* Information Gathering

Checking connectivity with an encrypted site; viewing the information available within the certificate; confirming what cipher strengths the server permits client browsers to use when communicating with it; etc

* Target Identification

Mostly this step is left to the automated tools like nmap, but connecting to ports that are running SSL (or TLS) services (not only TCP port 443, but many others) could be useful in helping to confirm that you want to include a particular target system as part of a test.

* Service Enumeration
Mostly this step is left to the automated tools like nmap, but being able to confirm that a service listening on a target is running SSL/TLS could help narrow the focus of the testing activities performed against the target.

* Manual Testing
Being able to manually perform (or re-perform) examples of the communications that normally are automatically performed between a web browser and a web server has become one of the cornerstones of any Web Application Vulnerability Assessment I have ever performed.

* Automated Testing
Generally, I will use manual testing to validate the key results identified by automated tools, e.g. vulnerability scanners like Nessus, ISS, Retina, WebInspect, AppScan, etc, with a primary aim being to eliminate false-positive results.

OpenSSL is available for many platforms. I use the OpenSSL package that comes with CygWin on my Microsoft Windows machines.

For information about command line switches and options available with openssl, refer to: http://dev.openssl.org/docs

When connecting to a web server, there are two main HTTP protocol standards used: HTTP/1.0 and HTTP/1.1

The basic command format needed to connect to a website so that you can interact with it as though you were mimicking a web browser is:
openssl s_client -connect web.site.address:port

== Example 1 Start ==
Example connection to a site, requesting the contents of the default root directory:
-- Step 1: Establish the connection to the site, by inputting "openssl s_client -connect www.google.com:443" at the command prompt and pressing [Enter]
-- Step 2: Issue the basic HTTP command "GET / HTTP/1.o" and press [Enter] twice

$ openssl s_client -connect www.google.com:443
CONNECTED(00000003)
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQS6WuWd7dHMeAfIkikfDiQzANBgkqhkiG9w0BAQQFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wNjA1MTUyMzE4MTFaFw0w
NzA1MTUyMzE4MTFaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcw
FQYDVQQDEw53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA5sXGjc0LowME3K7MyUa+vcydvHM0SP7TdWTQycl2J3IPqZYaO4HzFPaukFbn
GdJzaKeFpK7KJBQwALroNl2BczpxBY+xrxGH2lzxPr9TUYRvRA636CbXL7Jv8vJd
36fPjKXpHm8wSJQhCwGtug5xAQ0Q77/uLNON/lSo/tOXj8sCAwEAAaOB5zCB5DAo
BgNVHSUEITAfBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIEATA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlU0dDQ0EuY3Js
MHIGCCsGAQUFBwEBBGYwZDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AudGhhd3Rl
LmNvbTA+BggrBgEFBQcwAoYyaHR0cDovL3d3dy50aGF3dGUuY29tL3JlcG9zaXRv
cnkvVGhhd3RlX1NHQ19DQS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQF
AAOBgQBXS7ykQ+fgAZKgljX5GAiIHXtwGY/5NrIFOgXKFFlNJA7liq9Oh1r3HCqW
j8thQJ7StDhAISTBTx/LE0qPlQLfkT3WQOsRb5sQoW/OkV4w9m0TXhWkLsIYngDD
2DJnR/y4HprZmo7M/3wStwO/UiDPIfTzd90SFfCU+pDV41logQ==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1777 bytes and written 340 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 565454E28BCFC41C7704F9E67AD0A0AA70A36995464AE1D1A2C 1450F218F27B7
Session-ID-ctx:
Master-Key: 9579BF349BA3A4DFE3EF0E72E63DC3DF5303E33643FC4DC37D3 78ADBABCEFD57EA440EFCEFA39A7E81695DF2A717E999
Key-Arg : None
Start Time: 1152582311
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
GET / HTTP/1.0


HTTP/1.0 302 Found
Location: http://www.google.com
Date: Tue, 11 Jul 2006 01:45:16 GMT
Content-Type: text/html
Server: GFE/1.3
Connection: Close
Content-Length: 218


<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com">here</A>.
</BODY></HTML>
read:errno=0

== Example 1 End ==

P.S. I see there is a new project that is being worked on, which will be interesting to watch: OpenTLS.org