1. Trang chủ
  2. » Công Nghệ Thông Tin

Examination of Datagram Fields I

38 277 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Examination of Datagram Fields I
Tác giả Judy Novak
Trường học Johns Hopkins University Applied Physics Laboratory
Chuyên ngành Network Traffic Analysis
Thể loại Thesis
Năm xuất bản 2000
Thành phố Baltimore
Định dạng
Số trang 38
Dung lượng 246,34 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

hping2 ICMP/UDP/TCP packets and display target replies” hping2 is a very useful tool in scanning and crafting traffic to send to remote hosts.. 10 nmap-os-fingerprints • nmap comes with

Trang 2

2

Examination of Datagram Fields

This page intentionally left blank

Trang 3

Objectives

This page intentionally left blank

Trang 4

4

Why are Packets ”Crafted”?

Why would someone craft traffic to be abnormal or different in some way? We’ll examine this topic

in this section as we see mutations that are done to the IP datagram Some of the reasons for this are:

Fingerprinting: The intent is to send an unexpected stimulus of some sort by altering the datagram

and detecting how a target host responds If enough deviant stimuli are sent and responses gathered,

it is possible to identify the operating system of the target host This is done to better know how to target a future attack

Evasion: If the intent is to scan hosts or do some kind of reconnaissance for a future attack or attack

a host, why not try to send traffic that will scan yet, at the same time elude notice by an intrusion detection system?

Covert messages/channels: It is possible to alter fields or protocol operations in an attempt to send

secret traffic between hosts Fields or methods have to be selected that are not likely to attract attention

Elicit a response for mapping: If live host mapping cannot be done in a more classic sense with

echo requests and replies, perhaps because of access control lists; there are less conventional ways to map Some of these ways include sending traffic to a host and having it respond with some kind of error message This is enough to indicate that the host is alive

Trang 5

How are Packets “Crafted”?

Normally, IP datagram assembled by layers of TCP/IP stack

Different means of crafting packets

Application Programming Interfaces (API)

A good paper is available that discusses Unix sockets – it is entitled “Raw IP Networking FAQ” and

is found at www.whitefang.com/rin Both socket and libnet routines are used in programs such as C

or perl The user must decide what values to use to construct the packet and use the routines to fashion and send the packet

There are many software packages available to craft packets These are easier to use than the API’s because all you need to do is select command line options and the packet is crafted for you

Here is where to go to get the software mentioned in the slide:

libnet – www.packetfactory.net

nmap – www.insecure.org

hping2 – packetstorm.securify.com - hping2-beta54.tar.gz

ISIC – packetstorm.securify.com - isic-0.05.tar.gz

Trang 6

6

nmap

Straight from the man page for nmap, the description of the tool is “network exploration tool and security scanner” nmap is one of the most sophisticated tools available for remote scanning of a host Through overt and stealthy means, it can map a network for live hosts, map hosts for services running, and send hosts connections that are intended to elicit responses to assist in determining how they are unique and therefore figuring out the operating system of the scanned host

nmap has a bevy of command line options to alter its behavior It can scan in stealth modes so as to evade notice or attempt to elude detection It can send “decoy” traffic as it scans and fires off traffic

to the scanned host with a spoofed source ip(s) so that the receiving host or network will not know the real source of the traffic from the bogus traffic This is a truly remarkable and useful tool; the author is Fyodor

Trang 7

hping2

ICMP/UDP/TCP packets and display target

replies”

hping2 is a very useful tool in scanning and crafting traffic to send to remote hosts

Some of its capabilities are:

• sending spoofed source IP addresses

• setting a default initial TTL

• setting an IP ID number

• fragmenting packets

• setting TOS field

• setting source port

• setting TCP window size

• sending data with TCP transmission

• setting any TCP flag

Trang 8

8

ISIC

its component stacks (TCP, UDP, ICMP)”

packets

isic is used to generate random mutations to the IP header tcpsic, udpsic, and icmpsic generate mutant packets for TCP, UDP, and ICMP portions of the datagram The intention is to test how the receiving host’s TCP/IP stack responds to very strange traffic Some of the capabilities of this tool suite are:

• corrupt fields in the IP header such as:

• IP version

• header length

• protocol

• send strange fragments

• corrupt fields in the TCP header such as:

Trang 10

10

nmap-os-fingerprints

nmap comes with a file nmap-os-fingerprints

Scanning host sends remote host many different

connections:

9 different “tests” are examined

File contains expected responses for various different

operating systems

nmap comes with a fingerprinting file which lists hundreds of variations of operating systems and the expected responses of each OS to 9 different tests nmap probes remote systems for responses that differ among operating systems Some of these tests send unexpected stimuli to see how the remote host will respond Using a combination of these tests, nmap accurately distinguishes not only operating system types, but actual releases of the same operating system

