1. Insecurity and the Internet OWASP DAY #1 / 2009 – Auckland New Zealand

2. Who The Heck Am I?  Paul Craig  Principle Security Consultant – Security-Assessment.com  I lead the Security-Assessment.com penetration testing team.  Security author, researcher, devoted hacker!  Your welcome to contact me.  paul@ha.cked.net paul@ha.cked.net  paul.craig@security-assessment.com paul.craig@security-assessment.com

3.  My wife commonly asks me this on the way home: “ How was your day today Paul?”  “Oh, we broke into a large critical infrastructure provider, got credit cards, shells, full control on the domain..”  This happens regularly.  I am not shocked, or surprised, or even excited, just dead pan.  10 years of popping shells, this is just another day in the office.  75% of industries in NZ can be hacked, right now.  I have zero faith, or trust in the internet, I would rather not use it.  “Is it me, or is the internet not getting any more secure?”  What is the current trend in IT security ?  Is technology getting more, or less secure ?

4. Agenda  The history of vulnerabilities  Evolution of the internet and its insecurities.  How things have changed over the last 10 years.  Comparison of vulnerabilities  Vulnerabilities found 5 years ago Vs vulnerabilities found this year.  Are developers still making the same mistakes ?  Draw a conclusion: “Is it getting any better?”  Is the internet getting more or less secure ?

5.  “IT security is a new field, we are still working it out…”  Computer security was first outlined in the 80’s  Fred T. Grampp and Robert Morris Snr: UNIX Operating System Ssecurity. AT&T Bell Laboratories 1984.  Sheila L. Brand: DoD Trusted Computer System Evaluation Criteria. DoD Computer Security Center, 1985.  The first comprehensive security policies released to the public.  Account and password management is important.  You should force users to choose secure passwords.  Privilege separation = really good  Encryption is very important, use it whenever possible.  Robert Morris Snr became the NSA’s chief scientist.  His son wrote the first ever computer Worm The Morris Worm  Only 10% of the applications we review, today adhere to 80’s standards.

6.  Core security principals have existed for even longer.  Principal of Least Privilege:  “Every program and every user of a system should operate using the least set of privileges necessary to complete the task. “  The protection of information in computer systems, 1974.  Defense in Depth:  “Seeks to delay rather than prevent, the advance of an attacker, buying time and causing additional casualties.“  Earliest known example at the Battle of Cannae in 216 BC.  Layer upon layer of security, like an onion, makes hackers cry.  Modern technology is often lacking these principals.  Principal of least privilege was only fully implemented in Windows in Vista!

7.  The state of web application security is changing.  Technology advancements rapidly change the security landscape.  Hacking web apps nine years ago and today, very different.  In the year 2000…  Majority of interactive websites ran IIS v4-5 & ASP!  Web application security was not really focused on.  Security professionals still focused on networks!  Hackers hack networks.  Web applications are a novelty.

8.  By 2004 we were all focused on security.  Symantec’s stock price had increased 300% over the previous 3 years.  Worms! Worms! Worms!  Everyone is buying Firewalls, AV, IDS, IPS.  “Solve the security problem with this silver bullet software”  Networks became based on default DENY firewall rules.  The only entry point for hackers became web applications.  “Port 80 is the only open port!”  2004 became the year the world started hacking web applications.  Huge shift in the industry toward the security of web applications.

9.  ASP is a highly versatile and powerful language.  Used by the majority of Microsoft friendly corporations.  Biggest problem with ASP  Very easy to write very insecure ASP applications!  Little standardised user input validation.  ASP security relies on the developers own abilities.  Bad developers, write insecure code.  ASP Produced:  SQL Injection  XSS (Cross Site Scripting)  XML Injection  File path Injection

10.  Most prolific attack vector: SQL Injection  Inject content into a SQL query performed by a database.  Execute your own SQL queries on the database.  http://example.com/product.asp?id=1 SELECT ProductName from DB where id = ‘1’  http://example.com/product.asp?id=‘ ; exec master..xp_cmdshell ‘CMD’ SELECT ProdName from DB where id = ‘’; exec master..xp_cmdshell ‘dir C:\’  Microsoft SQL at the time contained support for executing arbitrary commands through extended stored procedures. (xp_cmdshell)  By default ran as the privileged SYSTEM user.  Obtaining a privileged interactive shell through SQL injection, not hard.

11.  Estimated that 75% of all web applications were vulnerable to SQL injection in 2005!  Auto-hack SQL tools were released, its too easy!  SQL injection became the most widely exploited vulnerability.  Even security vendors have been vulnerable to SQL injection!  Data exposure incidents skyrocketed over 400% from previous years.  Credit card fraud increased over 300%  SQL injection is perfect for data exposure.  Stealing credit card numbers.

12.  Software vendors took steps to increase the level of security  “We should protect against injection vulnerabilities at the framework!”  New technologies released. .NET/Ruby/Python/Java  “Injection vulnerabilities should not exist!”  Make it hard to write insecure code.  Education has increased!  Everyone knows about SQL injection  Even high level corporate type! (CIO/CTO)  Everyone knows how vulnerable web applications are.

13.  Microsoft replaced ASP with.NET  Most ASP web applications redeployed in.NET.  Modern frameworks try to make application security really easy.  Security is implemented for the developer, at the framework.  Standard SQL query method is secure from user input injection. obj.Parameters.Add("@Name", NameTextBox.Text); obj.Parameters.Add("@Password", PasswordTextBox.Text);  Automatic XSS prevention, in the framework.  Blocks many forms of injection through automatic sanitation.  SA reports saw a 50% decrease in the number of findings  Typical ASP application = 57 page SA report.  Typical.NET application = 25 page SA report.

