============================================================================ ettercap 0.6.3.1 2001-12-13 ============================================================================ Even if blessed with a feeble intelligence they are cruel and smart... @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@@@@@@ @@ @@@ @@@ @@ @@ @@ @@ @@ @@ @@ @@ @@@@@@ @@@ @@@ @@@@@@ @@@@@@ @@ @@@@@@@ @@@@@@ @@ @@@ @@@ @@ @@ @@ @@ @@ @@ @@ @@@@@@@ @@@ @@@ @@@@@@@ @@ @@@ @@@@@@@ @@ @@ @@ Multi purpose sniffer/interceptor Required Libraries: none ;) (optionally ncurses) Optional Libraries: openssl (if you want ssh support) Installation: configure make make install (optional) make plug-ins make plug-ins_install (if you are lazy, just run) make complete_install ============================================================================ INTRO ============================================================================ Kiddie: A friend of mine told me that it is possible to sniff on a LAN... so I bought a switch ;) NaGoR: mmhhh.... Kiddie: Now my LAN is SECURE ! you can't sniff my packets... ah ah ah NaGoR: are you sure ? look at ettercap doing its work... Kiddie: Oh my god... it sniffs all my traffic !! I will use only ciphered connections on my LAN, so ettercap can't sniff them ! ah ah ah NaGoR: mmhhh.... Kiddie: Now I'm using SSH. My LAN is SECURE ! NaGoR: are you sure ? look at ettercap doing its work... Kiddie: shit !! grrrr... "a false sense of security, is worse than insecurity" -- Steve Gibson hey folks... wake up ! the net is NOT secure !! ettercap demonstrates that now is the time to encourage research on internet protocols to make them more secure. ============================================================================ LICENSE ============================================================================ GNU GENERAL PUBLIC LICENSE. see COPYING for details... ============================================================================ AUTHORS ============================================================================ Alberto Ornaghi (ALoR) Marco Valleri (NaGA) ============================================================================ TABLE OF CONTENTS ============================================================================ 1. DISCLAIMER............................................sez. 1 2. INSTALLATION..........................................sez. 2 3. HOW TO USE IT.........................................sez. 3 3.1 ncurses interface 3.2 command line 4. TROUBLESHOOTING.......................................sez 4 common problems solved (READ THIS BEFORE MAIL US) 5. TECHNICAL PAPER.......................................sez 5 5.1 The host list 5.2 IP based sniffing 5.3 MAC based sniffing 5.4 ARP based sniffing 5.4.1 arp poisoning 5.4.1.1 public arp 5.4.1.2 smart public arp 5.4.2 characters injection 5.4.3 active protocol dissection 5.4.4 SSH1 man-in-the-middle 5.4.5 packet filtering 5.5 Passive scanning of the LAN 5.5.1 passive os fingerprint 5.5.2 open ports 5.5.3 gateways and routers 6. PLUG-INS..............................................sez. 6 7. USELESS INFORMATION...................................sez. 7 ============================================================================ 1> DISCLAIMER ============================================================================ This software is provided "as is" and without any expressed or implied warranties, including, without limitation, the implied warranties of merchantability and fitness for any particular purpose. ============================================================================ 2> INSTALLATION ============================================================================ The easiest way to compile ettercap is in the form: ./configure make make install Now you should be able to run ettercap (default location is /usr/local/bin) There are a lot of useful options in configure: try using --help. If you'd like to suid ettercap, thus enabling other users, and not only root, to use the program, use --enable-suid before applying suid to ettercap with chmod, otherwise it would drop the applied suid. If you have problems with plug-ins, disable them by using --disable-plugins If you have installed OpenSSL in a different DIR use --with-openssl=DIR If you get an error linking OpenSSL with ettercap, try recompiling OpenSSL with "Config shared && make && make install" (on my box it worked ;) ) If you still have difficulties, send an e-mail message one of the authors (alor@users.sourceforge.net or crwm@freemail.it). The sourceforge ettercap homesite could also contain useful information, latest bug fixes and updated versions (http://ettercap.sourceforge.net). Bug reports are welcome. Please report problems in the configure/make process by including a copy of config.status, config.cache and config.log, as well as the pertinent compiler diagnostics. If you have problems in the program, please configure with --enable-debug and send also a copy of ettercap_debug.log and a short description of your configuration (eg. kernel and glibc version) when reporting a sigfault or other strange behaviors. ============================================================================ 3> HOW TO USE IT ============================================================================ There are two main interfaces available, black and white text-mode and a colored ncurses based character mode! 3.1 NCURSES INTERFACE Let's start showing you the latter one: If ettercap is invoked without options (see later on, for the command line options) it will run the ncurses interface (a short delay to scan your LAN may be noticed =). The main window is divided in 3 subsections: top, middle and bottom. In the top window there is the connection diagram, displaying the two machines to sniff or to connect and operate to. Below you will see the list of known hosts in the current LAN (with hub or switch) that you can reach: select a couple to sniff them. The two identical columns let you choose the said couple: select with the arrow keys an entry representing an ip of an active machine ([enter] will do this job =) on the left. Then switch to the second column on the right with [tab], and move as usual to select the second ip. This will represent the traffic route you would like to sniff (and eventually connect/poison). Obviously you cannot select the same source and destination, but you are in any case forced to not select your IP. In the bottom window, there is a sort of status bar, giving you additional information about currently selected objects, current status and eventually other important hints. There are also a lot of other nifty options that are selectable at this point, first of all the 'p' plug-in feature (these are separate features, externally programmed in this project, covering a vast number of applications, not displayable here: there is a special README-PLUGIN for this). Or the ability to inspect with the 'c' key, if there is an other "evil" program in your LAN running, and thus alerting you of possible data interception. But remember that throughout all the stages of the program YOU CAN ALWAYS PRESS 'H' FOR HELP, and a nice help window will show up and list you the currently available keys! These should be self-explanatory help windows, so there is no need in reading this sections here, but.. in case. You'll notice that the top window will update while selecting source and destination ip, and finally show the current status scheme if you connect or sniff (respectively pressing 'a' and 's' or 'm') IP Based sniffing filters connections looking in the IP header for matching IPs. This is the old style, classic method performed by most programs. MAC Based sniffing filters connections looking in ETH header for matching MACs. This is useful if you want to sniff connections from your local host and a remote host through your gateway (simply selecting your host and your gateway as source and destination). Finally there is the connect option, as said, that lets you, if your computer results connected to a switched LAN, poison the ARP cache permitting you to sniff the traffic on your local net as if you where on a network with an hub. With this option you can specify one or two host. If you select only one host you'll enter the PublicARP mode and you will overtake the selected IP with yours. If you specify both hosts you will enter the ARPBased Mode that allows you to view all the bidirectional traffic between the two hosts. CONNECTIONS LIST: In any case, now you enter the second stage: the central window now will list any active connections between the two sources IPs. Eventually open connections will show up, and you can select them as usual, allowing you to enter the third stage: the actual sniff! =) In the meantime you can look at the status of the connections (active, closed, etc) and see what type of traffic/port is used (ftp, ssh, web, etc). It is also possible to kill an active connection of any type. If the application protocol is supported by ettercap you can see, in the bottom window, some useful information about the highlighted connection, such as USER and PASSWORD used for interactive sessions. (this information can be dumped to a file simply hitting the 'l' key) If you used ARPBased mode you can also start ACTIVE PROTOCOL DISSECTION, that allows you to view particular ciphered protocols like ssh. PACKET FACTORY: with 'x' you can create your own packet from ethernet layer to application level. By default the field of the packet factory form are filled with the current highlighted connection properties. The same can be done in the host list (the first interface) but now the field is not autocompleted if you don't select a target host. All the field can be modified as you want and for non supported protocol there is the possibility to build a raw header made up of hex string. example: assume that we want to forge a RIP packet: we fill the forms until UDP header (port 520) and in the payload we write "\x01\x02\x00\x00\xFF\xFF\x00\x02here the pass" we have built the RIP header by hex sequences... SNIFFING: Now assume you selected an active connection: two sub-windows appear in the main one. They show source packets passing through your computer before reaching the destination, you sniff traffic without them noticing it! There are different visualization options here: the type of stream can be hex ('x' key), ascii ('a' key) or text only ('t' key) that strips out all the unreadable chars (useful with unicode protocols). Some decoders needs the ACTIVE PROTOCOL DISSECTION to be ON. You can also specify to suspend the stream of data (only prevents their visualization, in reality they go forward in background) as a sort of scroll-lock (press 's' key), for better data-analysis. Finally, there is also a very cool feature: INJECT. With the 'i' key you can also inject some chars in the traffic, choosing the direction, being able to add commands to the stream (i.e. you could sniff a telnet session and also being able to transmit some commands to the machine connected to. Like "ls" or whatever you want, and they have absolutely effect as if originated by the source! The same way you could generate fake output on the originating machine, not responding to the real output). NOTE: Injector supports escape sequences. you can perform multi-line injection. NOTE: remember to terminate your injection with \r\n if you want to inject command to the server. Last, but not least, PACKET FILTERING: With the 'f' key a form is displayed asking you to set up a filter. Pay attention on the active window, because source and dest filter are different. You can set up a filter that searchs for a particular string (even hex) in the TCP or UDP payload and replace it with yours or drop the entire packet. Available commands while in the filtering form: F10 or ESC -- exit the form ^N -- go to next field ^P -- go to previous field Home -- go to first field End -- go to last field ^L -- go to field to left ^R -- go to field to right ^U -- move upward to field ^D -- move downward to field ^W -- go to next word ^B -- go to previous word ^S -- go to start of field ^E -- go to end of field ^H -- delete previous char ^Y -- delete line ^G -- delete current word ^C -- clear to end of line ^K -- clear to end of field ^X -- clear field ^] or Ins -- toggle insert mode For a detailed explanation for "how to filter a connection" see sect. 5.4.5 LOGGING: There is also an option to log all these beautiful data streams to a file, just press 'l', then read it down or pass it through to an automated script filter with calm. You can also set up a filter with the rule "Log" and only the packet matching the criteria will be logged to the file. As you will notice, using the tool in visual mode will be simpler when trying it on run than by reading these instructions.. help is also a good resource to count on while operating (simply hit 'h'). 3.2 COMMAND LINE Well here there are two classic commands that will display help. Launching ettercap with the --help switch and invoking our man page (man ettercap ;). NOTE: Some features are available only from visual interface. - Packet factory - Injection Starting in non interactive mode (-N) there are also some features available that are bound to the interactive mode: you can activate a little help line and change visualization mode on the fly (between hex and ascii for example) In the same way it is possible to set up a lot of options from the command line and see them in interactive mode already set and started. Now there is also the possibility to shorten command usage, by specifying one or more hosts to sniff (if you are in silent mode, also one or none is possible by setting -z option: like sniffit that sniffs from everywhere =) Example: ettercap -Nsz (sniff data from every ip) ettercap -NCsz (collect only users and passwords from every ip) ettercap -NCsz ghibli meltemi (collect only from "ghibli" to "meltemi") NOTE: if you had started in interactive mode (without -N) it would have been necessary to specify 'r' to refresh the ip host list if you returned with 'q' to the first interface, since no list has been generated at the beginning due to the -z option. ex: ettercap -zs ghibli meltemi or ettercap -zm 00:A0:24:4C:00:F9 00:A0:24:36:00:C2 Ok, that's all.. Have fun and await the next versions, including ssh handling, you could play tricks on your friends, especially if they are the ones who believe that ssh is an absolutely not-sniffable and cryptographically unbreakable thing, better yet if they also believe in switches doing their job! =) ============================================================================ 4> TROUBLESHOOTING ============================================================================ There are really a lot of things that could happen to you after installing this proggy. Don't blame us in case of accidents or hours spent trying to compile etc.. Until we reach a *very* stable version there will be no troubleshooting section, which would be too large and infeasible to write down and do the necessary spread out betatests. But we'll do our best, try to compile on lots of machines, port it as much as possible, and clean up everything. For now the main aspect was to write down base ideas and see them work. When the main skeleton is completed there will be a lot of fine tune. The best thing to do if you need support or help in compiling is to READ THE FORUM ON ETTERCAP WEBSITE. Here you can find common solutions for many problems. Then we will write down a sort of FAQ and a problem resolve list or todos here in this section. RPM VERSION: We'd like to know if you are experiencing any problems when installing the rpm binary version of ettercap, including ncurses, which can easily be miss-detected: simply try to add --nodeps to the rpm line. COMPILING WITH OPENSSL: Ettercap needs the shared version of OpenSSL so if you experience a problem linking ettercap try recompiling OpenSSL with: "config shared && make && make install" then edit the /etc/ld.so.conf and add the installed path. then run "ldconfig" START UP TOO SLOW: if the "Building host list for netmask 255.255.255.0, please wait..." message is displayed for more than 5-10 seconds, probably your gethostbyaddr() is too slow resolving domains, so try starting with -d this option prevent the resolution of the IPs. ============================================================================ 5> TECHNICAL PAPER ============================================================================ 5.1 THE HOST LIST When ettercap starts it makes the list of the hosts that are on the lan. Sending one ARP REQUEST for each ip in the lan (looking at the current ip and netmask), it is possible to get the ARP REPLIES and than make the list of the hosts that are responding on the lan. With this method even windows hosts, reply to the call-for-reply (they don't reply on broadcast-ping). Be very careful if the netmask is a class B (255.255.0.0) because ettercap will send 255*255 = 65025 arp requests, it takes more than a minute !! (the default delay between two requests is 1 millisecond) 5.2 IP BASED SNIFFING This is the "old style" sniffing mode. It puts the network interface in promisc mode and then sniffs all packets matching the ip filter. If you are using the ncurses interface, the ip filter is made up of: ip source, port source, ip dest, port dest; in both the directions of the connection. Instead if using the command line, you can make a personalized ip filter. You can specify only the source, only the dest or both. each with or without an associated port. Examples: ettercap -N -s ghibli ettercap -N -s ghibli:23 the first will sniff all the connections to the host "ghibli" the second only those which are on the port 23 ettercap -N -s ghibli meltemi ettercap -N -s ghibli:23 meltemi ettercap -N -s ANY:23 the first will sniff all the connections between "ghibli" and "meltemi" the second only those which are on ghibli:23 coming from "meltemi" the third ANY host but on port 23 (telnet) 5.3 MAC BASED SNIFFING It puts the network interface in promisc mode and then sniffs all the packets that match the mac filter. The mac filter is made up giving the IPs of the two hosts. Ettercap will scan the host list and associates the correct mac address to the filter. In this way specifying the gateway's ip and an host's ip, you will get all the connections between the host and the Internet. Examples: assuming that "meltemi" is the gateway to internet. ettercap -N -m ghibli meltemi this will return all the connections that "ghibli" makes to remote hosts. 5.4 ARP BASED SNIFFING This method doesn't put the interface in promiscuous mode. It isn't necessary because the packets will be sent to us! :) The switch will forward the packets to us, so we have a good method for sniffing in switched LANs. Let's view how this is possible: when you select this method, ettercap will poison the arp cache of the two hosts, identifying itself as the other host respectively (see the next section for this). Once the arp caches are poisoned, the two hosts start the connection, but their packets will be sent to us, and we will record them and, next, forward them to the right side of the connection. So the connection is transparent to the victims, not arguing that they are sniffed. The only method to discover that there is a man-in-the-middle in your connection, is to watch at the arp cache and check if there are two hosts with the same mac address! That is how we discover if there are others poisoning the arp cache in our LAN, thus being warned, that our traffic is under control! =) HOST 1 - - - - - - - - - - - - - - - - - - - -> HOST 2 (poisoned) (poisoned) | ^ | | ------------> ATTACKER HOST ------------------ ( ettercap ) Legenda: - - - -> the logic connection -------> the real one Ok, cool! Though, how can I poison the arp cache ? 5.4.1 ARP POISONING The arp protocol has an intrinsic insecurity. In order to reduce the traffic on the cable, it will insert an entry in the arp cache even if it wasn't requested. In other words, EVERY arp reply that goes on the wire will be inserted in the arp table. So, we take advantage of this "feature", sending fake arp replies to the two hosts we will sniff. In this reply we will tell that the mac address of the second host is the one hard-coded on OUR ethernet card. This host will now send packets that should go to the first host, to us, because he carries our mac address. The same process is done for the first host, in inverse manner, so we have a perfect man-in-the-middle connection between the two hosts, legally receiving their packets!! Example: HOST 1: mac: 01:01:01:01:01:01 ATTACKER HOST: ip: 192.168.0.1 mac: 03:03:03:03:03:03 ip: 192.168.0.3 HOST 2: mac: 02:02:02:02:02:02 ip: 192.168.0.2 we send arp replys to: HOST 1 telling that 192.168.0.2 is on 03:03:03:03:03:03 HOST 2 telling that 192.168.0.1 is on 03:03:03:03:03:03 now they are poisoned !! they will send their packets to us ! then if receive packets from: HOST 1 we will forward to 02:02:02:02:02:02 HOST 2 we will forward to 01:01:01:01:01:01 simple, isn't it ? *** LINUX KERNEL 2.4.x ISSUE *** In the latest release of the linux kernel we can find in : /usr/src/linux/net/ipv4/arp.c /* Unsolicited ARP is not accepted by default. It is possible, that this option should be enabled for some devices (strip is candidate) */ these kernels uses a special neighbor system to prevent unsolicited arp replies (what ettercap sends to the victim). Oh shit is ettercap unuseful with that kernel ? the answer is NO ! let's view why... in the same source code we find: /* * Process entry. The idea here is we want to send a reply if it is a * request for us or if it is a request for someone else that we hold * a proxy for. We want to add an entry to our cache if it is a reply * to us or if it is a request for our address. * (The assumption for this last is that if someone is requesting our * address, they are probably intending to talk to us, so it saves time * if we cache their address. Their address is also probably not in * our cache, since ours is not in their cache.) * * Putting this another way, we only care about replies if they are to * us, in which case we add them to the cache. For requests, we care * about those for us and those for our proxies. We reply to both, * and in the case of requests for us we add the requester to the arp * cache. */ so, if the kernel receive a REQUEST it will cache the host... what does that mean ? if ettercap sends spoofed REQUESTS instead of REPLIES the kernel will cache them ? the answer is YES !! ettercap 0.6.0 and later has this new ARP REQUEST POISONING method. it will alternate request and replies on poisoning because other OS doesn't have this "feature"... *** SOLARIS ISSUE *** Solaris will not cache a reply if it isn't already in the cache. The trick is simple, before poisoning, ettercap sends a spoofed ICMP ECHO_REQUSET to the host, it has to reply on it and it will make an arp entry for the spoofed host. Then we can begin to poison as always, the entry is now in the cache... 5.4.1.1 PUBLIC ARP In order to sniff from one target host to all others on a switched lan, you have to use Publi ARP mode. With this method ettercap sends broadcast ARP replies with the IP of the victim and the mac of ettercap (poisoning the arp cache). All the hosts will get this reply and add it to the cache so they will send all the packet for the victim to ettercap. But, there is a problem, even the victim will receive this reply and it will notice a IP conflict (as exeriencing under win2k). to solve this problem, SMART PUBLIC ARP was born... 5.4.1.2 SMART PUBLIC ARP With this method the replies are sent selectively to all the host but the victim. in this way there are no IP conficts. NOTE: The poisoned hosts will be the ones in the list, so if you don't want to poison a host, you can remove it from the list hitting 'd' NOTE: to do SMART ARP, ettercap needs to know the hosts list. so it is better that you don't use the broadping startup (-b). however it is impossible to do smart arp without the list in silent mode (-z). ettercap automatically select the clever option, if it has the list, it will use smart arp, if not, it uses the old public arp method. NOTE: with this method more arp replies are sent to the lan... 5.4.2 CHARACTERS INJECTION We have stated that the packets are for us... And the packets will not be received by destination until we forward them. But what happens if we change them? Yes, they reach destination with our modifications. We can modify, add, delete the content of these packets, by simply recalculating the checksum and substituting them on the traffic. But we can do also more: we can insert packets in the connection. We forge our packets with the right sequence and acknowledgement number and send them to the desired host. When the next packets will pass through us we simply subtract or add the sequence number with the amount of data we have injected till the connection is alive, preventing the connection to be rejected (this until we close ettercap, who maintains sequence numbers correct, after program exit, the connection must be RESET or all future traffic would be rejected, blocking the source workstation network). NOTE: Injector supports escape sequences. you can make multi-line injection eg: "this on line one \n this on line two \n and so on..." eg: "this in hex mode: \x65\x6c\x6c\x65" eg: "this in oct mode: \101\108\108\101" NOTE: remember to terminate your injection with \r\n if you want to inject command to the server. 5.4.3 ACTIVE PROTOCOL DISSECTION (for ARPBASED mode) To view in strongly-ciphered streams you need to act straight on the stream For example you need to change key-packets (man-in-the-middle technique). In particular cases this will result in a fault of the protocol, so pay attention using this feature. The used method changes from protocol to protocol and is more difficult to explain than to code it. So I'm sorry but you have to examine the source code if you really want to know how it works. 5.4.4 SSH1 MAN-IN-THE-MIDDLE When the connection starts (remember that we are the master-of-packets, all packets go through ettercap) we substitute the server public key with one generated on the fly and save it in a list so we can remember that this server has been poisoned before. Then the client send the packet containing the session key ciphered with our key, so we are able to decipher it and sniff the real 3DES session key. Now we encrypt the packet with the correct server public key and forward it to the SSH daemon. The connection is established normally, but we have the session key !! Now we can decrypt all the traffic and sit down watching the stream ! The connection will remain active even if we exit from ettercap, because ettercap doesn't proxy it (like dsniff). After the exchange of the keys, ettercap is only a spectator... ;) 5.4.5 PACKET FILTERING Like character injection, we can modify the packets payload and replace the right sequence and acknowledgement number if needed. With the integrated filtering engine you can program your own filter chain to make the best filter for your scopes. A filter chain is a simple array of filter that can be viewed as a list of instruction of a virtual machine. The entry point of the program is the filter 0 (zero). You can specify a jump if the filter is true and a different jump if the filter is false. A filter is considered true if is (in logical AND) equal to the filter. A NULL search string is always considered true. (NULL = 0 for the ports) If the filter matches, it will do the action (Log, Replace or Drop) and evaluate the right jump to be executed. So the "instruction pointer" will change to the filter jumped to. When the value of a jump is blank the filter chain is considered terminated and the packet is forwarded to the target host. So you can set up a filter that search for a particular string (even hex) in the TCP or UDP payload and replace it with yours or drop the entire packet. You can use wildcard in the search string using the special notation [n*] where n is the number of character to be matched. e.g. suppose a data flow as follow: packet 1: "var1=123&var2=400" packet 2: "var1=124&var2=420" packet 3: "var1=125&var2=460" packet 4: "var1=126&var2=540" packet 5: "var1=127&var2=700" ... ... we want to assign a value to the var1 disregarding the current value. so we set up the filter as follow: Search: "var1=[3*]" Replace: "var1=000" this filter will produce this output: packet 1: "var1=000&var2=400" packet 2: "var1=000&var2=420" packet 3: "var1=000&var2=460" packet 4: "var1=000&var2=540" packet 5: "var1=000&var2=700" ... ... and whenever a payload contains the "var1=" assignement it will modify it to "var1=000" NOTE: you can only set up the wildcard at the end of the search string !! e.g. "var1=[5*]" OK "[4*]=123" NOT PERMITTED "var1=[3*]&pippo" WILL BE TRANSLATED TO "var1=[3*]" "var1=[3*]&var2=[3*]" NOT PERMITTED to do multiple filter set up a first filter that makes the var1 replacement with the jump to a second filter that makes the second. i.e: 0 | var1=[3*] R var1=000 | => 1 1 | var2=[3*] R var2=111 You can search and replace even escaped strings like "\x72\x6f\x6f\x74". NOTE: the form automatically trims the trailing spaces of the strings, so if you want to search for "ettercap ", you have to set a filter on "ettercap\x20". "\x20" will be escaped with " ". And if you want to search the magic word "[*]" you have to escape it. 5.5 PASSIVE SCANNING OF THE LAN This feature is very useful if you want to know the topology of the lan but you don't want to send any packet on it. In this way the scan is done entirely by sniffing packets and extracting useful information from them. This scan will let you know the hosts in the lan (it watches ARP request), the Operating System of the hosts (it uses passive os fingerprint... see next section), the open ports of an host (looking the syn+ack packet), the gateway, the routers or hosts atcing as a router (it watches ICMP messages). As a passive method it is useless on a switched lan (because it can make a topology only of the host that are conneting to you), but if you put it on a gateway and let it run for hours or days, it will make a complete report of the hosts in the lan. 5.5.1 PASSIVE OS FINGERPRINT The main idea is to analyze the passive information coming form an host when it makes or receives connections with other hosts. This information is enough to detect the OS and the running services of the host. In this scenario, we look at SYN and SYN+ACK packet and collect some interesting info from them: Window Size: the TCP header field MSS: the TCP option Maximum Segment Size (can be present or not) TTL: the IP header field Time To Live (rounded to the next power of 2) Window Scale: the TCP option indicating the Scale SACK: the TCP option for the Selective ACK NOP: if the TCP options contain a NOP DF: the IP header field Don't Fragment TIMESTAMP: if the TCP timestamp option is enabled and obviously the type of the packet (syn or syn+ack) The database contains different fingerprints for each type of packet because some OSes have different fingerprints from SYN to SYN+ACK. Obviously the SYN fingerprint is more reliable, because the SYN+ACK is influenced by the SYN (if a SYN doen't contain a SACK the SYN+ACK will not have the SACK option even if the host support it). So while collecting information off the lan, if we receive a SYN+ACK we mark the OS of that host as temporary and when we receive a SYN we confirm that. Fingerprint ending with an ":A" are less reliable... this is the reason because some OS identification may change during the gathering process. The SYN+ACK packets are used also to discover the open ports of an host. (see next section) The intersting thing is that firewalls, gateways and NAT are trasparent to passive OS detection. So colleting info for the LAN will let you know info even for remote host. Only proxies aren't trasparent because they make a new connection to the target. Our fingerprint database has to be enlarged, so if you find a host with an unknown fingerprint and you know for sure the OS of that host, please mail us the fingerpring and the OS, we will insert in the database. 5.5.2 OPEN PORTS Open ports are identified by looking for stn+ack packets. If a syn+ack comes form a port, it is for sure open, except for the channel command of FTP protocol, for that reason syn+ack going to port 20 are not used to indicate a open port. For the udp ports the question is a little bit difficult because no syn or ack packet are present in the udp protocol, so ettercap assumes that a udp port < 1024 that sends packets is opened. We know that in this way we cannot discover open ports > 1024 but they can be misdetected as open when a client sends packet to a server. 5.5.3 GATEWAY AND ROUTERS The gateway is simply recognized looking at IP packet with a non local ip ( checking the netmask ). If a non local IP is found, ettercap look at the ethernet address (MAC) and store it as the gateway mac address, then it search for it in the list and mark the corresponding ip as the gateway. Looking in the ICMP messages we can rely that if a host sends a TTL-exceeded or a redirect messages it is a router or an host acting as it. ============================================================================ 6> PLUG-INs ============================================================================ see README.PLUGINS ============================================================================ 7> USELESS INFORMATION ============================================================================ Project started on : 2000-11-25 Last stable release : 0.6.3 Our software never has bugs. It just develops random features. Published on : 2001-12-12 whenever a code runs it's just obsolete Editor : vi, vim, gvim, mcedit, UltraEdit greetings to : The IEEE 802.3 standard :) ISO/OSI organization Andrew S.Tanenbaum Berkeley University the SiLAB (university lab) JJ's corner PUB ALoR greetings: VMWare staff ;) elle (she knows for what...) Raptor & awgn My car hi-fi My New Car (Volkswagen Polo 1.4 TDi) wow ! NaGA greetings: Heineken Inc. My MP3 player N-Team MegaBug fucks to : tutte le tipe che se la menano ;) mcedit (it sucks!) Motto : Specialization is for insects, a human being should be able to do anything! Who we are : If you think you know us... YOU DON'T. If you don't know us... YOU WILL. Shakespeare : question = ( to ) ? be : !be; 0xABADC0DE==============================================================EC-2K