Friday, June 22, 2007

Logitech 2.4 GHz Cordless Presenter

Recently we have found ourselves in need of a cordless presenter. Details on the device itself can be found on Logitech's web site:

http://www.logitech.com/index.cfm/mice_pointers/presentation_remote/devices/175&cl=us,en

I have to say we have been pleased with this device. It functions out of the box with no drivers (yes, it works in Ubuntu linux, I haven't had an opportunity to test it in other operating systems), the USB connector can be stored inside the unit and comes with a neoprene carrying case.

It has worked flawlessly in MS Powerpoint and OpenOffice Impress. Overall I would recommend it if you want a cordless presenter that does not function as a mouse.

Olympus VN-2100PC and Windows Vista Ultimate


It was high time to purchase these for the Incident Response team. According to the Olympus web site the device is Vista compatible:

http://www.olympus.co.jp/en/support/imsg/vtrek/compati/winvista.cfm#vn

Armed with this information I attempted to install the device allowing Vista to perform its automagical powers of detection and stup. Alas, to no avail. At this point I resorted to the installation CD that came with the device.

After running the installation and subsequently launching the executable it terminated immediately. Based off my previous dealings with Vista I simply allowed Vista to execute the program using Windows XP SP2 compatibility.

Voila! Instant access to the device and full functionality. As is true with all things there is more than one way to skin a cat. Olympus provides a patch to the software that provides Vista compatibility:

http://www.olympusamerica.com/files/DWPUP4EN.zip

As the device is used in the field I will keep folks updated with its pros and cons. If anyone else is using it or a similar device please leave a comment.

Thursday, June 21, 2007

PayPal and two factor authentication

Reading the article below really got me to thinking this morning. It sparked enough motivation for a blog post at least.

http://www.securityfocus.com/brief/528

I've always been an advocate for multi factor authentication. One of the main issues that I have with it is proper implementation. When I used to work for a major telecommunications carrier many of the staff in the IT department were issued credit card sized RSA devices to be used as secondary authentication when accessing the network via VPN. There were stringent rules as to where you could store it, that you couldn't loan it out or leave it lying about in plain view, etc.

On the other hand my girlfriend works for a local university in an accounting department. All of the employees in her department have RSA key fobs for usage as second factor authentication when logging in to the network. Well...while picking her up from work one evening I noticed that after she logged off she placed the key fob next to her keyboard. Being security conscious (picture that!) I asked “Aren't you going to lock that in your drawer or take it with you?”. She looked at me, smiled as if I were an idiot and matter of factly replied “Why would I do that? Everyone here leaves theirs on the desk when they leave.” Flabbergasted I walked to each workstation and checked, lo and behold at every workstation neatly placed to the left of the keyboard was an RSA key fob!

What does this story have to do with PayPal and the extra security measures they are attempting to employ? Everything. Two factor authentication doesn't do you much good if you don't take measures to ensure that the security it can provide you is not easily circumvented by poor security practices. When not in use do not leave it on your desk while you go to the restroom or leave for the day.

The following post below also shows that two factor authentication is not fool proof nor a panacea. You still need strong IT controls and policy in place.

http://neural-cybernetix.blogspot.com/2006/07/phishers-defeat-2-factor.html

On a side note I actually participated in the beta program and actually have one of the PayPal authentication devices. It was inexpensive, very painless to setup and works well. I keep it with me most of the time and when I don't I make certain that it is stored securely.

Monday, June 18, 2007

PQI Travel flash-Multi Slot Card R/W and Linux

I have one of these and needed to access an SD card to retreive some information from it via Slackware Linux. The text below shows the steps I took to get this piece of hardware working correctly.

First make sure that the card reader was even being picked up:

igs-awilliams@IGS-LAP02:~> less /proc/scsi/usb-storage-0/1

Host scsi1: usb-storage
Vendor: Generic
Product: USB Storage Device
Serial Number: 0AEC305000001A002
Protocol: Transparent SCSI
Transport: Bulk
GUID: 0aec5010aec305000001a002
Attached: Yes

Thats present so I can proceed.

Under Linux these things are detected as SCSI devices do you have to
accommodate the multiple devices. Add the following to your lilo.conf:

append = "max_scsi_luns=6"

You will have to reboot after running lilo for the changes to take effect.

Now once you have rebooted you can check what drives your system has available:

igs-awilliams@IGS-LAP02:~> sudo fdisk -l

Disk /dev/sdc: 256 MB, 256901632 bytes
8 heads, 62 sectors/track, 1011 cylinders
Units = cylinders of 496 * 512 = 253952 bytes

This doesn't look like a partition table
Probably you selected the wrong device.

Device Boot Start End Blocks Id System
/dev/sdc1 ? 1568823 3870254 570754815+ 72 Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(357, 116, 40) logical=(1568822, 3, 11)
Partition 1 has different physical/logical endings:
phys=(357, 32, 45) logical=(3870253, 0, 51)
Partition 1 does not end on cylinder boundary.
/dev/sdc2 ? 340100 4243383 968014120 65 Novell Netware 386
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(288, 115, 43) logical=(340099, 6, 47)
Partition 2 has different physical/logical endings:
phys=(367, 114, 50) logical=(4243382, 4, 42)
Partition 2 does not end on cylinder boundary.
/dev/sdc3 ? 3769923 7673205 968014096 79 Unknown
Partition 3 has different physical/logical beginnings (non-Linux?):
phys=(366, 32, 33) logical=(3769922, 2, 30)
Partition 3 has different physical/logical endings:
phys=(357, 32, 43) logical=(7673204, 7, 39)
Partition 3 does not end on cylinder boundary.
/dev/sdc4 ? 5817906 5818018 27749+ d Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
phys=(372, 97, 50) logical=(5817905, 4, 25)
Partition 4 has different physical/logical endings:
phys=(0, 10, 0) logical=(5818017, 3, 33)
Partition 4 does not end on cylinder boundary.

Partition table entries are not in disk order
This disk has both DOS and BSD magic.
Give the 'b' command to go to BSD mode.

Disk /dev/hda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 2197 17647371 7 HPFS/NTFS
/dev/hda2 2198 5844 29294527+ 83 Linux
/dev/hda3 5845 5968 996030 82 Linux swap
/dev/hda4 5969 7296 10667160 83 Linux

Now its a matter of mounting the drive and verifying the contents:

igs-awilliams@IGS-LAP02:~> sudo mount -t vfat /dev/sdc4 /mnt/usbkey
igs-awilliams@IGS-LAP02:~> ls /mnt/usbkey
FileThatIWanted.exe
igs-awilliams@IGS-LAP02:~> df -h /mnt/usbkey
Filesystem Size Used Avail Use% Mounted on
/dev/sdc4 245M 28M 217M 12% /mnt/usbkey

There you have it. If anyone has a better solution please feel free to post a comment.

May Your Skill Prevail.

Safari Browser Bugs, Attack Surfaces, Oh My!

Before anyone gets upset read the following, then if you have an opinion I would love to hear it.

http://www.darkreading.com/blog.asp?blog_sectionid=415

This is to be expected. I am not a Apple basher per say (Hey! I have an iPod nano that I love) but it is a matter of exposure to threats. Now that the source code for Safari has been exposed to a greater number of threats there will be more people poking and prodding at it and more vulnerabilities will be found. This is to be expected regardless of the platform or application.

In a semi-related blog post over at Taosecurity that I read yesterday it was put very well.

http://taosecurity.blogspot.com/2007/06/triple-boot-thinkpad-x60s.html

Richard Bejtlich says:

Second, I am attending Black Hat this summer, and I don't trust Windows or Linux to that crowd. Sure, FreeBSD is "just as vulnerable" but the majority of the attackers will be looking for Windows and Linux users. Booting into FreeBSD and staying there will reduce my exposure surface.”

I totally agree with this statement. Even with the risk of sounding like a broken record I will reiterate that regardless of platform or application there are vulnerabilities that can . I too will be attending Black Hat and Defcon and will take extra measures from an OS and application perspective to maintain as small an exposure surface as possible.

Sunday, June 17, 2007

Using voipong with Back|track 2 Final

In a recent engagement we had the oppurtunity to capture VOIP traffic using tcpdump to save the output to a libpcap formatted file. After letting it run for a short time we saved the file and wanted to extract the contents and save them to a .WAV file available for playback. The following will show you how to install the latest release of voipong into Back|track Final, use tcpreplay to playback the libpcap formatted file as network traffic and subsequently listen to the resulting .WAV file.

First we must extract the voipong tarball:

bt ~ # tar -zxpvf voipong-2.0.tar.gz

Enter the voipong directory:

bt ~ # cd voipong-2.0

Prepare the proper Makefile for our platform:

bt voipong-2.0 # cp Makefile.linux Makefile

Issue the pair of commands to build and install voipong from source

bt voipong-2.0 # make

bt voipong-2.0 # make install

According to the INSTALL file we must also have sox installed to have voipong save files out to .WAV file from network traffic. Let's verify that sox is indeed present on our system:

bt voipong-2.0 # which sox
/usr/bin/sox
bt voipong-2.0 # which soxmix
/usr/bin/soxmix

Now we must edit the voipong.conf file to instruct it where to find sox and soxmix. In addition we must also change the entry as to what network adapter we will be using. The default is em0, in our case we will be changing this to ath0.

bt voipong-2.0 # nano /usr/local/etc/voipong/voipong.conf

Now we can execute voipong, I have used the -f switch to force it to the foreground without daemonizing so we can see the output in real time.

bt ~ # voipong -f
EnderUNIX VOIPONG Voice Over IP Sniffer starting...
Release 2.0, running on bt [Linux 2.6.20-BT-PwnSauce-NOSMP #3 Sat Feb 24 15:52:59 GMT 2007 i686]

(c) Murat Balaban http://www.enderunix.org/
15/06/07 04:32:33: EnderUNIX VOIPONG Voice Over IP Sniffer starting...
15/06/07 04:32:33: Release 2.0 running on bt [Linux 2.6.20-BT-PwnSauce-NOSMP #3 Sat Feb 24 15:52:59 GMT 2007 i686]. (c) Murat Balaban http://www.enderunix.org/ 8493]
15/06/07 04:32:33: Default matching algorithm: lfp
15/06/07 04:32:33: loadmodule: /usr/local/etc/voipong/modules/modvocoder_pcma.so (@0xb7f162a1)
15/06/07 04:32:33: loadmodule: /usr/local/etc/voipong/modules/modvocoder_pcmu.so (@0xb7f1427f)
15/06/07 04:32:33: loaded 2 module(s)
15/06/07 04:32:33: loadnetfile: fopen(/usr/local/etc/voipong/voipongnets): No such file or directory
15/06/07 04:32:33: ath0 has been opened in promisc mode. (10.1.1.0/255.255.255.0)

All looks well. Now its time to invoke tcpreplay so we can push our captured traffic back onto the network and view it with voipong. NOTE: voipong will capture this traffic in real time all on its own, I had to use the method because I had a capture file with VOIP traffic.

bt ~ # tcpreplay -i ath0 IGScallcapture.lpc
sending out ath0
processing file: IGScallcapture.lpc


15/06/07 04:36:11: [11222] VoIP call has been detected.
15/06/07 04:36:11: [11222] 10.0.0.145:49604 <--> 10.0.0.200:49606
15/06/07 04:36:11: [11222] Encoding 0-PCMU-8KHz, recording.......
15/06/07 04:38:33: [11222] maximum idle time [10 secs] has been elapsed for this call, the call might have been ended.
15/06/07 04:38:33: [11222] .WAV file output/20070615/session-enc0-PCMU-8KHz-10.0.0.145,49604-10.0.0.200,49606.wav has been created successfully
15/06/07 04:38:33: [11222] .WAV file output/20070615/session-enc0-PCMU-8KHz-10.0.0.200,49606-10.0.0.145,49604.wav has been created successfully
15/06/07 04:38:33: [11222] Mixed output files: output/20070615/session-enc0-PCMU-8KHz-10.0.0.145,49604-10.0.0.200,49606-mixed.wav
15/06/07 04:38:33: child [pid: 11222] terminated normally [exit code: 0]
15/06/07 04:43:39: SHUTDOWN signal caught, starting shutdown procedures...
15/06/07 04:43:39: PID 11039 [parent: 3047]: exited with code: 0. uptime: 7 minutes 42 seconds.

Everything looks great so far. Let's verify log output

bt log # cat /var/log/voipcdr.log
Start;End;Duration(seconds);Session Id;Party1 RTP Pair; Party 2 RTP Pair;Encoding;Rate
Fri Jun 15 04:36:11 2007;Fri Jun 15 04:38:23 2007;132;11222;10.0.0.145:49604;10.0.0.145:49606;0;8000

Once again, looks great. Lets check and see if our output files are in place.

bt output/20070615 # ls
session-enc0-PCMU-8KHz-10.0.0.145,49604-10.0.0.200,49606-mixed.wav session-enc0-PCMU-8KHz-10.0.0.200,49606-10.0.0.145,49604.wav
session-enc0-PCMU-8KHz-10.0.0.145,49604-10.0.0.200,49606.wav

Everything appears to be in order. Time for playback:

bt output/20070615 # play session-enc0-PCMU-8KHz-10.0.0.200,49606-10.0.0.145,49604.wav

Input Filename : session-enc0-PCMU-8KHz-10.0.0.200,49606-10.0.0.145,49604.wav
Sample Size : 16-bits
Sample Encoding: signed (2's complement)
Channels : 1
Sample Rate : 8000

Time: 00:48.89 [00:00.00] of 00:48.89 ( 100.0%) Output Buffer: 2.35M

Done.

Well...that's it in a nutshell. If you have any questions or feedback please feel free to drop me a comment.

May Your Skill Prevail.

Happy Fathers Day!

I just wanted to give a shout out to the other Fathers out there and hope that you enjoyed your day. I know that I did, Korean BBQ and Marinated Chicken Drumettes off the grill with Arrogant Bastard Ale to wash it all down with. Not to mention the shiny Fossil watch and other presents and accolades.

Definitely a day to remember.

Friday, June 15, 2007

Getting Tcpreplay and 802.11 to Play Nice

Sometimes you want to be able to replay traffic to analyze it live with different tools in your arsenal. This is not really an issue with standard Ethernet but can prove to be a bit challenging when faced with 802.11 traffic. Let's take a hands on look at what I'm talking about below.

So you captured some wifi data (802.11) with airodump-ng like this, for example:

igs-awilliams@IGSLAP02~> airmon-ng start wlan0

igs-awilliams@IGSLAP02~> airodump-ng -w dump -c 11 wlan0

(Or you captured with Kismet, etc.)

Now you want to go back and pull out passwords, URLs, instant messages and images from your capture file: dump.cap.

igs-awilliams@IGSLAP02~> dsniff -r dump.cap

dsniff: record_init: Invalid argument

And the other fun programs (driftnet, msgsnarf, urlsnarf, etc.) don't read files at all, they only work in real time listening on network interfaces. Driftnet won't even listen on 802.11 interfaces in rfmon mode:

igs-awilliams@IGSLAP02~> driftnet -i wlan0

driftnet: unknown data link type 119

The solution: Use tcpreplay to play back the packets on a network interface so all these interesting programs can work.

Download the latest stable release of tcpreplay (currently tcpreplay-2.3.5.tar.gz) here:

http://tcpreplay.synfin.net/trac/wiki/Download

Install from source in the usual fashion:

igs-awilliams@IGSLAP02~> tar xzvf tcpreplay-2.3.5.tar.gz

igs-awilliams@IGSLAP02~> cd tcpreplay-2.3.5

igs-awilliams@IGSLAP02~>tcpreplay-2.3.5 # ./configure

igs-awilliams@IGSLAP02~>tcpreplay-2.3.5 # make

igs-awilliams@IGSLAP02~>tcpreplay-2.3.5 # make install

Another small problem, tcpreplay doesn't understand 802.11 headers:

igs-awilliams@IGSLAP02~> tcpreplay -i lo dump.cap

sending on: lo

validate_l2(): Unsupported datalink type: 802.11 (0x69)

Relax, airdecap-ng can convert the capture to straight Ethernet. Normally you use this program to decrypt encrypted 802.11 data, but you can also use it just to strip the 802.11 headers:

igs-awilliams@IGSLAP02~> airdecap-ng dump.cap

Total number of packets read 256828

Total number of WEP data packets 315

Total number of WPA data packets 0

Number of plaintext data packets 42287

Number of decrypted WEP packets 0

Number of decrypted WPA packets 0

This creates a file named dump-dec.cap. If you need to decrypt the data as well, just include the necessary parameters (for example -e and -w) in the airdecap-ng command.

Now we're going to replay the data on the local loopback Ethernet interface (lo). This gives us an interface to send the data on without actually sending it out over the air or on the local network.

First start your programs to listen on the local interface (in different sessions of course, so you can see the output of each):

igs-awilliams@IGSLAP02~> dsniff -i lo

igs-awilliams@IGSLAP02~> driftnet -i lo

igs-awilliams@IGSLAP02~> urlsnarf -i lo

igs-awilliams@IGSLAP02~> msgsnarf -i lo

Then run tcpreplay (the -R option speeds up the replay):

igs-awilliams@IGSLAP02~> tcpreplay -i lo -R dump-dec.cap

sending on: lo

42287 packets (20751892 bytes) sent in 4.67 seconds

4435909.0 bytes/sec 33.84 megabits/sec 9039 packets/sec

Each sniffer sees the packets as they are replayed on the local interface.

May Your Skill Prevail!

Thursday, June 14, 2007

Choicepoint pays...but who benefits?

After this debacle it appears that it will culminate in what constitutes as a pass in the enterprise universe. For more details I refer you to the link to the article below and some of my commentary on the matter.

http://security.blogs.techtarget.com/2007/06/01/choicepoint-to-pay-500000-to-settle-with-43-states-and-dc/

An interesting resolution to an obvious lack of IT controls and governance. Furthermore the settlements and fine allocation is interesting. Why is the FTC receiving $10 million while the states are receiving $500,000 total? What ever happened to the actual customers whose information was carelessly handled? A $5 million dollar redress last year? That's it? Where is the accountability? Without it there is little incentive to improve security when the punishment for inappropriate conduct constitutes a slap on the wrist.


What are your thoughts?


How to use Webspy from the dsniff suite

Webspy is an interesting tool from the dsniff family of tools including dsniff (password sniffer), arpspoof (ARP poisoning tool), dnsspoof (DNS spoofing tool), msgsnarf (view messages from IM clients), mailsnarf (view email messages), tcpkill (kill tcp connections on a local LAN), tcpnice (force other connections to "play nice" with their tcp connections) and webspy (view a targets web browsing in real time). When properly setup it will intercept web browsing requests from the victim and display them in the attackers web browser in real time. This post will show you how to run webspy successfully. I am assuming a basic knowledge of the Unix command shell in addition to reading the entire man pages for all of the applications listed in this write up.

You will need the following tools to successfully use webspy:

Tested using Ubuntu 7.04 and Slackware 11.

An ARP spoofing application, either arpspoof or ettercap will do.

fragrouter or echo 1 > /proc/sys/net/ipv4/ip_forward

Webspy

Web browser (Firefox 2.0.0.4 was used)

The first step is to successfully arp poison the target as well as the gateway for the local subnet. This can be accomplished via the use of one of two tools. The venerable arpspoof or the more recent ettercap (which contains its own plugin that allows for remote browsing but is outside the scope of this example). I will show both for completeness.

# arpspoof -i interface -t gatewayIP victimIP

# arpspoof -i interface -t victimIP gatewayIP

Open these in two separate shells and run them independently of one another. If you receive a "arpspoof: couldn't arp for host 10.1.1.1" or similar error please visit the Troubleshooting section at the end of this document.

To accomplish the same effect using ettercap as your ARP poisoner of choice:

# ettercap -i interface -Tq -M arp:remote /gatewayIP/ /victimIP/

At this stage you will need to open another shell and ensure that you are passing your stolen packets back onto the network. As is normal for most things there is more than one way to accomplish this goal. You will need to open another shell to execute these commands.

fragrouter -B1

If you do not have fragrouter or for some reason wish to pursue an alternate method of achieving the same goal you can use the following from the command line:

# echo 1 > /proc/sys/net/ipv4/ip_forward

You will need to open another shell/console to execute webspy:

# webspy -i interface victimIP

Well we are almost there! You will need to start one more shell and start up your browser from the command line (starting the browser via other methods did not function correctly for me).

# mozilla &

At this point if you have followed the directions correctly your broswer will start and any sites visited by the victimIP will appear in your browser in real time.

Troubleshooting:

Q:

Every time I attempt to execute arpspoof I get the following error: arpspoof: couldn't arp for host 10.1.1.1. I have tried various command line switches and nothing appears to work.

A;

I received this error on my Slackware 11 installation which was compiled from source as opposed to using a package manager. The function arp_cache_lookup does not use the correct interface when running under Linux .. it always uses interface "eth0".. Don't fret, we can change this without too much effort. Change directory to where you unpacked dsniff to, you will want to find the file arp.c and edit a single parameter within it. Using your favorite editor open arp.c and change the following:

strncpy(ar.arp_dev, "eth0", sizeof(ar.arp_dev));

to

strncpy(ar.arp_dev, "wlan0", sizeof(ar.arp_dev));

Save the file and recompile the application.

If you have other issues, you got it running properly or you just want to drop a line feel free to leave a comment.

May Your Skill Prevail.

Due diligence?

I have been reading the story referenced below and felt compelled to offer up yet another opinion on the matter:

http://www.securityfocus.com/news/11469?ref=rss

It would seem that when a persons private and professional reputation are at stake a forensic investigation would strive to perform due diligence in regards to their investigative techniques including reporting. I would think that this would cut down on “erroneous” forensic testimony.

For more details on the situations past and present please read the following blog posts:

http://blog.wired.com/27bstroke6/2007/06/teacher_granted.html

http://blog.washingtonpost.com/securityfix/2007/06/substitute_teacher_granted_new.html

I just don't even know where to begin here. Suppressed evidence from the defense's technical witness? Failure of the local Teacher's Union to step forward and do the right thing? The judge who criticized bloggers for trying to “improperly influence the court”? This case is a very strong example of how much ignorance still exists concerning computers, malware, strong information security policies, proper training, etc.

Saturday, June 9, 2007

iodine and pingtunnel

Well I tried to go to bed last night at a decent time...guess it just
didn't work out.

In any case I decided to experiment with some tunneling tools. I'm
very interested in being able to tunnel traffic along covert channels
especially for testing/auditing purposes for a client.

That being said I did a little searching around and found the two
tools listed in the subject of the blog. I tried pingtunnel first
but couldn't get it to function in my test environment. I sent an
information packed email to the softwares author and hope to hear
something in a timely fashion. In the interim I decided that I would
give iodine a shot and see what I could get to work. My preliminary
findings are below:

Start the server:

-(igs-awilliams@IGS-DEV01:ttyp5)-(11 files:26k@iodine)-(0 jobs)-(19:36)-
-(~/iodine:$)-> sudo /usr/local/sbin/iodined -f 172.16.0.1 test.asdf
Enter password on stdin:

Opened /dev/tun0
Setting IP of tun0 to 172.16.0.1
Adding route 172.16.0.1/24 to 172.16.0.1
add net 172.16.0.1/24: gateway 172.16.0.1
Setting MTU of tun0 to 1024
Opened UDP socket
Listening to dns for domain test.asdf

Verfiy that the tun/tap interface is enabled:

tun0: flags=51 mtu 1024
groups: tun
inet 172.16.0.1 --> 172.16.0.1 netmask 0xffffff00

Ok...so far so good. Now lets setup the client:

igs-awilliams@IGS-LAP02:~> sudo /usr/local/sbin/iodine -f 10.1.1.36 test.asdf
Enter password on stdin:

Opened dns0
Opened UDP socket
Version ok, both running 0x00000400. You are user #0
Setting IP of dns0 to 172.16.0.2
Setting MTU of dns0 to 1024
Sending queries for test.asdf to 10.1.1.36

The tun/tap interface was aptly named dns0 so lets check that its
been created correctly:

dns0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.2 P-t-P:172.16.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1024 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:2153 (2.1 Kb)

If all this works correctly I should be able to ping 172.16.0.1 from
172.16.0.2 right?

igs-awilliams@IGS-LAP02:~> ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=255 time=18.1 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=255 time=17.2 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=255 time=17.3 ms
64 bytes from 172.16.0.1: icmp_seq=4 ttl=255 time=17.3 ms
64 bytes from 172.16.0.1: icmp_seq=5 ttl=255 time=17.4 ms

--- 172.16.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4040ms
rtt min/avg/max/mdev = 17.201/17.491/18.108/0.339 ms

Voila!

NOTE: Usage of iodine makes use of the tun/tap driver of *nix
platforms. Windows users need not apply. The driver installs
standard on OpenBSD (the server in the example above) and requires a
kernel adjustment and compile on Linux (the client in the example).
For a list of supported OSes and platforms consult the following:

http://dev.kryo.se/iodine/wiki/SupportedPlatforms

May Your Skill Prevail.

Precedent case for illegal wifi usage

I had to read the article below several times to try and wrap my mind around exactly what was taking place and the ramifications this would have.

http://www.foxnews.com/story/0,2933,276720,00.html

In my opinion a definite gray area in many ways. It seems as if some sort of warning would be available that a breach of policy has occurred or that for enforcement of this law to be conditional that when a proprietor advertises free wireless it include a notification that it is for paying customers only.

On the other hand one shouldn't connect to wireless access points without obtaining permission in advance. In addition, it would seem that a prosecutors office would have more pressing cases to pursue than something like this other than cases that “fall into their lap”. It would seem like enforcement of this law would be analogous to personal assault laws insofar that the victim (the coffee ship in this scenario) would need to press charges against defendant for the case to proceed forward.

What are your thoughts?

Friday, June 8, 2007

Backtrack 2 and the Alfa Network AWUS036H

One of the new features of Backtrack 2 is support for the Alfa Network AWUS036H. This 802.11 wireless USB adapter sports power output of 500mW as is based off the Realtek 8187 chipset and uses the corresponding drivers. Some of the highlights of this hardware in addition to its exceptional power levels are its Apple support and ability to be used in Backtrack via virtual machine software such as VMWare 6 (There are many reported issues with using VMWare 5 with this hardware).

If you have this adapter with Backtrack 2 using the default drivers provided with the distribution you have probably noticed lackluster connectivity and reliability. This has been drastically improved with user released modules for Backtrack. These modules not only address the shortcomings of the default drivers but also provide an upgrade path to the latest release of the famed aircrack-ng software including support for aircrack-ptw.

The latest version of these drivers can be found via the Backtrack 2 Community Forums:

http://forums.remote-exploit.org/showthread.php?t=6784&highlight=alfa+modules

Once you have obtained the modules in question the subsequent installation is straightforward and painless. Documentation for the install is provided within the .zip archive. Reading of the above mentioned forum thread is also highly recommended especially if you haven't previously installed modules under Backtrack 2.

Once you have the modules installed you will need to unload the previous ones and load the new ones with using the following syntax:

igs-awilliams@igs-lap01# ifconfig wlan0 down
igs-awilliams@igs-lap01# rmmod r8187 && modprobe r8187

You should then be able to issue the following commands to bring up the adapter and perform MAC address spoofing (optional):

igs-awilliams@igs-lap01# ifconfig wlan up
igs-awilliams@igs-lap01# ifconfig wlan0 hw ether 00:11:22:33:44:55

From here the sky is the limit. Kismet, the aircrack-ng suite, etc should function correctly as well as receiving accurate power levels from the driver. In addition to this connectivty to access points should be possible as well.

One observation that I made was that Backtrack tended to have a kernel panic if the adapter was plugged in at boot time. If you insert the adapter after boot and perform the necessary commands all should be well.

May Your Skill Prevail.

Warrantless cellphone seizure

To quickly summarize the article below deals with what constitutes warrant less seizure of a cell phone when a suspect is apprehended by law enforcement.

http://articles.techrepublic.com.com/2100-1009_11-6187389.html?tag=nl.e118

After reading the article several times I felt compelled to at least comment on its relevancy insofar as laws regarding the seizure of information and the devices it is stored upon emerge and evolve.

Motion for exclusion of any evidence obtained from the cell phone in the above case in PDF format:

http://www.politechbot.com/docs/cell.phone.4a.brief.052907.pdf

This case has interesting ramifications as precedent is set. As the lines between cellphones, PDAs and laptops continue to blur will warrants have to be issued where granularity and specificity become commonplace as to what can be searched and what is off limits? If there is a shortcoming in the level of detail in the aforementioned warrant what valuable information inaccessible for building a case?

What are your thoughts?