Institute for Visualization and Perception Research 1 © Copyright 1998 Haim Levkowitz Internet & Web Security

Institute for Visualization and Perception ResearchI VPR 1

© Copyright 1998 Haim Levkowitz

Internet & Web Security



References & Resources

• Lincoln Stein, Web Security: A Step-by-Step Reference Guide

• Larry J. Hughes, Jr., Internet Security Techniques



What is web security?

• Three parts of web security

• Three points of view

• Risks



Three components of web security

• Browser

• Server

• Connection between the two (I.e., the Internet!)



Three points of view

• User’s

• Webmaster’s

• Both parties’



User’s point of view

• Remote server’s ownership known and true

• No viruses or other damaging documents / sw

• Remote server respects user’s privacy

• Doesn’t obtain / record / distribute private info



Webmaster’s point of view

• User won’t try to break in / alter contents

• User won’t try to gain access to documents s/he’s not privy to

• User won’t try to crash the server

• User’s ID (if provided!) is true



Both parties’ point of view

• Network connection free of eavesdropping

• Info between browser and server delivered intact, free from tampering



Three (interdependent) parts

• Document confidentiality

• Client-side security

• Server-side security



Document confidentiality

• Protect private information from

• Eavesdropping

• Fraudulent identities

• Mostly via cryptography



Client-side security• Protect user’s privacy and system’s

integrity• Virus protection• Limit amount of info browser transmits

(without user’s consent)• Protect organizations confidential

information / network integrity• From Web browsing activities



Server-side security

• Protect server from

• Break-ins

• Site vandalism

• Denial-of-service attacks

• Mostly firewalls and OS security measures



Risks

• Risks that affect both client and server

• Risks to the end user

• Risks to the web site



Risks that affect both client and server

• Eavesdropping

• “Packet sniffers” (more …)

• Fraud



Network snooping (sniffing) ...

• Abuse of network debugging tools ...

• Network interface into promiscuous mode ...

• Solution: encrypt



Abuse of network debugging tools ...• E.g., Network General's Expert Sniffer

• etherfind (SunOS)

• tcpdump (free on Internet)

• Sniffer FAQ

• comp.security, news.answers

• ftp://ftp.iss.net/pub/faq/sniff

• http://www.iss.net/iss/sniff.html



Network interface into promiscuous mode ...

• Report all packets to sniffer

• Display / record

• Analyze

• Remote also possible



Fraud

• Authenticate

• Individuals, organizations

• Transactions

• Documents

• Solution: digital signatures, certification authorities



Risks to the end user

• Active content

• Privacy infringement



Active content• Browsers download and run SW without

notice• Java applets• ActiveX controls• Plug-ins• Helper app’s• JavaScript• Malicious (not many) / buggy (???)



Privacy infringement

• Site-collected data on visitors• Server log (time, date, IP addr.,

document, referrer URL)• Proxy servers log (every site visited)• Cookies

• User-provided data• Solutions: e.g., “stealth browser”



Risks to the web site

• Webjacking

• Server and LAN break-ins

• Denial-of-service attacks



Webjacking

• Break in & modify contents

• Happens(ed) a lot

• How?

• Exploit holes in

• OS, Web server, buggy SW

• CGI scripts



Server and LAN break-ins

• Various attacks at different protocol layers (OSI, more …)

• Defense: firewall



Denial-of-service attacks

• Cause server to crash / hang / “crawl”• OS, server, CGI scripts, Web site

services• No real defenses

• Place limits on resources used by server / other sw

• Close known holes



Part I: Document confidentiality

• Basic cryptography

• SSL, SET, and Digital Payment Systems



Basic cryptography

• How cryptography works

• Symmetric cryptography

• Public key cryptography

• Online Resources

• Printed Resources



How cryptography works• Plaintext

• Ciphertext

• Cryptographic algorithm

• Key

Plaintext Ciphertext

Key

Algorithm

Encryption

Decryption



Simple cryptosystem ...

• Caesar Cipher

• Simple substitution cipher

• ROT-13

• half alphabet ==> 2 x ==> plaintext

