Chap3_3 Flashcards

1
Q

User Datagram Protocol (UDP)

A

Unreliable transport on top of IP:
 No acknowledgments; no message continuation
 No congestion/flow control
 Simply: IP + ports

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

UDP Vulnerabilities

A

 Source IP and port not authenticated

 Some UDP based services reply to any message

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

UDP Attacks Fraggle

A

 Broadcast UDP packet sent to the “echo” service
 All computers reply (amplification)
 Source IP was spoofed, victim is overwhelmed
 Similar to the ICMP Smurf attack

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

UDP Ping-Pong

A

 Some service or application issues a UDP reply no matter what is the input packet
 Set the source and destination ports of a UDP to
be one of the following ports
 daytime (port 13)
 time (port 37)
 This causes a Ping-Pong effect between the source
and the destination.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

UDP: DoS Attacks

A

Applications that reply with large packets to
small requests, e.g., games
 Hosts can be attacked by using these applications
as amplifiers, with forged source IP packets

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Transmission Control Protocol (TCP)

A
Connection-oriented, preserves order
 Sender
• Break data into packets
• Attach packet numbers
 Receiver
• Acknowledge receipt; lost packets are resent
• Reassemble packets in correct order
 Connection setup mechanisms (three-way handshaking)

But NO authentication

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

TCP Vulnerabilities

A
 No authentication of source
A TCP endpoint must accept out of order
packets that are within the range of a window
size
 RST segments must be processed immediately
 No authentication of SYN, RST, FIN
messages
 No authentication of quench requests
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

TCP:Attack: Sequence number prediction

A

 Insider sniffing attack (insider adversary)
 Outsider attack:
• Sequence number increments a constant amount per
second (prediction straightforward)
• Sequence number generated using a pseudo-random
algorithm (prediction possible but maybe complex)
 Implications:
 TCP connection spoofing
 TCP session hijacking
 DoS
 Defense: random initial sequence numbers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

TCP: SYN Flooding

A

An attacker sends many SYN packets to create
multiple connections without ever sending an ACK
to complete the connection
 The victim has to keep the half-opened connection
in its memory for certain amount of time (ex: 75
seconds)
 If there are so many of these malicious packets,
the victim quickly runs out of memory

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

TCP SYN Flooding: Real Example

A

MS Blaster worm (2003)
 Infected machines sent:
• SYN flood on port 80 to windowsupdate.com
• 50 SYN packets every second.
– each packet is 40 bytes.
• Spoofed source IP: a.b.X.Y where X,Y random.
 On 16 July 2003 Microsoft Security Bulletin
MS03-026 announced a buffer overrun in the
Windows Remote Procedure Call (RPC) interface
that could let attackers execute arbitrary code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

TCP SYN Flooding: Example II

A

DDoS attack
 20,000 bots can generate 2Gb/sec of SYNs
 At web site:
• Saturates network uplink or network router
• Random source IP 
attack SYNs look the same as real SYNs

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

TCP Session or Connection

Hijacking (Mitnick Attack)

A

Attacker gains control of a communication
mid stream
 Disrupt: Send a packet with RST and correct
sequence and Ack numbers, and spoofed IP of
one of the victims

Works because even if data is encrypted
TCP header is not

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

TCP RST Attacks

A

Attackers inject RST segment into an existing TCP
connection, causing it to be closed
 TCP Reset attack is possible due to the requirements
that:
 A TCP endpoint MUST accept out of order packets that are
within the range of a window size, and
 The Reset flags SHOULD be processed immediately

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

TCP Connection Spoofing

A

 Suppose init. sequence numbers are predictable
 Attacker can create TCP session on behalf of forged source
IP

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Random Initial TCP SNs

A

Unpredictable SNs prevent basic packet injection
 … but attacker can inject packets after
eavesdropping to obtain current SN
 Most TCP stacks now generate random SNs

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

TCP DoS Attack

A

Suppose attacker can guess sequence number for an
existing connection:
 Attacker can send Reset packet to close connection;
results in DoS.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

TCP: Fingerprinting Hosts

A

 Unique responses and values used (TTL, TOS, …)
facilitate host fingerprinting
 Tool: nmap –O –v host: identifies OS version and tells
you how difficult it is to predict ISN
 FIN Probe
 Send FIN packet (or any packet without ACK or SYN flag) to
