Ku Pilih Hatimu

ku pilih hatimu tak ada ku ragu
mencintaimu adalah hal yang terindah
dalam hidupku oh sayang
kau detak jantung hatiku

setiap nafasku hembuskan namamu
sumpah mati hati ingin memilihmu
dalam hidupku oh sayang
kau segalanya untukku

janganlah jangan kau sakiti cinta ini
sampai nanti di saat ragaku
sudah tidak bernyawa lagi
dan menutup mata ini untuk yang terakhir

setiap nafasku (setiap nafasku)
hembuskan namamu (hembuskan namamu)
sumpah mati (sumpah mati)
hati ingin memilihmu (ku milikmu)
dalam hidupku oh sayang
kau segalanya untukku ooh

janganlah jangan kau sakiti cinta ini
sampai nanti di saat ragaku
sudah tidak bernyawa lagi
dan menutup mata ini untuk yang terakhir

oh tolonglah jangan kau sakiti hati ini
sampai nanti di saat nafasku
sudah tidak berhembus lagi
karena sungguh cinta ini cinta sampai mati

tolonglah jangan kau sakiti cinta ini
sampai nanti aku tidak bernyawa lagi
dan menutup mata ini untuk yang terakhir

oh tolonglah jangan kau sakiti hati ini
sampai nanti di saat nafasku
sudah tidak berhembus lagi
karena sungguh cinta ini cinta sampai mati
cinta sampai mati

Nmap tutorial

Nmap is great security tool developed by “Fyodor”. Basically it was a *nix tool but now available on various platforms and with GUI as well.

This tutorial is for newbie’s and skiddies who would like to learn the proper way of using it. Geeks can use it to brush up the things.

I would opt the command line/console, as I love it. I won’t be going in great depth of NMap. For that you should read some book on it. I’ll try to give examples in between.

I’m assuming that you are “root”. Normal user won’t be able to execute many of its powerful scanning techniques. So let’s start….

Let the IP address to be scanned is 192.168.0.1. Simply it can be done as:

# nmap 192.168.0.1

Few default things have also been executed along with the above mentioned string. The actual string executed is:

#nmap –R –sS 192.168.0.1

Lets deal with “-R” here, will see –sS later on.

It’s a query to DNS server for reverse DNS name lookup i.e. requesting for some “name” attached with the specified IP address. It’s generally the case with servers. Hence if you don’t need the “name” desperately, avoid it using “-n” option.

#nmap –n 192.168.0.1 or #nmap –n –sS 192.168.0.1 (both are same)

‘-n’ disables Reverse DNS. Many DNS servers log name resolutions, so running an Nmap scan without disabling name resolution may cause Nmap station to appear in the DNS logs it attempts to resolve the name of every workstation it scans!

Disabling this option will speed up the scan manifold especially if you are scanning many machines simultaneously.

Now you may notice that Nmap doesn’t do anything for a while and then suddenly it comes up with result. It actually does lot of work in that duration. To see all that you must use ‘-v’ option, called as verbose.

#nmap –v –n 192.168.0.1

For more verbosity use ‘v’ twice

#nmap –vv –n 192.168.0.1

Scanning more than one machine

Ok, so up to here we were scanning one host only. What will you do to scan more than one host?

There are various ways of doing this. Let’s consider few of them, rest you should be able to think of:

Suppose you have to scan 192.168.0.1, 192.168.0.2 and 192.168.0.3

# nmap -vv –n 192.168.0.1,2,3 or

# nmap –vv –n 192.168.0.1-3

generalizing further

#nmap –vv –n 192.168.0.1-3,6,12-20.

It will scan 1,2,3,6 and 12 to 20.

If you have to scan all the 254 machines:

# nmap –vv –n 192.168.0.1-254 or

# nmap –vv –n 192.168.0.* or

# nmap –vv –n 192.168.0.1/24 (you should know subnetting for it)

# nmap –vv –n 192.168.1-2.*. It will scan 192.168.1.0 to 192.168.2.255. It can also be written as

#nmap –vv –n 192.168.1,2.0-255

Hope you have enough brain to get these things.

Scanning specific ports:

Suppose you have to scan specific ports only and not the defaults ones. You should use ‘-p’ for that

# nmap –vv –p 80 192.168.0.1. It will scan port 80

# nmap –vv –p 21,23,25,80-100 192.168.0.1

. It will scan port number 21, 23, 23 and 80 to 100.

# nmap –vv –n –p 21,23,25 192.168.1-2.*

· Verbose mode (for interactive mode)

· Disabled reverse DNS lookup (speed up and doesn’t let DNS server log anything)

· Scanning specific ports

· Scanning 192.168.1.0 to 192.168.2.254 machines.

Various Scanning options:

There are many scanning options available with Nmap. All have their advantages and disadvantages. You should use them according to your requirements.

· -sS: SYN scanning

TCP SYN scan gather information about open ports without completing the TCP handshake process. When an open port is identified, the TCP handshake is reset before it can be completed. This technique is often referred to as “half open” scanning.

It’s the default scanning technique if you are “root”. It’s the most common scan to use because it works on all networks, across all operating systems.

ADV:

The TCP SYN scan never actually creates a TCP session so isn’t logged by the destination host’s applications. And hence it’s a quiet scan.

DISADV:

You need privileged access to the system.

# nmap –vv –n –sS 192.168.0.1

· -sT: TCP connect scanning

It performs the 3-way handshake.

ADV:

You don’t need to have privileged access.

DISADV:

Since it completes a TCP connection so apparent when application connection logs are examined.

I would suggest you to never ever use this scan.

# nmap –vv –n –sT 192.168.0.1

· -sF, -sX, -sN: FIN scan, Xmas tree scan, NULL scan.

These are called “stealth” scans. They send a single frame to a TCP port without any TCP handshaking or additional packet transfers. They are more “stealth” than SYN scan and must be used if the remote machine is not a Windows-based machine. I’ll tell you why.

These scans operate by manipulating the bits of the TCP header. Nmap creates TCP headers that combine bit options that should never occur in the real world. These purposely mangled TCP header packets are thrown at a remote device, and nmap watches for the responses.

Window-based systems will reply with a RST frame for all queries, regardless of the status of the specific port that was queried.

ADV:

Since no TCP sessions are established, they are quiet stealthy.

DISADV:

Can’t be used against windows-based machine.

# nmap –vv –n –sF 192.168.0.1

# nmap –vv –n –sX 192.168.0.1

# nmap –vv –n –sN 192.168.0.1

· -sU: UDP scan.

The only scan in the arsenal of Nmap to identify UDP ports.

# nmap –vv –n –sU 192.168.0.1

· -sO: Protocol scan

Sometimes it has to be checked that what protocols the remote machine is running. It locates uncommon IP protocols that may be in use on the remote system. Hence it helps determining the type of remote device, i.e. is that router or printer or workstation etc.

DISADV:

This scan will appear on any network monitoring application that identifies the IP protocol types in use.

# nmap –vv –n –sO 192.168.0.1.

· -sR: RPC scan.

It’s used to locate and identify RPC applications. It runs automatically during a version scan (-sV, explained later)

DISADV:

RPC scan opens application sessions and hence it will be logged.

# nmap –vv –sR 192.168.0.1

· -sV: Version scan

