The Hacking Evolution: New Trends in Web Application Exploits and Vulnerabilities Brian Christian, Senior Security Eng

1. The Hacking Evolution: New Trends in Web Application Exploits and Vulnerabilities Brian Christian, Senior Security Engineer and Co-Founder, S.P.I Dynamics

2. Agenda Part 1: Introduction – How on earth did we get to this point? Part 2: Identifying the Problem – How does this stuff happen? Part 3: Key Application Vulnerabilities – Past, present and future Part 4: What Application Security Means to Compliance Efforts and how to fix the problem. Part 5:More information and online resources Part 6: Q&A

3. Part One Introduction • Who We Are - SPI Dynamics in a nutshell • Application Security -How did we get to this point?

4. We manufacture and license WebInspect, our industry leading web application security assessment product, to enterprises, consultants, and other institutions, both directly and via global partners. We own the world’s leading database of web application security vulnerabilities, SecureBase™. SecureBase is updated frequently by SPI Labs, our U.S.-based research & development organization. SPI Dynamics The Leader In Web Application Security Assessment

5. Web Sites Simple, single server solutions Web Server HTML CGI Browser

6. Web Applications Very complex architectures, multiple platforms, multiple protocols Web Services Database Server Customer Identification Access Controls Transaction Information Core Business Data Application Server Business Logic Content services Web Servers Presentation Layer Media Store Wireless Browser

7. Common Web Applications

8. The Absolute Truth • All code has bugs – regardless of platform, language or application. • From a Microsoft to a Mom and Pop’s home- brewed application, all code has bugs. • Some bugs are functionality bugs, which are discovered by QA. • Other bugs are security bugs, which largely go unidentified. • As long as functionality is the main objective and not security, there will always be vulnerabilities in computer applications.

9. This is your developed application. This is all the stuff that your application was supposed to do, but doesn’t do. These are Functionality bugs This is all the stuff that your application CAN also do, but you’re not aware of. These are Security vulnerabilities This is your application design. Why These Thing Happen This is all the stuff that your application is supposed to do.

10. Why Web Application Attacks Occur The Web Application Security Gap Application Developers and QA Professionals Don’t Know Security Security Professionals Don’t Know The Applications • “As a Network Security Professional, I don’t know how my company’s web applications are supposed to work so I deploy a protective solution…but don’t know if it’s protecting what it’s supposed to.” • “As an Application Developer, I can build great features and functions while meeting deadlines, but I don’t know how to develop my web application with security in mind.”

11. Web Applications Breach the Perimeter HTTP INTERNET IMAP SSH POP3 FTP TELNET Firewall only allows PORT 80 (or 443 SSL) traffic from the internet to the web server. Any – Web Server: 80 DMZ Firewall only allows applications on the web server to talk to application server. Web Server Application Server TRUSTED INSIDE Firewall only allows application server to talk to database server. Application Server Database CORPORATE INSIDE

12. Web Applications Invite Public Access “Today over 70% of attacks against a company’s website or web application come at the ‘Application Layer’ not the network or system layer.” - Gartner Group

13. Web Application Risk “Web application incidents cost companies more than $320,000,000 in 2001.” • Forty-four percent (223 respondents) to the 2002 Computer Crime and Security Survey were willing and/or able to quantify their financial losses. These 223 respondents reported $455,848,000 in financial losses. “2002 Computer Crime and Security Survey” Computer Security Institute & San Francisco FBI Computer Intrusion Squad

14. Part Two Identifying the Problem • What are the primary vulnerabilities? • How and why they occur

15. Web Application Vulnerabilities Web application vulnerabilities occur in multiple areas. Application Parameter Manipulation Cross-Site Scripting SQL Injection Buffer Overflow Reverse Directory Transversal JAVA Decompilation Path Truncation Hidden Web Paths Cookie Manipulation Application Mapping Backup Checking Directory Enumeration Administration Extension Checking Common File Checks Data Extension Checking Backup Checking Directory Enumeration Path Truncation Hidden Web Paths Forceful Browsing Platform Known Vulnerabilities

16. Cross Site Scripting (or XSS)

17. Cross Site Scripting (XSS) • Cross-site scripting (also know as XSS or CSS) occurs when dynamically generated web pages display input that is not property validated. • A user passes input in the form of a parameter to the web server. • The web server returns the user provided input back to the user without proper encoding. • Again, a demonstration!

18. SQL Injection

19. SQL Injection – Defined • SQL injection is a technique for exploiting web applications that use client-supplied data in SQL queries without stripping potentially harmful characters first. • Allow me to demonstrate!

20. Part Three Key Application Vulnerabilities • Past, Present and Future • Google Hacking

21. Google Hacking More then searching for great pr0n.