14.  So its 2009, and WOW has the internet changed!  “Web 2.0” “Rich interactive browser based content”  Full client server applications  Games in your browser.  Capable of complex application logic.  So are we secure?!?  It is true that SQL injection is becoming a rare find.  The vulnerabilities from 1999, probably do not exist.  However, new technology always = New vulnerabilities

15. Comparison of Vulnerabilities 2003-2005 vs 2009  Security-Assessment.com perform 3-4 web application reviews a week, every week, and have done so for 5 years.  We work for every sector/industry in New Zealand  Practically every large company in New Zealand.  Historic SA reports provide interesting statistical information.  Trends of vulnerabilities discovered, common mistakes.  Functionality developers can never implement securely.  So I started reading ALOT of reports…

16.  Number of Vulnerabilities: 2003-2005  I picked 5 large corporate web application reports at random.  Clients represented big business.  4 of the applications were developed by outsourced companies.  2 of the 5 applications were written in ASP. Low severity. Minor severity. Medium severity. Urgent severity. Critical severity

17.  Number of Vulnerabilities: 2009  5 web applications developed in 2009  Mix of Java and C# (.NET) Low severity. Minor severity. Medium severity. Urgent severity. Critical severity  Less critical severity findings.  I only need one!  More mediums.

18.  How did developers fail in 2003-2005?  in 2003-2005 web application developers were F$%^&* bad.  “Wow these are lame bugs..”  Critical, easy bugs, trivial to hack  “Secret Answer Question Kept in Hidden Form Value”

19.  “Multiple SQL Injection”  Over ½ of the Critical findings related to SQL injection.  Vulnerabilities allowed complete compromise.  Yep no surprise there.  Developers Fail at anything to do with Files.  Uploads:  “Application allows arbitrary script content to be uploaded, and subsequently executed on the web server.”  “Application permits directory traversal in File names during upload process”  Viewing Files:  File=../../../../../../../../boot.ini

20.  Very broken access controls  Only user Admin can access /admin/main.asp  However anyone can access /admin/edituser.asp.  POST to /admin/main.asp and Admin rights are not required.  Direct Object Reference  Accessing an arbitrary application object, ie: another users.  ViewMyProfile.asp?userid=101  “I wonder who is userid 102.. 103.. 104..”  ViewMyProfile.asp?userid=102  ViewMyProfile.asp?userid=103  Most of the Urgent severity findings relate to Direct Object Reference

21.  Default software credentials  Admin/Admin, Manage/manage, tomcat/tomcat  Not exactly hard to guess..  Default passwords not changed.  Default Application Samples  “Click here to execute a query on the Database”  “Samples/viewfile.php?file=../../../../boot.ini”  Vendor best practice not followed.  No one reads the manual.  Basic security precautions not taken, common sense stuff.

22.  How do developers fail in 2009.  “Same bugs as five years ago, completely different technology”  “Administrative Functionality Accessible Through hidden Control”  admintab = ctl00$MainMenu$ctl02  View based security  Restricting your access by removing the “Admin” tab.

23.  Only 1 SQL injection vulnerability  Through JSP, did not result in a command shell.  Developers still don’t know how to deal with files.  If its reading, writing, viewing files. Its likely vulnerable.  File/Uploads that store user supplied files, in the web root.  Upload cmdshell.aspx, find where its stored, request the page, shell.  “Attach your CV”, “Upload your Avatar”, “Upload your photo”  View File directory traversal “../../../../web.config”  Exactly the same bugs as 5 years ago

24.  Broken access controls.  Most development frameworks now provide authentication functionality. .NET Forms Authentication  “Any file under a directory, needs a username/password”  When developers implement their own access controls they FAIL.  “Unauthorized Access to Administrative AJAX Call “WriteCSS()”  Part of the Administrator's CMS application Edit CSS  Allowed anyone to write a file, anywhere on the web server.  All other pages required authentication, except the AJAX function!

25.  Growth in application logic manipulation.  All of the new fancy Web 2.0 technology contains complex application logic.  Which can often be manipulated by user supplied input.  10 of the 14 Medium severity findings relate to logic manipulation bugs.  Manipulate how the application works.  Accessing hidden controls/menu items.  Skipping a sequence of events.  Skip from Stage 1, to Stage 3  Purchasing negative amounts of products.  Bypassing applications requirements.  “You may only enter this competition once”

26.  “Users can skip the “Pay Now” stage, and proceed without payment”  What year is it?  Stage 5 = Confirm order  Stage 6 = Pay now  Stage 7 = Enter your shipping address  Stage 8 = Finalize your order  Dumb Mistakes.

27.  Direct Object Reference is not going anywhere.  Regular occurrence in application reviews.  Inconsistent/faulty access controls.  People still don’t read the manual.  “Make sure you change the default Admin password from ‘Admin’”  Its right there, in black and white. Yet still, no one does it.  The passwords:  Password0, Password9, 321, Admin, Manager, CMSADMIN  These are not good passwords.  Yet all found in 2009 security reviews!

28.  Less of the 2009 vulnerabilities resulted a shell.  More cases of sensitive information disclosure.  Name, address, date of birth, credit card.  What did I learn from reading all of these security reports ?  Is it getting more secure?

29. We have known how to be secure for 25 years! Still working on actually being secure.  Developers still do dumb things, 2003, 2005, 2009..  Security only works flawlessly when its already implemented in the framework.  Developers don’t have to do it!  Security can be challenging to implement correctly.  Education helps security.  Everyone knows about SQL injection.  SQL injection vulnerabilities decreased significantly. Fewer Critical Findings = More Secure The internet IS getting better, but its not there yet! I only need one critical bug.

30.  Thanks For Your Time  Questions / Comments ?  Paul.Craig@security-assessment.com