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:

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 –Word memory corruption (CVE ) –PHP Project Management file inclusion –iPhone TIFF file processing vulnerability

Scope of the problem Vulnerability statistics –CVE (Common Vulnerabilities and Exposures) is a widely accepted standard naming system for publicly known vulnerabilities Year * Vulns * 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 ( Apache security tips ( tips.html) 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 /security /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 –Secure Coding Guidelines for the Java Programming Language –Secure Coding in C and C++ (Book) –CERT Secure Coding Standards (Wiki)

Resources and References Open Web Application Security Project SPIKE, SPIKE Proxy freesoftware.shtml freesoftware.shtml PROTOS CERT Secure Coding Standards (Wiki) CERT