Intrusion Detection-..

Mikin Macwan CS 599 Spring '04

Client-Side defense against web-based identity theft

Presented by: Mikin MacwanSpecial Topics in Operating

systems and Distributed storage


Typical Phishing Characteristics

Link as Seen by User

Scam Email



Confidential information

Honest Image



Summary

Email title: "to users of eBay!"

Scam target: eBay users

Email format: A HTML with only a single picture in it, linking to the phish site

Sender: [email protected]

Sender spoofed? No

Scam call to action: "we could't verify your current information...your access to bid or buy on eBay has been restricted"

Scam goal: Getting victim's eBay, credit card and ATM PIN information

Call to action format: URL link

Visible link: https://scgi.ebay.com/saw-cgi/ebayISAPI.dll?VerifyInformation

Called link : http://%61%77%63%67%69%2E%69%6E%66%6F/%69%6E%64%65%78%2E%68%74%6D

Resolved site: http://ebaycom.%70%65%2e%6b%67/

Site URL decodes to: awcgi.info/index.htm


Terminology Spoof site: site or page which is a malicious

copy of some legitimate web page Attacker: the person or organization who

sets up the spoof site Honest site or honest page: the

legitimate site or page that is being spoofed Spoof Index: A measure of the likelihood

that a specific page is part of a spoof attack


Proposed Solutions Proposed Solutions to detect spoof pages from honest pages [1]

Scoring Described in the next slide

Stateless page Evaluation Includes tests conducted on the current web page only

Stateful page evaluation Browser History file and additional history stored by SpoofGaurd are

used to evaluate the referring page No warnings issued for visiting a site that is already in the users history

file Evaluating post data

User input intercepted by SpoofGaurd and html post data is checked Actual client data post allowed to proceed only if spoof index is below

the user specific thresholds for posts Stateful and stateless Page checks are combined with the analysis of the

post data to determine the spoof index associated with the web page.


Solutions: Scoring Input

Downloaded web page Existing browser state

Apply Tests T1, T2, …, Tn Each test Ti produces number Pi Pi is in the range [0,1] (Pi = 1: spoof page, Pi

= 0: honest page) Combine test results to generate a Total

Spoof Score

Product “Pi*Pj*Pk” Considers combinations of events and

determine likelihood of a page being a spoof Example: Consider the following condition

Presence of company logo on unauthorized page AND

Presence of password and credit card fields


Solutions: Stateless page evaluation (1/2)

URL check Attackers can produce misleading URLs Consider the following URL

http://don’[email protected]/my-phish-page.htm Text in blue lies between “http:” and “@”. Everything between “http” and “@” is

irrelevant Text in red is relevant and is the valid URL

Image check Spoof sites contains images taken from the honest site. Honest site images used in phish sites give an impression to unsuspecting

users that they are communicating with the honest site itself SpoofGaurd plug-in supplied with a database images with their associated

domains When browser downloads login page, all images on the page are compared

to images stored in the spoof guard database Spoof score increased if a match is found but the page’s domain is not valid


Solutions: Stateless page evaluation (2/2)

Link check All links within a page are examined Link check fails for a page if at least one fourth of the links fail the

URL check described above Password check

A page is considered suspicious if it asks for a user to enter some password.

Also check if secure http is being used and if so whether the certificate check succeeded or failed


Solutions: Stateful page evaluation (1/1)

Domain check SpoofGaurd currently compares domains by Hamming (edit) distance Example

efrade.com – considered as a spoof domain name Etrade.com – considered as a legitimate domain name Hamming distance -> ONE

Another Example Cnn.com – is a legitimate domain name Cnnfn.com – is flagged by SpoofGaurd as spoof page

Caveat Outsourced web pages to contractors with different domain names. Leads to false alarms in current version of SpoofGaurd

Referring Page Browser maintains a record of the referring page. Since a typical web spoofing attack begins with an E-mail message, a

referring page from a web site where the user may have been reading e-mail raises suspicion levels


Solutions: Evaluating post data Outgoing password check

Spoofguard maintains a database of <domain, user name, password> triplets

Is user reuses password on a new domain, this trips password check

Interaction with image check Image check interacts with the outgoing password check

non-linearly. If E-trade password is entered on a non E-trade page

containing an E-trade logo then spoof index is raised. Check of all post data

All outgoing post data is checked by SpoofGaurd. Exception for search engines


SpoofGaurd Architecture

COM Component extends IDeskBand (IE Interface)

CWindowImpl class implementations


Spoof Guard Architecture Implemented as a browser plug-in or a

browser helper object (COM component) SpoofGaurd runs in the same memory context

as the browser Access is made to the IE history file Three additional files are stored

Read-only file of hostnames of E-mail sites like Hotmail, Yahoo! Etc

Hashed password history (domain, user name, password)

File of hashed image history


Spoofguard Configuration


SpoofGuard in Action


Server Side Assistance: Confidentiality Tags

Confidentiality Tags Add a confidentiality attribute to the

<INPUT> html element This will help SpoofGuard to determine

how to process the field and thus warn the user

Possible confidential fields can be Name, Password, SSN etc.


Server Side Assistance: Image Tagging

Add a new attribute to IMG element in HTML page

Enables honest sites to identify images on their pages that are not supposed to appear outside their domain

SpoofGuard attribute indicates that a page is a likely spoof if the image appears on a non honest web page


Server Side Assistance: Password Hashing and Site Specific Salt

Attackers break into a low security site and recover logins and passwords

They then use this information to break into more secure sites

Passwords can be made independent of passwords at other sites by adding a password SALT to the html <INPUT> element

Site developers need to ensure that salt is unique for that web site


Evaluation SpoofGuard evaluated based on the following criteria

Detection of Spoof Attacks Tested SpoofGuard on 14 spoof pages (sent US Secret Service) Default settings were used to obtain SpoofGuard messages All fourteen spoof pages had password input fields – 100 %

detection Pages included images, retrieved directly from honest servers.

Images were stored in SpoofGuard image file as a result of initial navigation to that site.

Mock sign in on spoof page using “hello” and “test”, the same pair used on the honest eBay site during the initialization part of the experiment

False alarm rate

How difficult is it to write a spoof page that is not detected by SpoofGuard?


Security Attacker can circumvent current tests

proposed Password comparisons could fail Attacker could fool tests by breaking the password

input field into 2 or more adjacent fields that appear contiguous

Images could be sliced and uploaded on spoof web pages

These individual slices do not match images in the plug in database, but to the user this image would appear authentic

Although there are limitations, authors claim that it is difficult for attackers to set up spoof web sites


Performance Tests were conducted on a

1 GHz Pentium III with 128 MB RAM 10 Mbps Ethernet Card 779 milliseconds to navigate from one page

to another without SpoofGuard, with cache 484 milliseconds

911 milliseconds to navigate from one page to another with SpoofGuard, with cache 601 milliseconds

CPU usage was 30% without SpoofGuard and 40% with SpoofGuard


Pros &Cons Pros

A new direction in the area of web spoofing Implementation of Software, provides proof of

concept Software functionality does not cause high overhead

Cons Some techniques may not be foolproof Server side assistance techniques requires

collaboration with E-commerce sites User Interface may be a little annoying Users may not be sufficiently educated to set the

right threshold parameters to detect spoofs


References:

N.Chou, R. Ledesma, J. Mitchell et.al. “Client Side defense against web-based identity theft”.

Anti-Phishing Working Group “ www.antiphishing.org”

Intrusion Detection-..

Documents

Transcript of Intrusion Detection-..