an open port
 Wait for response
 Correct RFC793 behavior is to NOT respond
 Many broken implementations (MS Windows, BSDI, CISCO,
HP/UX, MVS and IRIX) send a RST back
 Most current tools utilize this technique

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Fingerprinting Hosts: BOGUS Flag Probe

A

 Queso was the first scanner to use this clever test
 Set an undefined TCP Flag (bit 7 or 8, counting from
the left) in a SYN packet
 Linux prior to 2.0.35 keep the flag set in their
response
 However, some OSs reset the connection when they
receive SYN+BOGUS packet
 Update: Bit 8 (and 9) are now used as the “ECN field”
for TCP congestion control
 Explicit Congestion Notification (ECN) for TCP/IP

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Fingerprinting Hosts: TCP ISN

Sampling

A

Find patterns in the ISN chosen by TCP
implementations when responding to a connection
request
 Traditional 64K increments (many old UNIX boxes)
 Random increments (newer versions of Solaris, IRIX,
FreeBSD, Digital UNIX, Cray and others)
 True “random” (Linux 2.0, OpenVMS, newer AIX)
 “Time dependent” where ISN is incremented by a small fixed
amount each time period (Windows and few others)

20
Q

Fingerprinting Hosts: ICMP

Message Quoting

A

RFCs specify that ICMP error messages quote some
small amount of the IP packet that causes the error
 For port unreachable message almost all implementations send
only the required IP header + 8bytes back
 However, Solaris sends back a bit more and Linux sends even
more
 This allows nmap to recognize Linux and Solaris hosts even if
they don’t have any ports listening!

21
Q

Popular OS Fingerprinting

Utilities

A

Nmap: by Insecure http://www.nmap.org
 Xprobe2: by Sys-Security Group
https://ofirarkin.wordpress.com/xprobe/
https://www.kali.org/tools/xprobe/
 Each tool uses different techniques to guess OS
 All use knowledge of how systems establish and
maintain communication (OS differ slightly)

22
Q

(ISN)

A

Initial Sequence Number

23
Q

If attackers can find out the current sequence number used in a TCP connection, they can inject ……. segment into the connection

A

valid TCP

24
Q

If the attacker is within the same LAN, they can ……. the sequence number

A

sniff

25
Q

If the attacker is not within the same LAN, they have to the sequence number

A

guess

26
Q

Guessing the Source Port

A

Assume OS randomly assigns source ports in the range
1025-49,152 (such as OpenBSD) a RST attack becomes
48,127 times more difficult
 Instead of 262,144 packets as before (16k window)
 Now 262,144*48,127=12,616,204,288 packets are
needed
 Attack of this size would be detected and dealt with
before the reset occurs

 Unfortunately, most OSs allocate source ports
sequentially (including Windows and Linux)
 Exception is OpenBSD, began randomizing source port
allocation in 1996
 There are some Observed Source Port Selection in
some operating systems

27
Q

(DNS)

A

Domain Name System

28
Q

Client wants IP for www.amazon.com:

A

client queries a root server to find com DNS server
 client queries com DNS server to get amazon.com
DNS server
 client queries amazon.com DNS server to get IP
address for www.amazon.com

29
Q

DNS: Basic Vulnerabilities

A

 Users/hosts trust the host-address mapping provided
by DNS:
 Used as basis for many security policies

30
Q

DNS Vulnerabilities

A

 No authentication of DNS server
 No authentication of information
 DNS servers can be tricked into querying any other
DNS server

31
Q

DNS Cache Poisoning

A

 Victim DNS server asks other DNS servers for
mappings if it doesn’t have them; It then caches the
mappings
 DNS cache poisoning is to poison the client’s cache
 Make a DNS server cache false information: usually, a
wrong record that will map a name to a “wrong” IP address

32
Q

DNS Cache Poisoning Unrelated Data Attac

A

 Was the first attack, the simplest and the most widely
used
 This problem has been fixed in BIND, by forbidding
anything that is not related to the original request to
be cached.

33
Q

DNS Cache Poisoning Related Data Attac

A

 The process is the same as the unrelated data attack
 The hacker has to make the “extra” information
related to the original query
 MX: mail server for a domain
 CNAME: canonical name for an alias
 NS: DNS servers for a domain
 The above information is “related” to the original
request, but they can point to totally different
information the hacker wants to be cached
 The problem has also been fixed in BIND, by rejecting
all the “out of zone” information (Sending DNS not
fully and directly responsible for)

