SSH1 MAN IN THE MIDDLE ATTACK Computer Network Security ECE578 Dr.

Cetin Kaya Koc Siva Sai Yerubandi 930-33-9878 Weetit Wanalertlak 230-77-0302

Abstract
SSH Secure Shell was originally an academic project written by Tatu Ylonen from the University of Finland. Presently, he is a CEO of SSH Communications Security company. SSH replaces the Berkeley r commands, telnet and ftp with a certain level of security. SSH Communications Security Company stops distributing and developing SSH1 from May 1st, 2001 because it contained many security flaws. Even though, there are still many servers on the risk. The flaws can be roughly classified into two categories. The first, vulnerabilities are from programming point of view. These are the flaws that occur in the machine code and they are depended on machine architecture and can be fix or harden by recompiling or patching source code, for example the buffer over flow for SSHD1 and Trojan horse. Most of the SSH programs are open source, we can expect the security will be available quickly after the bugs were announced. The second category is more serious and independent from machine architecture. The flaws from communication protocol point of view need to be fixed by rewriting standards. Most of the source code patched that came after security announcement produced incompatibilities to protocol. The new version of standard can take months to write. Example for this flaw is DNS spoofing and Man-in-the-middle attack. Because there are too many materials, this project will mainly cover the topic about SSH1 Man in the middle attack, or SSH1 confidentiality attack.

Introduction
The concept of remote access service provides the users mobility to work anywhere. However, the basic remote access service was lack of the confidentiality between pointto-point connections. As a reason of everybody has an access to the share medium, it is impossible to prevent them from view the contents of the data being transferred. However, we can make the data unintelligible to the middleman by using encryption scheme. Secure Shell Communication Inc came up with this idea and released the first version of commercial SSH. Still in developing process, SSH still needs more modifications in order to get the safe way of data transmission. This paper deals with the short coming in the SSH-1 protocol. We explain the OSI layer. We first start with the overview of UNIX and TCP/IP network covering the basic concept of IP network and history. Then we explain about the development of secure shell applications. This also covers the vulnerability of the OSI layer which are often exploited by cryptanalyst. Moreover, it still covers the ready application and preliminary attack for accessing the target network.

Network security and solution

Overview of UNIX and TCP/IP network
In 1969 the Advanced Research Project Agency (ARPA) supported a research and development project to create an experimental packet-switching network, called

ARPANET. The infrastructure was built to study techniques for providing robust, reliable, vendor-independent data communications. Many techniques of data communication had been developed for ARPANET. Project has been developed by many organizations. In 1975 the network has been connected for daily data communication. The TCP/IP protocols were developed as Military Standards (MIL STD) in 1893. ARPA in that time has been changed to be DRAPA. It required every node that connected to the system to use TCP/IP protocol. As a solution, DRAPA supported Bolt, Beranek, and Newman (BBN) to implement TCP/IP on (BSD) UNIX. Until now, most of the server systems still use UNIX systems based on the reason of open structure and reliability.

TCP/IP Protocol Architecture

An architectural model developed by the International Standard Organization (ISO) is frequently used to describe the structure and functionality of data communications protocols. The standard is called Open Systems Interconnection (OSI) model. This model consists of 7 internal layers.

Physical layer The physical layer function is to transmit raw bits over a communication channel. Most of the responsibility of physical layer is to make sure that when one side sends logic 1, the receiver receives logic 1, not as logic 0. The standard has to be set between sender and receiver such as how many volts should be used to represent a 1 and how many for a 0, how long a logic value should last, the number of connections that can be made at the same time, how to establish initial connection and how it is disconnected when both sides have finished the communication, and how many pins the network connector has and what is the functionality of each pin. Physical layer also consists of electric or mechanic signals.

