Xem mẫu

TCP Header 515 Table B-2 TCP Header Fields and Their Security Implications (Continued) Bit-Offset Header Field Header Value and Description protected by a personal firewall, for example.7 One other well-known scan is the so-called xmas-tree scan. The scanning tool Nmap uses the flags FIN-URG-PSH in its xmas scan mode (–sX option). Other tools use the full set of TCP flags (URG-ACK-PSH-RST-SYN-FIN), hence the name xmas-tree (or all flags lit up) for these scans. Xmas Tree scanning (also referred to as nastygram, kamikaze, and lamp-test) is most often used to bypass simple firewalls and in OS fingerprinting techniques. Any packet that uses the URG or PSH flags may always carry data. WinNuke is an older attack against a Windows system that caused a Blue Screen of Death (BSOD). The exploit consisted of setting the URG flag but not following it with data, and then sending an RST to tear down the connection. The combination SYN-PSH is invalid because a SYN would never be used in a packet carrying data. Other variations exist as well; all are illegal. 112–127 Window (16 bits) This value is exchanged by each side of the TCP connection to tell the opposite side how much data it is capable of buffering, and hence how much data the opposite side can send before pausing and waiting for acknowledgement from the receiver of the data. Because TCP is a full-duplex protocol, there are two window sizes: one in each direction. Security Implications:This is perhaps the most important field in legitimate TCP connections in that it is a key factor for efficient data transmission. The window value is also used as a form of flow control. The maximum value is 65,535 bytes. Typically, the window value fluctuates as data is received and processed. Under normal conditions, if the receiver’s input buffer is full, it will advertise a window size of 0, indicating that the other side should stop sending data until it is told to do so (with an increased window size). All TCP attacks against existing connections require knowledge of source and destination IP addresses, source and destination ports, and the sequence and acknowledgement numbers. Given that the sequence and acknowledgement numbers are incremented based on the amount of data transmitted, knowing the window size can be advantageous to an attacker. Because the receiving TCP implementation will accept any sequence number that falls within a certain range of the expected sequence numbers—as dictated by the window—this makes TCP vulnerable to reset attacks.8 This vulnerability has been exacerbated due to higher-bandwidth links and increased window sizes (to meet the so-called bandwidth-delay product). continues 516 Appendix B: IP Protocol Headers Table B-2 TCP Header Fields and Their Security Implications (Continued) Bit-Offset 128–143 (16 bits) Header Field Checksum Header Value and Description This field is calculated as the 16-bit one’s complement of the one’s complement sum of all 16-bit words in the TCP segment header and TCP segment data. If the segment contains an odd number of octets (that is, it does not end on a 16-bit boundary), then it is padded with 0s for checksum calculation purposes. While computing the checksum, the Checksum field itself is replaced with 0s. A 12-byte pseudo-header is also used in the checksum calculation, and contains the IP header Source Address, Destination Address, and Protocol fields, as well as a calculated TCP segment length (header and data) in bytes. Security Implications:Attacks using invalid checksums (purposely) are limited, because all TCP segments with invalid checksums are dropped. Checksum errors occur in fragmentation-based attacks that split the packet across the TCP header. Another interesting attack that has been hypothesized to actually take advantage of this behavior is a covert channel attack (surreptitiously passing confidential data without discovery). In this case, the sender creates TCP segments carrying the data to be divulged, but all packets are built with invalid TCP checksums. The destination address is selected to ensure that these packets travel through the network and pass a monitoring point employed by the attacker(s), where each packet is sniffed. When these packets reach their destination, they are simply discarded due to the invalid checksum.9 As a result, packet interception at the monitoring point goes undetected. 144–159 Urgent Pointer (16 bits) When the URG flag is set, this value, when added to the sequence number in the packet, is a pointer to the last urgent data byte. Security Implications: The URG flag and urgent pointer have been known to be used to cause a DoS condition. These TCP packets with URG set are referred to as out-of-band packets. When the urgent pointer points to the end of the frame but no normal data follows, a DoS condition may occur.10 A TCP packet with a non-zero Urgent Pointer field value but without the URG flag set must also be considered 160+ (32 bits) invalid. TCP Options Additional header fields (called options) may follow the urgent pointer and be identified by an option kind field. Currently defined kind values are maintained by IANA.11 TCP Header 517 Table B-2 TCP Header Fields and Their Security Implications (Continued) Bit-Offset Header Field Header Value and Description Security Implications:To date, 30 different kind values are specified.11 The kind value indicates the type of TCP option being invoked, and depending on the kind value, the length of the option varies. The total length of the option field must be a multiple of a 32-bit word, and the Data Offset field must be adjusted appropriately. The kind options End of List (0) and No-Operation (1) are exactly one octet (which is just their kind field) and are used to pad out other options to the 32-bit word boundary. All other options have a one-octet kind field, followed by a one-octet length field, followed by (length–2) octets of option data. Some well-known options include: No-Operation (1), Maximum Segment Size (2), Window Scale (WSOPT) (3), SelectiveAcknowledgement Permitted (SACKOK) (4), and Timestamp (8). Option kinds MSS, SACKOK, and WSOPT are only permitted during connection establishment (with the SYN flag). It is not valid to include these options otherwise. Not all options are required to be (or are) supported by all network stacks. Poorly written network stacks may improperly process unsupported or improperly specified options, possibly leading to a DoS condition or buffer overflow condition. The MD5 Signature Option (19) is used by BGP to provide some protection against spoofed TCP segments (hijacking and blind insertion) attacking BGP sessions on Internet core and customer premises equipment (CPE) routers. 2 As indicated above, there are two types of TCP options: a single-octet option (option-kind) and a two-octet option (option-kind+option-length+option-data). When TCP options are used, the Data Offset field indicates the total length of the TCP header, including the length of the options. If the TCP header length does not match the cumulative total of the lengths listed with each option, it is likely that the packet will be improperly processed, possibly leading to a DoS condition. 1. Reynolds, J., and J. Postel. Assigned Numbers. RFC 1700. IETF, Oct. 1994. http://www.ietf.org/rfc/ rfc1700.txt. 2. Jones, S. “Port 0 OS Fingerprinting.” Network Penetration, 2003. http://www.networkpenetration.com/ port0.html. 3. Nmap. Developed by Gordon Lyon. Available at Insecure.org. http://insecure.org/nmap/. 4. “Microsoft Windows Malformed TCP DoS (LAND).” Open Source Vulnerability Database, March 5, 2005. http://osvdb.org/displayvuln.php?osvdb_id=14578. 5. “What Is a TCP Sequence Prediction Attack?” Tech-FAQ. http://www.tech-faq.com/tcp-sequence-prediction.shtml. 6. “CVE-2004-0375” (Symantec Multiple Firewall TCP Options Denial of Service). CVE List. The MITRE Corp. http://cve.mitre.org/cgi-bin/cvename.cgi?name=2004-0375. 518 Appendix B: IP Protocol Headers 7. “Symantec Norton Personal Firewall 2002 SYN/FIN Scan Issue.” Symantec Security Response Advisory. Symantec, May 16, 2002. http://www.symantec.com/avcenter/security/Content/2002.05.16.html. 8. “Vulnerability Issues in TCP.” National Cyber Alert System Technical Cyber Security Alert TA04-111A., Last revised: September 9, 2005. http://www.us-cert.gov/cas/techalerts/TA04-111A.html. 9. Paxson, V. “Subterfuge Attacks.” Section in “Bro: A System for Detecting Network Intruders in Real-Time.” Proceedings of the 7th USENIX Security Symposium. San Antonio, Texas, Jan. 1998. http:// www.sagecertification.org/publications/library/proceedings/sec98/full_papers/paxson/paxson_html/ node17.html. 10. “Multiple Vendor ‘Out Of Band’ Data Denial Of Service Vulnerability.” SecurityFocus. http:// www.securityfocus.com/bid/2010/discuss. 11. “TCP Option Numbers.” IANA. http://www.iana.org/assignments/tcp-parameters. 12. Heffernan, A. Protection of BGP Sessions via the TCP MD5 Signature Option. RFC 2385. IETF, Aug. 1998. http://www.ietf. org/rfc/rfc2385.txt. UDP Header The User Datagram Protocol (UDP) is used for unreliable, minimal overhead transport services that give applications direct access to the datagram service of the IP layer. UDP provides no guarantees for delivery and no protection from duplication. Its simplicity in implementation is its strength when considering transport overhead, but its weakness when considering security implications. The UDP header consists of only four fields, of which two are optional, and requires 8 bytes to specify the necessary values. The UDP header is shown in Figure B-3. NOTE Figure B-3 Because UDP is stateless, unauthenticated, and often used in unidirectional data flows, it is highly susceptible to spoofing attacks against nearly every port and every service. This section does not attempt to cover or address each and every type of UDP attack known to exist. UDP Header Bits 0 4 8 12 16 0 Source Port 20 24 28 31 Destination Port 32 Length Checksum 64+ UDP Payload UDP Header 519 The UDP header fields shown in Figure B-3 are listed and described in Table B-3. Table B-3 also provides a brief description of some known modifications or spoofs to relevant header fields that have been seen in common attacks. Table B-3 UDP Header Fields and Their Security Implications Bit-Offset 0–15 (16 bits) Header Field Source Port Header Value and Description This optional field identifies the sending port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be 0. Security Implications: UDP spoofing attacks have been possible since day one. One well-known DoS attack that spoofed the UDP source port is the so-called UDP Echo/Chargen attack (or UDP Bomb, or UDP Packet Storm). This attack spoofs a UDP packet with a source port of echo (7) and a destination port of chargen (19), causing it to send a datagram back to port 7, which causes this loop to continue endlessly.1 This was effective against a single host (spoofing the same source and destination IP address), or between two hosts. The source port is often spoofed in reflection-based attacks or where feedback mechanisms can be abused to flood the target (purported source) and cause a DoS condition. The UDP Snork Attack used a similar technique, but targeted UDP source/destination port 135.2 16–31 (16 bits) Destination Port This mandatory field identifies the destination port number. The range of possible values is 0–65,535. (Unlike TCP, many port numbers above 1023 are registered as services.) Several well-known destination ports include: 53 (DNS), 67 (BOOTPS), 68 (BOOTPC), 69 (TFTP), 123 (NTP), 137 (WINS), 138 (NETBIOS), 139 (NETBIOS), 161 (SNMP), 162 (SNMPTRAP), 500 (IKE), 514 (SYSLOG), 1701 (L2TP), 1812 (RADIUS AUTH), and 1813 (RADIUS ACCT). An up-to-date list of ports can be found in Wikipedia.3 Security Implications:Attacks directed at specific UDP destination ports are used for several reasons. Reconnaissance attacks may be useful in identifying live services in preparation for future attacks. Security scanners such as Nmap4 have built-in UDP probing capabilities that conduct vertical UDP scans looking for open ports. Because UDP is stateless, scanning involves a negative-response technique. UDP probes reaching closed ports elicit ICMP Port Unreachable error messages, while probes to open (or filtered) ports receive either no response or a positive data response. continues ... - tailieumienphi.vn
nguon tai.lieu . vn