1 / 59

“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 neildaswani/

“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 http://www.neildaswani.com/. Is the sky falling? . TJX (March 2007) owns TJ Maxx, Marshalls, and other dept stores attacks exploited WEP used at branches

Télécharger la présentation

“Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 neildaswani/

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. “Emerging Security Vulnerabilities & the Impact to Business” Neil Daswani October 2007 http://www.neildaswani.com/

  2. Is the sky falling? • TJX (March 2007) • owns TJ Maxx, Marshalls, and other dept stores • attacks exploited WEP used at branches • over 47 million credit card (CC) #s dating back to 2002 • CardSystems (June 2005) • credit card payment processing company: out of business • 263,000 CC #s stolen from database via SQL Injection • 43 million CC #s stored unencrypted / compromised • Enter “sql injection” on news.google.com for more... • Additional Data Theft:www.privacyrights.org/ar/ChronDataBreaches.htm(153M compromised records; over 300 incidents in 2006 alone)

  3. Overview • High-Impact Threats & Defenses:SQL Injection and XSRF • Vulnerability Trends • Where To Learn More:Courses/Certifications, Books, Websites

  4. SQL Injection Example Enter Username & Password Web Browser(Client) Web Server DB SELECT passwd FROM USERS WHERE uname IS ‘smith’ Normal Query

  5. SQL Injection Example Attacker Provides This Input

  6. SQL Injection Example Malicious Query Enter Username & Password Web Browser(Client) Web Server DB SELECT passwd FROM USERS WHERE uname IS ‘’; DROP TABLEUSERS; -- ' Eliminates all user accounts

  7. SQL Injection Example View pizza order history:<br> <form method="post" action="..."> Month <select> <option name="month" value="1">Jan</option> ... <option name="month" value="12">Dec</option> </select> <p> <input type=submit name=submit value=View> </form>

  8. SQL Injection Example Normal SQL Query SELECT pizza, toppings, quantity, order_day FROM orders WHERE userid=4123 AND order_month=10 Type 2 Attack For order_month parameter, attacker could input 0 OR 1=1 WHERE condition is always true! Gives attacker access to other users’ private data! <option name="month" value=“0 OR 1=1">Dec</option> Malicious Query … WHERE userid=4123 AND order_month=0 OR 1=1

  9. SQL Injection Example All User Data Compromised

  10. SQL Injection Example A more damaging breach of user privacy: Attacker is able to • Combine the results of two queries • Empty table from first query with the sensitive credit card info of all users from second query For order_month parameter, attacker could input 0 AND 1=0UNION SELECT cardholder, number, exp_month, exp_year FROM creditcards

  11. SQL Injection Example Credit Card Info Compromised

  12. Source: securityfocus vulnerability database

  13. Preventing SQL Injection • Whitelisting • Why? Blacklisting chars doesn’t work: • Forget to filter out some characters • Could prevent valid input (e.g. username O’Brien) • Allow well-defined set of safe values:[A-Za-z0-9]*[0-1][0-9] • Valid input set implicitly defined through regular expressions • Escaping • For valid string inputs like username o’connor, use escape characters. Ex: escape(o’connor) = o’’connor (only works for string inputs)

  14. Prepared Statements & Bind Variables PreparedStatement ps = db.prepareStatement( "SELECT pizza, toppings, quantity, order_day “ + "FROM orders WHERE userid=? AND order_month=?"); ps.setInt(1, session.getCurrentUserId()); ps.setInt(2, Integer.parseInt(request.getParamenter("month"))); ResultSet res = ps.executeQuery(); • query parsed w/o parameters • bind variables are typed e.g. int, string, etc…* Bind Variables: Data Placeholders

  15. Additional Mitigations What else helps? • Limit Privileges (Defense-in-Depth) • Harden DB Server and Host OS What doesn’t? • Encrypt Sensitive Data stored in Database What else do I need to learn about SQL Injection? • Second Order SQL Injection • Blind SQL Injection

  16. Threats • Unvalidated Input • SQL Injection • Cross-Site-Scripting (XSS) • Design Errors • Cross-Site-Request-Forgery (XSRF) • Boundary Conditions • Exception Handling • Access Validation

  17. XSRF Alice is using our (“good”) web-application: www.bank.com (assume user is logged in w/ cookie) At the same time (i.e. same browser session), she’s also visiting a “malicious” web-application: www.evil.org

  18. How XSRF Works Alice bank.com /login.html /authuname=victim&pass=fmd9032 Cookie: sessionid=40a4c04de /viewbalanceCookie: sessionid=40a4c04de “Your balance is $X”

  19. How XSRF Works Alice bank.com evil.org /login.html /authuname=victim&pass=fmd9032 Cookie: sessionid=40a4c04de /evil.html <IMG SRC=“http://bank.com/paybill?addr=123%20evil%20st&amt=$10000”> /paybilladdr=123 evil st, amt=$10000Cookie: sessionid=40a4c04de “OK. Payment Sent!”

  20. More XSRF Malicious site can initiate HTTP requests to our app on Alice’s behalf, w/o her knowledge • authentication cookies stored in browser cache are sent to our server regardless of who made the request Another Example: change password feature on our app (“update_password”) • Hacker site could execute a script to send a fake password-change request • authenticates b/c cookies are sent

  21. <form method="POST" name="evilform“ target="hiddenframe" action="https://www.bank.com/update_password"> <input type="hidden" id="password" value="evilhax0r"> </form> <!– hiddenframe IFRAME here --> <script>document.evilform.submit();</script> More XSRF 1. Alice’s browser loads page from www.evil.org 2. Evil Script runs causing evilform to be submitted with a password-change request to our “good” form: www.bank.com/update_password with a<input type="password" id="password"> field evilform 3. Browser sends authentication cookies to our app. We’re hoodwinked into thinking the request is from Alice. Her password is changed to evilhax0r!

  22. XSRF: Write-only Malicious site can’t read info, but can make write requests to our app! Can still cause damage • in Alice’s case, attacker gained control of her account with full read/write access! Who should worry about XSRF? • apps w/ user info, profiles (e.g., Facebook) • apps that do financial transactions for users • any app that stores user data

  23. Yet Another XSRF: Home Routers [SRJ’07] • Fact: • 50% of home users use a broadband router with a default or no password • Drive-by Pharming attack: User visits malicious site • JavaScript at site scans home network looking for broadband router: • Same-Origin-Policy allows “send only” messages • Detect success using onerror: • <IMG SRC=192.168.0.1 onerror = do() > • Once found, login to router and change DNS server • Problem: “send-only” access is sufficient to reprogram router

  24. Preventing XSRF Inspecting Referer Headers • specifies the document originating the request • ok, but not practical since it could be forged or blanked (even by legitimate users) Validation via User-Provided Secret • ask for current password for important transactions Validation via Action Token • add special tokens to “genuine” forms to distinguish them from “forged” forms

  25. Vulernability Trends (Overall/MITRE) 2006 2001

  26. Overall Trends • Attacks are increasing • Big four are about the same (regardless of vuln database): • Cross-Site-Scripting (XSS, XSRF, XSSI) • Injection (SQL, PHP-includes) • Memory Corruption (buffer overflows, integer overflows, format strings, etc) • Denial-of-Service

  27. What should I do? • Engineers • Developers • Programmers • Architects1) Arm yourself!2) Elect a security czar for each project

  28. What Every EngineerNeeds To Know... • Secure Design: least privilege, fail-safe stance, weakest link, etc. • Technical Flaws: • XSS / XSRF / XSSI • Injection / Remote Code Execution • Directory Traversal • Race Conditions (e.g., TOCTOU) • Memory Corruption • Attacks: • Data Theft • Authentication / Authorization Bypass • Denial-of-Service • Privilege Escalation • Information Leakage

  29. Where to learn more? • Courses • Certification Programs • Books • Websites(not comprehensive)

  30. Security Courses • Cryptography Upper Division Courses(at almost every major university) • Some systems security courses(e.g., CS155 @ Stanford, CS161 @ UC Berkeley) • More crypto and security courses listed at:http://avirubin.com/courses.html

  31. Stanford Advanced Security Certificate • Online (anytime) or On-Campus (one week) • Required: 3 core courses; 3 electives • Hands-on labs conducting attacks & constructing defenses • Security Foundations Certificate also available • http://proed.stanford.edu/?advancedsecurityto sign up!

  32. Stanford Advanced Security Certificate • CORE COURSES • Using Cryptography Correctly • Writing Secure Code • Security Protocols • ELECTIVES • Computer Security Management – Recent Threats, Trends & the Law • Designing/Building Secure Networks • Emerging Threats and Defenses • Securing Web Applications • Systems Security • SPECIAL ELECTIVE • Computer Security Foundations Certificate

  33. Other Security Certification Programs • CISSP (offered by ISC2) • prepares for administration / gov't jobs in security • credential can be used for PCI compliance • multiple-choice test • GIAC Secure Software Programmer(offered by SANS) • secure programming assessment • multiple choice (questions in development) • new offering: first exam was Aug 2007

  34. Books • Foundations of Security:What Every Programmer Needs To Know(Daswani / Kern / Kesavan) • Security Engineering (Anderson) • Building Secure Software (Viega / McGraw) • Secure Programming Cookbook (Viega / Messier)

  35. Security Books • Security Engineering • Ross Anderson • Available online(for free) • http://www.cl.cam.ac.uk/~rja14/book.html

  36. Security Books • Building Secure Software • Viega / McGraw“Classic Text” • Other books by McGraw & Co:- Exploiting Software- Software Security

  37. Security Books • Foundations of Security: What Every Programmer Needs To Know • Daswani / Kern / Kesavan • Get your copy from B46-Anare or B46-284 • Topics: • Secure design principles • Web applicationattacks & defenses • Intro. to Cryptography • Free slides @ www.learnsecurity.com

  38. Security Books • Secure Programming Cookbookfor C and C++ • Viega / Messier • Lots of code exampleson how to use cryptocorrectly

  39. Websites • OWASP / Top Tenwww.owasp.org (chapters in almost every major city) • Security Focus / Bugtraqwww.securityfocus.com • code.google.com/edu

  40. OWASP Top 10 2004 2007 • A1 Unvalidated Input • A2 Broken Access Control • A3 Broken Authentication / Session Mg • A4 Cross Site Scripting • A5 Buffer Overflow • A6 Injection Flaws • A7 Improper Error Handling • A8 Insecure Storage • A9 Application Denial of Service • A10 Insecure Configuration Management • A1 Cross Site Scripting (XSS) • A2 Injection Flaws (e.g., SQL injection) • A3 Malicious File Execution (i.e., PHP) • A4 Insecure Direct Object Reference • A5 Cross Site Request Forgery (CSRF) • A6 Information Leakage and Improper Error Handling • A7 Broken Authentication / Session Mg • A8 Insecure Cryptographic Storage • A9 Insecure Communications • A10 Failure to Restrict URL Access

  41. Security Focus • www.securityfocus.com / Home of Bugtraq • Articles / Mailing Lists / Vuln. Reports • Focus areas: • Foundations • Microsoft / Unix • IDS • Incident Response • Viruses / Malware • Penetration Testing • Firewalls

  42. code.google.com/edu: Web Security • Free & available for external use • Ex. DoS against web server

  43. What should I do? • Managers(Project, Product, Directors, CIOs, CTOs, etc) 1) Organize to achieve security 2) Modify dev lifecycle as necessary 3) Invest in security training

  44. Organizing... Gatekeepers Satellites Authority Advisors Centralization

  45. Gatekeepers • Centralized Security Department with Approval Authority • Security Dept accountable for every line of deployed code, and must provide explicit approval for every deployment. • Pros: • High level of accountability • Tight control • Cons: • Scalability • Could stifle innovation • Bottleneck • Development might become tight-lipped (or work-around security)

  46. Advisors • Security Consulting Department with Escalation Authority • Security Department provides feedback to product teams when requested, or can actively “probe” • Pros • More openness to share risks • Cons • Less accountability • Frequent escalation will de-sensitize executives

  47. Satellites • Decentralized Security Staff / “Virtual” Department • Put developers with security expertise on the product teams. Rotate if necessary. • Or, train one of the developers on each product team to be “security czar.” • Pros • Security recommendations more likely to be implemented • Cons • Less flexibility in moving security engineers to most high risk projects fast.

  48. What should I do? • Every engineer should be a software security practitioner • Every manager should organize and invest in security • Links / Pointers: http://www.learnsecurity.com/ Click on “Resources” • Neil Daswanidaswani@learnsecurity.comhttp://www.neildaswani.com

  49. Last Remarks • Interested in jobs?(software security, botnets, ...) • Items in the back: • Free books • Stanford Security Certification Brochures • Need security help / consulting?

  50. Backup Slides Follow

More Related