ABCDEFGHIJKLMNOPQRSTUVWXYZ

DEFGHIJKLMNOPQRSTUVWXYZABC



Keys cryptosystems …

• keys and keyspace ...

• secret-key and public-key ...

• key management ...

• strength of key systems ...



Keys and keyspace …

• ROT: key is N

• Brute force: 25 values of N

• IDEA in PGP: 2128 numeric keys

• 1 billion keys / sec ==> >10,781,000,000,000,000,000,000 years



Plaintext Ciphertext

Key

Encryption Decryption Plaintext

Sender Recipient

Symmetric cryptography• DES

• Triple DES, DESX, GDES, RDES

• RC2, RC4, RC5

• IDEA

• Blowfish



DES• Data Encryption Standard

• US NIST (‘70s)

• 56-bit key

• Good then

• Not enough now (cracked June 1997)

• Discrete blocks of 64 bits

• Often w/ CBC (cipherblock chaining)

• Each blocks encr. depends on contents of previous



Triple DES, DESX, GDES, RDES

• Variants on DES: decrease risk of brute-force guessing

• Triple-DES• 1. W/ Key 1• 2. W/ Key 2• 3. W/ Key 1

• ==> Effective key length ~168 bits



RC2, RC4, RC5

• Proprietary (RSA Data Security, Inc.)

• Variable length keys(up to 2,048 bits)

• Outside US: 40-bit versions of RC2 & RC4

• ==> Web browsers & servers



IDEA

• Int’l Data Encryption Algorithm

• Patented (AscomTech AG)

• Popular in Europe

• 128-bit key ==> more secure than DES

• (One of) at heart of PGP

• (Other is RSA)



Blowfish

• Unpatented (Bruce Schneier)

• In many commercial & freeware

• Var-length key (up to 448 bits)



Symmetric not fit for Internet

• Spontaneous comm ==> can’t exchange keys

• Multiway comm ==> key secrecy compromised



Public key cryptography

• Two-in-one

• Cryptography

• Digital signatures



Public key cryptography• Asymmetric

Plaintext Ciphertext Plaintext

Senders

Recipient

Encryption

Key

Recipient’s public key

Decryption

Key

Recipient’s secret key



Digital signatures

• But, problem ...

Plaintext Digital signature

Authenticated Plaintext

Sender Recipient

Encryption Decryption

Key

Sender’s secret key

Key

Sender’s public key

=?y



Combining cryptography and digital signature

Ciphertext

Authenticated Message

SenderRecipient

Key

Sender’s secret key

Message text

Digital signature

Key

Sender’s public key =?

y

Key


Key


Signature text



Problem ...

• Can cut & paste from older• Solutions

• A --> B: random “challenge” phrase• B --> A: sign w/ secret key, return • A: decrypts w/ B’s public key,

compare to original• Or, message digest functions



Message digest functions & message integrity

• One-way hashes

• Digital fingerprint for original message

• Sender ...

• Recipient



Sender

• 1. Run message through digest function

• 2. Sign hash with secret key

• 3. Send signed hash & original message to recipient



Recipient• Decrypt hash w/ sender’s public key• Compare with result of running message

through digest function• Match ==> verified integrity• In SSL (later): Message Authenticity Check

(MAC)• MAC = digest(secret + digest(secret -

message))



Message digest functions

• MD4 (Rivest, MIT)

• 128-bit hashes

• Weaknesses ==>

• MD5 (Rivest)

• Most widely used

• SHA: Secure Hash Algorithm (NIST)

• 160-bit hash



Digital envelopes• Public key encryption SLOWER than symmetric ==>

Hybrid• 1. Random secret key (“session key”; discard when

done)• 2. Encrypt message w/ session key & symmetric alg.• Encrypt session key w/ recipient’s public key (==>

“digital envelope”)• Send encrypted message + digital envelope



Digital envelopes

Ciphertext

SenderRecipient

Key


Key


Message plaintext

Key

Session key

Key

Session key

Message plaintext



Certifying authorities & public key infrastructure

• Large public-key database

• ==> management? Trusted third party

