Transcript Handout - Ohio State Computer Science and Engineering

Application Layer Security
Outline
r Email security
r Web security
r Social networking security
Email security
r Email is one of the most widely used and regarded
network services; essentially file transfer, except:
m
m
m
m
Sender and receiver not present at same time
Has diversity (character sets, headers, …)
Not a transparent channel (8 bit data, CRLF)
Often across realms
r Currently message contents are not secure
m May be inspected either in transit
m Or by suitably privileged users on destination system
r Often principals have not met previously ⇒ use chain
of certificates
Email security enhancements
r Confidentiality: protection from disclosure
r Authentication: of sender of message
r Message integrity: protection from modification
r Non-repudiation of origin: protection from denial by
sender
r Accounting, self-destruction, audit, anonymity, proof of
delivery…
Internet Email
r Protocol: SMTP:
m ASCII commands, responses
m Separate headers from envelope
m TCP port 25
m Uses DNS
m Binary content, structure
• MIME (multipurpose Internet mail extensions)
r Note: Mail servers and agents use SMTP for exchange,
email clients use SMTP typically for relaying only,
preferring POP/IMAP for receiving
Secure Email
Alice wants to send confidential email, m, to Bob.

KS
m
K ( .)
S
+
KS
KS(m )
KS(m )
+
.
KB( )
K+
B
+
KB(KS )
.
KS( )
-
Internet
+
KB(KS )
Alice:
 Generates random symmetric private key, KS
 Encrypts message with KS (for efficiency)
 Also encrypts KS with Bob’s public key
 Sends both KS(m) and KB(KS) to Bob
m
KS
-
.
KB( )
K-B
Network Security
Secure Email
Alice wants to send confidential email, m, to Bob.

KS
m
K ( .)
KS( )
S
+
KS
.
KS(m )
KS(m )
+
.
KB( )
K+
B
+
KB(KS )
-
Internet
m
KS
-
.
KB( )
+
KB(KS )
K-B
Bob:
 Uses his private key to decrypt and recover KS
 Uses KS to decrypt KS(m) to recover m
Network Security
Secure E-mail (Continued)

Alice wants to provide sender authentication message integrity
K+
A
K-A
m
.
H( )
-
.
KA( )
+
m


-
-
KA(H(m))
KA(H(m))
Internet
-
+
.
KA( )
compare
.
H( )
m
H(m )
H(m )
Alice digitally signs message
Sends both message (in the clear) and digital signature
Network Security
Secure Email (Continued)