Data link layer The task of the data link layer is to take a raw transmission facility and reorder it into a line that appears free of transmission errors in the network layer. Data is ordered into frames and adding small overhead for basic error detection. The other advanced methods such as, error correction or flow control have to be done by software or operating system. Network layer The network layer controls the connection in the subnet. The purpose of this layer is to determine how the packets are routed from source to destination. Routes could be based on static tables in case of the topology that is not often changed. With the congestion control capability implemented in this layer, routing can be dynamically change based on traffic load. Transport layer The basic functionality of transport layer is to accept data from session layer, break it into smaller parts, and send it to network layer. The main function is to provide virtual circuit between transport layer of sender and transport layer of receiver in order to behave transparently for higher layers. The transport layer also determines the type of services provided to the session layer. The type of service is determined when the connection is established. Session layer The session layer allows users on different machines to establish sessions between them. A session allows from basic data transport up to complex services. A session might be used to allow a user to log into a remote time-sharing system or to transfer a file between two machines. One of the services of the session layer is to manage dialogue control. Sessions can allow traffic to go in both directions at the same time, or in only one direction at a time. If traffic can only go one way at a time, the session layer can help keep track of whose turn it is. Another session service is synchronization. Presentation layer This layer provides a communication between high-level applications for cooperating to exchange data. The layer will be the agreement between two applications in order to make a communication. The network data compression, data cryptography or authentication is frequently implemented in this layer. Application layer The application layer is the top most layer that is directly contacted to user. This layer provides the functionality for user and compatibility between other applications.

For example, the mail reader program provide the readable message to reader and connect to lower layer in order to transfer the data from mail server.

MAC (sub layer)

Another issue that we review is media access control (MAC). In order for a host to listen to traffic coming to the system, network adapter will monitor the traffic for the packet with destination IP matching its particular group address then puts the packet into its IP stack. Two key elements to this process are the IP stack, which must know the IP addresses to monitor (typically provided by the requesting application) and the network adapter, which needs to know the Media Access Control (MAC) layer addresses for monitoring. One of the flaws to allow sniffing and spoofing is the MAC layer that we will explain in the following. IP packets are processed and delivered according to the local system's Layer 2 topology addressing and framing services. In addition, a network adapter will process only the MAC-layer frames that contain either the local system's hardware address or the network's broadcast address (written as "FF:FF:FF:FF:FF:FF" on Ethernet).

Sniffer
Sniffing is the term that first stood for wiretap. Instead of phone networks packet sniffer intercept data from the network link. It came into vogue with Ethernet, which is known as a "shared medium" network. This means that traffic on a segment passes by all hosts attached to that segment. Ethernet cards have a MAC layer that prevents the host machine from seeing traffic addressed to other stations. Sniffing programs turn off the filter, and thus see everyones traffic. Today's networks are increasingly employing "switch" technology, preventing this technique from being as successful as in the past. It is still useful, though, as it is becoming increasingly easy to install remote sniffing programs on servers and routers, through which a lot of traffic flows. Today's networks may already contain built-in sniffing modules. Most hubs support the RMON standard, which allow the intruder to sniff remotely using SNMP, which has weak authentication. Many corporations employ Network Associates "Distributed Sniffer Servers", which are set up with easy to guess passwords. Windows NT machines often have a "Network Monitoring Agent" installed, which again allows for remote sniffing. Packets sniffing is difficult to detect, but it can be done. However the difficulty of the solution means that in practice, it is rarely done. The popularity of packet sniffing system comes from the fact that it sees everything.

Typical target for sniffer includes, SMTP, POP, IMAP traffic Allows intruder to read the actual e-mail. POP, IMAP, HTTP Basic, Telnet authentication Reads passwords off the wire in clear-text. SMB, NFS, FTP traffic Read files of the wire. SQL database Read financial transactions and credit card numbers.

Spoofer
A spoofing attack involves forging one's source address. It is the act of using one machine to impersonate another. Most of the applications and tools in UNIX rely on the source IP address authentication. Many developers have used the host based access controls to secure their networks. Source IP address is a unique identifier but not a reliable one. It can easily be spoofed. To understand the spoofing process, first we will explain about the TCP and IP authentication process and then how an attacker can spoof our network. The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then opened, and the service-specific data can be exchanged between the client and the server. Client and server can now send service-specific data TCP uses sequence numbers. When a virtual circuit is established between two hosts, then TCP assigns each packet a number as an identifying index. Both hosts use this number for error checking and reporting. Rik Farrow, in his article "Sequence Number Attacks", explains the sequence number system as follows: "The sequence number is used to acknowledge receipt of data. At the beginning of a TCP connection, the client sends a TCP packet with an initial sequence number, but no acknowledgment. If there is a server application running at the other end of the connection, the server sends back a TCP packet with its own initial sequence number, and an acknowledgment; the initial number from the client's packet plus one. When the client system receives this packet, it must send back its own acknowledgment; the server's initial sequence number plus one." Thus an attacker has two problems: 1) He must forge the source address. 2) He must maintain a sequence number with the target.

