Application Layer Security

Outline

Email security Web security Social networking security

Email security

Email is one of the most widely used and regarded network services; essentially file transfer, except: Sender and receiver not present at same time Has diversity (character sets, headers, …) Not a transparent channel (8 bit data, CRLF) Often across realms

Currently message contents are not secure May be inspected either in transit Or by suitably privileged users on destination system

Often principals have not met previously use chain of ⇒certificates

Email security enhancements

Confidentiality: protection from disclosure

Authentication: of sender of message

Message integrity: protection from modification

Non-repudiation of origin: protection from denial by sender

Accounting, self-destruction, audit, anonymity, proof of delivery…

Internet Email

Protocol: SMTP: ASCII commands, responses Separate headers from envelope TCP port 25 Uses DNS Binary content, structure

• MIME (multipurpose Internet mail extensions)

Note: Mail servers and agents use SMTP for exchange, email clients use SMTP typically for relaying only, preferring POP/IMAP for receiving

Secure Email

Network Security

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

Alice wants to send confidential email, m, to Bob.

KS( ).

KB( ).+

+ -

KS(m )

KB(KS )+

m

KS

KS

KB+

Internet

KS( ).

KB( ).-

KB-

KS

mKS(m )

KB(KS )+

Secure Email

Network Security

Bob: Uses his private key to decrypt and recover KS

Uses KS to decrypt KS(m) to recover m

Alice wants to send confidential email, m, to Bob.

KS( ).

KB( ).+

+ -

KS(m )

KB(KS )+

m

KS

KS

KB+

Internet

KS( ).

KB( ).-

KB-

KS

mKS(m )

KB(KS )+

Secure E-mail (Continued)

Network Security

Alice wants to provide sender authentication message integrity

Alice digitally signs message Sends both message (in the clear) and digital signature

H( ). KA( ).-

+ -

H(m )KA(H(m))-

m

KA-

Internet

m

KA( ).+

KA+

KA(H(m))-

mH( ). H(m )

compare

Secure Email (Continued)

Network Security

Alice wants to provide secrecy, sender authentication, message integrity.

Alice uses three keys: her private key, Bob’s public key, newly created symmetric key

H( ). KA( ).-

+

KA(H(m))-

m

KA

-

m

KS( ).

KB( ).+

+

KB(KS )+

KS

KB+

Internet

KS

Pretty Good Privacy (PGP)

Widely used confidentiality and authentication 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

Usability studies (1999, 2007) showed majority of users could not properly encrypt using PGP

The user interface is not intuitive enough Transparency of encryption/signature is confusing

• Users seem to need feedback that email was secured Verification is confusing

• Users don’t follow the reasoning for verification

Outline

Email security Web security Social networking security

The Web Web page:

Consists of “objects” Addressed by a URL

Most Web pages consist of: Base HTML page, and Several referenced

objects. URL has two

components: host name and path name

User agent for Web is called a browser: MS Internet Explorer Netscape

Communicator Server for Web is

called Web server: Apache (public

domain) MS Internet

Information Server Nginx (public domain)

The Web: the HTTP Protocol

HTTP: HyperText Transfer Protocol

Web’s application layer protocol Client/server model

Client: browser that requests, receives, “displays” Web objects

Server: Web server sends objects in response to requests

HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068

PC runningExplorer

Server running

NCSA Webserver

Mac runningNavigator

HTTP request

HTTP request

HTTP response

HTTP response

The HTTP Protocol (more)HTTP: TCP transport service: 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” Server maintains no

information about past client requests

Protocols that maintain “state” are complex!

Past history (state) must be maintained

If server/client crashes, their views of “state” may be inconsistent, must be reconciled

aside

HTTP ExampleSuppose 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

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

time

(contains text, references to 10 JPEG images)

HTTP Example (Cont.)

5. HTTP client receives response message containing HTML file, displays HTML. Parsing HTML file, finds 10 referenced JPEG objects

6. Steps 1-5 repeated for each of 10 JPEG objects

4. HTTP server closes TCP connection.

time

HTTP Message Format: Request

Two types of HTTP messages: request, response HTTP request message:

ASCII (human-readable format)

GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr

(extra carriage return, line feed)

request line(GET, POST,

HEAD commands)

header lines

Carriage return, line feed

indicates end of message

HTTP Message Format: Response

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 ...

status line(protocol

status codestatus phrase)

header lines

data, e.g., requestedhtml 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

Cybersquatters can register domain names similar to (trademarked) company, individual names

Example: http://www.google.com vs. http://gogle.com vs. …

Practice is illegal if done “in bad faith” 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/transferFunds.php?from=User&to=Attacker”/>

Threat: SQL Injection

Common vulnerability (~71 attacks/hour [18]) Exploits Web apps that [17, 19]

Poorly validate user input for SQL string literal escape characters, e.g., '

Example: [19] "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, 0mov eax, 1int 0x80

bb 00 00 00 00 b8 01 00 00 00 cd 80

...3caabb00000000b801000000cd80ad46..

.

Binary payloadinjection

Shellcode assembly