The scans which we have seen by now give you the status of the port and the service running on them. For exploiting the service you need the exact version number of the service. Version scan gives you this.

DISADV:

It opens sessions with the remote applications, which will often display in an application’s log file.

# nmap –vv –sV 192.168.0.1

· -sA: ACK scan

Its quiet useful when there is some packet filtering device or firewall. It never locates an open port. It does the job of identifying ports that are filtered through a firewall. It doesn’t open any application sessions and hence the conversation between nmap and the remote device is relatively simple.

DISADV:

It can only tell whether port is filtered or unfiltered. But can never definitively identify an open port.

# nmap –vv –sA 192.168.0.1

· -sI: Idle scan

It’s the stealthy most scan you can have. Tough to launch because you need a zombie for it. It would not be justice with this great scan to be described in just few lines. I would recommend you to read it in detail.

ADV:

You will never be caught.

DISADV:

Tough to launch as it’s not easy to find some zombie machine.

· -sP: Ping scan:

You must have heard of Ping sweep. It’s Nmap’s ping sweep.

# nmap –vv –sP 192.168.0.10

will check whether this machine is up or not

# nmap –vv –sP 192.168.0.*

will check the whole subnet (254) machines and will tell you which are up.

DISADV:

Ping scan will not interoperate with any other type of scan.

· -sW: Window scan

Forget it. As the number of operating systems vulnerable to its methodology is dwindling as operating systems are upgraded and patched.

· -sL: List scan

Would like to say only one line about it that you must use it if a separate application provides nmap with a list of IP addresses. Rest read yourself.

O/S fingerprinting and version detection

Ok, now you can use various scanning techniques to look for open/closed or filtered/unfiltered TCP as well as UDP ports. Don’t you want to know the remote operating system running???

-O:

Operating system fingerprinting.

# nmap –vv –O 192.168.0.1

It will tell you or at least tries its best to tell you the remote operating system along with the version it’s using. It at least need one open and one close TCP port. In case it doesn’t, it won’t be able to give the accurate result. In that case you should use some third party tool.

DISADV:

A trained eye will quickly identify that someone is watching the network.

-sV:

Version detection

As has been explained it will help you know the version of the service running on the remote machine.

# nmap –vv –sV 192.168.0.1

-A:

Named as Additional, Advanced, and Aggressive option. Its comprises of both the operating system fingerprinting process (-O) and the version scanning process (-sV).

i.e following two are same:

# nmap –vv –sV –O 192.168.0.1 and

# nmap –vv –A 192.168.01.

ETTERCAP ADVANCED

ECE4112 Lab 12

Lab12: Advanced Ettercap

 

Group Number: _________

Member Names: ___________________     _______________________

 

Date Assigned:

Date Due:

Last Edited: December 11, 2006

Authored By: David Wharton, Chris Cornett

Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions in the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the Date Due.

 Goal: This lab will introduce you to EttercapNG-0.7.3, showing you how to use it to do ARP poisoning, SSL man-in-the-middle attacks, DNS spoofing, and more.

 Summary: This lab consists of two sections. In Section 1 involves configuring, compiling, and installing all that is necessary to get Ettercap running.  Section 2 involves setting up a SSL enabled web server.  In Section 3 you will use Ettercap to demonstrate a SSL man-in-the-middle (MITM) attack.  Section 4 involves creating an Ettercap filter to modify packets between a web server and victim.  In Section 5 you will use Ettercap plugins to do DNS spoofing and more.

Background: Read “Hacking Exposed” Chapters 5 and 13.                                

Prelab:

A quick look at an ARP table.

  1. Find any windows machine and open the command prompt. [8]
  2. Type “arp –a” in the prompt to display the ARP table. Note that the table stores 3 things per entry: internet address (IP), physical address (MAC address) and whether the entry is static or dynamic. [8]
  3. Take a look at the Ettercap man page and familiarize yourself with what Ettercap is capable of. http://www.penguin-soft.com/penguin/man/8/ettercap.html. [4]
  4. Take a look at the appendices so you are aware of what is in them.

Lab Scenario:

This lab requires the use of three machines on the same network:

  1. RedHat WS 4 Host Machine
  2. RedHat WS 4 Virtual Machine that we will configure to be a SSL enabled web server.
  3. Windows XP Virtual Machine which will be the “victim”.

 

Section 1 – Installing EttercapNG

 

1.1. Installing Ettercap on the RedHat WS 4 Host Machine.

 

From the Lab12 directory on the nas4112 share copy the following to your RedHat WS 4 Host Machine:

             googlefilter.txt

            install (the entire directory)