There is a wonderful article that comes with nmap that discusses what the operating system

fingerprinting attempts to accomplish and how it does so This is located in the file

nmap-fingerprinting-article.txt This can also be found at the nmap site, www insecure.org

Trang 11

nmap OS Tests

# Tseq is the TCP sequenceability test

# T1 is a SYN packet with a bunch of TCP options to open port

# T2 is a NULL packet w/options to open port

# T3 is a SYN|FIN|URG|PSH packet w/options to open port

# T4 is an ACK to open port w/options

# T5 is a SYN to closed port w/options

# T6 is an ACK to closed port w/options

# T7 is a FIN|PSH|URG to a closed port w/options

# PU is a UDP packet to a closed port

The first test that nmap does is to discover open TCP ports and send a series of packets to that port to determine how the remote TCP/IP stack generates its initial sequence numbers (ISN’s) As you can see, there are seven tests that send a combination of normal and mutant TCP traffic to the remote host to see how it responds Finally, a UDP packet is sent to a closed port to examine the ICMP message that is returned and its embedded message

One thing to note is that all required tests must receive an exact response to classify a particular operating system Not all tests require a response, but any response that is received must match all the conditions for a given test to fit a given classification

Trang 12

12

Looking for Windows Host

Fingerprint Windows NT4 / Win95 / Win98

TSeq(Class=TD|RI%gcd=1|2|3|4|5|A|14|1E|28|5A%SI=<1F4)

T1(DF=Y%W=2017|16D0|860|869F%ACK=S++%Flags=AS%Ops=M|MNWNNT)

T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

T3(Resp=Y%DF=Y%W=2017|16D0|860|869F%ACK=S++%Flags=AS%Ops=M|MNWN NT)

The information on the slide above represents all the tests and responses that must be received in order to classify a remote host as a Windows NT4/ Win95/ Win98 host Each of the 9 tests must receive exact responses if a response is received There are multiple conditions for each test separated from each other with a % sign

Of all the tests, T2 and T3 must receive a response All others are optional The first test Tseq is different than the others because it tries to identify how initial sequence numbers are generated Windows hosts have a time dependent (TD) or random incremental formula Also, the ISN has a greatest common denominator of any of the values listed (separated by the pipe sign “|”) Finally, the Windows sequence index is a hex 1F4 or decimal 500

Trang 13

Response required = Yes, DF flag set = Yes, Window = 0x2017 (8215),

ACK = 1656491548 (SYN + 1), Flags = ACK, SYN, TCP options = mss

Let’s examine one of the tests and see how it applies to traffic sent to a Windows 98 host T3 is a SYN|FIN|URG|PSH packet with options to an open port The scanner, verbo, sends a TCP connection with the SYN, FIN, URG, PUSH flags set to destination port 139 which is listening All of the following conditions must be met:

Resp=Y means that there has to be a response to this test in order to classify the operating system as

Windows

DF=Y means that the Don’t Fragment flag is set which we see in the response

W=2017|16D0|860|869F We have a choice of 4 different window size values (all in hexadecimal) and

separated by the pipe sign “|” to signify an or The decimal window size of 8215 is the hex equivalent of

2017

ACK=S++ The acknowledgement number must be 1 more than the initial sequence number sent by the

Trang 14

DF=N The Don’t Fragment flag is not set on the response.

W=0 The response window size is 0.

ACK=S++ The acknowledgement number of 1656491548 is one more than the ISN set by verbo.

Flags=AR Both the ACK and Reset flags are set.

Ops= There are no TCP options on the response.

Trang 15

ccf0 8f65 ed9e 0001 0134 397c 6d6d 6d6d (more data)

14:06:16.684902 win98 > verbo: icmp: win98 udp port 1

ULEN UCK

RIPCK

< > -Embedded ICMP response

UCK ULEN

ID

IPCK

And, now let’s examine one final test to a Windows 98 host This test checks a UDP packet to a closed port In this case a packet is sent to win98 destination port 1 UDP which is not listening This test is somewhat different than the ones we’ve seen before This one tests a lot of fields of the ICMP message in response to the closed port scan Many of the fields of interest are located in the embedded ICMP response message that follows the ICMP message This message contains the original IP header from the message that elicited this response (the UDP packet to port 1) and 8 bytes of UDP data This test doesn’t require a response The tests for the ICMP response are as follows:

DF=N Don’t Fragment flag not set – it is not.

TOS=0 Type of service is 0.

IPLEN=38 The IP datagram length is a hex 38.

RIPTL=148 The return IP datagram length is 0x148.

RID=E The return IP identification number is the same as the one sent; it matches the 0xb937 The “E”

flag means it matches, a flag of “F” would mean it does not

RIPCK=E The return IP checksum is the same as the one sent – both are 0x1222.

Trang 16

16

Result of nmap Fingerprinting