The second task is the most complicated task because when target sets the initial sequence number, the attacker must response with the correct response. Once the attacker correctly guesses the sequence number, he can then synchronize with the target and establish a valid session.

Remote Access Services

Computer networks are not, by themselves, particularly secure. Communicating across a computer network can be linked to shouting across a crowded room where the intended recipient receives the message, as well by all the other people in the room. Neither the shouter nor the listener has any way of knowing whether any of the other people in the room might be overhearing the conversation. Encryption lets two parties exchange information so that only they can understand it--anyone else attempting to "listen in" on the conversation will hear only unintelligible gibberish. Encryption is extremely important for passwords. Sending an unencrypted password across the network gives an open invitation to hackers. Once our password has been compromised, a hacker can access our personal e-mail as well as our personal data and data stored on shared systems.

OSI 7 Layer Draw Back

Layer 1
Ethernet is a medium where it opens for every node to read all of the packets in the medium. Normally network cards would process only packet with the hardware address of the network card (MAC). However, every network cards can be brought into "Promiscuous Mode". In this mode every packet that existing in the medium will be processed and sent to upper OSI layer.

Layer 2
In IP-networks, Address Resolution Protocol (ARP) does the process of mapping IP and MAC-addresses. If hacker can fake the ARP-packets, the IP packet will be send to another computer.

Layer 3
The most common protocol in Layer 3 is the ICMP protocol. It is mostly used to "ping" a host, to not only see if it is operating, but also to see what is wrong with a network. This is an ideal playground for hackers because sending a mal formatted ICMP-unreachable packet to a server disconnects it and if the hacker have a good knowledge of the right commands they can hold a network under a DoS attack. Again nemesis is a good tool for this kind of attacks.

Layer 4
TCP and UDP are the most powerful protocols in transport layer. To address certain services user has to open ports that are assigned in the TCP and UDP protocol. With a port scanner (e.g. NMAP) attacker can see what ports are open on a server, giving information about how to attack such a server. Many hackers use NMAP for network scans, because NMAP has a variety of possible scans and it can use decoys and tiny bytes so that intrusion detection systems wont recognize a scan. Also NMAP can normally find out what the operating system is running on the server and for how long it is up. The disadvantage of nmap is it cannot scan behind a firewall. Still there is software like portscanner jakal, which can scan what ports are open behind a firewall. One more way is to use the tool called "hping". This tool is more advanced and can modify every packet that is being sent to a server, and thereby testing the firewall rules. This tool is more advanced and is very good to see what ports are open.

Layer 5
Vulnerability scanner works normally on Layer 5. It is used for testing the applications and the system weaknesses. One of the first scanners was SATAN, developed by Dan Farmer and Wietse Venema. Right now the best scanner is Nessus. With the plug-ins and the scripting language NASL, system can be updated and customized for maintaining or hacking purpose.

Layer 6
This layer is directly based on humans. For instance, it is the most vulnerable as all the layers. Social engineering for password is really possible. Also many users are fooled by replying to fake mails from the (faked) "admin" of their mail provider, giving them the password.

Secure Shell
Secure Shell is way of accessing remote systems securely using encryption and cryptography. It was designed to replace popular telnet, ftp and UC Berkley UNIX "r" commands to add security and encryptions. Secure Shell was made to perform these crucial tasks securely: 1. Secure remote access into a computer system 2. Securely transfer and copy files between systems 3. Act as software VPN or tunnel to secure protocols like SMTP, POP, FTP, Telnet, and X-window, which are not inherently secure on the TCP/IP. Secure Shell is designed in a client-server form. The server side is called Secure Shell server or daemon (SSHD). The client side is called Secure Shell client (SSH). A SSH client is used to connect to a remote machine running SSHD server and run any character mode programs in the SSHD server. All data and password are encrypted in an SSH SSHD session, thus eliminating virtually any risks associated with remote access. It is a widely used standard and available in most UNIX platforms for both clients and servers. It has two primary versions: SSH1 and SSH2. SSH1 is older version,

