State of Web Security RailsConf 2016
•
2 gefällt mir•665 views
A wild ride through the dizzying highs and terrifying lows of web security in 2015. Take a look at some major breaches of the year, including some free beer! We’ll look at how attack trends have changed over the past year and new ways websites are being compromised. We’ve pulled together data from all the sites we protect to show you insights on types and patterns of attacks, and sophistication and origin of the attackers. After the bad, we’ll look at the good - new technologies like RASP are helping secure the web.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie State of Web Security RailsConf 2016
Ähnlich wie State of Web Security RailsConf 2016 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
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