• Certifying authorities (CA)



Certifying authorities (CA)

Key

CA’s secret key

Individual’s distinguished name

Key

Individual’s public key

Certificate request

(w/ public key)

Signed certificate

Certifying Authority (CA):1. Verify individual’s ID2. Create certificate3. Generate message digest from certificate,signs hash w/ its secret key4. Return certificate to individual

$$$ Pay CA’s fee ID info



Public key infrastructure

• Site certificates: authenticate Web servers

• Personal certificate: individuals• SW publisher certificates: executables• Certifying authority certificates• Common format: X.509v3• CPS: certification practice statement



Root CAs & certificate chains• Browsers delivered w/ signed certificates of

well-known CAs (root)• Root CAs can sign

• End user’s public key• Another (secondary) CA’s public key

• ==> Signing authority• ==> Certificate chain• ==> “Hierarchy of trust”



Certificate expiration and revocation list

• Invalidate public/secret key pair

• Loss/corruption/theft of secret key

• Change in ID info in certificate

• Compromise of CA’s secret key

• CRL: Certificate Revocation List

• Certificate expiration date (1 year)



Diffie-Helman: encrypton without authentication• Encryption + authentication usually

together• At least one party produces signed

certificate ==> no anonymous comm.• Diffie-Helman key exchange: negotiate

session key wo sending key• Each party picks partial key independently



Diffie-Helman (cont.)• Send part of key info

• Other side calculates common key value

• Eavesdropper can’t reconstruct key

• Use symmetric algorithm

• Discard session key at end

• No authentication ==> “man-in-the-middle” attack



Man-in-the-middle attack• A, B want to communicate

• C imposes in network between two wo arousing suspicions

• A negotiates w/ C thinking it’s B

• B negotiates w/ C thinking it’s A

• A & B sending messages, C relaying

• A & B think comm is secure; C reads & can modify

• Hard to accomplish



Securing private (secret) keys• Stored on hard disk encrypted• When first invoked, prompt for pass phrase

to unlock• Key read into memory• Problem: virus/other sw looking for private

keys• Solution: on ROM on smart card (take away)



Key length and security

• Longer key ==> more secure message

• How long? How secure?

• Good alg. + implementation + key management ==> brute-force only

• Cost to crack vs. cost of normal use

• Estimated cracking cost...



Estimated cracking cost...

Cost ($)

$ thousandsSecondsDaysMonths Eons> Age of universe

$ millions< 1 SecondHoursDaysMillennia> Age of universe

Key length 40 bits56 bits64 bits80 bits128 bits



Key length & US encryption policy

• Strong encryption classified as munition

• SW must get export license• RC2, RC4 w/ 40-bit keys (or less)• RSA w/ 512-bit keys• Digital signature but no encryption• Financial app’s (e.g., Quicken)



US policy continued

• Slowing effect on SW dev• Online products limited to export version• ==> Most browsers crippled• Servers overseas crippled• Must have both side for secure transaction• Versions of Netscape + IE exempt ==>128-

bit keys



Resources

• Stein’s on-line resource

• B. Schneier: Practical Cryptography, 2nd Edition (Wiley, 1995)

• R. E. Smith: Internet Cryptography (Addison-Wesley, 1997)



SSL, SET, and Digital Payment Systems

• Internet cryptographic protocols

• SSL: Secure Sockets Layer

• SET: Secure Electronic Transactions

• Other Digital Payment Systems



Internet cryptographic protocols

Protocol PurposeCyberCash Electronic funds transactions

DNSSEC Domain name systemIPSec Packet-level encryption

PCT TCP/IP-level encryption

PGP E-mail

S/MIME E-mail

S-HTTP Web browsing

Secure RPC Remote procedure calls

SET Electronic funds transactions

SSL TCP/IP-level encryption

SSH Remote login

TLS TCP/IP-level encryption



SSL: Secure Sockets Layer

• History

• Characteristics

• SSL Transaction



SSL History

• 1994: Netscape Navigator 1.0• 1994: S-HTTP (CommerceNet)• Similarities: digital envelopes, signed

