Application Security

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/

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 overflowhttp://secunia.com/advisories/18649/ • Word memory corruption (CVE-2007-3899)http://www.microsoft.com/technet/security/Bulletin/MS07-060.mspx • PHP Project Management file inclusionhttp://secunia.com/advisories/27347/ • iPhone TIFF file processing vulnerabilityhttp://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 * 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) • Apache security tips (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://<vendor_web_site>/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 Securityhttp://msdn2.microsoft.com/en-us/library/aa286519.aspx • Secure Coding Guidelines for the Java Programming Languagehttp://java.sun.com/security/seccodeguide.html • Secure Coding in C and C++ (Book)http://www.cert.org/books/secure-coding/ • CERT Secure Coding Standards (Wiki)https://www.securecoding.cert.org/

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