nmap –O win98

( The 1522 ports scanned but not shown below are in state: closed)

Port State Service

139/tcp open netbios-ssn

TCP Sequence Prediction: Class=trivial time dependency

Difficulty=1 (Trivial joke) Remote operating system guess: Windows NT4 / Win95 / Win98

Using nmap to scan the host win98 and identify the operating system using the –O option, we discover from all the tests that it has sent that the remote system is either Windows NT4, Win95 or Win98 Indeed, it is a Windows 98 host The reason that nmap is so uncertain about which

Windows operating system it is, is because the Windows TCP/IP stack has not changed for all of these various releases Many of the other TCP/IP stacks change per release level, yet Microsoft has not changed theirs for about 4 years

The responses of the nmap –O scans were examined and all the tests matched the conditions that were necessary to classify this as a Windows host

Trang 17

17NID Evasion/Insertion Theory

This brief section will describe some theory written in a paper that discussed problems using a network intrusion detection system as the sole means of discovering events of interest on the network

Trang 18

Written by Thomas Ptacek and Timothy Newsham

NID cannot know for sure if destination host will receive/react to

a packet

Insertion: IDS accepts a packet destination host rejects

Evasion: Destination host accepts a packet IDS rejects

There was a landmark paper written in 1998 called “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection” In it, the authors Thomas Ptacek and Timothy Newsham discuss attacks that can elude detection by the NID by using methods of sending traffic that will cause the NID and the destination host to view packets sent differently The paper is an excellent treatise of different conditions that can cause a NID to improperly analyze an attack The authors conducted several different tests against NIDS to prove their theory

Along with the denial of service of a NID, the paper basically discusses the idea of individual attacks

to confuse the NID The first is known as insertion This is where the attacker can send a set of streams of traffic to the destination host One or more of the packets sent will be accepted or seen by the NID, yet they will never reach the destination host or if they do, the destination will reject them

as faulty The NID and the destination host see different traffic A second attack is known as evasion This involves the same idea of sending a set of streams of data to the destination host, yet this time the destination host will see all the traffic that the NID does, but it will evaluate the packet differently than the NID Perhaps the NID rejected one or more packets than the destination host accepted Again, the NID and the destination host will see the traffic differently

This paper can be found at:

www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.html

Trang 19

Let’s say we have a NID that is on a different network, such as the DMZ, from many of the hosts that it is guarding Now, let’s also say that the NID is looking for signatures that may indicate some kind of

problem or notable traffic One of those signatures may be to look for traffic to PCAnywhere that allows remote users access to Windows hosts Specifically, the signature looks for traffic to destination port TCP

5632 and a content of “ST” in the first and second bytes

We have an attacker who has done some reconnaissance on our network and knows more about the

network topology and behavior than we care for her/him to know It is possible for the attacker to elude notice of the NID if she/he can make the NID accept a packet that the end host will not accept or will never see

In this instance, the attacker sends three different packets destined for TCP port 5632 each with one character in the payload The first contains the letter “S” which both the NID and the end host receive, examine, and accept A second character of “A” is sent that has a bad TCP checksum As we’ll learn in the next section, checksums validate the integrity of the packet and if they are not correct, the packet should be discarded Let’s say that the NID sees this packet, is not programmed to examine the TCP checksum and blindly accepts it as a valid part of the stream of characters being sent to the destination host The destination host receives the packet, validates that the TCP checksum is incorrect and discards the packet The attacker has managed to insert a character that will cause the NID to fail to recognize a real attack or action against the end host Finally, a third packet is sent with a payload of “T” that both the NID

Trang 20

In the case of evasion, the destination host sees or accepts a packet that the NID rejects In this case we are still looking at PCAnywhere traffic to the destination host If the attacker can send the traffic in such

a manner that the NID rejects a packet that the end host accepts, this will elude detection

A possible scenario for this attack is sending data on the SYN connection We’ll examine this later While not typical of normal connections, sending data on SYN is valid The data on a SYN connection should later be considered part of the stream once the three-way handshake has been completed So, let’s say we have a first packet that arrives on the network with a SYN packet destined for TCP port 5632 of our destination host It has a payload of “S” in the SYN packet The NID only looks for payload after the three-way handshake has been completed so it totally misses that there is any data The destination host receives the same packet and knows to store the “S” for the session once the three-way handshake is completed We then have the packets that complete the three-way handshake each with no data in them

as expected And, finally, we have a normal packet with the letter “T” as the payload destined for port TCP 5632

The result is that the NID reassembles the TCP session for destination host port 5632 with a complete payload of “T” This doesn’t match any signature it knows The destination host, on the other hand, reassembles the stream as “ST” and happily starts the PCAnywhere session

Ngày đăng: 26/10/2013, 23:15

TỪ KHÓA LIÊN QUAN

w