• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities
 

Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities

on

  • 529 views

Presentation at the 2011 ACM Conference on Computer and Communications Security (CCS) on the paper "Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities"...

Presentation at the 2011 ACM Conference on Computer and Communications Security (CCS) on the paper "Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities"

The paper is available here:
http://cs.ucsb.edu/~adoupe/static/fear-the-ear-ccs2011.pdf

Statistics

Views

Total Views
529
Views on SlideShare
529
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities Presentation Transcript

    • Fear the EAR: Discoveringand Mitigating Execution After Redirect Vulnerabilities Adam Doupé, Bryce Boe, Christopher Kruegel, and Giovanni Vigna University of California, Santa Barbara CCS 2011 – 10/19/11
    • Motivation• Everyone uses web applications• Web applications are written by humans – They have flaws – Input sanitization flaws (XSS, SQLi) are most prevalent• Logic flaws are harder to detect than input sanitization flaws Doupé - 10/19/11
    • HTTP RedirectsGET /user/info HTTP/1.1Host: example.comHTTP/1.1 302 MovedLocation: http://example.com/loginGET /login HTTP/1.1Host: example.com Doupé - 10/19/11
    • Execution After Redirect: Overview• Developer issues a redirect assuming execution will halt – Redirect used as a goto – This is how it appears from the browser’s perspective• However, code continues to execute Doupé - 10/19/11
    • Execution After Redirect: Exampleclass TopicsController < ApplicationController def update @topic = Topic.find(params[:id]) if not current_user.is_admin? redirect_to(“/”) end @topic.update_attributes(params[:topic]) flash[:notice] = “Topic updated!” endend Doupé - 10/19/11
    • EAR History• 17 Common Vulnerabilities and Exposures (CVE) – Starting in 2007 – Difficult to find – no consistent category• Blog post about Cake PHP 2006 – Resulted in a bug filed and documentation changed• Prior work on logic flaws – Found EAR in J2EE web application• No one recognized it as a systemic logic flaw amongst web applications Doupé - 10/19/11
    • EAR Security Challenge• Attempt to observe familiarity to EARs• Added EAR challenge to the 2010 iCTF• Results – 34 / 72 teams accessed page that redirected them and leaked information – 12 of the 34 discovered and exploited the vulnerability• Conclusion: teams not very familiar Doupé - 10/19/11
    • Types of EARs• Benign – No confidentiality or integrity violated• Vulnerable – Allows for the unauthorized modification of the application state or discloses unauthorized data Doupé - 10/19/11
    • EAR: Information Leakage<?php$current_user = get_current_user();if (!$current_user->is_admin()){ header(“Location: /”);}echo “457-55-5462”;?> Doupé - 10/19/11
    • EAR: Nested Exampleclass UsersController < ApplicationController def ensure_admin unless current_user.is_admin? redirect_to(“/”) return end end def delete ensure_admin() @user = User.find(params[:id]) @user.delete() flash[:notice] = “User Deleted” endend Doupé - 10/19/11
    • Outline• Overview of Execution After Redirects• EAR Detection Algorithm• Results• Prevention Doupé - 10/19/11
    • EAR Detection: Overview• Static source code analysis – Attempt to find code that can possibly be executed after a redirect – Distinguish between benign and vulnerable Doupé - 10/19/11
    • EAR Detection: Overview1. Build CFG2. Find redirection methods3. Prune infeasible paths4. Detect EARs5. Classify as vulnerable Doupé - 10/19/11
    • EAR Detection: Build Control Flow Graph• CFG built using prior work – Diamondback Ruby parser by Furr et al. • Simplifies Ruby into easier-to-analyze format • Compiles Ruby into a subset called Ruby Intermediate Language (RIL) – CFG can be incomplete • eval • Ruby’s dynamic nature Doupé - 10/19/11
    • EAR Detection: Build CFGclass UsersController < ApplicationController def ensure_logged_in unless current_user redirect_to(“/”) and return true end @logged_in_users += 1 return false end def delete_all unless ensure_logged_in() return User.delete(:all) endend Doupé - 10/19/11
    • EAR Detection: Build CFG _tmp_ = ensure_logged_in ensure_logged_in() false true current_user true false redirect_to(“/”) @logged_in_users return true += 1 return falsefalse true _tmp_ User.delete(:all)return nil return nil Doupé - 10/19/11
    • EAR Detection: Find Redirection Methods• Find all program paths in the CFG that call the Ruby on Rails method redirect_to• Inter-procedural analysis – Methods that call redirect_to are added to interesting_methods – All methods that call an interesting_method are added to interesting_methods – Rinse and repeat until a fixpoint is reached Doupé - 10/19/11
    • EAR Detection: Find Redirect _tmp_ = Methods ensure_logged_in ensure_logged_in() false true current_user true false redirect_to(“/”) @logged_in_users return true += 1 return falsefalse true _tmp_ User.delete(:all)return nil return nil Doupé - 10/19/11
    • EAR Detection: Prune Infeasible _tmp_ = Paths ensure_logged_in ensure_logged_in() false true current_user true false redirect_to(“/”) @logged_in_users return true += 1 return falsefalse true _tmp_ User.delete(:all)return nil return nil Doupé - 10/19/11
    • EAR Detection: Detect EARs _tmp_ = ensure_logged_in ensure_logged_in() false true current_user true false redirect_to(“/”) @logged_in_users return true += 1 return falsefalse true _tmp_ User.delete(:all)return nil return nil Doupé - 10/19/11
    • EAR Detection: Classify as Vulnerable• Simple heuristic – Name of methods that modify database – Search for these on path Doupé - 10/19/11
    • Results• 18,127 Ruby on Rails projects from GitHub• 1,173 projects contained 3,944 EARs – 3,089 Benign EARs – 855 Vulnerable EARs Doupé - 10/19/11
    • EAR Email Notification• 624 project maintainers notified• 107 responded – 49 confirmed the EAR we reported – 26 told us that the app was demo or toy – 3 pointed out false positives – 6 NOFIX – Rest thanked us but did not offer confirmation Doupé - 10/19/11
    • Detection Effectiveness• Manual verification of all vulnerable EARs – 485 True vulnerable (56.7%) – 325 False positives (vulnerable) (38.0%) – 45 False positives (EARs) (5.3%)• Manual verification of 200 random benign EARs – 13 False positives (EARs) (6.5%) – 0 False negatives (vulnerable) Doupé - 10/19/11
    • True Positive Exampleclass BanksController < ApplicationController def redirect_to_login redirect_to(“/login”) and return end def create if not current_user.is_admin? redirect_to_login() and return end @bank = Bank.create(params[:bank]) endend Doupé - 10/19/11
    • False Positive Exampleclass UsersController < ApplicationController def update if request.get? redirect_to(“/users”) end if request.post? @user = User.find(params[:id]) @user.update_attributes(params[:user]) end endend Doupé - 10/19/11
    • EAR Detection: Limitations• False negatives – eval, send• False positives – Infeasible paths – No type analysis • Vulnerable EARs Doupé - 10/19/11
    • Framework Susceptibility• Analyzed 9 web frameworks – Rails, Grails, Django, ASP.NET MVC, Zend Framework, CakePHP, CodeIgniter, J2EE, Struts• Susceptible – Ruby on Rails – Grails – J2EE – Struts Doupé - 10/19/11
    • Prevention• Secure design – Django, ASP.NET MVC• Terminate process or thread – ASP.NET, CakePHP, Zend, CodeIgniter• Patched Ruby on Rails – Exception handling Doupé - 10/19/11
    • Contributions• Described a relatively unknown web application vulnerability called Execution After Redirect (EAR)• Developed an algorithm to statically detect EARs in Ruby on Rails applications• Discovered many vulnerabilities in real- world open-source Ruby on Rails applications Doupé - 10/19/11
    • Questions?Code: http://github.com/adamdoupe/find_ear_railsEmail: adoupe@cs.ucsb.eduTwitter: @adamdoupe Doupé - 10/19/11