![Page 1: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/1.jpg)
Application Security
2007 Annual Security Training
Kansas State University
![Page 2: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/2.jpg)
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
![Page 3: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/3.jpg)
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.
![Page 4: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/4.jpg)
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/
![Page 5: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/5.jpg)
Application Security
• Difficult to define, but the following comes close
• “everything involved in developing, maintaining, and purchasing applications that your organization can trust”– OWASP
![Page 6: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/6.jpg)
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
![Page 7: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/7.jpg)
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
![Page 8: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/8.jpg)
Sample attacks
• To illustrate, a few sample attacks– WinAMP playlist parsing overflow
http://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/
![Page 9: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/9.jpg)
Scope of the problem
• Vulnerability statistics– CVE (Common Vulnerabilities and
Exposures) is a widely accepted standard naming system for publicly known vulnerabilities
Year 2003 2004 2005 2006 2007*
Vulns 1493 2442 4926 6602 5708
* 2007 through mid-October
![Page 10: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/10.jpg)
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
![Page 11: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/11.jpg)
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
![Page 12: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/12.jpg)
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
![Page 13: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/13.jpg)
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
![Page 14: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/14.jpg)
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
![Page 15: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/15.jpg)
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
![Page 16: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/16.jpg)
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
![Page 17: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/17.jpg)
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.
![Page 18: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/18.jpg)
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)
![Page 19: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/19.jpg)
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
![Page 20: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/20.jpg)
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
![Page 21: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/21.jpg)
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?
![Page 22: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/22.jpg)
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
![Page 23: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/23.jpg)
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
![Page 24: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/24.jpg)
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
– 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/
![Page 25: Application Security 2007 Annual Security Training Kansas State University](https://reader038.vdocuments.us/reader038/viewer/2022110322/56649d0a5503460f949dc4ca/html5/thumbnails/25.jpg)
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/