22. Google Hacking • Find vulnerable sites using Google (Old method – new life) • Example Search Queries • “filetype:mdb inurl:admin” – 180 results • “Filetype:xls inurl:admin” – 14,100 results • “ORA-00921: unexpected end of SQL command” – 3,470 results • “allintitle:Netscape Enterprise Server Home Page” – 431 results

23. Google Hacking • Take this method a step further and use it to narrow your attack victims. • “inurl:id= filetype:asp site:gov” – 572,000 results • “inurl:id= filetype:asp site:com” – 7,150,000 results • “inurl:id= filetype:asp site:org” – 3,240,000 results • Use this list as a baseline for identifying SQL injection vulnerabilities

24. Google Hacking • Take this method a step further and use it to narrow your attack victims. • “inurl:id= filetype:asp site:gov” – 572,000 results • “inurl:id= filetype:asp site:com” – 7,150,000 results • “inurl:id= filetype:asp site:org” – 3,240,000 results • Use this list as a baseline for identifying SQL injection vulnerabilities

25. Google Hacking • Took 1 hour of coding • 500 vulnerable sites were found in 1 minute and 26 seconds

26. Google Hacking • Application Worm Find next victim Exploit victim Exploit victim

27. Enter the Santy Worm • Perl.Santy is a worm written in Perl script that attempts to spread to Web servers running versions of the phpBB 2.x bulletin board software Viewtopic.PHP PHP Script Injection Vulnerability • Other systems are not affected. If successful, the worm copies itself to the server and overwrites the files with the following extensions:.asp, .htm, .jsp, .php, .phtm, .shtm • The worm uses the Google search engine to find potential new infection targets. Google has now implemented blocking Perl.Santy search requests, which is expected to greatly reduce the worm's ability to propagate and lower the risk of further infections.

28. Enter the Santy Worm • Perl.Santy.A [Computer Associates], Santy [F-Secure], Net-Worm.Perl.Santy.a [Kaspersky], Perl/Santy.worm [McAfee], PHP/Santy.A.worm [Panda], Perl/Santy-A [Sophos], WORM_SANTY.A [Trend Micro] • UNIX, LINUX, Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows Server 2003, Windows XP

29. http://www.google.com/search?num=100&hl=en&lr=&as_qdr=all&q=allinurl%3A+%22viewtopic.php%22+%22

30. The Past, the Present, and the Future of Hacking How prolific could this whole scenario be?

31. Where We’ve Been – The Past • Since most sites were static HTML, not much to do but try to obtain root / admin privileges on the machine or deface the website. • This proved for some great comedy.

32. Where We’re At– The Present • Since more dynamic and unique content has been added to websites, and users demand even MORE functionality so that they can do everything electronically, insecure content was added at an expedited pace! • And users and management demand even more!

33. Where We’re Going– The Future • Application hacking is becoming more complex as applications are becoming more complex. The possibilities are endless when it comes down to what can you exploit in web applications. • Take for Instance Application Worms, Web Application Worms.

34. What Application Security Means to Compliance Efforts How prolific could this whole scenario be?

35. Types of Compliance Regulations • Privacy • HIPPA (Health Insurance Portability and Accountability Act) • SOX (The Sarbanes-Oxley Act ) • GLBA (Gramm-Leach-Bliley Act) • Disclosure • CA1386 • Federal Trade Commission • Privacy Policy • Practice • PCI

36. Privacy • Privacy • HIPAA (Health Insurance Portability and Accountability Act) • SOX (The Sarbanes-Oxley Act ) • GLBA (Gramm-Leach-Bliley Act)

37. HIPAA • The Health Insurance Portability and Accountability Act (HIPAA) mandates the privacy and security of personal health • The Security Rule of the Act recommends information security best practices to protect personal information. • HIPAA requires organizations to perform a HIPAA security risk assessment to determine what applications and data are vulnerable, to ensure proper authentication, access control, and logging systems, and to conduct ongoing auditing of information systems to test for newly discovered vulnerabilities. • Web Challenge: • Establishing a security policy • Establishing standards that support the policy • Effectively auditing to ensure policy compliance

38. SOX - The Sarbanes-Oxley Act • Sarbanes-Oxley focuses on regulating corporate behavior for the protection of financial records instead of enhancing the privacy and security of confidential customer information. • Difficult because it was not written specifically with information technology or information security in mind • Addresses • How information is accessed • What leaves the corporate network • Other financial controls • Web Challenges • Financial information resides on the same networks as web applications or there associated systems (Databases, etc) • Web front ends for financial systems are a common interface to financial systems. • These can be susceptible to web application attacks • Requires the development of a policy

