1. Fear the EAR: Discovering
and Mitigating Execution After
Redirect Vulnerabilities
Adam Doupé, Bryce Boe,
Christopher Kruegel, and Giovanni Vigna
University of California, Santa Barbara
CCS 2011 – 10/19/11

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

3. HTTP Redirects
GET /user/info HTTP/1.1
Host: example.com
HTTP/1.1 302 Moved
Location: http://example.com/login
GET /login HTTP/1.1
Host: example.com
Doupé - 10/19/11

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

5. Execution After Redirect: Example
class 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!”
end
end
Doupé - 10/19/11

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

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

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

9. EAR: Information Leakage
<?php
$current_user = get_current_user();
if (!$current_user->is_admin())
{
header(“Location: /”);
}
echo “457-55-5462”;
?>
Doupé - 10/19/11

10. EAR: Nested Example
class 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”
end
end
Doupé - 10/19/11

11. Outline
• Overview of Execution After Redirects
• EAR Detection Algorithm
• Results
• Prevention
Doupé - 10/19/11

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

13. EAR Detection: Overview
1. Build CFG
2. Find redirection methods
3. Prune infeasible paths
4. Detect EARs
5. Classify as vulnerable
Doupé - 10/19/11

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

15. EAR Detection: Build CFG
class 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)
end
end
Doupé - 10/19/11

16. 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 false
false true
_tmp_
User.delete(:all)
return nil return nil
Doupé - 10/19/11

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

18. 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 false
false true
_tmp_
User.delete(:all)
return nil return nil
Doupé - 10/19/11

19. 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 false
false true
_tmp_
User.delete(:all)
return nil return nil
Doupé - 10/19/11

20. 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 false
false true
_tmp_
User.delete(:all)
return nil return nil
Doupé - 10/19/11

21. EAR Detection: Classify as
Vulnerable
• Simple heuristic
– Name of methods that modify database
– Search for these on path
Doupé - 10/19/11

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

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

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

25. True Positive Example
class 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])
end
end
Doupé - 10/19/11

26. False Positive Example
class 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
end
end
Doupé - 10/19/11

27. EAR Detection: Limitations
• False negatives
– eval, send
• False positives
– Infeasible paths
– No type analysis
• Vulnerable EARs
Doupé - 10/19/11

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

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

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

31. Questions?
Code: http://github.com/adamdoupe/find_ear_rails
Email: adoupe@cs.ucsb.edu
Twitter: @adamdoupe
Doupé - 10/19/11