Alice wants to provide secrecy, sender authentication,
message integrity.
-
KA
m
.
H( )
-
.
KA( )
-
KA(H(m))
+
KS
.
KS( )
+
m
KS
+
.
KB( )
K+
B
Internet
+
KB(KS )
Alice uses three keys: her private key, Bob’s public key,
newly created symmetric key
Network Security
Pretty Good Privacy (PGP)
r Widely used confidentiality and authentication
r
r
r
r
service for securing electronic mail and other file
storage applications
Developed by Phil Zimmermann
Selected best available crypto algorithms to use
Integrated into a single program available on PC,
Macintosh, Linux systems
Free and commercial versions (e.g., GPG)
PGP Operation Summary
Why Johnny (Still) Can’t Encrypt
r Usability studies (1999, 2007) showed majority of
users could not properly encrypt using PGP
r The user interface is not intuitive enough
m Transparency of encryption/signature is confusing
• Users seem to need feedback that email was secured
m
Verification is confusing
• Users don’t follow the reasoning for verification
Outline
r Email security
r Web security
r Social networking security
The Web
r Web page:
m
m
Consists of “objects”
Addressed by a URL
r Most Web pages
r User agent for Web is
called a browser:
m
m
consist of:
m
m
Base HTML page, and
Several referenced
objects.
r Server for Web is
called Web server:
m
r URL has two
components: host
name and path name
MS Internet Explorer
Netscape
Communicator
m
m
Apache (public
domain)
MS Internet
Information Server
Nginx (public domain)
The Web: the HTTP Protocol
HTTP: HyperText Transfer
Protocol
r
r
r
r
Web’s application layer protocol
Client/server model
m Client: browser that requests,
receives, “displays” Web
objects
m Server: Web server sends
objects in response to requests
HTTP 1.0: RFC 1945
HTTP 1.1: RFC 2068
PC running
Explorer
Server
running
NCSA Web
server
Mac running
Navigator
The HTTP Protocol (more)
HTTP: TCP transport service:
r
r
r
r
Client initiates TCP connection
(creates socket) to server, port 80
Server accepts TCP connection
from client
HTTP messages (application-layer
protocol messages) exchanged
between browser (HTTP client)
and Web server (HTTP server)
TCP connection closed
HTTP is “stateless”
r
Server maintains no
information about past
client requests
aside
Protocols that maintain “state”
are complex!
r Past history (state) must be
maintained
r If server/client crashes, their
views of “state” may be
inconsistent, must be
reconciled
HTTP Example
Suppose user enters URL http://www.someschool.edu/aDepartment/index.html
1a. HTTP client initiates TCP
connection to http server (process)
at www.someschool.edu. Port
80 is default for HTTP server.
2. HTTP client sends http request
message (containing URL) into
TCP connection socket
time
(contains text,
references to 10
JPEG images)
1b. HTTP server at host
www.someschool.edu waiting
for TCP connection at port 80.
“Accepts” connection, notifies
client
3. HTTP server receives request
message, forms response message
containing requested object
(aDepartment/index.html),
sends message into socket
HTTP Example (Cont.)
4. HTTP server closes TCP
5. HTTP client receives response
message containing HTML file,
displays HTML. Parsing HTML file,
finds 10 referenced JPEG objects
time 6. Steps 1-5 repeated for each of 10
JPEG objects
connection.
HTTP Message Format: Request
r
r
Two types of HTTP messages: request, response
HTTP request message:
m
ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg
header Accept-language:fr
lines
Carriage return,
line feed
indicates end
of message
(extra carriage return, line feed)
HTTP Message Format: Response
status line
(protocol
status code
status phrase)
header
lines
HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
data, e.g.,
requested
html file
Threat: Information Leakage
• Sensitive information can be leaked via Web:
– All files accessible under a Web directory can be
downloaded via GET requests
– Example 1:
• http://www.website.com/secret.jpg publicly accessible
• http://www.website.com/index.html has no link to secret.jpg
• Attacker can still download secret.jpg via GET request!
–
Example 2: searching online for “proprietary
confidential” information
Threat: Misleading Websites
r Cybersquatters can register domain names similar
to (trademarked) company, individual names
r Example: http://www.google.com vs.
http://gogle.com vs. …
r Practice is illegal if done “in bad faith”
r Arbitration procedures available for name
reassignment (ICANN)
Threat: XSS and CSRF
• Cross-site scripting (XSS): inject JavaScript from
external source into insecure websites
–
Example: input <script
type=“text/javascript”><!--evil code-></script>
• Cross-site request forgery (CSRF): force victim
browser to send request to external website →
performs task on browser’s behalf
–
Example: force load <img
src=“http://www.bigbank.com/transferF
unds.php?from=User&to=Attacker”/>
Threat: SQL Injection
r Common vulnerability (~71 attacks/hour [18])
r Exploits Web apps that [17, 19]
m Poorly validate user input for SQL string literal escape
characters, e.g., '
r Example: [19]
m "SELECT * FROM users WHERE name = '" +
userName + "';"
• If userName is set to ' or '1'='1, the resulting SQL is
SELECT * FROM users WHERE name = '' OR
'1'='1';
• This evaluates to SELECT * FROM users ⇒ displays all
users
Threat: Malicious Shellcode
• Shellcode is non-self-contained binary executable code
– Distinct from malware that executes on its own
– Shellcode can only execute after injection into a running process’s
virtual address space
• Most shellcode written in Intel IA-32 assembly language
(x86)
• When injected into JS code, shellcode executes
–
–
Hijacks browser process
Can totally control target process or system
• Shellcode: attack vector for malicious code execution on
target systems (e.g., Conficker worm)
–
–
Usually, browser downloads JS code containing shellcode
JS code executes, controls target process/system
Threat: Shellcode Example
• Shellcode for exit() system call
– Store 0 into register ebx
– Store 1 into register eax
– Execute instruction int 0x80
• Assembled shellcode injected into
JS code
mov ebx, 0
mov eax, 1
int 0x80
Shellcode
assembly
bb 00 00 00 00 b8 01
00 00 00 cd 80
Binary
payload
injection
JS code ...3caabb00000000b801000000cd80ad46...
more JS code
Disguised as normal data; injected into target processes’ address spaces;
compromises target processes’ security
Defense: HTTPS (HTTP Secure)
• HTTPS uses cryptography with HTTP (TLS, SSL)
– Alice, Bob have public, private keys; public keys
accessible via certificate authority (CA)
– Alice encrypts message with Bob’s public key, signs
message with her private key
– Bob decrypts message with his private key, verifies
message using Alice’s public key
– Once they “know” each other, they can communicate
via symmetric crypto keys
• HTTPS provides greater assurance than HTTP
Defense: Blacklist Filtering (1)
• Misleading websites: register domain names similar to
trademarks, e.g., www.google.com, gogle.com, etc.
• XSS:
– Validate user input; reject invalid input
– Blacklist offending IP addresses
• CSRF:
– Use random “token” in web app forms
– If token is replayed, reject form (blacklist IP addresses)
• SQL injection:
– Validate user input to databases, reject invalid input
– Blacklist IP addresses
– Helpful browser extensions:
m NoScript/NotScripts/… (stop XSS)
m AdBlock (can stop malicious scripts in ads)
m SSL Everywhere (force HTTPS)
m Google Safe Browsing
Defense: Shellcode
r Two main detection approaches:
m Content Analysis
• Checks objects’ contents before using them
• Decodes content into instruction sequences, checks if
malicious
m
Hijack Prevention
• Focuses on preventing shellcode from being fully executed
• Randomly inserts special bytes into objects’ contents, raises
exception if executed
• Can be thwarted using several short “connected” shellcodes
Defense: Shellcode: Content
Analysis
• Two major types of content analysis:
– Static Analysis
• Uses signatures, code patterns to check for malicious instructions
• Advantage: Fast
• Disadvantages: Incomplete; can be thwarted by obfuscation
techniques
–
Dynamic Analysis
• Detects a malicious instruction sequence by emulating its
execution
• Advantages: Resistant to obfuscation; more complete than static
analysis
• Disadvantage: Slower
• Focus on dynamic analysis (greater completeness)
Defense: Shellcode: Dynamic
Analysis
• Approaches assume self-contained shellcodes
• Analyses’ shellcode emulation:
– Inefficiently uses JS code execution environment information
– All memory reads/writes only go to emulated memory system
– Detection uses GetPC code
• Current dynamic analysis approaches can be fooled:
– Shellcode using JS code execution environment info
– Shellcode using target process virtual memory info
– Shellcode not using GetPC code
• To detect all malicious shellcodes, we need a better
approach
Defense: Shellcode: JSGuard (1)
• Our design rationale: [20]
– Use dynamic analysis to detect malicious JS objects
• Create a virtual execution environment for detection
– Leveraging: (1) target processes’ virtual memory information; (2)
target systems’ context information in detection
– NOT a whole-system emulator
–
Facilitate multiple-level redundancy reduction
• Stack frames: check origins of JS code being interpreted
• Native methods: check if native methods to be called originate from JS
interpreter or external components
• Objects’ properties
• Assume: JS interpreter’s (native) methods have no
memory errors
Defense: Shellcode: JSGuard (2)
• It’s hard to fool our method: [20]
– Shellcode can use JS code execution environment
information to fool other dynamic analysis approaches
• Our design leverages system’s context information
–
Shellcode can use target process’s virtual memory
information to fool other dynamic analysis approaches
• Our design uses target processes’ virtual memory information
–
Shellcode can avoid GetPC code to fool other dynamic
analysis approaches
• Our method does not rely on GetPC code for detection. We
leverage real virtual memory content to decode instructions
and emulate their execution
Defense: Shellcode: JSGuard (3)
r JSGuard architecture shown in figure below [20]
r We mainly check JSString objects for shellcode injection (hard
to inject shellcode in other JS objects)
r Architecture runs in client-side application’s address space
(Firefox browser)
r JSString objects input to malicious JSString detector, which
scans for shellcode using shellcode analyzer
Source: [20]
Outline
r Email security
r Web security
r Social networking security
Online Social Networking (OSN)
r Online Web services
enabling people to
connect with each other,
share information
m
m
m
Common friends,
interests, personal info…
Post photos, videos, etc.
for others to see
Communicate via email,
instant message, etc.
r Major OSN services:
Facebook, Twitter,
MySpace, LinkedIn, etc.
Benefits of OSN Communication
r Vast majority of college students use OSNs
m Organizations want to market products, services, etc.
to this demographic
m OSNs can help them reach these potential buyers
r OSNs provide communal forum for expression
(self, group, mass), collaboration, etc.
Connect with old friends, find new friends and connect
m Play games with friends, e.g., Mafia Wars, Scrabulous
m Commerce in “virtual items”
m
r But using OSNs poses security issues for orgs as
well as individuals
Mobile Social Networking (MSN)
r E-SmallTalker
r E-Shadow
38
Small Talk
r People come into contact opportunistically
r Face-to-face interaction
m Crucial to people's social networking
m Immediate non-verbal communication
m Helps people get to know each other
m Provides the best opportunity to expand social network
r Small talk is an important social lubricant
m Difficult to identify significant topics
m Superficial
39
A Naive Approach of Smartphonebased Small Talk
Main Idea
Store all user information,
including each user’s full
contact list
r User report either his own geolocation or a collection of
phone IDs in his physical
proximity to the server using
Internet connection, SMS
r Server performs profile
matching, finds out small talk
topics (mutual contact,
common interests, etc.)
r Results are pushed to or
retrieved by users
r
Problems
r Require costly data services
(phone’s internet connection,
SMS)
r Require report and store
sensitive personal
information in 3rd party
r Trusted server may not exist
r Server is a bottleneck, single
point of failure, target of
attack
40
E-SmallTalker – A Fully Distributed
Approach
r No Internet connection required
r No trusted 3rd party
r No centralized server
r Information stored locally on mobile phones
r Original personal data never leaves a user’s phone
r Communication only happens in physical proximity
41
E-Shadow
r Enhanced E-SmallTalker
m Local profiles
m Mobile phone based local social interaction tools
• E-Shadow publishing
• E-Shadow localization
Threats: OSNs
r Malware distribution
r Cyber harassment, stalking, etc.
r Information “shelf life” in cyberspace
r Privacy issues:
m Information about person posted by him/herself,
others
m Information about people collected by OSNs
r Information posted on OSNs impacts
unemployment, insurance, etc.
r Organizations’ concerns: brand, laws,
regulations
Threats: MSN
r Personal information leakage
m
Particularly dangerous because of physical proximity
r Malware distribution
44
Defense: OSN “Common Sense”
Measures (1)
r Use strong, unique passwords
r Provide minimal personal information: avoid entering
birthdate, address, etc.
r Review privacy settings, set them to “maximum privacy”
m
“Friends of friends” includes far more people than “friends only”
r Exercise discretion about posted material:
m Pictures, videos, etc.
m Opinions on controversial issues
m Anything involving coworkers, bosses, classmates, professors
m Anything related to employer (unless authorized to do so)
r Be wary of 3rd party apps, ads, etc. (P.T. Barnum’s quote)
r Supervise children’s OSN activity
Defense: OSN “Common Sense”
Measures (2)
r “If it sounds too good to be true, it probably is”
r Use browser security tools for protection:
m Anti-phishing filters (IE, Firefox)
m Web of Trust (crowdsourced website trust)
m AdBlock/NoScript/Do Not Track Plus
r Personal reputation management:
m Search for yourself online, look at the results…
m Google Alerts: emails sent daily to you about results
for any search query (free), e.g., your name
r Extreme cases:
m Cease using OSNs, delete accounts
m Contact law enforcement re. relentless online
harassment
Defense: MSN: E-SmallTalker: PrivacyPreserved Information Exchange