but is still widely used. SSH2 is the newer vintage of the protocol and provides more robust and powerful security features. SSH2 (Secure Shell Version2) has been submitted to IETF (Internet Engineering Task Force) for establishing it as a secure remote access standard (SecSh). SSH clients are available for most operating systems including Windows XP / 2000 /XP / NT/ ME / 98 / 95 / 3.x and Macintosh. Remote access of systems is one of the most common tasks performed by most professionals and IT staff. It is very rare in these days of the Internet for one to work with one local computer alone. Quite frequently, one has to login into another machine and start some task or monitor the progress of some tasks started earlier. This other computer could be in the next room or in the next continent.

Need for SSH

The Internet and TCP/IP standard for doing the remote access are one of telnet, rsh, rexec or rlogin. But there were flaws in them. They were not secure because the password was sent in clear text and data was not encrypted. Hacker could simply sniff the data exchanges and pick the password up or even look at data that may be sensitive. Secure shell was intended to put an end to all of these security flaws. It introduced a single client (ssh) and a single server (sshd), which authenticated users based on any of the means used in telnet (password), rsh, rexec (password) and rlogin. Public key Cryptography and strong Encryption methods were used to securely establish a channel. Once a secure channel is established, credentials like password and other sensitive data can be sent without a worry of the attacker as all them are encrypted. SSH is a new generation protocol (1995-2001) allowing the ssh designers the freedom to architect ssh so that it fixed the flaws that older TCP/IP application protocols proved to be problem areas in security and features.

How is it used
Secure Shell is designed in TCP/IP client-server model. The Secure Shell Server (SSHD) runs as a daemon in UNIX and as a service in Windows NT/2000/XP, and listens for connection from SSH clients on TCP port22. A Secure Shell Client (SSH) is run to connect to a given SSHD server identified by the host name of the SSHD server machine. The client and server exchange certificates to identify each other and then establish a shared secret key dynamically and securely using public key encryption. The new-shared secret key is then used for encrypting all future data between SSH and SSHD nodes during establishing session because a secure path between the receiver and the sender, password or other authentication information can be transferred safely for user authentication. Once the user authentication is completed, the SSHD server typically provides the command shell of the operating system to SSH client. SSH client can type any command into this shell and get its output interactively. All input and output data are encrypted and optionally compressed during transit on the network. The session ends when a shell terminating command like 'exit' or 'logout' is typed on the SSH client. Thus SSH access works very much like telnet access. One of the important use of Secure Shell is to use an SSH-SSHD session as a secure tunnel to pass data from non-secure protocols like SMTP, POP, FTP, Telnet, X-window, etc. to make them run securely without any change. In this case, ports of the protocols to be protected are forwarded via proxy and listed when a SSH session is started. In the command line of SSH, -L option is used to 9

list protocol ports to be forwarded. Secure Shell is designed in TCP/IP client-server model

How it works
1. The SSH client contacts the SSH server 2. Both client and server disclose the SSH protocol versions they support 3. The remote host identifies itself to the SSH client by sending the following data, unencrypted: a. The remote host's public key (a discussion of public-key cryptography will follow in the next section) b. In the case of SSH1, the public key for the SSH server (note that there might be more than one SSH server for a given host) c. A sequence of random bytes called check bytes, to foil against IP spoofing. The client must then include these in its next response or the connection request will be rejected d. A list of encryption, compression, and authentication methods supported by the SSH server. Both sides then compute and exchange what is known as a session identifier, a common 128-bit session identifier that is a MD5 hash of the host key, server key, and check bytes taken together. The client checks the host public key against $HOME/.SSH/known_hosts and /etc/known_hosts. 4. A bulk cipher is generated for the session. Known as the session key, its purpose is to encrypt and decrypt all data exchanged between client and server. In addition, the session key plays an important role in guarding against replay attacks during the user or host authentication phase. The generation of the session key varies according to whether SSH-1 or SSH2 is followed. Under the SSH-1 protocol, the client formulates the session key, encrypts it twice with the host public key and the server key (in what is known as perfect forward secrecy), and sends it to the server. SSH2 has a different key- exchange procedure, in which both client and server produce a shared secret that is input to another process, which generates the session key. Thus, neither side can fully determine the session key as an additional precaution. And unlike in the SSH-1 protocol, a server key is not necessary in SSH-2 to produce the session key. Moreover, in SSH1, only one session key is used throughout the SSH session, however long the session takes. Potentially, this gives the cryptanalyst more data encrypted with the same key, and hence greatly increases the chances of the key being discovered. SSH-2 on the other hand, allows for session rekeying, whereby a new session key is generated as agreed upon by both client and server. 5. The server sends the client a confirmation message encrypted with the session key.