certificates, message digest• Differences

• S-HTTP: Web protocol; pay (dead)• SSL: Lower level; free



SSL cracked

• 1995, 1997: 40-bit keys (1 wk, 3.5 hrs)

• 1997: predictable session keys

• 1997: sniffer ==> file sharing attack discovered



SSL Characteristics

Application

Transport

Internet

Network interface

Physical layer

SSL

TELNET NNTP

HTTP FTP

S-HTTP



SSL Characteristics (cont.)• Flexibility, protocol independence• Not specifically tuned for HTTP• SSL connection must use dedicated TCP/IP

socket• Distinct port for SSL-mode server (443)• Flexibility re symmetric encryption alg.,

message digest function, authentication method



SSL connection ==> all encrypted

• URL of requested document

• Contents of requested document

• Contents of any submitted form

• Cookies sent from browser to server

• Cookies send from server to browser

• Contents of HTTP header



SSL transaction

Client (browser) Server

1. ClientHello message

2. ServerHello (ack)

3. Server’s signed site certficate (+chain)[4. Request client’s certificate]

[5. Client’s certificate]

6. ClientKeyExchange message (symmetric session key, digital envelope)

[7. Certificate Verify message (digital signature)]8. ChangeCipherSpec messages (both)9. Finished messages (both)



SET: Secure Electronic Transactions

• What is SET?

• Why not just use SSL?

• SET in a Nutshell

• SET user interface



What is SET (Secure Electronic Transactions)?

• Cryptogrqphic protocol

• Visa, Mastercard, Netscape, Microsoft

• Only for credit- and debit-card transactions

• SET low-level services ...

• SET high-level features ...



SET low-level services ...

• Authentication

• Confidentiality

• Linkage



SET high-level features ...• Cardholder registration

• Merchant registration

• Purchase requests

• Payment authorization

• Payment capture (funds transfer)

• Chargebacks (refunds)

• Credits

• Credit reversals

• Debit card transactions



Why not just use SSL?

• SSL: no support for high-level features• Server-side security• Avoid misuse of credit card number

guessers• Avoid general-purpose U.S. export

restrictions• Financial transactions excluded



SET in a nutshell• 1. Customer initiates purchase

• 2. Client’s SW send order & payment info

• 3. Merchant passes payment info to bank

• 4. Bank checks validity of card

• 5. Card issuer authorizes & signs charge slip

• 6. Merchant’s bank authorizes transaction

• 7. Merchant’s Web server completes transaction

• 8. Merchant “captures” transaction

• 9. Card issuer sends bill to customer



SET notes (functional)

• Authentication in every phase• ==> Certificates for card issuer,

merchant’s bank• All must register

• ==> SW generates public & secret keys

• Two key pairs for certain parts of protocol



SET notes (technical)• Secure Hash Algorithms (SHA)

• ==> 160-bit hash• Public/secret key pair: RSA, 1,024 bit• Symmetric encryption: DES

• 56-bit key• ==> Cost of cracking assumed higher than

value of single credit card transaction



Other digital payment systems

• Why need other payment systems?

• First Virtual

• CyberCash

• DigiCash

• Millicent



Why need other payment systems?• SET: credit/debit cards

• ==> Transaction fees

• ==> Not economical for low-cost

• ==> Not good for impulse buying

• Not anonymous

• ==> E-money

• Cryptography ==> complex systems



First Virtual

• For intangibles (SW, web pages, games)• No encryption, all secret info previously

by phone• Only PIN #• Merchant has CGI script to validate PIN• E-mail to customer w/ details of purchase

to be approved



CyberCash

• User: CyberCash Wallet SW on PC

• Credit card / bank account info encrypted there

• Merchant: Electronic Cash Register SW on server

• Strong encryption

• High transaction overhead

• CyberCoin for small payments



DigiCash• Like phone cards/subway tokens

• CyberBucks: electronic voucher

• User mints, banks signs

• Cost of signing = face value

• Digitally signed w/ public key encryption

• Can’t trace, unless try to use twice

• Transmit money safely between peers wo bank