34
Q

DNS Spoofing

A

 Answer DNS queries intended for another server
 Difficulties: Transaction ID (16 bits) (DNS uses ID
number to identify queries and answer) and source UDP
port must be guessed

35
Q

DNS ID Hacking

A

 DNS ID hacking is a necessary for a hacker to succeed
in impersonating a DNS server (this is the basic of
DNS spoofing)
 Without the correct ID number the client won’t take
the reply into account.
 On a LAN, getting the ID is easy: sniff the network
for the initial query and answer quicker than the DNS
(which is very easy on a LAN). The late reply from the
real DNS server will be discarded.

When the hacker is not on the same LAN as the victim
client, he can:
 Flood the DNS server to buy some more time for trying
different ID numbers.
 Send a few hundred replies at the same time to increase his
chances to find ID.
 Use a vulnerability in the server, knowing that some of them
just increase the ID number from one request to another.
• First make a request to the “client” (victim DNS) using a host name in a
zone controlled by the hacker, and sniff the ID used by the victim DNS
server.
• Then make a request to the host name he wants to poison the cache of our
victim with, and fake the answer using an increased value of the stolen ID

36
Q

Reverse DNS Attacks

A

 Assume ulysses.ecs.syr.edu and apollo.ecs.syr.edu trust each other, and the trust is based on name, not the IP address.
 Also assume that you are from hacker.com, and you have the control of your own DNS server (which means IP to name and name to IP for machines in hacker.com).
 How can you exploit the trust relationship between Ulysses and Apollo?
 Connect to one of them using your IP
 Target contacts reverse DNS with IP
 Use modified reverse DNS reply to say your IP is the other trusted host
 Q: How to prevent this?
 Use IP address for the trust relationship (or neither)
 A second (forward) DNS look up.

37
Q

Application: network applications

A

POP/SMTP/FTP
 POP (Post Office Protocol) – Email Apps.
 Passwords passed in the clear
 SMTP (Simple Mail Transfer Protocol) – Email Apps
 Nothing authenticated (spam)
 Nothing hidden (eavesdropping)
 File Transfer Protocol (FTP) – File Transfer Apps
 Passwords passed in the clear

38
Q

Web Sites Attacks Cross-Site Scripting Attacks

A

Basically: injecting malicious HTML including web
based scripting into the application hoping that the
application might print the code back unparsed

39
Q

Web Sites Attacks Forceful Browsing Attack

A

 Manipulate data submitted to CGI program via
browser
 Force the web server to return a page or file that
the attacker has no permission to access

40
Q

Web Sites Attacks Parameter Tampering

A

Web server is sent a wide array of information
 All originates at the client’s machine
 The user has complete control over the values and
can change them

41
Q

Web Sites Attacks SQL Injection

A

 Dominant language that database queries are written
in is SQL (Structured Query Language)
 Scripts or applications are the link between web
forms and the database
 In SQL, the query is likely to be constructed using
the data entered by the user

42
Q

Web Sites Attacks Buffer Overflow

A

 Provide an application more data than can be stored
in a particular variable
 It is likely that the application writes past the
bounds of the variable buffer

 Strategy is to change the return address to point to
attacker-supplied data on the stack
 This data would be interpreted as machine
instructions (shellcode or op-code)
 Example continued: Make HexDump launch MS
Notepad on local machine

43
Q

Fixing Buffer Overflow

Vulnerability

A

 Input streams need to be carefully checked for long
strings (Nimda, Code Red and Slammer worms were
enabled by code that didn’t constrain strings
embedded in protocols)
 Any assumption regarding size must be enforced in
code
 Many issues can be resolved by replacing dangerous
functions with safer alternatives (gets with fgets,
strcpy with strncpy, strcat with strncat)

44
Q

OS Vulnerabilities

A

 Different OS choose unique values for certain fields
(TTL, TOS, TCP window size, TCP options)
 Different OS may choose different ways to respond
(not exactly follow RFC)
 Choose specific nonrandom values (ISN, port
numbers)
 These facilitate host fingerprinting and guessing
sequence numbers and source port number.

45
Q

Volunteering Too Much Information

A

Example
 Consider a software that allows a user to upload and
download files
 Assume user has no delete permissions
 When file exists application returns “550 Permission
Denied”
 When file doesn’t exist application returns “550 File not
Found”
 Attacker can know what files exist gaining info about
the target system (OS and patches