1. Application Security 2007 Annual Security Training Kansas State University

2. Introduction Jeremiah Shirk InfoSec geek for over a decade –Firewall design –Security consulting –Vulnerability and malware research Currently, Application Services Administrator for the Office of Mediated Education

3. Office of Mediated Education Our mission –The Office of Mediated Education is dedicated to providing innovative and reliable solutions to meet the academic computing needs of K-State in the areas of teaching and learning as well as research, technology transfer and outreach. Project Highlights –DCE/EIS, Survey, K-State Online / Axio, Transaction Hub, Electronic Grade Submission, KEAS, eProfile & WID Support tools, ExpanSIS,Online TEVAL, SGA Elections, several Lecture Series, and too many more to list.

4. OME Services Web Hosting and Design Instructional Design Consultation Live A/V Webcasting CD/DVD Duplication A/V Encoding and Editing Web Presentations More information available at: http://ome.ksu.edu/about/ http://ome.ksu.edu/about/

5. Application Security Difficult to define, but the following comes close “everything involved in developing, maintaining, and purchasing applications that your organization can trust” –OWASP

6. Why does it matter? Attacks focus on data Applications have a trusted place in our networks Attacks on applications come in through avenues that cannot simply be blocked at the perimeter

7. Different perspectives Commercial applications –Expect vendor to keep application secure –Administrators (and users!) have a responsibility as well Home-grown applications –We are the vendor and user Open source application –Some mix of the above All applications –Ultimately, we are responsible for the security of all the apps that we install and/or use

8. Sample attacks To illustrate, a few sample attacks –WinAMP playlist parsing overflow http://secunia.com/advisories/18649/ http://secunia.com/advisories/18649/ –Word memory corruption (CVE-2007-3899) http://www.microsoft.com/technet/security/Bulletin/MS07-060.mspx http://www.microsoft.com/technet/security/Bulletin/MS07-060.mspx –PHP Project Management file inclusion http://secunia.com/advisories/27347/ http://secunia.com/advisories/27347/ –iPhone TIFF file processing vulnerability http://secunia.com/advisories/27213/ http://secunia.com/advisories/27213/

9. Scope of the problem Vulnerability statistics –CVE (Common Vulnerabilities and Exposures) is a widely accepted standard naming system for publicly known vulnerabilities Year20032004200520062007* Vulns14932442492666025708 * 2007 through mid-October

10. Which apps are vulnerable? Probably most of them Many vulnerabilities are as yet unknown In my personal experience: –Many who have looked for vulnerabilities have found them –None who looked at an app reported finding nothing –This is admittedly unscientific, but strongly suggestive If you look for vulnerabilities, you will find them

11. New threats How are new application vulnerabilities found? –Input fuzzing –Patch analysis Source, if available Binary patch differential analysis –Executable “debugging” Where do vulnerabilities come from? Developers, but more on that later

12. Input Fuzzing Testing by providing random input to a program, and noting failures and exceptions –Practical fuzzing takes into account data structures in protocols and/or file formats –SPIKE, and SPIKE Proxy, PROTOS –Inputs can include network connections, files, environment variables, yielding different attack vectors

13. Patch Analysis When a patch comes out, examine what changes This drastically narrows the scope of searching for vulnerabilities, which will work on all un-patched systems Tools to make it easier –Sabre BinDiff

14. Debugging/disassembling Complementary to fuzzing and patch analysis –Once you know where the code breaks, debugging/disassembling lets you find out how it breaks, and how to exploit it –Tools SoftICE IDAPro OllyDbg -- Free and powerful

15. Defense: What can we do? Depends on the type of software –Third party applications Open source Commercial –Internally developed applications Some strategies for each type

16. Third-party application security strategies Keep up with patches Read the (fine) manual Subscribe to security and announcement mailing lists Minimal software footprint Select applications with a better security track record

17. Keep up with patches Pay special attention to security patches, if the vendor makes the distinction Some vendors, such as Microsoft, allow for automatic patching. For most users, the risk of a bad patch is less than the risk of a delayed patch. Worms often spread near patch releases (immediately before and after) so time is of the essence.

18. Read the manual If your software manual specifically refers to security, it’s probably important –Most often true of servers and frameworks The PHP manual has multiple chapters on security (http://php.net/manual/en/security.php)http://php.net/manual/en/security.php Apache security tips (http://httpd.apache.org/docs/2.0/misc/security_ tips.html)http://httpd.apache.org/docs/2.0/misc/security_ tips.html

19. Subscribe to security mailing lists Almost all vendors now have a mailing list for security issues. This is one of the best ways to know as soon as possible about threats to your applications Details often found at http:// /security http:// /security Or search with Google…these lists almost always exist

20. Minimal software footprint Avoid installing components you don’t need For servers and frameworks, turn off or restrict features you won’t use The less software you run, the less chance you are running insecure code

21. Select secure software Some vendors have a better security track record Review security mailing lists: Does the vendor: –release patches before vulnerabilities are disclosed? –Release patches quickly? –Give direct information about risks?

22. Home grown applications Security advantages –Fewer interested attackers –Security through obscurity Security disadvantages –Responsible for own patches –Those who find flaws may be less likely to reveal them

23. Principles for secure apps Input validation –Defending against fuzzing and ‘smart’ attacks Start with a secure platform Limit public interfaces Layered security Avoid clear-text protocols

24. Guidelines for secure coding Depends on your tool set, but there is a lot of good help out there –.Net Security http://msdn2.microsoft.com/en-us/library/aa286519.aspx http://msdn2.microsoft.com/en-us/library/aa286519.aspx –Secure Coding Guidelines for the Java Programming Language http://java.sun.com/security/seccodeguide.html http://java.sun.com/security/seccodeguide.html –Secure Coding in C and C++ (Book) http://www.cert.org/books/secure-coding/ http://www.cert.org/books/secure-coding/ –CERT Secure Coding Standards (Wiki) https://www.securecoding.cert.org/ https://www.securecoding.cert.org/

25. Resources and References Open Web Application Security Project http://www.owasp.org/ http://www.owasp.org/ SPIKE, SPIKE Proxy http://www.immunitysec.com/resources- freesoftware.shtml http://www.immunitysec.com/resources- freesoftware.shtml PROTOS http://www.ee.oulu.fi/research/ouspg/protos/ http://www.ee.oulu.fi/research/ouspg/protos/ CERT Secure Coding Standards (Wiki) https://www.securecoding.cert.org/ https://www.securecoding.cert.org/ CERT http://www.cert.org/ http://www.cert.org/