Millicent• DEC, late 1996• Low overhead, up to $5• Brokers & scrips (like gift certificate)• Merchant produces & validates• Broker sells at markup• ==> No centralized server for validation

(bottleneck)• No strong cryptography (small amounts)



Part II: Client-side security

• Using SSL

• Active content

• Web privacy



Using SSL

• SSL at work

• Personal certificates

• Checklist





SSL at work

• Establishing an SSL connection

• Things to watch for



Personal certificates

• VeriSign personal certificates

• Obtaining a VeriSign personal certificate

• Browser SSL settings



Checklist• Always use SSL browser for confidential info• Never use crippled export-grade cryptography

browser for confidential documents• Password-protect personal certificate• Never accept CA certificate from unknown Web

site• Back up personal certificates



Online Resources• VeriSign: http://www.verisign.com

• Sage passage: http://www.c2.net

• PGP: www.pgp.com

• RSA Data Security (S/MIME): http://www.rsa.com/rsa/S-MIME

• Simple Perl-based packet sniffer: http://www.genome.wi.mit.edu/~lstein/talks/WWW6/sniffer

• Tcpdump & libpcap (required for sniffer): ftp://ftp.ee.lbl.gov/tcpdump.tar.Z, libpcap.tar.Z



Printed Resources

• Grafinkel, Simson: Pretty Good Privacy, O’Reilly & Assoc. 1995



Active content• Bad by design or bad by accident?

• Traditional threats

• Helper applications and plug-ins

• Java

• ActiveX

• JavaScript and VBScript

• Exotic technologies

• What can you do

• Changing active content settings

• Checklist

• Resources



Bad by design or bad by accident?

• E.g., the Moldovan scam• Pornography site• Download viewer• Viewer disconnect user, turn off

speakers, reconnect to ISP in Moldova (“900”)

• Even when leave site, still connected



Traditional threats• Trojan horses

• Pretend; introduce viruses, etc.• Viruses• Macro viruses

• Across OSs• Rabbits: many copies• Worms: like rabbits, but spread across Net



Helper applications and plug-ins

• Keep to bare minimum

• Only from trusted sources

• Check vendor’s support pages for discovered security holes



Java

• Applet security restrictions

• Hostile applets

• Annoying applets

• Inadequate applets



Java applets

• <applet code = “example_applet” codebase = “http://www.some-server.org/some-directory/”<param name = “image” value = “example.gif”><param name = “color” value = “blue”></applet>



Applet security restrictions

• Applet cannot

• Read from / write to local disk

• Access physical HW

• Memory, disk drives, drivers

• Access sys env info

• Invoke sys commands / run external programs

• Open network connections, only “home” (“phone-home restriction”)



Hostile applets

• Failure of phone-home restriction

• Execute arbitrary machine instructions

• Bypass Java security manager with hand-crafted bytecode



Failure of phone-home restriction

• 1996, Steve Gibbons, Edward Felten (independetly)

• Temporary subvert domain-name system

• ==> Circumvent net connection restriction

• Send out hostile applet

• Contact any machine on Net

• Including on user’s side of firewall

• Navigator 2.0; fixed (?) 2.01



Execute arbitrary machine instructions

• Bug in Java interpreter loading of libraries

• ==> Remote users can circumvent

• Trick browser to download code library

• Disguise as “broken” inline image

• ==> Place in browser cache

• Send applet that loads code

• Library not restricted by security manager

• ==> Applet “broken out of sandbox”

• ==> Can do whatever it wishes

• Navigtor 2.0, 2.01; fixed 2.02



Bypass Java security manager with hand-crafted bytecode• Sun, March 1997

• Bug in Java bytecode verifier

• Hand-craft bytecode

• ==> Bypass Java security manager

• ==> Execute forbidden commands

• IE 3.01, NN 3.01; fixed later



Another phone-home restriction bug

• Applets make network connections to machines behind corporate firewall

• NN 3.02, 4.01; IE not known

• No known fix



Summary: No known attacks

• Any of bugs

• Theoretical

• Most closed

• Holes may exist