10

6. The secure connection is established between client and server. All succeeding communication will henceforth be encrypted and decrypted using the session key.
1.Ask for contact 2.Check for compatibility protocol 3.Client and server authentication (server public key, nonce, etc) 4.Session key encrypt with server public key SSH 5.Client-Server test secure communication under session key SSHD

6.Begin the communication+unix authentication

Man-in-the-Middle Attack
All the others attacks except for this are considered to be passive since they do not involve altering the behavior of the systems being targeted causing the switch to fail-open can be seen as an active attack on the switch, but the network traffic is merely observed, not intercepted or modified en route. A Man-in-the-Middle attack is an active attack since the attacking host plays an important role managing the network traffic between the source and destination targets. A MITM attack is the target host is fooled by making it think that it is connecting to a desired destination host when in fact it is connecting to the attacker host, The attacker host handles the connection to the desired destination host and proxies traffic between the two from that point on. The attacker host completely controls the connection and can view and/or modify information passing between the connection it has forged with the source and destination hosts. This type of attack is particularly effective when dealing with connections encrypted with public-key cryptography. Public-key cryptography is an extremely effective encryption concept, but it does have a condition that connecting host must have a copy of the public key from the host being connected to. If the connecting host does not already have the public key from a previous connection with that host then it will have to get it from somewhere with protocols such as SSH, the destination host will supply its public key itself. MITM attacks take advantage of this by intercepting the initial connection attempt and substituting their own "forged" public key (which the attacker has from an earlier session and can therefore decrypt the data). If the user at the connecting end has never seen the correct public key before, then the forgery will not be noticed and the attack will be a success. Even in the case where the user does have the correct public key to compare with it, often it just results in a small warning being printed saying the key has changed and if they want to continue connecting. Most users will simply click OK without another thought. This is not the fault of the protocol. This is a problem with user education and

11

also with implementations that print simple warnings when an event as serious as a key change occurs. Executing the MITM attack is more complex than the others, but dsniffs tools make it almost as easy. It is hard to study Dsniff without being at least slightly troubled by the ease at which we can gather passwords, emails, files, and eavesdrop on encrypted connections, even on switched networks.

SSH Vulnerability Overview

One of the major design flaws in the SSH-1 protocol is to allowing server to establish two or more concurrent sessions with the same session ID. This method allows a man-in-the-middle attack. In order to intercept data between SSH and SSHD in the network link, malicious server needs to know the session key between client and server.
1.a.Ask for contact 2.Check for compatibility protocol 3b.Client and server authentication (server public key, nonce, etc) 4a.Session key encrypt with server public key SSH 5.Client-Server test secure communication under session key Man In The Middle (malicious server) 5.Client-Server test secure communication under session key 1.b.Ask for contact 2.Check for compatibility protocol 3a.Client and server authentication (server public key, nonce, etc) 4b.Session key encrypt with server public key SSHD

6.Begin the communication+unix authentication

6.Begin the communication+unix authentication

The client must accept host keys from the malicious server to enable exploitation of this vulnerability. Each server computes this public key and a corresponding private key by itself. Since there is a pseudorandom process, the computation of the keys for each severs are totally different and it is extremely unlikely that two servers come up with the same key pair. Servers share their public keys with other hosts, so a server can steal another server's public host key. However, if a server used another server's public host key as its own, it would also need the corresponding private key to decrypt messages from its clients. The private key is not shared and is very difficult to compute from the public host key alone. In SSH-1, a session ID is computed as a hash of the server's public host key and a 64-bit random number called "cookie". The SSH-1 protocol assumes that: 1. No two servers have the same public and private host keys, and 2. Given any public host key and 64-bit random number, it is very difficult to find a different public host key and/or cookie, which yield the same session ID.SSH-1 relies on the above assumptions during authentication. In the SSH-1 authentication process, the server generates a 256-bit random number called a "challenge". The challenge is then encrypted with the client's public key, so that only the client can decrypt it. The client receives the encrypted challenge and decrypts it. The client returns the challenge response: an MD5 hash of the concatenation of the challenge and the session ID. The server independently computes the expected challenge response by the same formula. If the client's challenge response matches what the server computed, then the server responds that client has successfully authenticated.

