Application Security

2007 Annual Security Training

Kansas State University

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

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.

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/

Application Security

• Difficult to define, but the following comes close

• “everything involved in developing, maintaining, and purchasing applications that your organization can trust”– OWASP

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

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

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/

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

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

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

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

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

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

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

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

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.

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)

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

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

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?

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

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

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/

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/