The Transmission Control Protocol Internet Protocol was originally developed by the United States Department of Defense (DoD) to provide robust service on large internetworks that incorporate a variety of computer types. In recent years, the Internet protocols constitute the most popular network protocols currently in use.
One reason for the popularity of TCP/IP is that no one vendor owns it, unlike IPX/SPX, DNA, SNA, NetBEUI, AppleTalk protocol suite, all of which are controlled by specific companies. TCP/IP evolved in response to input from a wide variety of industry sources. Consequently, TCP/IP is the most open of the protocol suites and is supported by the widest variety of vendors. Virtually every brand of computing equipment now supports TCP/IP.
TCP/IP provides a routable, enterprise networking protocol and access to the worldwide Internet and its resources.
The interoperability is one of the primary advantages to TCP/IP. Almost all networks support TCP/IP as a protocol. TCP/IP also supports routing, and is commonly used as an internetworking protocol.
Because of its popularity, TCP/IP has become the de facto standard for internetworking.
(1)Security Weakness of TCP/IP:
(01) IP Address Spoofing
In this type of attack, the attacker replaces the IP address of the sender, or in some rare cases the destination, with a different address. IP spoofing is normally used to exploit a target host. In other cases, it is used to start a denial-of-service (DoS) attack. As shown in Figure 5, in a DoS attack, an attacker modifies the IP packet to mislead the target host into accepting the original packet as a packet sourced at a trusted host. The attacker must know the IP address of the trusted host to modify the packet headers (source IP address) so that it appears that the packets are coming from that host.
Figure 1.1 DoS Attack Using IP Spoofing
For all DoS attacks launched against a host (the web server of Company XYZ in Figure 1.1), the attacker is not interested in retrieving effective data or information from the intended victim. The attacker has only one goal: to deny the use of service that the web server provides to valid users without being revealed. Therefore, the return address or source IP address can be spoofed.
In Figure 1.1, the attacker has the IP address 18.104.22.168 and is connected to the Internet. For normal traffic interaction between a workstation with a valid source IP address (22.214.171.124) and the web server (126.96.36.199), the packet is constructed with a source IP address of 188.8.131.52 and a destination IP address of 184.108.40.206. The web server returns the web page using the source IP address specified in the request as the destination IP address, 220.127.116.11, and its own IP address as the source IP address, 18.104.22.168.
Let's now assume that a DoS attack is launched from the attacker's workstation on Company XYZ's web server using IP spoofing. Imagine that a spoofed IP address of 22.214.171.124 is used by the workstation, which is a valid host. Company XYZ's web server executes the web page request by sending the information or data to the IP address of what it believes to be the originating end station (126.96.36.199). This workstation receives the unwanted connection attempts from the web server, but it simply discards the received data. It's becoming clear that multiple simultaneous attacks of this sort deny the use of service that the web server provides to valid users. As you can imagine, locating the origin of the attacker launching the DoS attack is very complex when IP address spoofing is used.
(02) Covert Channels:
A covert or clandestine channel can be best described as a pipe or communication channel between two entities that can be exploited by a process or application transferring information in a manner that violates the system's security specifications.
More specifically for TCP/IP, in some instances, covert channels are established, and data can be secretly passed between two end systems. Let's take Internet Control Message Protocol (ICMP) as an example. In the following types of circumstances, ICMP messages are sent to provide error and control mechanisms:
Testing connectivity/reach ability using datagram echo and Echo-Reply
Reporting unreachable destinations for datagram Destination Unreachable
Reporting buffer capacity problems for forwarding datagram Source
Reporting route changes in the path for datagram Redirect messages.
ICMP resides at the Internet layer of the TCP/IP protocol suite and is implemented in all TCP/IP hosts. Based on the specifications of the ICMP Protocol, an ICMP Echo Request message should have an 8-byte header and a 56-byte payload. The ICMP Echo Request packet should not carry any data in the payload. However, these packets are often used to carry secret information. The ICMP packets are altered slightly to carry secret data in the payload. This makes the size of the packet larger, but no control exists in the protocol stack to defeat this behavior. The alteration of ICMP packets gives intruders the opportunity to program specialized client-server pairs. These small pieces of code export confidential information without alerting the network administrator. Blocking ICMP packets that exceed a certain limit size is the only solution to protect against this vulnerability.
An example of a tool that uses this covert channel technique is Loki. The concept of the Loki tool is simple: It is a client-server application that tunnels arbitrary information in the data portion of ICMP_ECHO and ICMP_ECHO REPLY packets. Loki exploits the covert channel that exists inside of ICMP_ECHO traffic. Figure 1.2 illustrates this tool.
Figure 1.2 Loki Tool
In general, covert channels are prevalent in nearly all the underlying protocols of the TCP/IP protocol suite
(03) Routing attacks:
This attack takes advantage of Routing Information Protocol (RIP), which is often an essential component in a TCP/IP network. RIP is used to distribute routing information within networks, such as shortest-paths, and advertising routes out from the local network. Like TCP/IP, RIP has no built in authentication, and the information provided
in a RIP packet is often used without verifying it. Attacks on RIP change where data goes to, not where it came from. For example, an attacker could forge a RIP packet, claiming his host "X" has the fastest path out of the network. All packets sent out from that network would then be routed through X, where they could be modified or examined. An attacker could also use RIP to effectively impersonate any host, by causing all traffic sent to that host to be sent to the attacker's machine instead.
(04) DNS attacks:
The Domain Name Service ("DNS") is a protocol widely used on the Internet to map hostnames to IP addresses and vise versa. An attacker can use the property of mapping IP address to host name to fool name-based authentication. This attack can be prevented by performing a second DNS query on the hostname returned by the first query.
(05) IP Fragment Attacks
The TCP/IP protocol suite, or more specifically IP, allows the fragmentation of packets. As discussed in the previous sections, IP fragmentation offset is used to keep track of the different parts of a datagram. The information or content in this field is used at the destination to reassemble the datagrams. All such fragments have the same Identification field value, and the fragmentation offset indicates the position of the current fragment in the context of the original packet.
Many access routers and firewalls do not perform packet reassembly. In normal operation, IP fragments do not overlap, but attackers can create artificially fragmented packets to mislead the routers or firewalls. Usually, these packets are small and almost impractical for end systems because of data and computational overhead.
Let's go into a little more detail. The ingeniously constructed second fragment of a packet can have an offset value that is less than the length of the data in the first fragment. Upon packet reassembly at the end station, the second fragment overrides several bytes of the first fragment. These malformed IP packets cause the operating system at the end station to function improperly or even to crash.
A good example of an IP fragmentation attack is the Ping of Death attack. The Ping of Death attack sends fragments that, when reassembled at the end station, create a larger packet than the maximum permissible length.
One of the uses of this attack is to get past intrusion detection system (IDS) sensors. The individual fragments do not match any known signature, but after the overlap addresses overwrite some data, the result is an attack that can be recognized. A decent IP filtering code and configuration are required at the access router and firewalls to be assured that these attacks are blocked. These devices need to enforce a minimum fragment offset for fragments that have nonzero offsets so that overlaps can be prevented
(06) ICMP Attack:
The Internet Control Message Protocol ("ICMP") is used by the IP layer to send one-way informational messages to a host. There is no authentication in ICMP, which leads to attacks using ICMP that can result in a denial of service, or allowing the attacker to intercept packets. An attacker can forge one of these ICMP messages, and send it to one or both of the communicating hosts to disconnect their connection.
(07) Connection Hijacking:
TCP connections can be hijacked by unauthorized users without much difficulty. In Figure 8, an authorized user (Employee X) sends HTTP requests over a TCP session with the web server.
Figure 1.3 Connection Hijacking
The web server accepts the packets from Employee X only when the packet has the correct SEQ/ACK numbers. As seen previously, these numbers are important for the web server to distinguish between different sessions and to make sure it is still talking to Employee X. Imagine that the cracker starts sending packets to the web server spoofing the IP address of Employee X, using the correct SEQ/ACK combination. The web server accepts the packet and increments the ACK number.
In the meantime, Employee X continues to send packets but with incorrect SEQ/ACK numbers. As a result of sending unsynchronized packets, all data from Employee X is discarded when received by the web server. The attacker pretends to be Employee X using the correct numbers. This finally results in the cracker hijacking the connection, whereby Employee X is completely confused and the web server replies assuming the cracker is sending correct synchronized data.
SSL is designed to make use of TCP to provide a reliable end-to-end secure service. SSL is not a single protocol but rather two layers of protocols, as illustrated in
Figure: SSL Protocol Stack
The SSL Record Protocol provides basic security services to various higher-layer protocols. In particular, the Hypertext Transfer Protocol (HTTP), which provides the transfer service for Web client/server interaction, can operate on top of SSL. Three higher-layer protocols are defined as part of SSL: the Handshake Protocol, The Change Cipher Spec Protocol, and the Alert Protocol. These SSL-specific protocols are used in the management of SSL exchanges and are examined later in this section.
Two important SSL concepts are the SSL session and the SSL connection, which are defined in the specification as follows:
Connection: A connection is a transport (in the OSI layering model definition) that provides a suitable type of service. For SSL, such connections are peer-to-peer relationships. The connections are transient. Every connection is associated with one session.
Session: An SSL session is an association between a client and a server. Sessions are created by the Handshake Protocol. Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.
Between any pair of parties (applications such as HTTP on client and server), there may be multiple secure connections. In theory, there may also be multiple simultaneous sessions between parties, but this feature is not used in practice.
There are actually a number of states associated with each session. Once a session is established, there is a current operating state for both read and write (i.e., receive and send). In addition, during the Handshake Protocol, pending read and write states are created. Upon successful conclusion of the Handshake Protocol, the pending states become the current states.
A session state is defined by the following parameters (definitions taken from the SSL specification):
Session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null.
Compression method: The algorithm used to compress data prior to encryption.
Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the hash size.
Master secret: 48-byte secret shared between the client and server.
Is resumable: A flag indicating whether the session can be used to initiate new connections.
A connection state is defined by the following parameters:
Server and client random: Byte sequences that are chosen by the server and client for each connection.
Server write MAC secret: The secret key used in MAC operations on data sent by the server.
Client write MAC secret: The secret key used in MAC operations on data sent by the client.
Server write key: The conventional encryption key for data encrypted by the server and decrypted by the client.
Client write key: The conventional encryption key for data encrypted by the client and decrypted by the server.
Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key. This field is first initialized by the SSL Handshake Protocol. Thereafter the final cipher text block from each record is preserved for use as the IV with the following record.
Sequence numbers: Each party maintains separate sequence numbers for transmitted and received messages for each connection. When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero. Sequence numbers may not exceed 264 1.
The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with other applications that use SSL, alert messages are compressed and encrypted, as specified by the current state.
Each message in this protocol consists of two bytes. The first byte takes the value warning (1) or fatal (2) to convey the severity of the message. If the level is fatal, SSL immediately terminates the connection. Other connections on the same session may continue, but no new connections on this session may be established. The second byte contains a code that indicates the specific alert. First, we list those alerts that are always fatal (definitions from the SSL specification):
Unexpected message: An inappropriate message was received.
Bad record mac: An incorrect MAC was received.
Decompression failure: The decompression function received improper input (e.g., unable to decompress or decompress to greater than maximum allowable length).
Handshake failure: Sender was unable to negotiate an acceptable set of security parameters given the options available.
Illegal parameter: A field in a handshake message was out of range or inconsistent with other fields.
The remainder of the alerts is the following:
Close notify: Notifies the recipient that the sender will not send any more messages on this connection. Each party is required to send a close notify alert before closing the write side of a connection.
No certificate: May be sent in response to a certificate request if no appropriate certificate is available.
Bad certificate: A received certificate was corrupt (e.g., contained a signature that did not verify).
Unsupported certificate: The type of the received certificate is not supported.
Certificate revoked: A certificate has been revoked by its signer.
Certificate expired: A certificate has expired.
Certificate unknown: Some other unspecified issue arose in processing the certificate, rendering it unacceptable.
Applications of IPSec
IPSec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet. Examples of its use include the following:
Secure branch office connectivity over the Internet: A company can build a secure virtual private network over the Internet or over a public WAN. This enables a business to rely heavily on the Internet and reduce its need for private networks, saving costs and network management overhead.
Secure remote access over the Internet: An end user whose system is equipped with IP security protocols can make a local call to an Internet service provider (ISP) and gain secure access to a company network. This reduces the cost of toll charges for traveling employees and telecommuters.
Establishing extranet and intranet connectivity with partners: IPSec can be used to secure communication with other organizations, ensuring authentication and confidentiality and providing a key exchange mechanism.
Enhancing electronic commerce security: Even though some Web and electronic commerce applications have built-in security protocols, the use of IPSec enhances that security.
The principal feature of IPSec that enables it to support these varied applications is that it can encrypt and/or authenticate all traffic at the IP level. Thus, all distributed applications, including remote logon, client/server, e-mail, file transfer, Web access, and so on, can be secured.
Figure 16.1 is a typical scenario of IPSec usage. An organization maintains LANs at dispersed locations. No secure IP traffic is conducted on each LAN. For traffic offsite, through some sort of private or public WAN, IPSec protocols are used. These protocols operate in networking devices, such as a router or firewall that connect each LAN to the outside world. The IPSec networking device will typically encrypt and compress all traffic going into the WAN, and decrypt and decompress traffic coming from the WAN; these operations are transparent to workstations and servers on the LAN. Secure transmission is also possible with individual users who dial into the WAN. Such user workstations must implement the IPSec protocols to provide security.
Figure 16.1. An IP Security Scenario
Benefits of IPSec
Lists the following benefits of IPSec:
When IPSec is implemented in a firewall or router, it provides strong security that can be applied to all traffic crossing the perimeter. Traffic within a company or workgroup does not incur the overhead of security-related processing.
IPSec in a firewall is resistant to bypass if all traffic from the outside must use IP, and the firewall is the only means of entrance from the Internet into the organization.
IPSec is below the transport layer (TCP, UDP) and so is transparent to applications. There is no need to change software on a user or server system when IPSec is implemented in the firewall or router. Even if IPSec is implemented in end systems, upper-layer software, including applications, is not affected.
IPSec can be transparent to end users. There is no need to train users on security mechanisms, issue keying material on a per-user basis, or revoke keying material when users leave the organization.
IPSec can provide security for individual users if needed. This is useful for offsite workers and for setting up a secure virtual sub network within an organization for sensitive applications.
Kerberos is an authentication service developed as part of Project Athena at MIT. The problem that Kerberos addresses is this: Assume an open distributed environment in which users at workstations wish to access services on servers distributed throughout the network. We would like for servers to be able to restrict access to authorized users and to be able to authenticate requests for service. In this environment, a workstation cannot be trusted to identify its users correctly to network services. In particular, the following three threats exist:
A user may gain access to a particular workstation and pretend to be another user operating from that workstation.
A user may alter the network address of a workstation so that the requests sent from the altered workstation appear to come from the impersonated workstation.
A user may eavesdrop on exchanges and use a replay attack to gain entrance to a server or to disrupt operations.
In any of these cases, an unauthorized user may be able to gain access to services and data that he or she is not authorized to access. Rather than building in elaborate authentication protocols at each server, Kerberos provides a centralized authentication server whose function is to authenticate users to servers and servers to users. Unlike most other authentication schemes described in this book, Kerberos relies exclusively on symmetric encryption, making no use of public-key encryption.
Trusted Computer System Evaluation Criteria