39. GLBA - The Gramm-Leach-Bliley Act • The Gramm-Leach-Bliley Act (GLBA), formally known as the Financial Modernization Act of 1999, • Established requirements for financial institutions in the United States to protect consumers’ personal financial information. • The GLBA contains three principle requirements • The Financial Privacy Rule requires financial institutions to publish a privacy notice to their customers • Consumers also must be given the right to limit the sharing of their personal information. • The Safeguards Rules require all financial institutions to design, implement and maintain safeguards and a security plan to protect customer information that they handle. • Web Challenges • Customer information resides on the same networks as web applications or there associated systems (Databases, etc) • Web front ends for financial systems are a common interface to customer financial systems. • These can be susceptible to web application attacks • Requires the development of a policy

40. Disclosure • Disclosure • CA1386 • MANY others are coming VERY SOON

41. CA 1386 • Enacted in order to force anyone holding private personal information, to inform consumers immediately if their personal information has been compromised. • The law also gives consumers the right to sue • Any business, organization or individual that holds private personal information for a person residing in the state of California is bound by the provisions of the law, so California SB 1386 has a much greater impact nationally than is typical for state legislation. • Web Challenges: • Is a performance based law, not policy based • If you get hacked you have to disclose the incident

42. Federal Trade Commission • Federal Trade Commission • Privacy Policy www.owasp.org www.webappsec.org www.securityfocus.com www.spidynamics.com

43. Federal Trade Commission • From: http://www.ftc.gov/privacy/ • “Under the FTC Act, the Commission guards against unfairness and deception by enforcing companies' privacy promises about how they collect , use and secure consumers' personal information.” • Web security challenge: • Companies are being investigated for FTC violations because they are not living up to there stated policy • http://www.webappsec.org/documents/real_world_web_hacking.shtml • PETCO • Guess • Many others

44. Visa PCI • The Payment Card Industry (PCI) Data Security Standard is a collaborative effort by Visa, MasterCard, American Express and Discover to ensure the protection of customers' personal information. • The standard establishes 12 security requirements that all members, merchants and service providers must adhere to. • Sections 6, 11 and 12 have specific web related issues. • Web security challenges • PCI is the most comprehensive and specific standard in the industry. • Following the standard will greatly improve a companies web application security overall • Not following PCI can cost a company it’s ability to process credit cards

45. VISA PCI • http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html • Go to VISA.COM and search for PCI • Build and Maintain a Secure Network • 1. Install and maintain a firewall configuration to protect data • 2. Do not use vendor-supplied defaults for system passwords and other security parameters • Protect Cardholder Data • 3. Protect stored data • 4. Encrypt transmission of cardholder data and sensitive information across public networks • Maintain a Vulnerability Management Program • 5. Use and regularly update anti-virus software • 6. Develop and maintain secure systems and applications • Implement Strong Access Control Measures • 7. Restrict access to data by business need-to-know • 8. Assign a unique ID to each person with computer access • 9. Restrict physical access to cardholder data • Regularly Monitor and Test Networks • 10. Track and monitor all access to network resources and cardholder data • 11. Regularly test security systems and processes • Maintain an Information Security Policy • 12. Maintain a policy that addresses information security

46. General compliance needs • Establish a security policy • Identify what will be done to address web application security needs and who will be responsible for it • Follow the policy • Ensure that security policies are being followed throughout the software lifecycle • Document that the policy was followed • Have a record of testing that was done to ensure that the policy was followed • SDLC • The Software Development Lifecycle Cycle needs to respect and support compliance efforts • Unlike other compliance efforts, web application security needs to be integrated into the SDLC

47. ASAP Process Support & Services Release Development Design Requirements Test (QA) Security Training Security services Source code review Development Assessment Tools QA Automated Assessment tools Automated assessment tools Security Kickoff Threat Modeling Infrastructure Assessment Create Development Standards Secure coding libraries QA Manual Assessment tools Infrastructure Design Pen Testing Regulatory Compliance

48. Web Web D A A D Application Application Security Security Web Web Application Application Security Security Q Q S S Enterprise-Wide Web Application Security Web Application Security testing must be applied in all phases of the Application Lifecycle and by all constituencies throughout the enterprise – Auditors, Application Developers, QA and Security Operations.

49. A A D D Web Web Web Web Application Application Application Security Security S Q S Q Enterprise-Wide Web Application Security Application Developers • Must have clear cut security requirement to follow during Development and QA phases • Need to run automated tests on code during Development phase • Must utilize secure code for re-use • Require automated testing products that integrate into current environment

50. Q Q Enterprise-Wide Web Application Security • Must test applications not only for functionality but also for security • Must test environments for potential flaws and insecurities • Must provide detailed security flaw reports to development • Require automated testing products that integrate into current environment Quality Assurance Professionals D D A A Web Web Web Web Application Application Application Security Security S S