Installing rails on ubuntu 10.04 Server

Installing rails on Ubuntu 10.04 Server was painful. Lessons I learnt were, don’t use the system ruby, don’t use the system gem, don’t try and use the system ruby with a downloaded copy of gem…

I ended up using rvm (Ruby Version Manager) for the install, you also need to install nodejs from an external repository…

sudo su # become root

apt-get install build-essential openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake libtool bison subversion
sudo apt-get install python-software-properties

add-apt-repository ppa:chris-lea/node.js
apt-get update
apt-get install nodejs

bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer ) /usr/local/rvm/bin/rvm install 1.9.2 /usr/local/rvm/bin/rvm use 1.9.2 /usr/local/rvm/bin/gem install rails /usr/local/rvm/bin/gem install execjs exit # become a normal user again. cd ~ # your project directory, could change user here. rails new simpleweb # create a new rails project cd simpleweb rake db:create # create application databases (sqlite) rails server # start the rails server! [/sourcecode] Point a web browser at http://localhost:3000 and you should see the example Ruby site.

Can resolve using nslookup but not ping on Linux

In my case this was I believe caused by avahi lookups taking priority.

In nsswitch.conf I had:

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

I changed this to:

hosts:          files dns mdns4_minimal [NOTFOUND=return] dns mdns4

and all was well.

SecurityTube, Wireless Lan Security Megaprimer notes: part 13 (SSL Man-In-The-Middle Attacks)

Vivek’s video for this part is here.

In this part Vivek shows us how to modify the requests as they pass though the system in a man in the middle attack. This allows us to change web requests and intercept SSL connections (though this will give an error on the client, it is usually ignored by the user).

We’re going to use DNS spoofing. The tool used is called dnsspoof.

This will sniff on an interface, whenever it sees a DNS request it will reply with the attacker machines IP.

We’re carrying on from the previous part, with a bridge setup which routes all traffic via our host to the internet.

0. We can run dnsspoof on the bridge as follows:

dnsspoof -i mitm

This will trigger on all DNS traffic not originating from the attacker machine.

The external DNS will ALSO reply. However dnsspoof will respond first, and therefore will be used.

1. Try and correct to a site from your client.

You should see the DNS lookup in the dnsspoof window.

2. Now all traffic will be going to our machine, but our machine doesn’t know how to reply. So we need to run a proxy here.

We use a proxy server included with backtrack called Burp suite.

Select Backtrack->Web Application Analysis->Web (frontend)->Burp suite from the programs menu.

NOTE: I couldn’t find this on backtrack 5 R1. To run Burp suite here I did the following:

cd /pentest/web/burpsuite
sh ./suite.bat

This will start a proxy on port 8080 by default. This is no good because requests are coming in on port 80 and 443 (for ssl)

Click Proxy, options, enter 80 in “local listener port” and click add.

Enter 443 in “local listener port” and click add.

3. Try and connect to a site on your client again. It’ll screw up. This is because the client isn’t configured to use a proxy…

4. Click on the port 80 line in burp suite. Select “support invisible proxying for non-proxy aware clients”. (do the same for port 443).

5. Select the intercept tab. Load a page on the client.

You should see the web request in burp suite. Remove the intercept. And try and load a page on the client.

You should see that it loads normally. You can also see the DNS requests in dnsspoof.

6. Turn the intercept on, and search for “antivirus” on the client. Note that you see the search in the intercept.

7. You can now edit the intercepted request, change “antivirus” to “pwned”. And click “forward”. You should see that your client gets search requests for the word “pwned”.

Neat! You can automate a lot of this using burpscript to other proxy servers such as delicate.

8. Now, enter gmail.com on your client.

You will get an error saying “Can not verify server identity”. Burp proxy, is performing the signing itself, and this is causing the error.

However, must users will just hit continue though this. Beyond this point, the login will look fine. Enable intercepts again. Login on the client, and you’ll be able to see the password in the intercept window.

Vivek has other videos on this see:

here and here.

SecurityTube, Wireless Lan Security Megaprimer notes: part 12 (A Man-In-The-Middle Attack)

Vivek’s video is here.

In the unencrypted man in the middle attack, we deauth the client from the regular AP and reconnect it to our own fake AP.

We can either connect the client to a new wired (or 3G) internet connection or we can connect back to the real AP.

In our setup we’re going to get our victim to connect to our fake AP, and then send the traffic out to the internet via a different access point.

We’ll use the alfa card to create a fake AP. We’ll use the laptops built in wifi card to connect to our other AP.

0. Setup your network card in VirtualBox/VMWare, using “NAT” is probably your best option.

1. Bring up eth0 in backtrack

ifconfig eth0 up

2. Bring up an access point with SSID SecurityTube

ifconfig wlan0 up
airmon-ng start wlan0
iwconfig wlan0 channel 1
airbase-ng -ssid SecurityTube mon0

3. Bridge the interfaces

Run this in a new terminal window:

ifconfig at0 up
brctl addbr mitm
brctl show #will show the bridge, but no interfaces added
brctl addif mitm eth0
brctl addif mitm at0
ifconfig eth0 0.0.0.0 up  #not sure why this is needed!
ifconfig at0 0.0.0.0 up

If you do ifconfig, you’ll see a new bridge, mitm. Bring up the interface:

ifconfig mitm
dhclient3 mitm

The dhclient command, gets an IP address, this will come from the virtualbox dhcp server.

4. Go to the airbase-ng window. Connect a device to the fake network you created.

The device will get a IP address from VirtualBox.

5. Open up wireshark, start a capture on at0. Open a webpage on your client.

You should see a lot of traffic in wireshark. You should be able to view pages on your client via the laptops internet connect.

All packets have to go though us, this is a little better than passively sniffing cleartext packets and all packets /MUST/ go through us.