Transcript PPTX Clickjacking: Attacks and Defenses

Clickjacking: Attacks and Defenses
Lin-Shung Huang, Alexander Moshchuk, Helen J. Wang, Stuart
Schechter, and Collin Jackson
Carnegie Mellon University
Microsoft Research
USENIX Security Symposium 2012
Outline
•
•
•
•
•
•
•
•
Clickjacking Introduction
Existing Attacks
Existing Defenses
New Attack Variants
InContext Defense
Prototype Implementation
Experiments
Conclusion
Introduction
• Root Cause of clickjacking: an attack application presents a
sensitive UI element of a target application out of context to a
user
• Hiding the sensitive UI by making it transparent
• Some possible risks caused by clickjacking
• Web-surfing-anonymity can be compromised
• User’s private data and emails can be stolen
• Spy on a user through her webcam
Existing Attacks
• Three kinds of clickjacking attack:
• Compromising target display integrity
• Compromising pointer integrity
• Compromising temporal integrity
Compromising Target Display
Integrity
• Hiding the target element
• Using CSS opacity property and z-index property to hide
target element a make other element float under the target
element
• Using CSS pointer-events: none property to cover other
element over the target element
opacity: 0.1
pointer-event: none
Click Event
z-index: -1
Click Event
Compromising Target Display
Integrity (Cont.)
• Partial Overlays
• Overlay other elements onto an iframe using CSS z-index
property or Flash Window Mode wmode=direct porperty
• Cropping
• Wrapping target element in a new iframe and choose CSS
position offset propertites
z-index: 1
Paypal iframe
Paypal iframe
Cropping
Compromising Pointer Display
Integrity
• Hiding real cursor and create fake cursor
• Using CSS cursor property and JavaScript to simulate a fake
cursor icon on the screen
Real Cursor Icon
cursor: none
Fake Cursor Icon
Compromising Pointer Display
Integrity (Cont.)
• Keyboard focus “strokejacking” attack
• Simulate an input field getting focus, but actually the keyboard
focus is on target element, forcing user to type some
unwanted information into target element
Attacker’s page
Typing Game
Type what ever screen shows to you
Target Page (hidden iframe) within attacker’s page
Bank Transfer
9540
Bank Account: ________
3062
Amount: ___________
USD
Xfpog95403poigr06=2kfpx
[__________________________]
Transfer
Compromising Temporal Display
Integrity
• Cheat user within a short time
• Manipulate UI elements after the user has decided to click, but
before the actual click occurs
Click Event
Consequences
• Tweetbomb: hide tweet button and trick user to click
overlapping elements
• Facebook “Likejacking” attackes
• Trick user to click OAuth approval page and steal user’s private
data
• Upload private files via HTML5 File API
Existing Anti-clickjacking Defenses
• Same-origin-policy is not working here!
• FrameKiller: using JavaScript to detect whether target page is
inside an iframe or not
• Cons: not working on Facebook Like button
• User Confirmation: Ask user to re-verify the click event
• Cons: degrades user experience
• UI Randomization: Randomize the position of the Pay button
• Cons: attacker may ask victim to keep clicking until succeed
Existing Anti-clickjacking Defenses
(Cont.)
• Opaque Overlay Policy: forces all cross-origin frames to be
rendered opaquely
• Cons: may break other benign websites
• Framebusting: similar to FrameKiller, but use HTTP header XFrame-Options to ask browser not the render this page
inside an iframe
• Cons: same as FrameKiller, Facebook Like Button must within an
iframe
Existing Anti-clickjacking Defenses
(Cont.)
• Visibility Detection on Click: block mouse clicks if the browser
detect that the clicked cross-origin frame is not fully visible
• ClearClick: comparing the bitmap of target element rendered in
isolation, and the real target element on the page
• Cons: may have a false positive problem
• ClickIDS: alerts when clicked element overlaps with clickable
elements
• Cons: cannot detect attacks based on partial overlays or cropping
• Cons: Non of those defense guarantee pointer integrity
Existing Anti-clickjacking Defenses
(Cont.)
• Give UI Delays: Give user enough time to comprehand what’s
happening. User cannot interact with the target element until
the delay expires.
• Cons: giving a tradeoff between user experience penalty and
protection from timing(temporal) attack
New Attack Variants
• We construct and evaluate three attack variants using known
clickjacking techniques.
• Cursor spoofing attack to steal webcam access
• Double-click attack to steal user private data
• Whack-a-mole attack to compromise web surfing anonymity
Cursor Spoofing Attack
• Hide Flash webcam permission dialog inside Ads, and abuse
pointer integrity
Double-click Attack
• Bait-and-switch attack: bait user to perform a double-click,
and right after the first click, attacker switches user focus to
Google OAuth pop-up window under the cursor right before
the second click
First Click
Second Click
Whack-a-mole Attack
• Ask user to click as fast as possible,
and suddenly switch Facebook Like button
to user
• After clicked, immediately check the list of
like to get the profile of clicking victim
InContext Defense
• We propose a defense, InContext, to enforce context integrity
of user actions on the sensitive UI elements
• When target display integrity and pointer integrity is satisfied
then the system activate sensitive UI elements and delivers
user input to them
• Use Operating System functions to provide such crossapplication (or cross-web-site) protection
Guaranteeing Target Display
Integrity
• Not all webpages of a web site contain sensitive operations
and are susceptible to clickjacking
• We let web sites indicate which UI elements or webpages are
sensitive
• Strawman 1: CSS checking
• Check position offset, size, opacity, and z-index properties
• Cons: not reliable enough since new CSS properties comes out
• Strawman 2: Static reference bitmap
• Check rendered page with static bitmap data
• Cons: different browsers render HTML differently
Guaranteeing Target Display
Integrity (Cont.)
• Use OS-level screenshot APIs to get bitmap of the sensitive
element rendering result
• Use sensitive element rendered in isolation within browser for
comparison
• If bitmaps don’t match, trigger oninvalidclick event when
user click the sensitive element
• Enforce host page that cannot apply CSS transforms property
• Disallow any transparency inside the sensitive element itself
Guaranteeing Pointer Display
Integrity
• No cursor customization: disable cursor property when
sensitive element is present
• Screen freezing around sensitive element: to disable
animation distracting the user’s attention
• Muting: loud noise may trigger user to quickly look for a way
to turn it off
Guaranteeing Pointer Display
Integrity (Cont.)
• Lightbox around sensitive element: a randomly generated
mask to mask all rendered content around the sensitive UI
element
• No programmatic cross-origin keyboard focus changes
Ensuring Temporal Integrity
• Time-Of-Check-To-Time-Of-Use (TOCTTOU) race condition
• UI delay: the click on the sensitive UI element will not be
delivered unless the sensitive element has been fully visible
and stationary long enough
• UI delay after pointer entry: impose the delay each time the
pointer enters the sensitive element
Ensuring Temporal Integrity (Cont.)
• Pointer re-entry on a newly visible sensitive element: pointer
must re-enter the sensitive element to activate the UI element
• Padding area around sensitive element: add a padding
around sensitive element to let user distinguish whether the
pointer is on the sensitive element
Prototype Implementation
• Using Internet Explorer 9’s public COM interfaces
• IHTMLElementRender to get isolated rendering result
• Check the aforementioned methods when the element is
visually changed
• Performance
(Including time to take screenshot
and bitmap comparison)
Experiments
• Post a Human Interactive Task (HIT) on Amazon’s Mechanical
Turk
• 3521 participants, each HIT gives 25 cents
• Exclude 370 previously participated users, 1087 users not
having Facebook logged in
• 10 treatment groups for cursor-spoofing attacks
• 4 for double-click attacks
• 13 for whack-a-mole attacks
Experiments on Cursor-spoofing
Attacks
•
•
•
•
•
84% (43% of 51%(35/68)) users are attacked successfully
Timeout – wait for video ads end
Skip – click the skip link
Quit – quick the experiment
Attack Success – successfully get webcam permission
Experiments on Double-click Attack
• 47% users are attacked successfully
• Timeout – didn’t click the OAuth “Allow” button after pop-up
window shows up within 2 seconds
• Quit – quit the experiment
• Attack Success – click the OAuth “Allow” button
Experiments on Whack-a-mole
Attack
• Attack Success – user clicked the Like button
• On 1st Mouseover – user clicked the Like button right after 1st
mouse over the Like button
• Filter by Survey – user noticed the Like button and clicked it
Experiments on Whack-a-mole
Attack (Cont.)
• 95%/92% user click the Like button right after mouse over it
• Combined defense – pointer re-entry, appearance delay of
500ms, display freezing, and padding(M)
Conclusion
• Devised new clickjacking attack variants
• Propose InContext, a web browser or OS mechanism to ensure
user’s action on a sensitive UI element is in context