ETTERCAP
PART TWO
Ettercap Part 2
In the first part of this tutorial, we looked at the basic features of
ettercap, from general network sniffing to Man in the Middle attacks.
However, we only scratched the surface. In part two we will look at the
more advanced features, including ettercap's built in plugins, an
example of a few filters, along with one or two others, and how to
defend yourself against ettercap and other similar programs.
Plug-ins
Ettercap comes bundled with several very useful plugins. I'm not going
to go over them all, but I will show you several examples, and you
should be able to apply these to the others. The ones we will cover are;
* arp_cop
* chk_poison
* find_ettercap
* finger
* search_promic
first lets look at the plug-in selection screen, we can get there by
going to Plugins--> Manage the Plugins, or by pressing ctrl-p
Screen-Shot #1
Now, as you can see, we have the name of each of each of the plug-ins,
their version, and a brief description of what each one of them do. For
a complete list, and a better description of each, check here (warning:
PDF file). The first of the plugins that we are going to cover is
"arp_cop." So we will follow these steps, we are just going to select
out device (for me it would be ath0 or eth0 (or the name of your device
on windows). Now I am going to press ctrl-p and bring up the "manage
plugins" menu. Find arp_cop and double click it. In the info box on the
bottom you should see that it will say
arp_cop: plugin running...
Now we can go to Start-->Sniffing. Now ettercap will begin to
monitor the arp packets and the arp tables that are going through the
network, however without any kind of poisoning. If ettercap finds that
all the sudden one NIC is sending out arp packets consistent with arp
poisoning, then it will put an alert into the info box giving you that
NIC's IP address, and MAC address. It will not necessarily mean that
someone is doing something malicious, however it will point out
suspicious activity.
The next plugin is the one that I use the most, chk_poison. This plugin
doesn't require much explanation, you go through the steps in part 1 to
begin arp poisoning. Start your sniffing. Now go to the plugins menu,
and open up chk_poison. It will tell you if the arp poisoning was
successful and you are now in the middle sniffing all the traffic.
Again, it will be telling you all of this in the info box (sensing a
pattern?).
Screen-Shot #2
The number 3 plugin we are are going to look at is find ettercap
plugin. Treat it the same way as arp_cop, and it will go about doing
exactly what it sounds like, finding etterap on a network. It does this
by a couple of methods, 1st, acting like arp_cop (arp_cop is more
general though), and second is sniffing the types of packets, and the
headers on those packets, to find out if they are the same that
ettercap would use.
Finger is not always reliable, and kind of a pain in the ass, if you
need to fingerprint a host, I would suggest using nmap. If you are
unfamiliar with this program, I would HIGHLY recommend becoming
familiar with it. Nokia writes an excellent tutorial (in 5 parts,
covers alot) that you can find here;
http://tazforum.thetazzone.com/viewtopic.php?t=684.
GW_discover will scan the hosts that you picked up when you scanned,
and try to determine which IP address is the gateway if it has been
hidden in one way or another. This is great if you are looking for the
router to attack.
Search_promisc is a great plugin for finding any computer sniffing the
network in promiscuous mode, i.e., it will find
wireshark/tcpdump/ethereal/almost any other while they are not running
in silent mode. Usuaully this is not the default mode, so you should be
all set.
This should pretty much sum up which each of the plugins that I have
found most useful, but many others are useful as well, read the
documentation, play around with it, and if you can find a good use for
it, post it, and I'll enter it into the tutorial (giving you credit of
course). Next we get to look at the part of the tutorial that allows us
to do just about anything Smile
Filters
Filters in ettercap are, to put it simply, fairly amazing. They allow
you to do the simple, just look at TCP/UDP connections, to changing
what somebody sees on the webpage. This can be used in a humorous or
malicious way. In the example I will show you, we will be able to
change all the images on a web page into something else, Lets go and
take a look shall we?
First lets take a look at a simple ettercap filter;
if (ip.proto == TCP && tcp.dst == 80) {
if (search(DATA.data, "Accept-Encoding")) {
replace("Accept-Encoding", "Accept-Rubbish!");
# note: replacement string is same length as original string
msg("zapped Accept-Encoding!\n");
}
}
if (ip.proto == TCP && tcp.src == 80) {
replace("img src=", "img
src=\"http://www.irongeek.com/images/jollypwn.png\" ");
replace("IMG src=", "img
src=\"http://www.irongeek.com/images/jollypwn.png\" ");
msg("Filter Ran.\n");
}
**credit to IronGeek for the example!**
If you have coded before, you will be able to make pretty short work of
the code, and if you haven't coded before, this may not be the place to
start. But lets quickly walk through it;
* line-1 ) if its a TCP transmission on port 80 do the following;
* line 2 ) Look inside of the transmission, and accept the encoding (go
figure)
* line 3 ) replace accept encoding to accept-rubbish (to be honest not
quite sure about this line, perhaps someone could clarify it for me?
* line 4 ) a note by the programmer
* line 5) put a message in the info box on ettercap that says "zapped
accept-encoding"
* line 7 ) same as line 1
* line 8 ) replace string one with string 2
* line 9 ) same thing
* line 10 ) place another message in the info box
This code basically changes all the <img> tags in a webpage to a
string of the script authors choice in this case, its a jolly roger,
but really it could be anything.
Now lets take a look at all of the commands that we have to our
disposal while writing a filter;
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()
Using these commands, we can manipulate just about any packet that
comes through us destined for just about anywhere. If you write some
interesting scrips, let me know, I'll make sure to give you credit and
post them with this tutorial!
**screenshot links not up yet, more examples of filters to come, stay
tuned**
Original Tutorial
by jaymill230 for TheTAZZone-TAZForum
Originally posted on April 26th, 2007 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.