12

Public key encryption of the challenge protects the challenge from discovery by third parties as it is sent from the server to the client. Furthermore, the MD5 hash prevents third parties from discovering the challenge from the client's challenge response to the server. Assuming that neither host has been compromised, only the server and the client will know the challenge. The inclusion of the session ID identifies the challenge response with a certain server, since the session ID is derived from the server's public host key. Different servers should have different host keys, which produce different session ID's and change the expected challenge response. This difference in session ID's prevents a malicious server from replaying a client's challenge response to another server to authenticate as the client. Unfortunately, a weakness has been discovered in the formula for computing a session ID from the server's public key. This discovery allows modification of a server's public host key without changing the derived session ID. Furthermore, the modified key is often much weaker than the original, so it is easily factored to create a corresponding private key. This new key pair can be used to negotiate multiple concurrent SSH connections with the same session ID. Therefore, assumption 2 above, upon which the security of SSH-1 authentication is grounded, does not hold. As a result, authentication in SSH-1 is vulnerable to man-in-the-middle attacks.

Ready Application
ETTERCAP
Ettercap is a network sniffer/interceptor/logger for Ethernet LANs. It supports active and passive dissection of many protocols even ciphered ones, like SSH and HTTPS. Data injection in an established connection and filtering on the fly is also possible, keeping the connection synchronized. Many sniffing modes are implemented to give the attacker a powerful and complete sniffing suite. A lot of plug-in are supported. Ettercap has the ability to check whether we are in a switched LAN or not, and to use OS fingerprints which can be either active or passive to let the attacker know type of operating system or type of router then drawing the geometry of the LAN. The passive scan of the using the sniffing data to analyze the topology of the system, moreover the type and version OS and network component.

DSNIFF
Dsniff is a network sniffer designed for testing of a different sort. The application is included add on regular expression in order to seek for information in different application protocols, such as usernames and passwords, web pages being visited, contents of email, and more. It is also able to penetrate switched networks by making network traffic from other hosts on the same network segment to be visible, not just traffic involving the host Dsniff is running on. It includes programs to launch man-in-the-middle attacks on the SSH-1 and HTTPS protocols, which would allow viewing of the traffic unencrypted, and even the possibility of taking over interactive SSH sessions.

13

List of tools included in the Dsniff package and a brief description of their function are given below. arpspoof Redirects packets on a LAN to defeat the host-isolating behavior of the switch. dnsspoof forges replies to DNS queries. Password sniffer with ability to handle FTP, Telnet, SMTP, HTTP, POP, Dsniff poppas, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MSCHAP, NFS, VRRP, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase and Microsoft SQL authentication info. Saves files sniffed from NFS traffic. filesnarf Causes LAN switch to fail-open (ie. Act as a hub and broadcast traffic to all Macof hosts). mailsnarf Saves email messages sniffed from SMTP and POP traffic. msgsnarf Saves messages and chat sessions sniffed from most Instant Messenger protocols and IRC. Kills specified in-progress TCP connections. tcpkill slows down specified TCP connections. tcpnice reports URLs sniffed from HTTP traffic. urlsnarf Sends sniffed URLs to our local Netscape browser, allowing us to browse in webspy real-time along with the target. SSHmitm Proxies and sniffs SSH traffic redirected by dnsspoof, captures password logins and optionally allows hijacking interactive sessions. webmitm Proxies and sniffs HTTP/HTTPS traffic redirected by dnsspoof, capturing SSL-encrypted logins and form submissions.

Attack Preliminaries: Accessing the Target Network Traffic 1.The LAN uses a hub:
In this case, nothing extra needs to be done, all network traffic going to any host on the LAN is visible to all other hosts on the LAN.

2. The LAN uses a switch:

