"Fossies" - the Fresh Open Source Software Archive
Member "ettercap-0.8.3.1/README" (1 Aug 2020, 19660 Bytes) of package /linux/privat/ettercap-0.8.3.1.tar.gz:
As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard
) with prefixed line numbers.
Alternatively you can here view
the uninterpreted source code file.
See also the latest Fossies "Diffs"
side-by-side code changes report for "README": 0.8.3_vs_0.8.3.1
5 @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@
6 @@ @@@ @@@ @@ @@ @@ @@ @@ @@ @@ @@
7 @@@@@@ @@@ @@@ @@@@@@ @@@@@@ @@ @@@@@@@ @@@@@@
8 @@ @@@ @@@ @@ @@ @@ @@ @@ @@ @@
9 @@@@@@@ @@@ @@@ @@@@@@@ @@ @@@ @@@@@@@ @@ @@ @@
11 A suite for man in the middle attacks
13 Copyright 2001-2019 The Ettercap Dev Team
18 Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht
19 oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist
20 and lsat ltteer are in the rghit pclae. The rset can be a toatl mses and
21 you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed
22 ervey lteter by it slef but the wrod as a wlohe and the biran fguiers it
23 out aynawy.
25 ... so please excuse us for every typo in the documentation, man pages or
26 code, btw fixes and patches are welcome.
32 R E Q U I R E D P R O G R A M S
35 C compiler
37 flex (or other lex-compatible parser generator) for *.l files
39 bison (or other yacc-compatible parser generator) for *.y files
41 cmake (build tool)
44 R E Q U I R E D L I B R A R I E S
49 - libpcap >= 0.8.1
50 - libnet >= 220.127.116.11 (>= 1.1.5 for IPv6 support)
51 - openssl >= 0.9.7
52 - libpthread
53 - zlib
54 - libgeoip
55 - CMake 2.8
56 - Curl >= 7.26.0 to build SSLStrip plugin
57 If you don't want to enable SSLStrip plugin you have to disable it.
58 (more information about disabling a plugin in the README.GIT file)
61 To avoid use of our internal strlcat and strlcpy implementation:
62 - libbsd
64 To enable PDF documentation generation (enable via ENABLE_PDF_DOCS=On):
65 - groff
67 To enable plugins:
68 - libltdl (part of libtool)
70 To have perl regexp in the filters:
71 - libpcre
73 For the cursed GUI:
74 - ncurses >= 5.3
76 For the GTK+ GUI:
77 - Glib >= 2.2.2
78 - Gtk+3 >= 3.12.0 (recommended >= 3.22.0)
79 - Atk >= 1.2.4
80 - Pango >= 1.2.3
82 If you are running on debian, or any debian based distro you can install
83 the required dependencies by running:
85 apt-get install debhelper bison check cmake flex groff libbsd-dev \
86 libcurl4-openssl-dev libgeoip-dev libgtk-3-dev libltdl-dev libluajit-5.1-dev \
87 libncurses5-dev libnet1-dev libpcap-dev libpcre3-dev libssl-dev
93 see LICENSE file for details...
99 Alberto Ornaghi (ALoR) <firstname.lastname@example.org>
101 Marco Valleri (NaGA) <email@example.com>
103 Emilio Escobar (exfil) <firstname.lastname@example.org>
105 Eric Milam (J0hnnyBrav0) <email@example.com>
107 Gianfranco Costamagna (LocutusOfBorg) <firstname.lastname@example.org>
109 Alexander Koeppe (koeppea) <format_c AT online DOT de>
115 The easiest way to compile ettercap is in the form:
116 mkdir build
117 cd build
118 cmake ..
119 (Use ccmake . to change options such as disabling IPv6 support, add
120 plugins support, etc).
121 make install
123 read INSTALL for further details... and README.PLATFORMS for any issue
124 regarding your operating system.
127 HOW TO USE IT
130 You can choose between 3 User Interfaces: Text mode, Curses, GTK.
132 Please read the man pages ettercap(8) and ettercap_curses(8) to learn how
133 to use ettercap.
136 TECHNICAL PAPER
139 THE HOST LIST
141 Sending one ARP REQUEST for each ip in the lan (looking at the current ip
142 and netmask), it is possible to get the ARP REPLIES and then make the
143 list of the hosts that are responding on the lan. With this method even
144 windows hosts, reply to the call-for-reply (they don't reply on
146 Be very careful if the netmask is a class B (255.255.0.0) because ettercap
147 will send 255*255 = 65025 arp requests (the default delay between two
148 requests is 1 millisecond, can be configured in etter.conf)
151 UNIFIED SNIFFING
153 Ettercap NG uses the unified sniffing method which is the base for all the
154 attacks. The kernel ip forwarding is always disabled and this task is
155 accomplished by ettercap itself. Packet that needs to be forwarded are packets
156 with destination mac address equal to the attacker's one, but with different ip
157 address. Those packets are re-sent back to the wire to the real destination.
158 This way, you can plug in various mitm attacks at a time. You can even use
159 external attacker/poisoner, they only have to redirect packets to ettercap's
160 host and the game is over ;)
163 BRIDGED SNIFFING
165 Uses two network interfaces and forwards the traffic between them while performing
166 sniffing and content filtrating. This sniffing method is very stealthy as there
167 is no way to to detect that someone is in the middle. You can look at this as a layer
168 one attack. Don't use it on gateways or it will transform your gateway into a bridge.
170 HINT: You can use the content filtering engine to drop packets that should not pass.
171 This way ettercap will work as an inline IPS ;)
174 ARP POISONING ATTACK
176 When you select this method, ettercap will poison the arp cache of the
177 two hosts, identifying itself as the other host respectively (see the
178 next section for this).
179 Once the arp caches are poisoned, the two hosts start the connection, but
180 their packets will be sent to us, and we will record them and, next,
181 forward them to the right side of the connection. So the connection is
182 transparent to the victims, not arguing that they are sniffed. The only
183 method to discover that there is a man-in-the-middle in your connection, is
184 to watch at the arp cache and check if there are two hosts with the same
185 mac address!
186 That is how we discover if there are others poisoning the arp cache
187 in our LAN, thus being warned, that our traffic is under control! =)
189 HOST 1 - - - - - - - - - - - - - - - - - - - -> HOST 2
190 (poisoned) (poisoned)
191 | ^
192 | |
193 ------------> ATTACKER HOST ------------------
194 ( ettercap )
197 - - - -> the logic connection
198 -------> the real one
201 The arp protocol has an intrinsic insecurity. In order to reduce the
202 traffic on the cable, it will insert an entry in the arp cache even if it
203 wasn't requested. In other words, EVERY arp reply that goes on the wire
204 will be inserted in the arp table.
205 So, we take advantage of this "feature", sending fake arp replies to the two
206 hosts we will sniff. In this reply we will tell that the mac address of the
207 second host is the one hard-coded on OUR ethernet card. This host will now
208 send packets that should go to the first host, to us, because he carries
209 our mac address.
210 The same process is done for the first host, in inverse manner, so we have
211 a perfect man-in-the-middle connection between the two hosts, legally
212 receiving their packets!!
216 HOST 1: mac: 01:01:01:01:01:01 ATTACKER HOST:
217 ip: 192.168.0.1 mac: 03:03:03:03:03:03
218 ip: 192.168.0.3
220 HOST 2: mac: 02:02:02:02:02:02
221 ip: 192.168.0.2
224 we send arp replys to:
226 HOST 1 telling that 192.168.0.2 is on 03:03:03:03:03:03
227 HOST 2 telling that 192.168.0.1 is on 03:03:03:03:03:03
229 now they are poisoned !! they will send their packets to us !
230 then if receive packets from:
232 HOST 1 we will forward to 02:02:02:02:02:02
233 HOST 2 we will forward to 01:01:01:01:01:01
235 simple, isn't it ?
237 *** LINUX KERNEL 2.4.x ISSUE ***
239 In the latest release of the linux kernel we can find in :
242 /* Unsolicited ARP is not accepted by default.
243 It is possible, that this option should be enabled for some
244 devices (strip is candidate)
247 these kernels use a special neighbor system to prevent unsolicited arp
248 replies (what ettercap sends to the victim).
249 Good gracious, is ettercap unusable with that kernel ? the answer is NO !
250 let's view why... in the same source code we find:
253 * Process entry. The idea here is we want to send a reply if it is a
254 * request for us or if it is a request for someone else that we hold
255 * a proxy for. We want to add an entry to our cache if it is a reply
256 * to us or if it is a request for our address.
257 * (The assumption for this last is that if someone is requesting our
258 * address, they are probably intending to talk to us, so it saves time
259 * if we cache their address. Their address is also probably not in
260 * our cache, since ours is not in their cache.)
262 * Putting this another way, we only care about replies if they are to
263 * us, in which case we add them to the cache. For requests, we care
264 * about those for us and those for our proxies. We reply to both,
265 * and in the case of requests for us we add the requester to the arp
266 * cache.
269 so, if the kernel receives a REQUEST it will cache the host...
270 what does that mean ? if ettercap sends spoofed REQUESTS instead of
271 REPLIES the kernel will cache them ? the answer is YES !!
273 ettercap 0.6.0 and later has this new ARP REQUEST POISONING method.
274 it will alternate request and replies on poisoning because other OS doesn't
275 have this "feature"...
278 *** SOLARIS ISSUE ***
280 Solaris will not cache a reply if it isn't already in the cache.
281 The trick is simple, before poisoning, ettercap sends a spoofed ICMP
282 ECHO_REQUEST to the host, it has to reply on it and it will make an arp
283 entry for the spoofed host. Then we can begin to poison as always, the
284 entry is now in the cache...
287 ICMP REDIRECTION
289 This attack implements ICMP redirection. It sends a spoofed icmp redirect
290 message to the hosts in the lan pretending to be a best route for internet.
291 All connections to internet will be redirected to the attacker which, in turn,
292 will forward them to the real gateway. The resulting attack is an HALF-DUPLEX
293 mitm. Only the client is redirected, since the gateway will not accept redirect
294 messages for a directly connected network.
297 DHCP SPOOFING
299 This attack implements DHCP spoofing. It pretends to be a DHCP server and try
300 to win the race condition with the real one to force the client to accept
301 replies from it. This way the attacker is able to manipulate the GW parameter and
302 hijack all the outgoing traffic generated by the clients.
303 The resulting attack is an HALF-DUPLEX mitm.
306 PORT STEALING
308 This technique is useful to sniff in a switched environment when ARP poisoning
309 is not effective (for example where static mapped ARPs are used).
310 It floods the LAN with ARP packets. The destination MAC address of each
311 "stealing" packet is the same as the attacker's one (other NICs won't see these
312 packets), the source MAC address will be one of the MACs of the victims.
313 This process "steals" the switch's port of each victim.
314 Using low delays, packets destined to "stolen" MAC addresses will be received
315 by the attacker, winning the race condition with the real port owner.
316 When the attacker receives packets for "stolen" hosts, it stops the flooding
317 process and performs an ARP request for the real destination of the packet.
318 When it receives the ARP reply it's sure that the victim has "taken back" his
319 port, so ettercap can re-send the packet to the destination as is.
320 Now we can re-start the flooding process waiting for new packets.
323 CHARACTERS INJECTION
325 We have stated that the packets are for us...
326 And the packets will not be received by destination until we forward them.
327 But what happens if we change them?
328 Yes, they reach destination with our modifications.
329 We can modify, add, delete the content of these packets, by simply
330 recalculating the checksum and substituting them on the traffic.
331 But we can do also more: we can insert packets in the connection.
332 We forge our packets with the right sequence and acknowledgement number and
333 send them to the desired host. When the next packets will pass through us
334 we simply subtract or add the sequence number with the amount of data we
335 have injected till the connection is alive, preventing the connection to be
336 rejected (this until we close ettercap, who maintains sequence numbers
337 correct, after program exit, the connection must be RESET or all future
338 traffic would be rejected, blocking the source workstation network).
340 NOTE: Injector supports escape sequences. you can make multi-line injection
341 eg: "this on line one \n this on line two \n and so on..."
342 eg: "this in hex mode: \x65\x6c\x6c\x65"
343 eg: "this in oct mode: \101\108\108\101"
345 NOTE: remember to terminate your injection with \r\n if you want to inject
346 command to the server.
349 SSH1 MAN-IN-THE-MIDDLE
351 When the connection starts (remember that we are the master-of-packets, all
352 packets go through ettercap) we substitute the server public key with one
353 generated on the fly and save it in a list so we can remember that this
354 server has been poisoned before.
355 Then the client send the packet containing the session key ciphered with
356 our key, so we are able to decipher it and sniff the real 3DES session key.
357 Now we encrypt the packet with the correct server public key and forward it
358 to the SSH daemon.
359 The connection is established normally, but we have the session key !!
360 Now we can decrypt all the traffic and sit down watching the stream !
361 The connection will remain active even if we exit from ettercap, because
362 ettercap doesn't proxy it (like dsniff). After the exchange of the keys,
363 ettercap is only a spectator... ;)
366 PACKET FILTERING
368 Like character injection, we can modify the packets payload and replace
369 the right sequence and acknowledgement number if needed.
370 With the integrated filtering engine you can program your own filters
371 to make the best filter for your aims.
372 A scripting languages is used to make filters source that must be compiled
373 with etterfilter(8) in order to be used by ettercap.
376 PASSIVE SCANNING OF THE LAN
378 This feature is very useful if you want to know the topology of the lan but
379 you don't want to send any packet on it. In this way the scan is done entirely
380 by sniffing packets and extracting useful information from them.
381 This scan will let you know the hosts in the lan (it watches ARP request), the
382 Operating System of the hosts (it uses passive os fingerprint... see next
383 section), the open ports of an host (looking the SYN+ACK packet), the gateway,
384 the routers or hosts acting as a router (it watches ICMP messages).
385 As a passive method it is useless on a switched lan (because it can make a
386 topology only of the host that are connecting to you), but if you put it on a
387 gateway and let it run for hours or days, it will make a complete report of
388 the hosts in the lan.
391 PASSIVE OS FINGERPRINT
393 The main idea is to analyze the passive information coming from a host
394 when it makes or receives connections with other hosts. This information
395 is enough to detect the OS and the running services of the host.
396 In this scenario, we look at SYN and SYN+ACK packet and collect some
397 interesting info from them:
398 Window Size: the TCP header field
399 MSS: the TCP option Maximum Segment Size (can be present or not)
400 TTL: the IP header field Time To Live (rounded to the next power of 2)
401 Window Scale: the TCP option indicating the Scale
402 SACK: the TCP option for the Selective ACK
403 NOP: if the TCP options contain a NOP
404 DF: the IP header field Don't Fragment
405 TIMESTAMP: if the TCP timestamp option is enabled
406 and obviously the type of the packet (SYN or SYN+ACK)
408 The database contains different fingerprints for each type of packet
409 because some OSes have different fingerprints from SYN to SYN+ACK.
410 Obviously the SYN fingerprint is more reliable, because the SYN+ACK is
411 influenced by the SYN (if a SYN doesn't contain a SACK the SYN+ACK will not
412 have the SACK option even if the host support it). So while collecting
413 information off the lan, if we receive a SYN+ACK we mark the OS of that
414 host as temporary and when we receive a SYN we confirm that.
415 Fingerprints ending with an ":A" are less reliable... this is
416 because some OS identification may change during the gathering process.
418 The SYN+ACK packets are also used to discover the open ports of a host.
419 (see next section)
421 The interesting thing is that firewalls, gateways and NAT are transparent to
422 passive OS detection. So collecting info for the LAN will let you know info
423 even for remote hosts. Only proxies aren't transparent because they make a
424 new connection to the target.
426 Our fingerprint database has to be enlarged, so if you find a host with an
427 unknown fingerprint and you know for sure the OS of that host, please mail
428 us <email@example.com> the fingerprint and the OS, we will insert
429 in the database.
432 OPEN PORTS
434 Open ports are identified by looking for SYN+ACK packets.
435 If a SYN+ACK comes from a port, it is for sure open, except for the
436 channel command of FTP protocol, for that reason SYN+ACK going to port 20
437 are not used to indicate a open port.
438 For the udp ports the question is a little bit difficult because no SYN or
439 ACK packet are present in the udp protocol, so ettercap assumes that a udp
440 port < 1024 that sends packets is opened. We know that in this way we cannot
441 discover open ports > 1024 but they can go undetected as open when a client
442 sends packet to a server.
445 GATEWAY AND ROUTERS
447 The gateway is simply recognized looking at IP packet with a non local ip
448 ( checking the netmask ). If a non local IP is found, ettercap look at the
449 ethernet address (MAC) and store it as the gateway mac address, then it
450 search for it in the list and mark the corresponding ip as the gateway.
452 Looking in the ICMP messages we can rely that if a host sends a
453 TTL-exceeded or a redirect messages it is a router or an host acting as it.