Example of Alice’s Bloom filter
Alice has multiple contacts,
such as Bob, Tom, etc.
Encode contact strings,
Firstname.lastname@phone_nu
mber, such as
“Bob.Johnson@5555555555”
and
“Tom.Mattix@6141234567”
47
Defense: MSN: E-Shadow: Layered
Publishing
r Spatial Layering
m WiFi SSID
• at least 40-50 meters, 32 Bytes
m
Bluetooth Device (BTD) Name
• 20 meters, 2k Bytes
m
Bluetooth Service (BTS) Name
• 10 meters, 1k Bytes
r Temporal Layering
m For people being together long or repeatedly
m Erasure Code
Final Remarks
r Unencrypted email is easily intercepted
m PGP, GPG can provide confidentiality, integrity, client
authentication via encryption
r Web traffic vulnerable to attacks
m Defenses include domain name registration, blacklists,
browser extensions, and malicious code detection
r Social networking attacks are possible both online
and via mobiles
m
m
Follow “common sense” for online social networks
Mechanisms like Bloom filters, layered publishing can
help safeguard personal information
Acknowledgment
These slides are partially based on:
J.F. Kurose and K.W. Ross, Computer Networking: A Top-Down Approach
Featuring the Internet, Addison Wesley, 2011
A. Arora, “Lecture 5: Email security: PGP”, http://www.cse.ohiostate.edu/~anish/694KNotes/694Lecture5.ppt
W. Stallings, Network Security Essentials, Pearson, 2014,
http://williamstallings.com/NetworkSecurity/NetSec5e-Instructor/ (Ch. 8)
A.C. Champion and D. Xuan’s CSE 4471 slides, http://www.cse.ohiostate.edu/~champion/4471/4471_web_security_handout.pdf
http://www.cse.ohiostate.edu/~champion/4471/4471_social_network_security_handout.pdf