In the switched architecture, all hosts are connected to the switch on their own isolated port, and the switch keeps track of which host is on which port, and then only sends traffic intended for that host to its port. However, this is mainly intended to increase performance (since each host gets a dedicated connection instead of being shared like with a hub), and the security benefit is mostly a side effect. Therefore, it is easy to defeat by simply confusing the switch so it cannot be sure which host is on which port. Most switches respond to this condition by "failing-open", which means it begins to act like a hub and send all traffic to all ports. This will also cause network performance to suffer greatly, which might be noticed by others on the network.

14

One of the ways is using Macof to flood the network with random MAC addresses, which will overflow the internal translation table of the switch. Without an accurate translation table, the switch can no longer know which host is on which port, which leaves the switch with no choice but to forward all packets to all ports (like a hub would do). This is known as "fail-open". If the switch does not fail-open, the only other option is to "fail-closed" in which case no network traffic will get through to any host on the LAN at all. Although this latter case is not an option for most equipment, it would be an especially easy denial-of-service attack. Note: Most switches can be configured to allow only one, fixed, MAC address per port In that case, Macof would have no effect, but it is a difficult arrangement to manage.

3.The LAN uses a switch and we wish to target a specific host:

If we do not want to sniff all the traffic on the LAN but only wish to target a specific host on it, we can leave the switch alone and just confuse that specific host into thinking that we are the gateway/router. Therefore any traffic that host wishes to send to outside the LAN will go to our host first. This is the most clandestine form of sniffing, since it only affects the target host, and only in the way we specify, therefore it is not likely to be noticed by others. To accomplish this, we use ARP spoof to send fake ARP packets to the target host, telling it that the MITM attack host is the gateway. That way, any traffic it tries to send outside the LAN will actually go to the MITM attack host. Before doing this, we have to tell the attack host to forward packets on to the real gateway otherwise it will be noticed quickly that the target host can no longer communicate outside the LAN.

Conclusion
There will always be a tough fight between the hackers and the system administrators. Hackers attempt to break into the codes and security systems, whereas administrators attempt hold them from invading the networks. SSH -1, though called a secure shell is not perfectly safe. It has flaws in it because it is man made. However, we can get the system protected from intercepting by using the following measures: 1) The best protection against sniffing can be done by using a smart hub or a switch. 2) Use SSH-2 or other encryption clients for network communications 3) Public key cryptography provides better protection from sniffing because the private key is never sent and thus cannot be intercepted during transit. Secure Shell Communication has their latest version of SSH, which is called SSH-2. Presently the protocol used by SSH is fool proof. But still this may not be the case in the future because any smart hacker can up with the loophole in the software. So a better way to prevent the attacks from sniffing is by constantly updating the newer versions of better software

15

Reference
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Attacks Against SSH 1 And SSL, http://slashdot.org/articles/00/12/18/0759236.shtml Richard E. Silverman, dsniff and SSH Reports of My Demise are Greatly Exaggerated, http://sysadmin.oreilly.com/news/silverman_1200.html, December 22, 2000 dugsong, dsniff, http://www.monkey.org/~dugsong/dsniff/ Joel Scambray, Stuart McClure, George Kurtz, Hacking Expose 2nd edition, Osbone McGraw Hill, 2001 Alberto Ornaghi, Marco Valleri, ettercap, http://ettercap.sourceforge.net/ Craig Hunt, TCP/IP Administration, Oreilly, 1998 Bruce Schneier, Applied Cryptography, John Wiley & Sons, Inc., 1996 William Stalling, Cryptography and Network Security 2nd edition, Prentice Hall, 1998 W. Richard Stevens, UNIX Network programming, Prentice Hall, 1994 Dimitri Bertsekas, Robert Gallager, Data Networks 2nd edition, Prentice Hall, 1992 Abraham Silberschatz, Peter Baer Galvin, Operating System Concepts 5th edition, Addison-Wesley, 1998 Aeleen Frisch, Essential System Administration 2nd edition, Oreilly, 1995 A white paper on the technologies behind SSH1 & SSH2SecureShell from Pragma and how it can be used toSecure your Enterprise By Pragma Systems, Inc. Austin,Texas, USA. www.pragmasys.com August 21, 2001 Packet Sniffing, http://www.iss.net/security_center/advice/Underground/Hacking/Methods/Tec hnical/Packet_sniffing/default.html SSH-1 allows client authentication to be forwarded by a malicious server to another server, http://www.kb.cert.org/vuls/id/684820

16