On the RedHat WS 4 Host Machine, open a terminal and cd into the install directory you copied over.

 Install libpcap (also available from http://www.tcpdump.org/ [14]):

            tar –xvf libpcap-0.8.1.tar

            cd libpcap-0.8.1

            ./configure

            make

            make install

            cd ..

 

Install libnet (also available from http://www.packetfactory.net/libnet/ [15]):

            tar –xvf libnet-1.1.2.1.tar

            cd libnet

            ./configure

            make

            make install

            cd ..

 

Install OpenSSL (also available from http://www.openssl.org/ [16]):

            tar –xvf openssl-0.9.71.tar

            cd openssl-0.9.71

            ./config

            make

            make test

            make install

            cd ..

 

Install pkgconfig (also available from http://pkgconfig.freedesktop.org/ [17]):

            tar –xvf pkgconfig-0.15.0.tar

            cd pkgconfig-0.15.0

            ./configure

            make

            make check

            make install

            cd ..

 

Install glib (also available from http://www.gtk.org/ [18]):

            tar –xvzf glib-2.12.4.tar.gz

            cd glib-2.12.4

./configure

            make

            rm –rf /install-prefix/include/glib.h /install-prefix/include/gmodule.h

            make install

            ldconfig

            cd ..

 

Install ATK (also available from http://www.gtk.org/ [18]):

            tar –xvjf atk-1.9.1.tar.bz

            cd atk-1.9.1

            ./configure

            make

            make check

            make install

            cd ..

 

Install libpng (also available from http://www.libpng.org/pub/png/libpng.html [19]):

            tar –xvjf libpng-1.2.8.tar.bz2

            cd libpng-1.2.8

            ./configure

            make

            make install

            cd ..

 

Install freetype (also available from http://www.freetype.org/ [20]):

            tar –xvzf freetype-2.2.1.tar.gz

            cd freetype-2.2.1

            ./configure

            make install

 

Install fontconfig (also available from http://www.fontconfig.org/ [21]):

            tar –xvzf fontconfig-2.4.0.tar.gz

            cd fontconfig-2.4.0

            ./configure

            make

            make check

            make install

            cd ..

 

Install Cairo (also available from http://cairographics.org/ [22]):

            tar –xvzf cairo-1.2.2.tar.gz

            cd cairo-1.2.2

            ./configure

            make

            make install

            cd ..

 

Install Pango (also available from http://www.gtk.org/ [18]):

            tar –xvzf pango-1.14.7.tar.gz

            cd pango-1.14.7

 

open ../modules/Arabic/Arabic-lang.c and comment out the line that says:

 

#include “arabic-ot.h”

 

save the file and the continue the compilation and install:

 

./configure

            make

            make check

            make install

            cd ..

 

Install GTK (also available from http://www.gtk.org/ [18]):

            tar –xvzf gtk+-2.10.6.tar.gz

            cd gtk+-2.10.6

            ./configure

            make

            make install

            cd ..

 

Install Ettercap (also available from http://ettercap.sourceforge.net/ [23]):

 

Note: if you have a previous version of ettercap installed, you will want to uninstall it before installing ettercap-NG.  The easiest way to do this is to go the directory where you compiled the previous version and type, “make uninstall”.

 

            tar –xvf ettercap-NG-0.7.3.tar

            cd ettercap-NG-0.7.3

            ./configure

            make

            make install

 

Now, ettercap-NG is installed to /usr/local/bin.  This probably is not in your path so to make things easy, you can go ahead and put it in your path.  An easy way to do this, assuming that /sbin is in your path, is to create a symbolic link:

 

ln –s /usr/local/bin/ettercap /sbin/ettercap

 

Now you can launch ettercap from the terminal by just typing “ettercap” no matter what the current working directory is (of course you will have to specify a user interface; e.g. ettercap –G).

 

From a terminal type:

           

ettercap -G

 

If the Ettercap GUI comes up, you have successfully installed EttercapNG.  Close Ettercap for now since we still need to do some configurations.

 

Section 2 – Configuring Apache and SSL

 

Note: most of this section comes from Appendix E of Lab 9 although it has been modified somewhat. [2]

 

2.1. Copying over and configuring a RedHat WS 4 Virtual Machine.

 

From the nas4112 share, copy the following directory to your RedHat WS 4 Host Machine:

 

            VMWare/RedHatWS4

 

In VMWare, add the virtual machine you just copied over via the instructions from Lab 1.  You will also need to give it a unique IP in the IP range your group was assigned; see Lab 1 for instructions.

 

2.2. Installing and configuring Apache on a RedHat WS 4 Virtual Machine.

 

For this part of the lab we will be working on the RedHat WS 4 Virtual  Machine you just set up.  You will need to make sure you have mod_ssl installed before continuing with this part of the lab.  To install:

 

  • Applications à System Settings à Add/Remove Applications
  • Under Servers find Web Server
  • Open Details
  • Make sure the following are selected:
    • system-config-httpd
    • mod_ssl
    • crypto-utils
    • mod_ssl

 

If other items are checked as well that is OK, just leave it as it is.  Please obtain the RedHat WS 4 CD from the TA as necessary.

 

Now we need to make a few minor modifications to the default Apache/SSL configuration.  Go the Apache configuration directory:

 

NOTE: All the directories in this part of the lab should be correct.  If you have trouble finding any specific file, you can use the locate command, but make sure you run updatedb first since we just installed new software.

 

We need to adjust the default virtual host settings

 

With a text editor, open /etc/httpd/conf/httpd.conf

 

Go to the very bottom of the file and you should see Section 3: Virtual Hosts.  You need to modify it to look like this:

 

#

# Use name-based virtual hosting.

#

NameVirtualHost *:80

 

#

# VirtualHost example:

#

<VirtualHost *:80>

    ServerName http://www.ece4112.gatech.edu

    DocumentRoot /var/www/html

</VirtualHost>

 

You may notice the http://www.ece4112.gatech.edu.  Since we aren’t connected to the Internet in the lab, we have to fake it.  Open your /etc/hosts file and add the following entry to the end of the file:

 

57.35.6.x         http://www.ece4112.gatech.edu

 

Now add a default page to the new VirtualHost:

 

From the nas4112 share, copy the contents of Lab12/sample_web_page/ to /var/www/html/

 

The sample_web_page directory contains a html and gif file that are from www.google.com. [1]  The html file was modified slightly.

 

Next, make sure the permissions are set correctly:

 

chmod 755 /var/www/html/*

 

Start Apache:

 

apachectl start

 

At this point, you should be able to open a web browser and navigate to http://www.ece4112.gatech.edu and you should see the sample web page you copied over.  If everything works, go ahead and stop Apache then continue:

 

apachectl stop

 

2.3. Generating/Signing SSL Certificates

 

Now before we can setup the SSL virtual host in Apache we have to generate our own certificate and sign it ourselves (since we don’t want to pay for an SSL certificate for each group).

 

cd /etc/httpd/conf

mkdir ssl

cd ssl

openssl genrsa –out http://www.ece4112.gatech.edu.key 1024

chmod 0400 http://www.ece4112.gatech.edu.key

openssl req –new –x509 –nodes –sha1 –days 7 –key www.ece4112.gatech.edu.key –out http://www.ece4112.gatech.edu.crt

 

At the prompts, enter the following:

 

Country: US

State: Georgia

City: Atlanta

Organization: Georgia Tech

Organizational Unit: Group #x

Common Name: http://www.ece4112.gatech.edu

Email: <press enter / leave blank>

 

2.4. Configuring SSL in Apache

 

Now we have our certificate generated and signed, we can configure the SSL virtual host in Apache.  Go to the /etc/httpd/conf.d directory and open the ssl.conf file with a text editor.  You should see a similar section as before.  Make the necessary changes so your file looks like this:

 

<VirtualHost *:443>

# General setup for the virtual host, …

DocumentRoot “/var/www/html”

ServerName http://www.ece4112.gatech.edu:443

# Server Private Key:

SSLCertificateFile /etc/httpd/conf/ssl/www.ece4112.gatech.edu.crt

# Server Certificate:

SSLCertificateKeyFile /etc/httpd/conf/ssl/www.ece4112.gatech.edu.key

 

Save and close ssl.conf.

Start Apache:

 

apachectl start

 

In a web browser, go to https://www.ece4112.gatech.edu.  If you get a prompt about a certificate, you have configured the page correctly.

 

Section 3 – SSL Man-In-The-Middle

 

3.0.0 – Background on SSL and SSL MITM

 

Basic HTTP traffic is passed in plain text, and allows anyone who intercepts the traffic to easily see the information.  With the growth of e-commerce and websites that display personal information, there was a need to protect this information from prying and one form of protection is the Secured Socket Layer (SSL).  SSL is a protocol just below the application layer and above the transport layer that encrypts the communications between a host and website.  SSL makes use of an initial handshake that uses asymmetric encryption to securely pass a shared secret key for symmetric encryption, which is used for the actual transfer of data.

 

Symmetric encryption is where both hosts have a shared key, and the key can be used to encrypt and decrypt the code using a certain algorithm.  The benefit of symmetric encryption is that it is relatively fast. [12] The major problem is how to securely transfer the shared key without it being intercepted.  Asymmetric encryption can be used to solve this problem.  Asymmetric encryption makes use of public and private key pairs; the public key can be known by anyone, but the private key is kept secret. [12] The keys have a relationship where a message that is encrypted by the public key can only be decrypted by the private key. [12] Certain asymmetric encryption algorithms, such as Diffie-Hellman, are used to pass a shared key. 

 

One major concern of the use of asymmetric encryption is how to prevent a man in the middle attack.  All the person in the middle would have to do is intercept the public keys being sent and instead send his own to both.  Since both are using his public key, the eavesdropper can decrypt the message being sent and read it.  So they don’t realize the interception he re-encrypts the message and sends it to the intended receiver.   To prevent the man in the middle attack, digital certificates are used to tie the public key provided by the server to an organization.  Digital certificates contain the public key, information about the company to know who the key belongs to, and then the certificate is signed by a third party to verify that the information has been verified. [12] A Certificate Authority (CA) is the third party who checks the information is correct and the public key belongs to the correct organization. [12] They provide a company with a certificate that has been signed with their private key.  Browsers know the public key of most trusted CAs because their certificates are included in the install, so when a company sends their certificate issued by a CA, they can use the public key on the signature to verify it matches the certificate.  In these cases, the certificate is automatically trusted and the website is loaded seamlessly. [12] If a certificate is not issued by a CA, then the user is warned and must choose whether to accept the certificate.  After a certificate has been accepted it will be kept until the certificate is expired, and this version is compared to future submissions of the certificate.  If the certificate changes suddenly, then a warning or error will occur and the user will have to choose whether to accept the new certificate.

 

Further information about SSL can be found at http://en.wikipedia.org/wiki/SSL [11] and

http://apacheworld.org/ty24/site.chapter17.html. [12] Information on how to purchase a digital certificate can be found a Verisign’s website at http://www.verisign.com.  [13]

 

 

3.0.1.  How Ettercap does SSL MITM attack

 

In short, using Ettercap, the attacker will first ARP poison his victim and get all traffic between the victim and SSL web server to go through the attacker’s machine.  The attacker will then, using Ettercap, act as a “proxy”, giving the victim his SSL certificate 

when they request the SSL web server’s certificate, making it look like the SSL web server’s certificate.  The attacker will also set up a SSL connection with the web server.  Thus, when the victim thinks he is encrypting data and sending it to the SSL web server, the attacker is intercepting it, decrypting it (he can do this because 

the victim encrypted it with a key the attacker gave it), logging it, re-encrypting it using they key(s) that were set up when the attacker established a SSL connection to the SSL web server, and sending it on its way to the SSL web server.  The reverse happens for data going from the SSL web server to the victim.  This way, the attacker it able to see all the data between the victim and SSL web server in unencrypted format, including usernames and passwords.  The following diagram shows the SSL Man-In-The-Middle attack:

 

 

 

 

3.1. Configuring Ettercap for SSL Man-In-The-Middle.

 

Work in this section will be done on the RedHat WS 4 Host Machine on which on installed Ettercap.

 

open /usr/local/etc/etter.conf with a text editor.  Modify the line that looks like:

 

ec_uid = 65534

 

to be:

 

ec_uid = 0

 

Next, scroll down to the “redir_command_on/off” section and uncomment the following two lines (e.g. remove the ‘#’ character at the front of the line):

 

#redir_command_on = “iptables -t nat -A PREROUTING -i %iface -p tcp –dport %port -j REDIRECT –to-port %rport”

#redir_command_off = “iptables -t nat -D PREROUTING -i %iface -p tcp –dport %port -j REDIRECT –to-port %rport”

 

Save etter.conf and exit.

 

Finally, we need to turn on IP Forwarding:

 

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

 

3.2. SSL Man-In-The-Middle

 

The first thing we want to do is to navigate to the SSL page we set up so we can see the valid SSL certificate before we start messing with things using Ettercap.

 

From the Windows machine, in Internet Explorer, go to https://57.35.6.x/ where 57.35.6.x is the IP of the SSL enabled web server we set up.

 

If everything is working correctly, you will get a prompt about the SSL certificate.  This is the correct certificate for this site.  In the certificate window that pops up, do the following to save the certificate:

 

Click “View Certificate”

Click the “Details” tab and click “Copy to File…”.

This brings up a certificate export wizard.  Go through the wizard, selecting the default options and saving the file as certificate_valid.cer.

 

Next, on the RedHat WS 4 Host Machine,  start ettercap using the GUI:

 

ettercap –G

 

The Ettercap-NG window opens.  From the Sniff menu, select “Unified sniffing”.  Choose your network interface (probably eth0) and click “OK”.  Next, from the “Hosts” menu, select “Scan for hosts”.  To see the hosts ettercap found, select “Hosts list” from the “Hosts” menu.  We want to intercept traffic between our SSL web server and our Windows machine.  From the “Targets” menu, select “Select TARTGET(S)”.  For Target 1 enter the IP of the web server and for Target 2 enter the IP of the Windows machine.  Be sure to enclose the IP addresses with forward slashes (e.g. /57.35.6.127/).  Click “OK”.   Next, select “Start sniffing” from the “Start” menu.  Finally, now that the targets are set, choose “Arp poisoning” from the “Mitm” menu.  In the window that opens, check “Sniff remote connections” and click “OK”.

 

Now we have successfully ARP poisoned the web server and Windows machine.  On the Windows machine, open a command prompt and type:

 

            arp –a

 

Q3.2.1.  What does the Windows ARP table show as the MAC address of the web server?  Is this correct?

 

Q3.2.2. How can you prevent ARP poisoning?

 

Now, from the Windows machine, try to go to https://57.35.6.x/ where 57.35.6.x is the IP of the SSL enabled web server we set up.  When the certificate window pops up, go through the steps you did before to save the certificate, this time saving it as certificate_forged.cer.

 

Click OK to accept the certificate.

 

Q3.2.3.  After accepting the certificate, does the page load?

 

Next, on the Windows machine open up certificate_valid.cer and certificate_forged.cer and examine the certificates.

 

Q3.2.4.  How do the certificates certificate_valid.cer and certificate_forged.cer differ?  How are they similar?

 

Q3.2.5.  What is the significance of the victim using ettercap’s certificate instead of the one from the SSL web server?  The information is encrypted anyway so what is the big deal?

 

Q3.2.6.  When you are surfing the web and get a message about a SSL certificate, do you normally just click “OK” and surf on?   Do you think that will change after this lab?

 

Q3.2.7.  How can you prevent SSL MITM attacks?

 

Section 4 – Ettercap Filters

 

4.1. Writing and compiling an Ettercap filter.

 

Work in this part will be done on the RedHat WS 4 Host Machine on which we installed Ettercap.

 

Open the googlefilter.txt file you copied over earlier with a text editor.

 

Note: parts of this file were taken from the forums on Ettercap’s web page. [4]

 

Examine googlefilter.txt and try to figure out what it does.  You will probably want to take a look at Appendix A (man etterfilter).

 

Q4.1.1.  The file googlefilter.txt has 4 sections.  Using Appendix A, describe what each section does.  Also, why are sections 1-3 necessary?

 

In googlefilter.txt, find the section that reads:

 

if (ip.proto == TCP && tcp.src == 80) {

            msg(“data on TCP 80\n”);

            if (search(DATA.data, “Google Search”)) {

               msg(“snarfing google.com Google Search….”);

               replace(“Google Search”, ”   Group 00  “);

            }

 

and replace “00” with your group number.  Save and close googlefilter.txt.

 

Next, cd to the directory where googlefilter.txt is and compile the filter:

 

etterfilter –o googlefilter.filter googlefilter.txt

 

Copy the compiled filter to ettercap’s filter directory (not necessary but makes it easier to find in Ettercap):

 

cp googlefilter.filter /usr/local/share/ettercap/

 

Next well will load the filter we just created.  If ARP poisoning is not still enabled between the web server and Windows machine, go ahead and ARP poison them again like you did in the previous section.

 

4.2. Using an Ettercap filter.

 

Before we load the filter, first, using Internet Explorer on the Windows machine, go to http://57.35.6.x/ where 57.35.6.x is the IP of the SSL enabled web server we set up.  Note that this looks very similar to Google’s home page.

 

Now let’s load the filter.  In Ettercap on the RedHat WS 4 Host Machine, select “Load a filter” form the “Filters” menu.  Locate and select googlefilter.filter and click “OK”.  This loads the filter.

 

On the Windows machine, in Internet Explorer choose “Internet Options” from the “Tools” menu.  Then click “Delete Files…” under the “Temporary Internet files” section.  This clears Internet Explorer’s cache and ensures that the Windows machine will pull a new copy of the web page from the web server.

 

In Internet Explorer, go to http://57.35.6.x/ where 57.35.6.x is the IP of the SSL enabled web server we set up.

 

Q4.2.1.  What is different between the original google page and the one that is displayed after the googlefilter.filter was loaded?  How did this happen?

 

 

Section 5 – Ettercap Plugins

 

Ettercap comes with a myriad of plugins.  For details on the plugins available and descriptions of what they do, please see Appendix B.

 

5.1. Configuring Ettercap for DNS spoofing.

 

In a text editor, open /usr/local/share/ettercap/etter.dns.  Add a line that reads:

 

*ece4112* A 57.35.6.x

 

where 57.35.6.x is the IP of your web server.  This will cause ettercap to respond to DNS requests that include “ece4112” in the URL with a DNS replay saying that the IP of the requested URL is your web server.

 

5.2. DNS Spoofing With Ettercap

 

For this section we will use the text interface of Ettercap.  On your Ettercap machine, type the following in a terminal:

 

ettercap –T –M arp:remote –I eth0 /57.35.6.x/ /57.35.6.y/ -P dns_spoof

 

where 57.35.6.x and 57.35.6.y are the IPs of your windows machine and web server (it doesn’t matter which is which).  The ‘-T’ switch tells Ettercap to use the text interface, the –M switch tells Ettercap to perform a MITM attack, the ‘arp:remote’ specifies the type of MITM attack (arp poisoning and sniff remote connections), the ‘-I’ switch tells Ettercap which interface to use (eth0), the IP address are the target addresses, and the ‘-P’ switch tells Ettercap which plugin to load (dns_spoof).  [6]

 

From Windows machine, try to go to ece4112.com.  Then try to go to ece4112.net.

 

Q5.2.1. What happens when you try to go to a URL with ‘ece4112’ in it?  Why?

 

Q5.2.2. How is using Ettercap to do DNS spoofing better than just listening for DNS requests and replying to them?

 

Q5.2.3. What can be done to prevent DNS spoofing like this?

 

5.3 Using the remote_browser Plugin

 

We are going to take a look at one more Ettercap plugin.  Launch Ettercap with a graphical interface, as done previously (ettercap –G).

 

As before, ARP poison your web server and victim (Windows machine).

 

From the “Plugins” menu select “Manage the plugins”.

In the list of plugins, find “remote_browser” and double click it.  Verify that an asterisk appears next to “remote_browser” and the message “Activating remote_browser plugin…” appears in the messages pane (the bottom pane).

Next, on your Ettercap machine, open a new terminal and type:

 

            mozilla&

 

Go to your Windows Virtual Machine and in a web browser, go to http://57.35.6.x/ where 57.35.6.x is the IP of the SSL enabled web server we set up.  After the page loads on the Windows machine, go back to your Ettercap machine and look at Mozilla you previously opened up.

 

Q5.3.1.  How can the remote_browser plugin be useful for a hacker or administrator?

 

 


Final Section: Suggested additions and future enhancements

 

1.      SSH MITM attack.

2.      Capturing and analyzing packets/data using etterlog.

  1. Writing more advanced filters.
  2. Using more Ettercap plugins.
  3. Capture data and actually decrypt username/password from a SSL MITM attack (see section 9 of http://www.hak5.org/releases/1×04/sslattack.pdf). [9]

 


References

 

[1] www.google.com

 

[2] http://users.ece.gatech.edu/~owen/Academic/ECE4112/Fall2006/lab9_websec_07112006.doc

 

[3] http://ettercap.sourceforge.net/forum/viewtopic.php?t=2833

 

[4] http://www.penguin-soft.com/penguin/man/8/ettercap.html

 

[5] http://www.penguin-soft.com/penguin/man/8/etterfilter.html

 

[6] http://forum.s-t-d.org/viewtopic.php?pid=15078

 

[7] http://www.penguin-soft.com/penguin/man/8/ettercap_plugins.html

 

[8] http://users.ece.gatech.edu/~owen/Academic/ECE4112/Fall2006/lab2_01092006.doc

 

[9] http://www.hak5.org/releases/1×04/sslattack.pdf

 

[10] SANS Institute – SSL Man-in-the-Middle Attacks,  http://www.sans.org/reading_room/whitepapers/threats/480.php

 

[11] http://en.wikipedia.org/wiki/SSL

 

[12] http://apacheworld.org/ty24/site.chapter17.html

 

[13] http://www.verisign.com

 

[14] http://www.tcpdump.org

 

[15] http://www.packetfactory.net/libnet/

 

[16] http://www.openssl.org/

 

[17] http://pkgconfig.freedesktop.org/

 

[18] http://www.gtk.org/

 

[19] http://www.libpng.org/pub/png/libpng.html

 

[20] http://www.freetype.org/

 

[21] http://www.fontconfig.org/

 

[22] http://cairographics.org/

 

[23] http://ettercap.sourceforge.net/
Appendix A: etterfilter man page [5]

 

NAME

                etterfilter NG-0.7.3 – Filter compiler for ettercap content filtering engine

 

SYNOPSIS

                etterfilter [OPTIONS] FILE

 

DESCRIPTION

The etterfilter utility is used to compile source filter files into binary filter files that can be interpreted by the JIT interpreter in the ettercap(8) filter engine. You have to compile your filter scripts in order to use them in ettercap. All syntax/parse errors will be checked at compile time, so you will be sure to produce a correct binary filter for ettercap.

 

GENERAL OPTIONS

 

-o, –output <FILE>

you can specify the output file for a source filter file. By default the output is filter.ef.

    -t, –test <FILE>

you can analyze a compiled filter file with this option. etterfilter will print in a human readable form all the instructions contained in it. It is a sort of “disassembler” for binary filter files.

     -d, –debug

prints some debug messages during the compilation. Use it more than once to increase the debug level ( etterfilter -ddd … ).                         

     -w, –suppress-warnings

Don’t exit on warnings. With this option the compiler will compile the script even if it contains warnings.                            

      STANDARD OPTIONS

 

      -v, –version

Print the version and exit.

      -h, –help

prints the help screen with a short summary of the available options.

 

      SCRIPTS SYNTAX

A script is a compound of instructions. It is executed sequentially and you can make branches with the ‘if’ statements. ‘if’ and ‘if/else’ statements are the only supported. No loops are implemented. The syntax is almost like C code except that you have to put ‘if’ blocks into graph parentheses ‘{‘ ‘}’, even if they contain only one instruction. NOTE: you have to put a space between the ‘if’ and the ‘(‘. You must not put the space between the function name and the ‘(‘. Example:

if (conditions) { }

func(args…);

The conditions for an ‘if’ statement can be either functions or comparisons. Two or more conditions can be linked together with logical operators like OR ‘||’ and AND ‘&&’. Example:

if (tcp.src == 21 && search(DATA.data, “ettercap”)) {

} Pay attention to the operator precedence. You cannot use parentheses to group conditions, so be careful with the order. An AND at the beginning of a conditions block will exclude all the other tests if it is evaluated as false. The parsing is left-to-right, when an operator is found: if it is an AND and the previous condition is false, all the statement is evaluated as false; if it is an OR the parsing goes on even if the condition is false. Example:

if (ip.proto == UDP || ip.proto == TCP && tcp.src == 80) {

} if (ip.proto == TCP && tcp.src == 80 || ip.proto == UDP) {

} the former condition will match all udp or http traffic. The latter is wrong, because if the packet is not tcp, the whole condition block will be evaluated as false. If you want to make complex conditions, the best way is to split them into nested ‘if’ blocks.

Every instruction in a block must end with a semicolon ‘;’. Comparisons are implemented with the ‘==’ operator and can be used to compare numbers, strings or ip addresses. An ip address MUST be enclosed within two single quotes (eg. ‘192.168.0.7’). You can also use the ‘less than’ (‘<‘), ‘greater than’ (‘>’), ‘less or equal’ (‘<=’) and ‘greater or equal’ (‘>=’) operators. The lvalue of a comparison must be an offset (see later) Example:

if (DATA.data + 20 == “ettercap” && ip.ttl > 16) {

} Assignments are implemented with the ‘=’ operator and the lvalue can be an offset (see later). The rvalue can be a string, an integer or a hexadecimal value. Example:

ip.ttl = 0xff;

DATA.data + 7 = “ettercap NG”; You can also use the ‘inc’ and ‘dec’ operations on the packet fields. The operators used are ‘+=’ and ‘-=’. The rvalue can be an integer or a hexadecimal value. Example:

ip.ttl += 5;

 

      OFFSET DEFINITION

An offset is identified by a virtual pointer. In short words, an offset is a pointer to the packet buffer. The virtual pointer is a tuple <L, O, S>, where L is the iso/osi level, O is the offset in that level and S is the size of the virtual pointer. You can make algebraic operations on a virtual pointer and the result is still an offset. Specifying ‘vp + n’ will result in a new virtual pointer <L, O+n, S>. And this is perfectly legal, we have changed the internal offset of that level. Virtual pointers are in the form ‘name.field.subfield’. For example ‘ip.ttl’ is the virtual pointer for the Time To Live field in the IP header of a packet. It will be translated as <L=3, O=9, S=1>. Indeed it is the 9th byte of level 3 and its size is 1 byte. ‘ip.ttl + 1’ is the same as ‘ip.proto’ since the 10th byte of the IP header is the protocol encapsulated in the IP packet. The list of all supported virtual pointers is in the file etterfilter.tbl. You can add your own virtual pointers by adding a new table or modifying the existing ones. Refer to the comments at the beginning of the file for the syntax of etterfilter.tbl file.

 

      SCRIPTS FUNCTIONS

 

      search(where, what)

this function searches the string ‘what’ in the buffer ‘where’. The buffer can be either DATA.data or DECODED.data. The former is the payload at layer DATA (ontop TCP or UDP) as it is transmitted on the wire, the latter is the payload decoded/decrypted by dissectors.

So, if you want to search in an SSH connection, it is better to use ‘DECODED.data’ since ‘data’ will be encrypted.

The string ‘what’ can be binary. You have to escape it. example:

search(DATA.data, “\x41\x42\x43”)

 

      regex(where, regex)

this function will return true if the ‘regex’ has matched the buffer ‘where’. The considerations about ‘DECODED.data’ and ‘DATA.data’ mentioned for the function ‘search’ are the same for the regex function. NOTE: regex can be used only against a string buffer. example:

regex(DECODED.data, “.*login.*”)

 

      pcre_regex(where, pcre_regex … )

this function will evaluate a perl compatible regular expression. You can match against both DATA and DECODED, but if your expression modifies the buffer, it makes sense to operate only on DATA. The function accepts 2 or 3 parameters depending on the operation you want. The two parameter form is used only to match a pattern. The three parameter form means that you want to make a substitution. In both cases, the second parameter is the search string.

You can use $n in the replacement string. These placeholders are referred to the groups created in the search string. (e.g. pcre_regex(DATA.data, “^var1=([:digit:]*)&var2=([:digit:]*)”, “var1=$2&var2=$1”) will swap the value of var1 and var2).

NOTE: The pcre support is optional in ettercap and will be enabled only if you have the libpcre installed. The compiler will warn you if you try to compile a filter that contains pcre expressions but you don’t have libpcre. Use the -w option to suppress the warning. example:

pcre_regex(DATA.data, “.*foo$”)

pcre_regex(DATA.data, “([^ ]*) bar ([^ ]*)”, “foo $1 $2”)

 

      replace(what, with)

this function replaces the string ‘what’ with the string ‘with’. They can be binary string and must be escaped. The replacement is always performed in DATA.data since is the only payload which gets forwarded. The ‘DECODED.data’ buffer is used only internally and never reaches the wire. example:

replace(“ethercap”, “ettercap”)

 

      inject(what)

this function injects the content of the file ‘what’ after the packet being processed. It always injects in DATA.data. You can use it to replace the entire packet with a fake one using the drop() function right before the inject() command. In that case the filtering engine will drop the current packet and inject the fake one. example:

inject(“./fake_packet”)

 

      log(what, where)

this function dumps in the file ‘where’ the buffer ‘what’. No information is stored about the packet, only the payload is dumped. So you will see the stream in the file. If you want to log packets in a more enhanced mode, you need to use the ettercap -L option and analyze it with etterlog(8) .

The file ‘where’ must be writable to the user EC_UID (see etter.conf(5) ). example:

log(DECODED.data, “/tmp/interesting.log”)

 

      msg(message)

this function displays a message to the user in the User Messages window. It is useful to let the user know whether a particular filter has been successful or not. example:

msg(“Packet filtered successfully”)

 

      drop()

this function marks the packet “to be dropped”. The packet will not be forwarded to the real destination. example:

drop()

 

      kill()

this function kills the connection that owns the matched packet. If it is a TCP connection, a RST is sent to both sides of the connection. If it is an UDP connection, an ICMP PORT UNREACHABLE is sent to the source of the packet. example:

kill()

 

      exec(command)

this function executes a shell command. You have to provide the full path            to the command since it is executed without any environment. There is no way to determine if the command was successful or not. Furthermore, it is executed asynchronously since it is forked by the main process. example:

exec(“/bin/cat /tmp/foo >> /tmp/bar”)

 

      exit()

this function causes the filter engine to stop executing the code. It is useful to stop the execution of the script on some circumstance checked by an ‘if’ statement. example:

exit()

 

EXAMPLES

    Here are some examples of using etterfilter.

 

etterfilter filter.ecf -o filter.ef

Compiles the source filter.ecf into a binary filter.ef

 

AUTHORS

    Alberto Ornaghi (ALoR) <alor@users.sf.net>

    Marco Valleri (NaGA) <naga@antifork.org>

 

SEE ALSO

                “etter.filter.examples”

                “ettercap(8)” “etterlog(8)” “etter.conf(5)” “ettercap_curses(8)”

                “ettercap_plugins(8)”

 

Appendix B: Ettercap-plugins [6]

 

 

NAME

                ettercap-plugins NG-0.7.3 – A collection of plugins for ettercap

DESCRIPTION

Ettercap(8) supports loadable modules at runtime. They are called plugins and they come within the source tarball. They are automatically compiled if your system supports them or until you specify the –disable-plugins option to the configure script.

Some of older ettercap plugins (roper, banshee, and so on) have not been ported in the new version. By the way, you can achieve the same results by using new filtering engine.

If you use interactive mode, most plugins need to “Start Sniff” before using them.

           To have a list of plugins installed in your system do that command:

                ettercap -P list

                The following is a list of available plugins:

 

                arp_cop

It reports suspicious ARP activity by passively monitoring ARP requests/replies. It can report ARP posioning attempts, or simple IP-conflicts or IP-changes. If you build the initial host list the plugin will run more accurately. example : ettercap -TQP arp_cop //

 

                autoadd

It will automatically add new victims to the ARP poisoning mitm attack when they come up. It looks for ARP requests on the lan and when detected it will add the host to the victims list if it was specified in the TARGET. The host is added when an arp request is seen form it, since communicating hosts are alive 🙂

 

                chk_poison

It performs a check to see if the arp poisoning module of ettercap was successful. It sends spoofed ICMP echo packets to all the victims of the poisoning pretending to be each of the other targets. If we can catch an ICMP reply with our MAC address as destination it means that the poisoning between those two targets is successful. It checks both ways of each communication. This plugin makes sense only where poisoning makes sense. The test fails if you specify only one target in silent mode. You can’t run this plugin from command line because the poisoning process is not started yet. You have to launch it from the proper menu.

 

                dns_spoof

This plugin intercepts DNS query and reply with a spoofed answer. You can chose to which address the plugin has to reply by modifying the etter.dns file. The plugin intercepts A, PTR and MX request. If it was an A request, the name is searched in the file and the ip address is returned (you can use wildcards in the name). If if was a PTR request, the ip is searched in the file and the name is returned (except for those name containing a wildcard). In case of MX request a special reply is crafted. The host is resolved with a fake host ‘mail.host’ and the additional record contains the ip address of ‘mail.host’. The first address or name that matches is returned, so be careful with the order.

 

                dos_attack

This plugin runs a d.o.s. attack against a victim IP address. It first “scans” the victim to find open ports, then starts to flood these ports with SYN packets, using a “phantom” address as source IP. Then it uses fake ARP replies to intercept packets for the phantom host. When it receives SYN-ACK from the victim, it replies with an ACK packet creating an ESTABLISHED connection. You have to use a free IP address in your subnet to create the “phantom” host (you can use find_ip for this purpose). You can’t run this plugin in unoffensive mode.

This plugin is based on the original Naptha DoS attack (http://razor.bindview.com/publish/advisories/adv_NAPTHA.html) example : ettercap -TQP dos_attack

 

                dummy

                Only a template to demonstrate how to write a plugin.

 

                find_conn

Very simple plugin that listens for ARP requests to show you all the targets an host wants to talk to. It can also help you finding addresses in an unknown LAN. example : ettercap -TQzP find_conn ettercap -TQu -i eth0 -P find_conn

 

                find_ettercap

Try to identify ettercap packets sent on the LAN. It could be useful to detect if someone is using ettercap. Do not rely on it 100% since the tests are only on particular sequence/identification numbers.

 

                find_ip

Find the first unused IP address in the range specified by the user in the target list. Some other plugins (such as gre_relay) need an unused IP address of the LAN to create a “fake” host.    It can also be useful to obtain an IP address in an unknown LAN where there is no dhcp server. You can use find_conn to determine the IP addressing of the LAN, and then find_ip. You have to build host list to use this plugin so you can’t use it in unoffensive mode. If you don’t have an IP address for your interface, give it a bogus one (e.g. if the LAN is 192.168.0.0/24, use 10.0.0.1 to avoid conflicting IP), then launch this plugin specifying the subnet range. You can run it either from the command line or from the proper menu. example : ettercap -TQP find_ip // ettercap -TQP find_ip /192.168.0.1-254/

 

                finger

Uses the passive fingerprint capabilities to fingerprint a remote host. It does a connect() to the remote host to force the kernel to reply to the SYN with a SYN+ACK packet. The reply will be collected and the fingerprint is displayed. The connect() obey to the connect_timeout parameter in etter.conf(5) . You can specify a target on command-line or let the plugin ask the target host to be fingerprinted. You can also specify multiple target with the usual multi-target specification (see ettercap(8) ). if you specify multiple ports, all the ports will be tested on all the IPs. example : ettercap -TzP finger /192.168.0.1/22

                ettercap -TzP finger /192.168.0.1-50/22,23,25

 

                finger_submit

Use this plugin to submit a fingerprint to the ettercap website. If you found an unknown fingerprint, but you know for sure the operating system of the target, you can submit it so it will be inserted in the database in the next ettercap release. We need your help to increase the passive fingerprint database. Thank you very much. example : ettercap -TzP finger_submit

 

                gre_relay

This plugin can be used to sniff GRE-redirected remote traffic. The basic idea is to create a GRE tunnel that sends all the traffic on a router interface to the ettercap machine. The plugin will send back the GRE packets to the router, after ettercap “manipulation” (you can use “active” plugins such as smb_down, ssh decryption, filters, etc… on redirected traffic) It needs a “fake” host where the traffic has to be redirected to (to avoid kernel’s responses). The “fake” IP will be the tunnel endpoint. Gre_relay plugin will impersonate the “fake” host. To find an unused IP address for the “fake” host you can use find_ip plugin.   Based on the original Tunnelx technique by Anthony C. Zboralski published in http://www.phrack.org/show.php?p=56&a=10 by HERT.

 

                gw_discover

This plugin try to discover the gateway of the lan by sending TCP SYN packets to a remote host. The packet has the destination IP of a remote host and the destination mac address of a local host. If ettercap receives the SYN+ACK packet, the host which own the source mac address of the reply is the gatway. This operation is repeated for each host in the ‘host list’, so you need to have a valid host list before launching this plugin. example : ettercap -TP gw_discover /192.168.0.1-50/

               

                isolate

The isolate plugin will isolate an host form the LAN. It will poison the victim’s arp cache with its own mac address associated with all the host it tries to contact. This way the host will not be able to contact other hosts because the packet will never reach the wire.

You can specify all the host or only a group. the targets specification      work this way: the target1 is the victim and must be a single host, the target2 can be a range of addresses and represent the hosts that will be blocked to the victim. examples : ettercap -TzqP isolate /192.168.0.1/ //

                ettercap -TP isolate /192.168.0.1/ /192.168.0.2-30/

 

                link_type

It performs a check of the link type (hub or switch) by sending a spoofed ARP request and listening for replies. It needs at least one entry in the host list to perform the check. With two or more hosts the test will be more accurate. example : ettercap -TQP link_type /192.168.0.1/

                ettercap -TQP link_type //

 

                pptp_chapms1

It forces the pptp tunnel to negotiate MS-CHAPv1 authentication instead of MS-CHAPv2, that is usually easier to crack (for example with LC4). You have to be in the “middle” of the connection to use it successfully. It hooks the ppp dissector, so you have to keep them active.

 

                pptp_clear

Forces no compression/encryption for pptp tunnels during negotiation. It could fail if client (or the server) is configured to hang off the tunnel if no encryption is negotiated. You have to be in the “middle” of the connection to use it successfully. It hooks the ppp dissector, so you have to keep them active.

               

                pptp_pap

It forces the pptp tunnel to negotiate PAP (cleartext) authentication. It could fail if PAP is not supported, if pap_secret file is missing, or in case windows is configured with “authomatic use of domain account”. (It could fail for many other reasons too). You have to be in the “middle” of the connection to use it successfully. It hooks the ppp dissector, so you have to keep them active.

 

                pptp_reneg

Forces re-negotiation on an existing pptp tunnel. You can force re-negotiation for grabbing passwords already sent. Furthermore you can launch it to use pptp_pap, pptp_chapms1 or pptp_clear on existing tunnels (those plugins work only during negotiation phase). You have to be in the “middle” of the connection to use it successfully. It hooks the ppp dissector, so you have to keep them active.

 

                rand_flood

Floods the LAN with random MAC addresses. Some switches will fail open in repeating mode, facilitating sniffing. The delay between each packet is based on the port_steal_send_delay value in etter.conf.

                It is useful only on ethernet switches. example : ettercap -TP rand_flood

 

                remote_browser

It sends to the browser the URLs sniffed thru HTTP sessions. So you are able to see the webpages in real time. The command executed is configurable in the etter.conf(5) file. It sends to the browser only the GET requests and only for webpages, ignoring single request to images or other amenities. Don’t use it to view your own connection 🙂

 

                reply_arp

Simple arp responder. When it intercepts an arp request for a host in the targets’ lists, it replies with attacker’s MAC address. example : ettercap -TQzP reply_arp /192.168.0.1/

                ettercap -TQzP reply_arp //

 

                repoison_arp

It solicits poisoning packets after broadcast ARP requests (or replies) from a posioned host. For example: we are poisoning Group1 impersonating Host2. If Host2 makes a broadcast ARP request for Host3, it is possible that Group1 caches the right MAC address for Host2 contained in the ARP packet. This plugin re-poisons Group1 cache immediately after a legal broadcast ARP request (or reply).

                This plugin is effective only during an arp-posioning session.

In conjuction with reply_arp plugin, repoison_arp is a good support for standard arp-poisoning mitm method. example : ettercap -T -M arp:remote -P repoison_arp /192.168.0.10-20/ /192.168.0.1/

 

                scan_poisoner

Check if someone is poisoning between some host in the list and us. First of all it checks if two hosts in the list have the same mac address. It could mean that one of those is poisoning us pretending to be the other. It could generate many false-positives in a proxy-arp environment. You have to build hosts list to perform this check. After that, it sends icmp echo packets to each host in the list and checks if the source mac address of the reply differs from the address we have stored in the list for that ip. It could mean that someone is poisoning that host pretending to have our ip address and forwards intercepted packets to us. You can’t perform this active test in unoffensive mode. example : ettercap -TQP scan_poisoner //

 

                search_promisc

It tries to find if anyone is sniffing in promisc mode. It sends two different kinds of malformed arp request to each target in the host list and waits for replies. If a reply arrives from the target host, it’s more or less probable that this target has the NIC in promisc mode. It could generate false-positives. You can launch it either from the command line or from the plugin menu. Since it listens for arp replies it is better that you don’t use it while sending arp request. example : ettercap -TQP search_promisc /192.168.0.1/

                ettercap -TQP search_promisc //

 

                smb_clear

It forces the client to send smb password in clear-text by mangling protocol negotiation. You have to be in the “middle” of the connection to successfully use it. It hooks the smb dissector, so you have to keep it active. If you use it against a windows client it will probably result in a failure. Try it against a *nix smbclient 🙂    

 

                smb_down

It forces the client to not to use NTLM2 password exchange during smb authentication. This way, obtained hashes can be easily cracked by LC4. You have to be in the “middle” of the connection to successfully use it. It hooks the smb dissector, so you have to keep it active.

 

                stp_mangler

It sends spanning tree BPDUs pretending to be a switch with the highest priority. Once in the “root” of the spanning tree, ettercap can receive all the “unmanaged” network traffic.

                It is useful only against a group of switches running STP.

If there is another switch with the highest priority, try to manually decrease your MAC address before running it. example : ettercap -TP stp_mangler

 

SEE ALSO

“ettercap(8)” “ettercap_curses(8)” “etterlog(8)” “etterfilter(8)” “etter.conf(5)”

 

Answer Sheet Lab 12

 

Group Number:_____________

 

Member Names: ______________________   _______________________

 

 

Section 3.2. SSL Man-In-The-Middle

 

Q3.2.1.  What does the Windows ARP table show as the MAC address of the web server?  Is this correct?

 

 

 

 

Q3.2.2. How can you prevent ARP poisoning?

 

 

 

 

 

 

 

 

 

 

 

 

 

Q3.2.3.  After accepting the certificate, does the page load?

 

 

Q3.2.4.  How do the certificates certificate_valid.cer and certificate_forged.cer differ?  How are they similar?

 

 

 

 

 

 

 

 

 

 

 

 

Q3.2.5.  What is the significance of the victim using Ettercap’s certificate instead of the one from the SSL web server?  The information is encrypted anyway so what is the big deal?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Q3.2.6.  When you are surfing the web and get a message about a SSL certificate, do you normally just click “OK” and surf on?   Do you think that will change after this lab?

 

 

 

Q3.2.7.  How can you prevent SSL MITM attacks?

 


Section 4.2. Using an Ettercap filter

 

Q4.2.1.  What is different between the original google page and the one that is displayed after the googlefilter.filter was loaded?  How did this happen?

 

 

 

 

 

 

 

 

 

 

 

Section 5.2. DNS Spoofing With Ettercap

 

Q5.2.1. What happens when you try to go to a URL with ‘ece4112’ in it?  Why?

 

 

 

 

 

 

 

Q5.2.2. How is using Ettercap to do DNS spoofing better than just listening for DNS requests and replying to them?

 

 

 

 

 

 

 

 

 

Q5.2.3. What can be done to prevent DNS spoofing like this?

 


Section 5.3 Using the remote_browser Plugin

 

Q5.3.1.  How can the remote_browser plugin be useful for a hacker or administrator?

 

 

 

 

 

 

 

 

 

 

 

 

 

How long did it take you to complete this lab? Was it an appropriate length lab?

 

 

 

 

 

 

 

What corrections and/or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make minor corrections/suggestions. General suggestions like add tool xyz to do more capable scanning will not be awarded extras points even if the statement is totally true. Specific text that could be cut and pasted into this lab, completed exercises, and completed solutions may be awarded additional credit. Thus if tool xyz adds a capability or additional or better learning experience for future students here is what you need to do.  You should add that tool to the lab by writing new detailed lab instructions on where to get the tool, how to install it, how to run it, what exactly to do with it in our lab, example outputs, etc. You must prove with what you turn in that you actually did the lab improvement yourself. Screen shots and output hardcopy are a good way to demonstrate that you actually completed your suggested enhancements. The lab addition section must start with the form “laboratory Additions Cover Sheet” which may be found on the class web site.

 

 

Turn In Checklist

 

1)         Completed Answer Key