• Security model sound



Annoying applets• Infinite loop; slow machine• Allocate large memory structures• Make multiple copies of self in memory• Open window larger than desktop, prevent

from getting to other windows• Open new windows faster than user can

close• Windowing op’s that crash browser



Inadequate applets• Sandbox prevent bad and good

• Future: control stepping out

• Grant rights to read, write, print, make net connections

• Selected files, dirs., locations

• Code signing: authenticate ==> privileges

• For now: run or not



ActiveX

• ActiveX vs. Java

• Authenticode system

• Is ActiveX safe?



ActiveX control• <object

id = “example_control” classid = “clsid:7223B620-9FF9-11AF-00AA00C06662” codebase = “http://www.some-server.org/some-directory/” width = 70 height = 40><param name = “image” value = “example.gif”><param name = color” value = “blue”><param name = “_version” value = “3”></object>



ActiveX vs. Java

• Stripped down OLE

• Everything Java applets do

• Written in conventional language

• Compiled into machine native code

• Browser downloads control

• Calls O, load to mem, exec.

• Must be recompiled for OS / HW



Programmer’s advantages

• Use familiar compilers & languages

• Use existing programs, OLE components, libraries

• Controls can do anything

• Save to disk, report statistics, test network, check for viruses



Authenticode system



Is ActiveX safe?



JavaScript and VBScript

• JavaScript security problems

• VBScript security problems



JavaScript security problems

• Send email in user’s name

• Get directory listing on local file sys

• Upload contents of a file

• Monitor pages visited by user

• Log images viewed by user



VBScript security problems



Browser as security hole



Exotic technologies



What can you do

• General precautions

• User privileges

• Virus checkers

• Verify integrity of downloaded SW

• Backups

• Barring the gates



Changing active content settings

• Internet Explorer

• Netscape Navigator



Checklist



Resources



Web privacy

• What Web Surfing Reveals

• Server Logs

• Cookies

• PICS

• Advice for Users

• Advice for Webmasters

• Policy Initiatives

• Checklist

• Resources



Part III: Server-Side Security• Server Security• UNIX Web Servers• Windows NT Web Servers• Access Control• Encryption and Certificate-Based Access Control• Safe CGI Scripting• Remote Authoring and Administration• Web Servers and Firewalls



Server security

• Why Are Web Sites Vulnerable?

• Frequently Asked Questions About Web Server Security

• Overview: Steps to Securing a Web Site




UNIX Web servers

• Hardening a UNIX Web Server• Configuring the Web Server• Monitoring Logs• Monitor the Integrity of System Files and Binaries• Back Up Your System• Checklist• Online Resources• Printed Resources



Windows NT Web servers

• NT Security Concepts

• Windows NT Security Risks

• Securing a Windows NT Web Server

• Configuring the Web Server

• Checklist





Access control

• Types of Access Control

• Access Control Based on IP Address or Host Name

• Access Control Based on User Name and Password

• Other Types of Access Control

• Access Control and CGI Scripts

• Checklist




Encryption and Certificate-Based Access Control• SSL-Enabled Web Servers• Using Client Certificates for Access Control• Using Client Certificates for Web Server Access

Control• Becoming Your Own Certifying Authority• Final Words• Checklist• Online Resources• Printed Resources



Safe CGI Scripting

• Introduction to CGI Scripts and Server Modules• Common Failure Modes• Other Advice• Safe Scripting in Perl• CGI Wrappers• Checklist• Online Resources• Printed Resources



Remote Authoring and Administration• Degrees of Trust• Controlling Access to the Web Server Host• Remote Authoring Via FTP• Microsoft FrontPage• The HTTP PUT Protocol• An Upload Staging Area• Administering the Web Server Remotely • Access to the Server for Web Developers• Checklist• Online Resources• Printed Resources



Web Servers and Firewalls• What Is a Firewall?• Selecting a Firewall System• Configuring a Firewall• Automatic Proxy Configuration for Browsers• Examining Firewall Logs for Signs of Server

Compromise• Checklist• Online Resources• Printed Resources



Bibliography/references