JS code 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: NoScript/NotScripts/… (stop XSS) AdBlock (can stop malicious scripts in ads) SSL Everywhere (force HTTPS) Google Safe Browsing

Defense: Shellcode

Two main detection approaches: Content Analysis

• Checks objects’ contents before using them• Decodes content into instruction sequences, checks if

malicious 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)

JSGuard architecture shown in figure below [20] We mainly check JSString objects for shellcode injection (hard

to inject shellcode in other JS objects) Architecture runs in client-side application’s address space

(Firefox browser) JSString objects input to malicious JSString detector, which

scans for shellcode using shellcode analyzer

Source: [20]

Outline

Email security Web security Social networking security

Online Social Networking (OSN)

Online Web services enabling people to connect with each other, share information Common friends, interests,

personal info… Post photos, videos, etc. for

others to see Communicate via email,

instant message, etc. Major OSN services:

Facebook, Twitter, MySpace, LinkedIn, etc.

Benefits of OSN Communication

Vast majority of college students use OSNs Organizations want to market products, services, etc.

to this demographic OSNs can help them reach these potential buyers

OSNs provide communal forum for expression (self, group, mass), collaboration, etc. Connect with old friends, find new friends and connect Play games with friends, e.g., Mafia Wars, Scrabulous Commerce in “virtual items”

But using OSNs poses security issues for orgs as well as individuals

Mobile Social Networking (MSN)

E-SmallTalker

E-Shadow

38

Small Talk

People come into contact opportunistically Face-to-face interaction

Crucial to people's social networking Immediate non-verbal communication Helps people get to know each other Provides the best opportunity to expand social network

Small talk is an important social lubricant Difficult to identify significant topics Superficial

39

A Naive Approach of Smartphone-based Small Talk

Main Idea Store all user information,

including each user’s full contact list

User report either his own geo-location or a collection of phone IDs in his physical proximity to the server using Internet connection, SMS

Server performs profile matching, finds out small talk topics (mutual contact, common interests, etc.)

Results are pushed to or retrieved by users

Problems Require costly data services

(phone’s internet connection, SMS)

Require report and store sensitive personal information in 3rd party

Trusted server may not exist Server is a bottleneck,

single point of failure, target of attack

40

E-SmallTalker – A Fully Distributed Approach No Internet connection required No trusted 3rd party No centralized server

Information stored locally on mobile phones Original personal data never leaves a user’s phone Communication only happens in physical proximity

41

E-Shadow

Enhanced E-SmallTalker Local profiles Mobile phone based local social interaction tools

• E-Shadow publishing• E-Shadow localization

Threats: OSNs

Malware distribution Cyber harassment, stalking, etc. Information “shelf life” in cyberspace Privacy issues:

Information about person posted by him/herself, others

Information about people collected by OSNs Information posted on OSNs impacts

unemployment, insurance, etc. Organizations’ concerns: brand, laws,

regulations

Threats: MSN

Personal information leakage Particularly dangerous because of physical proximity

Malware distribution

44

Defense: OSN “Common Sense” Measures (1) Use strong, unique passwords Provide minimal personal information: avoid entering

birthdate, address, etc. Review privacy settings, set them to “maximum privacy”

“Friends of friends” includes far more people than “friends only” Exercise discretion about posted material:

Pictures, videos, etc. Opinions on controversial issues Anything involving coworkers, bosses, classmates, professors Anything related to employer (unless authorized to do so)

Be wary of 3rd party apps, ads, etc. (P.T. Barnum’s quote) Supervise children’s OSN activity

Defense: OSN “Common Sense” Measures (2) “If it sounds too good to be true, it probably is” Use browser security tools for protection:

Anti-phishing filters (IE, Firefox) Web of Trust (crowdsourced website trust) AdBlock/NoScript/Do Not Track Plus

Personal reputation management: Search for yourself online, look at the results… Google Alerts: emails sent daily to you about results

for any search query (free), e.g., your name Extreme cases:

Cease using OSNs, delete accounts Contact law enforcement re. relentless online

harassment

Defense: MSN: E-SmallTalker: Privacy-Preserved Information Exchange

Example of Alice’s Bloom filter Alice has multiple contacts,

such as Bob, Tom, etc. Encode contact strings,

Firstname.lastname@phone_number, such as “Bob.Johnson@5555555555” and

“Tom.Mattix@6141234567”

47

Defense: MSN: E-Shadow: Layered Publishing Spatial Layering

WiFi SSID• at least 40-50 meters, 32 Bytes

Bluetooth Device (BTD) Name • 20 meters, 2k Bytes

Bluetooth Service (BTS) Name• 10 meters, 1k Bytes

Temporal Layering For people being together long or repeatedly Erasure Code

Final Remarks

Unencrypted email is easily intercepted PGP, GPG can provide confidentiality, integrity, client

authentication via encryption Web traffic vulnerable to attacks

Defenses include domain name registration, blacklists, browser extensions, and malicious code detection

Social networking attacks are possible both online and via mobiles 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.ohio-state.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.ohio-state.edu/~champion/4471/4471_web_security_handout.pdfhttp://www.cse.ohio-state.edu/~champion/4471/4471_social_network_security_handout.pdf