Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Network Security > Chap3_3 > Flashcards

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

24
Q

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

25
If the attacker is not within the same LAN, they have to the sequence number
guess
26
Guessing the Source Port
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
(DNS)
Domain Name System
28
Client wants IP for www.amazon.com:
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
DNS: Basic Vulnerabilities
 Users/hosts trust the host-address mapping provided by DNS:  Used as basis for many security policies
30
DNS Vulnerabilities
 No authentication of DNS server  No authentication of information  DNS servers can be tricked into querying any other DNS server
31
DNS Cache Poisoning
 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
DNS Cache Poisoning Unrelated Data Attac
 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
DNS Cache Poisoning Related Data Attac
 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
DNS Spoofing
 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
DNS ID Hacking
 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
Reverse DNS Attacks
 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
Application: network applications
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
Web Sites Attacks Cross-Site Scripting Attacks
Basically: injecting malicious HTML including web based scripting into the application hoping that the application might print the code back unparsed
39
Web Sites Attacks Forceful Browsing Attack
 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
Web Sites Attacks Parameter Tampering
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
Web Sites Attacks SQL Injection
 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
Web Sites Attacks Buffer Overflow
 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
Fixing Buffer Overflow | Vulnerability
 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
OS Vulnerabilities
 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
Volunteering Too Much Information
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

Network Security (9 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions